HTTP/3 y QUIC

Durante treinta años, el tráfico HTTP viajó sobre TCP, el protocolo que garantiza que los bytes lleguen completos y en orden. QUIC reemplaza a TCP para la web. Empezó en Google alrededor de 2012 y la IETF lo estandarizó en 2021 (RFC 9000); corre arriba de UDP y reconstruye por su cuenta la confiabilidad, el orden y el control de congestión, en un software que navegadores y servidores pueden actualizar rápido. HTTP/3 (RFC 9114, 2022) es simplemente HTTP transportado sobre QUIC.

La primera ganancia es el bloqueo de cabeza de línea (head-of-line blocking). HTTP/2 ya mandaba muchos archivos a la vez por una sola conexión TCP, pero TCP ve un único chorro de bytes: si se pierde un paquete, todo lo que viene atrás espera, aunque sean datos de imágenes que no tienen nada que ver. QUIC conoce los streams por separado, así que un paquete perdido frena solo al suyo. En redes móviles y Wi-Fi con pérdidas, la diferencia se nota.

La segunda es el tiempo de arranque. TCP más TLS necesitan un par de idas y vueltas antes del primer byte útil; QUIC mete el cifrado (TLS 1.3) en su propio saludo inicial, así que una conexión nueva suele tardar una sola ida y vuelta, y un cliente que vuelve a veces puede mandar datos de entrada (0-RTT, con algunos reparos por ataques de repetición). Casi todo en QUIC va cifrado, incluida buena parte del encabezado que antes inspeccionaban los equipos intermedios.

Tercero, una conexión QUIC se identifica con un connection ID, no con la dirección IP y el puerto, así que sobrevive a que tu celular pase del Wi-Fi al 5G. Hoy Chrome, Firefox y Safari hablan HTTP/3, y Google, Meta y Cloudflare sirven buena parte de su tráfico así. El navegador se entera de que un sitio lo soporta por un encabezado Alt-Svc o un registro de DNS, y vuelve a HTTP/2 sobre TCP cuando un firewall bloquea UDP.