Nos complace anunciar la disponibilidad de NGINX Plus Release 27 (R27) . Basado en NGINX de código abierto, NGINX Plus es el único servidor web de software todo en uno , balanceador de carga, proxy inverso, caché de contenido y puerta de enlace API.
Las características nuevas y mejoradas de NGINX Plus R27 incluyen:
keepalive_time
de la directiva HTTP health_check
habilita conexiones keepalive para controles de estado y establece su duración. Establecer nuevas conexiones es computacionalmente costoso, por lo que reutilizar conexiones puede reducir considerablemente el uso de CPU cuando hay un gran número de servidores ascendentes.401
(No autorizado)
. NGINX Plus R27 introduce el parámetro de error
en la directiva auth_jwt_require
, lo que le permite configurar el código para401
o 403
(Prohibido)
para cada verificación para distinguir mejor entre errores de autenticación y autorización.ngx.fetch
y un nuevo objeto que informa la versión njs como un número hexadecimal. El módulo Prometheus-njs ahora puede convertir métricas NGINX Plus adicionales a un formato compatible con Prometheus: el campo de códigos
(que informa los recuentos de códigos de estado HTTP individuales para servidores ascendentes y virtuales) y métricas generadas por los módulos Limitar conexiones y Limitar solicitudes.Para completar el lanzamiento se incluye un nuevo número de versión (8) para la API NGINX Plus y una distribución más uniforme de las conexiones cuando se utiliza el modo EPOLLEXCLUSIVE en los kernels de Linux.
Nota: Si está actualizando desde una versión distinta a NGINX Plus R26 , asegúrese de consultar la sección Cambios importantes en el comportamiento en los blogs de anuncios de todas las versiones entre su versión actual y esta.
Nuevos sistemas operativos compatibles:
Se eliminaron sistemas operativos y arquitecturas más antiguas:
Sistemas operativos y arquitecturas más antiguos obsoletos y programados para su eliminación en NGINX Plus R28:
Las conexiones Keepalive entre NGINX Plus y los servidores ascendentes mejoran significativamente el rendimiento para casos de uso de equilibrio de carga y proxy inverso. En el caso particular del proxy sobre HTTPS, el gasto computacional del protocolo de enlace TLS completo requerido para cada nueva conexión puede generar tensión en sus recursos informáticos, especialmente en entornos de producción con un gran número de servidores ascendentes.
En versiones anteriores, NGINX Plus no utilizaba conexiones keepalive para los controles de estado, sino que establecía una nueva conexión para cada sonda de estado. NGINX Plus R27 introduce conexiones keepalive para comprobaciones del estado de HTTP. El nuevo parámetro keepalive_time
de la directiva health_check
establece el tiempo de vida de cada conexión keepalive, después de lo cual se establece una nueva conexión. Nuestras pruebas indican que, para el proxy sobre HTTPS, las conexiones keepalive reducen el uso de CPU para controles de estado en un factor de 10 a 20 en los servidores NGINX Plus. También ahorran recursos de CPU en servidores ascendentes.
El siguiente ejemplo habilita conexiones keepalive con una duración de 60 segundos. Teniendo en cuenta la frecuencia de comprobación de estado de 1 segundo establecida por el parámetro de intervalo
, NGINX Plus incurre en el gasto del protocolo de enlace TLS y el establecimiento de la conexión solo una vez cada 60 comprobaciones de estado.
Transport Layer Security (TLS) es el protocolo estándar de facto para el cifrado de datos en Internet. Desafortunadamente, proteger los datos también agrega latencia. La implementación de TLS en el kernel (kTLS) mejora el rendimiento al servir contenido estático al reducir significativamente la necesidad de operaciones de copia entre el espacio del usuario y el kernel.
La combinación de kTLS y la llamada al sistema sendfile()
significa que los datos se cifran directamente en el espacio del kernel antes de pasarlos a la pila de red para su transmisión, en lugar de copiarse al espacio del usuario para su cifrado mediante bibliotecas TLS y luego copiarse nuevamente al espacio del kernel antes de la transmisión. kTLS también permite la descarga del procesamiento de TLS al hardware, incluida la descarga del procesamiento de cifrado simétrico de TLS a los dispositivos de red.
Hay tres requisitos para admitir kTLS:
En octubre de 2021 agregamos soporte para kTLS a NGINX Open Source 1.21.4 en plataformas que cumplen con los requisitos 1 y 2. Ahora estamos agregando soporte para kTLS en NGINX Plus en estas plataformas:
Cuando NGINX Plus se implementa como un proxy inverso o un balanceador de carga, la API de NGINX Plus proporciona un amplio conjunto de métricas sobre el tráfico, los códigos de respuesta y la latencia para cada servidor virtual, lo que permite a los clientes observar y monitorear el rendimiento y la disponibilidad del servidor.
En versiones anteriores, NGINX Plus generaba métricas sobre la actividad y los errores de TLS a nivel de todo el sistema cuando se utilizaban conexiones HTTPS entre NGINX Plus y servidores ascendentes, tanto en contextos http
como de flujo
(establecidos con las directivas proxy_pass
https: //path-to-upstream
y proxy_ssl
on
respectivamente). Las estadísticas cubren protocolos de enlace, fallas y reutilizaciones de sesiones (según lo configurado con la directiva proxy_ssl_session_reuse
).
NGINX Plus R27 genera esas métricas TLS para servidores ascendentes individuales cuya configuración incluye la directiva zone
y para servidores virtuales cuya configuración incluye la directiva status_zone
. Disponer de métricas tanto del lado del cliente como del lado del servidor resulta útil a la hora de solucionar problemas con los protocolos de enlace TLS.
El siguiente ejemplo habilita la recopilación de estadísticas en el servidor ascendente upstream1 y el servidor virtual que redirige el tráfico hacia él.
Este resultado indica que el primer servidor ascendente participó en cuatro protocolos de enlace TLS y dos sesiones reutilizadas (para abreviar, mostramos un resultado parcial para el primer servidor y omitimos el resultado para los otros servidores ascendentes):
$ curl http://127.0.0.1:8000/api/8/http/upstreams/upstream1 | jq { "pares": [ { "id": 0, "servidor": "127.0.0.1:8081", "nombre": "127.0.0.1:8081", "copia de seguridad": falso, "peso": 1, "estado": "arriba", "activo": 0, "ssl": { "apretones de manos": 4, "el protocolo de enlace falló": 0, "reutilizaciones de sesión": 2 } , "solicitudes": 4, "tiempo_de_encabezado": 4, "tiempo_de_respuesta": 4, ... } ... ] }
Esta salida indica que NGINX Plus participó en siete protocolos de enlace TLS:
$ curl http://127.0.0.1:8000/api/8/http/server_zones/srv | jq { "procesando": 0, "solicitudes": 7, "respuestas": { "1xx": 0, "2xx": 7, "3xx": 0, "4xx": 0, "5xx": 0, "códigos": { "200": 7 }, "total": 7 }, "descartado": 0, "recibido": 546, "enviado": 1134, "ssl": { "apretones de manos": 7, "el protocolo de enlace falló": 0, "reutilizaciones de sesión": 0 } ... }
Tenga en cuenta que la API de NGINX Plus aún recopila las métricas TLS globales disponibles en versiones anteriores de NGINX Plus:
$ curl http://127.0.0.1:8000/api/8/ssl | jq { "apretones de manos": 21, "el protocolo de enlace falló": 0, "reutilizaciones de sesión": 6 }
NGINX Plus R25 introdujo la directiva auth_jwt_require
para definir verificaciones personalizadas durante el proceso de validación de JWT. En NGINX Plus R25 y R26 , el código de error devuelto por una falla de validación siempre es 401
(No autorizado)
.
NGINX Plus R27 introduce el parámetro de error
en la directiva auth_jwt_require
, que puede usar para configurar el código en401
o403
(Prohibido)
para cada directiva de forma independiente. Cuando falla la solicitud de acceso de un usuario, la elección de códigos le permite transmitir la distinción entre una falla de autenticación (JWT no es válido) y una falla de autorización (falta el reclamo requerido). También puede crear controladores personalizados para los códigos de error, por ejemplo, para devolver una página especial que explique el error (con la directiva error_page
) o para redirigir la solicitud a una ubicación interna determinada para su posterior procesamiento.
El código de estado predeterminado permanece401
por fallas en los siguientes tipos de comprobaciones JWT:
auth_jwt_require
pero no con el parámetro de error
Si hay varias directivas auth_jwt_require
en un bloque de ubicación
, se evalúan en el orden en que aparecen. El procesamiento se detiene en el primer fallo y se devuelve el código de error especificado.
En este ejemplo, la directiva auth_jwt_require
devuelve403
si $req1
o $req2
se evalúan como un valor vacío o0
(cero).
NGINX Plus R27 incorpora versiones0.7.3 y0.7.4 del módulo JavaScript de NGINX e incluye las siguientes mejoras.
NGINX Javascript 0.5.3, incorporado a NGINX Plus R24 , introdujo la función ngx.fetch
(también conocida como Fetch API) para crear una instancia de un cliente HTTP simple desde el contexto de una conexión TCP/UDP. (Para obtener una discusión sobre los casos de uso de la función, consulte Aprovechar los servicios HTTP para TCP.htmlUDP con un cliente HTTP simple en nuestro blog).
NGINX Plus R27 presenta las siguientes directivas para ajustar el comportamiento de la API Fetch:
js_fetch_buffer_size
[ HTTP ][ Stream ] – Establece el tamaño del búfer utilizado para leer y escribir.js_fetch_max_response_buffer_size
[ HTTP ][ Stream ] – Establece el tamaño máximo de la respuesta recibida con la API Fetch.js_fetch_timeout
[ HTTP ][ Stream ] – Define el tiempo de espera para lectura y escritura entre dos operaciones de lectura o escritura sucesivas (no para toda la respuesta). Si no se transmiten datos dentro del período de tiempo de espera, la conexión se cierra.js_fetch_verify
[ HTTP ][ Stream ] – Habilita o deshabilita la verificación del certificado del servidor HTTPS.El nuevo objeto njs.version_number
informa la versión del módulo njs como un número hexadecimal. (El objeto njs.version
existente devuelve la versión como una cadena de caracteres).
El módulo Prometheus-njs , que convierte las métricas de NGINX Plus a un formato compatible con Prometheus, ahora puede convertir las métricas expuestas en estos puntos finales adicionales:
/http/limit_conns
/http/limit_reqs
de códigos
(que informa los recuentos de códigos de estado HTTP individuales<.htmla>) en /http/server_zones
y /http/upstreams
/stream/limit_conns
El número de versión de la API NGINX Plus se actualiza de 7 a 8 para reflejar la adición del campo ssl
a las métricas informadas para servidores ascendentes y virtuales como se describe en Métricas TLS para servidores ascendentes y virtuales . Los números de versiones anteriores aún funcionan, pero la salida no incluye las métricas agregadas en versiones de API posteriores.
NGINX Plus R27 distribuye las conexiones de manera más uniforme entre los procesos de trabajo de NGINX cuando se utiliza el modo EPOLLEXCLUSIVE en los kernels de Linux. Normalmente, en este modo el kernel notifica solo al proceso que fue el primero en agregar el socket de escucha a la instancia EPOLL. Como resultado, la mayoría de las conexiones son manejadas por el primer proceso de trabajo. NGINX ahora vuelve a agregar el socket periódicamente para darles a otros procesos de trabajo la oportunidad de aceptar conexiones.
Si está utilizando NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R27 lo antes posible. También recibirás varias correcciones y mejoras adicionales, y ayudará a NGINX a ayudarte cuando necesites generar un ticket de soporte.
Si aún no ha probado NGINX Plus, le recomendamos que lo haga por cuestiones de seguridad, equilibrio de carga y puerta de enlace de API, o como servidor web totalmente compatible con API de administración y monitoreo mejoradas. Puede comenzar hoy con una prueba gratuita de 30 días .
"Esta publicación de blog puede hacer referencia a productos que ya no están disponibles o que ya no reciben soporte. Para obtener la información más actualizada sobre los productos y soluciones F5 NGINX disponibles, explore nuestra familia de productos NGINX . NGINX ahora es parte de F5. Todos los enlaces anteriores de NGINX.com redirigirán a contenido similar de NGINX en F5.com.