Fundamentals 12 min read

Understanding HTTP/2: Its Achievements, Limitations, and the Need for HTTP/3

This article reviews the development and core features of HTTP/2, explains why its TCP‑based design still suffers from head‑of‑line blocking and handshake latency, and argues that these inherent limitations make the transition to HTTP/3 over QUIC inevitable for modern web developers.

Full-Stack Internet Architecture
Full-Stack Internet Architecture
Full-Stack Internet Architecture
Understanding HTTP/2: Its Achievements, Limitations, and the Need for HTTP/3

In recent months many major companies have begun deploying HTTP/3, making it clear that the protocol is on the verge of widespread adoption. As front‑line developers, it is time to understand what HTTP/3 is and why it is needed.

This piece first revisits HTTP/2, which was standardized in May 2015 (RFC 7540) and saw broad browser support by the end of that year. Although adoption grew around 2018, the IETF officially approved HTTP‑over‑QUIC as HTTP/3 in November 2018.

HTTP/2 Highlights

HTTP/2 introduced multiplexing, binary framing, header compression, and server push to improve efficiency over HTTP/1.1. However, it still relies on TCP, which brings its own head‑of‑line blocking problems.

While HTTP/2 eliminates HTTP‑level head‑of‑line blocking by allowing independent frames to be sent out of order, TCP still delivers packets in sequence. If a single packet is delayed, the entire TCP stream stalls, causing all multiplexed requests to suffer.

TCP‑Related Issues

TCP’s three‑way handshake consumes 1.5 RTT, and HTTPS adds another RTT for TLS, resulting in 3–4 RTT before data can be exchanged. On high‑latency links this can add up to a second of perceived delay.

Upgrading TCP itself is difficult because countless intermediate devices (routers, switches, firewalls) and operating system kernels would need to support the changes, leading to the concept of “protocol ossification.”

Why Not Upgrade TCP?

Replacing TCP would require coordinated updates across all network infrastructure, which is costly and slow. Consequently, many TCP enhancements remain undeployed.

Abandoning TCP?

Given TCP’s limitations, the only practical path forward is to adopt a different transport. UDP, being connection‑less and not subject to the same ossification, serves as the foundation for QUIC, the transport layer used by HTTP/3.

Conclusion

HTTP/2 solved HTTP‑level head‑of‑line blocking but cannot overcome TCP’s inherent latency and ordering constraints. Because upgrading TCP is impractical, HTTP/3 leverages QUIC over UDP to provide faster, more reliable connections, setting the stage for the next generation of web performance.

TCPHTTPprotocolQUICHTTP/3HTTP/2
Full-Stack Internet Architecture
Written by

Full-Stack Internet Architecture

Introducing full-stack Internet architecture technologies centered on Java

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.