QUIC is not quick enough over fast internet

Original Article ↗ Hacker News Discussion ↗

Researchers and engineers are finding that QUIC, the UDP‑based, encrypted transport behind HTTP/3, can underperform traditional TCP/HTTP/2 on very fast links (≈500–600 Mbps and above), largely because TCP benefits from decades of kernel and NIC offloading optimizations that QUIC currently lacks. Contributors point to user‑space processing overhead, immature UDP networking stacks, and congestion control behavior as key bottlenecks, while noting that QUIC still shines on high‑latency or lossy mobile networks and for features like connection migration. Many expect these results to drive kernel‑level QUIC implementations, better offload hardware, and API improvements, but argue that for typical home and corporate connections today, HTTP/2 over TCP often remains the more efficient choice.

Scope of the performance problem

  • Paper shows QUIC underperforms TCP/HTTP/2 at high bandwidth and very low RTT, mainly ≥500–600 Mbps and sub‑millisecond latency.
  • Several commenters note this regime isn’t typical 4G/5G, but is increasingly common for home gigabit fiber and in data centers.
  • On “normal” or slow links (mobile, high latency, lossy), many report QUIC/HTTP/3 performs as well or better.

Root causes identified

  • Consensus in the thread: the gap is largely due to TCP hardware offload and mature kernel TCP optimizations that UDP/QUIC does not yet enjoy.
  • QUIC’s ACK and state handling in userspace add scheduler and syscall overhead; UDP receive buffers are small by default and accounting is expensive.
  • Lack of QUIC‑specific NIC offload (vs widespread TCP/TLS offload) is a central bottleneck.

Userspace vs kernel networking

  • One camp argues putting QUIC in userspace was a mistake; ACKs and congestion control belong in the kernel for latency and efficiency.
  • Others argue userspace is essential: kernels evolve slowly, and QUIC’s design goal was rapid iteration and avoiding kernel crypto stacks.
  • There is work on kernel QUIC and kTLS‑style offload, but encryption‑in‑NIC raises key‑exposure and IOMMU/I/O‑isolation concerns.

When QUIC helps vs when it hurts

  • QUIC/HTTP/3 seen as clear wins on:
    • High‑latency, lossy, or mobile connections (subways, roaming, bad rural links).
    • Multipath / interface switching without breaking connections.
  • On fast, stable networks:
    • Several operators report HTTP/1.1 or HTTP/2 giving lower CPU, memory, and latency; some have disabled HTTP/2/3 entirely.
    • Others see HTTP/2 clearly beating HTTP/1.1 in such conditions; results appear implementation‑dependent.

Alternatives and design philosophy

  • Some argue SCTP already solved QUIC’s problems, but is unusable on today’s Internet due to middleboxes and lack of Windows support.
  • QUIC over UDP is seen as a pragmatic response to “only TCP/UDP pass everywhere” and to keep transport headers encrypted from meddling middleboxes.
  • There is discomfort with rising protocol complexity (HTTP/2, HTTP/3/QUIC) and calls to keep HTTP/1.1 available and favor offline‑first, simpler app designs.

System and API issues

  • Discussion of Linux networking limits: slow syscalls, small UDP buffers, imperfect UDP offload, and need for better APIs (sendmmsg/recvmmsg, io_uring) or new interfaces beyond BSD sockets.
  • Some expect this kind of research to drive UDP/QUIC stack and NIC improvements over time, narrowing the gap with TCP.