The default bug view has changed. See this FAQ.

Implement TCP preconnections

RESOLVED DUPLICATE of bug 881804

Status

()

Core
Networking: HTTP
--
enhancement
RESOLVED DUPLICATE of bug 881804
6 years ago
2 years ago

People

(Reporter: mcmanus, Assigned: mayhemer)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [http-conn])

(Reporter)

Description

6 years ago
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).
(Reporter)

Updated

6 years ago
Depends on: 623948, 607741
Duplicate of this bug: 642504
(Reporter)

Comment 2

6 years ago
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.
(Assignee)

Comment 3

6 years ago
-> me
Assignee: nobody → honzab.moz
Status: NEW → ASSIGNED
It's probably a good idea to keep bug 621558 in mind when implementing this.
See Also: → bug 621558
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?

Updated

5 years ago
Blocks: 733748
(Reporter)

Comment 6

5 years ago
while not stricting blocking or depending on bug 737548, its worth looking at that when doing this.
(Assignee)

Updated

5 years ago
Whiteboard: [http-conn]
(Reporter)

Updated

5 years ago
Duplicate of this bug: 771220

Comment 8

4 years ago
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

3 years ago
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

3 years ago
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.
(Assignee)

Comment 11

3 years ago
Patrick, isn't this already implemented by seer?
Flags: needinfo?(mcmanus)
(Reporter)

Comment 12

3 years ago
seer is disabled at the moment, but yes that should be the mechanism.
Flags: needinfo?(mcmanus)
(Reporter)

Comment 13

2 years ago
hurley, should we dup this or otherwise close it based on your work?
Flags: needinfo?(hurley)
Yeah, let's dupe this to the original seer/predictor bug
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(hurley)
Resolution: --- → DUPLICATE
Duplicate of bug: 881804
You need to log in before you can comment on or make changes to this bug.