Why QUIC and HTTP/3 Are Redefining Internet Speed: A Deep Dive into Their History and Mechanics

HTTP Evolution

Key milestones: HTTP/1.1 (1991), SPDY (2009), QUIC (2013), HTTP/2 (2015), HTTP/3 (2018). HTTP/3 is built on QUIC, which uses UDP for low‑latency transport while preserving TLS security.

QUIC Protocol Overview

QUIC (Quick UDP Internet Connections) is a UDP‑based transport that integrates the reliability of TCP, the security of TLS, and the multiplexing of HTTP/2. It serves as the transport layer for HTTP/3 and can theoretically carry any application‑layer protocol (e.g., FTP, IMAP).

Connection Establishment (RTT)

Round‑Trip Time (RTT) measures the time for a request to reach the server and for the response to return. HTTP/2 needs three RTTs for a fresh TLS handshake (two RTTs with session resumption, one RTT with TLS 1.3). QUIC reduces the initial handshake to a single RTT and subsequent connections can use 0‑RTT, allowing the client to send encrypted HTTP data in the first packet.

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 g, p, A in a Server Config together with a Rejection message.

Client receives g, p, A, generates its 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.

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

The handshake provides forward secrecy because the private exponents a and b never leave their respective endpoints.

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 delay. QUIC uses a 64‑bit Connection ID that remains constant across IP or port changes, enabling seamless migration without breaking the session.

Head‑of‑Line Blocking and Multiplexing

HTTP/1.1 suffers from head‑of‑line (HoL) blocking at the request level; HTTP/2 mitigates this by multiplexing streams into frames over a single TCP connection. However, TCP still enforces in‑order delivery, so a lost packet stalls all streams. QUIC eliminates TCP‑induced HoL because each packet is independently encrypted and delivered over UDP, which does not require ordering.

Congestion Control

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

Hot‑plug : Congestion control can be switched at the application layer without kernel changes; QUIC can dynamically select the best algorithm for the current network.

Forward Error Correction (FEC) : Data is split into 10 packets; an XOR‑based parity packet is sent alongside. If any single packet is lost, it can be reconstructed from the remaining nine plus the parity packet.

Monotonically increasing packet numbers : Unlike TCP sequence numbers, QUIC packet numbers always increase, removing ambiguity between original and retransmitted packets.

ACK delay accounting : QUIC measures the time between data receipt and ACK transmission, yielding more accurate RTT estimates.

More ACK blocks : Up to 256 ACK blocks can be carried per packet (TCP’s SACK supports at most three), reducing unnecessary retransmissions in lossy environments.

Flow Control

QUIC implements two levels of flow control:

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

Stream‑level : Each stream has its own window that shrinks as data is received. When the remaining window falls below half of the maximum, the receiver sends a WINDOW_UPDATE frame to allow the sender to transmit more data.

These mechanisms together give QUIC lower latency, higher throughput, and better resilience compared with TCP‑based HTTP/2.