Why HTTP/3 Replaces TCP: Understanding QUIC and Protocol Evolution

From HTTP/1.0 through HTTP/2, TCP has been the reliable transport layer for HTTP because it provides ordered, loss‑free delivery.

With HTTP/3, this situation changes: the new protocol discards TCP entirely.

TCP suffers from head‑of‑line (HoL) blocking because data packets must arrive in order; if a packet is delayed, the receiver stalls the connection waiting for it.

HTTP/1.1’s pipelined persistent connections allow up to six TCP connections per domain, while HTTP/2 multiplexes many streams over a single TCP connection, making HoL blocking more severe.

TCP’s three‑way handshake adds roughly 1.5 RTT of latency, which becomes noticeable when RTT is 300–400 ms.

Upgrading TCP is difficult because countless intermediate devices (routers, switches, firewalls) would need to support new features, and operating‑system kernels are slow to adopt changes.

Consequently, many new TCP extensions standardized by IETF see little real‑world deployment.

HTTP/3 solves these problems by using QUIC, a UDP‑based transport that adds reliability, packet retransmission, congestion control, and ordered delivery per stream while allowing streams to be processed out of order.

QUIC also supports 0‑RTT and 1‑RTT connection establishment and incorporates TLS 1.3 for strong security with reduced handshake latency.

Despite its advantages, QUIC faces obstacles: many networks throttle or block non‑standard UDP traffic (especially on ports other than 53), UDP is vulnerable to amplification attacks, and some middleboxes provide limited support, leading to potential packet loss.

Nevertheless, the article concludes that HTTP/3 and QUIC will eventually replace TCP as the dominant transport for web traffic.