[e2e] Number of persistent connections per HTTP server?

[Jim.Gettys at hp.com]

Sorry I'm a bit slow to respond to this; this week has been
more than a little crazy.  I haven't had time to even read the
rest of this thread.

Comments below:
                           - Jim Gettys
                             HP Labs


> Sender: end2end-interest-admin at postel.org
> From: "Spencer Dawkins" <sdawkins at cynetanetworks.com>
> Date: Wed, 9 Oct 2002 17:07:07 -0500
> To: <end2end-interest at postel.org>
> Subject: [e2e] Number of persistent connections per HTTP server?
> -----
> >From the HTTP base spec http://www.ietf.org/rfc/rfc2616.txt,
> I'm reading (in section 8.1.4):
>
>         "Clients that use persistent connections SHOULD
>         limit the number of simultaneous connections
>         that they maintain to a given server. A single-user
>         client SHOULD NOT maintain more than 2 connections
>         with any server or proxy."
>
> My questions are:
>
> - Was anyone on this list involved in picking the number "2"?

Yes.  I certainly was (I'm the editor of the document).

>
> - Is this still the right number for today's networks?
>
> I'm looking at two current browsers that open four connections
> to proxies, for instance. Is there research that says "4" is now
> the right number?

This violates the spec, and is not the right number.  The number "4"
is almost certainly left from prehistory (pre HTTP/1.1) without pipelining,
when the folks at netscape, trying to get the best performance they could
given HTTP/1.0, went to multiple connections.  They tweaked the number
upward until they noticed performance started getting worse, which was around
4 at that point (my theory has been that the 4 connections started self
congesting in the edge dialup routers of the era).

Here's the history: we've shown (see our Sigcomm paper, most conveniently,
with access to lots of data and traces if things haven't bit-rotted at:)

http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html
And more generally:
http://www.w3.org/Protocols/HTTP/Performance/

that a single TCP connection can, with a good implementation, outperform
multiple connections.

That being said: to get there, some clients, most particularly browsers,
need to worry about getting blocked
behind large objects, and would have to implement "poor man's multiplexing"
of the connection using HTTP range requests (or you might get stuck behind
some huge image you'd already requested).

In particular, at the time we wrote those words, we were worried that
there might be circumstances we had not forseen in the working group that
might require more than one, so we settled on 2 for the spec; both a
somewhat conservative position but to some extent a political compromise.

But 1 connection is in fact best from both a network and absolute
performance standpoint, if you can implement poor man's multiplexing
(or aren't being a web browser that has to deal with pesky users who
don't like getting blocked arbitrarily).

Now that Mozilla and offshoots have finally gotten into the world (and they've
fixed their most egregious sins on layout so it might matter), I'm hoping
to poke some of the open source folks to taking a real stab at doing it
right.

There is some chance that Opera really does it right, but I've not
looked at traces: their CTO these days was one of our co-authors, and
Opera has the reputation of being fastest; this may very well be one of
the reasons why (HÃ¥kon said he had when I sent him mail a while back, but
I've not personally verfied this).

Would that HTTP were built on top of some multiplexing layer, (or almost
anything other than MIME/RFC822/true antiquity of protocols).
                            - Jim