HTTP/3

The Motivation for Change: A Transport-Layer Limitation

Moving from HTTP/1.1 to HTTP/2 improved web performance. HTTP/2 introduced multiplexing, allowing multiple requests and responses to be sent concurrently over a single TCP connection and reducing application-layer head-of-line blocking. A slow request for a large image no longer had to delay a CSS file at the HTTP layer. A transport-layer limitation remained: head-of-line blocking caused by the design of TCP.

HTTP/2 interleaves frames from multiple streams, while TCP delivers them as one ordered byte stream. TCP loss recovery therefore cannot distinguish which HTTP stream is affected by a missing segment.

TCP provides reliable, in-order delivery of a single byte stream. If a packet is lost in transit, TCP delays subsequent bytes, including bytes belonging to independent HTTP/2 streams, until the missing packet is retransmitted and received. A lost packet for an image download can therefore delay rendering of a JavaScript file on the same connection.

TCP-level HOL blocking is especially visible on unreliable or high-latency networks, including mobile networks. The limitation motivated changes to the transport used by HTTP. HTTP/3 was developed as one response to this requirement.

QUIC Transport over UDP

HTTP/3 does not run over TCP. It uses QUIC, which is the protocol's name rather than an acronym for Quick UDP Internet Connections. QUIC integrates TLS 1.3 into connection establishment, and HTTP/3 negotiates the h3 application identifier through ALPN.

QUIC is built on UDP. The User Datagram Protocol (UDP) lets applications send datagrams without establishing a connection and without delivery or ordering guarantees. Datagrams can be lost, duplicated, or delivered out of order.

QUIC adds reliable streams, congestion control, and flow control to UDP. These mechanisms operate independently for streams, while congestion control covers the connection as a whole. QUIC also provides packet encryption and endpoint authentication through TLS.

The QUIC handshake establishes transport parameters, including flow-control limits and stream limits. HTTP/3 sends its own settings on a control stream, while the h3 ALPN identifier selects the application protocol.

Property 1: No HOL Blocking Between Streams

QUIC removes head-of-line blocking between independent streams. Loss of a packet carrying data from one stream does not stop delivery from the other streams. Missing bytes still delay ordered delivery within the affected stream.

In HTTP/2 over TCP, the concept of streams exists only at the application layer. TCP itself is oblivious to them and sees only a single, monolithic byte stream. In contrast, QUIC manages multiple, independent logical streams within a single connection. STREAM frames in QUIC packets contain the stream identifier for the data they carry.

If a packet containing data for Stream 3 is lost, QUIC's reliability mechanism pauses delivery for that stream until the missing data is sent again. Streams 1 and 5, whose packets have arrived, can continue to the application layer. Separating stream handling limits the effect of packet loss on other data, especially on mobile and lossy networks. QUIC sends lost frames in new packets, preserving stream independence.

Property 2: Connection Establishment

HTTP/3 can reduce connection setup time because QUIC combines transport negotiation with TLS 1.3. In HTTP/2 over TCP, establishing a secure connection involves two sequential handshakes:

1. TCP Handshake: Requires one full round-trip between the client and server (SYN -> SYN-ACK -> ACK).
2. TLS Handshake: A full TLS 1.3 handshake usually requires one additional round-trip; older TLS 1.2 configurations could require two.

With TLS 1.3, the first application byte can normally be sent after about two round-trips; TLS 1.2 configurations could require three. The initial delay depends on round-trip time, which is often high on mobile networks.

QUIC's 1-RTT and 0-RTT Handshakes

QUIC combines the transport and cryptographic handshakes in one procedure. A new connection normally uses a 1-RTT handshake; 0-RTT uses state remembered from an earlier connection and requires replay-risk analysis.

• 1-RTT Connection: For a new connection, the client sends a ClientHello message, and the server can respond with a message containing its TLS certificate and all the necessary parameters to establish the secure session. The client can then verify this and start sending encrypted data. This whole process typically takes just one round-trip time (RTT).
• 0-RTT Connection Resumption: a client that knows the server can send early application data with its first handshake message. QUIC 0-RTT data has no protection against replay by an attacker, so a server may reject it and a client should restrict it to operations that are safe to repeat. The mechanism reduces the wait before transmission starts, but it does not remove network latency or request processing time.

A server can accept or reject 0-RTT data. Because early data can be replayed, an application should restrict it to operations with a safe repeated effect or apply replay protection.

Property 3: Connection Migration

QUIC can handle a change of network address through connection migration. A traditional TCP connection is identified by a 4-tuple: the source IP address, source port, destination IP address, and destination port. Changing one of these values makes the existing TCP connection unusable as that tuple.

When a phone switches from Wi-Fi to a cellular network, its IP address can change. From TCP's perspective, this changes the 4-tuple, so an application usually has to establish another TCP and TLS connection and resume the transfer. The change can cause buffering or an interruption in playback.

QUIC uses a Connection ID instead of relying only on IP addresses and ports. After a network change, the client can send packets with this identifier from the new address. The endpoint validates the new path; after successful validation, the connection can continue. Connection IDs can be changed for new paths to support routing and limit linkability. An implementation can disable active migration, and a failed validation requires reverting to the previous path.

An address change can also result from NAT rebinding. An endpoint validates the new path to reduce the risk of sending data to a spoofed address. The connection can then use one validated path at a time.

The HTTP/3 Application Layer

HTTP/3 uses QUIC instead of TCP while retaining HTTP semantics, including requests and responses, fields, methods (GET, POST, etc.), and status codes. HTTP/3 defines Server Push at the HTTP layer. Base RFC 9114 does not define priority signaling; RFC 9218 adds the Priority field and PRIORITY_UPDATE frame for HTTP/2 and HTTP/3. QUIC handles part of the stream machinery.

Mapping HTTP to QUIC Streams

The difference lies in how HTTP semantics map to the transport. QUIC provides a stream abstraction, so each HTTP/3 request-response pair maps to one client-initiated bidirectional QUIC stream. Pushed responses use server-initiated unidirectional streams. In HTTP/2, a framing layer provided a similar function over TCP.

QPACK: Field Compression for QUIC

Field compression remains important. HPACK from HTTP/2 relied on TCP's ordered delivery, while QUIC streams can progress independently. HTTP/3 uses QPACK, which uses separate unidirectional streams to modify and track dynamic field tables. This limits blocking between streams, but an encoded field section can still wait for a missing table entry. A decoder can process a section immediately when it refers only to static or already available dynamic entries.

HTTP/3 Deployment

HTTP/3 is a published standard from 2022. Major browsers, servers, and content delivery networks support it, but an operator must still configure QUIC and permit UDP traffic to the service port.

QUIC may be blocked by firewalls or middleboxes that do not permit UDP traffic to port $443$. A client discovers HTTP/3 support through information such as Alt-Svc, HTTPS DNS records, remembered server state, and its own configuration. A first visit therefore does not always begin with an HTTP/3 attempt. If QUIC is unavailable, the client can use HTTP/2 or HTTP/1.1 over TCP, depending on support at both endpoints.

An Alt-Svc value can identify the host and UDP port for an HTTP/3 service. The client can test that service and remember the result for later requests. A failed QUIC connection should leave TCP-based HTTP versions available.