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.
Conversation
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.
1
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
If you use assorted OS extensions (TCP_NODELAY is pretty much mandatory for anything interactive - not even close to real time), you can get TCP pretty usable over a very reliable, low latency network. Still not great for real time and it falls apart *really* fast when lossy.