En Noviembre del 2018, el Internet Engineering Task Force (IETF) se junto en Bangkok, y se adoptó un nuevo Plan Preliminar para el Internet. El protocolo de transporte QUIC, un sucesor de HTTP/2, se le cambió el nombre a HTTP/3. HTTP3/3 utiliza UDP como base, y ya está siendo usado por compañías prominentes del internet como Google y Facebook. Si usted está utilizando Chrome y se está conectando al servicio de Google, probablemente ya se encuentre utilizando QUIC.

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.

Como con HTTP/2, HTTP/3 empezará a construir de nuevo sobre estos logros para ayudar a hacer más rápida la red. 🚀 Haga clic para Tweet

HTTP/3 Está por Llegar

Algunos dicen que el hambre de la industria de la red por obtener más velocidad y baja latencia sólo es igualada por el hambre por más RAM de Google Chrome.

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.

Uso de HTTP/2

Uso de HTTP/2

HTTP/3 es, al momento de que escribimos este artículo, un Plan Preliminar o ID para el Internet por parte del IETF, lo cual quiere decir que está actualmente bajo consideración para un próximo estándar de internet por el Internet Engineering Task Force – un cuerpo de estándares internacionales del internet, a cargo de definir y promover estándares de protocolo para el internet, como el uso de TCP, IPv6, VoIP, Internet of Things, etc.

Es un cuerpo abierto el cual une la industria del internet y facilita la discusión sobre la dirección a donde se dirige el internet.

Actualmente, la fase de ID de HTTP/3 está en sus últimos pasos, antes de que se hagan las propuestas al nivel de RFC-s, o Petición para Comentarios, las cuales podemos considerar, para todas las intenciones y propósitos, las definiciones oficiales del protocolo del internet. Luego son implementadas por todos los jugadores más importantes en el internet.

Esto quiere decir que HTTP/3 se convertirá en el estándar oficial una vez que el Plan Preliminar expire a mediados de este año (Junio 2019).

Un Poco de Su Pasado – Todo Empezó con HTTP/2

En Kinsta estamos obsesionados por sacar cada milisegundo de nuestro stack, sea que esté tomando ventaja de nuestra más reciente versión de PHP, entregando datos a través de la red premium del Google Cloud Platform, o almacenando activos en el caché en nuestro HTTP/2 CDN.

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.

Empujando a HTTP/2

Empujando a HTTP/2

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

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

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

Digamos que los primeros días de adopción de esta versión, no fueron para los débiles de corazón.

La implementación de NGINX también carecía de la función de server-push, dependiendo de un módulo. Y los módulos de NGINX no son sus módulos usuales de Apache, que usted simplemente puede copiar – NGINX también puede ser recompilado con estos.

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.

Protocolo de Internet (IP)

El Protocolo de Internet (IP) define la parte inferior de toda la topología del internet. Es parte del stack del internet que es, y podemos decir con toda seguridad, completamente no negociable, sin tener que cambiar todo, incluyendo el tener que reemplazar toda la infraestructura del hardware, desde los routers a servidores e incluso las maquinas del usuario final.

Así que, mientras que esta mejora del protocolo ya se había tardado, tal acción no se encuentra en el horizonte por el momento, principalmente porque no hemos pensando en una alternativa viable, innovadora y compatible.

Debajo de todo esto, está la capa del enlace– la parte del protocolo que es el “metal expuesto”, si así le podemos decir.

Tocando otro tema, un caso muy convincente para una mejora total, puede ser visto al fijarse en la velocidad en la que los creadores del IPFS (interplanetary file system) han logrado acercarse a una inversión ICO que les otorgó unos 250 millones de dólares americanos en un mes.

Podemos rastrear los principios del protocolo IP hasta el año de 1974, en un documento publicado por el Institute of Electrical and Electronics Engineers, con Vint Cerf y Bob Cahn como autores. Este detalla los paquetes siendo enviados a través de una red, pasándolos a través de direcciones IP, y direcciones numéricamente definidas de nodos en una red/redes. El protocolo definió el formato de estos paquetes o datagramas – sus encabezados y cargas.

Después de la definición de RFC 760 de 1980, el IETF se quedó con la definición ampliamente usada hasta este día, en su Petición para recibir Comentarios 791. Esta es la cuarta versión del protocolo, pero podríamos decir que es la primera versión de producción.

Protocolo de Internet (RFC791)

Protocolo de Internet (fuente de la imagen: RFC791)

Este utiliza direcciones de 32-bit, la cual pone ciertas limitantes al número de direcciones a 4 mil millones. Esta limitación es la explicación para el misterio sobre por qué los usuarios comunes obtienen unas “direcciones dinámicas de IP” por sus Proveedores de Internet, y una IP estática es considerada un “valor agregado” y usualmente es sujeto a recibir cambios adicionales.

Lo están racionando.

No pasó mucho tiempo hasta que se dio por entendido que las direcciones de 32-bit no eran suficientes, y que se estaba acercando un desabasto, así que muchos RFCs fueron publicados, intentando lidiar con esto. A pesar de que estas soluciones son ampliamente usadas hoy en día, y son parte de nuestro día a día, es probablemente seguro asumir que estos son mayormente hacks.

La versión 6 del Protocolo de Internet o IPv6 surgió como una forma para lidiar con estas limitaciones, incluyendo la de gradualmente ser adoptada por todas las versiones pasadas. Lo hicieron parte estándar de este Plan Preliminar para el IETF en 1998, y fue puesto como Estándar el Internet en el 2017.

Mientras que las direcciones de IPv4 estuvieron limitadas por el largo de sus direcciones de 32-bits, el estándar de IPv6 recibió 128 bits, o 3.4 * 10 ^38 posibles direcciones. Esto debería ser suficiente para que nos dure un buen rato.

De acuerdo a Google y la conectividad de IPv6 entre sus usuarios, la adopción de IPv6 está por arriba de un 25% desde marzo del 2019.

Adopción de IPv6

Adopción de IPv6

IP es una capa rudimentaria del stack del internet, definiendo las cosas más básicas, sin garantías de entrega, integridad de datos, o el ordenamiento de los paquetes transmitidos. Por sí solo no es muy confiable. El formato de encabezado de IPv4 provee una suma de comprobación del encabezado, los cuales utilizan los nodos de transmisión para verificar la integridad del encabezado. Esto lo hace distinta de la versión de IPv6, la cual depende de la capa de enlace que se encuentra por debajo, permitiendo que sea más rápido.

Internet Datagram Header

Encabezado del Datagrama del Internet (fuente de la imagen: RFC791)

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. Hasta ahora, UDP, ha sido usado por 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.

Stack HTTP/2 vs stack HTTP/3

Stack HTTP/2 vs stack HTTP/3

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.

¿Luchando con el tiempo de inactividad y los problemas de WordPress? Kinsta es la solución de alojamiento diseñada para ahorrarle tiempo! Vea nuestras características

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.

Como lo dijo Lucas Pardue de Cloudflare:

Lucas Pardue sobre HTTP/3

Lucas Pardue sobre HTTP/3

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.

Google service QUIC

Google service QUIC

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.

Podríamos decir que QUIZ intenta re-construir todas las funciones TCP además de un protocolo más simple y flexible.

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.

Este año será emocionante, ya que podemos esperar ver el movimiento por parte de los vendedores de software más importante, un cambio para implementar el nuevo estándar.

¿Cuándo Estará Disponible HTTP/3 en Kinsta?

Una vez que haya sido finalizado el RFC (verano de 2019) y Ngnix oficialmente soporte QUIC, ¡podrá tener por garantizado que el equipo de Kinsta estará en todo esto! Cuando esté listo para ir en producción lo estaremos implementando.