Under what circumstances will my browser attempt to re-use a TCP connection for multiple requests?

Question

I am using Firefox, but I'd like to know how browsers decide this in general.

It seems that when I access the same URL twice in a short amount of time, my browser tries to re-use the TCP same connection for both requests (this is called keep-alive). However, when I access two different URLs (but still served by the same server), the browser sometimes decides to open up a new connection for each request. Obviously, the browser does not use a one-connection-per-URL policy.

I am asking this because I am trying to implement a web service that uses long polling. I can imagine that a user might want to open this service in multiple tabs on the same browser. However, with keep-alive, the second long poll request does not get sent until the first one completes (at least in Firefox), because the browser is trying to shove both of them into the same socket, which I did not expect when I designed the service. Even if the browser implements pipe-lining, there is no way that I can respond to the second request before I respond to the first, because HTTP mandates that I complete the responses in order.

Sciurine

Answer 1

When using HTTP/1.1, by default, the TCP connections are left open for reuse. This is for better performance than starting a new connection per request. The connection can be reused but the connection could close at any time by any of the parties.

You should read HTTP1.1 and the part on persistent connections.

In your case it is not even using HTTP pipelining (not broadly supported) because the next request is sent after the response of the first.

The browsers have a connection pool and reuse it per hostname. Generally speaking, a browser should not reuse a single connection for multiple hostnames, even if those hostnames actually resolve to the same IP address.

Most browsers allow the user to configure or override the number of persistent connections per server; most modern browsers default to six. If Firefox is truly blocking the second request because there's already a connection active, this is a bug in Firefox and should be filed in their bug tracking system. But if such a bug existed, I think you'd see many sites broken.

Godhead

Although I tell Firefox to send a request to the server a second time, I believe it does not actually send out a request because it wants to wait for the first request to finish, so that it can re-use the connection. This is a feature, not a bug, correct? – Sciurine

Perhaps for identical URLs it tries to use the same connection but for URL's it tries to select another connection in the pool? – Sciurine

If your testing is to send 2 concurrent HTTP requests to the same URL you could either see them "serialized" or being send over 2 different TCP connections. BUT you are NOT seeing them pipelined.What will happen, is now implementation dependend.E.g. the browser may opt to reuse a connection from the pool, or send the second request over a new connection.Both approaches are correct since HTTP is a stateless protocol.If your implementation depends on details such as these, then IMHO there is a flaw in your design.May be you should write more about what you want to achieve. – Godhead

It's also up to the server to decide whether to return a Connection: close (which forces the client to open a new connection on subsequent requests) It will also close the TCP connection, forcing a new one, if there is a time limit on the keepalive, or if it reaches the limit on the number of requests for the process. – Antlia

@user384706: I have solved the issue. I was sending two requests to the same URL, so Firefox chose not to actually send the second request until it got a response to the first request. Intuitively, this is a "feature" because if the server does not respond to the first request, there is not much reason to believe that it will respond to the second request, unless the server is programmed in a non-traditional manner - which was my case. Thanks. – Sciurine

@Mark:Well, not really.HTTP is a stateless protocol and there is no association among the requests.A server could have delayed a response due to perhaps the request requires a lot of processing or the server is overloaded or the response might never come.Firefox could have just as well send the second request over a second connection.Generally speaking, you should not rely your design on implementation details such as these because you may find yourself under surprise – Godhead

@Mark: How did you solve this? I ran into the same: I have long-polling server-side program, which gets only 1 request from multiple open tabs with the same page. As a result, I have my data round-robined between tabs. – Involuted

@peroksid: Wow this was a while ago. I think I ended up doing something hacky like making the client request the URL with a random query string attached on the end. – Sciurine

Thanks for the response. I was hoping for some kind of server-side solution. Trying to make life of my client-side colleague a bit easier. – Involuted