Wake up call

This post is about HTTP/3 and QUIC. If you don’t know what that is, there are many, many, many, many, many, many, many good resources that will get you up to speed. I’m writing this post to enlighten people on what has been happening in the last few years.

All major browsers support HTTP/3 now.

Most major cloud providers support HTTP/3 now.

Most major load balancers support HTTP/3 now.

In a short few years over 30% of web traffic is served with HTTP/3.

HTTP/3 isn’t the future. It’s the present.

Every time I mention HTTP/3 there’s always someone who pops up who’s completely unaware that it even exists, thinks that it’s some minor change or thinks that supporting HTTP/3 is cargo cult behavior. Every web developer should probably know that HTTP/3 exists because HTTP/3 is a giant change. HTTP/3 abandons TCP in favor of a channel-aware UDP-based protocol called QUIC. To me, this feels important! This feels like people need to be talking about it, doing more experiments around QUIC, and writing more tooling, security analysis and benchmarks. QUIC has the potential to dethrone TCP as the reliable layer 4 protocol. This is a big deal.

Why should you care about HTTP/3 if you’re not a big nerd who likes learning about network protocols? Because it promises to bring a lot of advantages: faster page loads, smoother video streaming, and more resilient connections. Plus, I think web developers need to know about the foundations of their profession. And this foundation has been changing. Rapidly.

What’s wrong with TCP?

Multiple streams: One Connection

There are issues with multiplexing multiple streams onto one TCP-backed connection. This is because TCP treats all data on a connection as one big stream. If one part of that stream gets delayed or lost, everything else gets stuck behind it, like a traffic jam on a single-lane road. This is called ‘head-of-line blocking,’ and it can significantly slow down web page loading, especially when multiple resources (like images, scripts, and stylesheets) are being requested simultaneously.

It isn’t good in dynamic network environments

As mentioned in the last section, TCP connections are slow to set up because of the number of round trips required. In environments that change often, causing your web clients to switch networks (and client IP addresses), the clients will have to re-establish an entirely new connection each time you switch networks. Think about the large pause that happens when you switch wifi networks while using video chat. That’s exactly this issue. TCP was not designed to handle this situation without that pause. In the following section, I’m going to tell you how QUIC (and HTTP/3) handles this situation in a much more reliable and smooth way. This is extremely relevant today in a world where mobile phones can choose to swap between multiple wifi and mobile networks.

Why can’t I use wifi and mobile at the same time?

This is actually possible with TCP, using a feature called multipath TCP, but the rollout has been slow and difficult for TCP. QUIC’s built-in support for connection migration and 0-RTT resumption offers a smoother and more efficient solution to this problem, potentially enabling true multipath connectivity in the future.

Enter: QUIC and HTTP/3

Faster Connections

First off, QUIC requires far fewer round trips to set up an encrypted connection. Instead of 3 needed for TLS+HTTP/2, QUIC just has one.

Zero Round Trip Time (0-RTT) Resumption

QUIC connections can be resumed, even if the client’s IP address changes. This allows connections to be re-established with zero round trips, so when you are on a conference call and switch wifi networks your HTTP/3 connection can resume instantaneously. While there have been security concerns around this feature, such as the potential for replay attacks, these have been largely mitigated through measures like rotating keys and client IDs.

I mentioned earlier how the rollout of multipath for TCP hasn’t been super successful. With the features to support 0-RTT, support for multipath is essentially built-in, so you may see more concurrent usage of wifi, ethernet and mobile networks in the future.

Multiplexing

In contrast to TCP+HTTP/2, QUIC ensures that packet loss or delays on one stream don’t impact others. This is because QUIC manages ordering guarantees at the individual stream level, not for the entire connection, effectively eliminating head-of-line blocking.

Improved Congestion Control

QUIC’s more responsive congestion control leads to faster recovery from packet loss.

“But I heard UDP is unreliable”

It’s a common misconception that UDP is inherently unreliable compared to TCP. TCP packets are just as unreliable, but they transparently get retried by TCP client and server implementations. In other words, both TCP and UDP packets can be lost or corrupted during transmission; the difference lies in how they handle those errors. While it is true that UDP doesn’t offer the same built-in guarantees as TCP, QUIC implements the same guarantees on top of UDP.

Think of it like this: TCP is like a delivery service that meticulously tracks every package and resends any that go missing. UDP, on the other hand, is more like a bulk mailer, sending out a flood of letters and hoping most of them arrive. However, QUIC builds its own tracking system on top of UDP, ensuring reliable delivery of data.

This means QUIC can enjoy UDP’s speed and flexibility without sacrificing reliability. In fact, in some cases, QUIC can even outperform TCP in terms of packet loss recovery, thanks to its advanced congestion control mechanisms.

So, while the “UDP is unreliable” mantra might have been true in the past, protocols built on UDP can be even more reliable than TCP.

Let’s see how far we’ve come

Okay, so I mentioned how available HTTP/3 is a few times now. But let’s look at the specifics: browser support, cloud support and support when self-hosting.

Web Browsers

Let’s start with web browsers. HTTP/3 support doesn’t matter if browsers don’t support the technology. CanIUse shows the support for each browser and it looks very good for all major browsers:

The only caveat is that Safari only enables HTTP/3 for a portion of users, but Apple will come around eventually.

Cloud Providers

Next, if you want to host websites with HTTP/3 it would be awesome if cloud providers supported HTTP/3. Well, you’re in luck. Most major cloud providers do support HTTP/3, including:

Load Balancers

But what if you’re setting up your own infrastructure, foregoing the cloud? What are the available options?

Is HTTP/2 already dying?

Take a look at the comparative usage of HTTP/2 and HTTP/3 over the last few years:

Source: w3techs.com

From this graph, you can see that in a short few years, HTTP/3 usage is rapidly approaching the same usage as HTTP/2. We had “peak HTTP/2” in 2021 and maybe next year we will see HTTP/3 overtake HTTP/2 to be the de-facto standard for new web deployments.

I will be honest though, other sources, such as Cloudflare and Internet Society Pulse, present a slightly different picture, with HTTP/2 still handling a significant portion of traffic.

Why don’t web developers know about this?

Well, simply put, none of this really intersects with them in any meaningful way. You can’t even tell what version of HTTP your browser is making from Javascript. No, not even with the Fetch API. I recently looked into this because I wanted to print out the version of HTTP being used when loading my website in a tool that I made but I had to resort to adding headers to the response via Cloudflare to get that information. Because of all of this, I’m certain that there’s a large number of web developers who have no idea that their website is using HTTP/3.

If you want to know which version of HTTP your browser is using when loading your website, most browser inspector interfaces can show this by going to the network tab, right-clicking the headers and adding “Protocol” to the list of columns to show. It also usually shows the protocol when you look at the details of each request.

Challenges Ahead

There are two main areas to focus on with QUIC: adding more tooling and language support for the protocol.

Tooling/Language Support

Even though browsers and load balancers have good support for QUIC, most programming languages don’t support HTTP/3 because QUIC presents a vastly different way to communicate. Without kernel support or widely supported bindings, adding QUIC to a language is a bit like re-implementing TCP in the language. TCP is usually relatively easy to add because OS kernels typically implement TCP for you and provide bindings. As far as I know, that isn’t the case for QUIC.

Will QUIC stay in userspace?

From what I’ve seen, there’s no well-supported kernel module for QUIC. There exist some projects that do add a kernel module for Linux but it doesn’t seem like it’s heavily used yet. TCP has benefitted a lot from being backed by OS kernels, which gives it performance optimizations not available in user space but that strength is also a weakness. TCP is now hard to change and adapt. It appears like QUIC has evolved much quicker because of its user-space implementations, but should it stay there? Some have reported that it’s possible to match the performance of TCP, even when running in userspace. So does QUIC need the performance improvements that are possible in the kernel? Should there be a hybrid approach that could give a balance of flexibility and performance advantages? To me, those are open questions and I’m curious how this will unfold over time.

Naysayers

Since QUIC does present a lot of changes, there are people, mostly network engineers, who do not like the quick adoption of QUIC. Here are some of the complaints:

  • Most web traffic is a bloated mess anyway, and the additional few milliseconds it takes to stand up a TCP connection doesn’t account for a large amount of bloat in modern web applications.
  • QUIC makes it more difficult for network administrators to monitor and inspect traffic.
  • QUIC induces more CPU overhead, as it doesn’t have decades of optimization that TCP has.
  • QUIC is a relatively new protocol, and there may still be undiscovered bugs or vulnerabilities, especially with so many languages/platforms re-implementing the protocol.

Further, many argue that the benefits just don’t outweigh the risks. I don’t think I agree. I think these network engineers are discounting just how much traffic comes from mobile or dynamic (sketchy) wifi environments. However, I am surprised at how quickly and the method by which QUIC has been rolled out. Should we pump the brakes or is it too late?

The Future is QUIC

HTTP/3 and QUIC are more than just incremental improvements; they represent a fundamental shift in how we build the web. By overcoming the limitations of TCP, QUIC offers a faster, more reliable, and more secure foundation for modern Internet communication.

The benefits are clear: faster page loads, smoother video streaming, more responsive applications, and seamless transitions between networks. This translates to a better user experience, increased engagement, and ultimately, a more vibrant and dynamic internet.

But QUIC’s potential extends far beyond the web. Its ability to handle real-time communication, coupled with its built-in security features, makes it an attractive option for applications like online gaming, video conferencing, and more. There are already some big projects built on QUIC:

While the transition to HTTP/3 is well underway, it’s far from complete. There are still challenges to overcome, such as improving tooling, expanding language support, and ensuring compatibility with existing infrastructure. And it remains to be seen if HTTP/3 is ready for mass adoption.

However, the momentum is undeniable. With major browsers, cloud providers, and load balancers embracing QUIC, the future is bright. As developers and engineers continue to innovate and build on this foundation, we can expect to see even more exciting possibilities emerge.

So, what are you waiting for? If you’re a web developer or tech enthusiast, now is the time to dive into QUIC and start exploring its potential. Experiment with new applications, build innovative tools and share your findings with the community. I’ve started doing this by trying HTTP/3 with gRPC. The future of the internet is being written in QUIC, and you can be a part of it.

If you want to learn more, here are a lot of resources that I used to research for this article: