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%) 'ਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਜੋ ਕਿ ਇਸ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਪ੍ਰਸਿੱਧੀ ਵਿੱਚ ਦੂਜੇ ਸਥਾਨ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ (ਅਪਾਚੇ ਦਾ ਸ਼ੇਅਰ 25.38% ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। (ਇੱਕ ਸਾਲ ਪਹਿਲਾਂ 27.64%), ਗੂਗਲ - 10.09%, Cloudflare - 8.51%। ਉਸੇ ਸਮੇਂ, ਸਾਰੀਆਂ ਸਾਈਟਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰਦੇ ਸਮੇਂ, nginx ਨੇ ਆਪਣੀ ਲੀਡਰਸ਼ਿਪ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਿਆ ਅਤੇ 35.34% ਮਾਰਕੀਟ 'ਤੇ ਕਬਜ਼ਾ ਕੀਤਾ (ਇੱਕ ਸਾਲ ਪਹਿਲਾਂ 36.91%, ਦੋ ਸਾਲ ਪਹਿਲਾਂ - 27.52%), ਜਦੋਂ ਕਿ ਅਪਾਚੇ ਦਾ ਸ਼ੇਅਰ 25.98%, ਓਪਨਰੇਸਟੀ (ਐਨਜੀਨੈਕਸ ਅਤੇ ਲੁਆਜਿਟ 'ਤੇ ਅਧਾਰਤ ਪਲੇਟਫਾਰਮ) - 6.55%, ਮਾਈਕ੍ਰੋਸਾੱਫਟ ਆਈਆਈਐਸ - 5.96% ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।

ਦੁਨੀਆ ਵਿੱਚ ਮਿਲੀਅਨ ਸਭ ਤੋਂ ਵੱਧ ਵੇਖੀਆਂ ਗਈਆਂ ਸਾਈਟਾਂ ਵਿੱਚੋਂ, ਐਨਜੀਨੈਕਸ ਦਾ ਹਿੱਸਾ 25.55% ਹੈ (ਇੱਕ ਸਾਲ ਪਹਿਲਾਂ 25.54%, ਦੋ ਸਾਲ ਪਹਿਲਾਂ 26.22%)। ਵਰਤਮਾਨ ਵਿੱਚ, ਲਗਭਗ 419 ਮਿਲੀਅਨ ਵੈਬਸਾਈਟਾਂ Nginx (459 ਮਿਲੀਅਨ ਇੱਕ ਸਾਲ ਪਹਿਲਾਂ) ਚਲਾ ਰਹੀਆਂ ਹਨ। W3Techs ਦੇ ਅਨੁਸਾਰ, nginx ਦੀ ਵਰਤੋਂ ਮਿਲੀਅਨ ਸਭ ਤੋਂ ਵੱਧ ਵੇਖੀਆਂ ਗਈਆਂ ਸਾਈਟਾਂ ਵਿੱਚੋਂ 33.7% ਸਾਈਟਾਂ 'ਤੇ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਪਿਛਲੇ ਸਾਲ ਅਪ੍ਰੈਲ ਵਿੱਚ ਇਹ ਅੰਕੜਾ 31.9% ਸੀ, ਇੱਕ ਸਾਲ ਪਹਿਲਾਂ - 41.8% (ਗਟਾਵੇ ਨੂੰ ਕਲਾਉਡਫਲੇਅਰ http ਦੇ ਵੱਖਰੇ ਲੇਖਾਕਾਰੀ ਵਿੱਚ ਤਬਦੀਲੀ ਦੁਆਰਾ ਸਮਝਾਇਆ ਗਿਆ ਹੈ। ਸਰਵਰ). ਅਪਾਚੇ ਦਾ ਸ਼ੇਅਰ ਸਾਲ ਭਰ ਵਿੱਚ 39.5% ਤੋਂ 34% ਤੱਕ ਡਿੱਗ ਗਿਆ, ਅਤੇ Microsoft IIS ਦਾ ਸ਼ੇਅਰ 8.3% ਤੋਂ 7% ਹੋ ਗਿਆ। LiteSpeed ​​ਦਾ ਸ਼ੇਅਰ 6.3% ਤੋਂ 8.4% ਤੱਕ ਵਧਿਆ, ਅਤੇ Node.js 0.8% ਤੋਂ 1.2% ਹੋ ਗਿਆ। ਰੂਸ ਵਿੱਚ, ਐਨਜੀਨੈਕਸ ਦੀ ਵਰਤੋਂ 79.1% ਸਭ ਤੋਂ ਵੱਧ ਵੇਖੀਆਂ ਗਈਆਂ ਸਾਈਟਾਂ (ਇੱਕ ਸਾਲ ਪਹਿਲਾਂ - 78.9%) 'ਤੇ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

1.19.x ਅਪਸਟ੍ਰੀਮ ਸ਼ਾਖਾ ਦੇ ਵਿਕਾਸ ਦੌਰਾਨ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਸੁਧਾਰ:

• OCSP (Online Certificate Status Protocol) ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਆਧਾਰ 'ਤੇ ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਦੀ ਯੋਗਤਾ ਸ਼ਾਮਲ ਕੀਤੀ ਗਈ ਹੈ। ਜਾਂਚ ਨੂੰ ਯੋਗ ਕਰਨ ਲਈ, ssl_ocsp ਨਿਰਦੇਸ਼ਕ ਪ੍ਰਸਤਾਵਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਕੈਸ਼ ਆਕਾਰ ਨੂੰ ਸੰਰਚਿਤ ਕਰਨ ਲਈ - ssl_ocsp_cache, ਸਰਟੀਫਿਕੇਟ ਵਿੱਚ ਦਰਸਾਏ OCSP ਹੈਂਡਲਰ ਦੇ URL ਨੂੰ ਮੁੜ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਲਈ - ssl_ocsp_responder।
• ngx_stream_set_module ਮੋਡੀਊਲ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ, ਜੋ ਤੁਹਾਨੂੰ ਵੇਰੀਏਬਲ ਸਰਵਰ ਨੂੰ ਇੱਕ ਮੁੱਲ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ { listen 12345; $true 1 ਸੈੱਟ ਕਰੋ; }
• ਪ੍ਰੌਕਸੀਡ ਕੁਨੈਕਸ਼ਨਾਂ ਵਿੱਚ ਕੂਕੀਜ਼ ਲਈ ਫਲੈਗ ਨਿਸ਼ਚਿਤ ਕਰਨ ਲਈ ਪ੍ਰੌਕਸੀ_ਕੂਕੀ_ਫਲੈਗਸ ਡਾਇਰੈਕਟਿਵ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ। ਉਦਾਹਰਨ ਲਈ, ਕੂਕੀ “ਇੱਕ” ਵਿੱਚ “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 ਵਿਕਲਪ PrioritizeChaCha ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰ ਸਕਦੇ ਹੋ; ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256;
• "ssl_reject_handshake" ਡਾਇਰੈਕਟਿਵ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ, ਜੋ SSL ਕਨੈਕਸ਼ਨਾਂ ਲਈ ਗੱਲਬਾਤ ਕਰਨ ਦੀਆਂ ਸਾਰੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰਨ ਦਾ ਨਿਰਦੇਸ਼ ਦਿੰਦਾ ਹੈ (ਉਦਾਹਰਣ ਵਜੋਂ, SNI ਖੇਤਰ ਵਿੱਚ ਅਣਜਾਣ ਹੋਸਟਨਾਮਾਂ ਵਾਲੀਆਂ ਸਾਰੀਆਂ ਕਾਲਾਂ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ)। ਸਰਵਰ { ਸੁਣੋ 443 ssl; ssl_reject_handshake ਚਾਲੂ; } ਸਰਵਰ { ਸੁਣੋ 443 ssl; server_name example.com; ssl_certificate example.com.crt; ssl_certificate_key example.com.key; }
• proxy_smtp_auth ਡਾਇਰੈਕਟਿਵ ਨੂੰ ਮੇਲ ਪ੍ਰੌਕਸੀ ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ ਹੈ, ਜਿਸ ਨਾਲ ਤੁਸੀਂ AUTH ਕਮਾਂਡ ਅਤੇ PLAIN SASL ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬੈਕਐਂਡ 'ਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰ ਸਕਦੇ ਹੋ।
• "keepalive_time" ਡਾਇਰੈਕਟਿਵ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ, ਜੋ ਕਿ ਹਰ ਇੱਕ-ਜ਼ਿੰਦਾ ਕੁਨੈਕਸ਼ਨ ਦੇ ਕੁੱਲ ਜੀਵਨ ਕਾਲ ਨੂੰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਕਨੈਕਸ਼ਨ ਬੰਦ ਹੋ ਜਾਵੇਗਾ (ਕੀਪਲਾਈਵ_ਟਾਈਮਆਉਟ ਨਾਲ ਉਲਝਣ ਵਿੱਚ ਨਹੀਂ, ਜੋ ਕਿ ਅਕਿਰਿਆਸ਼ੀਲਤਾ ਸਮੇਂ ਨੂੰ ਪਰਿਭਾਸ਼ਤ ਕਰਦਾ ਹੈ ਜਿਸ ਤੋਂ ਬਾਅਦ ਜ਼ਿੰਦਾ ਕੁਨੈਕਸ਼ਨ ਬੰਦ ਹੁੰਦਾ ਹੈ)।
• ਜੋੜਿਆ ਗਿਆ $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