nginx 1.20.0 ریلیز کریں۔

ایک سال کی ترقی کے بعد، اعلی کارکردگی والے HTTP سرور اور ملٹی پروٹوکول پراکسی سرور nginx 1.20.0 کی ایک نئی مستحکم برانچ متعارف کرائی گئی ہے، جو مرکزی برانچ 1.19.x میں جمع ہونے والی تبدیلیوں کو شامل کرتی ہے۔ مستقبل میں، مستحکم برانچ 1.20 میں تمام تبدیلیاں سنگین غلطیوں اور کمزوریوں کے خاتمے سے متعلق ہوں گی۔ جلد ہی nginx 1.21 کی مرکزی شاخ تشکیل دی جائے گی، جس میں نئی ​​خصوصیات کی ترقی جاری رہے گی۔ عام صارفین کے لئے جن کے پاس تھرڈ پارٹی ماڈیولز کے ساتھ مطابقت کو یقینی بنانے کا کام نہیں ہے، یہ مرکزی برانچ استعمال کرنے کی سفارش کی جاتی ہے، جس کی بنیاد پر ہر تین ماہ بعد تجارتی مصنوعات Nginx Plus کی ریلیز کی جاتی ہے۔

Netcraft کی مارچ کی ایک رپورٹ کے مطابق، nginx تمام فعال سائٹس کے 20.15% پر استعمال کیا جاتا ہے (ایک سال پہلے 19.56%، دو سال پہلے 20.73%)، جو اس زمرے میں مقبولیت میں دوسرے نمبر کے مساوی ہے (Apache کا حصہ 25.38% کے مساوی ہے۔ (ایک سال پہلے 27.64%)، گوگل - 10.09%، Cloudflare - 8.51%۔ ایک ہی وقت میں، تمام سائٹس پر غور کرتے وقت، nginx اپنی قیادت کو برقرار رکھتا ہے اور مارکیٹ کے 35.34% پر قبضہ کرتا ہے (ایک سال پہلے 36.91%، دو سال پہلے - 27.52%)، جبکہ اپاچی کا حصہ 25.98% کے مساوی ہے، OpenResty (پلیٹ فارم جو nginx اور LuaJIT پر مبنی ہے۔) - 6.55%، Microsoft IIS - 5.96%۔

دنیا میں سب سے زیادہ دیکھی جانے والی ملین سائٹس میں، nginx کا حصہ 25.55% ہے (ایک سال پہلے 25.54%، دو سال پہلے 26.22%)۔ فی الحال، تقریباً 419 ملین ویب سائٹس Nginx (459 ملین ایک سال پہلے) چل رہی ہیں۔ W3Techs کے مطابق، nginx سب سے زیادہ دیکھے جانے والے ملین میں سے 33.7% سائٹس پر استعمال کیا جاتا ہے، پچھلے سال اپریل میں یہ تعداد 31.9% تھی، جو ایک سال پہلے تھی - 41.8% (کمی کی وضاحت Cloudflare http کے علیحدہ اکاؤنٹنگ میں منتقلی سے ہوتی ہے۔ سرور)۔ اپاچی کا حصہ سال بھر میں 39.5٪ سے 34٪ تک گر گیا، اور Microsoft IIS کا حصہ 8.3٪ سے 7٪ پر آگیا۔ LiteSpeed ​​کا حصہ 6.3% سے بڑھ کر 8.4%، اور Node.js 0.8% سے 1.2% ہو گیا۔ روس میں، nginx سب سے زیادہ دیکھی جانے والی 79.1% سائٹس پر استعمال ہوتا ہے (ایک سال پہلے - 78.9%)۔

1.19.x اپ اسٹریم برانچ کی ترقی کے دوران شامل کی گئی سب سے قابل ذکر بہتری:

  • OCSP (آن لائن سرٹیفکیٹ اسٹیٹس پروٹوکول) پروٹوکول کی بنیاد پر بیرونی خدمات کا استعمال کرتے ہوئے کلائنٹ سرٹیفکیٹس کی تصدیق کرنے کی صلاحیت کو شامل کیا گیا۔ چیک کو فعال کرنے کے لیے، ssl_ocsp ہدایت تجویز کی گئی ہے، کیشے کے سائز کو کنفیگر کرنے کے لیے - ssl_ocsp_cache، سرٹیفکیٹ - ssl_ocsp_responder میں متعین OCSP ہینڈلر کے URL کی دوبارہ وضاحت کرنے کے لیے۔
  • ngx_stream_set_module ماڈیول شامل ہے، جو آپ کو متغیر سرور کو ایک قدر تفویض کرنے کی اجازت دیتا ہے { listen 12345; $true 1 سیٹ کریں؛ }
  • پراکسیڈ کنکشنز میں کوکیز کے لیے جھنڈوں کی وضاحت کرنے کے لیے proxy_cookie_flags ہدایت شامل کی گئی۔ مثال کے طور پر، کوکی "ایک" میں "httponly" جھنڈا شامل کرنے کے لیے، اور تمام دیگر کوکیز کے لیے "nosecure" اور "samesite=strict" جھنڈے شامل کرنے کے لیے، آپ مندرجہ ذیل تعمیر کا استعمال کر سکتے ہیں: proxy_cookie_flags one httponly; proxy_cookie_flags ~ nosecure samesite = سخت؛

    کوکیز میں جھنڈے شامل کرنے کے لیے اسی طرح کی userid_flags ہدایت ngx_http_userid ماڈیول کے لیے بھی لاگو کی گئی ہے۔

  • "ssl_conf_command"، "proxy_ssl_conf_command"، "grpc_ssl_conf_command" اور "uwsgi_ssl_conf_command" کو شامل کیا گیا، جس کے ساتھ آپ OpenSSL کو ترتیب دینے کے لیے صوابدیدی پیرامیٹرز سیٹ کر سکتے ہیں۔ مثال کے طور پر، ChaCha سائفرز اور TLSv1.3 سائفرز کی ایڈوانس کنفیگریشن کو ترجیح دینے کے لیے، آپ ssl_conf_command Options PrioritizeChaCha کی وضاحت کر سکتے ہیں؛ ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256؛
  • شامل کیا گیا "ssl_reject_handshake" ہدایت، جو SSL کنکشنز پر گفت و شنید کرنے کی تمام کوششوں کو مسترد کرنے کی ہدایت کرتی ہے (مثال کے طور پر، SNI فیلڈ میں نامعلوم میزبان ناموں والی تمام کالوں کو مسترد کرنے کے لیے استعمال کیا جا سکتا ہے)۔ سرور { سنیں 443 ایس ایس ایل؛ ssl_reject_handshake on; } سرور { سنیں 443 ایس ایس ایل؛ server_name example.com؛ ssl_certificate example.com.crt؛ ssl_certificate_key example.com.key؛ }
  • proxy_smtp_auth ہدایت کو میل پراکسی میں شامل کر دیا گیا ہے، جس سے آپ AUTH کمانڈ اور PLAIN SASL میکانزم کا استعمال کرتے ہوئے بیک اینڈ پر صارف کی تصدیق کر سکتے ہیں۔
  • "keepalive_time" ہدایت شامل کی گئی، جو ہر ایک زندہ رہنے والے کنکشن کی کل زندگی کو محدود کرتی ہے، جس کے بعد کنکشن بند ہو جائے گا (keepalive_timeout کے ساتھ الجھن میں نہ پڑیں، جو غیر فعال ہونے کے وقت کی وضاحت کرتا ہے جس کے بعد کیپ-ایلیو کنکشن بند ہو جاتا ہے)۔
  • شامل کیا گیا $connection_time متغیر، جس کے ذریعے آپ ملی سیکنڈ کی درستگی کے ساتھ سیکنڈوں میں کنکشن کی مدت کے بارے میں معلومات حاصل کر سکتے ہیں۔
  • ایک "min_free" پیرامیٹر کو "proxy_cache_path"، "fastcgi_cache_path"، "scgi_cache_path" اور "uwsgi_cache_path" ہدایات میں شامل کیا گیا ہے، جو مفت ڈسک کی جگہ کے کم از کم سائز کے تعین کی بنیاد پر کیشے کے سائز کو منظم کرتا ہے۔
  • "lingering_close"، "lingering_time" اور "lingering_timeout" ہدایات کو HTTP/2 کے ساتھ کام کرنے کے لیے ڈھال لیا گیا ہے۔
  • HTTP/2 میں کنکشن پروسیسنگ کوڈ HTTP/1.x کے نفاذ کے قریب ہے۔ انفرادی ترتیبات "http2_recv_timeout"، "http2_idle_timeout" اور "http2_max_requests" کے لیے سپورٹ کو عام ہدایات "keepalive_timeout" اور "keepalive_requests" کے حق میں بند کر دیا گیا ہے۔ ترتیبات "http2_max_field_size" اور "http2_max_header_size" کو ہٹا دیا گیا ہے اور اس کے بجائے "large_client_header_buffers" استعمال کیا جانا چاہئے۔
  • ایک نیا کمانڈ لائن آپشن "-e" شامل کیا گیا، جو آپ کو ایرر لاگ لکھنے کے لیے ایک متبادل فائل کی وضاحت کرنے کی اجازت دیتا ہے، جو سیٹنگز میں متعین لاگ کے بجائے استعمال کی جائے گی۔ فائل کے نام کے بجائے، آپ اسپیشل ویلیو stderr کی وضاحت کر سکتے ہیں۔

ماخذ: opennet.ru

نیا تبصرہ شامل کریں