HTTP/3

HTTP/3 represents a fundamental transition in how internet applications communicate. For decades, web communication relied on TCP (Transmission Control Protocol) to manage data reliability, ordering, and flow control. However, as web applications evolved to load hundreds of assets concurrently, the constraints of TCP became a primary performance bottleneck.

HTTP/3 breaks free from these limitations by replacing TCP with QUIC (Quick UDP Internet Connections), a new transport layer protocol built on top of UDP (User Datagram Protocol). QUIC re-implements reliability, congestion control, and connection handshake logic in user space, resolving legacy architectural bottlenecks while incorporating modern cryptographic security by default.

Consider a logistics depot delivering three separate customer orders (representing application data streams) to their destinations:

• HTTP/2 (TCP) is like packing all three orders onto a single large flatbed truck. The truck drives along a highway (a single TCP connection). If a single tire punctures (packet loss), the entire truck must pull over to the side of the road. Even if the packages for Customer 2 and Customer 3 are fully intact, they cannot be delivered until the tire is repaired (retransmission of the lost packet).
• HTTP/3 (QUIC) is like loading the three orders into three separate delivery vans. The vans travel along the highway concurrently. If the van carrying Customer 1's order breaks down, the vans carrying Customer 2 and Customer 3's orders continue their journeys unimpeded. They arrive and deliver their cargo on schedule, isolated from the failure affecting Customer 1.

HTTP/2 introduced multiplexing, allowing multiple request and response streams to be interleaved over a single TCP connection. However, because TCP treats the entire connection as a single, ordered byte stream, it is unaware of these logical divisions.

If a TCP segment is lost in transit, the receiving operating system kernel must buffer all subsequent segments in its TCP receive queue. It cannot pass these successful segments to the user space application until the missing segment is retransmitted and received. This condition, known as transport layer head-of-line (HoL) blocking, causes latency spikes and throughput degradation on networks with high packet loss, such as mobile networks or congested Wi-Fi.

HTTP/3 resolves this issue by delegating multiplexing to the transport layer. QUIC understands the concept of independent streams natively. When a packet containing data for Stream 1 is lost, QUIC pauses only Stream 1. Packets for Stream 2 and Stream 3 continue to be processed and dispatched to user space immediately.

QUIC runs directly over UDP, bypassing the operating system kernel's TCP stack. This shift offers several critical advantages:

• Custom Flow Control: Flow control is managed at both the connection level and individual stream level. Stream limits prevent a single fast stream from consuming the entire receive buffer, while connection limits govern overall memory consumption.
• User-Space Implementation: Because QUIC runs on top of UDP, its implementation is housed in user space rather than the operating system kernel. This architecture allows rapid optimization, security updates, and protocol evolution without requiring OS upgrades.
• Active Congestion Control: QUIC defines a pluggable congestion control interface, supporting algorithms like BBR (Bottleneck Bandwidth and Round-trip propagation time) and CUBIC natively in user space.

In traditional networks, a TCP connection is bound to a unique four-tuple: source IP, source port, destination IP, and destination port. If a client switches from a Wi-Fi network to cellular data, their source IP address changes. This change invalidates the four-tuple, forcing the operating system to terminate the TCP connection and establish a new one, causing application delays.

QUIC replaces four-tuple bindings with a 64-bit Connection ID (CID). The CID is independent of the network routing layer. When a client changes IP addresses:

1. The client sends a packet containing the existing Connection ID from its new IP address.
2. The server authenticates the client using cryptographic tokens associated with the CID.
3. The connection is migrated seamlessly to the new IP-port path without requiring a renegotiated handshake. This mechanism is known as Connection Migration.

Establishing an HTTPS connection over TCP requires multiple network round trips:

1. TCP Handshake (1 RTT): Exchanges SYN and ACK packets to establish transport ordering.
2. TLS Handshake (1 to 2 RTTs): Negotiates cryptographic parameters and exchanges certificates.

HTTP/3 consolidates transport and security configurations into a single unified handshake. Because QUIC integrates TLS 1.3 directly into its transport design, the handshake requires only 1 RTT:

Client                                      Server
  |                                           |
  |--- ClientHello + TransportParameters ---->|  (1 RTT: Unified Handshake)
  |<-- EncryptedExtensions + Cert + Finished -|
  |                                           |
  |====== Encrypted HTTP/3 Application Data ===|

On subsequent connections, QUIC supports 0-RTT resumption. The client uses previously cached session parameters to encrypt and transmit HTTP/3 requests in the very first packet, eliminating initial round-trip latency.

HTTP/2 uses HPACK to compress headers, maintaining a synchronized state table of headers on both the client and server. However, HPACK requires strict ordering of header blocks. If a packet containing header updates is lost, the receiver cannot decompress subsequent headers on other streams, reintroducing head-of-line blocking.

HTTP/3 utilizes QPACK (RFC 9204), which allows out-of-order header decompression. QPACK splits its design into:

• Static Table: A predefined list of 98 common header fields.
• Dynamic Table: A stateful table constructed from headers exchanged during the connection.
• Encoder and Decoder Streams: Dedicated unidirectional streams used to update and acknowledge dynamic table states.

If a header refers to a dynamic table index that the decoder has not yet processed, only that specific request stream is blocked. Other streams that reference the static table or already synchronized dynamic indexes are processed immediately.

Despite its advantages, deploying HTTP/3 introduces infrastructure hurdles:

• UDP Port Blocking: Many enterprise firewalls and ISPs block UDP port 443, assuming it is malicious traffic or DNS abuse.
• Fallback Mechanisms: To handle UDP blocking, web servers utilize the Alt-Svc (Alternative Services) response header to advertise HTTP/3 support:
  http 123

  Copy

  Alt-Svc: h3=":443"; max=2592000

  A browser initial request connects via TCP (HTTP/2 or HTTP/1.1). Upon reading the Alt-Svc header, the browser attempts to upgrade subsequent connections to HTTP/3. If the UDP attempt fails or times out, it gracefully falls back to TCP.

• RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport — The foundational QUIC protocol specification.
• RFC 9114: Hypertext Transfer Protocol Version 3 (HTTP/3) — The official HTTP/3 standard mapping semantics to QUIC.
• RFC 9204: QPACK: Header Compression for HTTP/3 — Architectural details of the QPACK compression mechanism.