3 ms·
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 multiple
by KaiserPro 1y ago
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 1y ago> 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 1y ago> 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 1y agoEven 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 1y agoOh yeah, but thats why HTTP2.0 was flawed from the start.