Por qué HTTP/3 tiene soporte generalizado, pero en la práctica casi no se usa

• HTTP/3 se ha estado desarrollando desde 2016, y QUIC, el protocolo en el que se basa, fue introducido por primera vez por Google en 2013
• Actualmente está estandarizado y cuenta con un soporte amplio como el siguiente
  • Es compatible con el 95% de los navegadores
  • El 32% de las solicitudes HTTP de Cloudflare usan HTTP/3
  • El 35% de los sitios web muestran soporte para HTTP/3 (mediante alt-svc o DNS)
• Sin embargo, las bibliotecas estándar de los principales lenguajes carecen de soporte para QUIC y HTTP/3
  • No está incluido en las bibliotecas estándar de Node.js, Go, Rust, Python, Ruby, etc.
  • Curl añadió recientemente soporte para HTTP/3, pero sigue en estado experimental y está desactivado por defecto
  • Nginx, un servidor popular, tiene soporte experimental y está desactivado por defecto
  • Apache no tiene planes de soportar HTTP/3
  • Ingress-Nginx de Kubernetes abandonó sus planes de soportar HTTP/3

La necesidad después de HTTP/1.1

• HTTP/3 es útil para tráfico de navegadores web y CDN con alta latencia
• Principales ventajas que ofrecen HTTP/2 y HTTP/3:
  • Multiplexación para reducir la latencia de respuesta
  • Compresión de encabezados HTTP para reducir el tráfico (usando HPACK y QPACK)
  • Streaming bidireccional que permite intercambio de datos en tiempo real entre cliente y servidor
  • Priorización para procesar primero las solicitudes importantes
• Ventajas adicionales de HTTP/3:
  • Procesamiento independiente de streams para que la pérdida de paquetes no afecte a otros streams
  • Handshake TLS 0-RTT para mejorar la velocidad de inicialización de la conexión
  • Migración de conexión para mantener la conexión cuando cambia la dirección IP
  • Mejoras en el control de congestión para aumentar el rendimiento y la estabilidad

Mejora de rendimiento de HTTP/3

• Resultados del benchmark de RequestMetric:
  • HTTP/3 ofrece tiempos de respuesta más rápidos que HTTP/1.1 y HTTP/2
• Caso real de Fastly:
  • En HTTP/3, el tiempo hasta el primer byte se redujo en un 18%

El problema de la falta de soporte para HTTP/3

• HTTP/3 tiene amplio soporte en navegadores y CDN, pero sigue siendo difícil de usar para desarrolladores comunes
• Actualmente existen dos tipos de tráfico web:
  • Web de hiperescala: basada en navegadores principales y grandes servidores (Google, Meta, Amazon, etc.)
  • Web de cola larga: basada en servidores y clientes pequeños y medianos (API backend, apps móviles, IoT, etc.)
• Diferencias principales:
  • El tráfico de cola larga representa el 67% del tráfico total
  • La hiperescala puede desarrollar e implementar rápido; la cola larga tiene menos recursos y prioriza la estabilidad
  • Existe una alta dependencia de herramientas open source

OpenSSL y el problema con QUIC

• OpenSSL es la base de la mayoría de las herramientas de red open source
• BoringSSL lanzó una API con soporte para QUIC en 2018, pero OpenSSL introdujo su propia API de QUIC
• Problemas principales:
  • No es compatible con implementaciones existentes basadas en BoringSSL
  • A Curl y a los principales lenguajes les resulta difícil cambiar su dependencia de OpenSSL
  • Node.js consideró usar BoringSSL en lugar de OpenSSL, pero eso no se concretó

Perspectivas a futuro

• A medida que la web de hiperescala adopta HTTP/3, podría surgir una brecha de rendimiento frente a la web de cola larga
• La falta de soporte para HTTP/3 podría causar problemas como:
  • Reforzar la ventaja en velocidad y estabilidad de los sitios de hiperescala
  • Si los frameworks basados en HTTP/3 se vuelven comunes, la web de cola larga podría tener dificultades para acceder a ellos
  • La falta de soporte para HTTP/3 podría usarse como criterio para bloquear clientes
• Soluciones posibles:
  • Resolver los problemas de la API de QUIC de OpenSSL
  • Desarrollar herramientas y adaptadores que mejoren la compatibilidad con implementaciones existentes de QUIC y HTTP/3
  • Impulsar una mayor expansión del soporte de HTTP/3 en herramientas open source

Conclusión

• HTTP/3 ofrece claras ventajas de rendimiento y estabilidad, pero actualmente solo las empresas de hiperescala pueden usarlo con facilidad
• Se necesitan mejoras en herramientas y estándares para que la web de cola larga también pueda usar HTTP/3 fácilmente

[GN⁺]

Opiniones en Hacker News

• Hay quienes opinan que es difícil encontrar herramientas populares de código abierto con soporte completo para HTTP/3

  • Los administradores de TI y los ingenieros de DevOps suelen terminar las conexiones HTTP/3 en el balanceador de carga y, tras terminar SSL, reenviar HTTP 1.1 a los servicios de backend
  • HTTP/3 e IPv6 son tecnologías más orientadas a lo móvil, y resultan más útiles en conexiones temporales e inestables que en centros de datos

• Las bibliotecas estándar de los principales lenguajes no incluyen QUIC ni HTTP/3

  • .NET ofrece un soporte decente para HTTP/3
  • Como la mayoría de los equipos de desarrollo no construyen productos centrados en redes, HTTP/3 tiene baja prioridad

• El mayor problema del despliegue a gran escala de HTTP/3 es que aumenta la superficie de código potencialmente vulnerable

  • Es preferible que el sistema operativo proporcione una capa de sockets segura y bibliotecas SSL enlazadas dinámicamente
  • En la mayoría de las aplicaciones cliente, unos pocos milisegundos de latencia en las solicitudes no representan un gran problema

• La adopción lenta de QUIC se debe a que OpenSSL no proporcionaba los elementos básicos necesarios para las implementaciones existentes de QUIC

  • Recientemente, OpenSSL 3.5 pasó a ofrecer una API para stacks QUIC de terceros

• HTTP/2 y HTTP/3 ya no se perciben como protocolos de capa de aplicación, sino a nivel de TCP y TLS

  • Los desarrolladores siguen viviendo en un mundo de "HTTP 1.1 en texto plano"

• nginx todavía no ofrece soporte para HTTP/3 listo para producción

• En Python se está usando niquests, que sí soporta HTTP/3

  • El ecosistema de Python se había quedado en el paquete requests por inercia

• Node.js publicó una actualización sobre el estado de QUIC y está teniendo dificultades por el lento soporte de API en OpenSSL

• Si se usan balanceadores de carga de proveedores de nube pública, HTTP/3 se utiliza por defecto

  • Los sitios que usan sus propios servidores no están aprovechando las ventajas de HTTP/3

• Todos los proyectos son, en cierta medida, impulsados por el código abierto y la comunidad

  • No se percibe la necesidad de dar soporte rápido a HTTP/3