Hacker News Reader

Comment by _ache_ | Hacker News Reader

I remember been bashed on HN saying that HTTP is hard. Yet, I saw non-sens here in the comment about HTTP. The whole article is good but:

> HTTP/2 is fully encrypted, so you need all your application servers to have a key and certificate

Nope. h2c is a thing and is official. But the article is right, the value HTTP/2 provides isn't for LAN, so HTTP 1.1 or HTTP/2 it doesn't matter much.

HTTP/3 however, is fully encrypted. h3c doesn't exists. So yeah, HTTP3 slower you connection, it isn't suited for LAN and should not be used.

BUT if you actually want to encrypt even in you LAN, use HTTP/3, not HTTP/2 encrypted. You will have a small but not negligible gain from 0-RTT.

View on HN

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.

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.

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.

You are right my last sentence was an approximation. The gain of H3 over H2 is theoretical not practical.

> 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.

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.

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, …?)

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.

https://docs.kernel.org/networking/tls-offload.html

https://news.ycombinator.com/item?id=41890784

Reply on news.ycombinator.com