HTTP/2 vs HTTP/3 ¿Qué realmente cambió (y si tu API lo presta)?

Respuesta breve: si estás detrás de un CDN, probablemente ya esté gestionado para ti y no hay nada que configurar. Si ejecutas tu propio servidor, HTTP/2 cubre el caso de 95% y HTTP/3 es una actualización útil, aunque no urgente.

Aquí está la versión más larga, porque el aspecto técnico detrás de la diferencia es realmente interesante — y conocerlo te ayuda a tomar decisiones mejores sobre dónde realmente importa la versión del protocolo.

Qué solucionó realmente HTTP/2

HTTP/1.1 tenía dos problemas que HTTP/2 resolvió adecuadamente.

Demasiadas conexiones TCP para cargar una sola página. Los navegadores abrían entre 6 y 8 conexiones TCP por origen solo para obtener activos en paralelo. Cada conexión tiene un costo de configuración (handshake TCP, negociación TLS), y este enfoque era ineficiente a escala. HTTP/2 reemplazó esto con multiplexado: una sola conexión TCP, múltiples flujos de solicitud y respuesta ejecutándose en paralelo. Ya no hay más juggle de conexiones.

Encabezados redundantes en cada solicitud. En HTTP/1.1, cada solicitud enviaba sus encabezados completos — User-Agent, Accept-Encoding, Authorization, todos ellos — incluso cuando no había cambios respecto a la solicitud anterior. El compresor HPACK de HTTP/2 deduplica los encabezados manteniendo una tabla compartida entre cliente y servidor. En una API donde se envía el mismo Authorization: Bearer ... token en cada llamada, esto reduce significativamente el costo en tráfico de alto volumen.

El servidor push estaba supuesto ser un tercer beneficio (enviar recursos que el cliente necesitaría antes de pedirlos), pero nunca funcionó realmente en la práctica. Chrome eliminó el soporte en 2022. Trátalo como desactualizado y no construyas nada sobre él.

El problema que HTTP/2 no pudo solucionar

Aquí está la parte que a menudo se omite: el multiplexado sobre TCP tiene un techo rígido. Cuando un paquete TCP se pierde en tránsito, TCP pone en pausa toda la conexión hasta que el paquete se retransmite y se confirma. Todos tus flujos HTTP/2 paralelos — independientemente de cuál era el paquete perdido — quedan inactivos esperando. Esto es bloqueo de cabeza en nivel TCP (HOL), y no es un error en HTTP/2 — es cómo funciona TCP.

En una conexión por cable confiable, la tasa de pérdida de paquetes es baja suficiente para que esto rara vez cause problemas. Pero en redes móviles, en enlaces por satélite o en cualquier camino con pérdida significativa de paquetes, la ventaja de multiplexado de HTTP/2 se colapsa. Puedes tener 20 flujos multiplexados sobre una sola conexión, y un solo paquete perdido bloquea los 20. 😬

Este no es un límite que se pueda solucionar. Es estructural al construir un protocolo de multiplexado de solicitudes sobre un transporte de bytes que no sabe qué es un "flujo".

Qué cambió realmente HTTP/3

HTTP/3 no solo ajusta el formato de marco o agrega una nueva bandera. Reemplaza TCP con QUIC — un protocolo de transporte que funciona sobre UDP.

QUIC maneja el multiplexado en el nivel de transporte, por lo que un paquete perdido solo bloquea el flujo al que pertenece, no todos los demás flujos en la conexión. El problema de bloqueo de cabeza se soluciona en el nivel adecuado de la pila. Eso es lo esencial.

Algunas otras cosas que trae QUIC:

• Migración de conexión. QUIC identifica las conexiones mediante un ID de conexión, no mediante una cuadrupla de IP fuente, puerto fuente, IP destino, puerto destino. Cambiar de Wi-Fi a red móvil durante una transferencia y la conexión sigue viva. Esto importa para aplicaciones móviles; para llamadas entre servidores es prácticamente irrelevante.
• Handshakes de 0-RTT. Para conexiones a servidores conocidos, QUIC puede omitir la negociación TLS de un viaje y enviar datos inmediatamente. Ganancia real de latencia en re-conexiones. Nota: el 0-RTT tiene una advertencia de ataque de retransmisión — no utilízalo para endpoints no idempotentes sin comprender los riesgos.
• TLS 1.3 obligatorio. QUIC no soporta conexiones sin cifrado. No hay HTTP/3 sin TLS, punto final.

La compresión de encabezados también cambió: HTTP/3 utiliza QPACK en lugar de HPACK. La diferencia es técnica — QPACK evita un problema de bloqueo en HPACK cuando los encabezados se comprimen entre flujos. En la práctica, no observarás una diferencia; es una mejora de infraestructura.

Comparación de características

Característica	HTTP/1.1	HTTP/2	HTTP/3
Protocolo de transporte	TCP	TCP	QUIC (UDP)
Multiplexado de solicitudes	No (múltiples conexiones)	Sí	Sí
Bloqueo de cabeza	Nivel de solicitud	Nivel de TCP (aún presente)	Ninguno
Compresión de encabezados	Ninguno	HPACK	QPACK
TLS requerido	No	No (especificación), sí (navegadores)	Sí (obligatorio)
Handshake de 0-RTT	No	No	Sí
Migración de conexión	No	No	Sí
Servidor push	No	Sí (desactualizado)	No (eliminado)

Qué significa esto para la latencia de API

HTTP/3 ayuda más en condiciones específicas. No mejora universalmente todo.

Redes con pérdida de paquetes. Los clientes móviles que acceden a tu API sobre LTE o 5G con cobertura subóptima verán una mejora medible. Las llamadas entre datacenters en una red privada confiable donde la pérdida de paquetes es efectivamente cero? La diferencia es insignificante.

Conexiones frías y re-conexiones. Si tus clientes de API se reconectan frecuentemente — funciones serverless de corta duración, reinicios de aplicaciones móviles, contenedores transitorios — el 0-RTT reduce el costo de configuración. Las conexiones largas que permanecen abiertas durante minutos no obtienen beneficio de esto.

El volumen de solicitudes importa. HTTP/2 y HTTP/3 brillan cuando un cliente realiza muchas solicitudes paralelas. Un navegador cargando 80 activos en paralelo obtiene grandes ganancias con multiplexado. Una API REST que realiza 3 solicitudes secuenciales obtiene ganancias mucho más pequeñas. Cuanto más solicitudes concurrentes emita tu cliente, tanto más importan las mejoras del transporte.

Cómo manejan los CDNs esto

Cloudflare ha soportado HTTP/3 desde 2019 y lo habilita por defecto. AWS CloudFront agregó soporte en 2022. Fastly, Akamai, BunnyCDN — todos lo soportan.

La arquitectura importa aquí: tu CDN termina la conexión del cliente en su borde. Aunque un cliente se conecte a tu CDN mediante HTTP/3 usando QUIC, el tramo de CDN a origen es casi seguramente HTTP/1.1 o HTTP/2 sobre TCP. Por lo tanto, "habilitar HTTP/3" en tu CDN no requiere cambios en tu servidor de origen.

Si estás en Cloudflare, revisa tus ajustes de Velocidad → Optimización: HTTP/3 (con QUIC) está habilitado por defecto para la mayoría de las zonas. Otros CDNs varían. Este es el cambio de mayor impacto que pueden hacer la mayoría de los equipos: sin cambios en el origen, beneficio inmediato para clientes en redes móviles o de alta latencia.

¿Deberías hacer realmente algo?

Detrás de un CDN: Verifica que HTTP/3 esté habilitado y continúa. Toma 30 segundos.

Ejecutando tu propio nginx: HTTP/3 requiere nginx 1.25+ (la rama principal — la estable está rezagada en QUIC). Necesitarás el --with-http_v3_module flag de compilación y una listen 443 quic reuseport directiva junto con tu listener TCP existente. Asegúrate de que el puerto UDP 443 esté abierto en tu firewall — algunas configuraciones de red lo bloquean. Hacerlo vale la pena si sirves usuarios móviles; no vale la pena la interrupción del upgrade si solo manejas tráfico entre servidores.

Usando Caddy: HTTP/3 está habilitado por defecto sin necesidad de configuración. Nada que hacer.

Construyendo un cliente que llame a APIs de terceros: Si obtienes HTTP/3 depende del servidor que estás llamando, no de tu código. curl soporta HTTP/3 a partir de 7.86.0 con un backend compatible (nghttp3 o quiche). La mayoría de las bibliotecas de cliente en Python y Node aún no lo soportan nativamente. Go no lo tiene en su biblioteca estándar; existe una biblioteca separada si lo necesitas. net/http Una nota práctica: si estás probando qué versión de HTTP un servidor realmente negociará, o construyendo comandos de curl con quic-go flags,

en iotools.cloud es útil para construir el comando adecuado sin tener que buscar cada vez la sintaxis exacta del flag. --http3 HTTP/2 vs HTTP/3: Qué realmente cambió (y si tu API se ve afectada) 2 Generador de Comandos cURL HTTP/2 vs HTTP/3: Qué realmente cambió (y si tu API se ve afectada) 1

También te puede interesar