HTTP/3 ready for testing

[Dragana Damjanovic]

Hi all,

HTTP/3 <https://tools.ietf.org/html/draft-ietf-quic-http-32> is a new
protocol based on QUIC (a UDP-based transport protocol) (the QUIC drafts: 1
<https://tools.ietf.org/html/draft-ietf-quic-transport-32>, 2
<https://tools.ietf.org/html/draft-ietf-quic-tls-32>, 3
<https://tools.ietf.org/html/draft-ietf-quic-recovery-32>). The protocol
offers:

-

Better security (it always uses TLS 1.3
<https://tools.ietf.org/html/rfc8446>),
-

Request multiplexing without head of line blocking (this is the main
limitation of HTTP/2),
-

Reduces request latency by allowing clients to send a request to an
already-visited server with zero connection setup delay,
-

Uses modern loss detection and recovery mechanisms,
-

Enable a long-lived connection to migrate across different network paths
(currently not available in our implementation).


Our implementation is ready for testing. Please try it out:

-

update Nightly to the newest version
-

go to about:config and set the "network.http.http3.enabled” to true
-

a restart is not needed


If you find any issue please file a bug under the Core::Networking::Http
component (Bugzilla link
<https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Networking%3A+HTTP>
)

HTTP/3 will be discovered using AltSvc <https://tools.ietf.org/html/rfc7838>
header and frame, therefore Firefox needs to establish a TCP connection and
use HTTP/2 or older version first before discovering HTTP/3. Whether the
protocol is used can be seen in DevTools (a request protocol version will
be HTTP/3) and in about:networking. Some major sites already support
HTTP/3, e.g. google, facebook and youtube.

Our HTTP/3 library is called neqo (“Nee-ko”). The repo can be found here
<https://github.com/mozilla/neqo>. It uses NSS cryptography library. It is
written in Rust which helps make it high performance, reduces the lines of
source code needed, and lowers the potential for bugs leading to security
vulnerabilities.

I am looking forward to your feedback,

Dragana

[James Graham]

On 20/11/2020 16:09, Dragana Damjanovic wrote:

> Our implementation is ready for testing.

What's the interop testing story for HTTP/3? How confident are we that
we won't run into implementation differences that look like web-compat
issues?

Also, what's the priority on enabling other test types over HTTP/3. wpt
has some quic support for WebTransport [1]; is that something that we
should be looking to enable in our test infra?

[1] https://github.com/web-platform-tests/rfcs/blob/master/rfcs/quic.md

[Dragana Damjanovic]

On Fri, Nov 20, 2020 at 6:06 PM James Graham <ja...@hoppipolla.co.uk> wrote:

> On 20/11/2020 16:09, Dragana Damjanovic wrote:
>
> > Our implementation is ready for testing.
>
> What's the interop testing story for HTTP/3? How confident are we that
> we won't run into implementation differences that look like web-compat
> issues?
>

The interop tests look good. They are regularly run:
https://interop.seemann.io/ (some of these tests failed but there are
different reasons for that, not interoperability.)
Performance tests against, some live sites are run regularly as well:
https://arewefastyet.com/linux64/network/overview?numDays=30
We also have a very conservative fallback mechanism that will disable
HTTP/3 on any error.

I am not worried about interoperability and web-compat issues very much,
but at the same time this is a new protocol (Google has shipt this version
of QUIC just recently as well) and it will need more testing on the
internet. New transport protocols are influenced by network
paths(middleboxes, firewalls, routers, etc) and that is out of our control.
Also using UDP as a transport protocol introduces some problems. UDP does
not work on all network paths and for that we have very conservative
fallback mechanisms.

> Also, what's the priority on enabling other test types over HTTP/3. wpt
> has some quic support for WebTransport [1]; is that something that we
> should be looking to enable in our test infra?
>
>

WebTransport is a different protocol proposal. This is not specified yet.
This is not HTTP/3.

dragana



> [1] https://github.com/web-platform-tests/rfcs/blob/master/rfcs/quic.md
>
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[RyanVM]

Have we considered adding HTTP/3 to about:preferences#experimental to make it easier for Nightly testers to opt into?

[Aditya Pratap Singh]

Hello Dragana
I'm curious about this "conservative fallback mechanism" you mentioned. When I looked into Chromium's workings, I realized that the protocol to be used is decided by racing QUIC and TCP jobs. In the event of QUIC's failure, it is marked as broken for some amount of time and then raced again post-expiration of timeout. Is there a similar implementation in Firefox too?

I referred to the QUIC Discovery Doc (https://docs.google.com/document/d/1i4m7DbrWGgXafHxwl8SwIusY2ELUe8WX258xt2LFxPM/) to understand QUIC implementation in Chromium. Does Firefox have a similar documentation as well?