Thankfully either side (client or server) can unilaterally refuse to use it, so there are lots of paths to push for deprecation.
Conversation
TLS 1.3 already goes a long way towards that and most people aren't trying to use 0-RTT. There will be even less reason to care about it with QUIC since it puts the TLS handshake into the equivalent of the TCP handshake as long as the certificates aren't too bloated.
2
1
With QUIC, if you don't use bloated certificates, you don't need any extra round trip for TLS anyway without needing the scary 0-RTT feature. 0-RTT is pretty fucking sketchy by the way. It would be safe to use with HTTP GET with how I implement services but not the way most do...
1
1
I'm really not interested in hearing about Google's goofy attempt to replace standard protocols for the sake of making hideously bloated websites less disincentivized by bad ux.
1
1
QUIC refers to the IETF protocol. Google's proof of concept protocol is referred to as gQUIC now. HTTP/3 is essentially HTTP/2 over QUIC with minor changes to deal with running on top of a multiplexed protocol. It won't be any less standard than other protocols.
2
1
Real-time applications like voice / video calls, gaming, etc. use custom protocols implemented on top of UDP. WebRTC uses SCTP-over-DTLS-over-UDP. QUIC is similar concept. WebRTC will move to using QUIC and most custom protocols implemented via UDP will be able to move to it.
1
IETF wanted QUIC to be separate from HTTP/3 because it's useful for other things. That's why they're standardizing it separately. It's not Google's protocol anymore. It has been heavily changed including dropping their much more minimal replacement for TLS and just using TLS 1.3.
1
What about uses other than web servers? Voice / video calls, etc. There's a reason that Zoom and nearly everyone else doing real-time stuff has terrible homegrown protocols. TCP doesn't work well for real-time applications and doesn't handle lossy networks or transitions well.
1
1
That's more defensible, but a big part of the problem is that they're actively trying to saturate your line to get the highest resolution possible. Aim for e.g. 10% of line capacity (thereby not ruining everything else on the network) and TCP works fine.
1
It works fine if it's not a lossy link, and if you don't want multiplexing. Games usually don't need very much throughput at all, but they need very low latency and they want to send a lot of messages in different streams which don't block each other. Many similar applications.
So for example, with a meeting, there's no reason that each different audio/video stream needs to block all of the others. It can be a bunch of streams multiplexed over the same connection. Also, a past frame doesn't need to block receiving future frames, etc. TCP is bad at this.
1
"a bunch of streams multiplexed over the same connection" 🤔
It's almost like that's what TCP/IP does...
2
Show replies