Curl HTTP/3 Performance

Original Article ↗ Hacker News Discussion ↗

Benchmarks of curl’s new HTTP/3/QUIC support show it currently lags HTTP/1.1 and HTTP/2 in raw throughput on localhost, highlighting QUIC’s higher CPU cost and the maturity of heavily optimized TCP stacks. Commenters note that these tests mainly measure efficiency, not real-world performance under latency and packet loss, where HTTP/3 can shine through better multiplexing, congestion control, and connection migration. The thread also touches on implementation details (OpenSSL QUIC, lack of UDP GSO, Caddy and Debian packaging), security and certificate requirements for HTTP/3, and broader questions about using C versus Rust for new protocol code.

HTTP/3 / QUIC Performance vs HTTP/1.1 and HTTP/2

  • Benchmarks show HTTP/1.1 highest throughput, HTTP/2 slower, HTTP/3 slower still on localhost.
  • Some readers are surprised or alarmed; others stress this measures CPU efficiency on loopback, not real network performance.
  • Several comments emphasize HTTP/2/3 target latency, multiplexing, and behavior under loss, not pure bandwidth.
  • Real‑world studies (linked in thread) are cited as showing better HTTP/3 throughput than HTTP/2 under Internet conditions.

CPU Efficiency vs Network Behavior

  • QUIC is acknowledged as intrinsically less CPU‑efficient than TCP+TLS.
  • Reasons discussed: per‑packet encryption, many small UDP packets, extra userspace work for packet assembly and crypto, and more complex connection/stream bookkeeping.
  • Lack of mature hardware offload and long‑standing TCP kernel/NIC optimizations makes QUIC roughly an order of magnitude less efficient for some high‑throughput server workloads, according to one experiment.

Benchmark Setup and Implementation Maturity

  • The test likely runs on localhost and uses a relatively old Caddy / quic-go stack without GSO and with suboptimal UDP buffer tuning.
  • Some argue this unfairly penalizes QUIC and favors highly tuned TCP stacks.
  • Others note HTTP/1.1 was given 50 parallel TCP connections, unlike real browsers which typically use far fewer.

Protocol Trade‑offs: Parallelism, HOL Blocking, and Connections

  • Debate around whether HTTP/1.1 “has” head‑of‑line blocking: protocol vs practical limits (browser connection caps, connection setup cost).
  • HTTP/2/3 multiplexing is seen as solving parallelism and HOL problems, though some argue multiple TCP connections can already deliver high performance.
  • Discussion on TCP 64k port/connection limits vs techniques like multiple IPs, DSR, and SO_REUSEPORT; context‑dependent and somewhat contentious.

Deployment Issues and Implementations (curl, nginx, Debian, Caddy)

  • curl maintainers are moving toward enabling HTTP/3 (via GnuTLS or OpenSSL QUIC) and considering WebSocket support, still experimental.
  • Some report severe latency issues with HTTP/2 via nginx (especially in Kubernetes), fixed by reverting to HTTP/1.1; others say nginx’s non‑H1 support is weak.
  • Caddy versioning in Debian is criticized as outdated and under‑patched; tension between “stable” packaging and timely security/perf fixes.

Security, Certificates, and the “Human Web”

  • HTTP/3’s mandatory TLS and lack of null cipher / TLS‑less modes raise concerns for self‑signed and hobbyist sites.
  • Some fear dependence on public CAs and browser policies will further marginalize self‑hosted, non‑corporate sites, versus TOFU/self‑signed workflows.

Language and Implementation Choices (C vs Rust)

  • Disappointment expressed that new QUIC code is written in C despite Rust QUIC implementations and prior Rust use in curl.
  • Counterpoints: Rust toolchains are not available/verified for many niche and embedded architectures; Rust has higher binary size and build cost; ecosystem maturity and target coverage remain practical constraints.