Why HTTP/3 and QUIC Are Revolutionizing Web Performance

HTTP History

1991: HTTP/1.1

2009: Google designs TCP‑based SPDY

2013: QUIC

2015: HTTP/2

2018: HTTP/3

On June 6 the IETF officially published the HTTP/3 RFC, a detailed 20,000‑word specification that defines the third major version of the Hypertext Transfer Protocol.

Problems with HTTP/2

Head‑of‑line (HoL) blocking caused by ordered byte streams reduces multiplexing efficiency.

TCP + TLS adds handshake latency, leaving room for a 1‑RTT reduction.

TCP connections are bound to a four‑tuple (source IP, source port, destination IP, destination port); when any element changes (e.g., mobile network handover) the connection must be re‑established, incurring extra delay.

How HTTP/3 Solves These Issues

HTTP/3 runs over QUIC, which uses UDP and provides unordered, concurrent byte streams, eliminating HoL blocking (including QPACK‑based header blocking).

QUIC integrates TLS encryption at the packet level, achieving security without sacrificing speed; a connection can be established with a single RTT.

QUIC separates Packet, QUIC Frame, and HTTP/3 Frame, enabling seamless connection migration and reducing overhead for high‑speed mobile (5G) scenarios.

QUIC Overview

QUIC (Quick UDP Internet Connections) combines the speed of UDP with the reliability features of TCP, TLS, and HTTP/2, allowing any application‑layer protocol (including HTTP/3) to run on top of it.

Key QUIC features include:

0‑RTT connection establishment.

Packet‑level encryption and transmission.

Connection IDs that make connections independent of IP/port changes.

0‑RTT Connection Establishment

Client sends an Inchoate Client Hello to request a connection.

Server generates parameters (g, p, a) and sends them in a Server Config within a Rejection message.

Client computes its own values (b, B) and derives the initial key K, encrypts HTTP data, and sends B + encrypted data.

Server uses the received values to derive the same key, decrypts the data, updates its random numbers, and sends a Server Hello with the HTTP response.

DH Key Exchange

The Diffie‑Hellman exchange lets the server generate random numbers a, g, p; the client generates b. Both sides compute a shared secret without transmitting a or b, providing forward secrecy even if the public parameters are intercepted.

Connection Migration

Unlike TCP, QUIC does not rely on the four‑tuple; it uses a 64‑bit random Connection ID, so the connection persists across IP or port changes.

Head‑of‑Line Blocking and Multiplexing

Both HTTP/1.1 and HTTP/2 suffer from HoL blocking. HTTP/2 mitigates it with streams and frames, but the underlying TCP still imposes ordering constraints, causing delays when packets are lost.

QUIC eliminates this by transmitting independent packets; loss of one packet does not block others.

QUIC Congestion Control

Hot‑plugable congestion algorithms selectable at the application layer.

Forward Error Correction (FEC) adds redundancy to recover from single‑packet loss without retransmission.

Monotonically increasing Packet Numbers avoid ambiguity between original and retransmitted packets.

ACK Delay accounts for receiver processing time, yielding more accurate RTT measurements.

Up to 256 ACK blocks per packet improve efficiency on lossy links.

Flow Control (Browsing Control)

QUIC implements two levels of flow control: connection‑level and stream‑level. Each stream has a receive window that shrinks as data arrives and expands when the receiver processes data and sends a WINDOW_UPDATE frame. The overall connection window is the sum of all stream windows.

Reference

HTTP/3 Principles in Practice (original article)