6 ms·
I’m not an expert but QUIC doesn’t seem like enough of an improvement over TCP to warrant replacing it, especially given that it’s even more complex. - 0-RTT h
by coddle-hark 6y ago
I’m not an expert but QUIC doesn’t seem like enough of an improvement over TCP to warrant replacing it, especially given that it’s even more complex.
- 0-RTT handshakes are great but there’s still the problem of slow start.
- QUIC’s congestion control mechanism is pretty much the same as TCP’s and doesn’t perform particularly well over e.g. mobile networks.
- Mandatory TLS means it’s going to be a huge PITA if you ever need to run a quic service locally (say, in a container).
- Having it in user space means there’a a good chance we’ll end up with 100s of implementations, all with their own quirks. It’s bad enough trying to optimise for the three big TCP stacks.
- tootie 6y agoIsn't there an exception explicitly for localhost?
- coddle-hark 6y agoNot that I know of.
- all_usernames 6y ago> Mandatory TLS means it’s going to be a huge PITA Let's Encrypt!
- coddle-hark 6y agoLet’s Encrypt can’t generate certificates for localhost, much less containers accessed via a local network. Sure, you can get anything to work, but it WILL be a huge PITA.
- mahkoh 6y agoLet's Encrypt can generate certificates for your.domain. your.domain can in turn resolve to localhost. I've been using Let's Encrypt for websites behind a VPN for several years.
- coddle-hark 6y agoYes, of course, and that might make sense in a production setting. Those certificates expire after 90 days though, do you really want to have to edit your dns records every 90 days? To run something locally?
- mahkoh 6y agoWhy would I have to edit dns records manually? I have a cron job that tries to renew the certificate once a day. There is no manual work involved.
- coddle-hark 6y agoIn that case you’re using either HTTP or TLS verification, which only works if you have a public static ip/port that LE can access. You can’t do that from behind a NAT without port forwarding and you generally don’t want your local docker machines to be accessible to the internet. Unless your cron script is doing some funky DNS altering, that is.
- mahkoh 6y agoAll of the DNS altering is performed automatically by lego [1] which has support for a large number of DNS providers. [1] https://github.com/go-acme/lego https://github.com/go-acme/lego [2] https://go-acme.github.io/lego/dns/ https://go-acme.github.io/lego/dns/
- coddle-hark 6y agoOh, that’s cool, I hadn’t heard of lego before! But still, you shouldn’t need to buy a domain to do stuff locally on your own device and it adds quite a bit of complexity.
- tialaramex 6y agoThe only thing we care about is that there's just one authoritative name hierarchy, if somebody in the name hierarchy wants to give you a name without selling it, that would be totally fine. I would totally be down with say, the US government issuing citizens with a DNS name under their ccTLD somewhere. Done your tax paperwork in reasonable time? Your name is guaranteed by law to keep working for another year. Maybe 1480219643.ny.citizen-names.us is ugly but it'd satisfy this problem for individuals. Maybe they could bolt on a checkbox, $50 extra to the IRS and you get to pick any as-yet unreserved legal name, or they have rules like for license plates.
- mcqueenjordan 6y agoNo head-of-line blocking is a pretty significant improvement.
- coddle-hark 6y agoYes, but in reality you don’t want your page to load until all above the fold assets are loaded anyway. We went through this a couple of years ago with increasingly complicated techniques to avoid the dreaded “flash of unstyled content”. Head-of-line blocking is only a problem if you’re multiplexing connections. Just open one TCP socket per request and you’ll never have head of line blocking. There are issues with opening multiple TCP sockets of course (mainly Slow Start) but these aren’t insurmountable.
- TravelPiglet 6y agoYou do want to download multiple assets like images in parallel over the same connection since you can’t open that many connections per domain.
- coddle-hark 6y agoThat’s not a fundamental limitation of TCP though. You can theoretically open 4294967296 sockets between two machines (with one IP address per machine) and a beefy machine can handle >1M concurrent connections. They’ve already proposed adding HTTPS and SVCB DNS records for performance, it would be easy enough to implement a ICANTAKEIT record that lets the browser know it’s OK to open as many sockets as it needs.
- CydeWeys 6y agoIt's a bigger lift than just switching from TCP to QUIC though. And there's other reasons you wouldn't want to use as many connections as you have assets to download; each connection has startup overhead.
- 6y ago
- faeyanpiraat 6y agoOr we'll have new tooling which makes it simple to enable SSL locally. Dev and prod should be as similar as possible anyway.
- coddle-hark 6y agoSure, I can create a self-signed certificate and copy it to my docker container and update the app’s config to use it and add it to the system’s certificate store and then add it to every browser’s certificate store every time I need to run something over QUIC locally. And sure, maybe one day there will be a tool that can do a that automatically. But like... why?
- gravypod 6y agoA lot of browsers already expect tls to enable specific features. I've had things break between dev and prod because of a lack of tls on the backend as well. It's also one of those things that once you sort it out it's no longer a problem. Like "why do I need to setup all this complex stuff to manage a dependancy? Just give me your source code and let me `gcc -o binary a.c b.c ....`" In reality once you solve a problem with an ergonomic solution and the solution improves your alignment with production and comes at no real cost it's a win/win/win.
- tialaramex 6y agoMostly browsers require Secure Context rather than TLS, so http://127.0.0.1/ http://127.0.0.1/ which is a secure context is fine.
- johncolanduoni 6y agoBrowsers have for some time behaveD quite differently when using HTTPS vs HTTP, particularly if you’re not navigating to precisely http://localhost http://localhost (e.g. if your dev environment needs multiple domains). In particular a lot of newer browser features will refuse to work, and you won’t be able to see any HTTP/2 specific issues (e.g. header case) either.
- 6y ago
- navaati 6y agoTo be fair the real problem is not mandatory TLS, it’s mandatory WebPKI certs: self-signed certs are not a problem in a local docker container, and is not worse than unencrypted.
- cma 6y agoIsn't there a performance burden?
- OptionX 6y agoSupposedly not (vs TCP/TLS), at least not in the Google implementation (haven't read anything about the IETF version). And with 0-RTT, when it comes out, you gain some performance back anyway by not having to re-handshake on drops.
- cma 6y agoThe comparison would be against TCP with no TLS, since the issue was mandatory encryption.
- loeg 6y agoSome, but maybe less than you think if you're using OpenSSL and a computer less than ten years old (AES-NI and maybe PCLMULQDQ for GCM). Often something else (NIC, network) will be the bottleneck.
- coddle-hark 6y agoYou still need to add those certs to a bunch of different places (browsers use their own certificate stores). More importantly, I don’t think it’s a good idea to teach people to add self signed certs to their certificate stores willy-nilly. Seems like a good way to get pwned.
- a1369209993 6y agoWell, there are other problems (even requiring encryption at all means some low-power clients can't use it because they lack the processing power), but X.509/WebPKI is the main one, followed by ciphersuite proliferation requiring dozens of times as much audited cryptographic code.
- RedShift1 6y agoWhat does QUIC solve then?
- Wohlf 6y agoRemoves the overhead and blocking of TCP while providing redundancy for the packet loss of UDP.
- coddle-hark 6y agoThat’s not quite right. It greatly reduces the handshake time for new connections, but it adds more network overhead (more bytes sent) than TCP. TCP doesn’t “block” any more than QUIC.
- Matthias247 6y agoIt also allows for multiple concurrent encrypted streams while just doing one handshake. HTTP/2 also allowed this, but suffered from head-of-line blocking between those multiplexed connections. Quic streams are independent. One Stream can still make progress if datagrams which contained data for another stream got lost.
- coddle-hark 6y agoMultiple concurrent encrypted streams with a single handshake isn’t much of a win though. N concurrent TLS connections won’t be any slower than a single TLS connection since the requests can be done in parallel.
- tick_tock_tick 6y agoIn a world with variable ping times and packet loss that is a bold lie.
- coddle-hark 6y agoHow so? Surely the variable ping times and packet loss affect both scenarios equally?
- an_opabinia 6y agoAs another user stated, the biggest advantage of QUIC is how much more sense it makes for wireless communications and mobile devices. Mobile networks break TCP connections all the time, it just violates too many useful assumptions of TCP. HTTP/3's WebTransport (i.e. gRPC + sessions) defines a Session far more logically than a TCP Connection + your ad-hoc in-application Session does. The predecessors of WebTransport already appear every everywhere in low-latency and realtime networked applications, like games, chat and video, on mobile devices. Typically that is achieved using UDP + an ad-hoc session management and authentication protocol. Or worse, undoing TCP connections and managing sessions on top of TCP connection breaks (as most dual web + native applications do). Why reinvent that clumsy stuff over and over again instead of having it standardized? TCP is already dead on mobile, for many of the most popular applications people actually use.
- coddle-hark 6y agoMy day job is providing internet connectivity to trains/busses/boats in remote areas over cellular modems. I couldn’t agree more that TCP over mobile networks is a non-starter, I just wish they’d done more than implement TCP over UDP. In terms of mobile performance, QUIC isn’t much better than TCP over a Wireguard VPN.
- Matthias247 6y ago> QUIC isn’t much better than TCP over a Wireguard VPN. Why? One of the main intends of QUIC is imho to be better in this scenarios. E.g. by handling retransmission and loss detection in a different fashion than TCP.
- coddle-hark 6y agoIt handles congestion control slightly differently since it can estimate the Round Trip Time more accurately, but it’s essentially the same ACK based mechanism that TCP uses. The current draft [0] from the QUIC working group basically describes TCP NewReno (the authors say so themselves). [0] https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html
- deleted 6y ago[deleted]
- Aissen 6y ago> - Having it in user space means there’a a good chance we’ll end up with 100s of implementations, all with their own quirks. It’s bad enough trying to optimise for the three big TCP stacks. Big QUIC implementors have all used the interop runner, intended to prevent exactly that: https://interop.seemann.io/ https://interop.seemann.io/ And it’s open source: https://github.com/marten-seemann/quic-interop-runner https://github.com/marten-seemann/quic-interop-runner