El Protocolo de Transferencia de Hipertexto (HTTP) es la piedra angular de Internet, ya que ayuda a cargar páginas web, transmitir vídeos y obtener datos para tus aplicaciones favoritas.
El año pasado, una nueva versión del protocolo, HTTP/3, fue normalizada por la Internet Engineering Task Force (IETF), 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 la metodología de medición, y la compatibilidad con HTTP/3 oscila entre el 19% y más del 50% 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, explicaré qué problemas resuelve HTTP/3, cómo funciona, por qué se ha adoptado tan rápidamente y qué limitaciones está intentando superar.
¿Por qué necesitamos HTTP/3?
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 crean software para la Web, es necesario normalizar 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 al mismo tiempo, cada uno con sus propias responsabilidades y reglas (Figura 1). Esto es para hacer las cosas flexibles y reutilizables – puedes seguir usando exactamente la misma lógica HTTP, independientemente de si estás usando 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 crearon teniendo en cuenta los objetivos y restricciones de esas décadas. Aunque algunos de estos protocolos han resistido el paso del tiempo, otros han empezado a mostrar su edad. La mayoría de los problemas se han resuelto con 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 la fiabilidad de los datos en Internet.
Por qué TCP no es óptimo para la web actual
HTTP/1.1 y HTTP/2 se basan en TCP para realizar correctamente 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 que plantea la introducción de 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, portátiles y servidores, así como routers, cortafuegos, equilibradores de carga y otros tipos de “middleboxes”. Así, si queremos actualizar TCP, tenemos que esperar a que una parte importante de todos estos dispositivos actualicen su implementación, lo que en la práctica puede llevar años.
La solución QUIC
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 lo siguen llamando (en broma) 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 de seguridad de la capa de transporte (TLS). TLS se encarga de cifrar los datos sensibles 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) todas las middleboxes 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 cambiarlo o añadir nuevas funciones: sólo tendremos que actualizar los clientes y servidores, ya que los 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 contenido de correo electrónico, pueden seguir siendo vulnerables a ataques complejos (contra la privacidad), cuya ejecución es 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 las amenazas más sofisticadas.
 | Más información sobre cómo la Internet Society trabaja en todo el mundo para proteger el cifrado ayudando a los responsables políticos a entender las propuestas que podrían poner en peligro la seguridad en línea. |
QUIC también cuenta con muchas otras funciones relacionadas con la seguridad, incluidas defensas contra ataques de denegación de servicio distribuidos (DDoS), con funciones como la prevención de 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, incluido un intercambio de conexiones más rápido (véase la Figura 3), la eliminación del problema del “bloqueo de la cabeza de línea”, una mejor detección/recuperación de la pérdida de paquetes y formas de tratar a los usuarios que cambian de red (entraré en más detalles sobre esto en mi próximo post).
No necesitábamos HTTP/3. Lo que necesitábamos era QUIC
Al principio, se intentó mantener HTTP/2 y hacer unos ajustes mínimos para poder utilizar también QUIC en las capas inferiores (al fin y al cabo, 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. Por ello, se tomó la decisión de crear 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 funciones de QUIC, se espera que su rendimiento sea mayor al 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, voy a entrar en más detalles sobre un problema de conectividad común que muy probablemente has experimentado y cómo QUIC puede ayudar a reducir las llamadas y videos de corte cuando el dispositivo móvil cambia de usar WiFi a la conectividad celular.
Robin Marx es Experto en Protocolo y Rendimiento Web en 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