Ya están disponibles los paquetes binarios de la versión preliminar de la implementación de QUIC+HTTP/3 de NGINX

Robert HaynesResponsable de marketing técnico

[Editor: NGINX ya es compatible oficialmente con HTTP/3 mediante QUIC. Está disponible como parte de la versión principal NGINX 1.25.1 para los usuarios de código abierto y NGINX Plus R30 para los clientes empresariales.]
[ngx_snippet name=’table-style-blog’]
Nos complace anunciar que nuestra implementación preliminar de la compatibilidad de NGINX con QUIC+HTTP/3 ya está disponible en forma de paquetes binarios precompilados para dos distribuciones:

• Red Hat Enterprise Linux 9 y variantes con compatibilidad binaria
• Ubuntu 22.04

Los binarios son la última versión disponible de la rama quic del repositorio independiente nginx-quic, que aloja la implementación preliminar. Como ha sido el caso desde que comenzamos a trabajar en QUIC+HTTP/3 en NGINX, todavía puede descargar y compilar NGINX Open Source con QUIC+HTTP/3 y elegir entre varias bibliotecas SSL/TLS compatibles con QUIC. Aunque el código está etiquetado como experimental, varios miembros de la comunidad han indicado que utilizan nginx-quic en producción con buenos resultados.

Nuestra principal motivación para publicar binarios precompilados es agilizar y facilitar las pruebas de NGINX con QUIC+HTTP/3. Estos binarios evitan tener que compilar el código fuente y se pueden instalar mediante herramientas estándar de gestión de paquetes.

En el momento de redactar este texto, OpenSSL, el estándar de facto para SSL/TLS de código abierto, no es compatible con QUIC. Por ello, compilamos las distribuciones binarias con un paquete de la biblioteca quictls que se instala automáticamente como dependencia. Elegimos quictls porque actualmente ofrece la mejor combinación de estabilidad, compatibilidad y funcionalidades.

Las instrucciones de instalación de la distribución binaria están disponibles en el sitio web de 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 las directivas para HTTP/1.1 y HTTP/2 en los bloques de configuración de servidor virtual (server{}), ya existentes.

Para obtener la configuración funcional más básica, basta con incluir tres directivas en el bloque server{} (y en el bloque secundario location{}):

Este es un ejemplo de bloque server{} :

server {    # for better compatibility we recommend
    # using the same port number for QUIC and 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 / {
        # advertise that QUIC is available on the configured port
        add_header Alt-Svc 'h3=":$server_port"; ma=86400';
                
        #proxy_pass <upstream_group>; 
        #root       /<root_directory>; 
    }
}

Hay varias directivas y variables opcionales nuevas relacionadas con HTTP/3 (que no se muestran en el fragmento), entre ellas 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 on, indica a NGINX que envíe al solicitante un mensaje de reintento de QUIC en el que se especifica el nuevo ID de conexión que debe utilizar, con el fin de validar la dirección IP del solicitante. El paquete de reintento de QUIC compensa parcialmente el hecho de que no se pueda utilizar un protocolo de enlace de tres vías de TCP para validar la conexión, ya que QUIC funciona sobre UDP.
• ssl_early_data – (Directiva) Cuando se establece en on, indica a NGINX que acepte datos de la aplicación en la primera solicitud enviada por un cliente a través de una nueva conexión TLS 1.3, si ese cliente ya había establecido una conexión anteriormente. Esto se conoce como reanudación de la conexión sin tiempo de ida y vuelta (0‑RTT). La compatibilidad con el envío de «datos anticipados» 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 conexiones 0‑RTT puede suponer un riesgo de seguridad, ya que los datos anticipados son vulnerables a ataques de repetición si incluyen un método de solicitud HTTP distinto de GET. Para obtener más información, consulte la sección sobre TLS 1.3 de Announcing NGINX Plus R17 en nuestro blog.

El diagrama muestra cómo la reanudación de conexiones 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 con NGINX. En cambio, con TCP y TLS, el cliente debe realizar un nuevo protocolo de enlace TLS con NGINX para establecer una conexión segura, lo que requiere varios viajes de ida y vuelta adicionales.

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

Pruebas de NGINX con QUIC+HTTP/3

Como ya se ha mencionado, una de nuestras motivaciones para publicar binarios precompilados es facilitar la comprobación de que NGINX gestiona correctamente el tráfico HTTP/3. Para realizar pruebas sencillas desde la línea de comandos, puede compilar curl con compatibilidad con HTTP/3 o utilizar un contenedor precompilado. Además, las versiones más recientes de la mayoría de los navegadores son compatibles con QUIC+HTTP/3.

Para comprobar que su sitio con QUIC habilitado atiende las solicitudes de conexión HTTP/3 de los navegadores, puede utilizar las herramientas para desarrolladores de un navegador para examinar las cabeceras HTTP devueltas por NGINX. La implementación de QUIC+HTTP/3 funciona correctamente si NGINX incluye la cabecera Alt-Svc mencionada 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 posteriores se transmiten mediante QUIC. Otra forma de comprobar que se está utilizando QUIC+HTTP/3 consiste en incluir otra directiva add_header para establecer como valor de una cabecera HTTP personalizada el protocolo capturado por la variable $server-protocol. Puede hacer un seguimiento del valor de la cabecera 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.

Este es un ejemplo de bloque location en el que el encabezado HTTP personalizado es X-protocol:

location / {     # advertise that QUIC is available on the configured port 
    add_header Alt-Svc 'h3=":$server_port"; ma=86400'; 
       
    # signal whether we are using QUIC+HTTP/3
    add_header X-protocol $server_protocol always;        
    
    #proxy_pass <upstream_group>; 
    #root /<root_directory>; 
}

Como alternativa, existen herramientas como la extensión de Chrome «HTTP Indicator», que indican visualmente el protocolo en uso. (Tenga en cuenta que esto no constituye una recomendación de ninguna extensión para navegadores y que debe asegurarse de que las posibles implicaciones de seguridad de una extensión sean aceptables dadas sus circunstancias).

Próximos pasos

Seguiremos desarrollando nuestra solución para QUIC+HTTP/3 y ofreciendo más ejemplos de optimizaciones de NGINX durante las próximas semanas. Mientras tanto, comparte los resultados de tus propias pruebas para ayudarnos a tomar decisiones fundamentadas. Puedes enviarnos tus comentarios a través de la lista de correo de desarrollo de NGINX y del canal #quic‑http3 en Slack de la comunidad de NGINX.

Para recibir novedades sobre nuestro trabajo en QUIC+HTTP/3, incluido el próximo hito importante —la integración del repositorio nginx-quic en la rama principal de NGINX Open Source—, suscríbase a la lista de correo de anuncios de NGINX.

Vea el seminario web

También le animamos a asistir a nuestro próximo seminario web, «Pruebe NGINX y QUIC+HTTP/3 de forma práctica», que tendrá lugar el miércoles 19 de abril de 2023:

• Norteamérica – 10:00 (hora del Pacífico)
• EMEA – 11:00 CET
• APCJ – 10:00 SGT

Sobre el autor

Robert HaynesResponsable de marketing técnico

Más artículos de Robert Haynes