Estado de HTTP en 2022

Después de más de treinta años, HTTP sigue siendo la base de la web y uno de los protocolos más populares de Internet, no solo para navegar, ver vídeos y escuchar música, sino también para aplicaciones, comunicación entre dispositivos e incluso como base para desarrollar otros protocolos, formando lo que algunos denominan "the second waist" en el clásico diagrama del reloj de arena de Internet.

¿Por qué HTTP tiene tanto éxito? Una respuesta es que alcanza el "punto óptimo" para la mayoría de las aplicaciones que necesitan un protocolo de aplicación. "Building Protocols with HTTP" (que el grupo de trabajo de HTTP publicó en 2022 como RFC de las prácticas recomendadas actuales) sostiene que el éxito de HTTP se puede atribuir a factores como:

- Familiaridad por parte de los responsables de las implementaciones, especificadores, administradores, desarrolladores y usuarios.- Disponibilidad de una variedad de implementaciones de cliente, servidor y proxy.- Facilidad de uso.- Disponibilidad de navegadores web.- Reutilización de mecanismos existentes como la autenticación y el cifrado.- Presencia de servidores y clientes HTTP en las implantaciones de destino.- Capacidad para atravesar firewalls.

Otro factor importante es la comunidad de personas que utilizan, implementan y estandarizan HTTP. Trabajamos juntos para mantener y desarrollar activamente el protocolo, para garantizar que sea interoperable y satisfaga las necesidades actuales. Si HTTP deja de evolucionar, otro protocolo lo sustituirá (con razón), y perderemos toda la inversión de la comunidad, el conocimiento común y la interoperabilidad.

Cloudflare, al igual que otros muchos, contribuye a esta misión enviando a ingenieros a participar en el IETF, donde se debaten y estandarizan la mayoría de los protocolos de Internet. También asistimos y patrocinamos eventos de la comunidad como el Seminario sobre HTTP, donde hablamos sobre los problemas que experimentan los usuarios y lo que necesitan, para entender así qué cambios podrían ayudarles.

Entonces, ¿qué ocurrió en todas esas reuniones de grupos de trabajo, documentos de especificaciones y actividades paralelas en 2022? ¿Qué están haciendo los responsables del desarrollo y la implementación de protocolos web? Y, ¿qué será lo siguiente?

Desde el punto de vista de las especificaciones, lo más importante que ocurrió en 2022 fue la publicación de HTTP/3, ya que supuso un gran avance para atender los requisitos de las aplicaciones y sitios modernos, utilizando la red de forma más eficiente para promover su rendimiento.

Allá por los años 90, HTTP/0.9 y HTTP/1.0 utilizaban una nueva conexión TCP para cada solicitud, un uso asombrosamente ineficiente de la red. HTTP/1.1 estableció conexiones persistentes (que se trasladaron a HTTP/1.0 con el encabezado `Connection: Keep-Alive`). Fue una mejora que ayudó a los servidores y a la red a hacer frente a la explosiva popularidad de la web, pero incluso entonces, la comunidad sabía que había limitaciones significativas, en particular, el bloqueo de encabezado de línea (cuando una solicitud pendiente en una conexión impide que se completen otras).

Este inconveniente no importaba tanto en los años 90 y principios de los 2000, pero las páginas y las aplicaciones web de hoy en día plantean exigencias a la red que hacen que estas limitaciones sean críticas para el rendimiento. Las páginas suelen tener cientos de activos que compiten por los recursos de la red, y HTTP/1.1 no estaba a la altura. Tras algunos intentos fallidos, la comunidad abordó finalmente estos problemas con HTTP/2 en 2015.

Sin embargo, la eliminación del bloqueo de encabezado de línea en HTTP dejó al descubierto el mismo problema una capa más abajo, en TCP. Dado que TCP es un protocolo que proporciona entrega de mensajes fiable y ordenada, la pérdida de un solo paquete en un flujo puede bloquear el acceso a los siguientes, aunque estén en los búferes del sistema operativo. Este obstáculo resulta ser un verdadero problema para la implementación de HTTP/2, especialmente en redes poco óptimas.

La respuesta, por supuesto, era sustituir TCP, el venerable protocolo de transporte en el que se basa gran parte de Internet. Tras muchos debates y borradores en el grupo de trabajo QUIC, se publicó la versión 1 de QUIC como sustituto en 2021.

HTTP/3 es la versión de HTTP que utiliza QUIC. Aunque el grupo de trabajo la completó, a efectos prácticos, en 2021 junto con QUIC, su publicación se aplazó hasta 2022 para sincronizarla con la publicación de otros documentos (véase más abajo). El año 2022 también fue clave para la implementación de HTTP/3. Cloudflare fue testigo de la creciente adopción y confianza en el nuevo protocolo.

Aunque solo hubo un breve intervalo de unos pocos años entre HTTP/2 y HTTP/3, la comunidad no tiene muchas ganas de trabajar en HTTP/4 a corto plazo. Tanto QUIC como HTTP/3 son nuevos, y el mundo está aún aprendiendo la mejor manera de implementar los protocolos, hacerlos funcionar y desarrollar sitios y aplicaciones que los utilicen. Si bien no podemos descartar una limitación que obligue a una nueva versión en el futuro, el IETF desarrolló estos protocolos basándose en la amplia experiencia del sector con las redes modernas, y dispone de una extensibilidad significativa para facilitar cualquier cambio necesario.

El otro acontecimiento destacado para las especificaciones HTTP en 2022 fue la publicación de sus documentos "básicos", el núcleo de las especificaciones de HTTP. Estos documentos incluyen: Semántica HTTP, que engloba aspectos como los métodos, los encabezados, los códigos de estado y el formato de los mensajes; Caché HTTP, es decir, cómo funcionan las cachés HTTP; HTTP/1.1, se refiere a la asignación de la semántica a la conexión, utilizando el formato que todo el mundo conoce y quiere.

Además, se ha vuelto a publicar HTTP/2 para integrarlo correctamente con el documento de Semántica, y para solucionar algunos problemas pendientes.

Esta es la última de una larga serie de revisiones de estos documentos. En el pasado, hemos tenido la serie RFC 723x, RFC 2616 (quizás la más conocida), RFC 2068 y la más antigua de todas ellas, RFC 1945. Cada revisión ha tenido como objetivo facilitar su lectura, corregir errores, explicar mejor los conceptos y aclarar el funcionamiento del protocolo. Las funciones mal especificadas (o implementadas) son obsoletas. Se han añadido otras nuevas que mejoran el funcionamiento del protocolo. Para más detalles, consulta el apéndice "Cambios de..." de cada documento y, lo que es más importante, consulta siempre las últimas revisiones cuyos enlaces están más arriba. Las RFC más antiguas han quedado obsoletas.

HTTP/2 incluía server push, una función diseñada para permitir a los servidores "enviar" un par solicitud/respuesta a los clientes cuando sabían que el cliente iba a necesitar algo, de modo que pudiera evitar la latencia derivada del proceso de hacer una solicitud y esperar la respuesta.

Tras la finalización de HTTP/2 en 2015, Cloudflare y muchas otras implementaciones de HTTP no tardaron en adoptar el mecanismo server push en previsión de grandes mejoras en el rendimiento. Lamentablemente, resultó ser más difícil de lo que parecía. Server push requiere, en la práctica, que el servidor prediga el futuro, no solo qué solicitudes enviará el cliente, sino también cuáles serán las condiciones de la red. Y, cuando el servidor se equivoca ("over-pushing"), las solicitudes enviadas compiten directamente con las solicitudes reales que está haciendo el navegador, lo que conlleva un coste de oportunidad significativo con un potencial real de afectar el rendimiento, en lugar de mejorarlo. El impacto es aún peor cuando el navegador ya tiene una copia en caché, por lo que no necesita el servicio push en absoluto.

Como consecuencia, Chrome eliminó server push para HTTP/2 en 2022. Otros navegadores y servidores podrían seguir siendo compatibles, pero la comunidad parece estar de acuerdo en que actualmente solo es adecuado para usos especializados, como el protocolo Web Push específico de las notificaciones del navegador.

Sin embargo, eso no significa que nos rindamos. El código de estado 103 (Early Hints) fue publicado como RFC experimental por el grupo de trabajo de HTTP en 2017. Permite a un servidor enviar indicaciones al navegador en una respuesta no final, antes de la respuesta final "real". Es útil si sabes que el contenido va a incluir algunos enlaces a recursos que el navegador obtendrá, pero necesitas más tiempo para hacer llegar la respuesta al cliente (porque tardará más en generarse, o porque el servidor necesita obtenerla de otro lugar, como hace una CDN).

Early Hints se puede utilizar en muchas situaciones para las que se diseñó server push, por ejemplo, cuando tienes CSS y JavaScript que una página va a necesitar cargar. En teoría, no son tan óptimas como server push porque solo permiten enviar indicaciones cuando hay una solicitud pendiente, y porque hacer llegar las indicaciones al cliente y actuar en consecuencia añade cierta latencia.

En la práctica, sin embargo, Cloudflare y nuestros socios (como Shopify y Google) han pasado 2022 experimentando con Early Hints y han descubierto que su uso es mucho más seguro y cuenta con prometedoras ventajas de rendimiento que incluyen reducciones significativas en las métricas clave del rendimiento web.

Estamos entusiasmados con el potencial que muestra Early Hints, tanto que lo hemos integrado en Cloudflare Pages. También estamos evaluando nuevas formas de mejorar el rendimiento utilizando esta nueva capacidad del protocolo.

Para muchos, las extensiones más emocionantes del protocolo HTTP en 2022 se centraron en la intermediación, la capacidad de insertar proxies, puertas de enlace y componentes similares en el protocolo para lograr objetivos específicos, a menudo centrados en mejorar la privacidad.

El grupo de trabajo MASQUE, por ejemplo, se esfuerza por añadir nuevas funciones de tunelización a HTTP, de modo que un intermediario pueda pasar el tráfico tunelizado a otro servidor.

Si bien CONNECT ha posibilitado túneles TCP durante mucho tiempo, MASQUE ha habilitado túneles UDP, lo que permite tunelizar más protocolos de forma más eficiente, incluidos QUIC y HTTP/3.

En Cloudflare, estamos encantados de trabajar con Apple para utilizar MASQUE con el fin de implementar iCloud Private Relay y mejorar la privacidad de sus clientes sin depender únicamente de una empresa. También nos interesa mucho el trabajo futuro del grupo de trabajo, incluida la tunelización de IP que permitirá las VPN basadas en MASQUE.

Otra especificación centrada en la intermediación es Oblivious HTTP (u OHTTP). OHTTP utiliza conjuntos de intermediarios para impedir que el servidor utilice conexiones o direcciones IP para rastrear a los clientes, garantizando así una mayor privacidad para acciones como la recopilación de telemetría u otros datos confidenciales. Se está completando el proceso de estandarización de esta especificación, y la estamos utilizando para crear un nuevo producto importante, Privacy Gateway, para proteger la privacidad de los clientes de nuestros clientes.

Creemos, al igual que otros muchos en la comunidad de Internet, que esto es solo el principio porque la intermediación puede realizar particiones de la comunicación, una herramienta útil para mejorar la privacidad.

Por último, en 2022 se trabajó mucho en los aspectos de HTTP relacionados con la seguridad. La especificación Digest Fields es una actualización del ya antiguo campo del encabezado `Digest`, que permite añadir resúmenes de integridad a los mensajes. La especificación HTTP Message Signatures permite firmas criptográficas en solicitudes y respuestas, algo que tiene una amplia implementación ad hoc, pero que hasta ahora carecía de un estándar. Ambas especificaciones se encuentran en las fases finales de estandarización.

La revisión de la especificación Cookie también experimentó muchos avances en 2022, y debería ser definitiva en breve. Dado que no es posible deshacerse de ellas por completo a corto plazo, se ha trabajado mucho para limitar su funcionamiento con el fin de mejorar la privacidad y la seguridad, incluido un nuevo atributo `SameSite`.

Otro conjunto de especificaciones relacionadas con la seguridad en el que Cloudflare ha invertido muchos años es Privacy Pass, también conocido como "Tokens de acceso privado". Se trata de tokens criptográficos que pueden garantizar que los clientes son usuarios reales, no bots, sin utilizar un desafío CAPTCHA intrusivo y sin rastrear la actividad del usuario en Internet. En HTTP, adoptan la forma de un nuevo esquema de autenticación.

Aunque aún no se ha iniciado totalmente el proceso de estandarización de Privacy Pass, en 2022 Apple lo implementó de forma general, lo que supone un gran avance. Y como Cloudflare lo utiliza en Turnstile, nuestra alternativa CAPTCHA, tus usuarios pueden disfrutar desde ya de mejores experiencias.

¿Qué será lo próximo? Además de las especificaciones anteriores que aún no se han completado, el grupo de trabajo de HTTP tiene otros proyectos en curso, como un método QUERY (como GET, pero con un cuerpo), cargas reanudables (basadas en el protocolo tus), variantes (un encabezado Vary mejorado para el almacenamiento en caché), mejoras en los campos estructurados (incluido un nuevo tipo de fecha) y una forma de readaptar los encabezados existentes a los campos estructurados. Escribiremos más sobre estos proyectos a medida que avancen en 2023.

En el Seminario sobre HTTP 2022, la comunidad también habló sobre nuevos trabajos que podemos emprender para mejorar el protocolo. Algunas de las ideas que se debatieron fueron mejorar nuestra infraestructura común de pruebas del protocolo (ahora mismo tenemos algunos recursos, pero podría mejorar), perfeccionar (o sustituir) los servicios alternativos para permitir una gestión más inteligente y correcta de las conexiones, y cambios más radicales, como serializaciones alternativas y binarias de los encabezados.

También hay un debate continuo en la comunidad sobre si HTTP debe dar cabida a pub/sub, o si se debe estandarizar para funcionar sobre WebSockets (y pronto, WebTransport). Aunque es difícil decirlo ahora, el trabajo adyacente sobre Media over QUIC que acaba de comenzar podría ofrecer una oportunidad para impulsarlo.

Por supuesto, eso no es todo, y está por ver lo que sucederá con HTTP en 2023 (y más adelante). HTTP sigue evolucionando, aunque siga siendo compatible con el mayor sistema de hipertexto distribuido jamás concebido, la red mundial.