Overview

HTTP/2 and HTTP/3 both let a browser send many requests over one logical connection, but they diverge at the transport layer. HTTP/2 rides on TCP, inheriting its single ordered byte stream and its packet-loss stalls; HTTP/3 replaces that with QUIC over UDP, giving each stream independent loss recovery and letting connections survive network changes.

Comparison Diagram

HTTP/2 (TCP)HTTP/3 (QUIC/UDP)Stream AStream BStream CStream AStream BStream CSingle TCP connectionOne lost packet stalls every streamIndependent QUIC streamsLoss stalls only its own streamX = lost packet dashed = blocked/waiting

Comparison Table

AspectHTTP/2HTTP/3
Transport protocolRuns over TCPRuns over QUIC (built on UDP)
Connection handshakeSeparate TCP handshake, then TLS handshake (1-2 RTT)TLS 1.3 is integrated into the QUIC handshake, often 1-RTT or 0-RTT on resumption
Stream multiplexingMultiple streams share one ordered TCP byte streamEach stream is a distinct, independently-sequenced QUIC stream
Head-of-line blockingA single lost TCP segment stalls delivery of every stream until it’s retransmittedLoss on one stream only stalls that stream; others keep flowing
Header compressionHPACKQPACK
Connection identity and migrationBound to the source/destination IP and port 4-tuple; changing networks breaks itBound to a connection ID; survives IP or network changes, e.g. Wi-Fi to cellular
Congestion control and loss recoveryImplemented in the OS kernel’s TCP stackImplemented in user-space by the QUIC library, easier to iterate on
Network and middlebox supportUbiquitous; TCP port 443 is rarely blockedUDP is sometimes blocked or throttled by firewalls, requiring a TCP fallback

Key Differences

  • HTTP/2 multiplexes streams inside a single TCP connection, while HTTP/3 gives each stream its own loss-recovery in QUIC
  • TCP’s in-order delivery means one dropped packet causes head-of-line blocking across all HTTP/2 streams; HTTP/3 avoids this by design
  • HTTP/3 folds the transport and TLS handshakes together for faster 0-RTT setup on reconnection
  • QUIC’s connection ID lets HTTP/3 sessions survive a client’s IP or network change without reconnecting
  • HTTP/3 depends on UDP reaching the server, so restrictive middleboxes can force a fallback to HTTP/2

When to Use Each

HTTP/2

  • Firewall-restricted networks: Corporate or legacy networks often filter UDP, so TCP-based HTTP/2 is more reliably reachable.
  • Stable, low-latency links: On a wired connection with negligible packet loss, TCP’s head-of-line blocking rarely matters in practice.
  • Older infrastructure: Load balancers, proxies, and CDNs without QUIC support still terminate HTTP/2 over TCP natively.

HTTP/3

  • Mobile clients switching networks: QUIC’s connection migration keeps a session alive when a device moves from Wi-Fi to cellular.
  • Lossy or high-latency links: Per-stream loss recovery avoids the multi-stream stalls that TCP’s HOL blocking causes on wireless or long-RTT paths.
  • Latency-sensitive reconnects: 0-RTT session resumption gets a returning client’s request moving with minimal round trips.