Presentamos NGINX 1.18 y 1.19

Hoy lanzamos NGINX 1.19, la última versión de NGINX Open Source, el servidor web más popular en Internet . Este lanzamiento marca el lanzamiento de la rama de desarrollo NGINX 1.19, luego del lanzamiento de la rama estable NGINX 1.18 el mes pasado.

En este blog analizamos el esquema de versiones de NGINX, repasamos lo que sucedió durante el ciclo de desarrollo de NGINX 1.17 y esperamos lo que nos depara el futuro con NGINX 1.19.

Explicación del control de versiones de NGINX

En NGINX, mantenemos dos ramas en el repositorio de código fuente abierto NGINX, denominadas mainline y stable :

• Mainline es la rama de desarrollo activa donde se agregan las últimas características y correcciones de errores. Se denota mediante un número impar en la segunda parte del número de versión, por ejemplo 1.19.0.
• La versión estable recibe correcciones para errores de alta gravedad, pero no se actualiza con nuevas funciones. Se denota mediante un número par en la segunda parte del número de versión, por ejemplo 1.18.0.

Qué significa ser “estable”

Para NGINX Open Source, la palabra “estable” se refiere a la funcionalidad y frecuencia de actualización, no a la calidad del software. La rama estable nunca recibe nueva funcionalidad durante su ciclo de vida y normalmente recibe solo una o dos actualizaciones para corregir errores críticos.

La rama estable tiene un ciclo de vida anual. Cada abril, retiramos la rama estable actual, después de lo cual no se realizan más correcciones de errores. Esto desencadena dos eventos:

1. La rama principal actual se bifurca para crear la próxima rama estable. La nueva rama estable hereda todas las correcciones de errores, características y otros cambios que se incluyeron en la rama principal durante el año anterior. El mes pasado, NGINX 1.17.10 se bifurcó para producir NGINX 1.18.0. Tenga en cuenta que hasta el lanzamiento de la nueva rama principal, "estable" es idéntico a la rama principal actual y puede incluir características nuevas que tienen solo unos días (ese estado finaliza hoy para la rama NGINX 1.18).
2. La rama principal obtiene un “aumento de versión”; es decir, la segunda parte del número de versión se incrementa al siguiente número impar. El desarrollo continuo continúa en la rama principal, con nuevas versiones creadas a partir de la línea principal cada cuatro a seis semanas. Hoy se lanza el primer lanzamiento de la línea principal NGINX 1.19 con NGINX 1.19.0.

¿Qué rama utiliza NGINX Plus?

NGINX Plus , la versión comercial de NGINX, se mantiene en un repositorio de código privado e independiente. Siempre se basa en la última versión de la línea principal NGINX, fusionada con las características y capacidades propietarias adicionales de NGINX Plus. Al momento de escribir este artículo, la última versión es NGINX Plus R21 , basada en NGINX 1.17.10.

¿Qué sucursal debo utilizar?

Generalmente recomendamos utilizar la rama principal. Aquí es donde incorporamos todas las nuevas características, mejoras de rendimiento y mejoras. Probamos y controlamos la calidad de forma activa de la rama principal y, como fuente de las compilaciones de NGINX Plus, es totalmente adecuada para su uso en producción.

Si le preocupa la sobrecarga que supone supervisar la rama principal en busca de nuevas funciones y correcciones de errores, utilizar la rama estable significa que solo necesitará revisar la nueva funcionalidad una vez al año y las correcciones de errores con poca frecuencia.

NGINX 1.17 en revisión, también conocido como Novedades en la rama estable de NGINX 1.18

El ciclo de desarrollo de NGINX 1.17 introdujo algunas características y mejoras nuevas, incluidas mejoras en la tasa de solicitudes y la limitación de conexión en ngx_http_limit_req_module y ngx_http_limit_conn_module respectivamente, agregando una directiva de retardo de autenticación a ngx_http_core_module , introduciendo soporte de variables para la directiva grpc_pass y variables que capturan la dirección del servidor y el puerto con el protocolo PROXY, y más. Antes de analizar las mejoras más significativas con más detalle, aquí está NGINX 1.17, en números:

• 10 lanzamientos principales
• 37 correcciones de errores
• 11 nuevas funciones

Mejoras en la tasa de solicitudes HTTP y la limitación de conexión

Las directivas limit_rate y limit_rate_after controlan el ancho de banda (velocidad en bytes por segundo) con la que NGINX responde a las solicitudes. En NGINX 1.17.0 y versiones posteriores, el parámetro que establece la tasa puede ser una variable, lo que permite un control dinámico basado en los atributos de la solicitud. Para ver un ejemplo, consulte Control dinámico de ancho de banda .

NGINX 1.17.1 agregó el modo de ejecución en seco para limitar la tasa de solicitudes, con la directiva limit_req_dry_run . En el modo de ejecución en seco, NGINX Plus no aplica límites de velocidad, pero aún rastrea la velocidad de solicitudes excesivas en la zona de memoria compartida y escribe una entrada en el registro de errores para cada solicitud que excede el límite configurado. Esto le permite determinar más fácilmente qué límite de velocidad es apropiado para los patrones de tráfico de su sitio. Para obtener más detalles, consulte Límites de velocidad de prueba en modo de ejecución en seco .

Para que el modo de ejecución en seco sea aún más útil, NGINX 1.17.6 agregó la variable $limit_req_status , que se puede incluir en las entradas del registro de acceso para capturar el efecto de la limitación de velocidad en el procesamiento de solicitudes, específicamente, si una solicitud:

• Aprobado (se envió a los servidores backend sin demora) [ APROBADO ]
• Se retrasó [ RETRASADO ]
• Fue rechazado [ RECHAZADO ]
• Se contabilizó como retrasado en el modo de ejecución en seco [ DELAYED_DRY_RUN ]
• Se contabilizó como rechazado en el modo de ejecución en seco [ REJECTED_DRY_RUN ]

NGINX 1.17.6 también agregó un modo de ejecución en seco para limitar la conexión con la directiva limit_conn_dry_run y la variable $limit_conn_status para capturar cuándo se produce una solicitud de conexión:

• Aprobado (se reenvió a los servidores backend) [ APROBADO ]
• Fue rechazado [ RECHAZADO ]
• Se contabilizó como rechazado en el modo de ejecución en seco [ REJECTED_DRY_RUN ]

Para ver una configuración de ejemplo, consulte Mejoras en la limitación de conexión .

Nueva directiva auth_delay

La directiva auth_delay (agregada en NGINX 1.17.10) permite el procesamiento retrasado de solicitudes no autorizadas, con código de estado 401(No autorizado) devuelto al cliente. Esto evita ataques de tiempo al procesar solicitudes de acceso. Los métodos de autenticación disponibles incluyen:

• Una contraseña (cuando se utiliza ngx_http_auth_basic_module )
• El resultado de una subsolicitud (disponible en ngx_http_auth_request_module )
• La presencia de un JWT (disponible en ngx_http_auth_jwt_module )

Variables compatibles con la directiva grpc_pass

Se agregó soporte nativo para el tráfico gRPC en NGINX 1.13.10, incluida la directiva grpc_pass , que especifica los servidores a los que NGINX pasa solicitudes gRPC. En NGINX 1.17.8 agregamos la capacidad de incluir nombres de dominio en el identificador del servidor, para admitir la búsqueda entre grupos de servidores ascendentes . Si no se encuentra el nombre de dominio, NGINX recurre a un solucionador para identificar las direcciones del servidor.

Variables adicionales del protocolo PROXY

El protocolo PROXY permite que un proxy de capa 4 proporcione información original del cliente al siguiente proxy o balanceador de carga que maneja la solicitud. Esto es importante para los casos de uso en los que necesita conocer la dirección IP del cliente; por ejemplo, para limitar la cantidad de conexiones para cada cliente (usando la directiva less_conn ). Estos datos están disponibles en la variable $proxy_protocol_addr ( HTTP | Stream ).

Cuando se implementan varios servidores proxy de capa 4, puede ser importante que NGINX conozca la dirección IP y el puerto del servidor proxy al que se conectó originalmente el cliente. Los metadatos del protocolo PROXY incluyen esta información, y NGINX 1.17.6 agregó las siguientes variables a los módulos HTTP y Stream para capturarla:

• $proxy_protocol_server_addr ( HTTP | Transmisión )
• $proxy_protocol_server_port ( HTTP | Transmisión )

Nota:  Las variables se completan solo si también incluye el parámetro proxy_protocol en la directiva listen para habilitar el manejo del protocolo PROXY.

Se agregó soporte de variables a las directivas proxy_upload_rate y proxy_download_rate

Las directivas proxy_upload_rate y proxy_download_rate en el módulo Stream controlan la velocidad a la que NGINX lee datos de un cliente o un servidor proxy, respectivamente. En NGINX 1.17.0 y versiones posteriores, las directivas aceptan un parámetro variable, lo que le permite definir tarifas específicas para cada condición.

Se agregó soporte para la llamada del sistema ioctl(FIONREAD)

En los sistemas Linux, la llamada al sistema ioctl() proporciona la cantidad de bytes legibles desde el dispositivo host. NGINX 1.17.5 agregó ioctl(FIONREAD) para evitar bucles cuando se agregan datos al búfer del socket más rápido de lo que NGINX puede leerlos y procesarlos. Cuando el kernel no proporciona la cantidad de bytes disponibles, podemos usar ioctl(FIONREAD) para obtener esta información de un búfer poblado.

Especificación de una ubicación con nombre en la función internal_redirect de Perl

En NGINX 1.17.2 y versiones posteriores, el parámetro uri de la función internal_redirect en el módulo Perl NGINX puede ser un URI escapado o una ubicación con nombre.

Lo que viene en NGINX 1.19

El primer lanzamiento de la línea principal NGINX 1.19 llegará muy pronto. NGINX 1.19.0 incluye soporte para QUIC (HTTP/3), la próxima actualización significativa de los protocolos de transporte para la comunicación entre clientes y sitios web, aplicações y API.

Si desea probar las funciones mejoradas de NGINX Plus, comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .