Skip to content

HTTP/1.1 vs HTTP/2 vs HTTP/3

1. Decision

Use HTTP/1.1 for legacy system compatibility; adopt HTTP/2 as the default baseline for web applications and gRPC microservices to leverage binary framing and multiplexing; upgrade to HTTP/3 (QUIC over UDP) for mobile applications, lossy network environments, and global edge CDNs to eliminate Head-of-Line blocking and connection migration latencies.

2. 30-Second Answer

HTTP/1.1 processes text payloads sequentially over TCP, suffering from Head-of-Line (HoL) blocking (each request must wait for the previous response to complete) and browser connection limits (max 6 TCP connections per domain). HTTP/2 introduced binary framing, HPACK header compression, and TCP multiplexing—allowing hundreds of concurrent request/response streams over a single shared TCP connection. However, HTTP/2 still suffers from Transport-Layer HoL blocking when TCP packet loss occurs. HTTP/3 replaces TCP with QUIC (built on UDP). QUIC handles stream multiplexing natively at the transport layer (single packet loss only pauses its specific stream), embeds TLS 1.3 handshakes for \(0\text{-RTT}\) connection establishment, and supports seamless Connection Migration when mobile clients switch networks (Wi-Fi \(\rightarrow\) 5G).

3. Decision Matrix

Option Best For Avoid When Latency Scalability Consistency Operational Complexity
HTTP/1.1 Legacy systems, simple internal microservices, basic REST APIs, static file proxies High-frequency multiplexed requests, modern web applications, gRPC Medium to High (TCP handshake + HoL blocking latency) Low to Medium (Bounded by TCP connection overhead & 6-conn limit) Standard HTTP request-response Very Low
HTTP/2 Modern web apps, gRPC microservices, multiplexed APIs, asset streaming Lossy mobile cellular networks where TCP packet loss triggers HoL blocking Low (Multiplexed single TCP connection; zero HoL at app layer) High (Single TCP socket handles hundreds of concurrent streams) HPACK header table state synchronization Medium (Requires TLS; L7 proxy load balancing)
HTTP/3 (QUIC over UDP) Mobile applications, global CDN edge networks, lossy Wi-Fi/5G networks, video streaming Environments where UDP traffic is throttled or blocked by enterprise firewalls Ultra-Low (0-RTT connection resumption; zero transport HoL blocking) Extremely High (UDP socket concurrency + Connection Migration) QUIC connection ID tracking High (UDP firewall tuning, QUIC stack implementation)

4. Selection Rules

Requirement Best Choice Rationale / Example
Default Standard Web App Baseline HTTP/2 Multiplexing & HPACK compression supported out-of-the-box by modern browsers
Mobile App on Lossy Cellular / 5G HTTP/3 (QUIC) Eliminates TCP packet loss HoL blocking and supports Wi-Fi-to-5G connection migration
gRPC Microservice Inter-Service Mesh HTTP/2 gRPC relies natively on HTTP/2 binary framing and stream multiplexing
0-RTT Connection Resumption HTTP/3 (QUIC) Re-establish secure connections instantly without multi-trip TLS handshakes
Legacy Systems & Old Enterprise Proxies HTTP/1.1 Universal compatibility across every legacy firewall, proxy, and web server
Global CDN Edge Acceleration HTTP/3 (QUIC) Cloudflare / Fastly terminate QUIC at edge PoPs close to mobile users

5. Tradeoffs

  1. Text Formatting (H1) vs Binary Framing (H2/H3)
  2. Gain (H2/H3): Compact binary parsing; zero text scanning overhead.
  3. Lose (H2/H3): Cannot inspect raw HTTP frames directly via simple telnet/cURL without HTTP/2 awareness.
  4. TCP Connection Limits (H1) vs Stream Multiplexing (H2)
  5. Gain (H2): 1 TCP connection serves hundreds of parallel streams, saving server socket memory.
  6. Lose (H2): TCP packet loss drops 1 packet, freezing all multiplexed streams on that TCP connection.
  7. TCP Transport HoL Blocking vs UDP QUIC Stream Independence (H3)
  8. Gain (H3): A lost UDP packet only delays its specific stream; all other streams continue processing.
  9. Lose (H3): Some enterprise firewalls restrict or throttle UDP traffic on Port 443.
  10. IP-Based Connection Binding (TCP) vs Connection ID Migration (QUIC)
  11. Gain (H3): Client switching from Wi-Fi to cellular maintains active QUIC connection via 64-bit Connection ID.
  12. Lose (H3): CPU-intensive UDP packet handling in OS user-space compared to hardware-accelerated TCP stacks.
  13. HPACK (H2) vs QPACK (H3) Header Compression
  14. Gain (H3): QPACK compresses headers asynchronously without forcing strict stream ordering.
  15. Lose (H3): Higher memory overhead for dynamic header table management.

6. Interview Counter Questions

  1. What is Head-of-Line (HoL) Blocking in HTTP/1.1 vs HTTP/2 vs HTTP/3?
  2. How does HTTP/2 Multiplexing work and why does TCP packet loss degrade HTTP/2 performance?
  3. How does QUIC solve Transport-Layer Head-of-Line blocking over UDP?
  4. What is 0-RTT Connection Establishment in HTTP/3 and how does it combine transport and TLS handshakes?
  5. How does QUIC Connection Migration work when a mobile user switches from Wi-Fi to 5G?
  6. What is the difference between HPACK (HTTP/2) and QPACK (HTTP/3) header compression?
  7. Why do some corporate networks block HTTP/3 traffic and how does Alt-Svc header fallback work?
  8. How does HTTP/2 Server Push work and why was it deprecated in Chrome?
  9. Why does QUIC consume higher CPU on server instances compared to TCP?
  10. How do you configure Nginx or Caddy to serve HTTP/3 alongside HTTP/2?

7. Gold Standard Answers

  1. HTTP/1.1: Application HoL blocking (requests queue behind slow responses on a TCP connection). HTTP/2: Solves application HoL, but TCP packet loss causes Transport HoL blocking (all streams freeze while TCP retransmits lost packet). HTTP/3: Eliminates transport HoL blocking completely using independent QUIC streams over UDP.
  2. HTTP/2 divides messages into binary frames tagged with Stream IDs over 1 TCP connection. If 1 TCP packet is lost, the OS TCP stack holds up all subsequent packets until retransmission arrives, blocking all streams.
  3. QUIC runs over UDP and manages individual stream flow control independently. If a UDP packet belonging to Stream A is lost, Stream B and C continue processing without waiting.
  4. QUIC integrates the transport and TLS 1.3 handshake into a single exchange (1-RTT). For returning clients, QUIC uses cached session keys to send encrypted request data in the very first packet (0-RTT).
  5. TCP binds connections to a 4-tuple (Source IP, Source Port, Dest IP, Dest Port). Changing networks breaks the 4-tuple and drops the connection. QUIC binds connections to a unique 64-bit Connection ID, allowing seamless IP migration.
  6. HPACK requires strict in-order delivery of compressed header fields, which forces stream blocking if a packet is lost. QPACK allows out-of-order header compression decoding using stream-local and dynamic tables.
  7. Firewalls block UDP Port 443 assuming DDoS attacks. Servers use the Alt-Svc: h3=":443" HTTP header to inform clients HTTP/3 is available. If QUIC fails, clients gracefully fall back to HTTP/2 over TCP.
  8. HTTP/2 Server Push allowed servers to send un-requested assets to the browser. It was deprecated because it often raced with browser caches, wasting bandwidth pushing assets the browser already had cached.
  9. TCP stack processing is optimized inside the OS kernel and NIC hardware. QUIC packet processing historically ran in OS user-space over UDP, incurring higher CPU context switching overhead (now mitigated via eBPF and UDP Segmentation Offload / USO).
  10. Enable QUIC listener in web server (listen 443 quic reuseport;), configure TLS 1.3 certificates, and add header add_header Alt-Svc 'h3=":443"; ma=86400'; to announce HTTP/3 support to clients.

8. Common Mistakes

  • Assuming HTTP/2 solves all Head-of-Line blocking without realizing that TCP packet loss still freezes all HTTP/2 streams.
  • Blocking UDP Port 443 on cloud firewalls, preventing mobile clients from establishing HTTP/3 connections.
  • Using HTTP/2 Server Push in production applications, causing cache racing and wasted mobile bandwidth.
  • Disabling TLS on HTTP/2 or HTTP/3 (both specs effectively require TLS 1.2+ / TLS 1.3 in production browsers).
  • Expecting HTTP/3 to improve latency on stable fiber-optic connections (HTTP/3 benefits most on lossy/mobile networks).

9. Keywords

HTTP/1.1, HTTP/2, HTTP/3, QUIC, UDP, Head-of-Line (HoL) Blocking, Multiplexing, Binary Framing, HPACK, QPACK, 0-RTT, Connection Migration, Connection ID, Alt-Svc, TLS 1.3, UDP Segmentation Offload (USO).

10. Cheat Sheet

  • HTTP/1.1: Text-based, sequential requests over TCP, App-level HoL blocking, max 6 connections per domain.
  • HTTP/2: Binary framing, HPACK header compression, stream multiplexing over 1 TCP connection. (Shedding: TCP packet loss freezes ALL streams).
  • HTTP/3: Built on QUIC over UDP. Zero transport HoL blocking, 0-RTT connection establishment, Connection ID migration (Wi-Fi \(\rightarrow\) 5G).
  • Fallback: Clients check Alt-Svc: h3=":443" header. If UDP is blocked by firewall, clients fall back to HTTP/2.
  • Mobile Benefit: HTTP/3 delivers massive SLA improvements for mobile apps on lossy 5G/Wi-Fi networks.
  • gRPC Baseline: gRPC requires HTTP/2 binary framing natively.

11. Related Decisions