Qué son HTTP/2 y HTTP/3 y por qué importan

La evolución del protocolo HTTP

HTTP, o Protocolo de Transferencia de Hipertexto, es la base de la comunicación web. Entender el protocolo es importante para elegir el alojamiento adecuado. Cada vez que abres una página web, tu navegador envía una solicitud HTTP al servidor, que responde con el contenido solicitado. HTTP/1.1, introducido en 1997, dio servicio a la web durante casi dos décadas, pero con la creciente complejidad de las webs modernas sus limitaciones se hicieron cada vez más evidentes. Las webs actuales cargan de media entre 70 y 100 recursos por página, incluidos HTML, CSS, JavaScript, imágenes y fuentes, y HTTP/1.1 no estaba diseñado para una comunicación tan intensa.

HTTP/2 se lanzó en 2015 como respuesta a estas limitaciones, aportando cambios revolucionarios en la forma en que el navegador y el servidor se comunican. HTTP/3, introducido en 2022, va un paso más allá al sustituir el protocolo TCP por QUIC para lograr conexiones aún más rápidas y fiables. Entender estos protocolos es importante para cualquiera que trabaje en desarrollo web o alojamiento, porque afectan directamente a la velocidad y el rendimiento de la web.

HTTP/1.1 y sus limitaciones

Cómo funciona HTTP/1.1

HTTP/1.1 utiliza un formato de texto para las cabeceras de las solicitudes y respuestas y funciona según el principio de solicitud-respuesta. El navegador envía una solicitud para un recurso, espera la respuesta y luego envía la siguiente solicitud. Esto se conoce como el problema del bloqueo en cabeza de línea (head-of-line blocking), en el que una solicitud lenta bloquea todas las demás solicitudes que tiene detrás. Para sortear esta limitación, los navegadores abren varias conexiones TCP paralelas al mismo servidor, normalmente entre 6 y 8 conexiones, pero cada conexión requiere un handshake TCP y una negociación TLS por separado, lo que consume tiempo y recursos.

Soluciones provisionales de HTTP/1.1

Durante años, los desarrolladores web han utilizado distintos trucos para sortear las limitaciones de HTTP/1.1. El domain sharding es una técnica en la que los recursos se distribuyen entre varios subdominios para que el navegador pueda abrir más conexiones paralelas. Los CSS sprites combinan muchos iconos pequeños en una sola imagen grande para reducir el número de solicitudes. La concatenación fusiona varios archivos JavaScript o CSS en un único archivo grande. El inlining incrusta pequeños bloques de CSS o JavaScript directamente en el HTML. Todas estas técnicas complican el desarrollo y el mantenimiento de la web y dejan de ser necesarias con HTTP/2.

La revolución de HTTP/2

Multiplexado

La innovación más importante del protocolo HTTP/2 es el multiplexado, que permite enviar varias solicitudes y respuestas de forma simultánea a través de una sola conexión TCP. En lugar de esperar una respuesta antes de enviar la siguiente solicitud, el navegador puede enviar todas las solicitudes a la vez y el servidor responde en cuanto tiene los datos listos. Esto elimina el bloqueo en cabeza de línea a nivel de aplicación y acelera drásticamente la carga de páginas con muchos recursos. Una sola conexión sustituye la necesidad de entre 6 y 8 conexiones paralelas, lo que ahorra memoria y tiempo de procesador en ambos lados.

Compresión de cabeceras con HPACK

HTTP/1.1 envía las cabeceras como texto sin comprimir en cada solicitud. Las cabeceras de cookies pueden ocupar varios kilobytes y se envían con cada solicitud al mismo servidor. HTTP/2 utiliza el algoritmo HPACK para comprimir las cabeceras, que mantiene una tabla de las cabeceras enviadas anteriormente y envía solo las diferencias. Esto reduce el tamaño de las cabeceras entre un 85 y un 95 por ciento, algo especialmente significativo en webs con cookies grandes o muchas cabeceras personalizadas.

Server Push

La función Server Push permite al servidor enviar recursos al navegador de forma proactiva, antes de que el navegador los solicite explícitamente. Por ejemplo, cuando el navegador solicita una página HTML, el servidor puede enviar de inmediato los archivos CSS y JavaScript que sabe que serán necesarios. Esto elimina el retraso entre el análisis del HTML y el envío de solicitudes de los recursos relacionados. En la práctica, Server Push debe usarse con cuidado, porque enviar recursos de forma demasiado agresiva puede consumir ancho de banda con recursos que el navegador ya tiene en la caché.

Formato binario

HTTP/2 utiliza un formato binario en lugar del formato de texto de HTTP/1.1. El formato binario es más eficiente de analizar porque los ordenadores trabajan de forma natural con datos binarios, más resistente a errores porque tiene una estructura de tramas claramente definida y más compacto porque no malgasta bytes en delimitadores de texto ni espacios en blanco. Cada mensaje HTTP/2 se divide en tramas que pertenecen a un flujo concreto, y varios flujos se multiplexan a través de una sola conexión.

Priorización de flujos

HTTP/2 permite al navegador asignar una prioridad a cada solicitud. Los archivos CSS que bloquean el renderizado de la página pueden recibir una prioridad más alta que las imágenes que se cargan por debajo del pliegue. El servidor utiliza estas prioridades para decidir el orden en el que enviar los datos cuando el ancho de banda no puede satisfacer todas las solicitudes a la vez. El resultado es una visualización más rápida del contenido visible de la página, incluso mientras todos los recursos siguen cargándose.

HTTP/3 y el protocolo QUIC

El problema de TCP

Aunque HTTP/2 resuelve muchos problemas a nivel de aplicación, sigue utilizando TCP para el transporte. TCP tiene su propio problema de bloqueo en cabeza de línea, porque si se pierde un paquete, todos los paquetes que vienen detrás deben esperar hasta que el paquete perdido se reenvíe y se reciba. En HTTP/2, donde todos los flujos comparten una sola conexión TCP, la pérdida de un paquete bloquea todos los flujos, incluso aquellos cuyos paquetes han llegado correctamente. En redes inestables, como las redes móviles o WiFi, esto puede ser un problema importante.

Protocolo QUIC

HTTP/3 sustituye TCP por el protocolo QUIC, desarrollado por Google, que funciona sobre UDP. QUIC implementa una entrega fiable de datos de forma independiente para cada flujo, lo que significa que la pérdida de paquetes en un flujo no bloquea los demás flujos. QUIC también integra el cifrado TLS 1.3 directamente en el protocolo de transporte, lo que elimina la necesidad de un handshake TLS por separado. El resultado es un establecimiento de conexión más rápido, porque el handshake de QUIC combina los parámetros de transporte y criptográficos en un solo paso.

Conexión Zero Round Trip

QUIC admite el establecimiento de conexión 0-RTT (Zero Round Trip Time) para visitas repetidas. Cuando el usuario vuelve a un sitio visitado previamente, QUIC puede empezar a enviar datos de inmediato sin ningún handshake, utilizando los parámetros criptográficos de la sesión anterior. Esto es especialmente importante para los usuarios móviles, que a menudo cambian entre redes WiFi y móviles, porque la conexión QUIC sobrevive a un cambio de dirección IP gracias al Connection ID, en lugar de identificarse por dirección IP y puerto.

Migración de conexión

Una conexión TCP se define por un par de direcciones IP y puertos, lo que significa que la conexión se rompe cuando cambia la dirección IP. Cuando un usuario móvil pasa de WiFi a la red móvil, todas las conexiones TCP se rompen y deben volver a establecerse. QUIC utiliza el Connection ID para identificar la conexión en lugar de la dirección IP, lo que permite una migración fluida entre redes sin interrumpir la transferencia de datos. El usuario no nota la transición y la web sigue cargándose sin interrupciones.

Rendimiento en la práctica

Mediciones de velocidad

En la práctica, HTTP/2 aporta una mejora de entre el 15 y el 50 por ciento en la velocidad de carga frente a HTTP/1.1, según la complejidad de la web. Las webs con muchos recursos pequeños son las más beneficiadas, porque el multiplexado elimina la sobrecarga de abrir varias conexiones. HTTP/3 aporta una mejora adicional de entre el 5 y el 15 por ciento en condiciones ideales, pero en redes inestables con pérdidas frecuentes de paquetes la mejora puede ser del 30 por ciento o más, gracias a la eliminación del bloqueo en cabeza de línea a nivel de transporte.

Impacto en los Core Web Vitals

HTTP/2 y HTTP/3 mejoran directamente las métricas de los Core Web Vitals que Google utiliza para el posicionamiento. Comprueba el rendimiento de tu web. El Largest Contentful Paint mejora porque los recursos se cargan más rápido en paralelo. El First Input Delay disminuye porque el JavaScript se descarga y ejecuta más rápido. El Cumulative Layout Shift mejora porque las fuentes y las imágenes se cargan más rápido, lo que reduce los desplazamientos del contenido. El Time to First Byte mejora con HTTP/3 gracias a un establecimiento de conexión más rápido.

Cómo habilitar HTTP/2 y HTTP/3

Compatibilidad del servidor

HTTP/2 requiere una conexión HTTPS (un certificado TLS válido) porque todos los navegadores modernos solo admiten HTTP/2 sobre TLS. La mayoría de los servidores web modernos, incluidos Nginx, Apache y LiteSpeed, admiten HTTP/2 con una configuración sencilla. En Nginx basta con añadir el parámetro http2 en la directiva listen. Apache requiere habilitar el módulo mod_http2. HTTP/3 requiere compatibilidad con el protocolo QUIC, que actualmente ofrecen Nginx con el módulo quic, LiteSpeed, Cloudflare y otros proveedores de CDN.

Comprobación del protocolo

Puedes comprobar qué protocolo HTTP utiliza tu web a través de Chrome DevTools. Abre la pestaña Network, haz clic con el botón derecho en la cabecera de las columnas, añade la columna Protocol y recarga la página. Verás h2 para HTTP/2 o h3 para HTTP/3 junto a cada solicitud. Herramientas online como KeyCDN HTTP/2 Test y HTTP/3 Check permiten una comprobación rápida sin instalar nada.

Conclusión

HTTP/2 y HTTP/3 son mejoras significativas que aportan una carga más rápida de la web, una mejor experiencia de usuario y un mejor posicionamiento en Google. El multiplexado, la compresión de cabeceras y el server push de HTTP/2 eliminan muchas limitaciones del antiguo protocolo HTTP/1.1. HTTP/3, con el protocolo QUIC, resuelve los problemas de pérdida de paquetes y la migración de conexión, algo especialmente útil para los usuarios móviles. En BeoHosting, todos los planes de alojamiento admiten HTTP/2 y nuestros planes avanzados también incluyen compatibilidad con HTTP/3 para un rendimiento máximo de la web.