Hi, my name is Mike Bishop; I'm the editor of the newest version of HTTP, HTTP/3. I'm part of Foundry, a team at Akamai that focuses on new and emerging technologies that will impact the future of the web. I've been involved in web standards since the early days of HTTP/2, and most of my work has been on the development of these modern HTTP versions. When the Internet Engineering Task Force (IETF) was forming the QUIC working group in 2016, I was asked to serve as the editor for the HTTP/3 specification. As we bring this development effort to a close, let's take a look back at how we got here.
Some Background in HTTP
HTTP is one of the fundamental protocols of the internet. It's a very flexible protocol that enables one device to request another device to do something or return some information. It's the basis of web browsing and of the vast majority of cross-machine APIs on the internet.
As Javier Garza discussed earlier this year, the first versions of HTTP (HTTP/1.0, HTTP/1.1) were text-based protocols that are typically used directly over TCP. Those of us who tinkered with servers and websites in school grew up looking at HTTP in logs and packet captures. The semantics are flexible and extensible, which has enabled a rich and diverse ecosystem on the internet today. The basic concepts -- methods, status codes, headers, etc. -- remain unchanged decades later, even as we've used those concepts to build new functionality within HTTP. And for a long time, that was good enough.
Nearly a decade ago, there was interest in overcoming some of the limitations of this text-based mapping over TCP. As that work moved into the HTTP Working Group, I had just joined the Web Protocols team at Microsoft; one of my first assignments was to go through an early draft of what would become HTTP/2.
HTTP/2 was an optimized mapping of those same HTTP semantics onto the same transport layer (TCP), but with a complete reimagining of how those semantics could be expressed on the wire. HTTP/2 brought us several key innovations:
- A binary protocol, making strict conformance easier to check and subtle bugs easier to find quickly
- Header compression, saving data usage on metadata routinely sent over and over
- Multiplexing, enabling a single TCP connection to be used for all requests between a client and a server
HTTP/2 development focused on the application layer; we didn't change anything about TCP. In one respect, multiplexing was an improvement for HTTP/2 -- it enabled a single congestion controller to see all the traffic between the client and server, enabling a better use of the network and less self-imposed congestion.
However, that also meant all the requests were in a single loss-recovery context. When a packet is lost, TCP stops delivering all data until the missing bytes can be repaired; TCP doesn't know that one packet contains a bit of a photo outside the viewport while the other is critical to rendering the page. We knew at the time that we were making a trade-off by not changing the transport, and the result was that HTTP/2 improves performance on good networks and worsens it on bad networks.
Innovating with H3 and QUIC
HTTP/3 flips this approach on its head. Instead of trying to carry the semantics over TCP more efficiently, the IETF has defined an entirely new transport protocol (QUIC) that incorporates the best ideas of TCP and is multiplexed from the start. HTTP/3 is a mapping of HTTP semantics onto this new transport -- drawing a lot of inspiration from HTTP/2 but working in concert with QUIC to ensure the result is richer and more capable.
This process began at Google, where they designed a protocol that sat on top of UDP and exposed HTTP-like functionality to the browser. The internals looked very much like HTTP/2, but mixed in innovative ideas in transport and encryption. This protocol is generally referred to as "Google QUIC" or "gQUIC." In creating "IETF QUIC" or "iQUIC," we've been focused on teasing the functionality into separate components. Many of the ideas in gQUIC's cryptographic layer are incorporated into TLS 1.3 or extensions to TLS that are still in progress.
One of my main jobs as editor has been to help clarify that abstraction between the transport and the application layer. While I'm deeply invested in HTTP/3, it's important to me that QUIC be a general-purpose transport protocol that we can ultimately run other applications over as well. While the IETF doesn't design APIs per se, I've tried to identify specific actions and exchanges between HTTP/3 and QUIC. If the specification can describe their interactions in those terms, instead of assuming that HTTP/3 knows the internals of the transport, it means the transport has room to evolve in the future without breaking HTTP/3.
Another focus in developing HTTP/3 has been to leverage QUIC and simplify the application layer. Because QUIC offers many streams, not just one, HTTP/3 doesn't need to build multiplexing on top. And because the transport is aware of which packets contain data from which stream, packet loss only affects the streams whose data is missing. The result is noticeably better performance on networks that drop packets from time to time. You might not see much difference on your fiber line, but you'll definitely notice on spotty cellular links.
From an initial four documents, the working group has now brought a collection of six drafts to Last Call. Last Call is a final chance for the internet engineering community at large to review and comment on the documents before they're sent to the Internet Engineering Steering Group to evaluate and publish them as RFCs. There has been an immense amount of work to get us to this point from many contributors across the spectrum. Many of the key participants have changed roles or employers along the way, but continued to drive the protocol forward. A few have moved on to other projects. The finish line is near.
Security Drives Deployability
A savvy reader might realize that many of the transport features QUIC offers can be done in TCP as well. Innovations like SACK, RACK, ACK timestamps, TCP Fast Open, and Multipath TCP aren't new. TLS 1.3 supports early data whether you're using TCP or QUIC. The difficulty for those features has been deployment, not invention. Many of these features can't be used on today's networks, because of a fundamental problem in TCP.
TCP is simply too well known. And by that, I mean that devices on the internet believe they can interpret and modify the packets that flow by them, because they think they know how TCP is supposed to behave. The result is that much of the innovation that's happened in the transport space over the past decades is still very difficult to deploy on the real internet, as these devices fail to function properly when confronted with a TCP packet that doesn't behave the way it expects.
QUIC addresses this by encrypting from the very start. Almost all data is encrypted, with keys that provide more security guarantees as you get further into connection setup. This has an immediate measurable benefit -- we can deploy the latest and greatest ideas from TCP in QUIC without worrying that it will confuse devices that are inspecting traffic as it goes by. These features aren't new, but they're usable on all QUIC connections versus a fraction of TCP connections.
QUIC/H3 at Akamai
Akamai has had QUIC in deployment for years now, even before Google's custom protocol was presented at the IETF. We've seen impressive performance improvements from it here at Akamai. For example, during a recent major streaming event, we made the following measurements:
- 3.1% more users were able to sustain a 4 Mbps stream using QUIC than with TCP, with regional measurements as high as 9.3% more
- The median goodput increased by 8.7% while the 10th percentile increased by an eye-popping 25.7%
This demonstrates that QUIC is improving the user experience and the efficiency of the internet already, and improving it more for the most challenging connections.
But the real value remains to be seen. An encrypted transport means that new technology can be tested and deployed rapidly, maybe just by updating your browser. QUIC isn't just today's great idea -- it's what will make tomorrow's great idea possible.