La próxima versión de HTTP no utilizará TCP

La próxima versión del Protocolo de Transferencia de Hipertexto (HTTP) -el protocolo de red que define cómo los navegadores hablan con los servidores Web- va a romper con las versiones actuales.

El HTTP actual (versiones 1.0, 1.1 y 2) tiene capas encima de TCP (Protocolo de Control de Transmisión). TCP, definido como parte del conjunto central de capas de IP (Protocolo de Internet), proporciona una entrega de datos fiable, ordenada y verificada por errores a través de una red IP. "Confiable" significa que si algunos datos se pierden durante la transferencia (debido a una falla de hardware, congestión o un tiempo de espera), el extremo receptor puede detectar esto y exigir que el extremo remitente vuelva a enviar los datos perdidos; "ordenado" significa que los datos se reciben en el orden en que fueron transmitidos; "verificado por error" significa que se puede detectar cualquier corrupción durante la transmisión.

Todas estas son propiedades deseables y necesarias para un protocolo como HTTP, pero TCP está diseñado como una especie de solución única, adecuada para cualquier aplicación que necesite este tipo de fiabilidad. No está especialmente adaptado a los tipos de escenarios para los que se utiliza HTTP. TCP requiere varios viajes de ida y vuelta entre el cliente y el servidor para establecer una conexión, por ejemplo; el uso de SSL sobre TCP requiere viajes de ida y vuelta posteriores para establecer la conexión cifrada. Un protocolo especialmente diseñado para HTTP podría combinar estas negociaciones y reducir el número de viajes de ida y vuelta, mejorando así la latencia de la red.

Diferentes modelos para llegar a HTTP/3

En sus continuos esfuerzos por agilizar las redes web, Google ha estado trabajando en un protocolo de red experimental llamado QUIC: "Quick UDP Internet Connections". QUIC abandona TCP, en su lugar utiliza su protocolo hermano UDP (User Datagram Protocol). UDP es lo "opuesto" a TCP; es poco fiable (los datos que se envían desde un extremo nunca pueden ser recibidos por el otro extremo, y el otro extremo no tiene forma de saber que algo ha desaparecido), y está desordenado (los datos que se envían más tarde pueden sobrepasar a los datos que se enviaron antes, llegando desordenados). UDP es, sin embargo, muy simple, y los nuevos protocolos a menudo se construyen sobre UDP.

QUIC restablece la fiabilidad y el orden que tiene TCP, pero sin introducir el mismo número de viajes de ida y vuelta y la misma latencia. Por ejemplo, si un cliente se está reconectando a un servidor, el cliente puede enviar datos de cifrado importantes con el primer paquete, lo que permite al servidor resucitar la conexión antigua, utilizando el mismo cifrado que se había negociado anteriormente, sin necesidad de realizar viajes de ida y vuelta adicionales.

La Internet Engineering Task Force (IETF), el grupo de la industria que colabora en el diseño de protocolos de red, ha estado trabajando para crear una versión estandarizada de QUIC, que actualmente se desvía significativamente de la propuesta original de Google. El IETF también quiere crear una versión de HTTP que utilice QUIC, antes conocido como HTTP-over-QUIC o HTTP/QUIC. HTTP-over-QUIC no es, sin embargo, HTTP/2 sobre QUIC; es una versión nueva y actualizada de HTTP construida para QUIC.

Por consiguiente, Mark Nottingham, presidente del grupo de trabajo HTTP y del grupo de trabajo QUIC para IETF, propuso renombrar HTTP-over-QUIC a HTTP/3, y la propuesta parece haber sido ampliamente aceptada. La próxima versión de HTTP tendrá QUIC como una característica esencial e integral, de manera que HTTP/3 siempre usará QUIC como su protocolo de red.