Status

    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.

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

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

    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 .Neqo is planned to be integratedin (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.

    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.

    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.

    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.