Robin Marx

The new QUIC and HTTP/3 protocols are finally here! With their standardization at the IETF almost complete and several mature implementations being deployed, we can start looking into which performance improvements they bring in practice. There's just one problem though: they're quite complex and difficult to test. Using high level tooling like lighthouse might show that they're faster or slower, but rarely why.

But problems are there to be solved, and that's what I've been doing for the past 2 years with the qlog and qvis projects. The qlog structured endpoint logging format (https://github.com/quiclog/internet-drafts) is supported by over 70% of all QUIC implementations and allows you to extract low-level protocol information in JSON directly from the client and server. These traces can then be loaded for analysis in different interactive visualizations in our open-source qvis toolsuite (https://qvis.edm.uhasselt.be). This brings an unparalleled opportunity to analyze performance problems and opportunities to the new protocols, as these tools start where the browser devtools end.

In this talk, we will explore QUIC and HTTP/3's main performance oriented features, such as 0-RTT connection establishment, advanced congestion and flow control, stream multiplexing and prioritization, and Head-of-Line blocking removal in-depth. We discuss how they are supposed to work, why it's not always that easy in practice, and of course: how to diagnose issues with these features using qlog and qvis. We will use concrete examples of bugs found in major implementations to teach how to interpret the behavior of these new protocols, based on some of our research (https://qlog.edm.uhasselt.be/epiq).

We explain how to properly approach testing the new protocols in the future, as great care should be taken in interpreting any results and their root causes. Along the way we debunk some common misconceptions on the protocols and their potential improvements (no, the fact that QUIC runs on top of UDP does not mean it no longer needs congestion control or magically becomes faster, no matter what that Hackernews commenter claims).

Come learn about how browsers try to guess in what order web page resources should be loaded and how servers use that information to often (accidentally) make your web page slower instead. We look at what resource prioritization is, how it's often implemented terribly in modern HTTP/2 stacks and how we're trying to fix it in QUIC and HTTP/3. We use clear visualizations and images to help explain the nuances in this complex topic and also muse a bit on whether prioritization actually has that large an impact on web performance.

HTTP/2 started the move from multiple parallel TCP connections to a single underlying pipe. QUIC and HTTP/3 continue that trend. While this reduces the connection overhead and lets congestion controllers do their work, it also means we no longer send data in a truly parallel fashion. As such, we need to be careful about how exactly we send our resource data, as some files are more important than others to achieve good web performance.

To help regulate this, HTTP/2 introduced a complex prioritization mechanism. Browsers use complex heuristics to try and estimate the importance of a resource and, with various success, communicate their preferences to the servers. It has however become clear that this scheme does not work well in practice. Between server implementation bugs, questionable browser choices and bufferbloat in caches and network setups, HTTP/2 prioritization is sometimes more a liability than a useful feature.

For this reason, this feature is being completely reworked in HTTP/3 over QUIC. However, there a whole new can of worms is opened. One of QUIC's main features for improving performance over TCP is that it removes "head of line blocking": if one resource suffers packet loss, other can still make progress. That is... if there are other resources in progress! What performs well for lossy links turns out to be exactly what to prevent for high speed connections.

Along the way, we also discuss existing options for web developers to impact the browser's heuristics and server behaviour (such as resource hints (e.g., preload) and the upcoming priority hints).

Finally, we question about how we got in this terrible state of things to begin with: if people made so many mistakes implementing HTTP/2 prioritization, why didn't anyone really notice until 3 years later? Could it be its impact on web performance is actually limited? Or have we just not seen its full potential yet?

We make this complex topic approachable with plenty of visualizations and animations. The content is mainly based on our own research (and papers) and that of others in the web community, such as Patrick Meenan and Andy Davies.