nginx 1.20.0 रिलीज

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

नेटक्राफ्ट की मार्च रिपोर्ट के अनुसार, सभी सक्रिय साइटों में से 20.15% पर nginx का उपयोग किया जाता है (एक साल पहले 19.56%, दो साल पहले 20.73%), जो इस श्रेणी में लोकप्रियता में दूसरे स्थान से मेल खाती है (अपाचे की हिस्सेदारी 25.38% से मेल खाती है) (एक साल पहले 27.64%), Google - 10.09%, Cloudflare - 8.51%। साथ ही, सभी साइटों पर विचार करते समय, nginx अपना नेतृत्व बरकरार रखता है और 35.34% बाजार पर कब्जा कर लेता है (एक साल पहले 36.91%, दो साल पहले - 27.52%), जबकि Apache की हिस्सेदारी 25.98%, OpenResty (nginx और LuaJIT पर आधारित प्लेटफॉर्म) - 6.55%, Microsoft IIS - 5.96% से मेल खाती है।

दुनिया में सबसे अधिक देखी जाने वाली दस लाख साइटों में से, nginx की हिस्सेदारी 25.55% (एक साल पहले 25.54%, दो साल पहले 26.22%) है। वर्तमान में, लगभग 419 मिलियन वेबसाइटें Nginx (एक वर्ष पहले 459 मिलियन) चला रही हैं। W3Tech के अनुसार, सबसे अधिक देखी जाने वाली दस लाख साइटों में से 33.7% साइटों पर nginx का उपयोग किया जाता है, पिछले साल अप्रैल में यह आंकड़ा 31.9% था, एक साल पहले - 41.8% (गिरावट को क्लाउडफ्लेयर के अलग लेखांकन में संक्रमण द्वारा समझाया गया है) http सर्वर). वर्ष के दौरान अपाचे की हिस्सेदारी 39.5% से गिरकर 34% हो गई, और माइक्रोसॉफ्ट आईआईएस की हिस्सेदारी 8.3% से गिरकर 7% हो गई। लाइटस्पीड की हिस्सेदारी 6.3% से बढ़कर 8.4% और Node.js की हिस्सेदारी 0.8% से बढ़कर 1.2% हो गई। रूस में, सबसे अधिक देखी जाने वाली साइटों में से 79.1% पर nginx का उपयोग किया जाता है (एक वर्ष पहले - 78.9%)।

1.19.x अपस्ट्रीम शाखा के विकास के दौरान जोड़े गए सबसे उल्लेखनीय सुधार:

• OCSP (ऑनलाइन सर्टिफिकेट स्टेटस प्रोटोकॉल) प्रोटोकॉल के आधार पर बाहरी सेवाओं का उपयोग करके क्लाइंट प्रमाणपत्रों को सत्यापित करने की क्षमता जोड़ी गई। चेक को सक्षम करने के लिए, ssl_ocsp निर्देश प्रस्तावित है, कैश आकार को कॉन्फ़िगर करने के लिए - ssl_ocsp_cache, प्रमाणपत्र में निर्दिष्ट OCSP हैंडलर के URL को फिर से परिभाषित करने के लिए - ssl_ocsp_responder।
• ngx_stream_set_module मॉड्यूल शामिल है, जो आपको वेरिएबल सर्वर के लिए एक मान निर्दिष्ट करने की अनुमति देता है { सुनें 12345; $true 1 सेट करें; }
• प्रॉक्सी कनेक्शन में कुकीज़ के लिए झंडे निर्दिष्ट करने के लिए proxy_cookie_flags निर्देश जोड़ा गया। उदाहरण के लिए, कुकी "एक" में "httponly" ध्वज, और अन्य सभी कुकीज़ के लिए "nosecure" और "samesite=strict" ध्वज जोड़ने के लिए, आप निम्नलिखित निर्माण का उपयोग कर सकते हैं: proxy_cookie_flags एक httponly; प्रॉक्सी_कुकी_फ्लैग ~ नोजक्योर सेमसाइट=सख्त;

  कुकीज़ में झंडे जोड़ने के लिए एक समान userid_flags निर्देश ngx_http_userid मॉड्यूल के लिए भी लागू किया गया है।

• निर्देश "ssl_conf_command", "proxy_ssl_conf_command", "grpc_ssl_conf_command" और "uwsgi_ssl_conf_command" जोड़े गए, जिनके साथ आप OpenSSL को कॉन्फ़िगर करने के लिए मनमाना पैरामीटर सेट कर सकते हैं। उदाहरण के लिए, चाचा सिफर और TLSv1.3 सिफर के उन्नत कॉन्फ़िगरेशन को प्राथमिकता देने के लिए, आप ssl_conf_command विकल्प प्राथमिकताChaCha निर्दिष्ट कर सकते हैं; ssl_conf_command सिफरसुइट्स TLS_CHACHA20_POLY1305_SHA256;
• "ssl_reject_handshake" निर्देश जोड़ा गया, जो SSL कनेक्शन पर बातचीत करने के सभी प्रयासों को अस्वीकार करने का निर्देश देता है (उदाहरण के लिए, SNI फ़ील्ड में अज्ञात होस्टनाम के साथ सभी कॉल को अस्वीकार करने के लिए उपयोग किया जा सकता है)। सर्वर {443 एसएसएल सुनें; ssl_reject_handshake चालू; } सर्वर {443 एसएसएल सुनें; सर्वर_नाम 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 वैरिएबल जोड़ा गया, जिसके माध्यम से आप मिलीसेकंड सटीकता के साथ सेकंड में कनेक्शन अवधि के बारे में जानकारी प्राप्त कर सकते हैं।
• "proxy_cache_path", "fastcgi_cache_path", "scgi_cache_path" और "uwsgi_cache_path" निर्देशों में एक "min_free" पैरामीटर जोड़ा गया है, जो मुक्त डिस्क स्थान के न्यूनतम आकार को निर्धारित करने के आधार पर कैश आकार को नियंत्रित करता है।
• HTTP/2 के साथ काम करने के लिए "lingering_close", "lingered_time" और "lingring_timeout" निर्देशों को अनुकूलित किया गया है।
• 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" का उपयोग किया जाना चाहिए।
• एक नया कमांड लाइन विकल्प "-ई" जोड़ा गया, जो आपको त्रुटि लॉग लिखने के लिए एक वैकल्पिक फ़ाइल निर्दिष्ट करने की अनुमति देता है, जिसका उपयोग सेटिंग्स में निर्दिष्ट लॉग के बजाय किया जाएगा। फ़ाइल नाम के बजाय, आप विशेष मान stderr निर्दिष्ट कर सकते हैं।

स्रोत: opennet.ru