Before you move to HTTP/3 ...

[@hnasr]

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

[@dario.lencina]

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.

[@hnasr]

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.

[@seonwookim9595]

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

[@swedishguy83]

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.

[@danieljenikovsky9455]

Reading one byte and than switching on it doesn't seem like a lot of "parsing" to do to decide what kind of frame header we are dealing with... even parsing http/2 headers doesn't seem like more work than what you need to do to parse http/1.1 headers? Array/table lookup seems faster than string comparision... maybe the huffman decoding is the most complex part, but I think for what you get size wise it's better than any other non-specific compression. Considering gzip and brotli are used for the body I don't see, how this part of http/2 would be the bottleneck of anything.

[@autohmae]

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.

[@kirillzlobin7135]

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

[@vladimir_v_it]

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

[@toniferic-tech8733]

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.

[@hkupty]

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

[@hnasr]

that is a great point! i think it is

[@tak68tak]

i want to know a ratio btween HTTP vs non-HTTPs such as gRPC, TCP socket, something native apps use.

[@Serpher1]

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

[@biswanathdutta4219]

Kernel also consumes CPU

[@biswanathdutta4219]

Userspace code can evolve faster than kernel code.

[@samhadi7972]

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

[@biswanathdutta4219]

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

[@kanemetal]

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!

[@JacobGextrem]

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

[@ryanseipp6944]

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]

@@ryanseipp6944 Thank you, that makes sense

[@hariharasudhans]

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

[@DejayClayton]

Volume +2

[@MrJloa]

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