2 ms·
Is there a "can I use" for networks/middleboxes/etc and the problems that arise with them, that talks about the real-world aspects of trying to use QUIC univers
by JoshTriplett 5y ago
Is there a "can I use" for networks/middleboxes/etc and the problems that arise with them, that talks about the real-world aspects of trying to use QUIC universally?
I'd love to use QUIC between a (non-browser) client and server for which both ends are code I've written, without having to have fallbacks to HTTP/1.1 or HTTP/2. (Among other things, I love the idea of just establishing one connection and using it for two-way communication, without worrying about things like WebSocket.)
However, the client also needs to run in random places, and while it doesn't necessarily need to support hostile networks, it does need to support broken networks, which to a first approximation can be similar.
Are there statistics available for whether and how often QUIC (or more generally UDP) works with:
- Random ISPs of varying quality
- Cell data connections
- Shops and airports and similar, which commonly use captive portals and try to intercept traffic when they shouldn't, and come pretty close to being hostile networks
- Vaguely reasonable corporate networks, that aren't trying to block QUIC but might do so through misconfiguration or through some misguided policy put in place for unrelated reasons (e.g "our firewall rules are written about TCP and just drop all UDP and ICMP, and people complain but nobody with the power to change it")
- Somewhat less reasonable corporate networks, that force everything through a proxy and may require things like CONNECT-UDP or SOCKS, but still aren't actively trying to block QUIC
I'm hoping that efforts like fly.io's userspace wireguard stack (which uses UDP) might have data here.
I'm specifically not asking about the case of networks that are actually trying to be hostile (to QUIC or otherwise), both because such networks may break any number of things including TLS or WebSockets, and because I'd like to avoid restarting the recurring discussion about whether QUIC/etc are a conspiracy to disempower network administrators. I'd love to know the statistics there too, though, if they're available.
I'm also curious about the best-known method to reliably and efficiently tunnel QUIC out of a network within a client, for the purposes of separating always-QUIC logic from weird-network-handling logic. Does it make sense, for instance, to have a standard way to tunnel a secure QUIC connection through an insecure TCP connection?
- benmmurphy 5y agoi think tunnelling quic over TCP might run into the same problems you have when tunnelling TCP/IP over TCP. if you have two congestion algorithms running then you get weird performance issues. http://sites.inka.de/~W1011/devel/tcp-tcp.html http://sites.inka.de/~W1011/devel/tcp-tcp.html
- JoshTriplett 5y agoAbsolutely. But if it's only needed on a small fraction of networks, it might still be worth doing in order to write code that can otherwise assume QUIC.
- benmmurphy 5y agoif you control the client/server in these situations in might be worth just using HTTP/2 instead of QUIC for these networks. just write your protocol assuming 'streams' exist and then have a HTTP/2 and a QUIC implementation. this is what cloudflare does with their cloudflared tunnel.
- Matthias247 5y agoThe are statistics. But those are mostly available for teams which are currently running quic in production at large scale and see the success and fallback rates. Roughly it works for > 90% of users, and you might be able to add more 9s depending on the region. Buts as you said the details are tricky, because there’s many reasons for it to fail. Network ACLs where either UDP is totally blocked or certain ports (like 443) are the obvious ones. But we’ve also experienced other issues where eg VPN setups didn’t support the minimum required MTU size for Quic. The recommendation to deal with situation where it does not work are the fallbacks you mentioned. For HTTP, both clients and servers are still expected to support lower versions for both interoperability and reliability. For other use cases creating plain TCP/TLS connections can be a fallback - even if it’s one per stream. Or running one of them and another multiplexing layer like yamux on top. I wouldn’t recommend tunneling quic over tcp or things alike - this might end up in flow control and congestion control mechanisms fighting having bad interactions and leading to poor performance. Quic assumes an unreliable datagram based transmission layer, and having a reliable layer below it will mean retransmission of data which is no longer required by the quic layer.