Understanding HTTP History, QUIC, and HTTP/3: Protocol Evolution, Connection Migration, and Congestion Control

The article provides a comprehensive overview of the development of HTTP protocols and the emergence of QUIC as the transport layer for HTTP/3.

HTTP History

1991 – HTTP/1.1

2009 – Google designs SPDY on top of TCP

2013 – QUIC is introduced

2015 – HTTP/2 is standardized

2018 – HTTP/3 (HTTP over QUIC) is standardized

QUIC Overview

QUIC (Quick UDP Internet Connections) is a UDP‑based protocol that integrates the functions of TCP, TLS, and HTTP/2, offering higher speed and maintaining TLS security.

RTT and Connection Establishment

HTTP/2 requires 2–3 RTTs for a new connection (or 1–2 RTTs with TLS 1.3 and session reuse). In contrast, HTTP/3 can establish the first connection with only 1 RTT and subsequent connections with 0 RTT, because the client can send request data in the initial packet.

Connection Migration

Unlike TCP, which binds a connection to a four‑tuple (source IP, source port, destination IP, destination port), QUIC uses a 64‑bit Connection ID. When the IP or port changes, the connection persists as long as the Connection ID remains unchanged.

Head‑of‑Line Blocking and Multiplexing

HTTP/1.1 and HTTP/2 suffer from head‑of‑line (HoL) blocking at the TCP layer. HTTP/2 mitigates HoL at the request level by multiplexing frames over a single TCP connection, but TCP’s packet ordering still causes blocking. QUIC eliminates this issue because each QUIC packet is encrypted and processed independently, so loss of a packet does not stall the entire stream.

Congestion Control

QUIC inherits TCP’s Cubic algorithm but allows hot‑swapping of congestion‑control strategies at the application layer.

It incorporates Forward Error Correction (FEC) to recover lost packets without retransmission.

ACK delay is accounted for, providing more accurate RTT measurements.

QUIC can carry up to 256 ACK blocks, reducing ACK overhead in lossy networks.

Packet Number Monotonicity

QUIC uses a strictly increasing packet number instead of TCP’s sequence number, eliminating ambiguity when distinguishing ACKs for original versus retransmitted packets.

Flow Control

QUIC implements two levels of flow control: connection‑level and stream‑level. The receiver advertises a receive window that shrinks as data arrives and expands when processed, sending WINDOW_UPDATE frames when the window falls below half of the maximum.

Overall, QUIC addresses many limitations of TCP‑based HTTP, offering lower latency, better loss tolerance, and more flexible congestion‑control and flow‑control mechanisms for modern web services.