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.
Conversation
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.
1
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
How can you stop a lost frame from blocking a future frame like that though? You could make a TCP connection for each stream in the meeting or even more fine-grained, but it's not fine-grained and TCP connections are problematic - they take time to ramp up / stabilize, etc.
WebRTC is SCTP over DTLS over UDP today. Nearly every voice/video application, video game, etc. uses custom protocols over UDP. QUIC has broader goals than trying to be a better TCP implementation, but they are making it do congestion control, etc. in a better way.
1
1
It's not like TCP is something simple / standard. It's got a ton of extensions and variations between operating systems. I always run into this problem when dealing with things that don't deal with it by default like nginx: extrahop.com/company/blog/2.
1
Show replies