5 ms·

In HTTP/2, because all the streams are muxed over a single TCP connection, packet loss really screws things up - every stream grinds to a halt. It is worse tha

In HTTP/2, because all the streams are muxed over a single TCP connection, packet loss really screws things up - every stream grinds to a halt. It is worse than HTTP/1.x in that case. I observed it myself when Fastmail was having some networking troubles - one response not making it through caused every other request to stall indefinitely. HTTP/3 being over UDP will hopefully fix that, while keeping the benefits of HTTP/2.

baybal2 6y ago
Yes, it being muxed into a single TCP stream was marketed as an advantage originally, as for almost all mainstream OSes, and network hardware, handling fever TCP connections faster is easier than more more slower connections. Even if a packet loss was to occur, it would still have a net benefit over pounding a CDN with countless individual requests.
- vbezhenar 6y ago
  Problem with multiple TCP connections is slow TCP startup. When TCP connections are established and "warmed up", multiple TCP connections are almost always work faster and more reliable. That was exploited back in the day by download managers which opened multiple connections to the save resource and managed to significantly increase download speed.
  - derefr 6y ago
    > That was exploited back in the day by download managers which opened multiple connections to the save resource and managed to significantly increase download speed. Even back then, that wasn't anything to do with multiple TCP connections being fundamentally faster somehow. The speed increase achieved by download managers comes down to: 1. DNS resolution round-robin-ing you to different CDN nodes, such that you're actually making requests to different hardware that each has its own NIC to separately saturate; where if the each server NIC can do 1Mbps, and your link can do 2Mbps, then you need two parallel chunk downloads from separate servers to saturate your link. (This is the same fundamental reason downloading e.g. an OS installer through a torrent is usually faster than downloading it through HTTP from the OS maker's CDN.) 2. Intentional per-connection download-rate throttling applied by many servers (especially those of "download sites" like CNet, which "back in the day" were one of the main places people would experience large downloads); where making multiple concurrent HTTP range-requests to the server at once was a way to bypass the server's throttling. You don't see this advantage any more, as these days the servers of "download sites" have enough smarts to dynamically aggregate downlink quota between nodes in a table keyed by peer IP, such that N concurrent downloads from the same site are always each throttled to 1/Nth the rate.
    - vbezhenar 6y ago
      Multiple TCP connections might increase speed even to single source because of the following reasons: 1. TCP connection increases speed gradually over time until it hit some bandwidth limit. So if you open 10 connections, you'll hit that limit faster. 2. Rare packet drop will drop connection speed and it'll take some time to restore that speed on a given connection. With multiple simultaneous connections and rare drops only one or two connections will experience that speed drop, while other connections might even compensate that with increased speed. So if your connection is flawless, it does not make sense. Otherwise it might make sense.
    - iso947 6y ago
      Back then tcp window scaling wasn’t widely supported
folmar 6y ago
You really should get a Selective ACK aware OS. Even Windows 2000 supports it.
fulafel 6y ago
Note that single lost packets only cause a delay related to a retransmission, but they don't trigger congestion control. This delay is even smaller than RTT due to https://en.m.wikipedia.org/wiki/TCP_congestion_control#Fast_retransmit https://en.m.wikipedia.org/wiki/TCP_congestion_control#Fast_...

baybal2 6y ago

Yes, it being muxed into a single TCP stream was marketed as an advantage originally, as for almost all mainstream OSes, and network hardware, handling fever TCP connections faster is easier than more more slower connections. Even if a packet loss was to occur, it would still have a net benefit over pounding a CDN with countless individual requests.

vbezhenar 6y ago
Problem with multiple TCP connections is slow TCP startup. When TCP connections are established and "warmed up", multiple TCP connections are almost always work faster and more reliable. That was exploited back in the day by download managers which opened multiple connections to the save resource and managed to significantly increase download speed.
- derefr 6y ago
  > That was exploited back in the day by download managers which opened multiple connections to the save resource and managed to significantly increase download speed. Even back then, that wasn't anything to do with multiple TCP connections being fundamentally faster somehow. The speed increase achieved by download managers comes down to: 1. DNS resolution round-robin-ing you to different CDN nodes, such that you're actually making requests to different hardware that each has its own NIC to separately saturate; where if the each server NIC can do 1Mbps, and your link can do 2Mbps, then you need two parallel chunk downloads from separate servers to saturate your link. (This is the same fundamental reason downloading e.g. an OS installer through a torrent is usually faster than downloading it through HTTP from the OS maker's CDN.) 2. Intentional per-connection download-rate throttling applied by many servers (especially those of "download sites" like CNet, which "back in the day" were one of the main places people would experience large downloads); where making multiple concurrent HTTP range-requests to the server at once was a way to bypass the server's throttling. You don't see this advantage any more, as these days the servers of "download sites" have enough smarts to dynamically aggregate downlink quota between nodes in a table keyed by peer IP, such that N concurrent downloads from the same site are always each throttled to 1/Nth the rate.
  - vbezhenar 6y ago
    Multiple TCP connections might increase speed even to single source because of the following reasons: 1. TCP connection increases speed gradually over time until it hit some bandwidth limit. So if you open 10 connections, you'll hit that limit faster. 2. Rare packet drop will drop connection speed and it'll take some time to restore that speed on a given connection. With multiple simultaneous connections and rare drops only one or two connections will experience that speed drop, while other connections might even compensate that with increased speed. So if your connection is flawless, it does not make sense. Otherwise it might make sense.
  - iso947 6y ago
    Back then tcp window scaling wasn’t widely supported

folmar 6y ago

You really should get a Selective ACK aware OS. Even Windows 2000 supports it.

fulafel 6y ago

Note that single lost packets only cause a delay related to a retransmission, but they don't trigger congestion control. This delay is even smaller than RTT due to https://en.m.wikipedia.org/wiki/TCP_congestion_control#Fast_retransmit https://en.m.wikipedia.org/wiki/TCP_congestion_control#Fast_...