Why HTTP/3 Abandons TCP: An Overview of QUIC and Its Benefits

Since HTTP/1.0, TCP has been the underlying transport for HTTP because it provides reliable connections, a situation that continued through HTTP/1.1 and HTTP/2.

However, starting with HTTP/3, TCP is completely abandoned in favor of UDP‑based QUIC.

TCP head‑of‑line blocking occurs when packets arrive out of order; the receiver waits for the missing packet, blocking subsequent requests. HTTP/1.1 allows up to six parallel TCP connections per domain, while HTTP/2 multiplexes many streams over a single TCP connection, making head‑of‑line blocking even more impactful.

The three‑way TCP handshake adds roughly 1.5 RTT of latency, which becomes noticeable when RTTs reach 300‑400 ms on long‑distance links.

Upgrading TCP is difficult because many intermediate devices (routers, switches, firewalls, etc.) would need to support the new features, and operating‑system kernels are slow to adopt changes, leading to what is called protocol ossification .

Consequently, HTTP/3 adopts QUIC, a transport protocol built on UDP with the following characteristics:

Uses UDP ports for server identification.

Provides TCP‑like reliability (retransmission, congestion control, flow control).

Supports unordered, concurrent byte streams, allowing independent ordering of multiple streams.

Offers fast connection establishment with 0‑RTT and 1‑RTT handshakes.

Integrates TLS 1.3 for security, reducing handshake round‑trips.

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

Overall, QUIC presents a superior alternative to TCP for HTTP/3, but widespread adoption will depend on overcoming these network and infrastructure challenges.