HTTP/2 vs HTTP/3 (QUIC) — ¿qué problema resuelve realmente cada uno?

#El cuello de botella que HTTP/1.1 nunca resolvió

HTTP/1.1 tiene una regla simple: en una conexión TCP dada, el cliente envía una petición y debe esperar la respuesta completa antes de poder enviar la siguiente (el pipelining —enviar varias peticiones sin esperar— existe técnicamente en el estándar, pero las respuestas igual deben volver en el mismo orden en que se pidieron, y tantos proxies intermedios lo manejaban mal que ningún navegador real llegó a activarlo). Si tu página necesita una hoja de estilos, tres scripts y una docena de imágenes, esa cola de uno en uno se convierte en el cuello de botella.

Los navegadores lo sortearon como pudieron, en la capa de aplicación: abriendo entre 6 y 8 conexiones TCP paralelas por origen, más trucos como el "domain sharding" (servir assets desde img1.example.com, img2.example.com, ...) para multiplicar aún más ese límite. Funcionaba, pero era caro — cada conexión TCP implica su propio handshake, su propia negociación TLS, su propia rampa de control de congestión y su propio trozo de memoria en el servidor. Estabas pagando overhead de la capa de transporte para parchear un problema de encolamiento de la capa de aplicación.

#HTTP/2: multiplexado sobre una sola conexión

HTTP/2 (heredero de SPDY, de Google) reemplaza el formato de texto plano de peticiones/respuestas de HTTP/1.1 por una capa de framing binario. Las peticiones y respuestas se dividen en frames, cada uno etiquetado con un ID de stream, e intercaladas sobre una sola conexión TCP. El servidor puede empezar a enviar la respuesta del stream 3 antes de terminar de enviar la del stream 1 — multiplexado de verdad, sin más cola de uno en uno. También añade compresión de cabeceras (HPACK, porque las cabeceras de las peticiones se repiten muchísimo a lo largo de una carga de página) y priorización de streams.

Esto sí resuelve el problema de head-of-line blocking a nivel de HTTP que describimos arriba. Pero HTTP/2 sigue viajando sobre TCP, y eso resulta importar más de lo que parece.

#El head-of-line blocking que HTTP/2 no pudo arreglar

TCP garantiza una cosa por encima de todo: los bytes llegan a la aplicación exactamente en el orden en que se enviaron, sin saltarse ninguno. Para lograrlo, hace buffer de todo lo que llega después de un hueco y se niega a entregárselo a la aplicación hasta que el segmento perdido se retransmita y llegue. TCP no tiene ningún concepto de "streams" — para el socket del sistema operativo, los frames multiplexados de HTTP/2 son solo un único stream de bytes ordenado.

Entonces, cuando se pierde un solo paquete en cualquier punto del camino, todos los streams de HTTP/2 en esa conexión se detienen, incluso los que llegaron intactos y no tienen nada que ver con el paquete perdido, porque el kernel no libera ningún byte que esté detrás del hueco. Este es head-of-line blocking a nivel de transporte, y ningún truco inteligente en la capa de HTTP puede rodearlo — el problema está una capa más abajo.

#HTTP/3: llevar el multiplexado a la capa de transporte

HTTP/3 conserva la idea de HTTP/2 (frames binarios, streams multiplexados) pero abandona TCP por completo y corre sobre QUIC, un protocolo de transporte construido sobre UDP. QUIC reimplementa la fiabilidad y el orden por su cuenta, pero, y esto es lo importante, lo hace por stream en lugar de para toda la conexión: cada stream de QUIC tiene su propia garantía de entrega, así que un paquete perdido solo detiene al stream al que pertenecía. Todos los demás siguen fluyendo.

QUIC además fusiona dos ganancias que antes eran round trips separados: TLS 1.3 está integrado directamente en el handshake de QUIC en lugar de negociarse después, así que establecer una conexión segura nueva suele costar un único round trip en vez de la secuencia "handshake TCP, luego handshake TLS" que pagan HTTP/1.1 y HTTP/2 — y un cliente que retoma una conexión previa puede enviar datos de aplicación desde el primer paquete (0-RTT), a costa de algunas consideraciones sobre ataques de repetición para peticiones no idempotentes. Las conexiones QUIC además se identifican por un connection ID en lugar de la clásica 4-tupla (IP origen, puerto origen, IP destino, puerto destino), así que un teléfono que salta de Wi-Fi a datos móviles puede mantener viva la misma conexión QUIC — "migración de conexión" — algo simplemente imposible para TCP, que corta la conexión en el instante en que esa 4-tupla cambia.

#Dónde se nota esto en la práctica

El soporte se negocia, no se asume: un servidor anuncia disponibilidad de HTTP/3 mediante una cabecera de respuesta Alt-Svc (por ejemplo Alt-Svc: h3=":443"; ma=86400) o vía ALPN durante el TLS, y un cliente que no puede alcanzarlo por UDP —muchos firewalls corporativos y middleboxes antiguos bloquean o limitan UDP directamente— cae de vuelta a HTTP/2 sin que el usuario lo note. La mayoría de los CDN grandes (Cloudflare, Fastly, Google, Akamai) soportan HTTP/3 hoy, y la mayoría de navegadores modernos lo prefieren automáticamente cuando se les ofrece, pero tu origen igual necesita hablar HTTP/1.1 o HTTP/2 como fallback.

#Cara a cara

🧠 Check your understanding
0/3 · 0/3 answered
1. ¿Qué causa exactamente el head-of-line blocking en HTTP/2 que HTTP/3 evita?
HTTP/2 envía las cabeceras sin comprimirLos navegadores se niegan a abrir más de una conexión HTTP/2Un único paquete TCP perdido bloquea todos los streams multiplexados porque TCP entrega los bytes en un orden estrictoHTTP/2 no soporta framing binario
2. ¿Por qué una conexión QUIC puede sobrevivir a que el cliente pase de Wi-Fi a datos móviles, cuando una conexión TCP no?
QUIC usa exclusivamente IPv6El sistema operativo renegocia automáticamente las conexiones TCPLas conexiones QUIC se identifican con un connection ID en lugar de la 4-tupla (IP origen, puerto origen, IP destino, puerto destino)QUIC no usa direcciones IP en absoluto
3. ¿Qué hace la cabecera Alt-Svc?
Cifra el cuerpo de la respuesta HTTPPermite que un servidor anuncie que hay un protocolo alternativo (como HTTP/3) disponible para futuras peticionesFuerza al cliente a desconectarse inmediatamenteEs obligatoria para el keep-alive de HTTP/1.1