La especificación HTTP/2 representa el salto más grande del protocolo desde 1999. Mantiene la semántica conocida (métodos, cabeceras, códigos) pero rediseña el formato en el que viajan los mensajes para aprovechar al máximo una única conexión TCP. El resultado es una entrega más rápida y predecible incluso en redes móviles congestionadas.
En esta lección comprenderás cómo funciona la multiplexación, qué resuelve la compresión HPACK, por qué las prioridades importan y cómo medir las mejoras frente a HTTP/1.1. También revisaremos la relación con HTTPS, requisito prácticamente universal para que los navegadores habiliten HTTP/2.
HTTP/2 introduce el concepto de streams, canales lógicos numerados que se envían entrelazados sobre el mismo socket TCP. Cada stream viaja en pequeños fragmentos llamados frames, lo que permite que el servidor responda a distintas solicitudes sin respetar el orden de llegada. Con esto desaparece el head-of-line blocking típico del pipelining HTTP/1.1.
En la práctica, un navegador puede descargar HTML, CSS, fuentes y datos JSON usando un solo socket, evitando el costo de abrir múltiples conexiones y maximizando el rendimiento de TLS gracias al reuso del canal cifrado.
Para complementar la multiplexación, HTTP/2 utiliza el algoritmo HPACK. Este mecanismo mantiene tablas de cabeceras estáticas y dinámicas para enviar solo referencias y valores nuevos.
El efecto es notorio en aplicaciones móviles: una cabecera que antes ocupaba cientos de bytes puede reducirse a decenas, liberando espacio para datos útiles y acortando los tiempos de transmisión.
HTTP/2 permite que el cliente declare dependencias entre streams. Cada solicitud se puede marcar con un peso (1 a 256) e indicar de qué flujo depende. El servidor usa esa información para decidir qué frames enviar primero cuando el ancho de banda es limitado.
Estrategias comunes:
Esta capacidad reduce el tiempo hasta el Largest Contentful Paint (LCP) porque asegura que los bytes más valiosos lleguen primero.
Al consolidar múltiples streams en un socket, HTTP/2 minimiza los handshakes TCP y TLS. Esto se traduce en menores tiempos de ida y vuelta (RTT) y una mejor experiencia especialmente cuando se conecta desde redes de alta latencia como 4G en movimiento.
Recomendaciones para aprovecharlo:
También mejora la eficiencia energética: menos conexiones implican menos ciclos de CPU para encriptar, monitorear y cerrar sockets.
Podemos comparar las versiones usando curl o las DevTools del navegador. El siguiente ejemplo mide el tiempo total que tarda en descargar una página con muchos recursos.
# Solicitud HTTP/1.1 (forzamos la versión)
curl -w "Tiempo total: %{time_total}s\n" -o /dev/null -s --http1.1 https://http2.akamai.com/demo
# Solicitud HTTP/2
curl -w "Tiempo total: %{time_total}s\n" -o /dev/null -s --http2 https://http2.akamai.com/demoEn un entorno de prueba típico se observan resultados como los siguientes:
| Métrica | HTTP/1.1 | HTTP/2 |
|---|---|---|
| Tiempo total (segundos) | 1.82 | 1.05 |
| Conexiones establecidas | 6 | 1 |
| Bytes en cabeceras | 180 KB | 62 KB |
Las cifras varían según la red, pero siempre se aprecia cómo la multiplexación y HPACK reducen la carga.
Aunque HTTP/2 podría operar sin cifrado, los principales navegadores (Chrome, Firefox, Safari, Edge) solo lo habilitan cuando la conexión se establece mediante HTTPS. Esto obliga a contar con certificados válidos, soporte de Application-Layer Protocol Negotiation (ALPN) y suites criptográficas modernas.
Pasos mínimos para activar HTTP/2 en producción:
curl --http2 -I https://tu-dominio o desde DevTools > Network > columna Protocol.Una vez cumplidos estos requisitos, los navegadores negocian HTTP/2 automáticamente sin que los usuarios deban hacer nada, ofreciendo mejores tiempos de carga y mayor estabilidad.