Tras un año de desarrollo, se ha publicado una nueva rama estable del servidor HTTP de alto rendimiento y servidor proxy multiprotocolo nginx 1.28.0, que incorpora los cambios acumulados en la rama principal 1.27.x. En el futuro, todos los cambios en la rama estable 1.28 estarán relacionados con la eliminación de errores y vulnerabilidades graves. Pronto se formará la rama principal de nginx 1.29, 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 el informe de marzo de Netcraft, alrededor de 245 millones de sitios funcionan con nginx (243 millones hace un año, 289 millones hace dos años). Nginx se utiliza en el 17.89% de todos los sitios activos (18.15% hace un año, 18.94% hace dos años), lo que corresponde al primer lugar en popularidad en esta categoría (la participación de Apache corresponde al 16.03% (20.09% hace un año, 20.52% hace dos años), Cloudflare - 17.81% (14.12%, 11.32%), Google - 9.89% (10.41%, 9.89%).
Al considerar todos los sitios, nginx mantiene su liderazgo y ocupa el 20.48% del mercado (hace un año 22.31%, hace dos años - 25.94%), mientras que la participación de Apache es del 16.03% (20.17%, 20.58%), Cloudflare - 12.87% (11.24%, 10.17%), OpenResty (una plataforma basada en nginx y LuaJIT) - 9.36% (7.93%, 7.94%).
Entre el millón de sitios más visitados del mundo, nginx ocupa el segundo lugar con una participación del 20.37% (hace un año 20.63%, hace dos años 21.37%). Cloudflare ocupa el primer lugar con un 22.32% (22.59% hace un año, 21.62% hace dos años). La cuota de mercado de Apache httpd es del 17.95% (20.09%, 21.18%).
Según W3Techs, nginx se utiliza en el 33.8% del millón de sitios más visitados (en abril del año pasado esta cifra fue del 34.3%, el año anterior, del 34.5%). La participación de Apache cayó del 30.1% al 26.3% durante el año, mientras que la participación de Microsoft IIS cayó del 5% al 4%. La participación de Node.js aumentó del 3.2% al 4.4% y la participación de LiteSpeed del 12.9% al 14.6%.
Las mejoras más notables agregadas durante el desarrollo de la rama ascendente 1.27.x:
- Para las conexiones que utilizan el protocolo QUIC, se ha agregado soporte para el algoritmo de control de congestión de red CUBIC (RFC 9438), que funciona aumentando gradualmente el tamaño de la ventana de congestión hasta que se produce una pérdida de paquetes, después de lo cual el tamaño de la ventana se revierte al valor anterior al inicio de la pérdida. En las pruebas realizadas, el uso de CUBIC permitió reducir el tiempo de transferencia de un archivo de 500MB en un 24% con retrasos de 40ms y BDP 750K (Bandwidth Delay Product) y en un 73% con retrasos de 100ms y BDP 9M.
- El módulo de transmisión ha agregado soporte para verificar la revocación de certificados de clientes utilizando el OCSP (Protocolo de estado de certificados en línea).
- El módulo de flujo implementa soporte para la técnica de verificación de revocación de certificados OCSP Stapling, cuya esencia es que al negociar una conexión TLS, el servidor que atiende al sitio transmite una respuesta OCSP certificada por la autoridad de certificación, sin la necesidad de contactar directamente al autoridad de certificación).
- Al iniciar y actualizar la configuración, se implementa el almacenamiento en caché de certificados SSL, claves y CRL (Lista de revocación de certificados).
- Se agregaron capacidades para reducir el consumo de recursos y la carga de la CPU al usar TLS en configuraciones con una gran cantidad de bloques de servidores y ubicaciones. Los cambios agregados permiten, en lugar de crear un contexto SSL separado (SSL_CTX en OpenSSL) para cada bloque de configuración, utilizar el contexto SSL existente del bloque principal.
- La directiva "ssl_client_certificate" brinda soporte para certificados con información adicional.
- Para verificar los certificados SSL del cliente, ya no se requiere la directiva "ssl_client_certificate".
- Se agregó soporte para el modo IMAP LOGIN específico de SmarterMail con respuesta de CAPACIDAD sin etiquetar al módulo ngx_mail_proxy_module.
- La directiva "proxy_pass_trailers" se agregó al módulo ngx_http_proxy_module, lo que permite la transmisión de campos de encabezado al final de la respuesta del servidor proxy al cliente.
- La directiva "servidor" utilizada en el bloque "upstream" ahora incluye soporte para el parámetro "resolve", que incluye el seguimiento de los cambios de dirección IP para el nombre de dominio que se utiliza y la actualización automática de la configuración del bloque "upstream" sin necesidad de reiniciar. nginx si la dirección cambia.
- Se agregó la capacidad de usar variables en las directivas "proxy_limit_rate", "fastcgi_limit_rate", "scgi_limit_rate" y "uwsgi_limit_rate".
- En las directivas "proxy_bind", "fastcgi_bind", "grpc_bind", "memcached_bind", "scgi_bind" y "uwsgi_bind", así como una dirección de cliente en ngx_http_realip_module, se permiten direcciones IPv6 entre corchetes sin número de puerto.
- Se agregó la directiva "keepalive_min_timeout", que define el tiempo de espera durante el cual nginx no cerrará la conexión keep-alive con el cliente.
- De forma predeterminada, los protocolos TLSv1 y TLSv1.1 están deshabilitados.
- Se solucionaron problemas con la carga prolongada de archivos de configuración debido al análisis repetido del mismo conjunto de certificados TLS, claves y listas de autoridades de certificación. Se mejoró el rendimiento de recarga de configuración al reutilizar objetos TLS sin cambios, como certificados, claves y CRL. Para deshabilitar la herencia de objetos al actualizar la configuración, se ha agregado la directiva "ssl_object_cache_inheritable".
- Se agregó caché para certificados y claves cargados usando variables en directivas (por ejemplo, "ssl_certificate /etc/ssl/$ssl_server_name.crt"). Se han agregado las directivas "ssl_certificate_cache", "proxy_ssl_certificate_cache", "grpc_ssl_certificate_cache" y "uwsgi_ssl_certificate_cache" para administrar el caché. Las directivas especificadas le permiten configurar el tamaño máximo de caché, el período de validez de los registros y el tiempo para limpiar los registros no utilizados. Por ejemplo: "ssl_certificate_cache max=1000 inactivo=20s válido=1m;".
- Se reduce el consumo de memoria al procesar consultas de larga duración en configuraciones que utilizan las directivas "gzip", "gunzip", "ssi", "sub_filter" o "grpc_pass".
- El tamaño máximo de las sesiones SSL almacenadas en caché en la memoria compartida se ha aumentado a 8192.
- Se ha constituido el conjunto con la biblioteca Musl C.
- Se ha trabajado para optimizar el rendimiento y eliminar errores en la implementación de HTTP/3.
Además, cabe destacar la publicación del release del proyecto FreeNginx 1.28.0, que desarrolla el fork de Nginx. La bifurcación está siendo desarrollada por Maxim Dunin, uno de los desarrolladores clave de Nginx. FreeNginx se posiciona como un proyecto sin fines de lucro que proporciona el desarrollo de la base de código Nginx sin interferencia corporativa. Entre los cambios específicos en la rama FreeNginx 1.28:
- El parámetro "off" en la directiva "pid" deshabilita la creación de un archivo PID.
- Limitar la intensidad de escritura de mensajes en el registro de errores para evitar que el registro se llene con mensajes típicos.
- Implementación del parámetro multipath en la directiva listen para soportar Multipath TCP.
- Soporte para el encabezado HTTP "Age" para definir la duración de las entradas de caché.
- Agregar métodos de autenticación XOAUTH2 y OAUTHBEARER al módulo mail_proxy.
Fuente: opennet.ru