Cada solicitud HTTP que sirve su API se basa en una capa de transporte en la que la mayoría de los desarrolladores nunca piensan. Durante 25 años, la respuesta fue TCP. Luego, Google se cansó de esperar a que TCP mejorara, construyó el protocolo QUIC sobre UDP, y el IETF lo convirtió en un estándar. HTTP/3 es la versión de HTTP creada para funcionar sobre él.
Eso suena a fontanería. En su mayor parte lo es. Pero esta fontanería cambia la rapidez con la que su API se conecta, cómo se comporta en redes móviles inestables y cómo las solicitudes paralelas comparten una conexión. Si diseña u opera APIs, debe saber qué cambió, qué no y cómo verificar qué utilizan sus propios endpoints hoy en día.
Una cosa permanece constante en todo esto: sus solicitudes, respuestas, códigos de estado y cargas útiles JSON se ven idénticos en HTTP/1.1, HTTP/2 y HTTP/3. Herramientas como Apidog prueban y depuran en la capa API, por lo que todo lo que valida sobre el comportamiento de un endpoint es válido sin importar qué versión de transporte negocie su infraestructura por debajo. Si ya ha leído nuestro desglose de qué es HTTP/2 y cómo probar APIs HTTP/2, este artículo retoma el tema donde aquel termina.
¿Qué es el protocolo QUIC?
QUIC es un protocolo de transporte estandarizado en RFC 9000. Se ejecuta sobre UDP en lugar de TCP, y reconstruye las características que TCP proporciona (fiabilidad, ordenación, control de congestión) en el espacio de usuario, por cada flujo, con cifrado integrado desde el primer paquete.
Cuatro decisiones de diseño lo definen:
Se ejecuta sobre UDP. TCP se implementa en los núcleos de los sistemas operativos y en los middleboxes de todo internet, lo que hace que sea casi imposible de evolucionar. UDP es una envoltura delgada sin garantías de entrega, por lo que QUIC construye su propia capa de fiabilidad encima y puede enviar mejoras como actualizaciones de biblioteca en lugar de actualizaciones del sistema operativo.
TLS 1.3 está integrado, no superpuesto. Con TCP, se completa un handshake de TCP y luego un handshake de TLS separado encima. QUIC los fusiona. La configuración criptográfica ocurre dentro del propio handshake de transporte, por lo que una nueva conexión segura está lista después de un solo viaje de ida y vuelta. No existe el QUIC sin cifrar.
Los flujos son independientes. Una conexión QUIC transporta muchos flujos, y cada uno se entrega de forma independiente. Un paquete perdido solo detiene el flujo al que pertenece. Esta es la solución al problema de bloqueo de cabecera de línea (head-of-line blocking) de TCP, al que llegaremos en un momento.
Las conexiones sobreviven a los cambios de red. TCP identifica una conexión por dirección IP y puerto. Cambie cualquiera de ellos (salga del alcance de Wi-Fi, cambie a 5G) y la conexión muere. QUIC identifica las conexiones por un ID de conexión en su lugar, por lo que un cliente puede moverse a una nueva red y mantener viva la misma conexión lógica. Sin reconexión, sin nuevo handshake.
HTTP/3, definido en RFC 9114, es el mapeo de la semántica HTTP a los flujos QUIC. Mismos métodos, mismos encabezados, mismos códigos de estado. Diferente formato de cable, diferente transporte.
HTTP/3 vs HTTP/2: qué cambió en la práctica
HTTP/2 fue un gran avance sobre HTTP/1.1. Introdujo la multiplexación, de modo que muchas solicitudes podían compartir una única conexión TCP en lugar de hacer cola o abrir seis sockets paralelos. Pero mantuvo TCP por debajo, y eso creó un problema que HTTP/2 no pudo resolver por sí mismo.
TCP garantiza la entrega ordenada de un único flujo de bytes. Cuando se pierde un paquete, TCP retiene todos los bytes posteriores hasta que llega la retransmisión, incluso los bytes que pertenecen a flujos HTTP/2 completamente no relacionados. Un paquete perdido congela las 20 solicitudes multiplexadas en la conexión. Eso es el bloqueo de cabecera de línea a nivel de transporte, y en una red con pérdidas puede hacer que HTTP/2 sea más lento que HTTP/1.1 con sus múltiples conexiones.
HTTP/3 elimina el flujo de bytes compartido. Cada solicitud se asigna a su propio flujo QUIC con su propio orden de entrega. Si se pierde un paquete que transporta el flujo 5, los flujos del 6 al 24 siguen fluyendo. La multiplexación finalmente funciona como siempre afirmaron los diagramas de HTTP/2.
La matemática del handshake también cambió:
| HTTP/2 sobre TCP+TLS 1.3 | HTTP/3 sobre QUIC | |
|---|---|---|
| Configuración de 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 (0-RTT) |
| Impacto de paquete perdido | Bloquea todos los flujos | Bloquea un flujo |
| Cambio de red (Wi-Fi a 5G) | La conexión muere, reconexión completa | La conexión migra, continúa |
| Cifrado | Opcional en teoría, capa separada | Obligatorio, TLS 1.3 integrado |
La fila de 0-RTT merece una advertencia. Cuando un cliente se reconecta a un servidor que ya ha visto, QUIC le permite enviar datos de la aplicación en el primer paquete, antes de que se complete el handshake. Excelente para la latencia. Pero los datos de 0-RTT pueden ser capturados y reproducidos por un atacante, por lo que los servidores solo deben aceptar solicitudes idempotentes en 0-RTT. Un GET reproducido es inofensivo. Un POST reproducido que carga una tarjeta de crédito no lo es. Si habilita 0-RTT en su edge, asegúrese de que las llamadas API no idempotentes estén excluidas, o confirme que su CDN lo haga por usted.
Qué significa HTTP/3 para sus APIs
Las actualizaciones de protocolo solo importan si cambian algo que se pueda medir. Aquí es donde HTTP/3 marca la diferencia para el tráfico de API, y dónde no.
La configuración de conexión se vuelve más económica
Un cliente móvil típico en una conexión con un RTT de 60 ms gasta alrededor de 120 ms en la configuración de TCP+TLS antes de que la primera solicitud de API siquiera salga del dispositivo. HTTP/3 reduce eso a unos 60 ms, y casi a cero en la reanudación. Para una API llamada desde una aplicación móvil que abre conexiones nuevas con frecuencia (arranques en frío, activaciones en segundo plano, sesiones de corta duración), el ahorro se aplica a cada una de esas primeras solicitudes. Para una integración de servidor a servidor que mantiene un pool de conexiones "calientes", el handshake se amortiza hasta la irrelevancia y no notará nada.
Los clientes móviles dejan de perder conexiones
La migración de conexión es la característica "dormida" para los equipos de API. Un usuario inicia una solicitud en la Wi-Fi de la oficina, camina hacia el ascensor y el teléfono salta a la red celular. Sobre TCP, esa solicitud en curso falla y su lógica de reintento del lado del cliente (¿tiene lógica de reintento, verdad?) entra en acción con una reconexión completa. Sobre QUIC, la conexión sigue al dispositivo a la nueva red. Menos errores de tiempo de espera en sus registros de cliente, menos escrituras a medio completar de las que preocuparse.
Multiplexación sin el modo de falla
Para las APIs REST, la solución al bloqueo HOL es más importante cuando un cliente lanza muchas solicitudes en paralelo: un dashboard que hidrata 15 widgets, un motor de sincronización que empuja un lote de actualizaciones. En una red limpia, HTTP/2 y HTTP/3 funcionan de manera similar. Añada una pérdida de paquetes del 1-2% (Wi-Fi de conferencias abarrotadas, celular en el metro), y HTTP/3 mantiene las solicitudes paralelas independientes mientras que HTTP/2 las detiene al unísono.
gRPC se mantiene mayormente en HTTP/2 por ahora
gRPC está vinculado a HTTP/2 por diseño; su contrato de cableado depende del framing y los trailers de HTTP/2. El ecosistema gRPC no ha estandarizado un mapeo para HTTP/3, y las implementaciones principales (Go, Java, Python, Node) no lo incluyen. El servidor Kestrel de .NET puede servir gRPC sobre HTTP/3 como una capacidad experimental, pero considérelo una excepción. Si su arquitectura se basa en gRPC y HTTP/2 para el rendimiento de la API interna, una migración a HTTP/3 no es algo que deba planificar este año.
Tráfico de streaming y en tiempo real
Los Server-Sent Events funcionan sobre HTTP/3 sin cambios, ya que SSE es una respuesta HTTP ordinaria de larga duración. Los WebSockets son más complicados: la actualización de WebSocket fue diseñada para TCP, y su equivalente en HTTP/3 (RFC 9220, más la API WebTransport emergente) tiene un soporte irregular. Si está sopesando WebSockets frente a HTTP plano para una función en tiempo real, la disponibilidad de HTTP/3 no debería ser el factor decisivo todavía.
La parte honesta: cuando HTTP/3 no ayudará
La mayoría de los problemas de latencia de las API no tienen nada que ver con el protocolo de transporte. Si su endpoint tarda 400 ms debido a una consulta de base de datos sin indexar, HTTP/3 entregará esa respuesta lenta 60 ms antes. El almacenamiento en caché, el diseño de la carga útil, las consultas N+1 y la reutilización de conexiones dominan el rendimiento real de las API, y debe agotar esas opciones antes de pensar en el transporte. Una prueba de rendimiento de API estructurada generalmente arrojará mejoras 10 veces mayores que una actualización de protocolo.
HTTP/3 brilla en condiciones específicas:
- Enlaces de alta latencia, donde ahorrar viajes de ida y vuelta representa una ganancia porcentual fija
- Redes con pérdidas, donde la eliminación del bloqueo HOL se agrava
- Clientes móviles que cambian de red a mitad de sesión
- Muchas conexiones cortas en lugar de pocas y largas
Para una API JSON típica consumida por servidores en la misma región a través de redes fiables, la diferencia es medible en benchmarks e invisible para los usuarios. Otras dos notas prácticas: el puerto UDP 443 está bloqueado en algunas redes corporativas (los clientes recurren a HTTP/2 automáticamente, por lo que nada se rompe), y el cifrado en espacio de usuario de QUIC actualmente cuesta más CPU de servidor por conexión que un TCP de kernel optimizado.
Soporte actual: quién usa HTTP/3 hoy
La adopción está más avanzada de lo que la mayoría de los desarrolladores de backend suponen:
- Navegadores: Chrome, Edge, Firefox y Safari incluyen HTTP/3 habilitado por defecto.
- CDNs y edges: Cloudflare, Fastly, Akamai y CloudFront lo soportan; en Cloudflare es una opción que se puede activar/desactivar. Para la mayoría de los equipos, este es el camino práctico: terminar HTTP/3 en el edge, mantener HTTP/1.1 o HTTP/2 del edge al origen.
- Servidores: Nginx añadió HTTP/3 experimentalmente en la versión 1.25 con
listen 443 quic;. Caddy lo habilita por defecto. LiteSpeed y HAProxy lo soportan. Apache httpd no. - Entornos de ejecución (Runtimes): Node.js no tiene soporte de servidor HTTP/3 integrado estable, lo cual es otra razón por la que la terminación en el edge es la implementación común.
- curl: lo soporta con la bandera
--http3cuando se compila contra una pila TLS compatible con HTTP/3; consulte la documentación de HTTP/3 de curl para ver qué compilaciones lo incluyen.
Cómo comprobar si su API sirve HTTP/3
El descubrimiento funciona a través del encabezado de respuesta Alt-Svc. Un servidor que anuncia HTTP/3 responde a su primera solicitud (HTTP/2) con algo como:
alt-svc: h3=":443"; ma=86400
Eso le dice al cliente: este mismo servicio está disponible a través de HTTP/3 en el puerto UDP 443 durante las próximas 24 horas. Verifíquelo con curl:
curl -sI https://www.cloudflare.com | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400
Para realizar la solicitud directamente a través de HTTP/3 (requiere una compilación de curl compatible con HTTP/3):
curl --http3 -I https://cloudflare-quic.com
# HTTP/3 200
La línea de estado informa HTTP/3 en lugar de HTTP/2. En las herramientas para desarrolladores de Chrome, abra la pestaña Red, haga clic derecho en el encabezado de la columna, habilite la columna Protocolo y busque h3 junto a sus llamadas API. En producción, añada el protocolo negociado a sus registros de acceso; la división entre el tráfico h2 y h3 le dirá cuántos de sus clientes obtienen el beneficio.
Mientras verifica el transporte, verifique también el comportamiento. Apunte Apidog a los mismos endpoints y valide los códigos de estado, los esquemas de respuesta y los presupuestos de latencia. Las ventajas a nivel de transporte no tienen valor si el contrato API subyacente está roto, y las comprobaciones de contrato son precisamente la capa donde un cambio de protocolo no puede salvarle. Descargue Apidog gratis y ejecute la misma suite de pruebas antes y después de activar HTTP/3 en su edge; la diferencia en los tiempos de respuesta en redes móviles será su respuesta real, no los titulares de los benchmarks.
Preguntas Frecuentes
¿Es HTTP/3 más rápido que HTTP/2?
En redes limpias y de baja latencia: apenas. En redes con pérdidas o de alta latencia: sí, a menudo de forma notable, porque HTTP/3 ahorra un viaje de ida y vuelta de handshake y un solo paquete perdido ya no detiene cada solicitud multiplexada. Mida con su propio perfil de tráfico antes de afirmar la victoria. Y recuerde que HTTP/2 sigue siendo excelente; si encuentra errores de conexión allí, suelen ser problemas de la capa TLS como el problema SSLV3_ALERT_HANDSHAKE_FAILURE en lugar de límites del protocolo.
¿HTTP/3 usa TCP?
No. HTTP/3 se ejecuta sobre QUIC, que a su vez se ejecuta sobre UDP, típicamente en el puerto 443. QUIC reimplementa la fiabilidad, la ordenación y el control de congestión que TCP solía proporcionar, pero por flujo y en espacio de usuario. Si el puerto UDP 443 está bloqueado en una red, los clientes recurren automáticamente a HTTP/2 sobre TCP.
¿Necesito cambiar el código de mi API para HTTP/3?
Casi nunca. La semántica HTTP no cambia: mismos métodos, encabezados, códigos de estado y cuerpos. El trabajo reside en la infraestructura (habilitarlo en su CDN, balanceador de carga o servidor) más una comprobación de diseño: asegúrese de que los datos anticipados 0-RTT estén restringidos a solicitudes idempotentes.
¿Puedo usar gRPC sobre HTTP/3?
En su mayoría no, por ahora. El formato de cable de gRPC está ligado a HTTP/2, y las principales bibliotecas de gRPC no incluyen transportes HTTP/3. .NET tiene soporte experimental. Mantenga los servicios gRPC en HTTP/2 y adopte HTTP/3 donde más rinda primero: endpoints REST públicos, orientados a navegadores y a móviles.