as noted by brian here: https://bugzilla.mozilla.org/show_bug.cgi?id=623948#c3 , the disassociation of http connection from a particular transaction (623948) allows a more aggressive kind of tcp preconnection. It appears IE9 and chrome can do so (I don't think at least chrome does it by default). http://code.google.com/p/chromium/issues/detail?id=42694 http://www.belshe.com/2011/02/10/the-era-of-browser-preconnect/ http://downloadsquad.switched.com/2010/05/18/dns-pre-resolution-is-weak-chrome-goes-one-step-further-and-pre/ One intriguing approach to this would be to track the high water mark for particular hosts and automatically open that many whenever one has to be created.. we could then back that number down by tracking connections that are closed without ever being used. This would result in some extra idle sockets hanging around, so we probably want to up the default 30 global connection limit (not changing the per server limit).
feedback from chrome indicates this is helpful, but if you send them in bursts you can see occasional tail drop. (my guess would be in nat tables).. for that reason they suggest a combination of prewarming (this bug) in addition to timer driven conections ala our 'syn retry' code.
Note that the downloadsquad article implies chromium is starting preconnections in the addressbar as you type (i.e. before it's even definitively known which domain you're actually going to), as la DNS prefetching. Which is a step more aggressive than just popping open extra connections once the first is opened normally. Thoughts? Privacy issues when the browser gets it wrong and opens to a domain other than what you eventually type? I'm guessing this might also best be a separate bug?
while not stricting blocking or depending on bug 737548, its worth looking at that when doing this.
Since 733748 is marked as resolved i'll chime in here. I understand what the browser is trying to do, for the better, but I feel that preconnections in their current form are breaking the HTTP model already established. The server should be the authority on what you can and cannot do when making connections to it, which is why we have request and response headers. Blindly making connections which you may not use, without giving notice, tying up server resources, is just not right. The browser should, in its first request, send a Request header to the server, asking to use preconnections and wait for a Response header with a non-zero integer before making any preconnections of that max amount to said host; with a 0 (or false) response disabling preconnections. If the server Responds with a different integer in any subsequent real request, the browser should respect that, and adjust its preconnections accordingly.
Please, oh please, don't implement preconnections. I'm fighting a DDoS attack whose log entries in Apache look exactly like abandonned preconnections from Google Chrome and IE. Even though the Apache reqtimeout module is configured with a very quick expiration of idle connections, we can't keep up. We have to use fail2ban to ban the attacking IPs. Unfortunately, this sometimes results in banning legitimate users. Firefox users have no problems with our sites, so I'm recommending it. Preconnections make our lives difficult and waste considerable server resources. We may have to put a reverse proxy in front of Apache just to deal with this obnoxious behavior, because it's difficult to distinguish the attackers from legitimate users.
And all that trouble for a measly performance gain of around 8% (http://www.belshe.com/2011/02/10/the-era-of-browser-preconnect/). Preconnections are really unjustifiable for the trouble they cause.
Patrick, isn't this already implemented by seer?
seer is disabled at the moment, but yes that should be the mechanism.
hurley, should we dup this or otherwise close it based on your work?
Yeah, let's dupe this to the original seer/predictor bug