High Performance Web Sites blog

A lot of blogging and follow-up discussion ensued with the announcement that IE8 supports six connections per host. The blogs I saw:

• IE8: The Performance Implications
• IE8 speeds things up
• IE8: 6 Connections Per Host
• IE 8 and Performance
• Testing IE8.s Connection Parallelism
• IE 8 Connection Parallelism Issues

It’s likely that Firefox 3 will support 6 connections per server in an upcoming beta release, which means more discussion is expected. I wanted to pull all the facts into one place and make several points that I think are important and interesting. Specifically I talk about:

• the HTTP/1.1 RFC
• settings for current browsers
• upperbound of open connections (cool!)
• effect of proxies
• will this break the Internet?

The HTTP/1.1 RFC

Section 8.1.4 of the HTTP/1.1 RFC says a “single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.” The key here is the word “should.” Web clients don’t have to follow this guideline. IE8 isn’t the first to exceed this guideline. Opera and Safari hold that honor supporting 4 connections per server.

It’s important to understand that this is on a per server basis. Using multiple domain names, such as 1.mydomain.com, 2.mydomain.com, 3.mydomain.com, etc., allows a web developer to achieve a multiple of the per server connection limit. This works even if all the domain names are CNAMEs to the same IP address.

Settings for Current Browsers

The table below shows the number of connections per server supported by current browsers for HTTP/1.1 as well as HTTP/1.0.

Browser	HTTP/1.1	HTTP/1.0
IE 8	6	6
IE 6,7	2	4
Firefox 3	6	6
Firefox 1.5, 2	2	8
Opera 9	4	?1
Safari 3,4	4	4

¹I don’t have the HTTP/1.0 stats for all browsers. If you know the stats submit a comment below and I’ll update the table. Use this parallel downloads test page.

I provide (some of) the settings for HTTP/1.0 in the table above because some of the blog discussions have confused the connections per server settings for HTTP/1.0 with those for HTTP/1.1. HTTP/1.0 does not have persistant connections so a higher number of connections per server is supported to achieve faster performance. For example, IE7 supports 4 connections per server in HTTP/1.0. In fact, AOL intentionally downgrades their responses to HTTP/1.0 to benefit from this increase in parallelization, although they do it at the cost of losing the benefits of persistent connections. They must have data that supports this decision, but I don’t recommend it.

It’s possible to reconfigure your browser to use different limits. How to configure Internet Explorer to have more than two download sessions describes how the MaxConnectionsPerServer and MaxConnectionsPer1_0Server settings in the Windows Registry control the number of connections per hostname for HTTP/1.1 and HTTP/1.0, respectively. In Firefox these values are controlled by the network.http.max-persistent-connections-per-server and network.http.max-connections-per-server settings in about:config.

Note that IE8 automatically drops back to 2 connections per server for users on dialup connections. Also, web developers can detect the number of connections per server currently in effect by accessing window.maxConnectionsPerServer and window.maxConnectionsPer1_0Server in JavaScript. These are read-only values.

Upperbound of Open Connections

What’s the maximum number of connections a browser will open?
This is relevant as server adminstrators prepare for spikes from browsers with increased parallelization.

This Max Connections test page contains 180 images split across 30 hostnames. That works out to 6 images per hostname. To determine the upperbound of open connections a browser supports I loaded this page and counted the number of simultaneous requests in a packet sniffer. Firefox 1.5 and 2.0 open a maximum of 24 connections (2 connections per hostname across 12 hostnames). This limit is imposed by Firefox’s network.http.max-connections setting which defaults to a value of 24.

In IE 6,7&8 I wasn’t able to determine the upperbound. At 2 connections per server, IE 6&7 opened 60 connections in parallel. At 6 connections per server, IE8 opened 180 connections in parallel. I’d have to create more domain names than the 30 I already have to try and find where IE maxes out. (If you load this in other browsers please post your results in a comment below and I’ll update this text.)

Effect of Proxies

Note that if you’re behind a proxy (at work, etc.) your download characteristics change. If web clients behind a proxy issued too many simulataneous requests an intelligent web server might interpret that as a DoS attack and block that IP address. Browser developers are aware of this issue and throttle back the number of open connections.

In Firefox the network.http.max-persistent-connections-per-proxy setting has a default value of 4. If you try the Max Connections test page while behind a proxy it loads painfully slowly opening no more than 4 connections at a time to download 180 images. IE8 drops back to 2 connections per server when it’s behind a proxy, so loading the Max Connections test page shows an upperbound of 60 open connections. Keep this in mind if you’re comparing notes with others - if you’re at home and they’re at work you might be seeing different behavior because of a proxy in the middle.

Will This Break the Internet?

Much of the debate in the blog comments has been about how IE8’s increase in the number of connections per server might bring those web servers to their knees. I found the most insightful comments in Mozilla’s Bugzilla discussion about increasing Firefox’s number of connections. In comment #22 Boris Zbarsky lays out a good argument for why this increase will have no effect on most servers. But in comment #23 Mike Hommey points out that persistent connections are kept open for longer than the life of the page request. This last point scares me. As someone who has spent many hours configuring Apache to find the right number of child processes across banks of servers, I’m not sure what impact this will have.

Having said that, I’m please that IE8 has taken this step and I’d be even happier if Firefox followed suit. This change in the client will improve page load times from the user’s perspective. It does put the onus on backend developers to watch closely as IE8 adoption grows to see if it affects their capacity planning. But I’ve always believed that part of the responsibility and joy of being a developer is doing extra work on my side that can improve the experience for thousands or millions of users. This is another opportunity to do just that.