Why HTTP/3 and QUIC Are Revolutionizing Web Performance

After the HTTP/2 standard was published in 2015 and quickly adopted by major browsers, developers began favoring its multiplexing, header compression, and server push features. This article shares the principles of HTTP/3 and practical ways to adopt it.

1. HTTP/3 Principles

1.1 HTTP History

To understand HTTP/3, we first review HTTP's evolution. HTTP/1.1 (1999) could not meet modern demands, leading Google to create SPDY (2009) on TCP, which later influenced HTTP/2. Because TCP has inherent efficiency drawbacks compared to UDP, Google developed QUIC (Quick UDP Internet Connections) in 2013, and the IETF later renamed HTTP over QUIC to HTTP/3.

1.2 QUIC Overview

QUIC replaces TCP with UDP, leveraging UDP's speed while integrating the advantages of TCP, TLS, and HTTP/2. It operates as the transport layer for HTTP/3, allowing HTTP to run directly over QUIC.

1.3 Zero‑RTT Connection Establishment

HTTP/2 requires three RTTs for a new connection (or two with session reuse, one with TLS 1.3). HTTP/3 establishes a connection in a single RTT, and subsequent connections can achieve 0‑RTT, sending request data in the first packet.

Step1: The client sends an Inchoate Client Hello to request a connection.

Step2: The server generates g, p, a, computes A, and returns a Server Config with a Rejection message.

Step3: The client receives g, p, A, generates b, computes B and the initial key K, encrypts HTTP data with K, and sends B and the encrypted data.

Step4: The server uses a, p, B to derive the same key, decrypts the data, updates its random number a and public key, generates a new key S, and sends a Server Hello with the new key and HTTP response.

Step5: The client receives Server Hello, derives the new key S, and all subsequent traffic uses S.

1.4 Connection Migration

TCP connections are identified by a four‑tuple (source IP, source port, destination IP, destination port). Changing any element breaks the connection, requiring a new TCP handshake. QUIC uses a 64‑bit random Connection ID instead, so the connection persists across IP or port changes.

1.5 Head‑of‑Line Blocking / Multiplexing

HTTP/1.1 and HTTP/2 suffer from head‑of‑line (HoL) blocking at the TCP layer. HTTP/2 solves request‑level HoL by multiplexing streams into frames, but TCP’s packet ordering still causes HoL at the transport level. QUIC eliminates this by using independent encrypted packets, so loss of one packet does not stall other streams.

1.6 Congestion Control

QUIC adopts TCP’s Cubic algorithm and adds several enhancements:

Hot‑swap: congestion control can be changed at the application layer without kernel modifications.

Forward Error Correction (FEC): adds redundant packets to recover lost data without retransmission.

Monotonic Packet Number: packet numbers always increase, eliminating ambiguity between original and retransmitted packets.

ACK Delay: QUIC accounts for the receiver’s processing delay when calculating RTT, improving accuracy.

More ACK blocks: up to 256 ACK blocks can be bundled, reducing unnecessary ACK traffic on lossy networks.

1.7 Flow Control

QUIC implements flow control at both the connection and stream levels. Each stream has a receive window that shrinks as data arrives and expands when the receiver processes data and sends WINDOW_UPDATE frames. The connection‑level window is the sum of all stream windows, preventing the sender from overwhelming the receiver.

2. Conclusion

By discarding TCP and TLS overhead and building on UDP, QUIC inherits the lessons of TCP, TLS, and HTTP/2 while adding zero‑RTT connections, seamless connection migration, near elimination of head‑of‑line blocking, and improved congestion and flow control. In most scenarios, QUIC delivers better performance than HTTP/2.

Microsoft recently open‑sourced its internal QUIC library, MsQuic, and recommends replacing TCP/IP with QUIC wherever possible.

HTTP/3 has a promising future.