3 ms·

I would not use http/3 for lan. Even the latest Linux kernels struggle with it. Http/1 aka TCP has fully supported encryption and other offload support. UDP con

by gmokki 2y ago

I would not use http/3 for lan. Even the latest Linux kernels struggle with it. Http/1 aka TCP has fully supported encryption and other offload support. UDP consumes still much more CPU for same amount of traffic.

_ache_ 2y ago
Do you have source for that? I'm very interested. There is no technical reason for UDP to be slower than TCP (at CPU level). The only field that is computed in UDP is checksum and the same exists in TCP and it must be recomputed each time someone actually re-route the packet (eg: bridge to VM) since TTL is decreased. So I doubt your assertion. _____ Writing my comment I understood what your are talking about. There is a bunch of encryption done at user mode in HTTP/3 that doesn't need to be done in user mode. In HTTP/2 it was sometime done in kernel mode (kTTL), so was quicker. The slowness comes for the CPU needed it to be copied out of kernel mode. I didn't follow the whole story so I trust you on this.
- 0x457 2y ago
  https://docs.kernel.org/networking/tls-offload.html https://docs.kernel.org/networking/tls-offload.html
- SahAssar 2y ago
  Encryption is one thing (if you run kTLS which is still not done in most manual setups) but the much bigger IIRC is how much of the networking stack needs to run in userspace and has not been given the optimization love of TCP. If you compared non-kTLS h2 with non-kTLS h3 over a low-latency link the h2 connection could handle a lot more traffic compared to h3. That is not to say that h3 does not have its place, but the networking stacks are not optimized for it yet.
  - _ache_ 2y ago
    You are right my last sentence was an approximation. The gain of H3 over H2 is theoretical not practical.
- koakuma-chan 2y ago
  https://news.ycombinator.com/item?id=41890784 https://news.ycombinator.com/item?id=41890784
- eqvinox 2y ago
  > There is no technical reason for UDP to be slower than TCP (at CPU level). The technical reason is 30+ years of history of TCP being ≥90% of Internet traffic and services. There's several orders of magnitude in resources more spent to make TCP fast starting at individual symbols on Ethernet links all the way up into applications.
  - _ache_ 2y ago
    That is not a technical reason. And no. It doesn't work like that. UDP is quicker than TCP. It's not like 40 years of history will change that.
    - eqvinox 2y ago
      If you're so sure of this, why did you even ask to begin with? (Also, what is your definition of "quick"? I have no association for that particular wording, are you referring to achievable thruput, CPU load, latency, congestion control, …?)
      - _ache_ 2y ago
        Are you a troll? The question was about H1 quicker than H3, and the OP explains the difference by saying it was TCP quicker than UDP, which is not a reasonable explanation, so I asked for source. But it was all about encryption (and only encryption) and how it was handled within the kernel, and I understood re-reading the first comment (before event sending mine). Here "quicker" was about CPU load and well defined. Please re-read too.

by gmokki 2y ago

_ache_ 2y ago

Do you have source for that? I'm very interested. There is no technical reason for UDP to be slower than TCP (at CPU level). The only field that is computed in UDP is checksum and the same exists in TCP and it must be recomputed each time someone actually re-route the packet (eg: bridge to VM) since TTL is decreased. So I doubt your assertion. _____ Writing my comment I understood what your are talking about. There is a bunch of encryption done at user mode in HTTP/3 that doesn't need to be done in user mode. In HTTP/2 it was sometime done in kernel mode (kTTL), so was quicker. The slowness comes for the CPU needed it to be copied out of kernel mode. I didn't follow the whole story so I trust you on this.

0x457 2y ago
https://docs.kernel.org/networking/tls-offload.html https://docs.kernel.org/networking/tls-offload.html
SahAssar 2y ago
Encryption is one thing (if you run kTLS which is still not done in most manual setups) but the much bigger IIRC is how much of the networking stack needs to run in userspace and has not been given the optimization love of TCP. If you compared non-kTLS h2 with non-kTLS h3 over a low-latency link the h2 connection could handle a lot more traffic compared to h3. That is not to say that h3 does not have its place, but the networking stacks are not optimized for it yet.
- _ache_ 2y ago
  You are right my last sentence was an approximation. The gain of H3 over H2 is theoretical not practical.
koakuma-chan 2y ago
https://news.ycombinator.com/item?id=41890784 https://news.ycombinator.com/item?id=41890784
eqvinox 2y ago
> There is no technical reason for UDP to be slower than TCP (at CPU level). The technical reason is 30+ years of history of TCP being ≥90% of Internet traffic and services. There's several orders of magnitude in resources more spent to make TCP fast starting at individual symbols on Ethernet links all the way up into applications.
- _ache_ 2y ago
  That is not a technical reason. And no. It doesn't work like that. UDP is quicker than TCP. It's not like 40 years of history will change that.
  - eqvinox 2y ago
    If you're so sure of this, why did you even ask to begin with? (Also, what is your definition of "quick"? I have no association for that particular wording, are you referring to achievable thruput, CPU load, latency, congestion control, …?)
    - _ache_ 2y ago
      Are you a troll? The question was about H1 quicker than H3, and the OP explains the difference by saying it was TCP quicker than UDP, which is not a reasonable explanation, so I asked for source. But it was all about encryption (and only encryption) and how it was handled within the kernel, and I understood re-reading the first comment (before event sending mine). Here "quicker" was about CPU load and well defined. Please re-read too.