I’m sure, like me, that you enjoyed the announcement of the third major version of the Hypertext Transfer Protocol, i.e. HTTP/3, was adopted as an Internet Engineering Task Force (IETF) standard last month. No, of course you didn’t – the web works, so why bother? But if you’re vaguely intrigued by why the change is happening, here’s a quick rundown of the story behind it. Next, we’ll discuss why you should adopt it for your business.
💡 HTTP/3 is the third version of the Hypertext Transfer Protocol (HTTP), and was previously known as HTTP-over-QUIC. QUIC was originally developed by Google and is the successor to HTTP/2. Companies such as Google and Facebook are already using QUIC to speed up the web.
A very short history of HTTP
At the time, there were two Internet protocols you could choose to work with. Even before the Web, we still had to send packets of information (or datagrams) from one machine to another over the Internet. For a game developer, the important protocol was UDP (User datagram protocol). It was the fast, shoot-and-forget standard: you threw a packet on the network and it was caught, or sometimes it wasn’t. This was perfect for representing (for example) a player’s bullet as it came from your gun, across the network, to be displayed on your target’s machine. Even if a ball got lost along the way, at least the game session as a whole would still be good.
But for more stable systems like the web, the correct underlying protocol to use was TCP (Transmission Control Protocol). This was a more formal system, which guaranteed the delivery and good order of packages. Thus, he created reliable connections, and later reliable information flows. Connecting to the Internet before the Web (yes, there was a before), I remember using Trumpet Winsock – and it’s been described as a “TCP/IP stack”. At a long-dead company, we used it to work with CIX, which was a UK online conferencing (message board) system. Today, of course, CIX is a South Korean boy band. It is progress.
Eventually, the World Wide Web and HTTP, written on top of TCP/IP, became the primary use of the Internet. The other missing acronym is TLS (Transport Layer Security), which provided the element of encryption and became the de facto security standard by the time HTTP/2 was ready.
At that time the connection between PCs was usually wired and any loss was due to noise on the old copper lines. TCP was good at bundling occasional stray packets. As the web has taken hold, the reasons for using UDP have diminished.
Walk in FAST
The Internet today is a very different place. Yes, I have a good fiber connection and good lines to my PC at home, but most people use the internet through their phone or laptop. When moving from mast to mast, behind walls that block or bounce signals, connections are usually cut and restarted. That’s 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 compatibility and waiting for that last spurious packet just means that users have to wait for web pages to load and new apps to download, or a connection timeout. be restored.
So to take advantage of the informality of UDP and allow the network to use some clever stuff on the fly, the new FAST (Fast UDP Internet Connections) has attracted more attention.
While we don’t want to see too much intelligence within the network itself, we’re much more comfortable these days with automatic decision-making. QUIC understands that a site is made up of multiple files, and it won’t mess up the whole connection just because one file hasn’t finished loading.
The other trend followed by QUIC is integrated security. Whereas encryption was optional before (i.e. HTTP or HTTPS), QUIC is still crypt. It’s a given these days that every site should be encrypted, despite the overhead. It’s not just to make sure a man in the middle can’t see what kind of orange juice you’re ordering; this confirms that you are actually talking to your real orange juice supplier.
Formats almost always improve, but what they really do is address different concerns over time.
So how is the implementation going? There are three sides to consider here. The browser, cloud infrastructure and user code.
First, the browser. Here is a table from the “Can I use” website:
Clearly, Google is keen — versions of Chrome from v87 (late 2020) were able to use the HTTP/3 protocol. Unsurprisingly, given Apple’s recent history in browser development, Safari lags behind.
You can use one of these sites right now to check if your browser is HTTP/3 compatible (may need to be reloaded):
But what about existing websites? Does your site currently use it? So, to test an existing site, try https://geekflare.com/tools/http3-test. And before you ask, no thenewstack.io (i.e. IP: 184.108.40.206) does not currently support it! But we have plenty of company in that regard. The good news is that if your website performs well under HTTP/2, it will perform well or better under HTTP/3.
Who is promoting HTTP/3?
Now, who is pushing HTTP/3? Well, you already know; it’s Google. But also CDNs, for example Cloudflare and Fastly. Their bread and butter is web response speed. Therefore, the easiest way to implement HTTP/3 is through a CDN. It’s also a change that benefits mobile users a bit more.
There are servers built with QUIC (e.g. L), but adoption has been uneven. Many servers depend on third-party libraries, hence the pattern of reusing existing, verified work breaks in this case. Legacy 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 untested. The beauty of using a web server is that it is reliable, well tested and maintained.
Under normal circumstances I would dive into some code – but I think that would be a little premature at this point. There are a plethora of projects that probably all change on a regular basis, so 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 telephone switching to wi-fi for example), the connection remains in order to avoid having to start the negotiation again.
The connections then open streams which carry their own data type and do not interfere with each other.
Below, there are still packages. Each packet, like a well-addressed letter, has its connection and cryptographic information. And inside the envelope are frames. These represent the actual data transmitted.
As I said earlier, progress only reflects changing patterns of use. Today, we value security and speed because we no longer treat the web like untrustworthy magic – and therefore use it to run our personal affairs. HTTP/3 will help align with these concerns. The elephants in the room may be Web3 and emerging rich metaverse worlds. Maybe new ideas from these areas will contribute to HTTP/4 in the future.
Featured image via Shutterstock.