TL;DR
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 estás utilizando Chrome y te estás conectando al servicio de Google, probablemente ya te encuentres 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 Agosto del 2021, podemos esperar que HTTP/3 sea promovido como el nuevo estándar de tercera generación de HTTP.
Progreso de HTTP/3 en 2024
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.
Hace unos años, publicamos un artículo sobre HTTP/2, un estándar que, según W3Techs, ha alcanzado ya una tasa de adopción mundial cercana al 45%. Y de acuerdo con 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.
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 «Internet Draft» de HTTP/3 es la última fase antes de que las propuestas sean promovidas al nivel de Solicitud de Comentarios (o RFC), que podemos considerar, a todos los efectos, definiciones oficiales del protocolo de Internet.
Aunque HTTP/3 todavía no es un protocolo oficial de Internet, muchas empresas y proyectos ya han empezado a añadir soporte para HTTP/3 en sus productos.
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.
Soporte de navegadores para HTTP/3
En cuanto a los navegadores web, Chrome v87, Firefox v88 y Edge v87 tienen HTTP/3 activado por defecto. Para los usuarios de Safari, la opción de activar HTTP/3 se añadió en Safari Technology Preview v104. Sin embargo, el soporte de HTTP/3 no está disponible actualmente en la versión estable de Safari.
Soporte de bibliotecas para HTTP/3
Para los desarrolladores que deseen aprovechar las tecnologías HTTP/3, muchas bibliotecas populares ya han añadido soporte para HTTP/3. Dado que HTTP/3 aún se encuentra en la etapa de borrador de Internet, deberás asegurarte de estar al tanto de las últimas actualizaciones cuando trabajes con una de las bibliotecas que aparecen a continuación.
- Python – http3 y aioquic
- Rust – quiche, neqo, y quinn
- C – nghttp3 y lsquic
- Go – quicgo
- JavaScript – Node.js
Soporte de infraestructura para HTTP/3
En el lado de la infraestructura, Cloudflare ha estado liderando la compatibilidad con HTTP/3 en toda su red de borde. Esto significa que los sitios con Cloudflare habilitado pueden aprovechar las mejoras de seguridad y rendimiento de HTTP/3 sin ningún trabajo adicional.
En Kinsta, todos los sitios que alojamos están protegidos por nuestra integración gratuita con Cloudflare. Además de un cortafuegos de nivel empresarial y protección DDoS, ¡los clientes de Kinsta también tienen acceso a HTTP/3!
Para probar si tu sitio es compatible con HTTP/3, puedes utilizar la herramienta de prueba HTTP/3 de Geekflare. Simplemente escribe tu dominio y pulsa el botón «Check HTTP/3», y la herramienta te dirá si tu sitio es compatible con HTTP/3.
Si tu sitio es compatible con HTTP/3, deberías ver un mensaje como el siguiente. Como kinstalife.com está alojado en Kinsta, HTTP/3 es totalmente compatible gracias a nuestra integración con Cloudflare.
También puedes utilizar el inspector de tu navegador para comprobar si es compatible con HTTP/3. Para este ejemplo, usaremos la última versión de Google Chrome que soporta HTTP/3.
Para abrir el inspector, haz clic con el botón derecho del ratón en la página y haz clic en «Inspeccionar» y navega hasta la pestaña «Red». En la columna «Protocolo», puedes ver el protocolo HTTP utilizado para la conexión. Las conexiones HTTP/2 aparecen como «h2», mientras que las conexiones HTTP/3 aparecen como «h3-XX» (XX se refiere a un borrador específico de HTTP/3). Como puedes ver en la imagen de abajo, kinstalife.com soporta conexiones sobre «h3-29», que significa «HTTP/3 Draft 29».
Ahora que hemos repasado el estado actual de HTTP/3, vamos a profundizar en algunas de las diferencias entre HTTP/2 y 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.
Agrega 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.
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 tu simplemente puedes 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úrate 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.
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.
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 35% desde junio del 2021.
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.
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.
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.
Dado que UDP está muy extendido, al igual que TCP, permite conseguir mejoras sin necesidad de actualizar el firmware de una amplia gama de dispositivos conectados a Internet, ni de realizar cambios significativos en 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 se ha utilizado para cosas como la sincronización del reloj de los sistemas informático (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.” Él 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.
Como lo dijo Lucas Pardue de Cloudflare:
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 declararon que, en 2017, el 7% del tráfico del internet siempre fue 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. Kinsta soporta TLS 1.3 en todos nuestros servidores y en nuestra Kinsta CDN.
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.
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, unidireccionales o bidireccionales. Los flujos tienen IDs, que identifican al iniciador, y si el flujo es unidireccional o bidireccional, 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. 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.
En 2024, tenemos soporte para HTTP/3 en los principales navegadores como Google Chrome y Brave. En cuanto a la infraestructura, servidores web como Litespeed y Nginx tienen implementaciones de HTTP/3 que funcionan, mientras que proveedores de red como Cloudflare ya han desplegado un soporte completo para HTTP/3.
En este momento, HTTP/3 está todavía en fase de borrador de Internet, y la revisión más reciente expirará en agosto de 2021. Este año será emocionante, ya que podemos esperar ver el movimiento de los principales proveedores de software para implementar el nuevo estándar.
Tonino is an entrepreneur, Linux & OSS enthusiast, developer, and tech educator. He has over ten years of experience in development and has been in the blockchain space for 3+ years. When he's not coding, he writes for SitePoint and Alibaba Cloud, binge-watches the newest works of fiction on Netflix, and explores new travel destinations.
Deja una respuesta