QUIC y HTTP/3: por qué sobre UDP

QUIC no es un protocolo de aplicación sino un transporte completo construido sobre UDP, con control de congestión, fiabilidad y cifrado propios. Elegir UDP no fue una preferencia técnica sino la única salida posible: TCP está implementado en los núcleos de los sistemas operativos y en el silicio de los equipos de red, y cambiarlo lleva décadas. Esa decisión es la que permite lo demás.

El problema de osificación

El bloqueo de cabecera de línea de TCP se conoce desde hace décadas y la solución conceptual es evidente: que el transporte sepa que hay flujos independientes y no retenga unos por culpa de otros. Existe incluso un protocolo estándar que lo hace.

El obstáculo no fue técnico sino de despliegue. TCP vive en el núcleo del sistema operativo y, sobre todo, lo conocen y lo inspeccionan los miles de intermediarios que hay entre un cliente y un servidor: cortafuegos, traductores de direcciones, aceleradores, equipos de operador. Esos intermediarios examinan las cabeceras de TCP, y muchos descartan lo que no entienden. Un protocolo nuevo a nivel de transporte, o incluso una opción nueva de TCP, tiene una probabilidad alta de no atravesar la red.

A ese fenómeno se le llama osificación: la red se ha endurecido alrededor de los protocolos existentes y ya no admite cambios en ellos.

La salida fue construir el transporte nuevo encima de UDP, que los intermediarios sí dejan pasar porque lo necesitan para DNS, para vídeo en tiempo real y para juegos. Desde el punto de vista de la red, QUIC son datagramas UDP con contenido opaco. Y como QUIC vive en espacio de usuario, dentro del navegador y del servidor, se puede actualizar con cada versión del navegador en lugar de esperar a que los sistemas operativos evolucionen.

Flujos de verdad independientes

QUIC entiende de flujos en el propio transporte. Cada flujo tiene su numeración y su control de flujo, y la pérdida de un paquete solo afecta a los flujos cuyos datos iban en ese paquete.

La diferencia con HTTP/2 es exacta y merece verse en paralelo:

Este es el argumento central a favor de HTTP/3, y su magnitud depende por completo de la pérdida de paquetes de la red del usuario. En una conexión de fibra con pérdida prácticamente nula, la diferencia es pequeña. En una red móvil real, puede ser grande.

Lo que QUIC integra

Además de los flujos, QUIC unifica cosas que en la pila clásica estaban separadas y que costaban viajes de ida y vuelta.

El cifrado es obligatorio y está integrado. QUIC no tiene modo sin cifrar. La negociación criptográfica usa TLS 1.3 pero fusionada con el establecimiento del transporte, no encima de él. En lugar de un viaje para TCP y otro para TLS, hay un solo viaje de ida y vuelta para ambos.

TCP + TLS 1.3   ->  1 RTT de TCP + 1 RTT de TLS = 2 RTT
QUIC            ->  1 RTT total

Ese ahorro de un viaje completo por conexión nueva es significativo, y se multiplica por el número de orígenes que toque la página.

El identificador de conexión sustituye a la tupla de direcciones. Una conexión TCP se identifica por las direcciones IP y los puertos de ambos extremos. Si cambia cualquiera de los cuatro, la conexión se rompe. QUIC identifica la conexión con un identificador propio que viaja en los paquetes, independiente de la dirección.

Eso habilita la migración de conexión: si el usuario pasa de wifi a red móvil, su dirección IP cambia, pero el identificador de conexión sigue siendo válido y la sesión continúa sin reconectar, sin repetir el saludo y sin repetir la negociación criptográfica. Con TCP, ese cambio significa que todas las peticiones en vuelo fallan y hay que empezar de cero.

Es la mejora que más se nota en el mundo real y la que menos aparece en las pruebas de laboratorio, porque nadie cambia de red mientras ejecuta Lighthouse.

Compresión de cabeceras adaptada. HTTP/3 usa un esquema de compresión de cabeceras equivalente al de HTTP/2 pero rediseñado para no introducir dependencias de orden entre flujos, que reintroducirían por la puerta de atrás el bloqueo que se acaba de eliminar.

Cómo se descubre HTTP/3

Un cliente que quiere conectarse no sabe de antemano si el servidor habla HTTP/3, y no puede simplemente probar con UDP porque puede estar bloqueado. Hay dos mecanismos.

La cabecera de servicio alternativo. El servidor responde por HTTP/1.1 o HTTP/2 anunciando que también está disponible por HTTP/3:

Alt-Svc: h3=":443"; ma=86400

El parámetro ma es el tiempo en segundos durante el cual el cliente puede recordar el anuncio. El navegador guarda la información y usa HTTP/3 a partir de la conexión siguiente. Es decir, la primera visita se hace por el protocolo antiguo y solo las siguientes se benefician.

El registro DNS de servicio. Publicando un registro de tipo HTTPS en el DNS del dominio, el cliente descubre el soporte de HTTP/3 durante la resolución de nombres, antes de abrir ninguna conexión. Eso permite usar HTTP/3 desde la primera conexión, y además puede transportar otra información útil de conexión.

Si gestionas el DNS de tu dominio, publicar ese registro es un cambio de configuración pequeño con un beneficio concreto: elimina la penalización de la primera visita.

Cuándo QUIC no gana

Para no vender más de lo que hay, hay tres situaciones en las que HTTP/3 no mejora o incluso pierde.

Redes que bloquean o limitan UDP. Algunas redes corporativas restringen UDP más allá del DNS. En ese caso el cliente cae a HTTP/2 tras un tiempo de espera, y ese intento fallido cuesta tiempo.

Coste de CPU. Al vivir en espacio de usuario, QUIC no puede aprovechar las optimizaciones de descarga a hardware que los sistemas y las tarjetas de red llevan décadas afinando para TCP. El coste de CPU por byte es mayor, lo cual importa en servidores con mucho tráfico y, en menor medida, en dispositivos móviles con batería.

Redes sin pérdida. Si la pérdida de paquetes es prácticamente cero, el principal argumento de QUIC no aplica, y lo que queda es el ahorro de un viaje en el establecimiento y la migración de conexión.