HTTP/1.1 vs HTTP/2 vs HTTP/3
Las tres versiones de HTTP en uso hoy resuelven, cada una, los cuellos de botella de rendimiento de la anterior, cambiando incluso el protocolo de transporte subyacente.
| Año | 1997 | 2015 | 2022 |
| Transporte | TCP | TCP | QUIC (sobre UDP) |
| Multiplexación | No (una petición por conexión, o pipelining limitado) | Sí, varias peticiones en paralelo por conexión | Sí, sin bloqueo de cabeza de línea entre streams |
| Compresión de cabeceras | No | Sí (HPACK) | Sí (QPACK) |
| Establecimiento de conexión | TCP handshake + TLS handshake por separado | Igual que HTTP/1.1 | Combinado, más rápido (0-RTT en reconexiones) |
| Problema que resuelve | — | Head-of-line blocking a nivel de aplicación | Head-of-line blocking a nivel de transporte (TCP) |
HTTP/1.1, publicado en 1997, sigue siendo ampliamente compatible pero arrastra una limitación de diseño: cada conexión TCP solo puede procesar una petición a la vez de forma fiable (el pipelining existía en el papel pero apenas se usó por problemas de implementación). Los navegadores compensaron esto abriendo varias conexiones TCP en paralelo hacia el mismo dominio, con el coste de recursos que eso implica.
HTTP/2 (2015) introdujo la multiplexación real: una sola conexión TCP puede llevar múltiples peticiones y respuestas entrelazadas simultáneamente, eliminando la necesidad de abrir conexiones paralelas. También añadió compresión de cabeceras (HPACK) y server push. El problema que persistió es que, al seguir sobre TCP, si un solo paquete se pierde, TCP bloquea la entrega de todos los streams multiplexados hasta que se retransmite — el llamado head-of-line blocking a nivel de transporte.
HTTP/3 (estandarizado en 2022) ataca ese problema de raíz cambiando el transporte: en lugar de TCP, usa QUIC, un protocolo construido sobre UDP que implementa su propio control de congestión y multiplexa los streams de forma que la pérdida de un paquete solo afecta al stream concreto al que pertenece, no a toda la conexión. QUIC también integra TLS 1.3 directamente en el handshake inicial, reduciendo la latencia de conexión, especialmente notable en redes móviles con pérdida de paquetes frecuente.
En la práctica, casi todo el tráfico web actual usa HTTP/2 como mínimo, y la adopción de HTTP/3 crece rápidamente entre los grandes proveedores (Cloudflare, Google, Meta) por su ventaja en redes inestables. Como desarrollador o administrador de sistemas normalmente no eliges la versión manualmente: navegador y servidor la negocian automáticamente, aunque sí conviene asegurarse de que tu servidor web (Nginx, Caddy) tiene HTTP/2 y, si es posible, HTTP/3 habilitados.
Herramientas relacionadas
Preguntas frecuentes
¿HTTP/3 requiere HTTPS obligatoriamente?
Sí, QUIC integra TLS 1.3 como parte del protocolo, así que no existe una versión sin cifrar de HTTP/3, a diferencia de HTTP/1.1 y HTTP/2 que sí pueden operar en teoría sobre texto plano.
¿Necesito cambiar mi código para aprovechar HTTP/2 o HTTP/3?
Normalmente no: son mejoras a nivel de transporte transparentes para la aplicación. Sí conviene revisar prácticas antiguas pensadas para HTTP/1.1, como concatenar assets para reducir peticiones, que pierden sentido con multiplexación real.
¿Todos los navegadores soportan HTTP/3?
Los navegadores modernos (Chrome, Firefox, Edge, Safari reciente) lo soportan, aunque algunas redes corporativas bloquean UDP en el puerto 443, forzando una caída automática a HTTP/2 sobre TCP.
Otras comparativas