Hoy lanzamos NGINX 1.19, la última versión de NGINX Open Source, el servidor web más popular de Internet. Esta versión marca el inicio de la rama de desarrollo de NGINX 1.19, tras el lanzamiento el mes pasado de la rama estable de NGINX 1.18.
En este blog analizamos el sistema de versiones de NGINX, repasamos lo ocurrido durante el ciclo de desarrollo de NGINX 1.17 y adelantamos lo que nos depara NGINX 1.19.
Explicación del sistema de versiones de NGINX
En NGINX, mantenemos dos ramas en el repositorio de código de NGINX Open Source, denominadas «mainline» y «stable»:
- Mainline es la rama de desarrollo activa en la que se incorporan las últimas funcionalidades y correcciones de errores. Se identifica mediante un número impar en la segunda parte del número de versión, por ejemplo, 1.19.0.
- Estable recibe correcciones para errores de gravedad alta, pero no se actualiza con nuevas funcionalidades. Se identifica mediante un número par en la segunda parte del número de versión, por ejemplo, 1.18.0.
Qué significa ser «estable»
En NGINX Open Source, la palabra «estable» hace referencia a la funcionalidad y la frecuencia de las actualizaciones, no a la calidad del software. La rama estable nunca recibe nuevas funcionalidades durante su ciclo de vida y, por lo general, solo recibe una o dos actualizaciones para corregir errores críticos.
La rama estable tiene un ciclo de vida anual. Cada mes de abril, retiramos la rama estable vigente, tras lo cual ya no se corrigen más errores. Esto da lugar a dos acontecimientos:
- La rama principal actual se bifurca para crear la siguiente rama estable. La nueva rama estable hereda todas las correcciones de errores, funcionalidades y demás cambios incorporados a la rama principal durante el año anterior. El mes pasado, NGINX 1.17.10 se bifurcó para crear NGINX 1.18.0. Tenga en cuenta que, hasta el lanzamiento de la nueva rama principal, la rama «estable» es idéntica a la rama principal actual y puede incluir funcionalidades nuevas con apenas unos días de antigüedad (esta situación termina hoy para la rama NGINX 1.18).
- La rama principal recibe un «incremento de versión»; es decir, la segunda parte del número de versión se incrementa hasta el siguiente número impar. El desarrollo continúa en la rama principal, con nuevas versiones creadas a partir de ella cada cuatro o seis semanas. Hoy se publica la primera versión de la rama principal NGINX 1.19: 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 versión más reciente de la rama principal de NGINX, combinada con las funciones y capacidades propietarias adicionales de NGINX Plus. En el momento de redactar este texto, la versión más reciente es NGINX Plus R21, basada en NGINX 1.17.10.
¿Qué rama debería usar?
Por lo general, recomendamos utilizar la rama principal. En ella incorporamos todas las funciones nuevas, las mejoras de rendimiento y otras mejoras. Probamos activamente la rama principal y la sometemos a controles de calidad; además, dado que sirve como base para las compilaciones de NGINX Plus, es totalmente apta para su uso en producción.
Si le preocupa el esfuerzo que supone supervisar la rama mainline para detectar nuevas funcionalidades y correcciones de errores, usar la rama stable significa que solo tendrá que revisar las nuevas funcionalidades una vez al año y las correcciones de errores de forma ocasional.
Repaso de NGINX 1.17, también conocido como «Novedades de la rama estable NGINX 1.18»
El ciclo de desarrollo de NGINX 1.17 introdujo nuevas funcionalidades y mejoras, entre ellas, mejoras en la limitación de la tasa de solicitudes y de conexiones en ngx_http_limit_req_module y ngx_http_limit_conn_module, respectivamente; la incorporación de una directiva para retrasar la autenticación en ngx_http_core_module; la compatibilidad con variables en la directiva grpc_pass y variables que capturan la dirección y el puerto del servidor con el protocolo PROXY, entre otras. Antes de analizar con más detalle las mejoras más importantes, veamos NGINX 1.17 en cifras:
- 10 versiones de la rama principal
- 37 correcciones de errores
- 11 funciones nuevas
Mejoras en la limitación de la tasa de solicitudes HTTP y de conexiones
Las directivas limit_rate y limit_rate_after controlan el ancho de banda (velocidad en bytes por segundo) con el que NGINX responde a las solicitudes. En NGINX 1.17.0 y versiones posteriores, el parámetro que establece la velocidad 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 del ancho de banda.
NGINX 1.17.1 incorporó el modo de simulación para limitar la tasa de solicitudes mediante la directiva limit_req_dry_run. En el modo de simulación, NGINX Plus no aplica los límites de tasa, pero sigue registrando la tasa de solicitudes excesivas en la zona de memoria compartida y añade una entrada al registro de errores por cada solicitud que supera el límite configurado. Esto permite determinar más fácilmente qué límite de tasa es adecuado para los patrones de tráfico de su sitio. Para obtener más información, consulte Prueba de los límites de tasa en modo de simulación.
Para que el modo de prueba sea aún más útil, NGINX 1.17.6 añadió la variable $limit_req_status, que puede incluirse en las entradas del registro de acceso para reflejar el efecto de la limitación de la tasa en el procesamiento de las solicitudes; concretamente, si una solicitud:
- Superada (se reenvió a los servidores backend sin demora) [
PASSED] - Se retrasó [
DELAYED] - Fue rechazado [
REJECTED] - Se contabilizó como retrasado en modo de prueba [
DELAYED_DRY_RUN] - Se contabilizó como rechazado en modo de prueba [
REJECTED_DRY_RUN]
NGINX 1.17.6 también añadió el modo de prueba para limitar las conexiones mediante la directiva limit_conn_dry_run, así como la variable $limit_conn_status para registrar cuándo una solicitud de conexión:
- Permitida (se reenvió a los servidores backend) [
PASSED] - Se rechazó [
REJECTED] - Se contabilizó como rechazado en modo de prueba [
REJECTED_DRY_RUN]
Para ver un ejemplo de configuración, consulte Mejoras en la limitación de conexiones.
Nueva directiva «auth_delay»
La directiva auth_delay (añadida en NGINX 1.17.10) permite retrasar el procesamiento de solicitudes no autorizadas y devolver al cliente el código de estado 401 (No autorizado). Esto evita los ataques de temporización al procesar solicitudes de acceso. Entre los métodos de autenticación disponibles se incluyen:
- Una contraseña (al usar 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)
Compatibilidad con variables para la directiva «grpc_pass»
La compatibilidad nativa con el tráfico gRPC se añadió en NGINX 1.13.10, incluida la directiva grpc_pass, que especifica los servidores a los que NGINX envía las solicitudes gRPC. En NGINX 1.17.8 añadimos la posibilidad de incluir nombres de dominio en el identificador del servidor para permitir la búsqueda entre grupos de servidores ascendentes. Si no se encuentra el nombre de dominio, NGINX recurre a un sistema de resolución para identificar las direcciones de los servidores.
Variables adicionales del protocolo PROXY
El protocolo PROXY permite que un proxy de capa 4 proporcione la información original del cliente al siguiente proxy o balanceador de carga que gestione la solicitud. Esto es importante en casos de uso en los que se necesita conocer la dirección IP del cliente, por ejemplo, para limitar el número de conexiones de cada cliente (mediante la directiva least_conn). Estos datos están disponibles en la variable $proxy_protocol_addr (HTTP | Stream).
Cuando se implementan varios proxies 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 añadió las siguientes variables a los módulos HTTP y Stream para capturarla:
Nota: Las variables solo se rellenan si también se incluye el parámetro proxy_protocol en la directiva listen para habilitar la gestión del protocolo PROXY.
Se ha añadido compatibilidad con variables a las directivas proxy_upload_rate y proxy_download_rate Directives
Las directivas proxy_upload_rate y proxy_download_rate del módulo Stream controlan, respectivamente, la velocidad a la que NGINX lee los datos de un cliente o de un servidor proxy. En NGINX 1.17.0 y versiones posteriores, las directivas aceptan una variable como parámetro, lo que permite definir velocidades específicas para cada condición.
Se ha añadido compatibilidad con la llamada al sistema ioctl(FIONREAD) System Call
En los sistemas Linux, la llamada al sistema ioctl() proporciona el número de bytes que se pueden leer del dispositivo host. NGINX 1.17.5 añadió ioctl(FIONREAD) para evitar bucles cuando se añaden datos al búfer del socket más rápido de lo que NGINX puede leerlos y procesarlos. Cuando el kernel no proporciona el número de bytes disponibles, podemos usar ioctl(FIONREAD) para obtener esta información de un búfer con datos.
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 del módulo Perl de NGINX puede ser un URI con caracteres de escape o una ubicación con nombre.
Novedades de NGINX 1.19
La primera versión de la rama principal de NGINX 1.19 llegará muy pronto. NGINX 1.19.0 incluye compatibilidad con QUIC (HTTP/3), la próxima gran actualización de los protocolos de transporte para la comunicación entre los clientes y los sitios web, las aplicaciones y las API.
Si quieres probar las funciones avanzadas de NGINX Plus, inicia hoy mismo tu prueba gratuita de 30 días o ponte en contacto con nosotros para hablar sobre tus casos de uso.
Sobre el autor
Artículos relacionados del blog
Únete a F5 NGINX en AppWorld 2024
Descubre las numerosas razones para asistir al evento insignia de F5, que incluirá un emocionante anuncio sobre la cartera de productos NGINX.
Rotación de certificados SSL/TLS sin reinicios en NGINX Open Source
La función de diccionario compartido permite configurar NGINX sin necesidad de reiniciarlo al renovar los certificados SSL/TLS.
Exposición de APIs en Kubernetes
La unidad 2 de Microservices March 2022 se centra en cómo exponer tus API en Kubernetes. Aquí tienes enlaces a los recursos que necesitas: la retransmisión en directo del 14 de marzo, artículos de blog y otros recursos de preparación, y el laboratorio práctico «Protege las API de Kubernetes mediante la limitación de solicitudes».
NGINX Sprint 2.0: visión clara, código renovado y nuevos compromisos con el código abierto
Hoy, en NGINX Sprint 2.0, anunciamos cómo respaldaremos nuestra visión del futuro de las aplicaciones modernas con una mayor presencia en la comunidad de código abierto, incluida la participación en el proyecto comunitario Kubernetes, nuevos proyectos de software de código abierto y la arquitectura de referencia para aplicaciones modernas.
Presentamos NGINX Plus R22
NGINX Plus R22 incorpora nuevas funcionalidades, como la compatibilidad con OCSP para verificar la revocación de certificados en TLS mutuo, el uso de varios proveedores de identidad OIDC en una configuración, el seguimiento en tiempo real de la limitación de solicitudes y conexiones en el panel de NGINX Plus y mejoras en NGINX JavaScript.
Presentamos NGINX Plus R17
NGINX Plus R17 incorpora compatibilidad con la limitación de velocidad en dos fases y con TLS 1.3, la versión más reciente del protocolo Transport Layer Security. La configuración de OpenID Connect es más sencilla y NGINX ModSecurity WAF es el doble de rápido que antes. También se ha actualizado el módulo JavaScript de NGINX.