HTTP/3, el nuevo protocolo de alta velocidad basado en UDP

 07/Ago/2019 -   Internet
HTTP/3, el nuevo protocolo de alta velocidad basado en UDP

En noviembre de 2018, el IETF se reunió en Bangkok para adoptar un nuevo borrador de Internet. El protocolo de transporte QUIC, sucedor del HTTP/2, fue renombrado como HTTP/3 y está basado en el protocolo UDP. Actualmente está siendo utilizado por grandes empresas de Internet como Google y Facebook.

El protocolo HTTP/3 se beneficia de las características del protocolo UDP, definiendo muchas de las nuevas características que estaban en versiones anteriores de HTTP en la capa TCP. Gracias a esto, es posible resolver las restricciones que existen dentro de la infraestructura de Internet.

Aunque se trata de un proyecto nuevo, los primeros resultados son muy prometedores. Cuando expire el borrador de Internet de IEFT layman en junio de 2019, se espera que HTTP/3 se promocione como un nuevo estándar HTTP de tercera generación.

¿Qué es HTTP / 3?

HTTP/3 es la tercera versión del protocolo de transferencia de hipertexto (HTTP), anteriormente conocido como HTTP-over-QUIC (Conexiones rápidas de Internet UDP). Este fue desarrollado inicialmente por Google y es el sucesor de HTTP/2. Empresas tan importantes como Google y Facebook ya han estado utilizando QUIC para acelerar la web.

Un poco de historia, empezando por HTTP/2

El sueño de cualquier propietario de una página web es conseguir que esta cargue lo más rápido posible. Para ello se puede utilizar la versión más reciente de PHP, entregando información a través de la red de nivel superior de Google Cloud Platform o bien almacenar en caché nuestra información.

El protocolo HTTP/2 trajo algunas interesantes mejoras con las descargas no bloqueadas, la canalización y el empuje del servidor, que nos ha ayudado a superar algunas limitaciones del protocolo TCP. También nos permitió minimizar el número de ciclos de solicitud-respuesta, mejorando la velocidad de carga.

Con la llegada de HTTP/2 fue posible enviar más de un recurso en una sola conexión TCP. También obtuvimos más flexibilidad a la hora de descargar los recursos estáticos, además de eliminar la limitación de la descarga lineal de nuestra página.

HTTP2 push

En la práctica, esto se traduce que un gran recurso javascript no tiene por qué ser un punto problemático para la carga del resto de recursos estáticos

A todo lo dicho hay que añadir la compresión HPACK en el encabezado HTTP/2 y el formato binario predeterminado de transferencia de datos, consiguiendo de esta forma un protocolo más eficiente.

HTTP2 Hpack

Para aprovechar toda su potencia, los principales navegadores hicieron que el uso de un SSL fuera requisito obligatorio. En ocasiones, debido a una carga de cómputo, estas mejoras de velocidad apenas se notaban.

Aunque algunos de estos problemas se resuelven ahora, si nos fijamos en toda la pila de protocolos, veremos como la restricción principal se encuentra en un nivel inferior al que HTTP/2 se atrevió a aventurar. Para probar esto, analizaremos la pila de protocolos de Internet desde su capa inferior hasta la superior.

Protocolo Internet (IP)

El protocolo de Internet (IP) se encarga de definir la parte inferior de toda la topología de la red. Podemos afirmar que se trata de una capa que ante cualquier cambio que se haga sobre ella, conlleva una sustitución de toda la infraestructura de hardware, desde los enrutadores a los servidores e incluso las máquinas de los usuarios finales. Debajo de este protocolo, nos encontramos una capa de enlace y que es la parte del protocolo más “simple”, por decirlo de alguna forma.

Para ver los inicios del protocolo IP hay que viajar hasta 1974, en un artículo publicado por el Instituto de Ingenieros Eléctricos y Electrónicos y escrito por Vint Cerf y Bob Cahn. En él se detalló como los paquetes se envían a través de una red, enrutándolos por medio de direcciones IP y direcciones numéricas definidas de nodos. El protocolo definió el formato de estos paquetes o datagramas: sus encabezados y su carga útil.

Después de la definición de RFC 760 de 1980, el IETF lanzó la definición que se viene utilizando hasta el día de hoy. Se trata de la cuarta versión del protocolo, pero podemos decir que es la primera versión de producción.

El protocolo utiliza direcciones de 32 bits, lo que estable una restricción en el número de direcciones de unas 4 mil millones. Esta limitación es la que explica como la mayoría de los usuarios corrientes, disponen de IPs dinámicas en sus conexiones y no fijas, además de que las fijas conllevan un cargo adicional por parte de su ISP.

Direcciones IP racionalizadas

No tuvo que pasar mucho tiempo hasta que se dieron cuenta de que las direcciones de 32 bits no eran suficientes, avecinándose un problema de escasez para dar respuesta a la demanda de direcciones IP. Para dar solución a este problema, se publicaron muchos RFC. Aunque estas soluciones se vienen utilizando hoy en día, es muy problema que sigamos diciendo que siguen siendo insuficientes.

El protocolo IPv6 se presentó como una forma de abordar estas limitaciones, incluso para ser adoptado de forma gradual sobre la versión anterior. En 1998 se elaboró un borrador por parte del IEFT, elevándose a un estándar de Internet en 2017.

Si bien el espacio de direcciones IPv4 estaba limitado por su longitud de dirección de 32 bits, al estándar IPv6 se le asignaron 128 bits, o 3,4 * 10 ^ 38 direcciones posibles. Esto debería ser suficiente para que nos dure bastante tiempo.

Según datos de Google, la adopción de IPv6 es algo superior al 25% a marzo de 2019.

Según datos de Google, la adopción de IPv6 es algo superior al 25% a marzo de 2019.

Centrándonos en el protocolo IP, se puede decir que es una capa rudimentaria de la pila de Internet, que define la mayoría de las cosas básicas, pero sin garantizar la entrega, la integridad de los datos o el orden de los paquetes transmitidos. Por sí solo no es confiable. El formato del encabezado de IPv4 proporciona una suma de comprobación del encabezado, que los nodos de transmisión utilizan para verificar la integridad del encabezado. Esto lo hace diferente de la versión de IPv6, que se basa en la capa de enlace que se encuentra debajo, lo que le permite ser más rápido.

Cabecera datagrama internet

Entendiendo el rol de TCP y UDP

Ahora es el momento de explorar dónde encaja HTTP/3 con TCP y UDP.

TCP

Si bien IP es la capa subyacente de todas nuestras comunicaciones en red, TCP es una parte de nivel superior del protocolo de Internet que se encarga de proporcionar la confiabilidad necesaria para la web o la transferencia de archivos, entre otras cosas. Esto incluye el establecimiento de la conexión en varios pasos, manteniendo un orden seguro de paquetes y ofreciendo la retransmisión de los paquetes perdidos. También ofrece un cálculo de suma de comprobación para detectar errores. Todas estas características hacen que TCP sea la base de los servicios de Internet más notorios que utilizamos en la actualidad.

Su especificación se remonta a 1974 (RFC 675) y 1981 (RFC 793) y no ha cambiado sustancialmente hasta el día de hoy. Sin embargo, la confiabilidad de proporciona TCP conlleva una importante penalización: la sobrecarga de todos los viajes de ida y vuelta requeridos para garantizar la entrega correcta de la información. Esto ha convertido a TCP en un cuello de botella a la hora de intentar conseguir mayor velocidad, aunque HTTP/2 ofrece algunas mejoras.

El problema es que cambiar el TCP de una manera sustancial no es nada sencillo ya que forma parte de la pila TCP/IP estando profundamente integrado en los sistemas operativos, el firmware, etc.

UDP

UDP es otra de las partes que forman parte del protocolo de Internet, cuya especificación se remonta a 1980 (RFC 768). Es un protocolo sin conexión basado en datagramas, lo que significa que no hay garantías en la entrega y que no se estable relación previa. De esta forma, cualquier entrega de información, la integridad de los datos u otras cosas, son delegadas a la capa de aplicación.

Al igual que TCP, UDP está muy extendido, por lo que lograr cualquier mejora requerirá importantes cambios en el firmware de todos los dispositivos conectados a Internet, e incluso en los sistemas operativos.

Las especificaciones del formato de paquetes UDP es bastante  mínima. Su encabezado consiste en el puerto de origen, el puerto de destino, la longitud del paquete en bytes, el encabezado del paquete y los datos del paquete. También incluye la suma de comprobación que se puede utilizar para verificar la integridad de los datos.

Hay que destacar que la suma de comprobación es opción cuando la capa de protocolo subyacente es IPv4 y obligatoria con IPv6. Hasta la fecha, UDP se ha venido utilizando para aplicaciones VoIP, transmisiones de vídeo, sistemas DNS o protocolo DHCP.

QUIC and HTTP/3

Google implementó por primera vez el QUIC (Conexiones rápidas de Internet UDP) en 2012. Mediante QUIC, redefinieron los límites de las capas de red, confiando en el protocolo UDP de nivel inferior, además de redefinir las comunicaciones, las características de confiabilidad y las características de seguridad en el espacio de usuario, evitando la necesidad de actualizar los núcleos del sistema de Internet.

Al igual que con HTTP/2, un avance tecnológico encabezado por SPDY de Google, se aprovechó de estos logros para el desarrollo de HTTP/3.

Como hemos hablado anteriormente, HTTP/2 llegó con la multiplexacion debajo del brazo, lo que mitigaba el problema de la descarga lineal, aunque seguía restringido por TCP. El problema que nos encontramos es que se puede utilizar una sola conexión TCP para múltiples transmisiones, pero cuando una de ellas sufre una pérdida de paquetes, toda la conexión se mantiene como “rehén”, por así decirlo, a la espera de que TCP haga su trabajo, retransmitiendo el paquete perdido. Esto significa que todos los paquetes, incluso si ya han sido transmitidos, se bloquean hasta que se retransmita el paquete perdido.

QUIC no está limitado por este problema. QUIC integrado en el protocolo UDP sin conexión, no ofrece las limitaciones de TCP, por lo que las fallas de una secuencia no influyen en el resto.

Con un cambio en el enfoque de las trasmisiones UDP, QUIC logra la multiplexación sin tener que volver en una conexión TCP. QUIC construye su conexión en un nivel más alto que TCP. Las nuevas secuencias dentro de las conexiones QUIC no se ven obligadas a esperar a que las otras terminen. También se benefician de la eliminación de sobrecarga de TCP, lo que reduce la latencia.

Si bien QUIC elimina algunas de las características de confiabilidad de TCP, lo compensa por encima de la capa UDP, proporcionando retransmisión de paquetes, pedidos, etc. Google Cloud Platform introdujo el soporte QUIC para sus balanceadores de carga en 2018 y vio una mejora en el tiempo promedio de carga de la página en un 8% a nivel mundial, y hasta un 13% en regiones donde la latencia es mayor.

La versión de QUIC de Google se centró solo en el transporte HTTP, utilizando para ello la sintaxis HTTP/2. La gente de IETF, encargada de la estandarización de QUIC, decidieron que este estándar debería poder transportar más cosas además de HTTP.

Si abrimos Chrome Dev Tools y cargamos algunos de los productos de Google, como Gmail, en la columna Protocolo de la pestaña Red, veremos que se están cargando muchos recursos a través de la versión de Google del protocolo QUIC.

Servicio google QUIC

Aunque UDP proporciona a QUIC y HTTP/3 algunas ventajas, también presenta ciertos desafíos. TCP ha sido el protocolo principal durante años, por lo que los sistemas operativos y el software en general, no están optimizados para su utilización. Debido a esto, hay una mayor carga de CPU con QUIC, según algunas estimaciones, el doble que con HTTP/2.

Las conexiones QUIC combinan TLS y el protocolo de transporte. Una vez establecido, se identifica mediante un ID de conexión único. Estos IDs persisten en los cambios de IP, pudiendo ayudar a asegurar las descargas.

El uso de TLS es obligatorio y está destinado a dificultar que los dispositivos en el medio manipulen o detecten el tráfico. Es por eso que no es raro ver a proveedores de firewall y proveedores como Cisco que ven el protocolo UDP como un problema, proporcionando formas de desactivarlo.

Los flujos QUIC se envían a través de conexiones QUIC, ya sean unidireccionales o bidireccionales. Estos flujos tienen un ID que se encargan de identificar a quien comienza la transmisión.

Dado que la compatibilidad con versiones anteriores es muy importante, la implementación de HTTP/3 promovida por IETF incluirá las versiones anteriores. Se incluirá un encabezado que informa al cliente que HTTP/3 está disponible, junto con la información del puerto, tal y como se describe en el RFC 7838.

Conclusión

Hay quienes piensan que como el estándar HTTP/2 no se ha adoptado completamente, puede ser demasiado pronto para lanzar su tercera versión. Aunque esto puede ser un punto a tener en cuenta, las pruebas realizadas son tan satisfactorias que animan a su lanzamiento, en beneficio de todos los usuarios. Hay que recordar que Google empezó a utilizarlo en 2015 y que Facebook se sumó en 2017. Desde entonces, otras empresas han empezado a utilizarlo como Akamai o Mozilla.

Habrá que estar atentos a lo que ocurre este año y ver cómo actúan los principales proveedores de software para implementar este nuevo estándar.