Rendimiento de Curl HTTP/3

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

Los benchmarks del nuevo soporte HTTP/3/QUIC de curl muestran que actualmente queda por detrás de HTTP/1.1 y HTTP/2 en rendimiento bruto en localhost, lo que pone de relieve el mayor coste de CPU de QUIC y la madurez de las pilas TCP muy optimizadas. Los comentaristas señalan que estas pruebas miden principalmente eficiencia, no rendimiento en el mundo real bajo latencia y pérdida de paquetes, donde HTTP/3 puede destacar gracias a un mejor multiplexado, control de congestión y migración de conexiones. El hilo también aborda detalles de implementación (OpenSSL QUIC, ausencia de UDP GSO, empaquetado de Caddy y Debian), requisitos de seguridad y certificados para HTTP/3, y cuestiones más amplias sobre el uso de C frente a Rust para nuevo código de protocolo.

Rendimiento de HTTP/3 / QUIC frente a HTTP/1.1 y HTTP/2

  • Los benchmarks muestran que HTTP/1.1 tiene el mayor rendimiento, HTTP/2 es más lento y HTTP/3 aún más lento en localhost.
  • Algunos lectores se sorprenden o se alarman; otros subrayan que esto mide la eficiencia de CPU en loopback, no el rendimiento en una red real.
  • Varios comentarios enfatizan que HTTP/2/3 apuntan a la latencia, al multiplexado y al comportamiento bajo pérdida, no al ancho de banda puro.
  • Estudios del mundo real (enlazados en el hilo) se citan como evidencia de un mejor rendimiento de HTTP/3 que HTTP/2 en condiciones de Internet.

Eficiencia de CPU frente a comportamiento de red

  • Se reconoce que QUIC es intrínsecamente menos eficiente en CPU que TCP+TLS.
  • Se comentan las razones: cifrado por paquete, muchos paquetes UDP pequeños, trabajo extra en userspace para ensamblaje de paquetes y criptografía, y un seguimiento más complejo de conexiones y streams.
  • La falta de aceleración por hardware madura y las optimizaciones de larga data en kernel/NIC para TCP hacen que QUIC sea aproximadamente un orden de magnitud menos eficiente para algunas cargas de servidor de alto rendimiento, según un experimento.

Configuración del benchmark y madurez de la implementación

  • Es probable que la prueba se ejecute en localhost y use una pila Caddy / quic-go relativamente antigua, sin GSO y con un ajuste subóptimo del búfer UDP.
  • Algunos argumentan que esto penaliza injustamente a QUIC y favorece a pilas TCP muy afinadas.
  • Otros señalan que HTTP/1.1 recibió 50 conexiones TCP paralelas, a diferencia de los navegadores reales, que normalmente usan muchas menos.

Compensaciones del protocolo: paralelismo, bloqueo HOL y conexiones

  • Hay debate sobre si HTTP/1.1 “tiene” bloqueo head-of-line: protocolo frente a límites prácticos (límites de conexiones del navegador, coste de establecimiento de conexiones).
  • Se considera que el multiplexado de HTTP/2/3 resuelve los problemas de paralelismo y HOL, aunque algunos sostienen que múltiples conexiones TCP ya pueden ofrecer alto rendimiento.
  • Se discute el límite de 64k puertos/conexiones de TCP frente a técnicas como múltiples IPs, DSR y SO_REUSEPORT; depende del contexto y es algo polémico.

Problemas de despliegue e implementaciones (curl, nginx, Debian, Caddy)

  • Los mantenedores de curl se están moviendo hacia habilitar HTTP/3 (mediante GnuTLS o OpenSSL QUIC) y están considerando soporte para WebSocket, aún experimental.
  • Algunos informan de graves problemas de latencia con HTTP/2 a través de nginx (especialmente en Kubernetes), solucionados al volver a HTTP/1.1; otros dicen que el soporte de nginx para lo que no es H1 es débil.
  • Se critica que la versión de Caddy en Debian está desactualizada y con parches insuficientes; hay tensión entre el empaquetado “estable” y la llegada oportuna de correcciones de seguridad/rendimiento.

Seguridad, certificados y la “web humana”

  • El TLS obligatorio de HTTP/3 y la ausencia de un modo de cifrado nulo / sin TLS generan preocupación para sitios autofirmados y de aficionados.
  • Algunos temen que la dependencia de CAs públicas y las políticas de los navegadores margine aún más a los sitios autohospedados y no corporativos, frente a flujos de trabajo TOFU/autofirmados.

Elecciones de lenguaje e implementación (C frente a Rust)

  • Se expresa decepción por el hecho de que el nuevo código de QUIC esté escrito en C, pese a las implementaciones de QUIC en Rust y al uso previo de Rust en curl.
  • Contraargumentos: las toolchains de Rust no están disponibles ni verificadas para muchas arquitecturas de nicho y embebidas; Rust tiene mayor tamaño de binario y coste de compilación; la madurez del ecosistema y la cobertura de objetivos siguen siendo restricciones prácticas.