Binary Packages Now Available for the Preview NGINX QUIC+HTTP/3 Implementation (Paquetes binarios disponibles para la versión preliminar de NGINX QUIC+HTTP/3)

[ Editor : NGINX ahora es oficialmente compatible con HTTP/3 con QUIC. Está disponible como parte de la versión principal de NGINX 1.25.1 para usuarios de código abierto y NGINX Plus R30 para clientes empresariales.
[ngx_snippet name='blog de estilo de tabla']
Nos complace anunciar que nuestra implementación preliminar del soporte de NGINX para QUIC+HTTP/3 ahora está disponible como paquetes binarios prediseñados para dos distribuciones:

• Red Hat Enterprise Linux 9 y variantes compatibles con binarios
• Ubuntu 22.04

Los binarios son el último resultado de la rama quic del repositorio separado nginx-quic que aloja la implementación de vista previa. Como ha sido el caso desde que comenzamos a trabajar en QUIC+HTTP/3 en NGINX , aún puede descargar y compilar NGINX de código abierto con QUIC+HTTP/3 y una selección de bibliotecas SSL/TLS compatibles con QUIC. Aunque el código está etiquetado como experimental, varios miembros de la comunidad han informado que están utilizando nginx-quic con éxito en producción.

Nuestra principal motivación para lanzar binarios prediseñados es hacer que sea más rápido y más fácil probar NGINX con QUIC+HTTP/3. Los binarios eliminan la necesidad de compilar desde la fuente y se pueden instalar utilizando herramientas de administración de paquetes estándar.

Al momento de escribir este artículo, el estándar de facto para SSL/TLS de código abierto, OpenSSL, no es compatible con QUIC. Por lo tanto, creamos las distribuciones binarias con un paquete de biblioteca quictls , que se instala automáticamente como dependencia. Seleccionamos quictls porque actualmente representa la mejor combinación de estabilidad, compatibilidad y características.

Las instrucciones de instalación para la distribución binaria están disponibles en el sitio web NGINX QUIC .

Configuración de NGINX para QUIC+HTTP/3

Hay varias directivas nuevas para configurar NGINX para QUIC+HTTP/3, pero es fácil combinarlas con directivas para HTTP/1.1 y HTTP/2 en bloques de configuración de servidor virtual ( server{} ) existentes.

Para la configuración funcional más básica, todo lo que tienes que hacer es incluir tres directivas en el bloque server{} (y child location{} ):

A continuación se muestra un bloque server{} de muestra:

servidor { # Para una mejor compatibilidad, recomendamos
# usar el mismo número de puerto para QUIC y TCP
listen 443 quic reuseport; # QUIC
listen 443 ssl; # TCP

ssl_certificate certs/example.com.crt;
ssl_certificate_key certs/example.com.key;
ssl_protocols TLSv1.3;

location / {
# Anunciar que QUIC está disponible en el puerto configurado
add_header Alt-Svc 'h3=":$server_port"; ma=86400';

#proxy_pass <grupo ascendente>; 
        #raíz       /<directorio_raíz>; 
}
}

Hay varias nuevas directivas y variables opcionales relacionadas con HTTP/3 (que no se muestran en el fragmento), incluidas las siguientes:

• $http3 – (Variable) Se establece en h3 cuando la solicitud se envía durante una sesión HTTP/3 (de lo contrario, es una cadena vacía).
• quic_retry – (Directiva) Cuando se establece en activado , le indica a NGINX que envíe un mensaje de reintento QUIC al solicitante especificando la nueva ID de conexión a utilizar, con el propósito de validar la dirección IP del solicitante. El paquete de reintento QUIC compensa parcialmente el hecho de que no se puede utilizar un protocolo de enlace de conexión de tres vías TCP para validar la conexión porque QUIC se ejecuta sobre UDP.

• ssl_early_data – (Directiva) Cuando se establece en activado , le indica a NGINX que acepte datos de la aplicação en la primera solicitud enviada por un cliente a través de una nueva conexión TLS 1.3, si hubo una conexión previa de ese cliente. Esto se conoce como reanudación de conexión con tiempo de ida y vuelta cero (0-RTT) . La compatibilidad con el envío de “datos tempranos” es una característica de TLS 1.3 y contribuye a mejorar el rendimiento de QUIC+HTTP/3 al eliminar los intercambios de mensajes de ida y vuelta adicionales necesarios para un protocolo de enlace TLS.

  Nota:  La reanudación de la conexión 0-RTT puede crear un riesgo de seguridad, porque los datos iniciales están sujetos a ataques de reproducción si incluyen un método de solicitud HTTP distinto de GET . Para obtener más detalles, consulte la sección sobre TLS 1.3 en Anuncio de NGINX Plus R17 en nuestro blog.

El diagrama destaca cómo la reanudación de la conexión 0-RTT con QUIC+HTTP/3 mejora el rendimiento, ya que el cliente puede enviar una solicitud HTTP en su primer mensaje al reanudar una conexión QUIC a NGINX. En cambio, para TCP con TLS, el cliente debe realizar un nuevo protocolo de enlace TLS con NGINX para establecer una conexión segura, lo que implica varios viajes de ida y vuelta adicionales.

Para obtener información sobre todas las nuevas directivas y variables, consulte 3. Configuración sección de la nginx-quic LÉAME.

Prueba de NGINX con QUIC+HTTP/3

Como se mencionó anteriormente, una de nuestras motivaciones para publicar binarios prediseñados es facilitar la prueba de que NGINX maneja correctamente el tráfico HTTP/3. Para realizar pruebas de línea de comandos simples, puede crear curl con soporte HTTP/3 o usar un contenedor prediseñado . Además, las versiones más nuevas de la mayoría de los navegadores admiten QUIC+HTTP/3.

Para verificar que su sitio web con QUIC habilitado satisface las solicitudes de conexión HTTP/3 de los navegadores, puede usar las herramientas de desarrollo del navegador para examinar los encabezados HTTP devueltos por NGINX. La implementación de QUIC+HTTP/3 funciona correctamente si NGINX incluye el encabezado Alt-Svc mencionado anteriormente en su respuesta a la solicitud HTTP inicial del navegador a través de TCP.

En ese momento, un navegador compatible con QUIC establece una conexión QUIC en el puerto especificado en la directiva Alt-Svc , y las solicitudes y respuestas HTTP subsiguientes se realizan a través de QUIC. Otra forma de verificar que se utiliza QUIC+HTTP/3 es incluir otra directiva add_header para establecer el valor de un encabezado HTTP personalizado en el protocolo capturado por la variable $server-protocol . Puede rastrear el valor del encabezado a medida que cambia de HTTP/1. x antes de que se establezca la conexión QUIC a HTTP/3.0 cuando se utiliza QUIC.

A continuación se muestra un bloque de ubicación de muestra donde el encabezado HTTP personalizado es X-protocol :

location / { # anuncia que QUIC está disponible en el puerto configurado

add_header Alt-Svc 'h3=":$server_port"; ma=86400';

# indica si estamos usando QUIC+HTTP/3

add_header X-protocol $server_protocol always;

#proxy_pass <grupo ascendente>; 
    #raíz /<directorio_raíz>; }

Alternativamente, existen herramientas como la extensión Chrome HTTP Indicator que indican visualmente el protocolo en uso. (Tenga en cuenta que esto no constituye un respaldo de ninguna extensión del navegador y usted debe asegurarse de que todas las posibles implicaciones de seguridad de una extensión sean aceptables dadas sus circunstancias).

¿Qué sigue?

Continuaremos ofreciendo nuestra solución para QUIC+HTTP/3 y proporcionaremos más ejemplos de optimizaciones de NGINX en las próximas semanas. Mientras tanto, comparta los resultados de sus propias pruebas para ayudarnos a tomar decisiones. Puedes compartir tus comentarios en la lista de correo de desarrollo de NGINX y en el canal #quic‑http3 en NGINX Community Slack .

Para recibir actualizaciones sobre nuestro trabajo en QUIC+HTTP/3, incluido el próximo hito importante (la fusión del repositorio nginx-quic en la rama principal de código abierto NGINX), suscríbase a la lista de correo de anuncios de NGINX .

Ver el webinar

También lo invitamos a asistir a nuestro próximo seminario web, Get Hands‑On with NGINX and QUIC+HTTP/3, el miércoles 19 de abril de 2023:

• América del Norte – 10:00 a. m. PST
• EMEA – 11:00 a. m. CET
• APCJ – 10:00 AM SGT