[KaiserPro]

One thing to note is that using HTTP2.0 for anything other than "this is not how to design high throughput protocols" is unfair.

At the time HTTP2.0's multiplexing was known to be bad for anything other than perfect, low latency networks. I hope this was because people had faith in better connectivity, rather than ignorance of how mobile and non-lan traffic worked.

You should probably at least try QUIC now, but you can get past HOL blocking by having multiple TCP streams. Its super cheap, cheaper than QUIC.

[lxgr]

> you can get past HOL blocking by having multiple TCP streams. Its super cheap, cheaper than QUIC

And also super inefficient, since it duplicates the TLS handshake across streams and uses more resources in the OS and middleboxes (like them or hate them, they're a thing that might throttle you if you go too crazy with connection-level parallelism).

That's on top of very poor fairness at bottlenecks (which is per TCP stream unless there's separate traffic policing).

[KaiserPro]

> since it duplicates the TLS handshake across streams

Depends on your usecase of course. if its something thats only around for a minute, then yeah, but over an hour, makes no difference at all.

QUIC eats more CPU per MB of data than plain TCP/TLS. but that might be solved by more modern offload/kernel optimisations

[tuetuopay]

Even on perfect networks HoL blocking is an issue. If the receiving end of a set of stream blocks on one stream, it ends up blocking the whole connection. One stream stops due to backpressure, all streams stop.

[KaiserPro]

Oh yeah, but thats why HTTP2.0 was flawed from the start.