Why HTTP/3 Beats HTTP/2: Inside QUIC’s Fast, Secure Transport

HTTP Evolution

1991 – HTTP/1.1

2009 – Google designs TCP‑based SPDY

2013 – Introduction of QUIC

2015 – HTTP/2 (multiplexed over TCP)

2018 – HTTP/3 (HTTP over QUIC)

HTTP/3 retains QUIC’s stability while using UDP for lower latency and keeps TLS security.

QUIC Protocol Overview

QUIC (Quick UDP Internet Connections) is a transport protocol built on UDP that integrates the reliability of TCP, the security of TLS, and the multiplexing of HTTP/2. It replaces TCP and SSL/TLS at the transport layer, allowing any application‑layer protocol (e.g., HTTP, FTP, IMAP) to run over it. When HTTP runs on QUIC, the resulting protocol is called HTTP/3.

RTT‑Based Connection Establishment

Round‑Trip Time (RTT) measures the time for a request‑response exchange. Connection setup costs differ:

HTTP/2 over TLS 1.3: 2 RTT (1 RTT with session resumption).

HTTP/3 (first connection): 1 RTT.

Subsequent HTTP/3 connections: 0 RTT (client can send data in the first packet).

The QUIC 1‑RTT handshake uses a Diffie‑Hellman (DH) key exchange:

Client sends an Inchoate Client Hello to request a connection.

Server generates DH parameters g, p, a private secret a, computes public A = g^a mod p, and returns them in a Server Config together with a Rejection message.

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

Server computes the same shared secret K = B^a mod p, decrypts the payload, updates its DH secret for forward secrecy, and sends a Server Hello containing the new public key and the HTTP response.

The large primes g and p make passive interception computationally infeasible.

Connection Migration

TCP connections are bound to a four‑tuple (source IP, source port, destination IP, destination port). Any change forces a new TCP connection, causing noticeable delay. QUIC uses a 64‑bit Connection ID that remains constant across IP/port changes, enabling seamless migration without breaking the existing connection.

Head‑of‑Line Blocking and Multiplexing

Both HTTP/1.1 and HTTP/2 suffer from head‑of‑line (HoL) blocking because TCP delivers data in order. If a single packet is lost, all subsequent packets are held back until the missing packet is retransmitted, reducing throughput.

HTTP/2 mitigates HoL at the application layer by multiplexing streams into frames, but the underlying TCP still blocks the whole connection on loss.

QUIC solves this by:

Using UDP, which does not enforce ordering; each QUIC packet is independent.

Encrypting and transmitting data at the packet level, so loss of one packet does not stall other streams.

Congestion Control in QUIC

QUIC re‑implements TCP’s Cubic algorithm and adds several enhancements:

1. Hot‑Plug Congestion Controllers

Unlike TCP, which requires kernel modifications to change the congestion algorithm, QUIC can switch algorithms at the application layer, allowing dynamic selection based on real‑time network conditions.

2. Forward Error Correction (FEC)

Data is split into 10 packets; an additional FEC packet is generated by XOR‑ing the 10 payloads. If any single data packet is lost, the receiver can reconstruct it from the remaining nine packets plus the FEC packet, reducing retransmissions.

3. Monotonically Increasing Packet Numbers

TCP sequence numbers can be ambiguous when a retransmitted packet is ACKed, leading to inaccurate RTT estimates. QUIC’s packet numbers always increase; a retransmission uses a higher number, eliminating ambiguity.

4. ACK Delay Accounting

TCP’s RTT calculation ignores the receiver’s processing delay before sending an ACK. QUIC measures and subtracts this ACK delay, yielding more accurate RTT estimates.

5. Larger ACK Block Capacity

TCP’s Selective ACK (SACK) can convey up to three ACK blocks. QUIC can carry up to 256 ACK blocks in a single ACK frame, reducing the number of ACK packets needed in high‑loss environments and improving efficiency.

Flow Control (Browser‑Level)

TCP uses a sliding‑window mechanism that only considers the sender’s side. QUIC implements flow control at two levels:

Connection‑level : The total receive window equals the sum of all stream windows.

Stream‑level : Each stream has an independent receive window that shrinks as data arrives and expands when the receiver processes data and sends a WINDOW_UPDATE frame.

When a stream’s remaining window falls below half of its maximum, the receiver notifies the sender to increase the window, allowing more data to be sent.

Receive window = maximum receive window – already received data (per stream)

Connection receive window = sum of all stream receive windows

These mechanisms enable QUIC to maintain high throughput while preventing both congestion and flow‑control stalls.