[HN Gopher] QUIC and HTTP/3 Support Now in Firefox Nightly and Beta
___________________________________________________________________
QUIC and HTTP/3 Support Now in Firefox Nightly and Beta
Author : caution
Score : 110 points
Date : 2021-04-16 20:21 UTC (1 hours ago)
(HTM) web link (hacks.mozilla.org)
(TXT) w3m dump (hacks.mozilla.org)
| codetrotter wrote:
| Is anyone else hyped about the possibility of tunneling traffic
| over QUIC?
|
| Public networks in coffee shops and libraries that block outbound
| SSH and outbound Wireguard are the bane of my existence when I am
| traveling and I try to get some god damn work done.
|
| With HTTP/3 most public networks in coffee shops, libraries etc
| are eventually going to allow QUIC. This means UDP tunnels
| masquerading as QUIC traffic, as well as tunneling over QUIC
| itself, is probably going to work. Eventually.
|
| I am cautiously optimistic :)
| cmeacham98 wrote:
| In the meantime, consider trying udp2raw[1], which will allow
| you to fake UDP over TCP (by colluding on both sides of the
| tunnel) and works pretty well on coffee shop WiFi in my
| experience.
|
| 1: https://github.com/wangyu-/udp2raw-tunnel
| achernya wrote:
| We have built a VPN over QUIC, and the core code is open source
| already [0].
|
| We're working on standardizing "IP Proxying" over QUIC as part
| of the MASQUE working group at IETF. So far, we've adopted a
| requirements document [1] and have started work on an
| implementation [2].
|
| [0]
| https://quiche.googlesource.com/quiche/+/refs/heads/master/q...
|
| [1] https://tools.ietf.org/html/draft-ietf-masque-ip-proxy-
| reqs-...
|
| [2] https://tools.ietf.org/html/draft-cms-masque-connect-ip-00
| georgyo wrote:
| Many people have answered your comment, but I don't think any
| of them actually addressed your comment...
|
| If a public access point has a restrictive network policy, then
| QUIC will change nothing. There is nothing that QUIC enables
| that people browsing the web will demand. A user cannot even
| tell if they are using QUIC (or http2) for that matter.
|
| The network operator is either non-technical and does not care
| about QUIC; or technical but trying to actively prevent people
| from using VPN and/or torrenting.
|
| There are many ways to VPN that look like tcp http. tcp over
| tcp is okay if the connection is stable.
| oliwarner wrote:
| If it's a bandwidth issue for them, isn't it more likely
| they'll just block UDP/443?
| legulere wrote:
| Or they just continue blocking UDP and browsers fall back to
| http1/2
| CameronNemo wrote:
| Can you not disguise the wireguard tunnels as something else?
| E.g. just set the destination/listen port as 443/UDP? Or 53,
| 123.
| judge2020 wrote:
| While not usual for places like coffee shops, i've seen
| cruises and hotels do DPI since probably a sizable amount of
| revenue can be generated from fast wifi access or by
| unblocking all sites.
| CameronNemo wrote:
| Yep that is always an issue. Not sure how a hypothetical
| QUIC tunnel would avoid that, though. Would appreciate any
| info you can provide on mitigating deep packet inspection
| blocking techniques.
| mjsir911 wrote:
| We're already most of the way there with SSTP, although it's a
| bit fiddly with SNI
|
| https://en.wikipedia.org/wiki/Secure_Socket_Tunneling_Protoc...
| codetrotter wrote:
| Tunneling over TCP has problems. (The article you linked
| mentions this as well.)
|
| This TCP meltdown problem is especially prominent in public
| WiFi networks where they often like to dramatically limit the
| bandwidth to the clients that connect to their network. So
| UDP tunneling will work much better there.
|
| That's why I am excited about maybe finally having tunneling
| over UDP be a reality on public networks in coffee shops and
| libraries in the future thanks to HTTP/3 and QUIC where
| historically the mentioned kinds of networks have often been
| blocking basically all UDP traffic except DNS.
| aduitsis wrote:
| Hello, it's not like every venue will be hard pressed to
| accommodate QUIC quickly, right?
|
| Please consider that today, in 2021, IPv4 is still the only
| thing supported in many venues. It took almost 20 years for
| IPv6 to become universally supported by Operating Systems,
| ISPs, providers, etc, but still you have to have IPv4.
|
| And I dare say IPv6 was much much more critical to have than
| QUIC.
|
| But having said all that, what is there to allow in QUIC? Isn't
| it just using UDP?
| livre wrote:
| > Hello, it's not like every venue will be hard pressed to
| accommodate QUIC quickly, right?
|
| If browsers fall back to regular HTTPS when the QUIC
| connection fails there won't be much incentive in making sure
| QUIC works or isn't blocked.
| lxgr wrote:
| > Isn't it just using UDP?
|
| Yes, but there's still networks blocking everything but TCP
| 80/443.
| Quekid5 wrote:
| > Hello, it's not like every venue will be hard pressed to
| accommodate QUIC quickly, right?
|
| Your aren't wrong about that, given the amount of fallback
| browsers do, but IPv6 actually required upgrading key pieces
| of hardware at critical points in the infrastructure[0]. Not
| sure if there's any hardware released in the last 10+ years
| that doesn't support it, but who knows?
|
| ... and yes, QUIC is "just UDP".
|
| [0] ... and dare I say: a more compelling _immediate_ use
| case. At the time is was designed the address shortage wasn
| 't actually looking all that dire. It might actually have
| been invented/designed _too soon_... like it solutions to Y2K
| had come out in 1980 or something.
| jk7tarYZAQNpTQa wrote:
| What stops you from tunneling VPN inside TLS, or directly over
| TCP? Something like
| https://github.com/moparisthebest/wireguard-proxy
| saurik wrote:
| I already support VPN over WebRTC in Orchid, and intend to
| support WebTransport (though the premise of that protocol irks
| me a bit) to get unreliable packets over QUIC as these
| standards finish forming.
|
| https://github.com/OrchidTechnologies/orchid
| the8472 wrote:
| TCP is far from optimal for tunneling multiple flows, but you
| can still tweak it a lot by using a recent(ish) linux kernel
| which will allow you to use FQ_CODEL + BBR + NOTSENT_LOWAT to
| reduce loss sensitivity and minimize the excess buffering in
| the presence of bulk flows over the tunnel. Well, and by not
| using SSH for tunneling, since that brings yet another layer of
| flow control. If you're on a fixed-bandwidth connection
| disabling SSR might help too. These are all sender-side
| changes, so you need to control the remote end of the VPN too.
| netflixandkill wrote:
| Been doing wireguard over udp 443 for a long time. Works pretty
| consistently.
|
| Probably take a few years for the low-effort network blocks to
| figure out how to deal with that.
| lxgr wrote:
| Interesting, I wonder if this is because of low effort
| firewall rules (just mirror the TCP settings for UDP) or
| explicitly to allow QUIC.
| netflixandkill wrote:
| Quic has been around long enough that I suspect it's simply
| a common policy for both tcp and udp on 443. If you just
| want to charge for access, rate limiting is easier and
| there is almost never any local person involved in managing
| it.
|
| A lot of VPN blocking isn't a specific, deliberate policy
| choice by the network owner, it comes in from default
| policy options on whatever awful vendor they use. The
| people seriously concerned about outgoing tunnels providing
| access back into protected networks that hides from normal
| packet inspection are a different case.
| api wrote:
| We've looked at QUIC transport for ZeroTier for this reason.
| crypt0x wrote:
| Does someone know if this includes the QuicTransport JS API?
|
| Im still salty that Google scrapped the p2p mode from chrome,
| which could have been a nice alternative for webrtc, too.
| chrissnell wrote:
| What server-side options do we have for QUIC?
| [deleted]
| pgjones wrote:
| Hypercorn a Python ASGI server supports HTTP/3 built on aioquic
| which is a Python library supports QUIC.
|
| (I'm the author of Hypercorn).
| jeffbee wrote:
| Depending on what you want to accomplish, an option is running
| your services in a cloud that supports terminating QUIC on
| their front-end load balancers. Google Cloud does, for example.
| dragonwriter wrote:
| Here's a list of implementations. There's quite a few backend
| (either servers or server libraries.)
|
| https://github.com/quicwg/base-drafts/wiki/Implementations
| ainar-g wrote:
| Do you mean libraries for backend languages, like Go and Java,
| or servers, like Nginx and Caddy? Because for Go there is the
| quic-go module[1], and since Caddy is written in Go, it already
| has (experimental) support for HTTP/3[2].
|
| [1]: https://github.com/lucas-clemente/quic-go
|
| [2]: https://caddyserver.com/docs/caddyfile/options#protocol
| [deleted]
| Denatonium wrote:
| I'd be interested in knowing how QUIC deals with networks where
| an upstream link has a lower MTU than the LAN, and some
| intermediate routers are blocking ICMP.
|
| With TCP, the router would be set up to clamp TCP MSS, but how's
| this going to work with a UDP-based transport?
| Matthias247 wrote:
| Both peers will start with a minimum MTU that is deemed to be
| safe (around 1200 bytes) and will independently start a path
| MTU discovery workflow from there. That allows each side to
| increase the MTU without having a dependency on the other end.
| For path MTU discovery, peers can send PING frames in higher
| MTU datagrams and detect their loss (miss of their
| acknowledgement)
| jeffbee wrote:
| https://tools.ietf.org/html/rfc8899
| ivan4th wrote:
| I have recently improved my rural multi-LTE setup by means of
| OpenMPTCPRouter [1]. MPTCP does a really great job at aggregating
| multiple paths for better throughput and reliability. Problem is,
| QUIC can't do this, and while multipath QUIC exists [2], right
| now it's more of a research project.
|
| I'm afraid I'll have to block UDP/443 at some point to prevent
| browsers from downgrading to 1/3 of available throughput...
|
| [1] https://www.openmptcprouter.com/ [2] https://multipath-
| quic.org/
___________________________________________________________________
(page generated 2021-04-16 22:00 UTC)