Open ozyman42 opened 5 years ago
I agree - would be great - and seems relatively accessible with https://github.com/djc/quinn I’m open to anyone who wants to attempt this. And if someone doesn’t pick it up, I would try myself once a few other things have been taken care of (We still don’t have basic TLS support for example- that should come first)
Maybe we can also consider https://github.com/cloudflare/quiche
Existing implementations of QUIC: https://github.com/quicwg/base-drafts/wiki/Implementations
The ones (under active development) in Rust:
quiche
seems to expose only mio based non-blocking API and not an async API.
From my experience with quiche, it's only the CPU bound parts, you bring your own network IO. I have used it with a Tokio UDP socket and converted it to a modern Rust async futures stream+sink. The library is basically only the hard parts of state machine, parsing, and crypto pieces.
The bigger problem with using quiche is that they require BoringSSL and have multiple times stated they are unlikely to change (see https://github.com/cloudflare/quiche/issues/129#issuecomment-524035205 and https://github.com/cloudflare/quiche/issues/16#issuecomment-460205108). But there is an old PR open yet on hold for OpenSSL so maybe there's hope for rustls.
@ry Is anyone working on this issue? I could give this a shot. Can't give any guarantees though.
Make sure you check out #3995 as it is more comprehensive of an issue (I missed this one when I opened that) and Ry had some thoughts on implementation.
An empirical study on QUIC implementations that's worth reading https://qlog.edm.uhasselt.be/epiq And a summary if you don't have much time https://qlog.edm.uhasselt.be/epiq/images/summary.png
Even though #3995 came after this one, let's close it in lieu of #3995 as it is more comprehensive.
For reference, this issue has been reopened following @ry's comment when closing #3995 (which this issue had been closed as a duplicate/subset of):
HTTP/2 shipped in v1.9.0 (see #9935)
HTTP/3 and QUIC can be discussed in a new issue.
hyper underpins deno's native http extensions. there is hyperium/hyper#1818 for http3 support in the hyper framework. there's an experimental implementation, hyperium/h3.
when http/3 can be implemented in deno?
What's interesting about HTTP/3 is that people will make ESM CDN servers that can server-push module graphs to clients and possibly beat bundlers, and this highly aligns with Deno's vanilla-esm-and-importmaps philosophy. The sooner we have HTTP/3, the sooner we might have even better vanilla ESM support in Deno (and others) where module downloads will be very optimized (f.e. all gzipped and cached from the CDN).
i'm working on an initial implementation of QUIC here https://github.com/denoland/deno/pull/21942
Many of Cloudflare's websites have been blocked.
any update? I found that the https TLS connection of the existing website was attacked by a man-in-the-middle, and the connection was disconnected, and the connection was successful only by using quic "xxxxxxxxxxx.xxxxxxxxxxxxxxxxx.xxxxxxxxx.workers.dev"!
我发现有的网站的https的tls连接被中间人攻击了,连接被断开了,只有使用quic才能连接成功!比如说"xxxxxxxxxxx.xxxxxxxxxxxxxxxxx.xxxxxxxxx.workers.dev".
At present, browsers Firefox, Chrome, and Edge already support HTTP3, and there is also a query of HTTPS type through DNS, and you can find out the server's support for HTTP3.
目前浏览器firefox,chrome,edge都已经支持http3了,还有通过dns查询https类型,可以查到服务器对于http3的支持情况.
I found that Chrome was able to open Cloudflare's workers.dev website, but deno couldn't access workers.dev.
@masx200
Many of Cloudflare's websites have been blocked.
any update? I found that the https TLS connection of the existing website was attacked by a man-in-the-middle, and the connection was disconnected, and the connection was successful only by using quic "xxxxxxxxxxx.xxxxxxxxxxxxxxxxx.xxxxxxxxx.workers.dev"!
我发现有的网站的https的tls连接被中间人攻击了,连接被断开了,只有使用quic才能连接成功!比如说"xxxxxxxxxxx.xxxxxxxxxxxxxxxxx.xxxxxxxxx.workers.dev".
At present, browsers Firefox, Chrome, and Edge already support HTTP3, and there is also a query of HTTPS type through DNS, and you can find out the server's support for HTTP3.
目前浏览器firefox,chrome,edge都已经支持http3了,还有通过dns查询https类型,可以查到服务器对于http3的支持情况.
I found that Chrome was able to open Cloudflare's workers.dev website, but deno couldn't access workers.dev.
Your issue is not related to Deno
, as it is caused by the Great Firewall of China. The Great Firewall is an IDS (Intrusion Detection System) bypass detector that can reassemble TCP packets and then perform struct decode and matching. Additionally, TLS handshake packets are not encrypted, and it contain SNI (Server Name Indication) field. The Great Firewall can easily identify and block subsequent connections. Moreover, I can tell you that the Initial Packet of HTTP/3 (QUIC) is also not encrypted (pseudo-encrypted), so the Great Firewall can potentially recognize and block HTTP/3 connections in future updates.
It would be nice if the Deno standard library had QUIC protocol support out-of-the-box, implemented in Rust underneath. QUIC will likely be the UDP-based alternative to TCP used as the foundation for the Internet Engineering Task Force (IETF)'s upcoming HTTP3 spec. Essentially QUIC is a more efficient implementation of the combined capabilities of TCP and TLS, and a less mature version of QUIC has been used by Google for years in requests from Chrome to its own webservers. Node.js has an open issue for adding in QUIC support, but based on the discussion there I'm assuming that the priority is low for them. They may not understand the significance of adding support.