HTTP/2 & HTTP/3 Multiplexing Analysis

Hello! Welcome to the fourth lesson in our "Advanced Network Analysis" module.

In our last session, we learned how to create custom network throttling profiles to simulate specific, real-world connection conditions. This gives us the power to test our applications under the same constraints our users might face.

Today, we'll see how the web's underlying protocols have evolved to perform better, especially on these challenging networks. We will connect the theory of modern HTTP protocols to practical analysis in DevTools. Our focus will be to analyze the benefits of HTTP/2 and HTTP/3 multiplexing by inspecting requests in the Protocol column. This will help you understand not just what is loading, but how it's being delivered.

The Problem: HTTP/1.1 and the Connection Limit

To appreciate the benefits of modern protocols, we first need to understand the limitations of their predecessor, HTTP/1.1. For decades, it was the backbone of the web, but it had a fundamental bottleneck.

The following video gives an excellent overview of this limitation, known as Head-of-Line (HOL) blocking.

As the video explained, HTTP/1.1 can only handle one request and response at a time on a single TCP connection. If you request a large image, any subsequent requests for CSS or JavaScript on that same connection are blocked until the image finishes downloading.

Browsers worked around this by opening multiple TCP connections to the same domain (typically six). While this allowed for some parallelism, it was an inefficient hack. Each new TCP connection requires its own handshake, adding latency and consuming resources on both the client and server.

The First Leap: HTTP/2 and Multiplexing

HTTP/2 was introduced to solve this problem directly. Its key innovation is multiplexing.

With multiplexing, a browser can send multiple requests simultaneously over a single TCP connection, and the server can send back the responses in any order. The browser then uses unique "stream IDs" to correctly match responses to their original requests. This eliminates the HOL blocking seen in HTTP/1.1 and removes the need for the multiple-connection hack.

Let's see how this works.

This single-connection approach is far more efficient, reducing the overhead of connection setup and allowing for better resource prioritization.

Observing HTTP/1.1 vs. HTTP/2 in DevTools

You can see these differences clearly in the Network panel.

First, you need to enable two columns that are often hidden by default: Protocol and Connection ID.

1. Open the Network panel in DevTools.
2. Right-click on any of the column headers (like Name, Status, or Type).
3. From the context menu, make sure both Protocol and Connection ID are checked.

Right-click the header of the request table in the Network panel to enable additional columns like Protocol and Connection ID.

Now, let's compare.

• HTTP/1.1 Site: Visit a site that still uses the older protocol, such as http://info.cern.ch. You'll notice the Protocol column shows http/1.1, and you'll see several different numbers in the Connection ID column as the browser opens multiple connections to download assets in parallel.
• HTTP/2 Site: Visit almost any modern website, like https://www.google.com or https://github.com. You will see h2 in the Protocol column, and you'll notice that most requests to the main domain share the same Connection ID, demonstrating multiplexing over a single connection.

The performance implications, especially on slower networks, are significant. This final clip from the video demonstrates this with a side-by-side comparison.

The Next Evolution: HTTP/3 and QUIC

HTTP/2 was a huge step forward, but it wasn't perfect. Because it's still built on top of TCP, it suffers from a different kind of Head-of-Line blocking—this time at the transport layer. In TCP, packets must be processed in order. If a single packet containing data for one of your multiplexed streams is lost on the network, all streams on that connection must wait until that packet is retransmitted and received.

Enter HTTP/3. It doesn't use TCP at all. Instead, it's built on a new transport protocol called QUIC, which runs over UDP. Your background in radiophysics might give you an appreciation for this shift in the underlying transport mechanism. By using UDP, QUIC avoids TCP's strict ordering requirements.

The following article explains the limitations of HTTP/2 and how QUIC/HTTP/3 solves them.

To summarize the key advantage: with QUIC, if a packet is lost, it only impacts the specific stream it belongs to. All other streams can continue processing, completely eliminating transport-layer HOL blocking. This is especially beneficial on unreliable networks where packet loss is common.

Observing HTTP/3 in DevTools

Spotting HTTP/3 is just as easy as spotting HTTP/2, but the process of how a browser decides to use it is more nuanced.

Let's try it:

1. Make sure the Protocol column is visible in the Network panel.
2. Navigate to a site that supports HTTP/3, such as https://www.google.com or https://cloudflare.com.
3. On your very first visit, you might see the initial request is h2. The server uses this connection to send an Alt-Svc (Alternative Service) header in its response, telling the browser "Hey, you can also reach me using HTTP/3."
4. Subsequent requests on that page, or a full page reload (you may need to check "Disable cache"), should show requests being made with the h3 protocol.
5. Pro Tip: As the article mentions, if you hover your mouse over the value in the Protocol column (e.g., h3), a tooltip will appear explaining why that protocol was chosen, which is invaluable for debugging.

You are now able to see the full evolution of the web's primary protocol right within your browser's developer tools.

Conclusion

Today, we've journeyed through the evolution of the HTTP protocol, from the limitations of HTTP/1.1 to the multiplexed efficiency of HTTP/2 and the cutting-edge performance of HTTP/3.

Key Takeaways:

• HTTP/1.1 suffers from Head-of-Line blocking, forcing browsers to use multiple TCP connections to achieve parallelism, which is inefficient.
• HTTP/2 introduces multiplexing over a single TCP connection, solving application-level HOL blocking. You can observe this in DevTools with the h2 tag in the Protocol column and a shared Connection ID for requests to the same origin.
• HTTP/3 uses the QUIC protocol over UDP to eliminate transport-level HOL blocking, offering superior performance on unreliable networks. You can spot this with the h3 tag in the Protocol column.
• Enabling the Protocol and Connection ID columns in the Network panel is essential for analyzing which protocol is in use and understanding its performance characteristics.

In our next and final lesson of this module, we will learn how to preserve and share the valuable network data we've learned to analyze. We will cover how to export, import, and analyze HAR files to share network logs for collaborative debugging.