HTTP/2 y HTTP/3 explicados

Artículo original ↗ Discusión en Hacker News ↗

Pipelining de HTTP/1.1 y middleboxes

  • Según la especificación, HTTP/1.1 permite enviar múltiples solicitudes en una conexión TCP antes de que lleguen las respuestas anteriores.
  • Varios comentaristas dicen que esto “nunca funcionó realmente” en la práctica: proxies defectuosos, MITM de antivirus y middleboxes corrompen o entrelazan las respuestas.
  • Por esto, los navegadores abandonaron en gran medida el pipelining a pesar de su corrección teórica.

Bloqueo de cabeza de línea, multiplexación y rendimiento

  • Aclaración: en HTTP/1.1, puedes enviar múltiples solicitudes, pero a menudo debes esperar a las respuestas anteriores antes de poder usar las posteriores.
  • Los navegadores limitan el número de conexiones TCP concurrentes por origen (históricamente pequeño, luego alrededor de ~6–10), lo que puede causar bloqueo.
  • Algunos argumentan que la multiplexación de una sola conexión de HTTP/2 crea bloqueo de cabeza de línea a nivel TCP: la pérdida de paquetes en un flujo puede detener a otros.
  • Otros responden que múltiples conexiones HTTP/1.1 tienen sus propios inconvenientes (handshakes, slow start, límites del kernel).

HTTP/2 en la práctica

  • Las opiniones están divididas:
    • Positivo: por lo general es más rápido en conexiones típicas; diseño más limpio (todos los metadatos como headers, streams, HPACK); funciona bien para RPC y muchas cargas de trabajo web.
    • Negativo: algunos informan tiempos de carga móviles entre 5 y 25% peores, especialmente con alta latencia/pérdida y casos de uso interactivos + de carga perezosa. Se citan datos pero no se comparten, lo que lleva a acusaciones de anécdota frente a evidencia.
  • Server push es ampliamente visto como una característica fallida; los navegadores principales la eliminaron.

HTTP/3 / QUIC y UDP

  • Se promociona HTTP/3/QUIC para redes inestables o móviles gracias a la migración de conexión y a un mejor manejo de la pérdida.
  • Un comentarista dice que HTTP/3 rinde peor que HTTP/1.1 + “PEP” satelital en enlaces satelitales.
  • Se expresan preocupaciones sobre las implicaciones de DDoS de QUIC sobre UDP y sobre propuestas de “QUIC sobre TCP” como señal de fricción en el mundo real.
  • Discusión sobre por qué UDP está menos optimizado: los offloads de TCP en hardware y sistema operativo (segmentación, coalescencia) no se trasladan limpiamente a UDP.

Complejidad vs. beneficios

  • Algunos argumentan que si HTTP/2/3 son más complejos y costosos de implementar que HTTP/1.1, son un error.
  • Otros responden que la complejidad está justificada cuando un pequeño número de implementaciones da servicio a miles de millones de usuarios, y que HTTP/3 efectivamente integra TCP+TLS+HTTP en una sola pila con una complejidad global similar.
  • Para desarrolladores de aplicaciones en plataformas modernas en la nube, HTTP/3 puede ser “gratis” mediante balanceadores de carga gestionados.

TLS, CAs y longevidad / censura

  • Fuerte desacuerdo sobre TLS obligatorio basado en CA para HTTP/3:
    • A favor: los despliegues inseguros/en texto claro o con certificados autofirmados no deberían exponerse públicamente; la seguridad y la privacidad del usuario pesan más que la comodidad.
    • En contra: la dependencia de CA perjudica la longevidad (caducidad de certificados, fragilidad de ACME), centraliza el poder para la censura y bloquea sitios personales sencillos; lo autofirmado o el texto claro deberían seguir siendo posibles (con advertencias).
  • Debate sobre si el cifrado siempre es necesario para contenido de solo lectura; los opositores citan la vigilancia en jurisdicciones hostiles como razón de que sí lo es.

Casos de uso y “a quién sirven HTTP/2/3”

  • Un comentarista argumenta que HTTP/2/3 principalmente resuelven problemas de páginas con muchos anuncios y múltiples dominios impulsadas por grandes empresas de publicidad y CDN, no la recuperación simple de texto.
  • Afirman que para la obtención de texto de un solo dominio, el pipelining de HTTP/1.1 sigue siendo superior; otros lo disputan, pero no ofrecen contrabenchmarks.
  • Una pequeña prueba de cargar muchas imágenes en varios navegadores/versiones HTTP muestra distinto paralelismo y orden, lo que resalta la variación de implementación.

Multiplexación de nivel superior vs. SCTP

  • Una pregunta no resuelta: por qué la multiplexación de HTTP/2/3 se hizo en la capa de aplicación (sobre TCP/UDP) en lugar de usar SCTP directamente.
  • El hilo plantea la pregunta, pero no ofrece una respuesta clara.