The Next Generation of HTTP

HTTP, the protocol that runs the web, is getting an update! The Internet Engineering Task Force (IETF) just released something we’ve collectively been working on for several years: HTTP/3. HTTP/3 leverages a new transport protocol, QUIC, to deliver improved performance on the most challenging networks without compromising performance on great ones. And along the way, these updates change which document you should be referencing for any version of HTTP, not just HTTP/3.

Advantages of QUIC and HTTP/3

When the QUIC RFCs were published last year, I wrote about the advantages that this new transport could bring to the internet at large. HTTP/3 enables multiplexing and better congestion control, like HTTP/2, but without head-of-line blocking, which reduces performance in the presence of packet loss. HTTP/3 offers fast connection setup, like TCP Fast Open and TLS 1.3 Early Data, but without the tight constraints on the size of that first request.

Because HTTP/3 runs on top of QUIC, it also stands to benefit from future innovations enabled by an encrypted transport. We already see that happening with the QUIC Datagram extension (RFC 9221) being used by HTTP proxies to carry UDP traffic as well as TCP. (This extension to HTTP is at the heart of iCloud Private Relay, an Apple feature that Akamai helps to deliver.)

“But, wait,” you say, “I thought HTTP/3 has been out for a while?” HTTP/3 and the QUIC specifications have been technically complete and stable for more than a year now, and the time it has taken to publish the RFC means that draft versions have been widely adopted even in the absence of the final RFC. HTTP/3 is already supported by most major browsers and by 25% of websites. 

Because it can be implemented in user space, you don’t have to change your kernel to enable it – just install client or server software that supports it. (But stay up-to-date anyway because  many operating systems are improving QUIC performance with kernel fixes!)

Of course, if you need the best in security and performance, you’ll already be using a content delivery network to deliver your site. Akamai has collaborated on the deployment of QUIC over the course of several years, has followed its evolution through the IETF, and currently has HTTP/3 available to customers in beta. Otherwise, HTTP/3 support is available or in preview for most popular web servers.

What is an RFC?

Not all RFCs are standards; just ask RFC 1796. The RFC series contains many types of documents – information, poetry, humor – but the vast majority are technical publications of the IETF: the standards body that defines many of the fundamental protocols of the internet. Among those fundamental protocols are IP, TCP, TLS, and HTTP. 

RFC (Request for Comments) publication today requires thorough review; before being published as a standards-track RFC, the document has received and addressed literally thousands of comments. Before an RFC is identified as an internet standard, it must be “stable and well-understood” and “technically competent,” have “substantial operational experience,” and be “recognizably useful in some or all parts of the Internet.”

Unlike some other specifications, which are “living documents,” an RFC is never changed once published. If you need to make changes, you publish a new RFC that “obsoletes” or “updates” the previous one. So when RFCs 7230-7235 defined HTTP/1.1, they obsoleted RFC 2616; RFC 2616 obsoleted RFC 2068. Although each revision is compatible with what came before, the new documents aim to be easier to implement and more accurately reflect the protocol as it is actually used on the internet.

Previous HTTP documents

Which brings us to the stack of HTTP RFCs that were just published. We have yet another HTTP/1.1 RFC, a new HTTP/2 RFC, and at long last the official RFC for HTTP/3. But headlining them all is a document that seems brand new: HTTP Semantics, no version number in sight, which is declared an internet standard.

We used HTTP/1.x for decades, thinking of it as a single thing – it was a text-based protocol that made requests and responses. It could be transmitted over anything that could carry bidirectional text, though it was usually TCP. There were lots of extension points: You could define new methods, new status codes, or new headers.

When HTTP/2 came along, we had to decide just exactly what it meant to have a new major version of HTTP. Fifteen years earlier, RFC 2145 had said that a new major version might change “the interpretation of other header fields,” while minor versions should be backward-compatible. 

But HTTP/2 brought much more radical changes – it was a binary protocol, not a text-based one! RFC 7540 (HTTP/2 from 2015) tries awkwardly to point out which parts of HTTP/1.1 are actually version-independent, relying on RFCs 7231-7235 and “selected portions” of RFC 7230.

A single protocol called HTTP

In 2016, I wrote an Internet-Draft describing a new concept of HTTP that was beginning to take hold in the community: the idea that there is a single protocol called HTTP, and it is not versioned. The things we call “versions” are actually “mappings” – ways of communicating the same HTTP requests and responses over the network in new and useful ways.

The HTTP community teased apart these layers, and the new RFCs published today reflect that concept:

• HTTP Semantics (RFC 9110) defines the HTTP protocol, independent of version or transport

• HTTP Caching (RFC 9111) defines how HTTP resources are cached, independent of version or transport

• HTTP/1.1 (RFC 9112) defines the classic mapping of HTTP over a transport, typically TCP

• HTTP/2 (RFC 9113) defines an optimized mapping of HTTP over TCP

  • HPACK (RFC 7541) defines how header and trailer fields are compressed in HTTP/2

• HTTP/3 (RFC 9114) defines a mapping of HTTP over QUIC (RFCs 9000-9002)

  • QPACK (RFC 9204) defines how header and trailer fields are compressed in HTTP/3