Por qué HTTP/3 se está comiendo el mundo

El protocolo de transferencia de hipertexto (HTTP) es una piedra angular de Internet, que ayuda a cargar páginas web, transmitir vídeos y obtener datos para sus aplicaciones favoritas.

El año pasado, una nueva versión del protocolo, HTTP/3, fue estandarizada por la Internet Engineering Task Force (IETF), la organización encargada de definir las tecnologías de Internet. Desde entonces, HTTP/3 y el protocolo QUIC relacionado han experimentado una rápida adopción en la Web pública. Las cifras exactas dependen de la fuente y de la metodología de medición, y el soporte de HTTP/3 oscila entre el 19% y el 50% o más de los servidores y redes web de todo el mundo.

Dado que estos nuevos protocolos son muy utilizados por grandes empresas como Google y Meta, podemos afirmar sin temor a equivocarnos que una gran parte del tráfico actual de Internet ya utiliza HTTP/3 en la actualidad. De hecho, ¡la entrada del blog que está leyendo ahora mismo probablemente se cargó a través de HTTP/3!

En esta serie, proporcionaré algo de contexto sobre qué problemas resuelve HTTP/3, cómo funciona, por qué ha visto una adopción tan rápida y qué limitaciones aún está trabajando para superar.

Un protocolo de red describe cómo se comunican los datos entre dos entidades de la red, normalmente el dispositivo del usuario y un servidor web. Como hay muchas empresas diferentes que construyen software para la web, es necesario estandarizar el protocolo para que todo este software pueda ser "interoperable", es decir, que todos puedan entenderse entre sí porque siguen las mismas reglas.

En la práctica, no utilizamos un único protocolo, sino una combinación de varios a la vez, cada uno con sus propias responsabilidades y reglas (Figura 1). Esto se hace para que las cosas sean flexibles y reutilizables: puede seguir utilizando exactamente la misma lógica HTTP, independientemente de si utiliza WiFi, cable o 4G/5G.

Muchos de los protocolos originales de Internet se estandarizaron en los años 80 y 90, lo que significa que se construyeron teniendo en cuenta los objetivos y restricciones de esas décadas. Aunque algunos de estos protocolos han superado la prueba del tiempo, otros han empezado a mostrar su edad. La mayoría de los problemas se han resuelto mediante soluciones provisionales y trucos ingeniosos. Sin embargo, estaba claro que algo tendría que cambiar. Esto es especialmente cierto en el caso del Protocolo de Control de Transporte (TCP), que garantiza que sus datos lleguen de forma fiable a través de Internet.

HTTP/1.1 y HTTP/2 dependen de TCP para realizar con éxito su trabajo: antes de que un cliente y un servidor puedan intercambiar una solicitud/respuesta HTTP, deben establecer una conexión TCP.

Con el tiempo, ha habido muchos esfuerzos para actualizar TCP y resolver algunas de sus ineficiencias - TCP todavía carga páginas web como si fueran archivos individuales en lugar de una colección de cientos de archivos individuales. Algunas de estas actualizaciones han tenido éxito, pero la mayoría de las más impactantes (por ejemplo, TCP multipath y TCP Fast Open) tardaron casi una década en ser prácticamente utilizables en la Internet pública.

El principal reto a la hora de implementar cambios en TCP es que miles de dispositivos en Internet tienen cada uno su propia implementación del protocolo TCP. Entre ellos se incluyen teléfonos, ordenadores portátiles y servidores, así como enrutadores, cortafuegos, equilibradores de carga y otros tipos de "middleboxes". Como tal, si queremos actualizar el TCP, tenemos que esperar a que una parte significativa de todos estos dispositivos actualice su implementación, lo que en la práctica puede llevar años.

Esto se convirtió en un problema hasta el punto de que la forma más práctica de avanzar era sustituir TCP por algo totalmente nuevo. Este sustituto es el protocolo QUIC, aunque muchos todavía se refieren a él (en broma) como TCP 2.0. Este apodo es apropiado porque QUIC incluye muchas de las mismas características de alto nivel de TCP pero con un par de cambios cruciales.

El principal cambio es que QUIC se integra en gran medida con el protocolo Transport Layer Security (TLS). TLS se encarga de encriptar los datos confidenciales en la Web: es lo que proporciona la S (seguro) en HTTPS. Con TCP, TLS sólo cifra los datos HTTP propiamente dichos (figura 2). Con QUIC, TLS también encripta grandes partes del propio protocolo QUIC. Esto significa que los metadatos, como los números de paquete y las señales de cierre de conexión, que eran visibles para (y modificables por) todos los intermediarios en TCP, ahora sólo están disponibles para el cliente y el servidor en QUIC.

Además, como QUIC está más ampliamente encriptado, será mucho más fácil que en el caso de TCP modificarlo o añadirle nuevas funciones: sólo tenemos que actualizar los clientes y los servidores, ya que las middleboxes no pueden desencriptar los metadatos de todos modos. Esto convierte a QUIC en un protocolo preparado para el futuro que nos permitirá resolver más rápidamente nuevos retos.

Por supuesto, este cifrado adicional también es bueno para la seguridad general y la privacidad del nuevo protocolo. Aunque TCP + TLS son perfectos para proteger datos personales sensibles, como tarjetas de crédito o contenidos de correo electrónico, aún pueden ser vulnerables a ataques complejos (contra la privacidad), cuya ejecución se ha vuelto cada vez más práctica gracias a los recientes avances en IA. Al cifrar aún más este tipo de metadatos, QUIC es más resistente a los actores de amenazas sofisticadas.

QUIC también cuenta con muchas otras funciones relacionadas con la seguridad, incluidas las defensas contra los ataques de denegación de servicio distribuidos (DDoS), con funciones como la prevención de la amplificación y los paquetes RETRY.

Por último, QUIC también incluye una gran cantidad de mejoras de eficiencia y rendimiento en comparación con TCP, entre las que se incluyen un "handshake" de conexión más rápido (véase la figura 3), la eliminación del problema del "bloqueo de cabecera", una mejor detección/recuperación de la pérdida de paquetes y formas de tratar con los usuarios que cambian de red (entraré en más detalles sobre esto en mi próximo post).

En un principio, se intentó mantener HTTP/2 y realizar unos ajustes mínimos para poder utilizar también QUIC en las capas inferiores (después de todo, ese es el objetivo de tener estos diferentes protocolos cooperativos y reutilizables). Sin embargo, quedó claro que QUIC era lo suficientemente diferente de TCP como para hacerlo incompatible con HTTP/2. Como tal, se tomó la decisión de hacer una nueva versión de HTTP, sólo para QUIC, que finalmente se convirtió en HTTP/3.

HTTP/3 es casi idéntico a HTTP/2. Se diferencian principalmente en la implementación técnica de las funciones sobre QUIC o TCP. Sin embargo, como HTTP/3 puede utilizar todas las nuevas características de QUIC, se espera que tenga un mayor rendimiento a la hora de cargar páginas web y transmitir vídeos. En la práctica, es especialmente este aspecto el que ha propiciado la rápida adopción de HTTP/3.

En mi próximo post, entraré en más detalles sobre un problema de conectividad común que probablemente haya experimentado y cómo QUIC puede ayudarle a reducir las llamadas y los vídeos que se cortan cuando su dispositivo móvil pasa de utilizar la conectividad WiFi a la celular.

Robin Marx es experta en rendimiento y protocolo web de Akamai. Las opiniones expresadas por los autores de este blog son suyas y no reflejan necesariamente los puntos de vista de la Internet Society.

Foto de Nick Night en Unsplash