I’m sure, like me, you welcomed the news that the third major version of the Hypertext Transfer Protocol, i.e. HTTP/3, was adopted last month as an IETF standard (Internet Engineering Task Force). No, of course, you didn’t — the web just works, so why worry about it? But if you are vaguely intrigued about why the change is happening, here is a short breakdown of the history behind it. Then we will get into the reasons why you should adopt it for your company.

HTTP/3 is the third version of the Hypertext Transfer Protocol (HTTP), and was previously known as HTTP-over-QUIC. QUIC was initially developed by Google and is the successor of HTTP/2. Companies such as Google and Facebook already use QUIC to speed up the web.

A Very Short History of HTTP

Back in the day, there were two internet protocols that you could choose to work with. Even before the web, we still had to squirt packets of information (or datagrams) from one machine to another across the internet. For a games developer, the important protocol was UDP (User Datagram Protocol). This was the quick, fire and forget standard: you threw a packet across the network and it was caught, or sometimes it wasn’t. It was perfect to represent (for example) a game player’s bullet as it came from your gun, across the network, to be displayed on your target’s machine. Even if a bullet did get lost along the way, at least the game session as a whole would still be fine.

But for more steady systems like the web, the correct underlying protocol to use was TCP (Transmission Control Protocol). This was a more formal system, which guaranteed delivery and the correct order of the packets. Thus it created reliable connections, and later on reliable streams of information. Connecting to the internet before the web (yes, there was a before), I remember using Trumpet Winsock — and this was described as a “TCP/IP stack”. In a long-since deceased company, we used this to work with CIX, which was a British online conferencing system (message board). Today, of course, CIX is a South Korean boy band. That’s progress.

Eventually, the world wide web and HTTP, written on top of TCP/IP, took over as the main use for the internet. The other missing acronym is TLS (Transport Layer Security), which provided the encryption element and became the de facto security standard by the time HTTP/2 was ready.

In those days, the connection between PCs was usually wired and any loss was due to noise on old copper lines. TCP was good for corralling occasional errant packets. As the web took hold, the reasons for using UDP diminished.

Enter QUIC

The internet today is a very different place. Yes, I have a nice fibre connection and good lines to my PC at home, but most users experience the internet over their phones or laptops. As you move from one mast to another, from behind walls that block or bounce signals, connections are commonly cut and restarted. This is not what TCP likes — it doesn’t really want to communicate without formal introductions and a good firm handshake. In fact, it turns out that TCP’s strict accounting and waiting for that last stray packet just means that users have to wait around for webpages to load and new apps to download, or a connection timeout to be re-established.

So to take advantage of the informality of UDP, and to allow the network to use some smart stuff on-the-fly, the new QUIC (Quick UDP Internet Connections) format got more attention.

While we don’t want to see too much intelligence within the network itself, we are much more comfortable these days with automatic decision making. QUIC understands that a site is made up of multiple files, and it won’t blight the entire connection just because one file hasn’t finished loading.

The other trend that QUIC follows up on is built-in security. Whereas encryption was optional before (i.e. HTTP or HTTPS) QUIC is always encrypted. It is a given these days that every site should be encrypted — despite the overhead. This isn’t just to ensure that a man in the middle can’t see what type of orange juice you are ordering; it confirms that you are actually talking to your genuine orange juice supplier.

Formats nearly always improve, but what they really do is address different concerns over time.

Active Use

So how is the implementation going? There are three sides to consider here. The browser, cloud infrastructure and user code.

First, the browser. This is a table from the “Can I use” website:

Clearly, Google is keen — versions of Chrome from v87 (late 2020) onwards have been able to use the HTTP/3 protocol. Unsurprisingly, given Apple’s recent history in browser development, Safari is the laggard.

You can use any of these sites right now to check if your browser is HTTP/3 compliant (may need a reload):

But what about existing websites? Is your site currently using it? So to test an existing site, try https://geekflare.com/tools/http3-test. And before you ask, no thenewstack.io (i.e. IP: 172.67.70.57) doesn’t currently support it! But we have lots of company in that regard. The good news is that if your website works well under HTTP/2, it will be good or better under HTTP/3.

Who Is Promoting HTTP/3?

Now, who is pushing HTTP/3? Well, you already know; it is Google. But also the CDNs, e.g. Cloudflare and Fastly. Their bread and butter is web response speed. Consequently, the easiest way to implement HTTP/3 is via a CDN. It is also a change that benefits mobile users a little bit more.

There do exist servers that are built with QUIC (for example, Litespeed) but adoption has been uneven. Many servers depend on third-party libraries, so the pattern of reusing existing, verified work breaks in this case. The existing servers, such as Node.js, NGINX and Apache, lose their user experience advantages when they start implementing new innards. And conversely, new libraries are relatively unproven. The point of using a web server is that it is dependable, well tested and maintained.

Adopting HTTP/3

Under normal circumstances, I would dive into some code — but I feel that would be a bit premature at this stage. There are a plethora of projects that are probably all regularly changing, so just dig in.

Looking at some of the simple minimal working examples (e.g. a simple server and a simple client), we can recognize several levels of work.

First, the connection. This higher-level channel is established initially between two endpoints. A connection identifier is established. Once established, if the protocols below change (a phone switching wi-fi, for example), the connection remains in order to avoid having to start the negotiation all over again.

Connections then open streams that carry their own type of data and don’t interfere with each other.

Below that are still packets. Each packet, like a well-addressed letter, has its connection and cryptographic information. And inside the envelope are frames. These represent the actual data being transmitted.

As I said earlier, progress really just reflects changing use patterns. Today, we value security and speed because we no longer treat the web as untrustworthy magic — and hence use it to manage our personal affairs. HTTP/3 will help to align with these concerns. The elephants in the room may be Web3 and the emerging rich metaverse worlds. Perhaps new ideas from these areas will be contributing to HTTP/4 in the future.

Feature image via Shutterstock.