3 ms·

Those connections will all go though TCP startup phase where throughput is limited by the congestion window size. And because they're unaware of each other it'

Those connections will all go though TCP startup phase where throughput is limited by the congestion window size. And because they're unaware of each other it's likely they'll eventually start competing with each other and cause packet loss

CyberRabbi 6y ago
In the vast majority of cases, neither of those things practically matter. The multiple connections are for intended for concurrency, not parallelism. Web assets are not large enough for slow start to impact overall download speed by any large margin, nor sustain downloads long enough that the connections start to compete. Requests are bursty.
- youngtaff 6y ago
  It's quite a few years old –https://web.archive.org/web/20170724120441/https://insouciant.org/tech/network-congestion-and-web-browsing/ https://web.archive.org/web/20170724120441/https://insoucian... – but I still see this in some packet captures
  - CyberRabbi 6y ago
    Yea technically there is a potential benefit but the point is that it’s so marginal that the majority of users won’t ever notice it. You’re saving 1-5ms off of a page load.
saurik 6y ago
...but multiple TCP connections (within reason: too many causes a problem, but not just a handful) actually almost always out-perform a single one for numerous reasons (including the congestion controller having more leverage from looking like multiple users, being able to hit multiple backend machines from dns load balancing, and working around various per-connection bottlenecks); this is in fact the primary trick of "download helpers": they download multiple independent segments of the file on parallel connections.