As defined in 1999 (RFC 2616) “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.” Since developers are using AJAX or AJAX-like requests to update a Web page the http limits are discussed more and more.

Currently WinInet limits connections per server with a registry setting (for both, http 1.1 and 1.0). You can simply change the value and have the possibility to connect to more than one server at the time. Other Web browser have limited the concurrent connections to other values. Opera lets you change the value through the Preferences dialog box, look under Advanced –> Network. Firefox users just type about:config in the address bar and hit enter. Then type connections into the filter field. The setting your looking for is network.http.max-persistent-connections-per-server.

Now, Internet Explorer 8 changes the maximum number of concurrent connections:

What does this mean for end-users? Well, it is much easier for a client to initiate more than two downloads (in the past you had to open Internet Explorer again to start a new instance to get two more connections). You may expect higher number of downloads at the same time instead of several two-paired downloads on your Web server.

What about XMLHttpRequest? You’re now able to initiate up to 6 AJAX requests to the same Web server. Do you really need this? In my eyes running more than one AJAX request makes still no sense. The only benefit I see is that files included in the page (i.e. CSS, JavaScript,…) are downloaded faster as they can downloaded at the same time. Another thing that will be better are mouseover events that change images while an AJAX request is running.

Internet Explorer 8 includes two new read-only properties of the window object that enable your server to determine the number of available connections on the client computer: window.maxConnectionsPerServer (http 1.1) and window.maxConnectionsPer1_0Server (http 1.0).

Read more details at Connectivity Enhancements in Internet Explorer 8 (MSDN), IE8: The Performance Implications, Testing IE8’s Connection Parallelism, IE8: Better Ajax, CSS, DOM, and new features.

Update: there is another new property, the XMLHttpRequest’s timeout. With the timeout property, Web developers can specify the length of time in milliseconds for the host to wait for a response before timing out the connection. I’m very sure that this new property and the event timeoutRaised will be added by the Firefox developers very soon.

Update 2: Updated the citation to include the recommendation that a single-user client SHOULD NOT maintain more than two connections. Well, it was defined in 1999 and Web has changed since then but I still would like to see Web applications only accessing my Web server with one connection. The only reason to have more than one connection: downloading files (CSS, JavaScript, or in common big files that are saved to disk). In the documentation of connectivity enhancements in IE8 the registry key FEATURE_AJAX_CONNECTIONSERVICES will set the new maximum number back to two concurrent connections. I don’t know why there is the name AJAX used. ASP.NET developers may get in trouble if they are using the Session object and running concurrent AJAX requests as each requests has to wait until the previous has been finished.

10 Comments

• mathertel said Monday, July 21, 2008 2:13:08 PM

  First, rfc2616 also says: A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy (please make your citations complete!) but the discussion is good today. Making more than 1 AJAX call to a server is pretty problematic because you run into racing conditions when those calls depend on each other. It is better by far to make them fast and queue them.

• Michael Schwarz said Monday, July 21, 2008 2:36:07 PM

  @Mathertel: yes, of course, but the RFC has been written in 1999 and things are changing. I've added an update to my post above. I would allow downloading files (CSS, JavaScript, images) to improve the overall performance; also downloading many files to hard disk I see no problem to have more than 2. BUT: AJAX should NEVER use more than one concurrent request to the same Web server.

• Steve said Monday, July 21, 2008 3:04:58 PM

  Michael, I see no need for this, too. Only for downloading files to hard disk as you wrote above. Thanks for your details!

• Bertrand Le Roy said Monday, July 21, 2008 6:14:07 PM

  While I agree that for Ajax it rarely makes sense, there are still a couple of scenarios where this matters. The first one is mashups, which might actuallly proxy through the same server requests coming from independant parts. The second is Comet applications: once the Comet connection is made, only one connection remains for the rest of the app. Do one regular Ajax request, update parts of the DOM (including new images for example) and you've got a nice bottleneck on your hands.

• Michael Schwarz said Monday, July 21, 2008 6:32:24 PM

  @Bertrand: yes, using mashups with a proxy at the same server is one type of application where the additional concurrent connections are great. A comet connection I compare with an AJAX request that polls every second or more often. Changing DOM (including new images) should not end in too many requests for both types of updating the DOM. A simple mouseover could be developed bad that it requries those connectons, too. What I'd like to say is that Web developers should not start using all the available connections. Instead they should try to save those requests. I have seen some Web applications where on AJAX request ends in another three requests. This could be done in one single request that hold all the data needed to process all of them. I'm using a simple interface where objects can tell what they need, then a common AJAX request (or Comet connection) will send this and distribute each result to the correct JavaScript handler. This is much better for PCs that are running not as fast as most Web developer's PCs.

• Scott Walter said Monday, July 21, 2008 6:36:34 PM

  Great post...! Michael, I read in you comment that you collect several requests to a single AJAX request and then process the request and later distribute each result to a JavaScript callback handler. How did you run this? I would like to see a demo for this.

• Bertrand Le Roy said Monday, July 21, 2008 6:48:16 PM

  @Michael: Completely agree, just wanted to point those out. In any case, the additional connections won't be ubiquitous for a while so we should never *rely* on them. But if they make the experience nicer, that's cool.

• 工控 said Friday, July 25, 2008 8:02:59 AM

  we choosing create virtual sub domain image servers to solve connection limit problem.

• Stijn said Tuesday, August 5, 2008 12:48:56 PM

  First of all I'd like to add a usage scenario for supporting more than two concurrent connections. If you try to make a background upload component with some progress bar, you'll soon run into this problem. Whith two uploads running in the background, you're out of connections and your progress bar will not be able to make it's progress status requests anymore. I ran into that myself. Second, a question, You state: "Internet Explorer 8 includes two new read-only properties of the window object that enable your server to determine the number of available connections on the client computer: window.maxConnectionsPerServer (http 1.1) and window.maxConnectionsPer1_0Server (http 1.0). ... I’m very sure that this new property ... will be added by the Firefox developers very soon." I'd love for that property to work cross browser. It allows my component to figure out the best strategy for queueing uploads; If you have more requests we can upload more files concurrently, if you don't, we queue them. Any news on wheter Mozilla has any plans on implementing it?

• Michael Schwarz said Tuesday, August 5, 2008 3:03:21 PM

  @Stijn: well, yes, concurrent uploads are not easy to manage different. I tried it with a Silverlight plugin but everything else is difficult. So, yes, you've found another reason. I have no news about how to access those values in Firefox/Mozilla.