|
|
|
|
|
|
by Lukasa
3625 days ago
|
|
|
This is a real worry, but as with all things the actual behaviour of H2 on lossy networks is more complex than that. TCP's congestion control algorithms don't work that well when you have many TCP streams competing for the same bandwidth. This is because while packet loss is a property of the link, not an individual TCP stream, each packet loss event necessarily only affects one TCP stream. This means the others don't get the true feedback about the lossiness of the connection. This behaviour can lead to a situation where all of your TCP streams try to over-ramp. A single stream generally behaves better on such a link: it's getting a much more complete picture of the world. However, your HOL blocking concern is real. This is why QUIC is being worked on. In QUIC, each HTTP request/response is streamed independently over UDP, which gets the behaviour you're talking about here, while also maintaining an overall view of packet loss for rate limiting purposes. |
|
|
Multiple HTTP connections work better for exactly this reason, because they are 'stealing' bandwidth from streaming video by 'not playing fair'. For example, 6 connections ramping back up bandwidth at 6x the rate of a single connection or sometimes only scaling back on 1/6th of the streams at once.
...which is fine because multiple parallel HTTP connections is usually a browser doing so for short-lived data transfers for active users and it is not the bulk of the data on the network.