¿Qué es HTTP/3? El nuevo protocolo basado en UDP

La nueva versión del protocolo de HTTP se beneficia del protocolo básico de bajo nivel de UDP, y define cuántas de estas nuevas funciones, las cuales estaban en versiones previas de HTTP en la capa de TCP está usando. Esto provee una nueva forma de resolver problemas dentro de la misma infraestructura del internet.

• HTTP/3 está por llegar
• Qué es HTTP/3 – En términos más simples
• Un poco de su pasado – Todo empezó con HTTP/2
• Protocolo de Internet (IP)
• Entendiendo el rol de TCP y UDP
• QUIC y HTTP/3

HTTP/3 está por llegar

En el 2016, publicamos uno artículos sobre HTTP/2, un estándar que, de acuerdo a W3Techs, actualmente tiene un 34% de rango de adopción. Y de acuerdo a Can I use, también es soportado por todos los navegadores modernos. Aún así, aquí estamos, escribiendo un artículo sobre la siguiente versión del protocolo, HTTP/3.

Qué es HTTP/3 – En términos más simples

HTTP/3 es la tercera versión del Hypertext Transfer Protocol (HTTP), anteriormente conocido como HTTP-sobre-QUIC. QUIC (Quick UDP Internet Connections) fue inicialmente desarrollado por Google y es el sucesor de HTTP/2. Las compañías como Google y Facebook ya habían estado usando QUIC para acelerar la red.

Un poco de su pasado – Todo empezó con HTTP/2

HTTP/2 trajo unas mejoras muy importantes con descargas no bloqueables, pipelining y server push lo cual nos ha ayudado a vencer algunas de las limitaciones del protocolo TCP subyacente. Esto nos permite minimizar el número de los ciclos de peticiones-respuestas y handshakes.

HTTP/2 hizo que fuera posible sacar más de un recurso en una sola conexión de TCP – multiplexación. En práctica, esto quiere decir que ahora un gran recurso de Javascript no es necesariamente igual a un cuello de botella para todo el resto de recursos estáticos esperando su turno.

Sin pipelining vs pipelining (fuente de la imagen: Wikipedia, Autor Mwhitlock)

Agregue estas dos cosas a la compresión de HPACK del encabezado de HTTP/2 y el formato binario por defecto de la transferencia de datos, y tenemos, en muchos casos, un protocolo mucho más eficiente.

Compresión HTTP/2 HPACK

Las implementaciones más grandes de los navegadores hicieron que fuera un requisito para los sitios web implementar encriptación – SSL – para poder obtener los beneficios de HTTP/2 – y en algunas ocasiones las mejoras de velocidad fueron indetectables. Incluso hubo algunos casos donde los usuarios reportaron una baja en la velocidad al pasar a HTTP/2.

Mientras que algunos de estos problemas ya han sido resueltos, si vemos todo este stack del protocolo, podemos observar que la limitación principal yace en un nivel más bajo del que HTTP/2 se atrevería a aventurarse.

Si quiere aprender más sobre el pasado de HTTP/2, asegúrese de leer la guía detallada sobre HTTP/2.

Entendiendo el rol de TCP y UDP

Ahora es tiempo de explorar donde HTTP/3 se ajusta con TCP y UDP.

TCP

Mientras que la IP es una capa subyacente de todas nuestras comunicaciones de hoy en día, TCP (Transmission Control Protocol) es una parte de nivel más alto de la suite del protocolo de internet, brindando fiabilidad que es necesaria para la red, mail, transferencia de archivos (FTP) – para la aplicación de capas/protocolos del internet.

Esto incluye un establecimiento de una conexión de múltiples pasos, con handshakes, un orden asegurado de paquetes, y una retransmisión de paquetes perdidos. Este provee retroalimentación (ACKs) al remitente. También hay una suma de comprobación de la computación para detectar errores.

Su especificación que data a 1974 (RFC 67) y 1981 (RFC 793) no ha cambiado mucho hasta hoy.

La sobrecarga de todos los roundtrips requeridos por los handshakes y la suma de comprobación, que podrían ser considerados débiles y redundantes, han hecho que TCP sea un cuello de botella del stack de protocolo moderno. HTTP/2 ha llegado a un estancamiento de mejoras de velocidad que pueden ser alcanzadas sobre TCP.

Cambiar TCP de una forma substancial no es una acción sencilla porque el stack de TCP/IP, que data de los 70s, está profundamente arraigado en los sistemas operativos, firmware de los dispositivos, etc.

UDP

UDP (User Datagram Protocol) es también una de las partes de la suite del protocolo de Internet, con su especificación que data desde 1980 (RFC 768).

Como su nombre lo sugiere, es un protocolo sin conexión basado en datagramas. Lo que quiere decir que no hay handshakes y no hay garantía de entrega de paquetes. Esto quiere decir que cualquier paso posible para asegurar una entrega, integridad de datos, y otras cosas, se dejan a la aplicación o se puede recurrir a elementos de la capa del enlace, como la suma de comprobación, para evitar una sobre carga.

Considerando lo anterior, es posible mejorarlo sin la necesidad de recurrir a un gran cambio de firmware en todos los dispositivos conectados al internet, o que se hagan cambios significativos a los sistemas operativos.

Este artículo en Hacker News puede ayudar a entender el razonamiento detrás de la construcción de una nueva versión de HTTP sobre el ya existente stack de red, en lugar de reinventarlo.

La especificación del formato del paquete de UDP es relativamente mínima, su encabezado consiste del puerto origen, puerto destino, longitud en bytes del paquete, y la suma de comprobación, usada para verificar la integridad de los datos del encabezado y del paquete propiamente dicho.

La suma de comprobación es opcional cuando la capa del protocolo subyacente es IPv4, y obligatoria en IPv6. Hasta ahora, UDP se ha utilizado para cosas como sincronización de reloj de sistemas informáticos (NTP), aplicaciones VoIP, transmisión de video, sistema DNS y en el protocolo DHCP.

QUIC y HTTP/3

QUIC (Quick UDP Internet Connections) fue desplegado por primera vez por Google en 2012. Este redefine los límites de las capas de la red, dependiendo de un protocolo UDP de bajo nivel, redefiniendo handshakes, funciones de fiabilidad, y funciones de seguridad en el "espacio-usuario", evitando la necesidad de mejorar el núcleo de todos los sistemas.

Stack HTTP/2 vs stack HTTP/3

HTTP/2 ha sido un adelanto, basado en SPDY de Google, y el nuevo HTTP/3 será construido sobre estos logros.

Mientras que HTTP/2 brindó multiplexación, y el poder mitigar el head-of-line-blocking de TCP. Se puede utilizar una sola conexión TCP para múltiples flujos multiplexados para transferir datos, pero cuando uno de estos flujos sufre de la pérdida de un paquete, toda la conexión (y todos sus flujos) son retenidos, por así decirlo, hasta que TCP haga lo suyo (retransmitir el paquete perdido).

Esto quiere decir que todos los paquetes, incluso si ya han sido transmitidos y están en espera, en el buffer del nodo destino, están siendo bloqueados hasta que el paquete perdido es retransmitido. Daniel Stenberg en su libro sobre HTTP/3 llama a esto "TCP- based head of like block". Daniel dice que, con el 2% de pérdida de paquetes, a los usuarios les iría mejor con HTTP/1, con seis conexiones para cubrir el riesgo.

QUIC no está limitado por esto. Al ser onstruído sobre los protocolos UDP sin conexión, el concepto de conexión no tiene las limitaciones de TCP y las fallas de un flujo no ejercen influencia al resto de los paquetes. Con un enfoque en flujos UDP, QUIC logra hacer un multiplexor sin la necesidad de depender de una conexión TCP. QUIC construye su conexión en un nivel mucho mayor que TCP. Los nuevos flujos de datos dentro de las conexiones QUIC no son forzados a esperar a que terminen las demás, lo cual reduce la latencia.

El equipo de Cisco grabó un interesante video explicando el handshake de 3 vías de TCP.

Como QUIC se deshace de las funciones de fiabilidad de TCP, las compensa un poco sobre la capa de UDP, ofreciendo la retransmisión de paquetes y algunos controles adicionales. El Google Cloud Platform introdujo soporte para QUIC para la carga de sus balanceadores en 2018 y vio una mejora en el tiempo de carga de página de un 8% global, y hasta 13% en regiones donde la latencia es más alta.

Entre Google Chrome, YouTube, Gmail, el buscador de Google y otros servicios, Google pudo desplegar QUIC en una gran parte del internet, sin tener que esperar por IETF. Los ingenieros de Google declaran que, en 2017, 7% del tráfico del internet siempre era realizado a través de QUIC.

La versión de QUIC de Google se enfocaba en sólo el transporte HTTP, utilizando una sintaxis de HTTP/2. La gente de IETF (aquellos a cargo de estandarizar QUIC), decidieron que la versión de QUIC de IETF debería poder transportar más que HTTP. Por el momento, sin embargo, cualquier trabajo en protocolos que no sean de HTTP a través de QUIC están a la espera.

Una cosa más, el grupo de trabajo de IETF decidió que la versión estandarizada usaría un cifrado TLSv1.3 en lugar de la solución personalizada de Google. TLSv1.3, comparado con versiones más viejas, contribuye a la velocidad del protocolo, ya que sus handshakes requieren rondas de verificación.

Ahora mismo, Google continúa usando su propia versión de QUIC en su producto, mientras dirige sus esfuerzos al desarrollo hacia los estándares de IETF. La mayoría de los otros jugadores del internet están construyendo sobre la versión de IETF. Ambos modelos difieren en algunos de los otros aspectos además del cifrado utilizado.

Si abrimos Chrome Dev Tools, y cargamos algunos de los productos de Google, como Gmail, en la columna de Protocolo de la pestaña de Red, veremos muchos de los recursos siendo cargados a través de la versión de Google del protocolo de QUIC. Este también es el caso de los productos de Google como las Analytics, Google Tag Manager, etc.

Google service QUIC

Cloudflare recientemente publicó una actualización bastante extensiva sobre la estandarización y progreso de QUIC.

Mientras que QUIC sobre UDP provee algunas ventajas, TCP ha sido el protocolo de moda desde hace años, así que los sistemas operativos y el stack de software no están preparados para UDP y no están optimizados para su uso. Consecuentemente, hay mucho mayor carga de CPU con QUIC y algunos han estimado que puede llegar al doble que HTTP/2.

Las optimizaciones deben ir hasta el núcleo de los sistemas operativos, y diferentes routers y firmwares de dispositivos. Esta guía de Red Hat muestra un poco sobre este tema para aquellos con más conocimientos técnicos.

Las conexiones QUIC combinan TLS y los handshakes de transporte. Una vez establecidos, son identificados por CID únicos (IDs conexión). Estos IDs persisten a través de los cambios de IP y pueden ayudar a asegurar descargas sin interrupción en, por ejemplo, un cambio de 4G a WiFi. Esto es relevante, particularmente porque más y más tráfico de Internet es realizado en dispositivos móviles.

TLS es obligatorio, y está hecho para hacer más difícil manipular o alterar el tráfico a través de MitM. Es por eso que no es tan raro ver proveedores de firewall y vendedores como Cisco viendo el protocolo UDP como un problema, e incluso proveen formas de deshabilitarlo, porque es más difícil para el intermediario inspeccionar, supervisar o filtrar el tráfico de QUIC.

Mientras que el QUIC es un protocolo de capa de transporte, HTTP funciona  sobre este como una capa aplicación. Ya que la compatibilidad retroactiva es uno de los puntos más importantes,  IETF promovió que la implementación de HTTP/3 incluya versiones anteriores (HTTP/1 y HTT/2) en la respuesta. Este incluirá un encabezado el cual informa al cliente que HTTP/3 está disponible, junto con información de Puerto/Host, como está descrito en el RFC 7838.

Esto es diferente a HTTP/2, en donde el transporte puede ser negociado dentro del handshake del TLS. Pero ya que IETF ha aceptado HTTP/3 basado en QUIC, como el próximo estándar, podemos esperar que los clientes web agreguen soporte para HTTP/3 cada vez más a menudo.

Resumen

Hay aquellos que piensan que, considerando que el estándar de HTTP/2 aún no ha sido adoptado por completo, podría ser muy pronto intentar promover HTTP/3 (tercera versión). Este es un punto válido, pero, como lo mencionamos, este protocolo ha tenido grandes pruebas e implementaciones. Google comenzó a hacer pruebas a partir de 2015, y Facebook en el 2017.

Desde entonces, otros jugadores se han unido a los esfuerzos de estandarización, como Akamai y Mozilla. En un hackathon de IETF de noviembre del 2018, la lista de visitantes mostró el interés que hay por QUIC por parte de compañías como Facebook, Apple, Google, Mozilla, NetApp y LiteSpeed Tech.

Hubo muchas pruebas prometedoras, Cloudflare también se encuentra probando con QUIC en una beta y, al poco tiempo después de esto, QUIC recibió el nombre de HTTP/3 en el Plan Preliminar del Internet por la IETF.

Fuente: Kinsta

Suscríbete a nuestro Boletín