[e2e] Number of persistent connections per HTTP server?

[Qiaobing Xie]

This may be a little controversial, but SCTP seems to be able to help
here. With SCTP one would only need to have 1 association between the
HTTP server and client, which will provide up to 64k
non-head-of-line-blocking steams in each direction. Either side could
then transfer independent objects using separate streams within this
single association, without worrying too much about the HOL blocking
problem. For example, one could reserve stream 0 from the client to the
server for all the requests, and the server would have full control over
how many streams to use for the requested page and to which stream an
object on the page should be sent, etc.

An experimental SCTP-capable Apache code is now available at
<http://www.sctp.org>. It would be interesting to see if some one can
experiment with it (especially its stream capability) with some
object-rich web contents.

-Qiaobing

Joe Touch wrote:
> 
> Venkat Padmanabhan wrote:
> > I believe the reason the recommended number of persistent connections
> > per client was set to 2 rather than 1 was to prevent head-of-line
> > blocking. With a single connection (and in the absence of byte-range
> > requests), the transfer of a large object could block subsequent
> > requests for a significant length of time. With two connections, one can
> > confine the large transfers to one connection, keeping the other one
> > clear for short transfers. This is analogous to why a two-lane road is
> > far better than a single-lane one.
> 
> Hi, Venkat (et al.),
> 
> That would make sense if clients managed the connections that way.
> However, they often take the first idle connection for each pending
> request; i.e., it's like watching trailers passing each other slooowly
> while the cars backup behind.
> 
> Besides, how is the client to know what a short request is vs. a long
> one? Sometimes even the server doesn't know (when the reply is sent in
> chunks)...
> 
> Joe