Understanding HTTP History, QUIC, and HTTP/3: Connection Setup, Head‑of‑Line Blocking, Congestion Control and Flow Control

HTTP History

1991 HTTP/1.1, 2009 Google designed TCP‑based SPDY, 2013 QUIC, 2015 HTTP/2, 2018 HTTP/3. HTTP/3 uses UDP to retain QUIC’s stability while preserving TLS security.

QUIC Overview

QUIC (Quick UDP Internet Connections) is a UDP‑based protocol that combines the advantages of TCP, TLS and HTTP/2, illustrated in the accompanying diagram.

QUIC replaces TCP/SSL/TLS at the transport layer; any application‑layer protocol (HTTP, FTP, IMAP, etc.) can run over QUIC, with HTTP/3 being HTTP over QUIC.

RTT Connection Establishment

HTTP/2 requires 3 RTT for a new connection (2 RTT with session resumption, 1 RTT with TLS 1.3). HTTP/3 needs only 1 RTT for the first connection and 0 RTT for subsequent connections, allowing the client to send request data in the first packet.

Client sends Inchoate Client Hello.

Server replies with Server Config containing g, p, A.

Client generates b, computes B and initial key K, encrypts HTTP data with K and sends B.

Server derives the same key, decrypts data, updates its random numbers, and sends Server Hello with new public key.

Connection Migration

TCP connections are bound to a 4‑tuple; changing any element (IP or port) forces a new connection. QUIC uses a 64‑bit Connection ID, so the connection survives IP/port changes.

Head‑of‑Line Blocking / Multiplexing

Both HTTP/1.1 and HTTP/2 suffer from head‑of‑line (HOL) blocking. TCP’s ordered delivery means a lost packet stalls all later packets. HTTP/2 mitigates this by multiplexing streams into frames, but the underlying TCP still blocks on loss.

Because TLS encrypts records of 16 KB split into multiple TCP packets, loss of any packet prevents decryption of the whole record, worsening HOL blocking under lossy networks.

Congestion Control

QUIC inherits TCP’s congestion‑control concepts (slow start, congestion avoidance, fast retransmit/recovery) and implements the Cubic algorithm. Unlike TCP, QUIC can change congestion‑control strategies at the application layer and selects algorithms dynamically based on network conditions.

1. Hot Plug

TCP requires kernel‑level changes to modify congestion control; QUIC can switch algorithms in user space.

2. Forward Error Correction (FEC)

QUIC adds an FEC packet generated by XOR‑ing ten data packets; if one data packet is lost, the missing packet can be reconstructed, reducing retransmissions.

3. Monotonically Increasing Packet Number

QUIC’s packet numbers increase strictly; a lost packet is retransmitted with a higher number, eliminating ambiguity between original and retransmitted packets.

4. ACK Delay

QUIC accounts for the receiver’s processing delay before sending ACKs, yielding more accurate RTT measurements than TCP.

5. More ACK Blocks

QUIC can carry up to 256 ACK blocks in a single ACK, compared with TCP’s maximum of 3, improving efficiency on high‑loss paths.

Browser Control (Flow Control)

TCP flow control uses a sliding window to prevent the sender from overwhelming the receiver. QUIC provides two levels of flow control: connection‑level and stream‑level. Each stream’s receive window shrinks as data arrives and grows when the receiver processes data and sends WINDOW_UPDATE frames.

Connection‑level flow control aggregates the windows of all active streams, ensuring the overall connection does not exceed the receiver’s capacity.

Receive window = max receive window – already received data

Overall, QUIC’s design—packet‑based transport, connection IDs, FEC, flexible congestion control, and richer ACK mechanisms—addresses the limitations of TCP/HTTP/2 and enables faster, more reliable web communication.