QUIC is not quick enough over fast internet

Original Article ↗ Hacker News Discussion ↗

A recent networking study finds that HTTP/3 over QUIC can deliver up to 45% less throughput than HTTP/2 over TCP on very fast connections (≈500 Mbps+), largely because current QUIC stacks are CPU‑bound and incur extra user‑space overhead for ACKs and syscalls. Commenters generally see this as an implementation and tooling gap rather than a fundamental flaw in QUIC, noting that TCP benefits from decades of kernel and hardware optimization, while QUIC is still maturing in browsers and OSes. The exchange broadens into questions about when ultra‑high bandwidth really matters for typical web use, tradeoffs between latency and throughput, and how much protocol complexity and Google‑driven change the web should accept.

Performance and CPU Findings

  • Paper reports up to ~45% lower throughput for QUIC/HTTP/3 vs TCP/TLS/HTTP/2 on “fast Internet” (≈500–600+ Mbps).
  • Several commenters note Chrome tops out around ~500 Mbps and appears CPU-bound; curl tests also show QUIC taking much more CPU than HTTP/2.
  • Others report seeing close to line‑rate (≈900 Mbps–1 Gbps) with QUIC in their own setups, suggesting results are implementation‑ and environment‑dependent.
  • For most web browsing workloads, many argue these speeds are already beyond what users notice; for large game/OS downloads or heavy file transfers, the cap is annoying.

Suspected Causes

  • Main culprit discussed: receiver‑side overhead from user‑space QUIC, many syscalls, and user‑space ACK handling vs TCP’s mature in‑kernel path with GRO/TSO and hardware offload.
  • Lack of UDP GRO/TSO and NIC offloads for QUIC is highlighted; proposals include UDP GRO, pacing, and kernel‑mode QUIC.
  • Extra TLS 1.3 work and QUIC header protection add some per‑packet cost, but thread suggests syscalls and lack of offload dominate.

Intended Benefits and Use Cases

  • QUIC is seen as optimized for latency, loss, and unstable/mobile networks (IP changes, Wi‑Fi↔cell handover, high RTT), not raw throughput.
  • Features praised: 0‑RTT/1‑RTT handshakes, better behavior under packet loss, stream multiplexing without TCP head‑of‑line blocking, resistance to middlebox ossification.
  • Several say that on high‑latency paths (e.g., Asia/Australia/China ↔ US), QUIC’s latency gains are “night and day” and more important than peak Mbps.

Deployment Strategies

  • Common suggestion: QUIC/HTTP‑3 between client and CDN edge; HTTP‑2/TCP between edge and origin, where long‑lived, fast, reusable TCP connections shine.
  • Others propose using HTTP‑3 by default but falling back to HTTP‑2 for large file transfers.

Implementation Maturity and Tooling

  • Many view problems as implementation immaturity, not protocol flaws; paper’s recommendations (receiver optimizations, multithreading, kernel support) reflect this.
  • Some note QUIC in browsers is “unstable” or not fully optimized yet; others point to ongoing Linux kernel QUIC work.
  • Mandatory TLS makes QUIC harder to debug locally; requires key logging or special tooling instead of simple packet inspection.

Politics, Complexity, and Web Bloat

  • Heated debate over Google’s role in pushing QUIC/HTTP‑2/3 via Chromium:
    • Critics argue it drives protocol and web‑stack complexity and resembles an “embrace/extend” dynamic.
    • Defenders counter that QUIC/HTTP‑2/3 are open standards with multi‑vendor input, optional to implement, and address real latency and ossification issues.
  • Several argue that perceived speed problems on the web stem more from JS‑heavy, bloated sites and complex frontend stacks than from transport protocols; lightweight, server‑rendered sites are cited as “instant” regardless of QUIC vs TCP.