El fin del TCP en la Web: Adios y Gracias por todo

Resulta que dicen las noticias que el IETF (Internet Engineering Task Force, el grupo de empresas de la industria que colabora para diseñar protocolos de red) está trabajando en desarrollar una nueva versión de HTTP (Hyper Text Transfer Protocol), el protocolo que usan los browsers para comunicarse con los servidores web. Lo que se sabe hasta este momento es que la versión que resultará de este trabajo significará un cambio realmente abrupto en la arquitectura de las comunicaciones en Internet.

HTTP es un protocolo de Capa de Aplicación enviado sobre TCP

La versión de hoy del protocolo HTTP (actualmente se utilizan las 1.0, 1.1 y 2) está edificada sobre la base del protocolo TCP (Transmission Control Protocol), el cual a su vez hace parte del grupo central de los protocolos IP (Internet Protocol), y permite una confiable, ordenada, y limpia de errores, entrega de datos en una red IP. La confiabilidad radica en que si algún dato se pierde durante la transferencia (debido a una falla de hardware, congestión o timeout), el receptor puede detectar esto y demandar que el emisor reenvíe los datos faltantes; El orden radica en que los datos transmitidos son recibidos en el orden en el que fueron transmitidos; Limpio de errores implica que cualquier corrupción en la transmisión puede ser detectada.

Un mensaje de Request típico contiene un Método, una ruta y una Versión de HTTP solicitada

Estas son características deseables para cualquier protocolo y particularmente el HTTP, pero el problema que sobreviene es que el diseño del protocolo TCP tiene un carácter generalista, y para uso de cualquier tipo de aplicación que necesite este tipo de confiabilidad. 

El análisis que viene a continuación se hace desde la perspectiva de los escenarios en los que se desenvuelve normalmente el protocolo HTTP. TCP requiere un número de 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 subsecuentes viajes de ida y vuelta para establecer la conexión encriptada. Si se diseñara un nuevo protocolo construido específicamente para HTTP, este nuevo protocolo combinaría estas negociaciones reduciendo así el numero de viajes de ida y vuelta, por ende mejorando la latencia de red. 

La Apuesta de Goooogle

Para nadie es un secreto que Google ha venido trabajando en proyectos y propuestas para hacer más eficiente la conectividad de la Web. Uno de estos proyectos es un protocolo experimental de red llamado QUIC: Quick UDP Internet Connections. QUIC abandona por completo TCP, ocupándose de su protocolo hermano UDP (User Datagram Protocol). UDP es diametralmente opuesto a TCP; no es confiable (los datos enviados desde el emisor pueden no ser nunca recibidos por el receptor, y el receptor no tiene forma de saber que algo hace falta). Es desordenado (datos enviados con posterioridad pueden adelantarse a datos enviados antes, llegando así en desorden). Por otro lado, dada la simpleza de UDP, los nuevos protocolos son creados a partir de su arquitectura. 

Ahora, QUIC retoma la confiabilidad y orden que ofrece TCP pero sin introducir el mismo número de viajes de ida y vuelta y su latencia. Por ejemplo, si un cliente se reconecta a un servidor, el cliente puede enviar datos de encriptado importantes con el PRIMER paquete, permitiendo que el servidor resucite la vieja conexión, utilizando la misma encriptación negociada previamente, sin requerir ningún viaje de ida y vuelta adicional.

El nuevo HTTP

La IETF (Internet Engineering Task Force) ha estado trabajando para crear una versión estandarizada de QUIC, la cual en la actualidad se ha desviado significativamente de la propuesta original de Google. La IETF también quiere crear una versión de HTTP que utilice QUIC, la cual se ha dado a conocer con distintos nombres tales como HTTP-over-QUIC ó HTTP/QUIC. 

HTTP-over-QUIC no es una especie de HTTP/2-over-QUIC. Es una nueva y actualizada versión de HTTP construida para QUIC. 

Según palabras del director de ambos grupos de trabajo: HTTP y QUIC, Mark Nottingham, se propuso renombrar HTTP-over-QUIC a HTTP/3, y la propuesta aparentemente tuvo amplia aceptación. 

La próxima versión de HTTP contará como una de sus más importantes novedades, con QUIC como una característica esencial e integral hasta el punto de que HTTP/3 siempre usará QUIC como protocolo de red. 

Gracias por Todo