Despois dun ano de desenvolvemento, presentouse unha nova rama estable do servidor HTTP de alto rendemento e do servidor proxy multiprotocolo nginx 1.20.0, que incorpora os cambios acumulados na rama principal 1.19.x. No futuro, todos os cambios na rama estable 1.20 estarán relacionados coa eliminación de erros graves e vulnerabilidades. En breve formarase a rama principal de nginx 1.21, na que continuará o desenvolvemento de novas funcións. Para os usuarios comúns que non teñen a tarefa de garantir a compatibilidade con módulos de terceiros, recoméndase utilizar a rama principal, en base á cal se forman lanzamentos do produto comercial Nginx Plus cada tres meses.
Segundo un informe de marzo de Netcraft, nginx úsase no 20.15% de todos os sitios activos (hai un ano o 19.56%, hai dous anos o 20.73%), o que corresponde ao segundo lugar en popularidade nesta categoría (a cota de Apache corresponde ao 25.38%). (hai un ano 27.64%), Google - 10.09%, Cloudflare - 8.51%. Ao mesmo tempo, ao considerar todos os sitios, nginx mantén o seu liderado e ocupa o 35.34% do mercado (hai un ano o 36.91%, hai dous anos -). 27.52%), mentres que a participación de Apache corresponde ao 25.98%, OpenResty (plataforma baseada en nginx e LuaJIT.) - 6.55%, Microsoft IIS - 5.96%.
Entre os millóns de sitios máis visitados do mundo, a cota de nginx é do 25.55% (hai un ano o 25.54%, hai dous anos o 26.22%). Actualmente, preto de 419 millóns de sitios web están executando Nginx (459 millóns hai un ano). Segundo W3Techs, nginx úsase no 33.7% dos sitios do millón máis visitados, en abril do ano pasado esta cifra foi do 31.9%, o ano anterior - 41.8% (o descenso explícase pola transición á contabilidade separada do http de Cloudflare). servidor). A cota de Apache caeu ao longo do ano do 39.5% ao 34% e a de Microsoft IIS do 8.3% ao 7%. A cota de LiteSpeed creceu do 6.3% ao 8.4% e Node.js do 0.8% ao 1.2%. En Rusia, nginx úsase no 79.1% dos sitios máis visitados (hai un ano - 78.9%).
As melloras máis notables engadidas durante o desenvolvemento da rama anterior 1.19.x:
- Engadida a posibilidade de verificar os certificados de clientes mediante servizos externos baseados no protocolo OCSP (Online Certificate Status Protocol). Para activar a comprobación, proponse a directiva ssl_ocsp, para configurar o tamaño da caché - ssl_ocsp_cache, para redefinir o URL do manejador OCSP especificado no certificado - ssl_ocsp_responder.
- Inclúese o módulo ngx_stream_set_module, que lle permite asignar un valor á variable servidor { listen 12345; establecer $true 1; }
- Engadiuse a directiva proxy_cookie_flags para especificar marcas para as cookies nas conexións proxy. Por exemplo, para engadir a marca "httponly" á cookie "one" e as marcas "nosecure" e "samesite=strict" para todas as demais cookies, pode usar a seguinte construción: proxy_cookie_flags one httponly; proxy_cookie_flags ~ nosecure samesite=estricto;
Tamén se implementa unha directiva userid_flags similar para engadir marcas ás cookies para o módulo ngx_http_userid.
- Engadíronse as directivas “ssl_conf_command”, “proxy_ssl_conf_command”, “grpc_ssl_conf_command” e “uwsgi_ssl_conf_command”, coas que pode establecer parámetros arbitrarios para configurar OpenSSL. Por exemplo, para priorizar os cifrados ChaCha e a configuración avanzada dos cifrados TLSv1.3, pode especificar ssl_conf_command Opcións PrioritizeChaCha; ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256;
- Engadiuse a directiva "ssl_reject_handshake", que indica que se rexeitan todos os intentos de negociar conexións SSL (por exemplo, pódese usar para rexeitar todas as chamadas con nomes de host descoñecidos no campo SNI). servidor { listen 443 ssl; ssl_reject_handshake activado; } servidor { escoitar 443 ssl; nome_servidor exemplo.com; ssl_certificate example.com.crt; ssl_certificate_key example.com.key; }
- A directiva proxy_smtp_auth engadiuse ao proxy de correo, o que lle permite autenticar o usuario no backend mediante o comando AUTH e o mecanismo PLAIN SASL.
- Engadiuse a directiva "keepalive_time", que limita o tempo de vida total de cada conexión Keep-Alive, despois de que a conexión se pechará (non debe confundirse con keepalive_timeout, que define o tempo de inactividade despois do cal se pecha a conexión Keep-Alive).
- Engadiuse a variable $connection_time, a través da cal pode obter información sobre a duración da conexión en segundos cunha precisión de milisegundos.
- Engadiuse un parámetro "min_free" ás directivas "proxy_cache_path", "fastcgi_cache_path", "scgi_cache_path" e "uwsgi_cache_path", que regula o tamaño da caché en función da determinación do tamaño mínimo de espazo libre en disco.
- As directivas "lingering_close", "lingering_time" e "lingering_timeout" adaptáronse para funcionar con HTTP/2.
- O código de procesamento de conexión en HTTP/2 está próximo á implementación HTTP/1.x. O soporte para as configuracións individuais "http2_recv_timeout", "http2_idle_timeout" e "http2_max_requests" interrompeuse en favor das directivas xerais "keepalive_timeout" e "keepalive_requests". Elimináronse os axustes "http2_max_field_size" e "http2_max_header_size" e no seu lugar deberían utilizarse "large_client_header_buffers".
- Engadiuse unha nova opción de liña de comandos "-e", que lle permite especificar un ficheiro alternativo para escribir o rexistro de erros, que se utilizará en lugar do rexistro especificado na configuración. En lugar do nome do ficheiro, pode especificar o valor especial stderr.
Fonte: opennet.ru