QUIC is not quick enough over fast internet

Original Article ↗ Hacker News Discussion ↗

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.