Re:HTTP/2 and HTTP/3 explained
by pi-e-sigma on Thursday March 14, 2024 @07:22AM
(#39702474)
Which is exactly the same in HTTP2/3. You can't forward a stream when it's missing some data.
[ Parent
| on HN ]
Re:HTTP/2 and HTTP/3 explained
by brickteacup on Thursday March 14, 2024 @12:01PM
(#39705670)
Yes, bytes from a *logical* stream need to be delivered in order. But in HTTP2 (3) multiple logical streams are multiplexed on top of one physical TCP (QUIC) connection. In the HTTP2 case this means that a dropped segment from logical stream A will block delivery of subsequent segments from an different logical stream B (which is bad for obvious reasons). QUIC doesn't have this problem, which is a large part of its value proposition.
Re:HTTP/2 and HTTP/3 explained
by pi-e-sigma on Thursday March 14, 2024 @12:13PM
(#39705784)
Except it doesn't work in practice and real world data proves it. Multiplexing streams inside of a single TCP connection don't magically make your data link less prone to dropped packets or high latency.
I am curious of why the kernel does not allow it; there could be an API that gives you fragments of the stream in "events" like {slice: [10000, 10100], data:<blob>} and let the application have a peak preview of future data