NGINX ۱.۳۱.۷ یک انتشار مهم برای مدیران وب‌سرور است؛ چون علاوه بر قابلیت‌های تازه، چند تغییر رفتاری دارد که باید پیش از ارتقا در محیط staging بررسی شوند. نسخهٔ جدید پشتیبانی بومی از پایگاه‌های GeoIP2 و GeoLite2 مبتنی بر MMDB را به ماژول‌های HTTP و Stream اضافه می‌کند، اولویت‌بندی مدرن HTTP/۲ را فعال می‌سازد و مسیر reload و binary upgrade در استقرارهای QUIC مبتنی بر BPF را بهبود می‌دهد.
مهم‌ترین تغییرات NGINX ۱.۳۱.۷
در این مطلب، NGINX ۱.۳۱.۷ را از زاویهٔ مهاجرت GeoIP، رفتار HTTP/۲ و ریسک عملیاتی ارتقا بررسی می‌کنیم.
مهم‌ترین تغییر برای بسیاری از نصب‌های قدیمی، اضافه‌شدن پشتیبانی native از MaxMind DB یا MMDB است. مدیران می‌توانند در ماژول‌های موجود GeoIP از پایگاه‌های GeoIP2 و GeoLite2 استفاده کنند و در بسیاری از سناریوها همان مدل آشنای directiveها و متغیرهای $geoip_* را حفظ کنند. این مسیر، مهاجرت از قالب قدیمی GeoIP را ساده‌تر می‌کند؛ قالبی که چرخهٔ عمر آن پایان یافته و داده‌هایش به‌مرور قدیمی‌تر می‌شوند.
بااین‌حال، MMDB کاملاً معادل پایگاه قدیمی نیست. بعضی متغیرها از فیلدهای متفاوتی پر می‌شوند، کد سه‌حرفی کشور از کد دوحرفی استخراج می‌شود و فیلدهایی مانند area code ممکن است دیگر مقدار نداشته باشند. بنابراین پیش از تغییر در production باید خروجی کشور، شهر، سازمان و منطقه را با داده‌های واقعی لاگ‌ها مقایسه کنید.
اولویت‌بندی HTTP/۲ بر پایه RFC ۹۲۱۸
در NGINX ۱.۳۱.۷ ماژول HTTP/۲ از طرح اولویت‌بندی RFC ۹۲۱۸ پشتیبانی می‌کند. کلاینت می‌تواند با header یا فریم PRIORITY_UPDATE میزان urgency و incremental بودن پاسخ را مشخص کند. urgency از ۰ تا ۷ تعریف می‌شود و مقدار کمتر، اولویت بالاتری دارد. این قابلیت برای صفحاتی که منابع مهمی مانند CSS یا پاسخ‌های API حساس دارند مفید است، چون NGINX می‌تواند آن‌ها را در زمان رقابت منابع زودتر ارسال کند.
این تغییر به‌صورت پیش‌فرض فعال است و به directive جداگانه نیاز ندارد. در مقابل، سیگنال‌های قدیمی مبتنی بر درخت وابستگی و weight در RFC ۷۵۴۰ نادیده گرفته می‌شوند. تیم‌های توسعه باید رفتار واقعی مرورگرها، CDN و reverse proxyهای بین مسیر را در محیط آزمایشی اندازه‌گیری کنند؛ مخصوصاً اگر قبلاً روی weightهای HTTP/۲ حساب کرده‌اند.
بهبود QUIC و BPF در reload
برای تیم‌هایی که NGINX ۱.۳۱.۷ را در لبهٔ شبکه اجرا می‌کنند، این بخش از تغییرات اهمیت ویژه‌ای دارد.
برای استقرارهایی که از مسیریابی QUIC مبتنی بر BPF استفاده می‌کنند، نسخهٔ جدید reload و binary upgrade را پایدارتر می‌کند. در زمان reload، workerهای جدید اتصال‌های تازه را می‌گیرند و workerهای قبلی نشست‌های موجود را تا پایان drain می‌کنند. این تغییر احتمال گیرکردن اتصال‌ها هنگام reload یا جایگزینی binary را کاهش می‌دهد، اما وضعیت HTTP/۳ و QUIC در این مسیر همچنان experimental است و نباید بدون آزمون به‌عنوان تضمین production در نظر گرفته شود.
پنج اصلاح امنیتی و نکته‌های سازگاری
در NGINX ۱.۳۱.۷ پنج اصلاح امنیتی اصلی در کنار تغییرات سازگاری ارائه شده است.
با توجه به اصلاحات امنیتی NGINX ۱.۳۱.۷، بررسی نسخهٔ فعلی و برنامهٔ rollback باید پیش از rollout انجام شود.
این انتشار پنج مشکل امنیتی را اصلاح می‌کند؛ ازجمله سرریز بافر در ترکیب خاص alias و rewrite، مشکل ارزیابی script، تزریق request body در HTTP/۳، جعل نشست با TLS session ticket و use-after-free در asynchronous file I/O. نسخهٔ ۱.۳۱.۶ نیز یک اصلاح امنیتی مرتبط با HTTP/۳ داشت، بنابراین ارتقا از نسخه‌های قدیمی‌تر باید با مرور کامل changelog انجام شود.
دو تغییر سازگاری را پیش از ارتقا جدی بگیرید:
client_body_buffer_size، proxy_buffers، bufferهای stream، HTTP/۳ و SSL را جست‌وجو کنید و سپس nginx -t بگیرید.dNSName یا common name دیگر کافی نیست.برای مرور نکات عملی ارتقای سرویس‌ها، راهنمای چک‌لیست ارتقای امن سرویس‌های وب را هم کنار برنامهٔ تغییر خود قرار دهید.
چک‌لیست ارتقای امن
۱. نسخهٔ فعلی، ماژول‌های فعال و روش build را ثبت کنید و وجود libmaxminddb را برای buildهای source بررسی کنید.
۲. همهٔ directiveهای GeoIP و متغیرهای مصرف‌شده در لاگ، routing و محتوای محلی‌سازی‌شده را فهرست کنید.
۳. تنظیمات buffer با مقدار صفر و گواهی‌های upstream را اصلاح کنید و در staging فرمان nginx -t را اجرا کنید.
۴. reload، binary upgrade، HTTP/۲ priority و سناریوهای QUIC/BPF را با ترافیک کنترل‌شده آزمایش کنید.
۵. backup، مسیر rollback، health check، خطاهای TLS و لاگ workerها را پیش از rollout production آماده کنید.
جمع‌بندی
NGINX ۱.۳۱.۷ فقط یک به‌روزرسانی قابلیت نیست؛ ترکیبی از مهاجرت دادهٔ GeoIP، تغییر رفتار HTTP/۲، بهبود مسیرهای QUIC و اصلاحات امنیتی است. مدیران وب‌سرور بهتر است ابتدا نسخه و پیکربندی را inventory کنند، سپس تست staging و rollback را انجام دهند و بعد از ارتقا سلامت پاسخ‌ها، گواهی‌ها، reload و لاگ‌ها را بررسی کنند. منبع اصلی، اعلام رسمی NGINX Community Blog است.
