As far as transport protocols go, TCP is the most used today, and when it comes to TCP implementations, there are as many TCP stacks as there are networked operating systems. This includes everything from Windows PCs to Android Phones and Cisco routers. In most cases, an update to TCP requires a firmware change or OS update - and all endpoints, routers and network appliances may need to deploy a feature for it to work.

Not the case with QUIC, an encrypted transport layer protocol which runs on top of UDP. As QUIC implementations can live in userspace, development can happen separate from the OS. This means control over transport features shifts away from network vendors and operating system implementors to application service providers - enterprises who run the web, like Google and Facebook.

The IETF standards for HTTP/3 and QUIC version 1 are about to be published by the IETF, and the software ecosystem to go with them is still emerging. Many implementations are still under development, and while some provide servers and clients for the QUIC transport, there are very few production-ready out-of-the-box HTTP/3 servers.

Who’s using what?

Serving a website using HTTP3/QUIC needs:

• an SSL library with TLS 1.3 and QUIC crypto support
• a QUIC implementation
• an HTTP/3-enabled webserver

It’s March 2021 at the time of writing. There are several open-source implementations of QUIC, in various stages of readiness. Here’s a diagram of all the QUICs, their TLS library dependencies, and who implements and uses them. Those who run their variant in production are highlighted in orange:

This diagram is not exhaustive, the IETF QUIC working group maintains its own list, including non-open-source implementations.

All the implementations rely on some sort of custom TLS library: the most popular appears to be BoringSSL, Google’s fork of OpenSSL. Other implementations take the approach of developing their own TLS 1.3 libraries (like PicoTLS), which depend on OpenSSL. It doesn’t look like gnuTLS is making an appearance.

Google have been using QUIC in production for a few years (and have switched to IETF QUIC), unsurprisingly as they originated the protocol.

Facebook allegedly use QUIC for more than 75% of their traffic.

Fastly and Cloudflare now allow their customers to enable QUIC for their websites.

Akamai have been using their own implementation since 2016.

Client-side, there is support for QUIC in major browsers, including Firefox nightly since last year - although it’s not enabled by default.

With so many implementations, perhaps you’re wondering if they all talk to each other? Well, the QUIC Working Group also runs interoperability testing of the various implementations.

What about us?

If you’re not a big corporation and want to serve your website over QUIC, then right now you have a few options:

• nginx-quic - according to their README, code is experimental and still under development
• h2o- also provides ‘experimental’ HTTP/3 support
• apache with QUIC support- also under development
• openlitespeed - appears to be the only production-ready option

To run an HTTP/3 server out of the box on any OS, first the custom TLS libraries need to make their way into their respective distribution. On top of this, webservers like Apache and NGINX also need to integrate support for QUIC/HTTP3 in a main release. Any other QUIC and HTTP/3 implementations would also need to be packaged for major server distributions.
In my experience with Debian packaging, this is only likely to happen after the software is mature enough, by which point TLS dependencies will have already been packaged.

For now, everything needs to be built from source.

You can of course host your website with Cloudflare or Fastly and simply enable QUIC - but where’s the fun in that?

My experience with nginx-quic

I’ve deployed nginx-quic on a Raspberry Pi. This was made more complicated due to hitting a bug in gcc 8.3 when building BoringSSL and needing to upgrade the Pi from buster to bullseye, the soon-to-be Debian Stable. After upgrading, BoringSSL built as per instructions in their repo.

Nginx-quic provides a guide for building and configuring the server. I configured the server as per instructions, and tested it with Firefox versions 78 and 85, and Chrome version 88 on both Linux and MacOS.

The mechanism to signal a client the presence of an HTTP/3 server is the use of the alt-svc header, which tells the client which QUIC versions are support and which port to use. In theory, the second time a resource is requested it will use HTTP/3. For my server, this worked… eventually, using version 85, after much page reloading, cache clearing and browser restarting. The logs show about 20 HTTP/1.1 attempts until HTTP/3 was finally used.

I have not managed to get Firefox version 78 and the latest Chrome to do the same, despite enabling QUIC support.

Final words

On one hand, controlling software at both endpoints of a network path (like Google controls its own servers and your browser!) means innovation in the QUIC transport can happen really fast.

But right now, each of my browsers comes with a different implementation of QUIC. If I want cURL with HTTP/3 support I’ll likely need to install yet another QUIC library. What happens when more applications use it? All this seems wasteful, if you consider all applications on an endpoint share a TCP stack.

---