HTTP/3 (QUIC): Qué es y su significado para tus APIs

Cada solicitud HTTP que atiende su API depende de una capa de transporte que la mayoría de los desarrolladores nunca ve. Durante 25 años la respuesta fue TCP; después, Google creó QUIC sobre UDP y el IETF lo convirtió en estándar. HTTP/3 es la versión de HTTP diseñada para funcionar sobre QUIC.

Prueba Apidog hoy

Aunque parezca infraestructura interna, esta capa afecta la velocidad de conexión, el comportamiento en redes móviles inestables y la forma en que las solicitudes paralelas comparten una conexión. Si diseña u opera APIs, conviene saber qué cambió, qué no y cómo comprobar qué protocolo usan sus endpoints.

La semántica de la API permanece igual en HTTP/1.1, HTTP/2 y HTTP/3: solicitudes, respuestas, códigos de estado y cargas JSON no cambian. Herramientas como Apidog siguen siendo válidas para probar y depurar endpoints, independientemente del transporte negociado. Si ya leyó qué es HTTP/2 y cómo probar APIs HTTP/2, este artículo continúa desde allí.

¿Qué es QUIC?

QUIC es un protocolo de transporte estandarizado en RFC 9000. Funciona sobre UDP y reconstruye en el espacio de usuario las capacidades que TCP proporciona —fiabilidad, ordenación y control de congestión—, pero por flujo y con cifrado integrado desde el primer paquete.

Sus cuatro decisiones de diseño principales son:

• UDP como base: TCP está implementado en kernels y middleboxes de todo Internet, lo que dificulta su evolución. UDP es una capa delgada sin garantías de entrega; QUIC añade su propia fiabilidad y puede evolucionar mediante actualizaciones de biblioteca.
• TLS 1.3 integrado: TCP y TLS requieren handshakes separados. QUIC los combina, por lo que una conexión segura nueva queda lista después de un solo viaje de ida y vuelta. No existe QUIC sin cifrado.
• Flujos independientes: una conexión QUIC transporta varios flujos que se entregan de forma independiente. La pérdida de un paquete solo detiene el flujo afectado.
• Migración de conexión: TCP identifica una conexión mediante IP y puerto. QUIC utiliza un ID de conexión, de modo que un cliente puede pasar de Wi-Fi a 5G sin cerrar la conexión lógica ni repetir el handshake.

HTTP/3 es el mapeo de la semántica HTTP a los flujos QUIC: mismos métodos, encabezados y códigos de estado, pero distinto transporte y formato de cable.

HTTP/3 frente a HTTP/2

HTTP/2 introdujo la multiplexación: varias solicitudes podían compartir una conexión TCP. Sin embargo, TCP garantiza la entrega ordenada de un único flujo de bytes. Cuando se pierde un paquete, retiene todos los bytes posteriores hasta recibir la retransmisión, incluso si pertenecen a flujos HTTP/2 no relacionados.

Así aparece el bloqueo de cabecera de línea (head-of-line blocking, HOL): un paquete perdido puede congelar las 20 solicitudes multiplexadas de una conexión. En redes con pérdidas, HTTP/2 puede terminar siendo más lento que HTTP/1.1 con varias conexiones.

HTTP/3 elimina ese flujo de bytes compartido. Cada solicitud usa su propio flujo QUIC:

• Si se pierde un paquete del flujo 5, los flujos 6 a 24 continúan.
• Las solicitudes paralelas permanecen independientes.
• La multiplexación funciona como se esperaba, incluso durante una pérdida de paquetes.

Comparación práctica

Situación	HTTP/2 sobre TCP + TLS 1.3	HTTP/3 sobre QUIC
Nueva conexión	2 viajes de ida y vuelta (TCP + TLS)	1 viaje de ida y vuelta
Conexión reanudada	1 viaje de ida y vuelta	0 viajes de ida y vuelta con 0-RTT
Paquete perdido	Bloquea todos los flujos	Bloquea un flujo
Cambio de Wi-Fi a 5G	La conexión muere y debe reconectarse	La conexión migra y continúa
Cifrado	Opcional en teoría, como capa separada	Obligatorio, TLS 1.3 integrado

Precaución con 0-RTT

Cuando un cliente se reconecta a un servidor conocido, QUIC puede enviar datos de aplicación en el primer paquete, antes de completar el handshake. Esto reduce la latencia, pero esos datos pueden capturarse y reproducirse.

Por eso, los servidores deben aceptar en 0-RTT únicamente solicitudes idempotentes:

• Un GET reproducido normalmente es inofensivo.
• Un POST reproducido que procesa un pago puede ser peligroso.

Si activa 0-RTT en su edge, excluya las llamadas no idempotentes o confirme que su CDN ya lo hace.

Qué cambia HTTP/3 en sus APIs

Las actualizaciones de protocolo solo importan cuando producen mejoras medibles. HTTP/3 ayuda especialmente en estos escenarios.

Conexiones nuevas más económicas

En una conexión móvil con un RTT de 60 ms, TCP + TLS puede consumir unos 120 ms antes de enviar la primera solicitud. HTTP/3 reduce la configuración a aproximadamente 60 ms y puede acercarla a cero al reanudar una conexión.

El ahorro se nota en aplicaciones móviles que abren conexiones con frecuencia:

• Arranques en frío.
• Activaciones en segundo plano.
• Sesiones cortas.

En una integración servidor a servidor con un pool de conexiones calientes, el handshake se amortiza y la diferencia será mínima.

Menos conexiones perdidas en móviles

Un usuario puede iniciar una solicitud en la Wi-Fi de la oficina y pasar a la red celular en un ascensor. Con TCP, la solicitud en curso falla y el cliente debe reconectar. Con QUIC, la conexión sigue al dispositivo hacia la nueva red.

Esto reduce:

• Timeouts en los clientes.
• Reconexiones completas.
• Solicitudes parcialmente procesadas.
• Complejidad de la lógica de reintentos.

Multiplexación sin el peor caso de HOL

La ventaja es mayor cuando el cliente realiza muchas solicitudes paralelas: por ejemplo, un dashboard que carga 15 widgets o un motor de sincronización que envía un lote de actualizaciones.

En una red limpia, HTTP/2 y HTTP/3 suelen comportarse de forma parecida. Con una pérdida de paquetes del 1–2 % —como en una Wi-Fi saturada o en el metro— HTTP/3 mantiene las solicitudes independientes, mientras HTTP/2 puede detenerlas simultáneamente.

gRPC continúa principalmente en HTTP/2

gRPC y HTTP/2 para el rendimiento de la API interna están estrechamente vinculados: el contrato de gRPC depende del framing y los trailers de HTTP/2.

El ecosistema gRPC todavía no tiene un mapeo HTTP/3 estandarizado en sus principales implementaciones de Go, Java, Python y Node. Kestrel de .NET puede servir gRPC sobre HTTP/3 como capacidad experimental, pero sigue siendo una excepción.

Si su arquitectura usa gRPC y HTTP/2 para el rendimiento interno, no necesita priorizar una migración a HTTP/3. Empiece por endpoints REST públicos orientados a navegadores y móviles.

Streaming y tiempo real

Los Server-Sent Events funcionan sobre HTTP/3 sin cambios porque son respuestas HTTP de larga duración.

Los WebSockets son más complicados: su actualización original fue diseñada para TCP. El equivalente para HTTP/3, definido en RFC 9220 junto con la API WebTransport emergente, aún tiene soporte irregular. Si compara WebSockets frente a HTTP plano, la disponibilidad de HTTP/3 todavía no debería ser el factor decisivo.

Cuándo HTTP/3 no ayudará

La mayoría de los problemas de latencia de una API no están en el transporte. Si un endpoint tarda 400 ms por una consulta sin índice, HTTP/3 solo entregará esa respuesta lenta unos 60 ms antes.

Antes de cambiar de protocolo, revise:

• Caché.
• Diseño de la carga útil.
• Consultas N+1.
• Reutilización de conexiones.
• Consultas y dependencias externas.
• Tiempo de procesamiento del servidor.

Una prueba de rendimiento de API estructurada suele producir mejoras mucho mayores que una actualización de transporte.

HTTP/3 brilla especialmente en:

• Enlaces de alta latencia, donde cada viaje de ida y vuelta importa.
• Redes con pérdidas, donde HOL tiene mayor impacto.
• Clientes móviles que cambian de red durante una sesión.
• Muchas conexiones cortas en lugar de pocas conexiones largas.

Para una API JSON consumida por servidores de la misma región mediante redes fiables, la diferencia puede ser medible en benchmarks pero invisible para los usuarios.

Dos detalles operativos adicionales:

• Algunas redes corporativas bloquean UDP 443. En ese caso, los clientes suelen recurrir automáticamente a HTTP/2, sin romper la conexión.
• El cifrado de QUIC en espacio de usuario puede consumir más CPU por conexión que un TCP optimizado en el kernel.

Soporte actual

La adopción de HTTP/3 está más avanzada de lo que muchos equipos backend suponen:

• Navegadores: Chrome, Edge, Firefox y Safari lo incluyen habilitado por defecto.
• CDN y edge: Cloudflare, Fastly, Akamai y CloudFront lo soportan. En Cloudflare puede activarse o desactivarse. El patrón más práctico es terminar HTTP/3 en el edge y mantener HTTP/1.1 o HTTP/2 entre el edge y el origen.
• Servidores: Nginx añadió soporte experimental en la versión 1.25 mediante listen 443 quic;. Caddy lo habilita por defecto. LiteSpeed y HAProxy también lo soportan; Apache httpd no.
• Runtimes: Node.js todavía no ofrece soporte de servidor HTTP/3 integrado y estable, otra razón para terminar el protocolo en el edge.
• curl: admite --http3 cuando se compila con una pila TLS compatible. Consulte la documentación de HTTP/3 de curl para comprobar qué compilaciones lo incluyen.

Cómo comprobar si su API sirve HTTP/3

El descubrimiento suele hacerse mediante el encabezado Alt-Svc. Un servidor que anuncia HTTP/3 puede responder a la primera solicitud —normalmente HTTP/2— con:

alt-svc: h3=":443"; ma=86400

Esto indica al cliente que el mismo servicio está disponible mediante HTTP/3 en UDP 443 durante las próximas 24 horas.

Compruébelo con curl:

curl -sI https://www.cloudflare.com | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400

Para realizar la solicitud directamente mediante HTTP/3 —requiere una compilación compatible—:

curl --http3 -I https://cloudflare-quic.com
# HTTP/3 200

La línea de estado mostrará HTTP/3 en lugar de HTTP/2. También puede verificarlo en Chrome:

1. Abra DevTools y vaya a Red.
2. Haga clic derecho en los encabezados de las columnas.
3. Active Protocolo.
4. Busque h3 junto a sus llamadas API.

En producción, registre el protocolo negociado. La proporción entre tráfico h2 y h3 mostrará cuántos clientes reciben el beneficio.

Mientras verifica el transporte, valide también el comportamiento de la API. Apunte Apidog a los mismos endpoints y compruebe:

• Códigos de estado.
• Esquemas de respuesta.
• Presupuestos de latencia.
• Contratos y casos de error.

Las mejoras del transporte no sirven si el contrato API está roto. Puede descargar Apidog y ejecutar la misma suite de pruebas antes y después de activar HTTP/3 en el edge. Compare los resultados, especialmente desde redes móviles.

Preguntas frecuentes

¿HTTP/3 es más rápido que HTTP/2?

En redes limpias y de baja latencia, apenas. En redes con pérdidas o alta latencia, suele ser notablemente más rápido porque reduce un viaje de ida y vuelta del handshake y evita que un paquete perdido detenga todos los flujos multiplexados.

Mida con su propio tráfico antes de sacar conclusiones. HTTP/2 sigue siendo una excelente opción; los errores de conexión suelen pertenecer a TLS, como el problema SSLV3_ALERT_HANDSHAKE_FAILURE, no a un límite del protocolo HTTP/2.

¿HTTP/3 usa TCP?

No. HTTP/3 usa QUIC, que funciona sobre UDP, normalmente en el puerto 443. QUIC reimplementa la fiabilidad, la ordenación y el control de congestión de TCP, pero por flujo y en espacio de usuario.

Si una red bloquea UDP 443, los clientes suelen recurrir automáticamente a HTTP/2 sobre TCP.

¿Necesito cambiar el código de mi API?

Casi nunca. Los métodos, encabezados, códigos de estado y cuerpos no cambian. El trabajo se realiza en la infraestructura: CDN, balanceador de carga o servidor.

La única comprobación de diseño importante es restringir los datos anticipados de 0-RTT a solicitudes idempotentes.

¿Puedo usar gRPC sobre HTTP/3?

Por ahora, en su mayoría no. El formato de cable de gRPC está ligado a HTTP/2 y las principales bibliotecas no incluyen transportes HTTP/3 estables. .NET ofrece soporte experimental.

Mantenga los servicios gRPC en HTTP/2 y adopte HTTP/3 primero en endpoints REST públicos orientados a navegadores y móviles.