HTTP/3 y QUIC: el futuro del protocolo web
Dedicados & VPS
23

De HTTP/1 a HTTP/3 en pocos años

Durante casi dos décadas, la web se sirvió sobre HTTP/1.1: texto plano sobre TCP, una petición por conexión (o pipelining con muchos peros). En 2015 llegó HTTP/2, que introdujo multiplexing y compresión de cabeceras. Y ahora, con HTTP/3, el cambio es todavía más radical: cambia la capa de transporte por debajo. Ya no usa TCP. Usa UDP, a través de un protocolo llamado QUIC.

Qué es QUIC

QUIC es un protocolo de transporte moderno creado originalmente en Google y estandarizado por la IETF. Corre sobre UDP porque TCP está tan ossificado por routers y middleboxes que era imposible evolucionarlo. QUIC combina en una sola capa:

  • Confiabilidad (retransmisiones y orden, como TCP).
  • Cifrado obligatorio (TLS 1.3 integrado, no es opcional).
  • Control de congestión configurable.
  • Multiplexing real sin head-of-line blocking.

El problema del head-of-line blocking

En HTTP/2 sobre TCP, varios streams viajan en paralelo dentro de una misma conexión. Pero si un paquete TCP se pierde, toda la conexión se detiene hasta que el paquete llegue, aunque los otros streams estén listos. Es el famoso head-of-line blocking, y en redes móviles con pérdida de paquetes se nota muchísimo.

QUIC soluciona esto porque cada stream es independiente a nivel de transporte. Si un paquete de un stream se pierde, los demás siguen avanzando sin esperarlo. Para usuarios en 4G, 5G o wifi inestable, la diferencia puede ser enorme.

Ventajas prácticas

  • Menos latencia al conectar: el handshake de QUIC combina conexión y TLS en un solo ida y vuelta, o incluso en cero con 0-RTT para clientes que ya conocen el servidor.
  • Migración de conexión: si tu celular salta de wifi a 4G, la conexión sobrevive porque QUIC identifica la sesión por un ID, no por la IP del cliente.
  • Mejor rendimiento en redes móviles, donde la pérdida de paquetes es común.

Quién lo soporta

Chrome, Firefox, Safari y Edge soportan HTTP/3 desde hace varias versiones. Del lado del servidor, Cloudflare lo activó globalmente, Caddy lo habilita por defecto, y Nginx lo soporta desde la versión 1.25 de forma estable. Apache todavía va más lento con el soporte oficial, aunque hay módulos de terceros.

Cómo activarlo en Nginx

Necesitas Nginx 1.25 o superior, compilado con OpenSSL que soporte QUIC. En tu bloque de server añades una directiva para abrir QUIC en UDP:

server {
    listen 443 quic reuseport;
    listen 443 ssl;
    http2 on;

    ssl_certificate     /etc/ssl/fullchain.pem;
    ssl_certificate_key /etc/ssl/privkey.pem;

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

    server_name tu-dominio.com;
    # ... resto de tu config
}

El reuseport es importante porque QUIC depende de balanceo por socket. La cabecera Alt-Svc le dice al navegador que ese dominio también está disponible sobre HTTP/3 y puede intentar usarlo en la próxima visita.

Firewall y UDP

No olvides abrir el puerto UDP 443 en tu firewall. Mucha gente se traba aquí porque por costumbre solo tiene TCP 443 abierto. Sin UDP abierto, los navegadores harán fallback silencioso a HTTP/2 y no notarás nada raro salvo que no sentirás la mejora.

¿Vale la pena?

Para sitios con usuarios en móvil o con audiencia global, sí. La mejora de latencia y la resistencia a redes inestables se nota. Para una app interna de oficina, el impacto es marginal. Y como el fallback es transparente, activarlo no rompe nada: simplemente los clientes compatibles van más rápido.