4 ms·
The article states: >"In HTTP/2, the single connection carries hundreds of streams. In this case, when we lose one packet, "one hundred streams are waiting for
by bogomipz 7y ago
The article states:
>"In HTTP/2, the single connection carries hundreds of streams. In this case, when we lose one packet, "one hundred streams are waiting for that one single packet"
Could someone elaborate on how this is worse if all of those streams are part of the some client request? Am I missing something really obvious.
- philwelch 7y agoThey're all between the same client and the same server, but they're not necessarily the same request. If there's only a single request it's no different from HTTP/1.
- bogomipz 7y agoThanks all for the great explanations. I was failing to think about how a browser's opening of multiple TCP connections in 1.1 maps to the multiple streams model of HTTP/2. Cheers.
- stingraycharles 7y agoThey’re all part of the same TCP connection, which means that if a packet gets lost, they all need to wait for this packet to be retransmitted, even if the data was unimportant for almost all of them.
- dochtman 7y agoAs I understand it, in HTTP 2 there would be one logical stream per request. So in reality, all requests will be blocked on one (or a minority of) particular request for which a packet was lost, which is clearly subopptimal. This problem is known as head of line blocking.
- chrismorgan 7y agoThe difference is that in HTTP/1.1 browsers tended to use up to six TCP connections per origin. On a site that loaded many resources (a.jpg, b.png, c.js, an API call, &c.) from one origin, they were multiplexed across six TCP connections, and so if a packet on one connection was lost, the other five would be unaffected and could continue at full speed. In HTTP/2, all those requests are multiplexed across only one TCP connection per origin (each request becomes an HTTP/2 stream); so now when a packet is lost, all requests in progress are affected, rather than as few as ⅙ of them. If you only ever make one request at a time, this difference does not affect you, because only one connection would be used under HTTP/1.1 as well. But this case can make HTTP/2 significantly worse than HTTP/1.1 on low-quality mobile networks.
- the8472 7y agoThey may all be affected, but with selective ACK that means the receiver will still ACK most of the data, the server will notice that one packet was missing via SACK, resend it along with even more new data and all you got is a larger batch coming in 1RTT later, throughput isn't affected if your congestion controller can distinguish spurious losses from congestion (as BBR does). The problem only snowballs when future requests will only be made depending on previous data.
- mnarayan01 7y agoThe other requests are still taking the latency hit.
- the8472 7y agoSure, but they were parallel requests in the first place, so in terms of wall time you're still only taking the latency hit once. And if they're larger in aggregate than the connection's BDP some of them would only have finished by the time that it has recovered from the loss anyway. So... it's complicated. I'm not saying that HoL is a non-issue and that TCP is perfect. It's just that you're not eating the latency penalty N times and for anything that is dominated by throughput rather than latency it's even less relevant.