Will moving QUIC to kernel make a huge difference? Let us explore this.. today in QUIC the raw UDP packets are copied from kernel receive buffer to user space, then decrypted and parsed by the user process. Because QUIC is a transport protocol it has to implement ACKs/retransmission/congestion control. ACKs are sent from userspace as just another UDP packet (inside it the QUIC ACK) that is copied to kernel send buffer. whereas if QUIC was in kernel, all this logic will be there and the only thing that will be copied to userspace is pure stream data. i also imagine the kernel can do tricks as it does in TCP like segment coalescing to reduce header size because it has more context. plus context switching. i don’t know to be honest it if it will make a huge difference but all the copying back and forth can add up for sure good change.
Yup, there's no free lunch, HTTP3 introduces cpu overhead, but that is ok, you get so much better performance at the network layer that i tis worth paying.
2:30 I think it's important to understand we can push changes in the protocol through a simple browser update. Most of the time. The real issue might be performance of UDP in kernel/hardware-offloading, etc.
That would be great to have a video on HTTP status codes. For now all info available is just that 200 is ok and 404 is not found. But no one talks about the difference between 301 and 302 for example. 304 and a lot of codes that are useful
I don’t share your concerns over processes performance in userspace. It’s easier to get better performance by optimization than by moving a process to kernelspace. I’m surprised you didn’t mention the lack of QUIC support in regular modern Linux server distributions, as the OpenSSL project still hasn’t implemented it yet. No soup for you on Linux, unless you’re prepared to self-compile your crypo-libs. So that’s another reason for slow adoption.
great content, however the microphone picks up constant banging vibrations and it really is painful for those that are sensitive to that sort of thing, otherwise thanks!
HTTP/2 allows for non-TLS connections. Normally ALPN negotiates HTTP/2 when the TLS connection is established, but there's a special string that indicates HTTP/2 when not connecting with TLS. QUIC on the other hand requires encryption, and thus so does HTTP/3
Considering that a budget phone has octa-core cpu nowadays which costs like 200$ and the fact that in most of the world the isp speed is still crap like 20mbs, its probably a good bargain to trade off the cpu usage. Coz atm the only bottleneck is the connection speed imo. Even in western Europe in most countries u get a 20-30mbs furthermore its expensive 🫰 While the cpu/ram cost nothing
