Status

The QUIC working group has worked fiercely since late 2016 on specifying theprotocols and the plan is now to have it done by July 2019.

As of November 2018, there still has not been any larger interoperabilitytests with HTTP/3 - only with the existing two implementations and none ofthem are done by a browser or a popular open server software.

There are fifteen or so different QUIC implementationslisted in the QUICworking groups’ wiki pages, but far from all of them can interoperate on thelatest spec draft revisions.

Implementing QUIC is not easy and the protocol has kept moving and changingeven up to this date.

Servers

NGINX support for QUIC and HTTP/3 is under development.It is planned to be released duringNGINX 1.17 development cycle.

There have been no public statement in terms of support for QUIC from Apache.

Clients

None of the larger browser vendors have yet shipped any version, at any state,that can run the IETF version of QUIC or HTTP/3.

Google Chrome has shipped with a working implementation of Google’s own QUICversion since many years, but that does not interoperate with the IETFQUIC protocol and its HTTP implementation is different than HTTP/3.

Mozilla is developing Neqo -a QUIC and HTTP/3 implementation written in Rust.Neqo is planned to be integratedin Necko(which is a network library used in many Mozilla-based client applications -including Firefox).

curl shipped the first experimental HTTP/3 support (draft-22) in the 7.66.0release on September 11, 2019. curl uses either the Quiche library fromCloudflare or the ngtcp2 family of libraries to get the work done.

Implementation Obstacles

QUIC decided to use TLS 1.3 as the foundation for the crypto and securitylayer to avoid inventing something new and instead lean on a trustworthy andexisting protocol. However, while doing this, the working group also decidedthat to really streamline the use of TLS in QUIC, it should only use “TLSmessages” and not “TLS records” for the protocol.

This might sound like an innocuous change, but this has actually caused asignificant hurdle for many QUIC stack implementors. Existing TLS librariesthat support TLS 1.3 simply do not have APIs enough to expose thisfunctionality and allow QUIC to access it. While several QUIC implementorscome from larger organizations who work on their own TLS stack in parallel,this is not true for everyone.

The dominant open source heavyweight OpenSSL for example, does not have anyAPI for this. The plan to address this seems to happen in their PR8797 that aims to introduce anAPI that is very similar to the one of BoringSSL.

This will eventually also lead to deployment obstacles since QUIC stacks willneed to either base themselves on other TLS libraries, use a separate patchedOpenSSL build or require an update to a future OpenSSL version.

Kernels and CPU load

Both Google and Facebook have mentioned that their wide scale deployments ofQUIC require roughly twice the amount of CPU than the same traffic load doeswhen serving HTTP/2 over TLS.

Some explanations for this include

  • the UDP parts in primarily Linux is not at all as optimized as the TCP stackis, since it has not traditionally been used for high speed transfers likethis.

  • TCP and TLS offloading to hardware exist, but that is much rarer for UDP andbasically non-existing for QUIC.

There are reasons to believe that performance and CPU requirements willimprove over time.