W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: Feedback on TCP Fast Open?

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Fri, 2 Aug 2013 08:47:05 -0700
Message-ID: <CAA4WUYiBpsjEhPbs3ynHL+5Hh5o8VDJrqY1mYMzBKtSQF2jGaw@mail.gmail.com>
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>
Hey Willy!

Your description sounds very familiar. Please see this bug:

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


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC