Después de un año de desarrollo, se ha publicado una nueva rama estable del servidor HTTP de alto rendimiento y proxy multiprotocolo nginx 1.28.0, que ha incorporado los cambios acumulados en la rama principal 1.27.x. En adelante, todos los cambios en la rama estable 1.28 se centrarán en corregir errores graves y vulnerabilidades. Pronto se formará la rama principal nginx 1.29, en la que se continuará el desarrollo de nuevas funcionalidades. Se recomienda a los usuarios comunes, que no tienen la tarea de asegurar la compatibilidad con módulos externos, utilizar la rama principal, a partir de la cual se generan lanzamientos del producto comercial Nginx Plus cada tres meses.
Según el informe de marzo de Netcraft, aproximadamente 245 millones de sitios están bajo 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 lo coloca en la primera posición en popularidad en esta categoría (la cuota de Apache es del 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 el liderazgo con una cuota del 20.48% del mercado (22.31% hace un año, 25.94% hace dos años), mientras que la cuota de Apache es del 16.03% (20.17%, 20.58%), Cloudflare — 12.87% (11.24%, 10.17%), OpenResty (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 cuota del 20.37% (20.63% hace un año, 21.37% hace dos años). El primer lugar lo ocupa Cloudflare — 22.32% (22.59% hace un año, 21.62% hace dos años). La cuota de Apache httpd es del 17.95% (20.09%, 21.18%).
Según W3Techs, nginx se utiliza en el 33.8% de los sitios entre el millón más visitados (en abril del año pasado era del 34.3%, y hace dos años del 34.5%). La cuota de Apache ha disminuido en un año del 30.1% al 26.3%, y la cuota de Microsoft IIS ha bajado del 5% al 4%. La cuota de Node.js ha aumentado del 3.2% al 4.4%, y la cuota de LiteSpeed del 12.9% al 14.6%.
Las mejoras más notables añadidas durante la formación de la rama principal 1.27.x:
- Para conexiones que utilizan el protocolo QUIC, se ha añadido soporte para el algoritmo de control de congestión CUBIC (RFC 9438), cuya operación consiste en aumentar gradualmente el tamaño de la ventana de congestión hasta la aparición de pérdida de paquetes, después de lo cual el tamaño de la ventana se reduce al valor anterior a la pérdida. En las pruebas realizadas, el uso de CUBIC permitió reducir el tiempo de transferencia de un archivo de 500 MB en un 24 % con retrasos de 40 ms y un BDP de 750K (Producto de Retardo de Ancho de Banda) y en un 73 % con retrasos de 100 ms y un BDP de 9M.
- En el módulo stream se ha añadido la compatibilidad con la verificación de revocación de certificados de clientes utilizando el protocolo OCSP (Protocolo de Estado de Certificado en Línea).
- En el módulo stream se ha implementado el soporte para la técnica de verificación de revocación de certificados OCSP Stapling, que consiste en que, al establecer una conexión TLS, la respuesta OCSP validada por la autoridad certificadora es transmitida por el servidor que atiende el sitio, sin necesidad de una consulta directa a la autoridad certificadora.
- Se ha implementado el almacenamiento en caché al iniciar y actualizar la configuración. certificados SSL, claves y CRL (Lista de Revocación de Certificados).
- Se han añadido funcionalidades para reducir el consumo de recursos y disminuir la carga en la CPU al utilizar TLS en configuraciones con un gran número de bloques server y location. Los cambios añadidos permiten usar el contexto SSL existente del bloque principal en lugar de crear un contexto SSL separado (SSL_CTX en OpenSSL) para cada bloque de configuración.
- En la directiva «ssl_client_certificate» se ha añadido soporte para certificados con información adicional.
- Para la verificación de los certificados SSL de clientes, la directiva «ssl_client_certificate» ya no es obligatoria.
- Se agregó soporte para el modo IMAP LOGIN específico de SmarterMail con respuesta CAPABILITY no etiquetada en el módulo ngx_mail_proxy_module.
- Se ha añadido la directiva «proxy_pass_trailers» en el módulo ngx_http_proxy_module, que permite la transmisión de los campos de cabecera al final de la respuesta del servidor proxy al cliente.
- Se agregó soporte para el parámetro «resolve» en la directiva «server» utilizada en el bloque «upstream», lo que permite rastrear los cambios IP en el nombre de dominio utilizado y actualizar automáticamente la configuración del bloque «upstream» sin necesidad de reiniciar nginx en caso de que la dirección cambie.
- Se agregó la posibilidad 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 en la dirección del cliente en el módulo ngx_http_realip_module, se permite especificar direcciones IPv6 entre corchetes sin número de puerto.
- Se ha añadido 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.
- Por defecto, se desactivan los protocolos TLSv1 y TLSv1.1.
- Se resolvieron problemas de carga prolongada de archivos de configuración debido a la reanálisis del mismo conjunto de certificados, claves y listas de autoridades de certificación TLS. Se aceleró la recarga de la configuración gracias a la reutilización de objetos TLS no modificados, como certificados, claves y CRL. Para deshabilitar la herencia de objetos al actualizar la configuración, se agregó la directiva «ssl_object_cache_inheritable».
- Se ha agregado caché para certificados y claves cargados utilizando variables en las directivas (por ejemplo, «ssl_certificate /etc/ssl/$ssl_server_name.crt»). Se han añadido las directivas «ssl_certificate_cache», «proxy_ssl_certificate_cache», «grpc_ssl_certificate_cache» y «uwsgi_ssl_certificate_cache» para gestionar el caché. A través de estas directivas, se puede configurar el tamaño máximo del caché, el tiempo de vida de las entradas y el tiempo de limpieza de entradas no utilizadas. Por ejemplo: «ssl_certificate_cache max=1000 inactive=20s valid=1m;».
- Se redujo el consumo de memoria al procesar solicitudes 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 que se pueden almacenar en caché en la memoria compartida se ha aumentado a 8192.
- Se ha configurado la construcción con la biblioteca C Musl.
- Se ha trabajado en la optimización del rendimiento y en la corrección de errores en la implementación de HTTP/3.
También se puede destacar la publicación de la versión 1.28.0 del proyecto FreeNginx, que desarrolla un fork de Nginx. El desarrollo del fork está dirigido por Maxim Dunin, uno de los desarrolladores clave de Nginx. FreeNginx se posiciona como un proyecto no comercial que proporciona el desarrollo de la base de código de Nginx sin intervención corporativa. Entre los cambios específicos en la rama FreeNginx 1.28 están:
- El parámetro «off» en la directiva «pid», que desactiva la creación del archivo PID.
- Limitación de la intensidad de escritura de mensajes en el registro de errores para proteger contra el llenado del registro con mensajes repetitivos.
- Implementación del parámetro multipath en la directiva listen para soportar Multipath TCP.
- Soporte para el encabezado HTTP «Age» para determinar la vida útil de las entradas en la caché.
- Adición de los métodos de autenticación XOAUTH2 y OAUTHBEARER en el módulo mail_proxy.
Fuente: opennet.ru
