Table of contents of the article:
I'm sure you, like me, have welcomed the news that the third major version of the Hypertext Transfer Protocol, that is HTTP / 3, was adopted last month as IETF standard (Internet Engineering Task Force). No, sure, you didn't: the web just works, so why bother? But if you're vaguely intrigued as to why the change is taking place, here's a brief analysis of the story behind it. Then we will delve into the reasons why you should adopt it for your business.
HTTP / 3 is the third version of the Hypertext Transfer Protocol (HTTP) and was formerly known as HTTP-over-QUIC. QUIC was initially developed by Google and is the successor to HTTP / 2. Companies like Google and Facebook are already using QUIC to speed up the web.
A very short history of HTTP
In the past, there were two internet protocols that you could choose to work with. Even before the Web, we still had to spray 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). This was the quick standard, shoot and forget: you threw a packet across the net and it got caught, or sometimes it wasn't. It was perfect for representing (for example) a player's bullet as it came from your gun, through the net, to be displayed on your target's machine. Even if a bullet got lost along the way, at least the game session as a whole would still be fine.
But for more stable systems like the web, the correct underlying protocol to use was the TCP (Transmission Control Protocol). It was a more formal system, which guaranteed delivery and proper ordering of packages. Thus he created reliable connections and later reliable information flows.
Eventually, the World Wide Web and HTTP, written over TCP / IP, took over as the primary use of the Internet. The other missing acronym is TLS (Transport Layer Security), which provided the encryption element and became the de facto security standard when HTTP / 2 was ready.
In those days the connection between PCs was usually wired and any loss was due to noise on the old copper lines. TCP was good for bundling occasional bad packets. With the rise of the web, the reasons for using UDP have diminished.
Enter the scene HERE C
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 users use the internet via phones or laptops. When moving from tree to tree, from behind walls blocking or bouncing signals, connections are commonly interrupted and restarted. That's not what TCP likes - it doesn't really want to communicate without formal introductions and a good handshake. In fact, it turns out that TCP's strict accounting and waiting for the last stray packet only means that users have to wait for web pages to load and download new apps or reset a connection timeout.
So to take advantage of the informality of UDP and to allow the network to use some smart stuff on the fly, the new format HERE C (Quick UDP Internet Connections) received more attention.
While we don't want to see too much intelligence within the network itself, we are much more comfortable with automated decision making these days. QUIC understands that a site is made up of multiple files and will not damage the entire connection just because one file has not finished loading.
The other trend followed by QUIC is integrated security. While encryption was optional before (such as HTTP or HTTPS), QUIC is always encrypted. It is a fact nowadays that every site should be encrypted, despite the overhead. This isn't just to ensure a man in the middle can't see what kind of orange juice you're ordering; confirm that you are indeed talking to your real orange juice supplier.
Formats almost 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, the cloud infrastructure and the user code.
First, the browser. This is a table from the "Can I Use" website
Clearly, Google is thrilled: Chrome versions from v87 (late 2020) onwards have been able to use the HTTP / 3 protocol. Not surprisingly, given Apple's recent history in development browsers, Safari is running late.
You can use one of these sites right now to check if your browser is compatible with HTTP / 3 (may need to 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 currently supports it!
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 daily bread is the responsiveness of the web. Consequently, the simplest way to implement HTTP / 3 is via a CDN. It's also a change that benefits mobile users a little more.
There are servers created with QUIC (for example Litespeed) but the adoption was not uniform. Many servers depend on third-party libraries, so the reuse model of existing and verified work interruptions in this case breaks. Existing servers, such as Node.js, NGINX, and Apache, lose the user experience benefits when they start implementing new extensions. And conversely, the new libraries are relatively unproven. The point of using a web server is that it is reliable, well tested and maintained.
Currently in Managed Server, our company, after about 6 months of testing and monitoring we have released into production the support for the QUIC protocol for the NGINX web servers that are the basis of our performance oriented web software stack.
We can claim to be a Hosting that provides HTTP3 and QUIC on the high-end plans.
Therefore, unlike many other hosting providers that use QUIC exclusively with webservers that support QUIC by default such as LiteSpeed, we were able to integrate this important improvement into an excellent webserver like NGINX.
Adoption of HTTP / 3
Under normal circumstances, I would dive into some code, but I feel it would be a bit premature at this stage. There are a plethora of projects that probably all change regularly, so dig deeper.
Looking at some of the simple examples of minimal operation (for example a simple server and a simple client), we can recognize different levels of work.
First, the connection. This top-level channel is initially established between two endpoints. A connection identifier. Once established, if the underlying protocols change (a phone changing wi-fi, for example), the connection remains to avoid having to start the deal all over again.
The connections then open flows which carry their own type of data and do not interfere with each other.
There are still packages underneath. Each packet, like a well-addressed letter, has its own connection and cryptographic information. And inside the envelope there are some frames. These represent the actual data transmitted.
As I said earlier, progress really only reflects changing usage patterns. Today, we value security and speed because we no longer treat the web as unreliable magic and therefore use it to manage our personal affairs. HTTP / 3 will help align with these concerns. The elephants in the room could be Web3 and the rich emerging worlds of the metaverse. Perhaps new ideas from these areas will contribute to an eventual, possible and probable HTTP / 4 in the future.
