HTTP/3, basado en UDP, es la nueva versión del protocolo HTTP. El IETF (Internet Engineering Task Force) se reunió en Bangkok en noviembre de 2018 para adoptar este nuevo borrador de Internet.
¿Qué es HTTP/3?
El protocolo HTTP/3 es la nueva versión del protocolo de transferencia de hipertexto (HTTP) y está basado en el protocolo UDP. Pasó a ser un estándar en junio de 2022. Sin embargo, empresas como Google, Microsoft o Facebook hacía tiempo que lo habían estado utilizando para acelerar la web. Según datos sobre el uso de HTTP/3 de W3Techs, en torno al 25 % de los sitios webs ya usan HTTP/3 a fecha de septiembre de 2022.
Anteriormente se conocía como HTTP-over-QUIC (HTTP sobre QUIC, en español). El protocolo de red QUIC fue desarrollado inicialmente por Google y es el sucesor de HTTP/2. HTTP/3 lleva años en desarrollo y tiene como objetivo acelerar la velocidad de carga en Internet mediante ciertos cambios importantes en el modo de intercambiar datos en la red.
HTTP/3 se beneficia de las características del protocolo UDP y define muchas de las nuevas características que estaban en versiones anteriores de HTTP en la capa TCP. Esto permite resolver las restricciones que existen dentro de la infraestructura de Internet. Mientras HTTP/1.1 y HTTP/2 utilizan TCP en la capa de transporte, HTTP/3 utiliza QUIC, con el objetivo de solucionar uno de los problemas principales de HTTP/2 relacionados con la descarga lineal.
Aunque HTTP/2 mitiga el problema de la descarga lineal gracias a la multiplexación, sigue estando limitado por TCP. Esto se debe a que a pesar de poder usar una sola conexión TCP para múltiples transmisiones, cuando una de ellas sufre una pérdida de paquetes, toda la conexión se paraliza a la espera de que TCP retransmita el paquete perdido. HTTP/3 no está limitado por este problema de bloqueo, gracias a su integración en el protocolo UDP sin conexión.
Al proporcionar multiplexación de forma nativa, QUIC permite que los paquetes perdidos solo afecten a aquellas transmisiones en las que se hayan perdido datos. De modo que las secuencias nuevas dentro de las conexiones QUIC no necesitan esperar a que las otras terminen. Asimismo, también se elimina la sobrecarga de TCP y, como consecuencia, se reduce la latencia. En cuanto a fiabilidad, QUIC no incluye algunas de las características del protocolo TCP, pero lo compensa por encima de la capa UDP proporcionando retransmisión de paquetes, pedidos, etc.
Capa de transporte: TCP vs UDP
TCP: Protocolo de control de transmisión
TCP es el acrónimo de Transport Control Protocol (protocolo de control de transmisión, en español). Este protocolo se encuentra en un nivel superior al protocolo de Internet (IP). TCP es la base de numerosos servicios y protocolos de Internet y se encarga, entre otras cosas, de:
- Proporcionar la fiabilidad necesaria para la web, la transferencia de archivos, etc.
- Establecer la conexión en varios pasos, garantizando el orden de paquetes y ofreciendo la retransmisión de los paquetes perdidos.
- Ofrecer un cálculo de suma de comprobación para detectar errores.
No obstante, en lo que se refiere a fiabilidad, el protocolo TCP también conlleva una penalización importante: la sobrecarga de todos los viajes de ida y vuelta requeridos para garantizar la entrega correcta de la información. Esto hace que TCP se haya convertido en un cuello de botella a la hora de mejorar la velocidad. Aunque HTTP/2 ofrece algunas mejoras en este sentido, como se describe más abajo.
La especificación del protocolo TCP se remonta a 1974 y 1981 (RFC 675 y RFC 793 respectivamente). Desde entonces, este protocolo no ha sufrido cambios sustanciales porque está profundamente integrado en los sistemas operativos, firmware, etc., y su modificación no es sencilla.
UDP: Protocolo de datagrama del usuario
UDP es el acrónimo de User Datagram Protocol (protocolo de datagrama del usuario, en español). UDP es un protocolo sin conexión basado en datagramas; sin garantías en la entrega. La entrega de información, la integridad de los datos, etc., están delegadas a la capa de aplicación. El protocolo UDP se ha usado principalmente para aplicaciones VoIP, DNS, DHCP, BOOTP, etc. Las especificaciones del formato de paquetes UDP es mínima. Su encabezado consiste en:
- El puerto de origen y el de destino,
- la longitud del encabezado y los datos del paquete (en bytes),
- y la suma de comprobación para verificar la integridad de los datos (opcional con IPv4 y obligatoria con IPv6).
La especificación del protocolo UDP se remonta a 1980 (RFC 768) y su uso también está muy extendido. De modo que cualquier mejora significativa también requeriría cambios importantes en el firmware de los dispositivos conectados a Internet y en los sistemas operativos.
Protocolo de red QUIC
QUIC es el acrónimo de Quick UDP Internet Connections (conexiones UDP rápidas en Internet, en español). QUIC, diseñado por Jim Roskind en Google en 2012, es un protocolo de red sobre la capa de transporte UDP. La versión de QUIC de Google se centraba solo en el transporte HTTP, para lo cual utilizaba la sintaxis HTTP/2. Sin embargo, para su estandarización, el IETF va más allá.
Con QUIC se redefinen los límites de las capas de red, las comunicaciones, las características de fiabilidad y las de seguridad en el espacio de usuario. Esto permite evitar la necesidad de actualizar los núcleos del sistema de Internet. No obstante, el uso de UDP proporciona tanto ventajas como desafíos a QUIC y HTTP/3. Uno de los desafíos es la carga de CPU, que puede ser el doble con QUIC que con HTTP/2, según algunas estimaciones. Esto se debe a que los sistemas operativos y el software no están optimizados para usar UDP; ya que TCP ha sido el protocolo principal durante mucho tiempo.
Asimismo, en las conexiones QUIC el uso de TLS es obligatorio; con el objetivo de dificultar que dispositivos intermedios manipulen o detecten el tráfico. Los flujos QUIC disponen de un ID que identifica quién comienza la transmisión y se envían a través de conexiones QUIC, unidireccionales o bidireccionales.
Implementación de HTTP/3
La implementación de HTTP/3 que promueve el IETF también incluye las versiones anteriores; para garantizar la compatibilidad. Tal y como se precisa en el RFC 7838, un encabezado informa al cliente de que HTTP/3 está disponible, junto con la información del puerto. A fecha de mayo de 2021, los navegadores Google Chrome, Firefox, Safari y Microsoft Edge ya soportan HTTP/3 —al menos como característica experimental, a la espera de su estandarización—. También lo hacen algunos servidores como Litespeed Web Server, HAProxy 2.3 o el servidor web Caddy.
Asimismo, existen algunas librerías de código abierto de implementaciones de HTTP sobre QUIC como: neqo de Mozilla, Cronet de Google, proxygen de Facebook, lsquic de LiteSpeed, aioquic, quic-go o nghttp3. En GitHub está la lista completa de librerías disponibles desarrolladas con diferentes lenguajes de programación (C, C++, Rust, Python…).
Versiones de HTTP
La primera versión de HTTP se lanzó en 1991 como HTTP/0.9. A esta le siguieron HTTP/1.0 en 1996 y HTTP/1.1 en 1997. Con la evolución de Internet y la web, el protocolo se ha actualizado gradualmente para perfeccionar la transferencia de los datos en la red. Aunque, hasta el lanzamiento de HTTP/2 en 2015, no se hicieron grandes cambios. Esta nueva versión mejoró la transferencia de datos y, como consecuencia, permitió acelerar considerablemente la velocidad de carga de las páginas web. Por último, HTTP/3 es la próxima versión y se espera que mejore aún más la velocidad de Internet.
Mejoras introducidas por HTTP/2
El protocolo HTTP/2 ya introdujo algunas mejoras interesantes como:
- Superar algunas limitaciones del protocolo TCP con mejoras como las descargas no bloqueadas, la canalización y el empuje del servidor.
- Minimizar el número de ciclos de solicitud-respuesta y, como consecuencia, mejorar la velocidad de carga.
- Enviar más de un recurso en una sola conexión TCP (multiplexación).
- Ganar flexibilidad a la hora de descargar recursos estáticos y eliminar la limitación de la descarga lineal de una página. Lo cual se traduce en que un recurso JavaScript de gran tamaño no tiene por qué ser un problema para la carga del resto de recursos estáticos.
A esta lista hay que añadir la compresión HPACK en el encabezado HTTP/2 y el formato binario predeterminado de transferencia de datos. Lo cual mejoró considerablemente la eficiencia del protocolo.
Asimismo, para aprovechar al máximo el potencial de HTTP/2, los principales navegadores hicieron obligatorio el uso de un SSL. Lo cual hizo que, en algunos casos, estas mejoras de velocidad apenas fueran perceptibles.
En resumen, la evolución de protocolos clave como HTTP es indispensable en el contexto de evolución continua de Internet y de la web. En cuanto a la nueva versión de este protocolo, hay diversos enfoques. Algunos piensan que, dado que el estándar HTTP/2 aún no se ha adoptado completamente, puede ser demasiado pronto para lanzar una nueva versión. No obstante, el éxito de las pruebas realizadas con HTTP/3 animan a lanzar esta nueva versión pues sería beneficiosa para todos los usuarios. Como mencionamos anteriormente, los navegadores principales ya soportan HTTP/3 y algunas empresas como Google, Mozilla, Facebook o Akamai utilizan este nuevo protocolo desde hace años.
Fuentes: W3Techs.
