HTTP/2 and HTTP/3 explained

Original Article ↗ Hacker News Discussion ↗

Debate over HTTP/2 and HTTP/3 centers on whether their added complexity, encryption requirements, and QUIC-based multiplexing actually improve real‑world performance over HTTP/1.1, especially on high-latency or mobile networks. Commenters highlight how theoretical benefits like reduced head-of-line blocking and fewer TCP connections can be offset by issues such as mobile slowdowns, middlebox breakage, DDoS concerns over UDP, and the difficulty of correct implementation. There is also tension between security and longevity: mandatory CA-based TLS is seen by some as essential user protection, and by others as a fragile, corporate-controlled dependency that threatens the long-term accessibility of small or personal sites.

HTTP/1.1 Pipelining and Middleboxes

  • Spec-wise, HTTP/1.1 allows sending multiple requests on one TCP connection before prior responses arrive.
  • Several commenters say this “never really worked” in practice: broken proxies, antivirus MITM, and middleboxes mangle or interleave responses.
  • Because of this, browsers largely abandoned pipelining despite theoretical correctness.

Head-of-Line Blocking, Multiplexing, and Performance

  • Clarification: in HTTP/1.1, you can send multiple requests but often must wait for earlier responses before later ones can be used.
  • Browsers cap concurrent TCP connections per origin (historically small, later around ~6–10), which can cause blocking.
  • Some argue HTTP/2’s single-connection multiplexing creates TCP-level head‑of‑line: packet loss on one stream can stall others.
  • Others counter that multiple HTTP/1.1 connections have their own downsides (handshakes, slow start, kernel limits).

HTTP/2 in Practice

  • Opinions split:
    • Positive: generally faster on typical connections; cleaner design (all metadata as headers, streams, HPACK); works well for RPC and many web workloads.
    • Negative: some report 5–25% worse mobile load times, especially with high latency/loss and interactive + lazy-loading use cases. Data is referenced but not shared, leading to accusations of anecdote vs. evidence.
  • Server push is widely viewed as a failed feature; major browsers removed it.

HTTP/3 / QUIC and UDP

  • HTTP/3/QUIC touted for unstable/mobile networks via connection migration and better handling of loss.
  • One commenter says HTTP/3 performs worse than HTTP/1.1 + satellite “PEP” on satellite links.
  • Concerns raised about QUIC’s DDoS implications over UDP and about proposals for “QUIC over TCP” as a sign of real‑world friction.
  • Discussion on why UDP is less optimized: hardware and OS TCP offloads (segmentation, coalescing) don’t translate cleanly to UDP.

Complexity vs. Benefits

  • Some argue if HTTP/2/3 are more complex and costly to implement than HTTP/1.1, they’re a mistake.
  • Others respond that complexity is justified when a small number of implementations serve billions of users, and that HTTP/3 effectively folds TCP+TLS+HTTP into one stack with similar overall complexity.
  • For app developers on modern cloud platforms, HTTP/3 can be “free” via managed load balancers.

TLS, CAs, and Longevity / Censorship

  • Strong disagreement about mandatory CA-based TLS for HTTP/3:
    • Pro side: insecure/plain or self‑signed deployments shouldn’t be exposed publicly; user safety and privacy outweigh convenience.
    • Contra side: CA dependence harms longevity (cert expiry, ACME fragility), centralizes power for censorship, and blocks simple personal sites; self‑signed or plain-text should remain possible (with warnings).
  • Debate over whether encryption is always needed for read‑only content; opponents raise surveillance in hostile jurisdictions as a reason it is.

Use Cases and “Who HTTP/2/3 Serve”

  • One commenter argues HTTP/2/3 mainly solve problems of ad‑heavy, multi-domain pages driven by large ad and CDN companies, not simple text retrieval.
  • They claim for single‑domain text fetching, HTTP/1.1 pipelining remains superior; others dispute this but provide no counter-benchmarks.
  • A small test of loading many images across browsers/HTTP versions shows differing parallelism and ordering, highlighting implementation variance.

Higher-Layer Multiplexing vs. SCTP

  • One unresolved question: why HTTP/2/3 multiplexing was done at the application layer (over TCP/UDP) instead of using SCTP directly.
  • The thread raises the question but offers no clear answer.