Why HTTP/3 and QUIC Are Revolutionizing Web Performance

After years of development, the IETF officially published the HTTP/3 RFC on June 6, delivering a comprehensive specification of the third major version of the Hypertext Transfer Protocol.

HTTP History

1991: HTTP/1.1

2009: Google designs TCP‑based SPDY

2013: QUIC

2015: HTTP/2

2018: HTTP/3

HTTP/3 retains QUIC's stability while using UDP to achieve high speed without sacrificing TLS security.

QUIC Protocol Overview

QUIC (Quick UDP Internet Connections) is a UDP‑based protocol that combines the advantages of TCP, TLS, and HTTP/2 and optimizes them. The diagram below illustrates the relationship among these protocols.

QUIC replaces TCP and SSL/TLS at the transport layer; any application‑layer protocol (HTTP, FTP, IMAP, etc.) can run over QUIC. When HTTP runs over QUIC, it is referred to as HTTP over QUIC or simply HTTP/3.

0‑RTT Connection Establishment

RTT: round‑trip time, the time for a request to travel to the server and back.

HTTP/3 establishes a connection with only 1RTT for the first handshake and 0RTT for subsequent requests, allowing the client to send data in the very first packet.

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

The server generates parameters g, p, a, computes A, and returns a Rejection message containing these values.

The client generates b, computes B and the initial key K, encrypts HTTP data with K, and sends B and the encrypted data to the server.

The server derives the same key, decrypts the data, updates its random number a and public key, and sends a Server Hello together with the HTTP response.

Connection Migration

TCP connections are identified by a four‑tuple (source IP, source port, destination IP, destination port). Changing any element forces a new TCP connection, causing delays. QUIC uses a 64‑bit random Connection ID, so the connection persists even when IP or ports change.

Head‑of‑Line Blocking and Multiplexing

Both HTTP/1.1 and HTTP/2 suffer from head‑of‑line (HoL) blocking. TCP requires an ACK for each packet, and pipelines or streams can still be blocked if a single packet is lost. Browsers typically open up to six parallel TCP connections, but HoL blocking remains.

HTTP/2 mitigates HoL at the request level by splitting each request into multiple Frame s transmitted over a single TCP connection, but the underlying TCP and TLS layers still exhibit HoL behavior.

How QUIC Solves HoL Blocking

QUIC’s transmission unit is a Packet; encryption, transmission, and decryption all operate on packets, avoiding TLS‑level blocking.

Because QUIC runs over UDP, packets are processed independently; loss of a packet does not stall the entire connection.

Congestion Control

Congestion control prevents overwhelming the network. QUIC re‑implements TCP’s Cubic algorithm and adds several enhancements:

1. Hot‑Swap

TCP requires kernel‑level changes to switch congestion algorithms, whereas QUIC can change them at the application layer and dynamically select the best algorithm for the current network.

2. Forward Error Correction (FEC)

QUIC adds FEC packets generated by XOR‑ing groups of data packets; if one packet is lost, it can be reconstructed from the remaining packets and the FEC packet.

3. Monotonically Increasing Packet Number

Unlike TCP’s Sequence Number, QUIC uses a strictly increasing Packet Number. Retransmitted packets receive a higher number, eliminating ambiguity between original and retransmitted ACKs.

4. ACK Delay

QUIC accounts for the delay between receiving data and sending an ACK, resulting in more accurate RTT measurements.

5. More ACK Blocks

QUIC can carry up to 256 ACK blocks in a single ACK, reducing retransmissions on lossy links.

Flow Control

TCP flow control uses a sliding window to prevent the sender from overwhelming the receiver. QUIC implements two levels of flow control: connection‑level and stream‑level.

For each stream, the receive window shrinks as data arrives; when the remaining window falls below half of the maximum, the receiver sends a WINDOW_UPDATE frame to allow more data.

receive_window = max_receive_window - received_data

At the connection level, the total receive window is the sum of all stream windows:

receive_window = stream1_window + stream2_window + ... + streamN_window

Reference Links

HTTP/3 Principles in Practice – https://mp.weixin.qq.com/s?__biz=MjM5ODYwMjI2MA==&mid=2649746858&idx=1&sn=26e90bb6dde7541fb9fe9f121eb11984