Http persistent connections limit

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.

[..]

I'm particularly uncertain about the "SHOULD"..what's the sense of it?anw Why?

I know that HTTP persistent connections, also called HTTP keep-alive,are the idea of using the same TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new one for every single request/response pair. I know that Using persistent connections is very important for improving HTTP performance.

• Is the 2 connections-limit per server predefined or not?
• When is a request going to use an existing connection or fetching a new one?

let's say I have an HTML page containing the following image references:

<img src="http://example.com/image1.gif"/>
<img src="http://example.com/image2.gif"/>
<img src="http://example.com/image3.gif"/>
<img src="http://example.com/image4.gif"/>

My server's keep-alive directive is turned on:what is happening here in terms persistent connections??The optimizing rule/trick related to the 2 simultaneous-connections-per-server limit like the one following is valid?

<img src="http://example.com/image1.gif"/>
<img src="http://example.com/image2.gif"/>
<img src="http://example2.com/image3.gif"/>
<img src="http://example2.com/image4.gif"/>

thanks

---

A client may use more than one connection to download resources in parallel. In your example, for instance, it may decided to download image1.gif and image2.gif simultaneously on two connections. If we suppose that image1.gif finishes first, it will then queue image3.gif on that connection. And so forth.

I have no proof of this, but I strongly suspect that most browsers will close all connections after they have downloaded all the resources on a page. If the user clicks to another page, it will open new connections.

The two connection limit is a convention more than anything. There's nothing stopping a browser from opening 50 if it wanted to. However, at this level, bandwidth usage is the limiting factor, so most browsers (I suspect) limit themselves to a handful of connections.

Again, nothing specific stopping them, however there are diminishing returns on having many connections.

---

Do not take that "SHOULD" too seriously. IE at some point used to allow only 2 simultaneous connections. Even at that point, there was an option of removing the limit (via a 'hack').

Right now, the limit is 8, in most browsers (including firefox, safari). IE8 has a 6 connections per host limit.

As you can imagine, 2 connections per host is too less. You wouldnt be able to load a page from the host, of you had 2 ongoing downloads from the same host!

And in case you are using the connection: keep-alive header, all five of your images would load on the same TCP connection, rather than terminating the connection and re-making it, in case of connection:close.

That is inefficient as the three-way TCP handshake has to be remade every time you request an image!

Under HTTP 1.1, All connections are kept alive, unless stated otherwise with the following header: Connection:close

On the other hand, you also have HTTP Pipelining (see Mike Caron's answer), which does not wait for one request to return before sending another. This is implemented by firefox( as you can see/disable in about:config), but that is a different issue from Maximum Connections per Host.

Also: If you are not using persistent connections with pipelining, you would be making multiple connections. Sending one request before closing the previous. That would block because of the max-connections limit.