Why HTTP/3 Beats HTTP/2: A Deep Dive into QUIC’s Innovations

HTTP Evolution Timeline

Key milestones in the HTTP protocol family are:

1991 – HTTP/1.1 introduced.

2009 – Google designed SPDY, a TCP‑based protocol that added multiplexing and header compression.

2013 – QUIC (Quick UDP Internet Connections) was proposed as a UDP‑based transport.

2015 – HTTP/2 standardized, reusing many SPDY concepts but still built on TCP.

2018 – HTTP/3 standardized; it runs over QUIC and retains TLS security while using UDP for lower latency.

QUIC Protocol Overview

QUIC is a transport protocol that uses UDP as its underlying carrier. It combines the low‑latency nature of UDP with reliability mechanisms traditionally provided by TCP, TLS, and HTTP/2. QUIC can carry any application‑layer protocol; when HTTP is run on top of QUIC the resulting protocol is called HTTP/3.

Connection Establishment and RTT

Connection setup latency differs markedly between HTTP/2 (TCP) and HTTP/3 (QUIC):

HTTP/2 requires three round‑trip times (RTT) for a fresh TLS 1.2 connection, two RTT when TLS 1.3 is used, and one RTT when a previous session is resumed.

HTTP/3 establishes the first connection with a single RTT and subsequent connections can use 0‑RTT, allowing the client to send request data in the very first packet.

The QUIC handshake (simplified) proceeds as follows:

Client sends an Inchoate Client Hello to request a connection.

Server generates Diffie‑Hellman parameters g, p, a, computes A = g^a mod p, and returns a Server Config containing g, p, A together with a Rejection message.

Client receives g, p, A, generates its own secret b, computes B = g^b mod p and the shared secret K = A^b mod p. It encrypts the initial HTTP payload with K and sends B plus the encrypted data to the server.

Server derives the same secret K = B^a mod p, decrypts the payload, then rotates its own secret a and public key, creates a new secret S, and sends a Server Hello containing the new public key and the HTTP response.

Connection Migration

TCP binds a connection to a four‑tuple (source IP, source port, destination IP, destination port). Any change in these fields forces a new TCP connection. QUIC instead uses a 64‑bit Connection ID . As long as the Connection ID remains unchanged, the QUIC connection survives IP or port changes, enabling seamless migration between networks (e.g., Wi‑Fi ↔ cellular).

Head‑of‑Line Blocking and Multiplexing

TCP delivers data in order; loss of a single packet stalls all subsequent streams (head‑of‑line blocking). QUIC mitigates this by:

Using UDP packets as the atomic transmission unit; each packet is encrypted and processed independently.

Not enforcing ordering at the transport layer, so lost packets are retransmitted without stalling other streams.

Congestion Control

QUIC implements congestion‑control algorithms in user space, allowing hot‑plug replacement without kernel changes. It adopts the TCP Cubic algorithm and adds several enhancements:

Hot‑plugging: Applications can switch congestion‑control strategies at runtime.

Forward Error Correction (FEC): Data is split into ten packets; an XOR‑based FEC packet enables recovery of any single lost packet.

Monotonically increasing Packet Number: Packet numbers increase strictly, eliminating ambiguity between original and retransmitted packets.

ACK Delay accounting: QUIC includes the receiver’s processing delay when computing RTT, yielding more accurate RTT estimates.

Extended ACK blocks: Up to 256 ACK blocks can be carried, reducing unnecessary retransmissions in lossy environments.

Flow Control

QUIC provides two levels of flow control to prevent a sender from overwhelming the receiver:

Stream‑level flow control: Each stream has its own receive window. The window shrinks as data is received and expands when the receiver sends a WINDOW_UPDATE frame.

Connection‑level flow control: The overall connection window equals the sum of all stream windows, coordinating bandwidth across streams.

Reference: https://www.cnblogs.com/YYFaGe/p/16599675.html