HTTP/3: el pasado, el presente y el futuro

Durante la semana del aniversario del año pasado,anunciamos el soporte preliminar para QUIC y HTTP/3 (o "HTTP sobre QUIC" como se conocía en aquel entonces), el nuevo estándar para la web, que permite conexiones más rápidas, más confiables y más seguras a los puntos de conexión web, tales como sitios web y API. También permitimos que nuestros clientes se unan a una lista de espera para probar QUIC y HTTP/3 tan pronto como estén disponibles.

Desde entonces, hemos estado trabajando con colegas de la industria a través del Grupo de trabajo de ingeniería de Internet, incluidos Google Chrome y Mozilla Firefox, para profundizar en los documentos estándares HTTP/3 y QUIC. Paralelamente a la maduración de los estándares, también hemos trabajado para mejorar el soporte en nuestra red.

En este momento nos complace anunciar que el soporte de QUIC y HTTP/3 ya está disponible en la red perimetral de Cloudflare. Nos entusiasma de que Google Chrome y Mozilla Firefox, dos de los principales proveedores y socios de navegadores, se unan a nuestro esfuerzo por hacer que la web sea más rápida y confiable para todos.

Las palabras de Ryan Hamilton, ingeniero de software del personal de Google, fueron: “HTTP/3 debería mejorar la web para todos. Los equipos de Chrome y Cloudflare han trabajado juntos para llevar HTTP/3 y QUIC de estándares nacientes a tecnologías ampliamente adoptadas para mejorar la web. Una sólida asociación entre los líderes de la industria es lo que hace posible las innovaciones en los estándares de Internet y esperamos ansiosamente seguir trabajando juntos”.

¿Qué significa esto para usted, un cliente de Cloudflare que utiliza nuestros servicios y nuestra red perimetral para hacer que la presencia de su web sea más rápida y segura? Una vez que se habilita la compatibilidad con HTTP/3 para su dominio en el panel de Cloudflare, sus clientes pueden interactuar con sus sitios web y API al usar HTTP/3. Hemos estado invitando continuamente a los clientes en nuestra lista de espera HTTP/3 para que activen la función (así que esté atento a un correo electrónico de nuestra parte) y en las próximas semanas pondremos la función a disposición de todos.

¿Qué significa este anuncio si usted es un usuario de Internet que interactúa con sitios y API mediante un navegador y otros clientes? A partir de hoy, puede usar Chrome Canary para interactuar con Cloudflare y otros servidores por medio de HTTP/3. Para aquellos de ustedes que buscan un cliente de línea de comandos, curl también ofrece soporte para HTTP/3. Las instrucciones para usar Chrome y curl con HTTP/3 se encuentran más adelante en esta publicación.

Históricamente, la innovación de estándares en Internet ha sido difícil debido a un problema de tipo “El huevo o la gallina”: ¿qué debe ser primero, el soporte del servidor (como Cloudflare u otras grandes fuentes de datos de respuesta) o el soporte del cliente (como navegadores, sistemas operativos, etc.)? Ambos lados de una conexión deben admitir un nuevo protocolo de comunicaciones para que tenga alguna utilidad.

Cloudflare tiene un largo historial de impulsar estándares web, desde HTTP/2 (la versión de HTTP anterior a HTTP/3) hasta TLS 1.3 y cosas como SNI cifrado. Hemos impulsado los estándares al asociarnos con organizaciones afines que comparten nuestro deseo de ayudar a crear una mejor Internet. Nuestros esfuerzos para introducir HTTP/3 en el centro de todo no son diferentes.

A lo largo del proceso de desarrollo de estándares HTTP/3, hemos estado trabajando estrechamente con socios de la industria para crear y validar el soporte HTTP/3 del cliente que es compatible con nuestro soporte perimetral. Estamos contentos de habernos asociado con Google Chrome y curl, que se pueden usar hoy en día para realizar solicitudes perimetrales de Cloudflare a través de HTTP/3. Mozilla Firefox también espera proporcionar soporte pronto en un lanzamiento nocturno.

En resumen: hoy es un buen día para los usuarios de Internet; la implementación generalizada de HTTP/3 dará lugar a una experiencia web más rápida para todos, y el soporte de hoy es un gran paso para lograrlo.

Más importante aún, hoy es un buen día para Internet: El hecho de que Chrome, curl y Cloudflare, y próximamente Mozilla, realicen la implementación experimental, pero funcional, del soporte para HTTP/3 en una rápida sucesión demuestra que el proceso de creación de estándares de Internet funciona. Coordinado por el Grupo de trabajo de ingeniería de Internet, los socios de la industria, los competidores y otras partes interesadas clave pueden unirse para elaborar estándares que beneficien a todo Internet y no solo a los gigantes.

Eric Rescorla, directora de Tecnología de Firefox, lo resumió muy bien: “Desarrollar un nuevo protocolo de red es difícil y hacerlo bien requiere que todos trabajen juntos. En los últimos años, hemos estado trabajando con Cloudflare y otros socios de la industria para probar TLS 1.3 y actualmente HTTP/3 y QUIC. El soporte inicial del servidor de Cloudflare para estos protocolos nos ha ayudado a resolver los problemas de interoperabilidad de nuestra implementación de Firefox desde el lado del cliente. Esperamos que juntos promovamos la seguridad y el rendimiento de Internet”.

Antes de profundizar en HTTP/3, echemos un vistazo rápido a la evolución de HTTP a lo largo de los años con el fin de comprender mejor por qué se necesita HTTP/3.

Todo comenzó en 1996 con la publicación de la especificación HTTP/1.0 que definía el formato básico de transmisión de texto HTTP, tal como lo conocemos hoy (para los efectos de esta publicación, estoy fingiendo que HTTP/0.9 nunca existió). En HTTP/1.0 se crea una nueva conexión TCP para cada intercambio de solicitud/respuesta entre los clientes y los servidores, lo que significa que todas las solicitudes incurren en una penalización de latencia a medida que se completan los protocolos de enlace TCP y TLS antes de cada solicitud.

Peor aún, en lugar de enviar todos los datos pendientes lo más rápido posible una vez que se establece la conexión, TCP aplica un período de calentamiento llamado "inicio lento", que permite que el algoritmo de control de congestión TCP determine la cantidad de datos que pueden estar en proceso en cualquier momento antes de que ocurra la congestión en la ruta de la red, y evitar así inundar la red con paquetes que no puede manejar. Pero debido a que las nuevas conexiones tienen que pasar por el proceso de inicio lento, no pueden usar todo el ancho de banda de red disponible de inmediato.

La revisión HTTP/1.1 de la especificación HTTP trató de resolver estos problemas unos años más tarde al introducir el concepto de conexiones "keep-alive", que permiten a los clientes reutilizar las conexiones TCP, y así amortizar el costo del establecimiento de la conexión inicial y el inicio lento en múltiples solicitudes. Pero esto no fue una fórmula milagrosa: si bien varias solicitudes podían compartir la misma conexión, aún tenían que ser serializadas una tras otra, por lo que un cliente y un servidor solo podían ejecutar un único intercambio de solicitud/respuesta en un momento dado para cada conexión.

A medida que la web evolucionó, los navegadores se dieron cuenta que necesitaban más y más competitividad al buscar y procesar páginas web a medida que la cantidad de recursos (CSS, JavaScript, imágenes...) requeridos por cada sitio web aumentaba con los años. Pero ya que HTTP/1.1 solo permitía a los clientes hacer un intercambio de solicitud/respuesta HTTP a la vez, la única forma de obtener competitividad en la capa de red era usar múltiples conexiones TCP al mismo origen en paralelo, lo que resultaba en la pérdida de la mayoría de los beneficios de las conexiones de mantenimiento. Si bien las conexiones aún se podían volver a utilizar en cierta medida (pero en menor grado), volvimos al punto de partida.

Finalmente, más de una década después, llegó SPDY y luegoHTTP/2, que, entre otras cosas, introdujo el concepto de "secuencias" HTTP: una abstracción que permite que las implementaciones HTTP multiplexen simultáneamente diferentes intercambios HTTP en la misma conexión TCP, que permite a los navegadores volver a utilizar de manera más eficiente las conexiones TCP.

Pero, una vez más, ¡esto no era una fórmula mágica! HTTP/2 resuelve el problema original —el uso ineficiente de una sola conexión TCP— ya que ahora se pueden transmitir múltiples solicitudes/respuestas a través de la misma conexión al mismo tiempo. Sin embargo, todas las solicitudes y respuestas se ven igualmente afectadas por la pérdida de paquetes (por ejemplo, debido a la congestión de la red), inclusive si los datos que se pierden solo se relacionan con una sola solicitud. Esto se debe a que, si bien la capa HTTP/2 puede segregar diferentes intercambios HTTP en secuencias separadas, TCP no tiene conocimiento de esta abstracción y todo lo que ve es una secuencia de bytes sin un significado particular.

La función de TCP es entregar el flujo completo de bytes, en el orden correcto, de un punto de conexión a otro. Cuando un paquete TCP que transporta algunos de esos bytes se pierde en la ruta de la red, crea un espacio en el flujo y TCP necesita llenarlo al reenviar el paquete afectado cuando se detecta la pérdida. Al hacerlo, ninguno de los bytes entregados con éxito, que siguen a los perdidos, se pueden entregar a la aplicación, incluso si no se perdieron y pertenecen a una solicitud HTTP completamente independiente. Por lo tanto, se terminan retrasando innecesariamente ya que TCP no puede saber si la aplicación podría procesarlos sin los bits que faltan. Este problema se conoce como "bloqueo de cabeza de línea".

Aquí es donde entra en juego HTTP/3: en lugar de usar TCP como la capa de transporte para la sesión, utiliza QUIC, un nuevo protocolo de transporte de Internet, que, entre otras cosas, introduce secuencias como ciudadanos de primera clase en la capa de transporte. Las secuencias QUIC comparten la misma conexión QUIC, por lo que no se requieren protocolos de enlace adicionales e inicios lentos para crear nuevas, pero las secuencias QUIC se entregan de forma independiente de modo que en la mayoría de los casos la pérdida de paquetes que afecta a una secuencia no afecta a otras. Esto es posible porque los paquetes QUIC están encapsulados en la parte superior de los datagramas UDP.

El uso de UDP permite mucha más flexibilidad en comparación con TCP y permite que las implementaciones de QUIC se radiquen por completo en el espacio del usuario: las actualizaciones de las implementaciones del protocolo no están vinculadas a las actualizaciones de los sistemas operativos, como es el caso con TCP. Con QUIC, las secuencias de nivel HTTP se pueden mapear simplemente sobre las secuencias de QUIC para obtener todos los beneficios de HTTP/2 sin el bloqueo de cabeza de línea.

QUIC también combina el típico protocolo de enlace TCP de 3 vías con el protocolo de enlace TLS 1.3. La combinación de estos pasos significa que el cifrado y la autenticación se proporcionan de manera predeterminada y también permite un establecimiento de conexión más rápido. En otras palabras, incluso cuando se requiere una nueva conexión QUIC para la solicitud inicial en una sesión HTTP, la latencia incurrida antes de que los datos empiezan a fluir es menor que la de TCP con TLS.

Pero, ¿por qué no usar HTTP/2 además de QUIC, en lugar de crear una revisión HTTP completamente nueva? Después de todo, HTTP/2 también ofrece la función de multiplexación de flujo. Resulta que es algo más complicado que eso.

Si bien es cierto que algunas de las características de HTTP/2 pueden asignarse fácilmente a QUIC, eso no es cierto para todas. Una en particular, el esquema de compresión de encabezado de HTTP/2 llamado HPACK, depende en gran medida del orden en que se envían las diferentes solicitudes y respuestas HTTP a los puntos de conexión. QUIC aplica el orden de entrega de bytes dentro de las secuencias individuales, pero no garantiza el orden entre las diferentes secuencias.

Este comportamiento requirió la creación de un nuevo esquema de compresión de encabezado HTTP, llamado QPACK, que soluciona el problema pero que requiere cambios en la asignación HTTP. Además, algunas de las características que ofrece HTTP/2 (como el control de flujo por flujo) ya las ofrece QUIC, por lo que se quitaron de HTTP/3 para eliminar la complejidad innecesaria del protocolo.

QUIC y HTTP/3 son estándares muy interesantes, que prometen abordar muchas de las deficiencias de los estándares anteriores y marcan el inicio de una nueva era de rendimiento en la web. Entonces, ¿cómo pasamos de documentos de estándares interesantes a una implementación funcional?

El soporte QUIC y HTTP/3 de Cloudflare funciona con quiche, nuestra propia implementación de código abierto escrita en Rust.

Lo puede encontrar en GitHub en github.com/cloudflare/quiche.

Anunciamos quiche hace unos meses y desde entonces hemos agregado soporte para el protocolo HTTP/3, además del soporte QUIC existente. Hemos diseñado quiche de tal manera que ahora se puede usar para implementar clientes y servidores HTTP/3 o simplemente QUIC.

Como se mencionó anteriormente, hemos empezado a incorporar clientes que se registraron en la lista de espera. Si está en la lista de espera y ha recibido un correo electrónico de nosotros informándole que ahora puede habilitar la función para sus sitios web, simplemente vaya al panel de control de Cloudflare y active el interruptor de la pestaña "Red" manualmente:

Esperamos que la función HTTP/3 esté disponible para todos los clientes en el futuro cercano.

Una vez habilitado, usted puede experimentar con HTTP/3 de varias maneras:

Para poder usar el navegador Chrome para conectarse a su sitio web a través de HTTP/3, primero debe descargar e instalar la última versión de Canary. Entonces, todo lo que necesita hacer para habilitar el soporte HTTP/3 es iniciar Chrome Canary con los argumentos de la línea de comandos "--enable-quic" y "--quic-version=h3-23".

Una vez que Chrome se inicia con los argumentos necesarios, puede escribir su dominio en la barra de direcciones y verlo cargado a través de HTTP/3 (puede usar la pestaña Red en las Herramientas para desarrolladores de Chrome para verificar qué versión de protocolo se usó). Tome en cuenta que debido a la forma en que se negocia HTTP/3 entre el navegador y el servidor, es posible que HTTP/3 no se utilice para las primeras conexiones al dominio, por lo que debe intentar volver a cargar la página varias veces.

Si esto le parece muy complicado, no se preocupe ya que el soporte de HTTP/3 en Chrome se volverá más estable a medida que pase el tiempo y habilitar HTTP/3 será más fácil.

Esto es lo que muestra la pestaña Red en las Herramientas para desarrolladores al navegar por este mismo blog a través de HTTP/3:

Tome en cuenta que debido a la naturaleza experimental del soporte HTTP/3 en Chrome, el protocolo se identifica realmente como "http2+quic/99" en las Herramientas para desarrolladores, pero no permita que eso lo engañe porque de hecho es HTTP/3.

La herramienta de línea de comandos curl también admite HTTP/3 como una característica experimental. Deberá descargar la última versión de git y seguir las instrucciones sobre cómo habilitar HTTP/3 support.

Si está ejecutando macOS, también facilitamos la instalación de una versión de curl que cuenta con HTTP/3 a través de Homebrew:

Para realizar una solicitud HTTP/3, lo único que debe hacer es agregar el indicador de línea de comando "--http3" a un comando curl normal:

 % brew install --HEAD -s https://raw.githubusercontent.com/cloudflare/homebrew-cloudflare/master/curl.rb

 % ./curl -I https://blog.cloudflare.com/ --http3
HTTP/3 200
date: Tue, 17 Sep 2019 12:27:07 GMT
content-type: text/html; charset=utf-8
set-cookie: __cfduid=d3fc7b95edd40bc69c7d894d296564df31568723227; expires=Wed, 16-Sep-20 12:27:07 GMT; path=/; domain=.blog.cloudflare.com; HttpOnly; Secure
x-powered-by: Express
cache-control: public, max-age=60
vary: Accept-Encoding
cf-cache-status: HIT
age: 57
expires: Tue, 17 Sep 2019 12:28:07 GMT
alt-svc: h3-23=":443"; ma=86400
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 517b128df871bfe3-MAN

Finalmente, también proporcionamos un ejemplo de cliente de línea de comandos HTTP/3 (así como un servidor de línea de comandos) creado sobre quiche, que puede usar para experimentar con HTTP/3.

Para que funcione, primero clone el repositorio GitHub de quiche:

Luego, créelo. Para que esto se realice correctamente, necesita una instalación de Rust y Cargo en funcionamiento (recomendamos usar Rustup para configurar fácilmente un entorno de desarrollo de Rust en funcionamiento).

$ git clone --recursive https://github.com/cloudflare/quiche

Y finalmente puede ejecutar una solicitud HTTP/3:

$ cargo build --examples

$ RUST_LOG=info target/debug/examples/http3-client https://blog.cloudflare.com/

En los próximos meses estaremos trabajando para mejorar y optimizar nuestra implementación de QUIC y HTTP/3, y eventualmente permitiremos que todos habiliten esta nueva función sin tener que pasar por una lista de espera. Continuaremos actualizando nuestra implementación a medida que evolucionen los estándares, lo que puede resultar en cambios importantes entre las versiones preliminares de las estándares.

Estas son algunas de las características nuevas en nuestra hoja de ruta que nos entusiasman en particular:

Una característica importante que habilita QUIC es la migración eficiente y transparente de las conexiones entre diferentes redes (como la red WiFi de su hogar y la red móvil de su operador cuando sale a trabajar por la mañana) sin requerir que sea cree una conexión completamente nueva.

Esta función requerirá algunos cambios adicionales en nuestra infraestructura, pero es algo que nos complace ofrecer a nuestros clientes en el futuro.

Al igual que TLS 1.3, QUIC admite un modo de operación que permite a los clientes empezar a enviar solicitudes HTTP antes de que se complete el protocolo de enlace de conexión. Aún no admitimos esta función en nuestra implementación de QUIC, pero trabajaremos para que esté disponible, tal como ya lo hacemos para nuestro soporte TLS 1.3.

Estamos orgullosos de ofrecer compatibilidad con HTTP/3 y permitir que nuestros clientes lo prueben, mientras continuamos con nuestros esfuerzos por estandarizar QUIC y HTTP/3. Seguiremos trabajando junto a otras organizaciones, incluidas Google y Mozilla, para completar los estándares QUIC y HTTP/3, e impulsar la adopción a gran escala.

Se trata de una experiencia web más rápida, más confiable y más segura para todos.