HTTP/2 and HTTP/3 explained

Original Article ↗ Hacker News Discussion ↗

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.