Comment by austin-cheney
4 days ago
Here is a Google Chrome discussion about it from 2018: https://groups.google.com/a/chromium.org/g/proto-quic/c/pAQz...
Here is a quick overview (undated) from Google about it: https://peering.google.com/#/learn-more/quic
The phrase in that last one is: "multiplexing without head of line blocking". If you search for that phrase you will get a bunch of results. The browser is an extremely limited interface with regards to transmission, so the solution in the browser is always open more sockets. However, on the server, the advantages are huge.
You have to understand that multicast is OSI layers 2, 3, and 4. Its layer 2 because it uses a NIC as a local identifier for management apart from other multicast sockets available, UDP and TCP are layer 4 protocols, and it also takes on some layer 3 capabilities for congestion management. This is where the CPU advantage comes in, because you are offloading some of the traffic processing elsewhere in the stack and to network devices, like switches/routers.
Yes, Google has said that part of the motivation was reducing CPU load but I cannot remember where I saw that.
I don't understand the conflation of multiplexing and multicasting. Are we talking about the same multicasting? (https://en.wikipedia.org/wiki/IP_multicast)
Regarding QUIC CPU load, at least as of a year or two ago it's demonstrably greater then TCP+TLS. Even Google's own numbers showed higher server-side load of up to 10%, IIRC. QUIC has to do all the same work (QUIC libraries embed the same congestion control and stream management logic as TCP, even using slightly modified versions of BBR, CUBIC, etc), and then some. More over, both TCP stream management and TLS are often offloaded to the NIC, and QUIC support isn't nearly as mature there. Even with vanilla NICs, high-performance application servers use kTLS. Unless your QUIC userland stack is DMA'ing raw packets directly to and from the NIC, QUIC is doing more work.