W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2009

Re: [OT] Re: #131: Connection limits (proposal)

From: Jamie Lokier <jamie@shareable.org>
Date: Thu, 22 Oct 2009 01:57:51 +0100
To: Adrien de Croy <adrien@qbik.com>
Cc: Jim Gettys <jg@freedesktop.org>, "William A. Rowe, Jr." <wrowe@rowe-clan.net>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20091022005751.GC27677@shareable.org>
Adrien de Croy wrote:
> Jim Gettys wrote:
> >We showed in the HTTP/1.1 paper that additional parallel connections 
> >did not actually increase performance; fastest performance was 
> >achieved with a single TCP connection.  But for many bad 
> >implementations, doing so will, without the implementers having to 
> >actually think or restructure their code.
> >
> >
> depends on how you define performance.  Agreed for the case where you 
> are making a single HTTP request to download a large resource.
> 
> But for a site with a large number of embedded images or parts (common 
> nowadays for a home-page to result in well over 100 requests), then 
> serializing requests + latency results in a poor user experience.  
> Opening multiple connections and making concurrent requests greatly 
> improves user experience.   That's why browsers do it.

This is precisely why I keep advocating multiplexing over on the hybi
list, if anyone is subscribed to both...

Multiple connections reduces aggregate throughput (mostly), but
improves the user experience because of the concurrent arrivals.
Resources taking a long time to generate on the server, and large
resources, don't block the arrival of other resources so much.

Good multiplexing can provide a combination of both - maximal
throughput using few or one TCP connection, at the same time as
concurrency.

Which is why HTTP-over-SCTP is being looked at (it is multiplexing
done better than TCP can).  But even over TCP it has potential.

-- Jamie
Received on Thursday, 22 October 2009 00:58:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:12 GMT