HTTP/3: State of Play

It’s good to be the King! – Mel Brooks

The October HTTP/3 Interop has come and gone. What follows is a short recap, a look at the current status of HTTP/3, and where we will go from here.

Introduction

The IETF QUIC Working Group held a virtual interoperability event on October 1 and 2. These events have been held regularly for the past year and a half. This interop was virtual, meaning we were collaborating online across the time zones.

During an interop, the various server and client QUIC and HTTP/3 implementations try to talk to each other and exercise different pieces of functionality. The interops serve as a sanity check and allow us to find bugs in our code and, more importantly, in the specifications themselves.

The Matrix

To keep track of different features, an interop matrix is recorded in an online spreadsheet.

14th Implementation Draft Interop Matrix

Each feature is assigned a letter and categorized into Core, Optional, Performance, and HTTP/3.

The “aioquic client / lsquic server” cell from the matrix above

For example, the above means that aioquic client was able to connect to LiteSpeed server and

• perform version negotiation (V);
• complete handshake (H);
• transfer data (D);
• close connection successfully (C);
• use TLS session ticket to resume a connection (R);
• send request in zero-rtt data and receive response (Z);
• respond to a stateless retry (S);
• migrate a connection to server’s preferred address (M);
• survive a NAT port rebinding (B);
• update TLS keys (U);
• spin latency bits (P);
• transfer a 10MB resource reasonably fast (T);
• fetch an HTTP/3 resource (3);
• utilize QPACK dynamic tables (d); and
• receive a push request (p).

One can see the complete list of categories and features here.

Two more features not listed here are

• explicit congestion notification (E) (which our server supports); and
• structured logging support (L), which was a last-minute addition to the list of features.

The way the letters are colored is a bit obscure, but the general rule is that more features get you a hotter color. LiteSpeed supports all but one feature (including all HTTP/3 features) and the client in this case was able to hit all but one of them. At the time of this writing, our server implementation was the only one to have earned the imperial purple. It’s good to be the king!

Participation

The number of participating implementations has decreased from the previous interop. Notable absentees are Quant (implementation by Lars Eggert (NetApp), the co-chair of the QUIC Working Group), quic-go (a Go implementation by Marten Seemann), and Apple. The latter only make an endpoint available in face-to-face meetings, running on someone’s laptop.

A couple of implementations are still dragging their feet on HTTP/3 support.

I had productive interop sessions with Cloudflare, F5, Facebook, and Microsoft, among others. We found a few bugs and clarified a couple of points in the specification.

Throughput

This metric is the only member of the Performance Features category. It is roughly defined as “being able to download a 10MB resource over QUIC that is at most 10% slower than the same resource downloaded using HTTP/2.”

The problem with this definition is that most people have different servers for HTTP/2 and QUIC. This may cause highly disparate download times between the two protocols. At times, some hoodoo was used to get the coveted “T” letter. As one participant — not your humble author — muttered to himself, “I need to cripple TCP…”

Take these results with a grain of salt

ECN

Only three implementations support Explicit Congestion Notifications: F5, LiteSpeed, and Quant. As Quant did not participate this time around, there is only one “E” letter in the whole matrix: LiteSpeed client and F5 server. The reverse test failed, as something dropped ECN markings on path.

The future of ECN as a feature of QUIC is uncertain.

Bugs Found

With help from Alessandro Ghedini (Cloudflare), Nick Banks (Microsoft), and others, I found and fixed a couple of minor (standard compliance) bugs in our implementation. Look for them in the next release of the LiteSpeed QUIC and HTTP/3 Library.

To return the favor, our server broke Tatsuhiro Tsujikawa’s HTTP/3 client (nghttp3) via its “unidirectional stream torture mode,” which is turned on by default for the interop purposes. Our client found a bug in the way Google server interprets transport parameters.

Clients

Finally, there is HTTP/3 browser support! Two weeks ago, Chrome Canary began to support HTTP/3 when provided a couple of special flags. This is wonderful, as we now can test HTTP/3 using real websites with a real browser. LiteSpeed Web Server and ADC have supported HTTP/3 since July 2019 and OpenLiteSpeed — since September. Now our customers and users can try HTTP/3 for themselves.

As of October 4, Microsoft Edge Canary supports HTTP/3 as well.

The venerable curl command-line tool and library added HTTP/3 support in August.

Firefox is planning to add HTTP/3 support by the end of the year.

These are good signs.

Servers

We have been shipping HTTP/3-enabled products for months. We are happy there are now real browsers to pollinate our servers, so to speak.

Cloudflare announced QUIC availability last week to much ado. Indeed, using our http3check.net tool, one can see that they do support HTTP/3. Welcome to the party.

LiteSpeed and Cloudflare are the only two known vendors running HTTP/3 in production.

Future

The next QUIC Interim Meeting is in two weeks. There are a few design items on the menu, but nothing earth-shattering. I can see the light at the end of the tunnel; HTTP/3 is inching closer to being released.

In the meantime, our LiteSpeed QUIC Team will continue to improve our software, participate in the HTTP/3 standardization process, and think of new ways to deliver value for our customers.