Rendimiento de TLS: QUIC y HTTP/3

HTTP/2 multiplexa varios streams sobre una única conexión TCP, lo que resuelve el bloqueo de cabecera de línea por conexión de HTTP/1.1. Sin embargo, el propio TCP provoca bloqueo de cabecera de línea en la capa de transporte: si se pierde un segmento TCP, todos los datos que están detrás en la cola deben esperar a la retransmisión, bloqueando simultáneamente todos los streams de HTTP/2. Una pérdida de paquetes del 1 % puede degradar el rendimiento de HTTP/2 por debajo del de HTTP/1.1 con varias conexiones. QUIC (Quick UDP Internet Connections) resuelve este problema implementando streams multiplexados sobre UDP, donde la recuperación de pérdidas a nivel de stream no bloquea los demás streams.

QUIC es un protocolo de transporte basado en UDP, desarrollado por Google (2012-2015) y estandarizado por el IETF como RFC 9000 (2021). QUIC integra TLS 1.3 en la capa de transporte: no existe un handshake de TLS independiente sobre QUIC; TLS está integrado en el propio handshake de QUIC. QUIC proporciona: streams multiplexados sin bloqueo de cabecera de línea, migración de conexiones (mantener la conexión al cambiar de red, por ejemplo, de WiFi a LTE), establecimiento de conexiones 0-RTT para conexiones repetidas, y detección de pérdidas y control de congestión integrados. HTTP/3 (RFC 9114) proporciona la semántica de HTTP sobre streams de QUIC.

El handshake de QUIC combina el establecimiento de la conexión con la negociación de TLS. En el primer vuelo (0 RTT en la terminología de QUIC), el cliente envía paquetes Initial que contienen ClientHello de TLS. El servidor responde con su propio Initial (ServerHello) y con paquetes Handshake (extensiones cifradas, certificado, Finished). El cliente envía Handshake Finished y queda listo para enviar datos de la aplicación: esto corresponde a 1-RTT. En las conexiones 0-RTT, el cliente envía paquetes 0-RTT (datos de la aplicación) junto con ClientHello, utilizando una clave derivada del resumption secret de la sesión anterior, y logra cero viajes de ida y vuelta adicionales en las sesiones almacenadas en caché.

QUIC utiliza cuatro niveles de cifrado distintos, correspondientes a las fases del key schedule de TLS: Initial (AEAD derivado de QUIC mediante una clave constante conocida; proporciona integridad, pero no confidencialidad frente a atacantes sofisticados), Handshake (derivado de TLS handshake_secret; proporciona confidencialidad para los mensajes del handshake de TLS), 0-RTT (derivado de early_secret de la sesión anterior; cifra los datos de la aplicación 0-RTT) y 1-RTT (derivado de TLS master_secret; cifra todos los datos de la aplicación). Las cabeceras de QUIC están parcialmente cifradas: el número de paquete y el payload están cifrados, pero cierta información de enrutamiento (Connection ID) permanece visible para los balanceadores de carga.

Las conexiones QUIC se identifican mediante un Connection ID (CID) en lugar de una 4-tupla (IP de origen, puerto de origen, IP de destino, puerto de destino). Esto permite que las conexiones sobrevivan a los cambios de red: cuando un cliente móvil cambia de WiFi a LTE, la dirección IP cambia, pero el CID permanece igual. El cliente envía un frame PATH_CHALLENGE por la nueva ruta; el servidor responde con PATH_RESPONSE y valida la nueva dirección. La conexión continúa sin interrupciones y sin renegociación. TCP no admite esto: una conexión TCP está vinculada a su 4-tupla y debe establecerse de nuevo cuando cambia la red, lo que requiere un nuevo handshake de TLS. La migración de QUIC mejora considerablemente el rendimiento percibido por los usuarios móviles.

HTTP/3 asigna la semántica de HTTP a los streams de QUIC. Cada par de solicitud y respuesta HTTP ocupa un stream bidireccional de QUIC independiente. Los streams de QUIC son independientes: una pérdida en el stream 3 no bloquea el stream 7. HTTP/3 utiliza QPACK para la compresión de cabeceras (en sustitución de HPACK de HTTP/2); QPACK se rediseñó para funcionar sin requerir la entrega en orden. Dos streams de control unidireccionales dedicados transportan la configuración y las instrucciones del decodificador y el codificador. Server push en HTTP/3 utiliza push streams (unidireccionales). El efecto general es que HTTP/3 supera a HTTP/2 sobre todo en condiciones de pérdida de paquetes (redes móviles y rutas congestionadas), donde el bloqueo de cabecera de línea de TCP resulta más perjudicial.

Las mediciones del rendimiento de QUIC y HTTP/3 en condiciones reales muestran resultados variados según las condiciones de la red. En redes de alta calidad (baja latencia y pocas pérdidas de paquetes), HTTP/3 y HTTP/2 ofrecen un rendimiento similar; la sobrecarga de QUIC (cabeceras más grandes y sobrecarga de procesamiento de UDP) incluso puede hacer que HTTP/3 sea ligeramente más lento. En redes con pérdidas (más del 1 % de pérdida de paquetes, algo habitual en redes móviles y por satélite), HTTP/3 supera significativamente a HTTP/2. Google informó de una reducción del 7-8 % en el rebuffering de YouTube al cambiar a QUIC. Facebook (Meta) informó de una mejora del 7-15 % en la latencia de las solicitudes de los feeds de Instagram mediante QUIC. Las mejoras son más visibles en la latencia de cola (p95 y p99), donde las pausas causadas por las retransmisiones de TCP tienen mayor impacto.

El balanceo de carga de QUIC es más complejo que el de TCP porque QUIC se basa en UDP y los balanceadores de carga UDP sin estado no pueden mantener la afinidad de las conexiones. El borrador draft-ietf-quic-load-balancers del IETF define un enfoque: los servidores codifican la información de enrutamiento en el Connection ID, de modo que los balanceadores de carga puedan dirigir los paquetes de una misma conexión al mismo servidor sin mantener el estado de cada conexión. El Connection ID contiene un ID de servidor cifrado mediante una clave compartida entre el balanceador de carga y los servidores. Cloudflare, Fastly y Nginx implementan variantes de este enfoque. La traversía de NAT es otra cuestión: las conexiones QUIC deben sobrevivir al remapeo de NAT, que gestiona el mecanismo de migración de conexiones.

Las principales CDN han implementado QUIC y HTTP/3 a gran escala. Cloudflare ofrece HTTP/3 desde 2019 e informa de que aproximadamente el 20 % del tráfico utiliza QUIC cuando tanto el cliente como el servidor lo admiten. Fastly, Akamai y AWS CloudFront admiten HTTP/3 en sus puntos de presencia. La propia infraestructura de Google (Search, YouTube y Gmail) utiliza QUIC internamente desde 2013 y ofrece HTTP/3 al público. Las implementaciones en CDN se benefician de la reanudación 0-RTT de QUIC: los visitantes recurrentes establecen conexiones más rápido y la migración de conexiones mejora el rendimiento de los usuarios móviles que cambian de punto de acceso durante la entrega de contenido.

El diseño de QUIC basado en UDP introduce consideraciones de seguridad específicas. Ataques de amplificación: un atacante puede falsificar una IP de origen y enviar paquetes Initial pequeños, lo que provoca que el servidor envíe respuestas Handshake grandes a la víctima. QUIC lo mitiga limitando las respuestas del servidor a 3 veces los datos recibidos hasta que se complete la validación de la dirección (mediante el mecanismo RETRY). Inundación de conexiones: los servidores QUIC deben limitar la tasa de nuevos intentos de conexión procedentes de una misma IP. Los ataques de negociación de versiones se evitan incluyendo la versión en el handshake protegido criptográficamente. El cifrado integrado de QUIC impide que los dispositivos de inspección analicen el payload de QUIC sin estar en la ruta y disponer del certificado del servidor, lo que mejora la privacidad en comparación con el tráfico TCP inspeccionable.

La implementación de HTTP/3 requiere: (1) un servidor compatible con QUIC (nginx 1.25+, Caddy, HAProxy 2.6+, LiteSpeed o una implementación a nivel de aplicación mediante las bibliotecas quic-go, aioquic o ngtcp2); (2) el puerto UDP 443 abierto en los firewalls; muchos firewalls corporativos bloquean UDP 443, lo que provoca que QUIC vuelva a TCP/TLS; (3) anunciar la compatibilidad con HTTP/3 mediante la cabecera de respuesta Alt-Svc: Alt-Svc: h3=":443"; ma=86400, para indicar a los clientes HTTP/2 que actualicen el protocolo; (4) balanceadores de carga compatibles con QUIC o passthrough UDP de capa 4; (5) supervisar métricas específicas de QUIC: eventos de migración de conexiones, tasa de aceptación de 0-RTT y tasa de fallback del protocolo. Un despliegue gradual con fallback a HTTPS resulta transparente para los clientes que no admiten QUIC.

¿Cómo resuelve QUIC el problema del bloqueo de cabecera de línea que afecta a HTTP/2 sobre TCP?

QUIC integra TLS 1.3 en la capa de transporte sobre UDP y elimina el bloqueo de cabecera de línea de TCP mediante la recuperación independiente de pérdidas por stream. Los Connection ID permiten migrar entre redes sin renegociación. HTTP/3 asigna HTTP a los streams de QUIC mediante la compresión de cabeceras QPACK. La reanudación de conexiones 0-RTT reutiliza los secretos de sesión de TLS. QUIC supera a HTTP/2 sobre todo cuando hay pérdida de paquetes (en redes móviles y congestionadas). El balanceo de carga de QUIC requiere codificar el enrutamiento del servidor en los Connection ID. La implementación requiere UDP 443, servidores compatibles con QUIC y cabeceras Alt-Svc para anunciar el protocolo.