- From: 陈智昌 <willchan@chromium.org>
- Date: Fri, 2 Aug 2013 08:47:05 -0700
- To: Willy Tarreau <w@1wt.eu>
- Cc: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "tcpm@ietf.org" <tcpm@ietf.org>
- Message-ID: <CAA4WUYiBpsjEhPbs3ynHL+5Hh5o8VDJrqY1mYMzBKtSQF2jGaw@mail.gmail.com>
Hey Willy! Your description sounds very familiar. Please see this bug: https://code.google.com/p/chromium/issues/detail?id=85229. I am hesitant to open to the door to turning off preconnect in favor of TFO (although it's definitely on the table). Preconnect has shown substantial improvements in page load time. Indeed, it's one of our hugest improvements ever. But I'm super sensitive to harming servers, and would love to get details from any servers that are encountering issues. Please contact me if you have details to share here. And yes, the concern about the reliability of TFO is totally valid. And that's another reason I'm hesitant to switch preconnect over to TFO because preconnect Just Works from a client's perspective (yes, it may cost the server). Cheers. On Fri, Aug 2, 2013 at 7:15 AM, Willy Tarreau <w@1wt.eu> wrote: > Hi William, > > On Fri, Aug 02, 2013 at 06:51:31AM -0700, William Chan (?????????) wrote: > > The short of it is, for vanilla HTTP, it's unclear how beneficial it > would > > be for us since we already have such gains for browser preconnect (our > > browser feature that learns from past web browsing to speculatively > > establish connections, typically just TCP connections but perhaps doing a > > TLS or other handshakes too as needed). > > That's pretty interesting. Is this already enabled by default ? I'm asking > because I've got several users of haproxy report me that their web site was > regularly "attacked" by many connections in which no request is sent, and > that because of this they had to increase the number of concurrent > connections > otherwise they can't stand the load. I asked if they thought it could be > something like a bug in some JS application or something like this as I was > no aware of the preconnect feature. It's been a bit hard to analyse, since > they see no request, they can't get any information on the user agent for > example. The thing is that it does not look like a regular attack since the > load is more or less constant, and not very high. So till now it was always > possible to work around this by increasing the connection limits 2-10 > times. > > But now I'm thinking that *if it was a preconnect behaviour*, there could > possibly be some harm there. I have no idea how many connections a browser > can send to recently visited sites, but for sites which use a short > keep-alive > timeout to limit the concurrency, having a significant increase on the > number > of concurrent connections can be a problem. > > Note that I'm talking using a conditional form, as I can't provide evidence > for this to be related to a preconnect feature, but your description really > matches what I observed, and I am really wondering about the risks and > possibile impacts based on something that could appear related. If the > increase in connection count may be significant for small sites, then maybe > TFO could be a decent alternative (though it will clearly not pass through > every firewall). > > Best regards, > Willy > >
Received on Friday, 2 August 2013 15:47:33 UTC