nginx 1.20.0 रिलीज करा

एका वर्षाच्या विकासानंतर, उच्च-कार्यक्षमता HTTP सर्व्हर आणि मल्टीप्रोटोकॉल प्रॉक्सी सर्व्हरची एक नवीन स्थिर शाखा, nginx 1.20.0, रिलीज करण्यात आली आहे. त्यात मुख्य 1.19.x शाखेत जमा झालेले बदल समाविष्ट आहेत. पुढे जाऊन, स्थिर 1.20 शाखेतील सर्व बदल गंभीर बग आणि भेद्यता दुरुस्त करण्यावर केंद्रित असतील. मुख्य nginx 1.21 शाखा लवकरच रिलीज केली जाईल, जिथे नवीन वैशिष्ट्ये विकसित केली जातील. नियमित वापरकर्त्यांसाठी ज्यांना तृतीय-पक्ष मॉड्यूलसह ​​सुसंगतता सुनिश्चित करण्याची आवश्यकता नाही, आम्ही मुख्य शाखा वापरण्याची शिफारस करतो, जी दर तीन महिन्यांनी व्यावसायिक Nginx Plus रिलीझसाठी आधार आहे.

नेटक्राफ्टच्या मार्च महिन्याच्या अहवालानुसार, सर्व सक्रिय वेबसाइट्सपैकी २०.१५% वर nginx वापरले जाते (एक वर्षापूर्वी १९.५६%, दोन वर्षांपूर्वी २०.७३%), जे या श्रेणीतील लोकप्रियतेत दुसऱ्या स्थानाशी जुळते (अपाचेचा वाटा २५.३८% (एक वर्षापूर्वी २७.६४%), गुगलचा १०.०९% आणि क्लाउडफ्लेअरचा वाटा ८.५१%). त्याच वेळी, सर्व वेबसाइट्सचा विचार करता, nginx त्याचे नेतृत्व कायम ठेवते आणि बाजारपेठेतील ३५.३४% (एक वर्षापूर्वी ३६.९१%, दोन वर्षांपूर्वी २७.५२%) व्यापते, तर Apache चा वाटा २५.९८%, OpenResty चा (nginx आणि LuaJIT वर आधारित प्लॅटफॉर्म) ६.५५% ​​आणि Microsoft IIS चा वाटा ५.९६% आहे.

जगातील सर्वाधिक भेट दिलेल्या दशलक्ष वेबसाइट्समध्ये, nginx चा वाटा २५.५५% आहे (एक वर्षापूर्वी २५.५४%, दोन वर्षांपूर्वी २६.२२%). सध्या, nginx अंदाजे ४१९ दशलक्ष वेबसाइट्सना (एक वर्षापूर्वी ४५९ दशलक्ष) समर्थन देते. W3Techs नुसार, सर्वाधिक भेट दिलेल्या दशलक्ष वेबसाइट्सपैकी ३३.७% वेबसाइट्सवर nginx वापरले जाते; गेल्या वर्षी एप्रिलमध्ये, हा आकडा ३१.९% होता आणि त्याआधीच्या वर्षी, तो ४१.८% होता (क्लाउडफ्लेअरच्या HTTP सर्व्हरच्या स्वतंत्र अकाउंटिंगमध्ये संक्रमणामुळे ही घट स्पष्ट झाली आहे). वर्षभरात Apache चा वाटा ३९.५% वरून ३४% पर्यंत कमी झाला आणि मायक्रोसॉफ्ट IIS चा वाटा ८.३% वरून ७% पर्यंत कमी झाला. LiteSpeed ​​चा वाटा ६.३% वरून ८.४% पर्यंत वाढला आणि Node.js चा ०.८% वरून १.२% पर्यंत वाढला. रशियामध्ये, सर्वाधिक भेट दिलेल्या वेबसाइटपैकी ७९.१% वेबसाइट्स NGINX वापरतात (गेल्या वर्षी - ७८.९%).

1.19.x अपस्ट्रीम शाखेच्या विकासादरम्यान जोडलेल्या सर्वात लक्षणीय सुधारणा:

• OCSP (ऑनलाइन सर्टिफिकेट स्टेटस प्रोटोकॉल) वर आधारित बाह्य सेवा वापरून क्लायंट सर्टिफिकेट पडताळण्याची क्षमता जोडण्यात आली आहे. पडताळणी सक्षम करण्यासाठी ssl_ocsp निर्देश वापरला जातो, कॅशे आकार कॉन्फिगर करण्यासाठी ssl_ocsp_cache वापरला जातो आणि प्रमाणपत्रात निर्दिष्ट केलेल्या OCSP हँडलर URL ला ओव्हरराइड करण्यासाठी ssl_ocsp_responder वापरला जातो.
• ngx_stream_set_module मॉड्यूल समाविष्ट आहे, जो तुम्हाला सर्व्हर व्हेरिएबलला मूल्य नियुक्त करण्याची परवानगी देतो { listen 12345; set $true 1; }
• प्रॉक्सी कनेक्शनमध्ये कुकीजसाठी फ्लॅग निर्दिष्ट करण्यासाठी proxy_cookie_flags निर्देश जोडण्यात आला आहे. उदाहरणार्थ, कुकी "वन" मध्ये "httponly" फ्लॅग आणि इतर सर्व कुकीजमध्ये "nosecure" आणि "samesite=strict" फ्लॅग जोडण्यासाठी, तुम्ही खालील रचना वापरू शकता: proxy_cookie_flags one httponly; proxy_cookie_flags ~ nosecure samesite=strict;

  कुकीमध्ये फ्लॅग जोडण्यासाठी 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 पर्यायांना प्राधान्य द्याChaCha; ssl_conf_command सायफरसुइट्स TLS_CHACHA20_POLY1305_SHA256; निर्दिष्ट करू शकता.
• "ssl_reject_handshake" हा निर्देश जोडला आहे, जो सर्व हस्तांदोलन प्रयत्नांना नकार देण्याचे निर्देश देतो. SSL-कनेक्शन्स (उदाहरणार्थ, SNI फील्डमधील अज्ञात होस्टनेम असलेल्या सर्व विनंत्या नाकारण्यासाठी वापरल्या जाऊ शकतात). सर्व्हर { ऐका 443 ssl; ssl_reject_handshake चालू; } सर्व्हर { ऐका 443 ssl; सर्व्हर_नाव example.com; ssl_certificate example.com.crt; ssl_certificate_key example.com.key; }
• मेल प्रॉक्सीमध्ये proxy_smtp_auth डायरेक्टिव्ह जोडण्यात आला आहे, जो AUTH कमांड आणि PLAIN SASL मेकॅनिझम वापरून बॅकएंडवर वापरकर्ता प्रमाणीकरण करण्यास अनुमती देतो.
• "keepalive_time" निर्देश जोडला गेला आहे, जो प्रत्येक कीप-अलाइव्ह कनेक्शनच्या एकूण आयुष्यमानावर मर्यादा घालतो, त्यानंतर कनेक्शन बंद केले जाईल (कीपअलाइव्ह_टाइमआउटसह गोंधळून जाऊ नका, जे कीप-अलाइव्ह कनेक्शन बंद झाल्यानंतर निष्क्रियतेचा वेळ निश्चित करते).
• $connection_time व्हेरिएबल जोडले आहे, ज्याचा वापर मिलिसेकंद अचूकतेसह सेकंदांमध्ये कनेक्शन कालावधीबद्दल माहिती मिळविण्यासाठी केला जाऊ शकतो.
• "proxy_cache_path", "fastcgi_cache_path", "scgi_cache_path", आणि "uwsgi_cache_path" निर्देशांमध्ये "min_free" पॅरामीटर जोडला गेला आहे. हे पॅरामीटर किमान मोकळ्या डिस्क जागेवर आधारित कॅशे आकार नियंत्रित करते.
• "lingering_close", "lingering_time", आणि "lingering_timeout" निर्देश HTTP/2 सह कार्य करण्यासाठी अनुकूलित केले गेले आहेत.
• HTTP/2 कनेक्शन हँडलिंग कोड HTTP/1.x अंमलबजावणीच्या जवळ आणला गेला आहे. सामान्य "keepalive_timeout" आणि "keepalive_requests" निर्देशांच्या बाजूने वैयक्तिक "http2_recv_timeout," "http2_idle_timeout," आणि "http2_max_requests" सेटिंग्जसाठी समर्थन कालबाह्य करण्यात आले आहे. "http2_max_field_size" आणि "http2_max_header_size" सेटिंग्ज काढून टाकण्यात आल्या आहेत; त्याऐवजी "large_client_header_buffers" वापरावे.
• "-e" हा एक नवीन कमांड लाइन पर्याय जोडण्यात आला आहे. हा पर्याय तुम्हाला सेटिंग्जमध्ये निर्दिष्ट केलेल्या ऐवजी वापरण्यासाठी पर्यायी एरर लॉग फाइल निर्दिष्ट करण्याची परवानगी देतो. फाइल नावाऐवजी stderr हे विशेष मूल्य निर्दिष्ट केले जाऊ शकते.

स्त्रोत: opennet.ru