How to Get Started with HTTP/3 – The New Stack

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.

  1. TCP only allows one connection per device at a time, and all data going over that connection has to arrive in order. If a packet drops, the TCP connection can hang or disconnect. When a device switches networks, packets drop, the connection closes and the client can get hung up waiting for packets when it actually needs to reconnect.
  2. Because TCP runs all data reception linearly over one connection, if a packet gets dropped for one kind of asset, like JavaScript, it blocks everything else.
  3. TCP connections have a lot of redundant steps when a client reconnects with a known server using transport layer security (TLS).

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 doesn’t block delivering the HTML, CSS or streaming video. 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.


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 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.

Group Created with Sketch.

Source link


Leave a Reply

Your email address will not be published. Required fields are marked *