- From: Mark Nottingham <mnot@yahoo-inc.com>
- Date: Wed, 5 Mar 2008 15:27:37 +1100
- To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
RFC2616 Section 8.1.4, Practical Considerations: > 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. A proxy SHOULD use up to 2*N connections to > another server or proxy, where N is the number of simultaneously > active users. These guidelines are intended to improve HTTP response > times and avoid congestion. I'm not sure I want to suggest that these limits should be changed, but I think it's worth a discussion. I've seen a number of cases where; * resources have been spread across multiple servers, just to work around this limitation * client-side frameworks have been designed to work around this limitation by batching multiple representations together (removing the possibility of caching) * because of low adoption of pipelining, two slow responses blocking an entire Web page * servers purposefully answer HTTP/1.0, because some clients will use four connections with them Also, considering the wider availability of event-driven Web servers and intermediaries, resource limitations on servers isn't necessarily the problem it once was. What do people think? Should we consider upping this to 4? There's also the possibility of negotiating a higher number of connections hop- by-hop (but that would be outside of HTTPBIS). Cheers, -- Mark Nottingham mnot@yahoo-inc.com
Received on Wednesday, 5 March 2008 04:28:26 UTC