4 ms·

My experience as former technical lead of a major HTTP/3 deployment is that while TLS certainly adds CPU overhead, it's by far not as major as the overhead of T

My experience as former technical lead of a major HTTP/3 deployment is that while TLS certainly adds CPU overhead, it's by far not as major as the overhead of TLS on top of TCP is. QUIC in general is far less efficient than TCP+TLS. Very optimized implementations require about 2x CPU for bulk data transfers, more usual ones (and running on operating systems that don't support UDP segmentation offloads) require about 5x the CPU. From that CPU overhead, only a small part is crypto. Most CPU time is spent in the OS networking stack processing the tiny MTU sized packets. In an optimized implementation where crypto has a bigger impact, you might see around 30% CPU time being spent in crypto operations in a profile when using hardware-accelerated AES (chacha20 is worse). Which means one could gain that amount of CPU back for other things in a cryptoless QUIC. However in a less network-optimized deployment it would only be 10%. What I however can understand is people not wanting to deal with the complexity of issuing, deploying and rotating certificates for internal deployments that are already secured by other means like wireguard. It could be a concern - but on the other hand tools like the k8s cert-manager already simplify the process for those environments. And of course one needs to consider whether QUIC is the perfect tool for those environments anyway - plain TCP has lots of strength too.

djbusby 4y ago
What kind of profiler can tell which areas the CPU is burning cycles? Like, just mapping a bunch of known function and timing? Then every "ssl_" function is classified as crypto time? And every "net_" function is networking? (Or something like that?)
- toast0 4y ago
  Intel vTune and AMD uProf, as well as opensource tools like hwpmc for FreeBSD and perf for Linux.
- Matthias247 4y ago
  perf can do the job on Linux. Networking cost will be within callstacks for the system calls that send and receive packets (sendmsg, sendmmsg, recvmsg, recvmmsg). Crypto cost in functions which sound like the crypto primitives being used. They typically won't have ssl_ in the name, because QUIC implementations directly make use of lower-level primitives - that are e.g. exposed by libcrypto/ring/etc. Here's one example of an old profile using Quinn: https://gist.githubusercontent.com/Matthias247/47dc290dde72e2e2f581a114234e8382/raw/c7afb63f0eeae4d3c7f8429d54eb6cdeb47df7f3/8x_gso_memory_opts.svg https://gist.githubusercontent.com/Matthias247/47dc290dde72e... It clearly shows the networking and crypto parts (here using ChaCha20). However don't interpret too much into the actual values in this graph, since the profile is nearly 2 years, uses ChaCha20 instead of AES (much more expensive), and used loopback networking (cheaper than the real thing).
int_19h 4y ago
My concern long-term is that browsers will simply drop other options. And keep in mind that "internal deployments" also include home servers and such, where it all makes even less sense.
- ric2b 4y ago
  It does make sense though, our home networks aren't safe these days when random apps on your phone and random websites on your web browser can just make requests to random hosts inside your network, possibly exploit your router and then snoop on traffic.

djbusby 4y ago

What kind of profiler can tell which areas the CPU is burning cycles? Like, just mapping a bunch of known function and timing? Then every "ssl_" function is classified as crypto time? And every "net_" function is networking? (Or something like that?)

toast0 4y ago
Intel vTune and AMD uProf, as well as opensource tools like hwpmc for FreeBSD and perf for Linux.
Matthias247 4y ago
perf can do the job on Linux. Networking cost will be within callstacks for the system calls that send and receive packets (sendmsg, sendmmsg, recvmsg, recvmmsg). Crypto cost in functions which sound like the crypto primitives being used. They typically won't have ssl_ in the name, because QUIC implementations directly make use of lower-level primitives - that are e.g. exposed by libcrypto/ring/etc. Here's one example of an old profile using Quinn: https://gist.githubusercontent.com/Matthias247/47dc290dde72e2e2f581a114234e8382/raw/c7afb63f0eeae4d3c7f8429d54eb6cdeb47df7f3/8x_gso_memory_opts.svg https://gist.githubusercontent.com/Matthias247/47dc290dde72e... It clearly shows the networking and crypto parts (here using ChaCha20). However don't interpret too much into the actual values in this graph, since the profile is nearly 2 years, uses ChaCha20 instead of AES (much more expensive), and used loopback networking (cheaper than the real thing).

int_19h 4y ago

My concern long-term is that browsers will simply drop other options. And keep in mind that "internal deployments" also include home servers and such, where it all makes even less sense.

ric2b 4y ago
It does make sense though, our home networks aren't safe these days when random apps on your phone and random websites on your web browser can just make requests to random hosts inside your network, possibly exploit your router and then snoop on traffic.