IIRC even UDP isn't ideal, the reason for choosing it over making a brand new protocol was to avoid network devices like routers dropping packets that they wouldn't recognize.
WebSockets is just an abstraction over a reliable protocol (TCP), therefore, WebSockets could theoretically work over QUIC too.
Unfortunately today's internet has needed to be a continuum of newer stuff that still has to work with the older stuff. Such is life.
- SSL and "TCP" handshake are collapsed into a single transaction
- That transaction is worst case 1 network roundtrip, best case (returning user) 0 roundtrips
- Anti-filtering baked in. Quic reveals almost nothing for middleboxes to filter on. There is not yet an accepted solution for encrypting the target server name (SSL SNI) but that's still being worked on AFAIK
- "Modern" congestion control approach, where "modern" means "fuck any TCP connections sharing the link"
This is all based on my brief reading of the QUIC Wikipedia article, so take my knowledge with a grain of salt, but I think that my above summary fits.
Wikipedia at relevant anchor: https://en.wikipedia.org/wiki/QUIC#Background
UDP packets have checksums, its what network switches use to check before sending the packet on or dropping the packet.
Other benefit is UDP doesn't have a window size (buffer). Which is part of the design when computers had ram measured in K instead of GB (Hey my buffer is full, stop). The chatty nature of TCP reduces download speeds across larger physical distances. Its why download managers spin up multiple threads to download part of a file to work around it.
QUIC is basically HTTP2 (bidi frames and keep-alive connections) over (TCP over UDP) with encryption builtin. The cool thing about QUIC also, is the ability to 'lower down' to the UDP layer and skip the control and encryption protocol if you need it. (I just dont know if they will extend this feature to the application level).
WebRTC is SRTP with UDP have hole punching et al. if you want so use UDP but with a whole problems of the UDP approach P2P world already taken care of.
WebSockets works over plain TCP.
QUIC is the more advanced of the protocols and it will probably "take over the world" with time, but it has yet to prove itself.
It probably can be a good fit to the cases where the WebRTC is being used for, but i dont now if Chrome will be ambitious enough to let developers mess with the building blocks of QUIC. If not, it will just become a sink to HTTP3 (a no small feat anyway).
Come on. Networks are extremely FAST by now, TCP or not. It's the silly amount of JS computation pushed to the client that is slow, both in download speed and on the client.
They call this HTTP3, and they shouldn't; it's not HTTP.
If there's a general tuning problem in TCP implementations, the cycle time for getting it fixed should be around 2 years from discovery to all regularly updated machines getting the fix. Given global impact, that seems pretty reasonable to me.