How QUIC is displacing TCP for speed

Original Article ↗ Hacker News Discussion ↗

QUIC, the UDP-based transport behind HTTP/3, is pitched as a faster, more flexible replacement for TCP, but commenters question both the article’s technical accuracy and its lack of real-world benchmarks. They note that QUIC can reproduce TCP-style congestion control and offers benefits like reduced handshakes and less head-of-line blocking, yet point out that gains seem most meaningful at hyperscaler scale, while many corporate networks block UDP/443 and smaller sites see little incentive to migrate. Concerns also surface about fairness, potential congestion collapse if congestion algorithms are tuned aggressively, mandatory TLS/CA dependence, and the reality that current adoption spikes mainly reflect big players like Google and Cloudflare rather than a smooth, universal shift away from TCP.

Article quality and imagery

  • Several commenters found the article poorly written or oversimplified (e.g., confused about QUIC handshakes, vague diagrams, shallow explanations).
  • A cartoon using the “baby yeet” meme sparked debate: some saw it as racially charged or inappropriate for a technical piece; others claimed they didn’t even notice race or saw complaints as oversensitivity.
  • Some noted that meme origins can be problematic even if the author is unaware, and that such imagery could be unacceptable in a professional context.

QUIC design vs TCP

  • QUIC runs over UDP and re‑implements transport features (reliability, congestion control, multiplexing, encryption).
  • Commenters correct the article: QUIC does have a handshake and typically uses TLS; it’s not “no handshake.”
  • Congestion control in QUIC is generally similar in shape to TCP New Reno, but implementations can swap algorithms, as with TCP.

Fairness, congestion, and network behavior

  • Questions raised about how QUIC preserves fairness given TCP’s long history of fairness-oriented congestion control.
  • Responses emphasize:
    • Congestion control is mostly orthogonal to TCP vs QUIC; either can be “fair” or “greedy.”
    • Real problems often stem from ISP overprovisioning and lack of active queue management, not the protocol.
    • Inside home networks, many parallel TCP flows can already starve others; QUIC doesn’t uniquely create that problem.

Performance and benchmarks

  • Several commenters criticize the article for lacking real measurements.
  • Shared references:
    • curl experiments where HTTP/3 (QUIC) is slower than HTTP/2 and HTTP/1.1 in some setups.
    • An older paper reporting poor QUIC performance.
  • Others counter that:
    • QUIC’s advantages show up on lossy, high-latency, or mobile networks and at large scale (e.g., big CDNs), not in localhost or “perfect network” tests.
    • Major providers report latency improvements in production, though data was not reproduced in this thread.
  • Net view: performance gains are plausible but not universal or conclusively demonstrated here.

Adoption and middleboxes

  • Graphs of HTTP/3 usage appear spiky: major players (Google, Meta, Cloudflare, Netflix) turn it on, then growth flattens.
  • HTTP/3 is widely used via CDNs and browsers’ “happy eyeballs” (race QUIC vs TCP), often without users noticing.
  • Some firewalls and corporate environments explicitly block QUIC/UDP 443 and push traffic back to TCP/TLS, suggesting slower adoption in enterprises.

Hardware offload and resource cost

  • Concern that TCP benefits from NIC offloads (checksum, segmentation) and kernel optimizations; QUIC in user space may cost more CPU.
  • Others note:
    • Most NICs don’t hardwire congestion control; offloads are partial.
    • For typical servers, CPU overhead is acceptable; hardware offload for QUIC will likely follow if hyperscalers demand it.
  • Overall: QUIC may not be “cheaper” than TCP on a single box today but is still viable for many deployments.

TLS, CAs, and openness

  • One thread worries that tying QUIC/HTTP/3 tightly to TLS and public CAs makes the protocol fragile and dependent on third parties.
  • Examples: ACME version changes, CA root expirations can silently break systems; self-signed or private CAs are hard to use with mainstream clients.
  • Others respond that modern ACME (e.g., Let’s Encrypt) can be “set and forget” for years, and that TLS centralization is comparable to DNS reliance.
  • Tension remains between security-by-default and long-term, low-maintenance connectivity.