Why QUIC Beats TCP: Understanding UDP‑Based Transport and Its Benefits

Background

Quick, UDP, Internet, Connections

Evolution of HTTP

HTTP/1: a new TCP connection is created for each request.

HTTP/1.1: supports persistent connections; one TCP connection per IP.

HTTP/2: TCP multiplexing allows multiple concurrent HTTP requests over a single TCP connection. Browsers typically limit concurrent streams to 6‑8.

When packet loss occurs, TCP's in‑order acknowledgment stalls the sliding window, causing all subsequent packets to be blocked; in such cases HTTP/2 can perform worse than HTTP/1.

Establishing a TCP connection requires a three‑way handshake (1.5 RTT). Adding TLS for HTTPS adds another 1‑2 RTT, so HTTP/2 may need 2.5‑4 RTT before any data is transmitted.

TCP Shortcomings

TCP + TLS handshake overhead (at least 2.5 RTT).

Large TCP header overhead (20‑60 bytes) wastes bandwidth.

Head‑of‑line blocking caused by in‑order delivery.

TCP connections cannot migrate; any change in the 5‑tuple (source IP, source port, destination IP, destination port, protocol) forces a new handshake.

Because TCP has been entrenched for over 40 years, protocol‑level changes are difficult. Google therefore introduced QUIC, a UDP‑based transport.

Key Features of QUIC

Multiplexing

Unlike HTTP/2, which multiplexes streams over a single TCP connection, QUIC creates a logical connection over UDP. One QUIC connection can contain multiple independent streams; loss of a single stream does not block others.

Protocol Header

QUIC sits on top of UDP, so the outermost header is the UDP header (bits). Inside are the QUIC connection header and per‑stream frame headers.

Flags : indicate lengths of Connection ID, Packet Number, etc.

Connection ID : a 64‑bit random identifier chosen by the client, allowing connection migration without relying on the IP/port 4‑tuple.

QUIC Version : optional 32‑bit version field.

Diversification nonce : used by the server to generate session keys; present only in the server‑to‑client handshake.

Packet Number : up to 6 bytes, monotonically increasing.

Stream ID : identifies the resource request.

Offset : byte offset of the packet within its stream.

Data‑flow Control

QUIC provides two levels of flow control:

Stream flow control : limits the maximum absolute byte offset that can be sent on any single stream.

Connection flow control : limits the total bytes of all STREAM frames, preventing the sender from exceeding the receiver's connection buffer.

Stream Control

Each stream is identified by Stream ID + Offset . The sender must keep the offset below the maximum absolute byte offset, which is calculated from the bytes already consumed by the receiver.

QUIC uses ACK frames that can contain multiple acknowledgments without a payload.

If a packet times out, the sender assigns a new packet number and retransmits.

Other in‑flight packets can still be acknowledged based on their offsets, avoiding the need for TCP‑style SACK.

Connection Control

Beyond per‑stream limits, QUIC enforces an overall connection byte limit. The sum of the maximum offsets of all streams must stay within this limit. The receiver can send MAX_DATA frames to raise the connection limit and MAX_STREAM_DATA frames to adjust individual streams.

Fast Handshake and Encrypted Transport

QUIC’s handshake uses Diffie‑Hellman key exchange to derive an initial secret, then negotiates a fresh session key (K'). The handshake steps are:

Client sends an Inchoate Client Hello (CHLO).

Server replies with a Rejection (REJ) containing a server config (long‑term public key A, primes g and p).

Client generates a short‑term key b, derives the initial secret K, and sends a Complete Client Hello (CHLO) encrypted with K.

Server derives the same K, decrypts the client data, generates a fresh session key K', encrypts it with K, and sends it in a Server Hello (SHLO).

Client decrypts K' and all subsequent traffic uses K'.

These steps require only 1 RTT for the first connection.

Connection Migration

TCP identifies a connection by a 5‑tuple; any change forces a new connection. QUIC identifies a connection by a 64‑bit random Connection ID, so IP or port changes do not break the connection. Migration proceeds as follows:

Client continues sending non‑probing packets from the old address.

Client switches to a new IP and sends non‑probing packets, implicitly migrating the connection.

Server validates the new path by sending a PATH_CHALLENGE frame containing a random value.

Client replies with a PATH_RESPONSE frame echoing the value.

Server verifies the response; the client then performs the reverse validation.

Loss Detection

TCP relies solely on checksums and retransmits lost packets. QUIC adds Forward Error Correction (FEC) to recover small amounts of loss without retransmission, reducing unnecessary congestion control triggers. QUIC also uses a monotonically increasing packet number, avoiding RTT ambiguity caused by duplicate packet numbers in TCP.

TCP RTT Calculation

TCP’s RTT measurement can be distorted by retransmissions, especially when many packets are lost.

QUIC RTT Calculation

QUIC computes a smoothed RTT, applies a weighted moving average to the difference between smoothed and actual RTT, and then derives RTO using empirically chosen constants (α=0.125, β=0.25, etc.). Because packet numbers never repeat, retransmissions do not confuse RTT estimation.

Custom Congestion Control

QUIC’s congestion control is implemented in user space, allowing applications to choose algorithms such as BBR or Cubic and tune parameters for specific workloads.

Use on HTTP/3

Seamless Wi‑Fi to cellular handover.

Stronger security (forward secrecy + full payload encryption).

Higher throughput on high‑latency or lossy networks.

QUIC Is Not Far Away

QUIC was experimentally deployed in 2012, proposed to IETF in 2015, and standardized in RFC 9000 in May 2021. It can be enabled in Chrome via chrome://flags/#enable-quic when the server supports it.

Performance Reference (Tencent PCG R&D)

Measurements on a 60 KB page show that in good network conditions QUIC’s advantage over HTTP/2 is modest (≈15 % faster first‑RTT), but with cached connections the speed gain is significant. In weak networks with high packet loss, QUIC’s accurate RTO estimation, independent streams, lightweight header, and fast handshake yield dramatic performance improvements.

Conclusion

While TCP’s ubiquitous kernel implementation makes it hard to replace, its 20‑60 byte header and head‑of‑line blocking reduce efficiency. UDP’s smaller header and QUIC’s design allow customized transport that can substantially improve throughput for modern, resource‑heavy front‑ends.

Adopting QUIC is analogous to moving from hardware‑based context switches to software‑controlled task switching in operating systems.

References

HTTP/2 and HTTP/3 new features – https://blog.csdn.net/howgod/article/details/102597450

QUIC protocol overview – https://www.163.com/dy/article/G5D1ETVH0518R7MO.html

Shared‑key algorithm in QUIC handshake – https://blog.csdn.net/chuanglan/article/details/85106706

QUIC flow control – https://zhuanlan.zhihu.com/p/337175711

QUIC encryption and handshake – https://zhuanlan.zhihu.com/p/301505712

TCP out‑of‑order cache and retransmission improvements – https://blog.csdn.net/cws1214/article/details/52430554

Popular science: QUIC protocol analysis – https://zhuanlan.zhihu.com/p/32553477

RFC 9000 – https://datatracker.ietf.org/doc/html/rfc9000