Después de un año de desarrollo, se ha introducido una nueva rama estable del servidor HTTP de alto rendimiento y servidor proxy multiprotocolo nginx 1.20.0, que incorpora los cambios acumulados en la rama principal 1.19.x. En el futuro, todos los cambios en la rama estable 1.20 estarán relacionados con la eliminación de errores y vulnerabilidades graves. Pronto se formará la rama principal de nginx 1.21, en la que continuará el desarrollo de nuevas funciones. Para los usuarios normales que no tienen la tarea de garantizar la compatibilidad con módulos de terceros, se recomienda utilizar la rama principal, a partir de la cual se forman los lanzamientos del producto comercial Nginx Plus cada tres meses.
Según un informe de Netcraft de marzo, nginx se utiliza en el 20.15% de todos los sitios activos (hace un año el 19.56%, hace dos años el 20.73%), lo que corresponde al segundo lugar en popularidad en esta categoría (la cuota de Apache corresponde al 25.38% (hace un año 27.64%), Google - 10.09%, Cloudflare - 8.51%. Al mismo tiempo, considerando todos los sitios, nginx conserva su liderazgo y ocupa el 35.34% del mercado (hace un año 36.91%, hace dos años - 27.52%), mientras que la participación de Apache corresponde al 25.98%, OpenResty (plataforma basada en nginx y LuaJIT) - 6.55%, Microsoft IIS - 5.96%.
Entre el millón de sitios más visitados del mundo, la participación de nginx es del 25.55% (hace un año el 25.54%, hace dos años el 26.22%). Actualmente, alrededor de 419 millones de sitios web ejecutan Nginx (459 millones hace un año). Según W3Techs, nginx se utiliza en el 33.7% de los sitios entre el millón de más visitados, en abril del año pasado esta cifra era del 31.9%, el año anterior, del 41.8% (la disminución se explica por la transición a la contabilidad separada de Cloudflare http servidor). La participación de Apache cayó durante el año del 39.5% al 34%, y la participación de Microsoft IIS del 8.3% al 7%. La participación de LiteSpeed aumentó del 6.3% al 8.4% y la de Node.js del 0.8% al 1.2%. En Rusia, nginx se utiliza en el 79.1% de los sitios más visitados (hace un año, 78.9%).
Las mejoras más notables agregadas durante el desarrollo de la rama ascendente 1.19.x:
- Se agregó la capacidad de verificar los certificados de los clientes utilizando servicios externos basados en el protocolo OCSP (Protocolo de estado de certificados en línea). Para habilitar la verificación, se propone la directiva ssl_ocsp, para configurar el tamaño de la caché - ssl_ocsp_cache, para redefinir la URL del controlador OCSP especificado en el certificado - ssl_ocsp_responder.
- Se incluye el módulo ngx_stream_set_module, que permite asignar un valor a la variable server { listening 12345; establecer $verdadero 1; }
- Se agregó la directiva proxy_cookie_flags para especificar indicadores para cookies en conexiones proxy. Por ejemplo, para agregar el indicador “httponly” a la Cookie “one” y los indicadores “nosecure” y “samesite=strict” para todas las demás Cookies, puede utilizar la siguiente construcción: proxy_cookie_flags one httponly; proxy_cookie_flags ~ nosecure mismo sitio = estricto;
También se implementa una directiva userid_flags similar para agregar indicadores a las cookies para el módulo ngx_http_userid.
- Se agregaron directivas “ssl_conf_command”, “proxy_ssl_conf_command”, “grpc_ssl_conf_command” y “uwsgi_ssl_conf_command”, con las que puede establecer parámetros arbitrarios para configurar OpenSSL. Por ejemplo, para priorizar los cifrados ChaCha y la configuración avanzada de los cifrados TLSv1.3, puede especificar ssl_conf_command Opciones PrioritizeChaCha; ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256;
- Se agregó la directiva "ssl_reject_handshake", que indica rechazar todos los intentos de negociar conexiones SSL (por ejemplo, se puede usar para rechazar todas las llamadas con nombres de host desconocidos en el campo SNI). servidor { escuchar 443 ssl; ssl_reject_handshake activado; } servidor { escuchar 443 ssl; nombre_servidor ejemplo.com; ssl_certificate ejemplo.com.crt; ssl_certificate_key ejemplo.com.key; }
- La directiva proxy_smtp_auth se agregó al proxy de correo, lo que le permite autenticar al usuario en el servidor mediante el comando AUTH y el mecanismo PLAIN SASL.
- Se agregó la directiva "keepalive_time", que limita la vida útil total de cada conexión keep-alive, después de la cual la conexión se cerrará (no debe confundirse con keepalive_timeout, que define el tiempo de inactividad después del cual se cierra la conexión keep-alive).
- Se agregó la variable $connection_time, a través de la cual puede obtener información sobre la duración de la conexión en segundos con precisión de milisegundos.
- Se ha agregado un parámetro "min_free" a las directivas "proxy_cache_path", "fastcgi_cache_path", "scgi_cache_path" y "uwsgi_cache_path", que regula el tamaño de la caché basándose en la determinación del tamaño mínimo de espacio libre en el disco.
- Las directivas "lingering_close", "lingering_time" y "lingering_timeout" se han adaptado para funcionar con HTTP/2.
- El código de procesamiento de conexión en HTTP/2 está cerca de la implementación de HTTP/1.x. Se ha eliminado el soporte para las configuraciones individuales "http2_recv_timeout", "http2_idle_timeout" y "http2_max_requests" en favor de las directivas generales "keepalive_timeout" y "keepalive_requests". Las configuraciones "http2_max_field_size" y "http2_max_header_size" se han eliminado y en su lugar se debe utilizar "large_client_header_buffers".
- Se agregó una nueva opción de línea de comando "-e", que le permite especificar un archivo alternativo para escribir el registro de errores, que se utilizará en lugar del registro especificado en la configuración. En lugar del nombre del archivo, puede especificar el valor especial stderr.
Fuente: opennet.ru