denoland / deno

A modern runtime for JavaScript and TypeScript.
https://deno.com
MIT License
94.45k stars 5.24k forks source link

QUIC & HTTP/3 support #1558

Open ozyman42 opened 5 years ago

ozyman42 commented 5 years ago

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.

ry commented 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)

xin-hao-awx commented 5 years ago

Maybe we can also consider https://github.com/cloudflare/quiche

trivikr commented 5 years ago

Existing implementations of QUIC: https://github.com/quicwg/base-drafts/wiki/Implementations

The ones (under active development) in Rust:

95th commented 4 years ago

quiche seems to expose only mio based non-blocking API and not an async API.

cretz commented 4 years ago

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.

akshatagarwl commented 4 years ago

@ry Is anyone working on this issue? I could give this a shot. Can't give any guarantees though.

kitsonk commented 4 years ago

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.

fimbault commented 4 years ago

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

kitsonk commented 4 years ago

Even though #3995 came after this one, let's close it in lieu of #3995 as it is more comprehensive.

balupton commented 3 years ago

Other links that may be of interest:

waldyrious commented 3 years ago

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.

rektide commented 2 years ago

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.

ahmadkakarr commented 1 year ago

when http/3 can be implemented in deno?

trusktr commented 10 months ago

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).

devsnek commented 8 months ago

i'm working on an initial implementation of QUIC here https://github.com/denoland/deno/pull/21942

masx200 commented 6 months ago

https://github.com/caddyserver/caddy/issues/5086

masx200 commented 6 months ago

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.

highlyrecommand commented 2 months ago

@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.