This was a popular feature request for IE in the late '00s, as it was a common feature of download managers of the era.
Our investigation at the time concluded that it only reliably improved performance in the case that the server was deliberately throttling per-connection throughput (e.g. to entice the user to pay for an upgrade); it frequently failed on such sites though because they caught on and started using one-time tokens for downloads such that the parallel attempt would be redirected to the download page.
In a world of multiplexed HTTP2 connections, I wonder whether there would still be any benefit.
#1. Understood. Thanks!
The investigative portion of this bug is to understand the effects of this technique. We currently don't have much data on how something like this would perform in practice.
I'm also conjecturing that support for multiple parallel requests will make it possible for us to speculatively reconnect to servers where the existing connection is likely stalled. Currently there are situations where we can't reliably tell when a connection is dead without waiting for it to timeout. Since the current stack is only capable of dealing with one request, we have to wait for the existing connection to fail before starting a new one.
In this bug, a new connection implies a new socket. I don't think anything useful would come of starting a new multiplexed request over an existing socket.
Comment 1 by elawrence@chromium.org
, Sep 6 2016