OT: How to tell an HTTP client to limit parallel connections?
ian.g.kelly at gmail.com
Fri Nov 8 21:13:11 CET 2013
On Fri, Nov 8, 2013 at 10:25 AM, Grant Edwards <invalid at invalid.invalid> wrote:
> Yes, this off-topic, but after a fair amount of Googling and searching
> in the "right" places, I'm running out of ideas.
> I've got a very feeble web server. The crypto handshaking involved in
> opening an https: connection takes 2-3 seconds. That would be fine if
> a browser opened a single connection and then sent a series of
> requests on that connection to load the various elements on a page.
> But that's not what browsers do. They all seem to open whole handful
> of connections (often as many as 8-10) and try to load all the page's
> elements in parallel. That turns what would be a 3-4 second page load
> time (using a single connection) into a 20-30 second page load time.
> Even with plaintext http: connections, the multi-connection page load
> time is slower than the single-connection load time, but not by as
> large a factor.
> Some browsers have user-preference settings that limit the max number
> of simultaneous connections to a single server (IIRC the RFCs suggest
> a max of 4, but most browsers seem to default to a max of 8-16).
> What I really need is an HTTP header or meta-tag or something that I
> can use to tell clients to limit themselves to a single connection.
> I haven't been able to find such a thing, but I'm hoping I've
> overlooked something...
No such header exists, that I'm aware of. The RFC simply recommends
limiting client connections to 2 per user, but modern browsers no
longer follow that recommendation and typically use 4-6 instead.
Do you really need to send all the page resources over HTTPS? Perhaps
you could reduce some of the SSL overhead by sending images and
stylesheets over a plain HTTP connection instead.
More information about the Python-list