HTTP/1.1 vs. HTTP/2 vs. HTTP/3: Connection and Performance

The Evolution of HTTP

Let's begin with a high-level tour of how HTTP has evolved to meet the demands of the modern web. The following video provides a concise and clear overview of the journey from HTTP/1.0 to HTTP/3, introducing the core problems and solutions at each stage.

This video gives us a fantastic road map. Now, let's unpack these concepts in greater technical detail, starting with the protocol that has powered the web for over two decades.

HTTP/1.1: Persistent Connections and a Persistent Problem

As the video mentioned, HTTP/1.0 was simple but inefficient, requiring a new TCP (and TLS) handshake for every single resource. HTTP/1.1 introduced two key improvements:

1. Persistent Connections (Keep-Alive): It allowed a single TCP connection to be reused for multiple requests and responses, dramatically reducing the overhead from repeated handshakes.
2. Pipelining: It allowed a client to send multiple requests over that single connection without waiting for the responses.

However, pipelining came with a critical flaw known as Head-of-Line (HOL) Blocking.

Head-of-Line Blocking in HTTP/1.1 means that the server must send its responses back in the same order that the requests were received. If the first request in the pipeline is for a resource that is slow to generate (e.g., a complex database query), it holds up the delivery of all subsequent resources, even if they are small and ready to be sent (like a CSS file or an icon). This created a significant performance bottleneck, so much so that most browsers ended up disabling pipelining.

Developers came up with workarounds like "domain sharding"—splitting resources across multiple subdomains (static1.example.com, static2.example.com) to trick the browser into opening more parallel TCP connections (typically browsers limit connections to 6 per domain). This, however, added complexity and more TCP/TLS handshake overhead.

HTTP/2: Multiplexing over a Single Connection

HTTP/2, standardized in 2015, was designed specifically to solve the HOL blocking problem of HTTP/1.1. Its single most important feature is multiplexing.

To understand how it works, we need to look at its new binary framing layer.

As the article explained, HTTP/2 achieves multiplexing by breaking down each request/response message into independent, binary-encoded frames.

• A Stream is a logical, bidirectional flow of frames representing a single request/response pair.
• Multiple streams can run in parallel over a single TCP connection.
• The client and server can interleave frames from different streams and reassemble them at the other end using the stream identifier present in each frame's header.

This completely eliminates the application-layer HOL blocking. A slow response in one stream no longer blocks others. A large image download won't prevent a small, critical CSS file from arriving and being processed first.

Other Key HTTP/2 Features:

• Stream Prioritization: The client can assign weights and dependencies to streams, telling the server which resources are more important (e.g., load the main content before the sidebar ads).
• Header Compression (HPACK): HTTP/1.1 headers are plaintext and can be repetitive and large, especially with many cookies. HTTP/2 uses HPACK, a sophisticated compression scheme that dramatically reduces this overhead.
• Server Push: The server can proactively send resources it knows the client will need, saving a request round trip. For example, when you request index.html, the server can "push" style.css and main.js at the same time.

HTTP/3: Fixing the Transport Layer

HTTP/2 was a monumental leap forward. However, it still had a hidden bottleneck. While it solved HOL blocking at the application layer, the problem still existed one layer down: at the TCP transport layer.

TCP guarantees reliable, in-order delivery of packets. If a single packet is lost in transit, the entire TCP connection freezes while it waits for that packet to be retransmitted. Since all of HTTP/2's streams are multiplexed over that one TCP connection, a single lost packet blocks all streams. This is TCP Head-of-Line Blocking. This is particularly painful on lossy networks like mobile connections.

The solution was radical: don't just update HTTP, replace TCP.

This is where HTTP/3 comes in. HTTP/3 runs on a new transport protocol called QUIC.

Let's summarize the genius of QUIC:

1. Built on UDP: Instead of TCP, QUIC is built on top of UDP. UDP is a simple, "fire-and-forget" protocol that doesn't guarantee delivery or order. This gives QUIC a blank slate to implement transport logic in a new, better way.
2. Truly Independent Streams: QUIC re-implements reliability and flow control, but it does so per stream. A lost packet for one stream only affects that stream; the others can continue processing. This finally solves TCP HOL blocking.
3. Faster Connection Establishment: As we saw in the previous lesson, establishing a secure connection requires a TCP handshake followed by a TLS handshake. QUIC merges these into a single, combined handshake. This means a new HTTPS connection over HTTP/3 often takes only 1 round trip (1-RTT), and resumed connections can even take 0 round trips (0-RTT).

4. Connection Migration: A TCP connection is defined by a 4-tuple: (source IP, source port, destination IP, destination port). If your IP changes (e.g., you switch from Wi-Fi to cellular data), the TCP connection breaks and must be re-established. QUIC uses a Connection ID to identify the connection. This ID persists even if your underlying IP address changes, allowing for a seamless transition without interruption.

Summary Comparison

This layered diagram provides an excellent visual summary of the features and underlying protocols for each HTTP version.

Here is a summary table to consolidate the key differences:

Conclusion

We've traced the evolution of HTTP from a simple text protocol to a highly optimized transport system. The journey has been a relentless pursuit of lower latency and better performance, especially in the face of increasingly complex web applications and challenging network conditions.

Key Takeaways:

• HTTP/1.1 introduced persistent connections but suffered from Head-of-Line (HOL) blocking, forcing workarounds like domain sharding.
• HTTP/2 solved application-layer HOL blocking with multiplexing over a single TCP connection but was still vulnerable to HOL blocking at the underlying TCP layer.
• HTTP/3 represents a paradigm shift by moving to QUIC over UDP. This finally solves TCP HOL blocking by making streams truly independent and dramatically speeds up connection establishment.

The biggest performance gains from HTTP/3 are seen on networks with high latency or packet loss, making it a game-changer for the mobile web.

Preview of the Next Lesson:

While the evolution of HTTP has largely focused on performance, a parallel track of evolution has focused on web security. One of the most fundamental security policies that backend developers must understand is the Same-Origin Policy and its controlled exception, Cross-Origin Resource Sharing (CORS). In our next lesson, we will explore what CORS is, why browsers enforce it, and how to configure it correctly on your backend to allow legitimate cross-domain requests.