For those of you unfamiliar with the idiom, it should be taken to mean "benefiting one at the expense of another." In this case, Paul is the end-user and Peter is the server administrator. Or better yet, Paul is the browser and Peter is the server.

All web browsers, including IE (Internet Explorer), impose a per-server connection limit was imposed to reduce overload on servers. This was introduced back when the web was exploding and browsers opened up connections willy-nilly and made server operators cry. Often. The limitation imposed by IE (two connections per host) was harsher than those imposed later by FireFox, which set the limit at eight.

End-users have often bemoaned the slowness of IE's rendering of web pages. This poor performance was due in part to the limitation on connections. With objects numbering many times the connection limit - and each one requiring a separate request to retrieve - requests could queue up quickly on the client, each one waiting to use one of two allowed connections.

In IE8 the limitation still exists, but it's been increased from two connections to six, to improve page download times and overall performance. 

Ryan Breen in his Ajax Performance blog (an excellent resource on the subject, by the way) tested out IE8's new parallelism earlier this year and came to an obvious (at least to me, I predicted this years ago) conclusion:

I suspect that my hosting provider (Dreamhost) simply can’t keep up with the dramatic increase in connection parallelism. 18 connections is simply too much of a good thing, and it will present a scaling problem for those who are on small to medium hosts. 10 users hitting at the same time will yield 180 concurrent connections, a pretty significant number for smaller providers.

Given that FireFox already allows eight connections per host, and now IE users will be allowed six, that's a lot of connections per site. Especially when you consider that IE, despite FireFox's grand gains in recent years, still owns the lion share of the browser market.

Ryan is so very correct about the impact this will have on hosting providers and really the infrastructure of anyone who runs a web site or delivers web applications via the Internet. Especially Web 2.0 applications that make extensive use of AJAX. The impact of constantly open connections between the browser and the server from AJAX applications was noticeable, but with the increase in per-server connections in IE that impact may become even more noticeable yet.

I've talked, and written, and written some more on the subject, but now is a good time to proselytize yet again: if you want to mitigate the risk associated with increased connections then consider deploying an application delivery controller. Not a load balancer. Not a cluster controller. An application delivery controller.

Why? Because one of the things an application delivery controller does is to reuse connections between itself and the servers it is virtualizing. By reusing and managing more efficiently those connections it can handle the increase in connections from clients using the same number (or perhaps fewer) of servers you have now. So when 10 users hit the same site, it results in only around 10 connections, not around 180, because the connections on the back-end are reused to handle requests.

Basically, more browser connections means a reduction in the efficiency and capacity of your servers. The number of connections a server can have open at any given time is limited, so particularly heavy use of a site can result in supporting a decreased number of concurrent users, often with a corresponding decrease in application performance resulting from the increased load on the servers, effectively negating the performance gains achieved by IE8's new connection limit.

There isn't a whole lot you can do to your servers to combat this problem. You can either deploy more servers or you can make the servers you have more efficient. If you end up spending money on additional servers it will increase the cost of maintenance and management, or you can spend that money on a solution that not only solves the problem but just might provide some extra value like better performance, additional security, and easier scalability.

Or you can ignore it and hope your site doesn't twitter.