Last Comment Bug 634278 - Implement TCP preconnections
: Implement TCP preconnections
Status: RESOLVED DUPLICATE of bug 881804
[http-conn]
:
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: unspecified
: All All
: -- enhancement with 8 votes (vote)
: ---
Assigned To: Honza Bambas (:mayhemer)
:
: Patrick McManus [:mcmanus]
Mentors:
: 642504 771220 (view as bug list)
Depends on: 607741 623948
Blocks: 733748
  Show dependency treegraph
 
Reported: 2011-02-15 08:11 PST by Patrick McManus [:mcmanus]
Modified: 2015-02-20 11:19 PST (History)
23 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Patrick McManus [:mcmanus] 2011-02-15 08:11:20 PST
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).
Comment 1 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2011-03-17 10:38:57 PDT
*** Bug 642504 has been marked as a duplicate of this bug. ***
Comment 2 Patrick McManus [:mcmanus] 2011-04-06 10:10:45 PDT
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.
Comment 3 Honza Bambas (:mayhemer) 2011-05-14 07:46:51 PDT
-> me
Comment 4 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2011-05-17 03:49:21 PDT
It's probably a good idea to keep bug 621558 in mind when implementing this.
Comment 5 Jason Duell [:jduell] (needinfo me) 2011-05-19 09:59:38 PDT
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?
Comment 6 Patrick McManus [:mcmanus] 2012-03-20 11:31:57 PDT
while not stricting blocking or depending on bug 737548, its worth looking at that when doing this.
Comment 7 Patrick McManus [:mcmanus] 2012-07-09 06:06:36 PDT
*** Bug 771220 has been marked as a duplicate of this bug. ***
Comment 8 Anthony J. Biacco 2013-10-14 21:26:42 PDT
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.
Comment 9 pmeunier 2014-05-15 03:33:28 PDT
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.
Comment 10 pmeunier 2014-05-15 03:37:21 PDT
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.
Comment 11 Honza Bambas (:mayhemer) 2014-05-18 07:48:55 PDT
Patrick, isn't this already implemented by seer?
Comment 12 Patrick McManus [:mcmanus] 2014-05-19 05:28:43 PDT
seer is disabled at the moment, but yes that should be the mechanism.
Comment 13 Patrick McManus [:mcmanus] 2015-02-20 10:24:14 PST
hurley, should we dup this or otherwise close it based on your work?
Comment 14 Nicholas Hurley [:nwgh][:hurley] 2015-02-20 11:19:23 PST
Yeah, let's dupe this to the original seer/predictor bug

*** This bug has been marked as a duplicate of bug 881804 ***

Note You need to log in before you can comment on or make changes to this bug.