Después de un año de desarrollo, se presenta una nueva rama estable del servidor HTTP de alto rendimiento y proxy multiprotocolo nginx 1.20.0, que incorpora los cambios acumulados en la rama principal 1.19.x. En adelante, todos los cambios en la rama estable 1.20 estarán relacionados con la corrección de errores graves y vulnerabilidades. En breve, se formará la rama principal nginx 1.21, en la que se continuará el desarrollo de nuevas funcionalidades. Se recomienda a los usuarios comunes, que no tienen la tarea de garantizar la compatibilidad con módulos externos, utilizar la rama principal, sobre la cual se generan lanzamientos del producto comercial Nginx Plus cada tres meses.
Según el informe de marzo de la empresa Netcraft, nginx se utiliza en el 20.15% de todos los sitios activos (hace un año 19.56%, hace dos años 20.73%), lo que lo convierte en el segundo más popular en esta categoría (la cuota de Apache es del 25.38% (hace un año 27.64%), Google — 10.09%, Cloudflare — 8.51%. Al considerar todos los sitios, nginx mantiene el liderazgo y ocupa el 35.34% del mercado (hace un año 36.91%, hace dos años — 27.52%), mientras que la cuota de Apache es del 25.98%, OpenResty (plataforma basada en nginx y LuaJIT) — 6.55%, Microsoft IIS — 5.96%.
Entre los millones de sitios más visitados en el mundo, la cuota de nginx es del 25.55% (hace un año 25.54%, hace dos años 26.22%). Actualmente, alrededor de 419 millones de sitios están bajo la gestión de nginx (hace un año 459 millones). Según W3Techs, nginx se utiliza en el 33.7% de los sitios de un millón de los más visitados, en abril del año pasado esta cifra era del 31.9%, y hace dos años — 41.8% (la caída se explica por el cambio a un conteo separado del servidor http de Cloudflare). La cuota de Apache disminuyó en un año del 39.5% al 34%, y la de Microsoft IIS del 8.3% al 7%. La cuota de LiteSpeed aumentó del 6.3% al 8.4%, y 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 destacadas añadidas en el proceso de creación de la rama principal 1.19.x:
- Se ha añadido la capacidad de verificar certificados de cliente a través de servicios externos basados en el protocolo OCSP (Online Certificate Status Protocol). Para activar la verificación, se ha propuesto la directiva ssl_ocsp, para configurar el tamaño de la caché — ssl_ocsp_cache, y para sobreescribir la URL del manipulador OCSP indicada en el certificado — ssl_ocsp_responder.
- Se incluye el módulo ngx_stream_set_module, que permite asignar un valor a una variable server { listen 12345; set $true 1; }
- Se ha añadido la directiva proxy_cookie_flags para especificar las banderas de las Cookies en conexiones proxy. Por ejemplo, para agregar la bandera «httponly» a la Cookie «one», y las banderas «nosecure» y «samesite=strict» a todas las demás Cookies, se puede utilizar la siguiente construcción: proxy_cookie_flags one httponly; proxy_cookie_flags ~ nosecure samesite=strict;
Una directiva similar, userid_flags, para agregar banderas a las Cookies también se ha implementado para el módulo ngx_http_userid.
- Se han añadido las directivas «ssl_conf_command», «proxy_ssl_conf_command», «grpc_ssl_conf_command» y «uwsgi_ssl_conf_command», mediante las cuales se pueden establecer parámetros arbitrarios para la configuración de OpenSSL. Por ejemplo, para priorizar los cifrados ChaCha y una configuración avanzada de los cifrados TLSv1.3 se puede indicar ssl_conf_command Options PrioritizeChaCha; ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256;
- Se ha añadido la directiva «ssl_reject_handshake», que ordena rechazar todos los intentos de negociación SSL-conexiones (por ejemplo, se puede utilizar para rechazar todas las solicitudes con nombres de host desconocidos en el campo SNI). server { listen 443 ssl; ssl_reject_handshake on; } server { listen 443 ssl; server_name example.com; ssl_certificate example.com.crt; ssl_certificate_key example.com.key; }
- Se ha añadido la directiva proxy_smtp_auth al proxy de correo, que permite autenticar al usuario en el backend usando el comando AUTH y el mecanismo PLAIN SASL.
- Se ha añadido la directiva «keepalive_time», que limita el tiempo total de vida de cada conexión keep-alive, tras el cual la conexión se cerrará (no confundir con keepalive_timeout, que determina el tiempo de inactividad, tras el cual se cierra la conexión keep-alive).
- Se ha añadido la variable $connection_time, a través de la cual se puede obtener información sobre la duración de la conexión en segundos con precisión de milisegundos.
- En las directivas «proxy_cache_path», «fastcgi_cache_path», «scgi_cache_path» y «uwsgi_cache_path» se ha añadido el parámetro «min_free», que regula el tamaño de la caché en función de la definición del tamaño mínimo del espacio libre en disco.
- Las directivas «lingering_close», «lingering_time» y «lingering_timeout» se han adaptado para trabajar con HTTP/2.
- El código de manejo de conexiones en HTTP/2 se ha acercado a la implementación de HTTP/1.x. El soporte para configuraciones individuales «http2_recv_timeout», «http2_idle_timeout» y «http2_max_requests» ha sido descontinuado en favor de las directivas generales «keepalive_timeout» y «keepalive_requests». Se han eliminado las configuraciones «http2_max_field_size» y «http2_max_header_size», en su lugar se deben utilizar «large_client_header_buffers».
- Se ha añadido una nueva opción de línea de comando «-e», que permite especificar un archivo alternativo para registrar errores, que se utilizará en lugar del registro definido en la configuración. En lugar del nombre del archivo, se puede especificar el valor especial stderr.
Fuente: opennet.ru
