How QUIC Achieves Reliable Transmission Over UDP and Solves TCP’s Head‑of‑Line Blocking

Why Build Reliable Transmission on UDP?

Interviewers sometimes ask how to achieve reliable transmission over UDP, prompting the question of why not simply use TCP, which already provides reliability. The answer lies in TCP’s inherent limitations, which QUIC addresses.

TCP Pain Points

TCP suffers from retransmission ambiguity, head‑of‑line (HoL) blocking in both send and receive windows, and rigid congestion control tied to the kernel.

QUIC Overview

QUIC is a UDP‑based reliable transport protocol used by HTTP/3. It introduces three layers of headers between the UDP packet and the HTTP message.

Packet Header

QUIC defines two packet header types:

Long Packet Header – used during connection establishment.

Short Packet Header – used for regular data transfer.

During the handshake, a connection ID is negotiated, allowing the short header to omit the source connection ID, which reduces overhead.

Each packet carries a monotonically increasing Packet Number . Unlike TCP, where retransmitted packets keep the same sequence number, QUIC assigns a new, larger packet number to each retransmission, eliminating ambiguity in RTT measurement and ACK handling.

Because packet numbers always increase, QUIC can calculate RTT accurately regardless of whether an ACK corresponds to an original or retransmitted packet.

The monotonic packet number also enables out‑of‑order acknowledgments: when a packet is lost, later packets can still be acknowledged, allowing the send window to slide forward.

Frame Header

Each QUIC packet can contain multiple frames. Frames have explicit types; for example, a Stream frame carries:

Stream ID – distinguishes concurrent HTTP streams.

Offset – similar to TCP’s sequence number, ensuring ordered reconstruction.

Length – size of the frame payload.

When a packet is retransmitted, the combination of Stream ID and Offset guarantees that the retransmitted data matches the original, preserving reliability.

How QUIC Solves TCP HoL Blocking

Send‑Window HoL Blocking

TCP requires in‑order ACKs before the send window can advance. If an early packet or its ACK is lost, the sender stalls, even if later packets are acknowledged.

Receive‑Window HoL Blocking

The receive window advances only after receiving in‑order data. Out‑of‑order data is buffered but cannot be delivered to the application until the missing bytes arrive.

HTTP/2 HoL Blocking

HTTP/2 multiplexes streams over a single TCP connection, but all streams share the same TCP window. A loss in any stream stalls the entire connection.

QUIC’s Independent Stream Windows

QUIC assigns a separate flow‑control window to each stream. Losses affect only the impacted stream, leaving others unaffected.

QUIC Flow Control

Stream‑Level Flow Control

Each stream has its own sliding window, preventing a single stream from consuming all connection buffer space.

Connection‑Level Flow Control

The connection window equals the sum of all stream windows, limiting total bytes in flight.

available_window = stream1_window + stream2_window + stream3_window

When a stream’s received offset exceeds half of its maximum window, the receiver sends a WINDOW_UPDATE frame, allowing the sender’s window to advance even in the presence of loss.

QUIC Congestion Control Improvements

QUIC adopts TCP’s Cubic algorithm by default but also supports CubicBytes, Reno, RenoBytes, BBR, PCC, etc. Because QUIC operates in user space, browsers can update its congestion‑control algorithm without kernel changes, enabling faster iteration and per‑application tuning.

Faster Connection Establishment

Traditional HTTP/1 and HTTP/2 require a 3‑RTT handshake (TCP + TLS). QUIC combines transport and TLS 1.3 handshakes into a single 1‑RTT exchange, and with 0‑RTT support it can send data on the first packet of a resumed session.

Connection Migration

TCP binds a connection to a 4‑tuple (src IP, src port, dst IP, dst port). When a device changes networks, the connection must be torn down and rebuilt.

QUIC uses a connection ID that is independent of the IP address. As long as the client and server retain the connection ID and cryptographic context, they can continue communication over a new network path without interruption.

References

https://www.taohui.tech/2021/02/04/%E7%BD%91%E7%BB%9C%E5%8D%8F%E8%AE%AE/%E6%B7%B1%E5%85%A5%E5%89%96%E6%9E%90HTTP3%E5%8D%8F%E8%AE%AE/

https://zhuanlan.zhihu.com/p/32553477