We did experimentation and real-world measurement w.r.t. HTTP2/SPDY and
HTTPS along these lines.
Multiple TCP streams are faster so long as the congestion context from one
connection isn't informed by the other connections' contexts and the
connections are using a reasonable percentage of their maximum rate.
Below the maximum rate, and there ended up being adverse effects thanks to
not triggering various TCP optimizations and requiring timeouts.
Some of the obvious effects occur at the start of the connection, with
ICWND=10, 6 connections get 60 packets worth, while one gets 10.
Unfortunately, I don't have data to give anymore, but folks at Google who
are still working on this stuff (no longer me) may have more up-to-date
information.
What is definitely true is that the fact that this is all an artifact of
the fact that congestion controllers are instantiated per connection
instead of for wider contexts, and are currently loss-based instead of
rate/timing based (which does have its own problems).
-=R
On Wed, Feb 4, 2015 at 11:22 AM, Phillip Hallam-Baker
<phill(_at_)hallambaker(_dot_)com
wrote:
Today most Web browsers attempt to optimize download of images etc. by
opening multiple TCP/IP streams at the same time. This is actually done for
two reasons, first to reduce load times and second to allow the browser to
optimize page layout by getting image sizes etc up front.
This approach first appeared round about 1994. I am not sure whether
anyone actually did a study to see if multiple TCP/IP streams are faster
than one but the approach has certainly stuck.
But looking at the problem from the perspective of the network it is
really hard to see why setting up five TCP/IP streams between the same
endpoints should provide any more bandwidth than one. If the narrow waist
is observed, then the only parts of the Internet that are taking note of
the TCP part of the packet are the end points. So having five streams
should not provide any more bandwidth than one unless the bandwidth
bottleneck was at one or other endpoint.
Now there are some parts of the deployed Internet that do actually perform
statefull inspection. But I would expect increasing the number of channels
to degrade performance at a firewall or any other middle boxen.
So we have a set of behavior that seems at odd with the theory. Has anyone
done any experiments recently that would show which is right?
The reason it makes a difference is that it is becoming clear that modern
applications are not best served by an application API that is limited to
one bi-directional stream. There are two possible ways to fix this
situation. The first is to build something on top of TCP/IP the second is
to replace single stream TCP with multi-stream.
My preference and gut instinct is that the first is the proper
architectural way to go regardless of the performance benefits. When
Thompson and co were arguing that all files are flat sequences of bits,
they were saying that was the right O/S abstraction because you could build
anything you like on top.
But then I started to ask what the performance benefits to a multi-stream
TCP might be and I am pretty sure there should not be any. But the actual
Internet does not always behave like it appears it should.
I suspect that the preference for multiple streams probably comes from the
threading strategies it permits. But that is an argument about where the
boundary between the kernel and application is placed in the network stack
rather than where multiplex should live in the stack. Microsoft already
provides a network stack for .NET where the boundary is in the HTTP layer
after all.
So anyone got hard data they could share?