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.

Los primeros resultados son prometedores, y cuando expire el Plan Preliminar del Internet por IETF, en Junio del 2019, podemos esperar que HTTP/3 sea promovido como el nuevo estándar de tercera generación de HTTP.

• 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.

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. También obtuvimos más flexibilidad en el ordenamiento de descargas estáticas, y nuestras páginas ahora ya no están siendo limitadas por una progresión lineal de las descargas.

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.

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.

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 esto incurrió a una computación superior que hizo que las mejoras de velocidad fueran 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.

Para elaborar esto, analizaremos el stack del protocolo del internet de hoy en día, desde su punto más bajo hasta el más alto. 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.

Todas estas cosas indican muchos pasos que hacen de TCP un protocolo fiable, haciendo la base de los servicios más notorios del internet que usamos hoy en día.

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

La fiabilidad que TCP provee no hace esto, sin embargo, viene sin costo alguno. La sobrecarga de todos los roundtrips requeridos por los handshakes, retroalimentación entregada, garantía de órdenes, y suma de comprobación que podrían ser considerados débiles y redundantes. Ha 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 además de TCP.

Cambiar el TCP de una forma substancial no es una acción sencilla, porque el protocolo es, como parte del stack de TCP/IP que data hasta los 70s. Está profundamente arraigada a 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 habrán handshakes y no habrá garantía de ordenanzas o de entrega. Esto quiere decir que cualquier paso posible para asegurar una entrega, integridad de datos, y otras cosas, estas se dejan a la capa de la aplicación. Esto quiere decir que una aplicación construida sobre el UDP puede elegir estrategias, este empleará dependiendo del caso concreto, o posiblemente pueda recurrir a elementos de la capa del enlace, como la suma de comprobación, para evitar una sobre carga.

Considerando que UDP es tan extenso como TCP, hace que sea posible archivar mejorar 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.

El despliegue de nuevos protocolos es obstaculizado por muchos firewalls, NATs, routers y otras cajas-medias que sólo permiten que el TCP o UDP sea desplegado entre usuarios y los servidores a los que necesitan llegar. – HTTP/3 explicado

Este artículo en Hacker News puede ayudarle a entender el razonamiento detrás de la construcción de una nueva versión de HTTP sobre el ya existente stack de la red, en lugar de reinventarlo (aunque si es un poco más complejo que eso).

La especificación del formato del paquete de UDP es relativamente mínima, su encabezado consiste del puerto fuente, puerto destino, largo, en bytes, del encabezado del paquete o datos del paquete, y la suma de comprobación. La suma de la comprobación puede ser usada para verificar la integridad de datos para la parte del encabezado y la de los datos del paquete.

La suma de comprobación es opcional cuando la capa del protocolo subyacente es IPv4, y una IPv6 obligatoria. Até agora, o UDP tem sido usado para coisas como a sincronização de relógio de sistemas de computador (NTP), aplicaciones VoIP, streaming de video, sistema DNS y 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 los sistemas de todo el internet.

Justo como con HTTP/2, un adelanto, el cual ha sido lanzado por el SPDY o speedy de Google, HTTP/3 de nuevo, será construido sobre estos logros.

Mientras que HTTP/2 nos dio multiplexación, y el poder mitigar el head-of-line-blocking, este es limitado por TCP. Usted puede utilizar una sola conexión TCP para múltiples flujos multiplexados juntos 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 perdida es retransmitido. Daniel Stenberg en su libro sobre http/3 llama a esto como un “TCP- based head of like block.” El declara que, con el 2% de pérdida de paquete, a los usuarios les irá mejor con HTTP/1, con seis conexiones para cubrir el riesgo.

QUIC no está limitado por esto. Con QUIC construyendo sobre los protocolos UDP sin conexión, el concepto de conexión no carga las limitaciones de TCP y las fallas de un flujo no tienen que influenciar al resto.

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. Nuevos flujos dentro de las conexiones QUIC no son forzadas a esperar a que terminen las demás. Las conexiones QUIC se benefician al hacer esto con la sobrecarga de handshake de TCP, lo cual reduce la latencia.

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

Mientras que QUIC se deshace de las funciones de fiabilidad de TCP, compensa un poco sobre la capa de UDP, ofreciendo la retransmisión de paquetes, ordenanza y más. 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 EIFT. 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 un 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á una encriptación TLS 1.3 en lugar de la solución personalizada de Google. TLS 1.3, comparado a versiones más viejas, esto también contribuye a la velocidad del protocolo, ya que sus handshakes requieren menos viajes redondos.

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

Si nosotros abrimos Chrome Dev Tools, y cargamos algunos de los productos de Google, como Gmail, en la columna de Protocolo de la pestaña de la 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 Analíticas, el Google Tag Manager, etc.

Cloudflare recientemente publicó una actualización bastante extensiva sobre la estandarización del progreso.

Mientras que UDP si provee QUIC y HTTP/3 algunas ventajas inherentes, igual trae algunos retos. TCP ha sido el protocolo de moda desde hace años, mientras que UDP no lo ha sido, así que los sistemas operativos y el stack del software para esto, en general, no está tan optimizado. Consecuentemente, hay mucho mayor carga de CPU/requisitos con QUIC, por algunos estimados, el doble que HTTP/2.

Las optimizaciones van muy al fondo al núcleo de los sistemas operativos, y diferentes routers y firmwares de dispositivos. Esta guía de arreglo de Red Hat podría mostrar un poco sobre este tema para aquellos con más conocimientos técnicos.

Conexiones QUIC, que mencionamos anteriormente, combinan el 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 del internet es realizado en dispositivos móviles. Las preguntas podrán surgir, si este elemento es concebido por Google para facilitar un mejor rastreo de usuario a través de distintas conexiones y proveedores de internet.

TLS es obligatorio, y está hecho para hacer más difícil a los dispositivos que se encuentren como intermediarios de manipular o alterar el tráfico. Es por eso que no es tan raro ver proveedores de firewall y vendedores como Cisco viendo el protocolo UDP como un problema, y para proveer formas para deshabilitarlo, es más difícil para el intermediario inspeccionar y supervisar o filtrar el tráfico de QUIC.

Los flujos de QUIC son enviados a través de conexiones QUIC, uni-direccionales o bi-direccionales. Los flujos tienen IDs, que identifican al iniciador, y si el flujo es uni-direccional o bi-direccional, y también sirve como control de flujo.

Mientras que el QUIC es un protocolo de capa de transporte, HTTP es la capa sobre este, una capa de protocolo de aplicación o protocolo de aplicación.

Ya que la compatibilidad retroactiva es uno de los puntos más importantes, el IEFT promovió que la implementación de HTTP/3 incluya la vieja versión (HTT1 o 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 adoptado el HTTP/3 basado en QUIC, como el próximo estándar, podemos esperar que los clientes web anticipen el soporte a HTTP/3 cada vez más a menudo. Es posible para los clientes de almacenar los datos en el caché de previas conexiones de HTTP/3, y para conectar directamente (viaje redondo cero, o 0RTT) o visitas subsecuentes al mismo host.

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 todavía 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 el último hackathon de IETF de Noviembre del 2018, la lista de visitantes mostró el interés que hay en QUIC por parte de compañías como Facebook, Apple, Google, Mozilla, NetApp y LiteSpeed Tech. Hubo unas pruebas prometedoras, y parece que LiteSpeed podría ser el mayor vendedor de servidores con un servidor funcional de HTTP/3. Cloudflare también se encuentra probando con QUIC en una beta.

Poco tiempo después de esto, QUIC recibió el nombre de HTTP/3 en el Plan Preliminar del Internet por la IEFT. Este expirará a finales de junio de 2019, y podemos esperar que el RFC, o el último estándar llegue aproximadamente en julio.

Fuente: Kinsta