I cover HTTP/3 in details on my backend engineering course check it out backend.win

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.

Great video! I don't think HTTP/3 will replace the other protocols in all scenarios but it's definitely an interesting addition to the toolbox.

Maybe we should consider not only the time it takes to decrypt QUIC messages, but also the advantages of skipping protocol handshakes(TCP).

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.

Thank you! To establish this encrypted connection should I make request to 443 port with ALPN=http3? Or it works in another way?

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 want to know a ratio btween HTTP vs non-HTTPs such as gRPC, TCP socket, something native apps use.

I'm wondering if eBPF could be a solution to lower the userspace cost of the protocol...

@hnasr

8 ай бұрын

that is a great point! i think it is

HTTP/3 exists big tech: *oh yeah gimmie all of it*

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.

Volume +2

Kernel also consumes CPU

@biswanathdutta4219

8 ай бұрын

Userspace code can evolve faster than kernel code.

@samhadi7972

8 ай бұрын

Yea I think the concern should be the context switching back and forth rather than the kernel code being “faster”

@biswanathdutta4219

8 ай бұрын

@@samhadi7972 kernel bypass techniques will become more popular over time.

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!

I thought you can run HTTP/3 and HTTP/2 without encryption, can't you?

@ryanseipp6944

8 ай бұрын

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

@JacobGextrem

8 ай бұрын

@@ryanseipp6944 Thank you, that makes sense

@hariharasudhans

3 ай бұрын

HTTP/2 you can. HTTP/3 you can't ask most of the encryption is done at QUIC layer and it's mandatory there.