You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Ben <be...@meh.net.nz> on 2014/03/25 20:42:41 UTC

Re: TCP Fast Open (TFO) in Traffic Server

On Wed, Jan 22, 2014 at 10:18:45AM -0200, Alex Garz?o wrote:
> Hello,
> 
> Ticket: https://issues.apache.org/jira/browse/TS-2520.
> 
> I am a newbie in ATS, but I would like to contribute. Can I implement
> a patch to solve this?

Did this ever go anywhere?

I'm still interested in such, but as far as I can tell Chrome is sitll sending POST requests
that way which will sometimes end up with duplicate requests.

I don't know what I thought before, but now I think it's okay to accept even with Chrome's bug--
Chrome doesn't enable by default, and it's not the servers responsibility to deal with buggy client.

Getting the connecting out using TFO should definitely be done right though.  And I imagine that's
where it will get complicated.

I should have some spare time in a week or two, so if no-one else wants to try adding support for
accepting TFO connections then I should be able to.  I imagine it's going to take me quite a long time
to get orientated enough to add outbound support though.

The other outbound issue is that if you have existing connections you don't want to risk opening a TFO
connection to somewhere that may or may not have TFO support, and instead want to reuse an existing
connection.

As far as performance improvements go - Chrome is already preconnecting.  And that preconnecting will
only get as far as a proxy server - so if the proxy preconnected too that would give benefit to more
users.  Although if not careful and preconnecting too much could create a DOS vector - so it'd make sense
to err on the side of caution.

In a lot of cases even using TFO for POST requests is probably fine - a user can click on POST twice, to
duplicate a request, and both normally clients, and proxy to web server connections don't usually have
packet loss. (downstream packet loss tends to be more common on cable/adsl networks, and upstream usually
has bufferbloat instead, proxies usually have stable connections to web servers, and in high load cases
are more likely to congesting down stream than upstream).  So if you have a proxy server on the same local
network as a server, it's probably safe to accept non TFO connections to the proxy, then do TFO from proxy
to web server.

Unfortunately web server support still isn't common.  I've only tested with modified lighttpd, but afaik none
of the web servers have native support yet.

Ben.

Re: TCP Fast Open (TFO) in Traffic Server

Posted by Alex Garzão <al...@azion.com>.
Hello,

We did not progress in TFO. Currently we are developing some custom plugins
and investigating some forms to improve regexp purge.

Our plan is to solve the TFO issue in about 4 months.

Regards.

Alex Sandro Garzão

Porto Alegre, Brasil + 55 51 3012 3005
Miami, USA + 1 305 704 8816

Quaisquer informações contidas neste e-mail e anexos podem ser
confidenciais e privilegiadas, protegidas por sigilo legal. Qualquer forma
de utilização deste documento depende de autorização do emissor, sujeito as
penalidades cabíveis.

Any information in this e-mail and attachments may be confidential and
privileged, protected by legal confidentiality. The use of this document
require authorization by the issuer, subject to penalties.