[meta] QUIC support
Categories
(Core :: Networking, enhancement, P3)
Tracking
()
People
(Reporter: mt, Unassigned)
References
(Depends on 37 open bugs, )
Details
(Keywords: feature, meta, parity-chrome, Whiteboard: [necko-backlog])
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Firefox/37.0 Build ID: 20150415140819 Steps to reproduce: The official website of QUIC: https://www.chromium.org/quic The source code of QUIC: https://chromium.googlesource.com/chromium/src/net/+/master/quic/
Updated•9 years ago
|
Comment 1•9 years ago
|
||
Informational RFC Draft: https://tools.ietf.org/html/draft-tsvwg-quic-protocol
Comment 2•9 years ago
|
||
Patrick, what's the opinion of the networking team on that?
Comment 3•9 years ago
|
||
To anyone that read any QUIC docs a long while ago: they've made drastic improvements to completeness and readability. For a long while the documentation did not look like something that was practical to try to implement from.
Comment 4•9 years ago
|
||
(In reply to [:fabrice] Fabrice Desré from comment #2) > Patrick, what's the opinion of the networking team on that? userspace based transport is an incredibly important area of interest. Personally, its probably my top interest right now and its strategically important for Mozilla as part of Internet evolution. It allows us to deploy what are effectively L4 upgrades in an era when OS stack updates to TCP are becoming a an ossified bottleneck to things like transport security, effective network utilization, and fault tolerance. quic deserves credit for pushing forward the state of the art, and has shown good results with the specific case of streaming media on a well distributed CDN. We eagerly look forward to working with goog and engaging with other interested parties to develop an open standard in this space that is suitable for a broad range of use cases and operators. Informational drops of evolving packet formats are welcome contributions on the road to this goal, but they don't reach the bar on their own.
May the following library help? https://github.com/devsisters/libquic
Comment 6•9 years ago
|
||
YouTube serves video to Chrome over QUIC. A contact at YouTube says, "QUIC has worked out pretty well for Chrome. Improved things across the board for Chrome and Android."
Updated•8 years ago
|
Comment hidden (spam) |
Updated•8 years ago
|
Updated•8 years ago
|
Comment 8•7 years ago
|
||
If this is implemented, we should ensure that it's accessible to WebExtensions webRequest APIs. https://blog.brave.com/quic-in-the-wild-for-google-ad-advantage/ "AdBlock Plus, uBlock Origin, and other extensions cannot block QUIC requests. Recommended best practice is to disable QUIC from the chrome://flags/ URL."
Comment 9•7 years ago
|
||
re comment 8 - the protocol should not be a problem for any sensible content API. Just make sure they are defined in terms of content and scheme and not protocol. There is nothing about quic that would make it harder to implement for than than say http/2 (which also does not have its own scheme - they both use https://). If the webextension gets defined in terms of TCP or something then that would be a problem - but I cannot see a reason to do that.
Comment 10•7 years ago
|
||
Regarding that specific blog post in comment 8, there was a huge twitter thread about it: https://twitter.com/bcrypt/status/856886044066590721 It seems maybe the confusion is due to QUIC pre-connects being allowed even if the actual requests are blocked by webRequest: https://bugs.chromium.org/p/chromium/issues/detail?id=715140#c11 Also, chrome has some special whitelisting of google domains that bypass webRequest that muddies the waters: https://bugs.chromium.org/p/chromium/issues/detail?id=715184
Comment 11•7 years ago
|
||
specifically protocol-independent pre-connects are not impacted by webRequest (which seems right to me fwiw). Its not a QUIC issue - same would apply to other transports. And the whitelist thing certainly sounds undesirable, but again that's a chrome implementation issue independent of transport (i.e. turning off quic doesn't make the whitelisted requests visible to the ad blockets.) it seems possible that the nascent state of quic tooling made it harder for the bloggers to correctly diagnose the bytes they were seeing. Time and standards will fix that problem.
Updated•7 years ago
|
Comment 12•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Comment 13•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Comment 14•6 years ago
|
||
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Comment 15•6 years ago
|
||
Dirkjan Ochtman (already CCed on this bug) mentioned on Twitter today that he published the first version of his Rust crate (quinn) that implements QUIC: https://crates.io/crates/quinn We probably couldn't ship it as-is because it uses ring / rustls, but it's possible it could be modified to swap those implementations to use NSS by way of wrapper crates in Firefox.
Comment 16•6 years ago
|
||
I actually emailed Dragana (the current Networking module owner) about this recently, it appears she would prefer to stick to the mozquic implementation that Patrick and she have been working on, on the premise that it will be hard to integrate the Rust code into the Gecko environment (she mentioned NSPR). We'd be happy to bring up some traits to abstract over TLS implementations -- although in the end, I think that Gecko adopting rustls would be a much more interesting long-term strategy than doing NSS bindings. Isn't this exactly the kind of thing Rust is better at?
Comment 17•6 years ago
|
||
> I think that Gecko adopting rustls would be a much more interesting long-term strategy than doing NSS bindings
Changing TLS provider from NSS to something else is a much bigger question than "just" quic (and I wouldn't be surprised if there's already a bug filed about that with a very long comment section), but it also seems totally unlikely (and wrong) that a quic implementation for Firefox would use a different TLS 1.3 provider than the rest of necko/gecko.
Comment 18•6 years ago
|
||
Daniel: I agree that these are largely orthogonal issues, which is why I mentioned that we'd be happy to abstract over TLS implementations in our QUIC implementation if that will help unblock this strategy. (BTW, searching Bugzilla for rustls results in Zarro Boogs for now.)
Comment 19•6 years ago
|
||
Regardless of where we start for QUIC support, our basic policy here is that Firefox should use a consistent TLS 1.3 implementation, which, at least for now, means NSS.
Comment 20•5 years ago
|
||
I considered modifying this to "HTTP/3 support" given that is the only current use case, but I realized that there are a few differences between HTTP/2 and HTTP/3 other than QUIC. (Some of which is just bypassing HTTP/2 flow control routines to calls into quic.) Should that be a separate bug, or just roll it up into this one since it's all part of the same push?
Comment 21•5 years ago
|
||
I believe HTTP/3 support should be a separate bug, depending on this one.
Updated•5 years ago
|
Comment 22•5 years ago
|
||
Updated•5 years ago
|
Comment 23•5 years ago
|
||
Couldn't help myself.
Comment 24•5 years ago
|
||
Excuse me, sorry for the intrusion.
"Initial support was added in Chrome 29 and Opera 16, and in LiteSpeed servers. Chrome support expanded this month, but the bigger news is Cloudflare making the protocol generally available for its customers."
Link:
https://www.zdnet.com/article/cloudflare-google-chrome-and-firefox-add-http3-support/
Thanks...
Comment 25•5 years ago
|
||
Excuse me, sorry for the intrusion(again).
There is this project in GO:
https://github.com/lucas-clemente/quic-go
Thanks!
Comment 26•4 years ago
|
||
INFO: currently that is a problem with QUIC/HTTP3 because some functionality in neqo has changed and necko has not adapted to it. I am working a solution. The problem can be experience that http3 connection will never be closed and will enter a busy wait state.
Comment 27•4 years ago
|
||
blog.cloudflare.com/how-to-test-http-3-and-quic-with-firefox-nightly/
when you enable network.http.http3.enabled to true >slows down Internet connect and request stopped
Comment 28•4 years ago
|
||
(In reply to artymka1 from comment #27)
blog.cloudflare.com/how-to-test-http-3-and-quic-with-firefox-nightly/
when you enable network.http.http3.enabled to true >slows down Internet connect and request stopped
¡Hola!
I'm sorry to learn that enabling HTTP/3 on your Nightly has negatively impacted performance.
Could you please elaborate on what exactly do you mean by "slows down Internet connect and request stopped"?
Could you please share URL(s) of where the slow down is observed and how exactly it manifests?
¡Gracias!
Alex
Comment 29•4 years ago
|
||
¡Hola Dragana!
Thanks so much for all of your work on HTTP/3 on Firefox!
Lazy Saturday so I was again testing the servers listed at https://bagder.github.io/HTTP3-test/ on today's Nightly...
Some work but I noticed that all of these fail with the initial request showing "Blocked" on the "Transferred" column on the 1st request in the "Network" tab of the Developer Tools:
https://quic.tech:8433/
https://pgjones.dev:4433/
https://f5quic.com:4433/
https://nghttp2.org:4433/
These fail with the initial request showing "0 B" on the "Transferred" column on the 1st request in the "Network" tab of the Developer Tools:
https://test.privateoctopus.com:4433/
https://fb.mvfst.net:4433/
The rest of test servers seem to work.
Are these known bugs? If not, are these worth filing?
¡Gracias!
Alex
Comment 30•3 years ago
|
||
🎉 QUIC is finalized and standardized 🎉
https://www.ietf.org/rfc/rfc9000.html
Comment 31•2 years ago
|
||
Redirect needinfos that are pending on inactive users to the triage owner.
:dragana, since the bug has recent activity, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Updated•2 years ago
|
Description
•