QUIC — a latency-reducing, reliable, and secure transport protocol — and HTTP/3 — a mapping of HTTP semantics on top of QUIC — are co-evolving protocols that are being developed and deployed in tandem. This regularly updated blog post will elaborate on the current state of the protocols, their deployment across the web, and our expectations for the technologies in the near future.

TL;DR, Summer 2020: Development of QUIC and HTTP/3 within the IETF has reached a significant milestone as it nears completion. Most implementations are able to interoperate with each other and servers are ready to serve QUIC and HTTP/3. And, while clients are at various stages, client support is starting to roll out as well.

QUIC and HTTP/3 at the IETF

As QUIC and HTTP/3 evolve through a collaborative and iterative standardization process at the IETF, we are at a particularly significant moment. Just a few weeks ago — after four years, 22 face-to-face meetings, 1,800 issues, and many thousands of emails — the working group completed its last call for issues, meaning the chairs of the working group have solicited and received the last set of design issues from the working group. Almost all issues filed during this period already have resolutions that will soon be incorporated into the specifications.

In short, the QUIC working group is finally wrapping up the development of the QUIC and HTTP/3 protocols.

This is a big deal. It’s been five years since HTTP/2 was published, and four decades since the completion of TCP, the underlying transport protocol that QUIC seeks to replace.

There still are a few important steps left before the IETF publishes the specifications as IETF Requests for Comments (RFCs), as shown in the following figure. Importantly, however, the bulk of the time in this process is in the evolution stage, culminating in a working-group last call to establish rough consensus within the working group on the specifications. This is the stage we are currently concluding. At this point, any new issues filed against the protocols’ design — even minor ones — must go through additional layers of process, and demonstrate urgency and significance before they can be taken up by the working group for changing the specifications.

Fastly loves QUIC and HTTP/3. Several of us within the company have been engaged in the process of developing the protocol specifications from the beginning. We have been building and tuning Fastly’s own implementations of these protocols and made them available to our customers. We are deeply invested in making these technologies a success because we believe that they align with what we want to build — a faster, more resilient, and more trustworthy internet.

While we are driving this work and excited about the progress of this rapidly changing technology, we understand that it is difficult to keep track of the state of things from the outside. This post will clarify the state of QUIC and HTTP/3 development at the IETF, the state of their deployment in the world, and lay out our best guess at what to expect in the near future.

QUIC and HTTP/3 interoperability

Changing an internet protocol, especially a transport protocol designed to replace TCP for the web, requires all the communicating entities to be able to speak to each other without any issues. The internet is fundamentally a multi-vendor ecosystem, and as a result, communication almost always involves multiple implementations of the same protocol. To be successfully deployed, various vendors need to build QUIC implementations, and these implementations need to interoperate with each other.

Vendors, including Apple, Google, Microsoft, Mozilla, and our team at Fastly, have been working hard on their own implementations, many of which are now quite mature. These implementers gather periodically to test their implementations against each other, and most of them also participate in a continuously running automated interoperability testing tool called the QUIC Interop Runner. The Interop Runner shows the current state of HTTP/3 and QUIC interoperability between participating implementations, on a suite of correctness and performance tests.

The community of implementers working on these protocols has learned that having open and continuous communication with each other is essential for implementing and deploying these protocols. These implementers have been in close touch with each other over the past years as the protocol has evolved and, excitingly, most implementations are close to being fully interoperable with each other.

QUIC and HTTP/3 in the wild

We at Fastly have deployed QUIC and HTTP/3 to our own servers: our quicly library provides the QUIC implementation, as a part of our HTTP/3 implementation in the H2O webserver. Other content providers, who are also represented in the QUIC Interop Runner, have deployed QUIC and HTTP/3 to their servers as well. This means customers and domain owners can advertise that their domain supports QUIC and HTTP/3 today. However, for any customer traffic to flow over these protocols, we need the clients to deploy support for them as well.

When the specifications are eventually published as RFCs, all implementations will support HTTP/3, which will use QUIC version 1. While under development, however, implementations support one or more draft versions of HTTP/3 and QUIC. Each HTTP/3 draft version uses a specific draft version of QUIC. For example, HTTP/3 draft version h3-27 uses QUIC version 0xff00001B, and similarly, HTTP/3 draft version h3-29 uses QUIC version 0xff00001D. To simplify things, and since the draft versions and implementations of the protocols move in lock-step anyway, we simply refer to the HTTP/3 draft version.

So where does client support for QUIC stand right now? We summarize the state of the most widely used browsers and platforms below; platform support is summarized for those looking to use QUIC and HTTP/3 with their non-browser client applications.

Browsers

• Google Chrome includes support of HTTP/3 draft version h3-29 in all its channels. Google has turned on HTTP/3 for a small fraction of Chrome users across all channels. Users can also manually enable draft version h3-29 on any Chrome channel. (This is different from Chrome’s support of GQUIC — the older, proprietary protocol built by Google — which is still used by a large fraction of Chrome users to primarily Google servers. Chrome is expected to replace GQUIC with HTTP/3 and QUIC. As Chrome’s HTTP/3 and QUIC deployment increases, its GQUIC deployment should decrease.)

• Microsoft Edge uses Chrome's networking stack, which includes Chrome’s QUIC and HTTP/3 implementations, and therefore closely follows Chrome in its support of these protocols. Edge has these protocols enabled by default for a small fraction of its Dev and Canary populations, which speak draft version h3-29. Users can manually turn on draft version h3-29 on any Edge channel.

• Mozilla Firefox includes support of HTTP/3 draft version h3-29 in its nightly build, which can be manually enabled.

• Apple Safari includes support of HTTP/3 draft version h3-29 as an experimental feature that can be manually enabled.

Platforms

• Apple iOS and macOS include support of HTTP/3 draft version h3-29 as an experimental feature that can be manually enabled for applications in iOS 14 and macOS Big Sur.

• Microsoft Windows has its own implementation of HTTP/3 and QUIC, which is used by the IIS web server and is being piloted for internal online services like M365. This implementation supports draft versions h3-27, h3-28, and h3-29.

• Google Android currently has no public plan for the availability and support of HTTP/3 and QUIC on the platform. Chrome runs on Android however, and Android applications can (and several do) build in Chrome’s networking stack (cronet), which includes Chrome’s QUIC and HTTP/3 implementations. We will add an update here as soon as a plan is made public.

The finish line — and a modernized web — are in sight.

So where does this leave us in terms of final QUIC and HTTP/3 deployment in the world? I’ll venture to make a few predictions; note that standard disclaimers apply about any such forecasting. Looking at the landscape, I expect that we will see rapidly increased rollouts of QUIC and HTTP/3 by clients this year, as well as higher volume testing on pre-release channels first, followed eventually by clients turning QUIC and HTTP/3 on in their stable releases. Going a step further, I believe that QUIC and HTTP/3 will become the de-facto mainstream web protocol stack in 2021.

We at Fastly are very excited to see these protocols over the finish line. Our team will be participating in the final stages of the IETF process and watching various deployments closely. We will keep you updated through this page as these protocols come to fruition and enable a better web experience around the globe.