45 ms·
Since QUIC is UDP based, there are performance issues that become apparent at higher rates. In TCP, a single write can write a large amount of data. You can e
by tomohawk 3y ago
Since QUIC is UDP based, there are performance issues that become apparent at higher rates. In TCP, a single write can write a large amount of data. You can even use sendfile to directly send the contents of a file to a TCP socket, all in kernel space. In UDP, you need to write out data in chunks, and you need to be aware of the link MTU as IP fragments can be very bad news at higher rates. This means an app needs to context switch with the kernel multiple times to send a large amount of data, whereas only a single context switch is required for TCP. There are newish system calls such as sendmmsg which alleviate the strain a bit, but they are not as simple as a stream oriented interface.
The QUIC implementations are primarily in user space, so you end up with multiple QUIC implementations in whatever language on any given system.
Hopefully Linux will add a QUIC kernel implementation that will bypass and overcome the traditional UDP shortcomings in the current stack.
- BitPirate 3y agoIsn't the syscall overhead solved by GSO and GRO?
- tomohawk 3y agoNot necessarily. With GSO, you can send near 64K datagrams, which will then get split into MTU sized datagrams in the driver or on the card. But if you're sending a 1G file, that's a lot of 64K writes. And then you have to consider what is seen on the other end. Is GRO configured on all the endpoints these datagrams are going to? They won't necessarily see those near 64K datagrams, but lots of smaller ones.