How to Get Started with HTTP/3
Like many around the world, as 2022 ended I looked forward to watching the World Cup. One day, I was watching the World Cup on my phone while walking my dog. As Team USA was about to score, I walked out of my Wi-Fi range, and my phone switched to a cellular connection. The stream paused and didn’t come back for about 15 seconds. I missed the goal!
With the rise of Wi-Fi over hardwired connections, and particularly with the rise of phones, we’ve gone from a world where our connections to the internet were very steady to one where we go in and out of connection. Our connections drop data packets, and we switch between networks regularly, interrupting our ability to receive data, whether it’s new messages on Slack, a video call with a loved one or that all-important goal in a big game. If that is regularly happening to your users, they will go elsewhere. HTTP/3 is the right solution.
What Does Connectivity Have to Do with HTTP/3?
To answer that, let’s dive into why I missed seeing that goal. HTTP/3 is based on QUIC (Quick UDP Internet Connections), and thus UDP, rather than transmission control protocol (TCP), and TCP’s limitations are what caused my streaming video problems.
- Both HTTP/1.1 and HTTP/2 over TCP have Head-of-Line blocking issues, where “one lost packet in the stream makes all streams wait until that package is re-transmitted and received.”
- TCP connections have redundant steps when a client reconnects with a known server when using transport layer security (TLS) (though this can be avoided by using TLS 1.3, which QUIC adopts).
All these issues factored into my stream being interrupted for so long that I missed the action.
HTTP/3 was designed to solve the above problems. It supports out-of-order packet delivery. Connections can multiplex streams of data, so a delay in delivering all your JavaScript packets doesn’t block delivering the HTML, CSS or streaming video packets. When a client reconnects with a server over HTTP/3, it can skip several steps in the TLS handshake process, making that process much faster. There are also other advantages to HTTP/3 that improve quality of life for users, like improved compression and bandwidth usage optimization.
Great! How Do I Get Started with HTTP/3?
Investing in HTTP/3 adoption today is an investment in the future. It is still cutting-edge technology, with limited support. The reason I started with an example of connection interruptions is that it is HTTP/3’s “killer app.” If your users are on reliable connections, or your site or app can already handle dropped connections, you probably don’t need HTTP/3 right now. But if high resiliency for unreliable connections is required to support your app, then it’s worth making the investment now.
Where Is HTTP/3 Supported?
HTTP/3 is supported by two of the three major browsers, the most recognized mobile app languages, and some server-side languages, as well as the largest content-delivery networks. But there are caveats.
Client Side
You can track browser support at Can I Use. Chrome and other Chromium-based browsers like Edge support HTTP/3, as do Firefox and Opera, both on desktop and mobile. However, as of writing this article, Safari on desktop and mobile only supports HTTP/3 as an experimental feature that can be turned on in the dev tools, which, let’s face it, your users aren’t doing. From a web app perspective, it’s promising for enterprise applications where you have some assurance that users will use a compatible browser. Building in support now will also get you ahead of the game when support lands in Safari.
But! My original example involved streaming video from a phone app, and in an app, you don’t need to rely on browser support. Client libraries exist for Swift, Kotlin and React Native. You can implement an end-to-end HTTP/3 stack in your app today for your mobile app.
Server Side
On the server side, there are production-ready libraries for:
This list is missing some major languages/frameworks, like Node.js, where the implementation is in progress. Additionally, those production-ready libraries tend to be lower-level libraries that your teams will need to build on top of. There’s no Spring Bean that auto-magically adds HTTP/3 support right now.
Infrastructure
Of course, client devices rarely connect directly to your server. There are various layers of networking technology between them. The good news is most of the vendors in the CDN and WAF space have a strong incentive to stay ahead of the curve here. Cloudflare, Fastly, AWS CloudFront, and of course, Google Cloud CDN (as Google is where QUIC originated) already support HTTP/3 to some extent. There are caveats; for example, Fastly supports client connections to Fastly using HTTP/3 but not between Fastly and your origin servers.
If you are running a traditional web server architecture, two web servers support HTTP/3:
If you do decide to adopt HTTP/3, and you happen to be running on Kubernetes (and if you’re forward-thinking enough for the former, smart money is that you’re doing the latter), it does support HTTP/3 connections. However, there is currently only one Kubernetes-native API Gateway that supports HTTP/3: Emissary-Ingress and its paid version Ambassador Edge Stack.
Summing It Up
HTTP/3 is an exciting new technology that stands to address many of the issues that have surfaced in our changing network world that includes more mobile devices and less stable connections, and where we expect to have seamless, uninterrupted user experiences as we move from our homes to the metro to work and play. HTTP/3 is still in its early days with a lot of room to mature, but if you need those features, you can start adopting it now.
