How QUIC Eliminates TCP Head‑of‑Line Blocking and Boosts Network Performance

1.1 Why TCP suffers from head‑of‑line blocking

TCP uses positive acknowledgments and timeout retransmission; if a packet is lost, the sender must wait for its acknowledgment before sending subsequent packets, causing the sliding window to stall and blocking all following data.

TCP mitigates this with a sliding window, but when a packet times out, the window cannot advance, leading to head‑of‑line blocking similar to HTTP/1.1 pipelining.

1.2 How QUIC solves head‑of‑line blocking

QUIC replaces TCP's sequence numbers with monotonically increasing packet numbers. Each retransmitted packet receives a new, larger packet number, allowing the receiver to acknowledge out‑of‑order packets and keep the window moving.

QUIC also adds Stream ID and Stream Offset fields so that retransmitted packets can be matched to the original data, enabling unordered delivery within a stream.

1.3 QUIC multiplexing without head‑of‑line blocking

Because packet numbers are independent of order, multiple streams can be multiplexed over the same connection and retransmissions of one stream do not block others.

QUIC also encrypts transport headers with TLS, removing TLS‑level head‑of‑line blocking.

2.1 What a TCP connection really is

A TCP connection is identified by the tuple

<source IP, source port, destination IP, destination port>

. This ties the connection to specific network endpoints.

2.2 How QUIC reduces connection‑setup overhead

QUIC combines transport and TLS handshakes, achieving a 1‑RTT initial connection and 0‑RTT session resumption, similar to TCP Fast Open and TLS 1.3 short handshakes but without OS‑level deployment constraints.

The table below (originally in the source) shows RTT savings for various protocols; QUIC reduces the total from 5‑RTT (HTTP/2 + TLS 1.2) to 3‑RTT for the first request and 1‑RTT for session resumption.

2.3 Seamless connection migration with QUIC

QUIC uses a 64‑bit Connection ID that is independent of IP and port, allowing the connection to survive network changes (e.g., switching Wi‑Fi to LTE) without breaking.

3.1 Bottlenecks in TCP congestion control

TCP’s congestion control (slow start, congestion avoidance, fast retransmit, fast recovery) reacts slowly to network changes, and frequent timeout retransmissions drastically reduce throughput.

3.2 How QUIC lowers retransmission probability

QUIC’s increasing packet numbers eliminate ambiguity between original and retransmitted packets, improving RTT measurement accuracy. It also adds forward error correction (FEC) to recover small losses without retransmission.

3.3 QUIC’s approach to congestion control

QUIC adopts TCP’s proven algorithms (Cubic, Reno, BBR, etc.) but can update them quickly as a user‑space protocol, and it supports pluggable congestion control modules that can be tuned per connection using AI or big‑data analysis.