You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Alex Garzão <al...@azion.com> on 2014/01/20 17:27:10 UTC
TCP Fast Open (TFO) in Traffic Server
Hello,
Are any plans to support TCP Fast Open (TFO) in ATS?
Regards.
--
Alex Garzão
Projetista de Software
Azion Technologies
alex.garzao (at) azion.com
Re: TCP Fast Open (TFO) in Traffic Server
Posted by Bahram Akhundov <de...@hotmail.de>.
I will nothing send you and report this bug.
Buth i can only says me , from traffic server i can make XSS and SQL
injection.
The latest version of traffic server have backdoor and can any web
server installed the latest version of this server traffic read mysql
config or make any sql inejction :)
Latest traffic server version ared bypassed :)
0day and vuln...
Gr33tz :)
Re: TCP Fast Open (TFO) in Traffic Server
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> I don't know how you implemented it in traffic server, but in traffic server
> we do a setsockopt on the listening socket and there is a configuration
We'd need a autoconf check for that option, I pressume…
> option to add additional options. This part would need to change and
> another configuration option should be added for the queue size.
>
> Happy to see TFO support being added. I have been wanting to play around
> with TFO for awhile.
>
> -Bryan
>
> On Jan 23, 2014, at 8:22 AM, Ben <be...@meh.net.nz> wrote:
>
> > 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?
> >
> > if you want to implement tcp fast open listening in traffic server, i've
> > got a really hackish kludge to http_load to support tcp fast
> > open, and it doesn't look as hard as it probably is in the main
> > trafficserver.
> >
> > without tcp fast open:
> > <ben@amethyst:/src/trafficserver-svn/tools/http_load>
> > zsh/2 3093 (git)-[master]-% ./http_load -parallel 2 -fetches 50
> > /tmp/urlfile
> > 50 fetches on 50 conns, 1 max parallel, 8850 bytes, in 0.66447 seconds
> > 177 mean bytes/fetch
> > 75.2479 fetches/sec, 13318.9 bytes/sec
> > msecs/connect: 13.0597 mean, 16.855 max, 11.127 min
> > msecs/first-response: 13.4596 mean, 17.641 max, 11.97 min
> > HTTP response codes:
> > code 200 -- 50
> >
> > with tcp fast open:
> > [Thu 14/01/23 20:15 NZDT][pts/40][x86_64/linux-gnu/3.13.0-rc7ice][5.0.5]
> > <ben@amethyst:/src/trafficserver-svn/tools/http_load>
> > zsh/2 3094 (git)-[master]-% ./http_load -parallel 2 -fetches 50
> > /tmp/urlfile
> > 50 fetches on 50 conns, 1 max parallel, 8850 bytes, in 0.355519 seconds
> > 177 mean bytes/fetch
> > 140.639 fetches/sec, 24893.2 bytes/sec
> > msecs/connect: 0.00864 mean, 0.018 max, 0.002 min
> > msecs/first-response: 14.0743 mean, 15.28 max, 11.833 min
> > HTTP response codes:
> > code 200 -- 50
> >
> > i don't really know how the parallel command is meant to work. and that's
> > a near empty page and against lighttpd with my local modifications
> > for tcp fast open listening.
> >
> >
> > i dunno the best way to go about it, i'm forcing doublechecking code in
> > handle_connect and moving all the connecting logic there, as that
> > simplifies
> >
> > And basically doing:
> >
> > #ifdef TCP_FASTOPEN
> > if (sendto (connections[cnum].conn_fd, urls[url_num].buf,
> > urls[url_num].buf_bytes, MSG_FASTOPEN, (struct sockaddr *)
> > &connections[cnum].sa, connections[cnum].sa_len) < 0) {
> > #else
> > if (connect(connections[cnum].conn_fd, (struct sockaddr *)
> > &connections[cnum].sa, connections[cnum].sa_len) < 0) {
> > #endif
> >
> > And then skipping the sending of that data later...
> >
> > Ben.
>
>
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
Re: TCP Fast Open (TFO) in Traffic Server
Posted by Bryan Call <bc...@yahoo-inc.com>.
I don't know how you implemented it in traffic server, but in traffic server we do a setsockopt on the listening socket and there is a configuration option to add additional options. This part would need to change and another configuration option should be added for the queue size.
Happy to see TFO support being added. I have been wanting to play around with TFO for awhile.
-Bryan
On Jan 23, 2014, at 8:22 AM, Ben <be...@meh.net.nz> wrote:
> 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?
>
> if you want to implement tcp fast open listening in traffic server, i've got a really hackish kludge to http_load to support tcp fast
> open, and it doesn't look as hard as it probably is in the main trafficserver.
>
> without tcp fast open:
> <ben@amethyst:/src/trafficserver-svn/tools/http_load>
> zsh/2 3093 (git)-[master]-% ./http_load -parallel 2 -fetches 50 /tmp/urlfile
> 50 fetches on 50 conns, 1 max parallel, 8850 bytes, in 0.66447 seconds
> 177 mean bytes/fetch
> 75.2479 fetches/sec, 13318.9 bytes/sec
> msecs/connect: 13.0597 mean, 16.855 max, 11.127 min
> msecs/first-response: 13.4596 mean, 17.641 max, 11.97 min
> HTTP response codes:
> code 200 -- 50
>
> with tcp fast open:
> [Thu 14/01/23 20:15 NZDT][pts/40][x86_64/linux-gnu/3.13.0-rc7ice][5.0.5]
> <ben@amethyst:/src/trafficserver-svn/tools/http_load>
> zsh/2 3094 (git)-[master]-% ./http_load -parallel 2 -fetches 50 /tmp/urlfile
> 50 fetches on 50 conns, 1 max parallel, 8850 bytes, in 0.355519 seconds
> 177 mean bytes/fetch
> 140.639 fetches/sec, 24893.2 bytes/sec
> msecs/connect: 0.00864 mean, 0.018 max, 0.002 min
> msecs/first-response: 14.0743 mean, 15.28 max, 11.833 min
> HTTP response codes:
> code 200 -- 50
>
> i don't really know how the parallel command is meant to work. and that's a near empty page and against lighttpd with my local modifications
> for tcp fast open listening.
>
>
> i dunno the best way to go about it, i'm forcing doublechecking code in handle_connect and moving all the connecting logic there, as that
> simplifies
>
> And basically doing:
>
> #ifdef TCP_FASTOPEN
> if (sendto (connections[cnum].conn_fd, urls[url_num].buf, urls[url_num].buf_bytes, MSG_FASTOPEN, (struct sockaddr *) &connections[cnum].sa, connections[cnum].sa_len) < 0) {
> #else
> if (connect(connections[cnum].conn_fd, (struct sockaddr *) &connections[cnum].sa, connections[cnum].sa_len) < 0) {
> #endif
>
> And then skipping the sending of that data later...
>
> Ben.
Re: TCP Fast Open (TFO) in Traffic Server
Posted by Ben <be...@meh.net.nz>.
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?
if you want to implement tcp fast open listening in traffic server, i've got a really hackish kludge to http_load to support tcp fast
open, and it doesn't look as hard as it probably is in the main trafficserver.
without tcp fast open:
<ben@amethyst:/src/trafficserver-svn/tools/http_load>
zsh/2 3093 (git)-[master]-% ./http_load -parallel 2 -fetches 50 /tmp/urlfile
50 fetches on 50 conns, 1 max parallel, 8850 bytes, in 0.66447 seconds
177 mean bytes/fetch
75.2479 fetches/sec, 13318.9 bytes/sec
msecs/connect: 13.0597 mean, 16.855 max, 11.127 min
msecs/first-response: 13.4596 mean, 17.641 max, 11.97 min
HTTP response codes:
code 200 -- 50
with tcp fast open:
[Thu 14/01/23 20:15 NZDT][pts/40][x86_64/linux-gnu/3.13.0-rc7ice][5.0.5]
<ben@amethyst:/src/trafficserver-svn/tools/http_load>
zsh/2 3094 (git)-[master]-% ./http_load -parallel 2 -fetches 50 /tmp/urlfile
50 fetches on 50 conns, 1 max parallel, 8850 bytes, in 0.355519 seconds
177 mean bytes/fetch
140.639 fetches/sec, 24893.2 bytes/sec
msecs/connect: 0.00864 mean, 0.018 max, 0.002 min
msecs/first-response: 14.0743 mean, 15.28 max, 11.833 min
HTTP response codes:
code 200 -- 50
i don't really know how the parallel command is meant to work. and that's a near empty page and against lighttpd with my local modifications
for tcp fast open listening.
i dunno the best way to go about it, i'm forcing doublechecking code in handle_connect and moving all the connecting logic there, as that
simplifies
And basically doing:
#ifdef TCP_FASTOPEN
if (sendto (connections[cnum].conn_fd, urls[url_num].buf, urls[url_num].buf_bytes, MSG_FASTOPEN, (struct sockaddr *) &connections[cnum].sa, connections[cnum].sa_len) < 0) {
#else
if (connect(connections[cnum].conn_fd, (struct sockaddr *) &connections[cnum].sa, connections[cnum].sa_len) < 0) {
#endif
And then skipping the sending of that data later...
Ben.
Re: TCP Fast Open (TFO) in Traffic Server
Posted by Bryan Call <bc...@yahoo-inc.com>.
If you want to implement it, you can submit a patch to the ticket you created.
-Bryan
On Jan 22, 2014, at 1:18 PM, Alex Garzão <al...@azion.com> 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?
>
> Regards.
>
> --
> Alex Garzão
> Projetista de Software
> Azion Technologies
> alex.garzao (at) azion.com
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.
Re: TCP Fast Open (TFO) in Traffic Server
Posted by Ben <be...@meh.net.nz>.
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,
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?
Regards.
--
Alex Garzão
Projetista de Software
Azion Technologies
alex.garzao (at) azion.com
Re: TCP Fast Open (TFO) in Traffic Server
Posted by Ben <be...@meh.net.nz>.
On Mon, Jan 20, 2014 at 09:18:02AM -0800, James Peach wrote:
> On Jan 20, 2014, at 8:27 AM, Alex Garz?o <al...@azion.com> wrote:
>
> > Hello,
> >
> > Are any plans to support TCP Fast Open (TFO) in ATS?
>
> I'm not aware of anyone currently working on this.
>
> On my reading of the kernel docs, you can enable TFO on all listen sockets automatically; that should let you experiment without any ATS changes. If you want ATS to set the TCP_FASTOPEN socket option, that's a pretty easy change; you'd want to plumb a configuration variable to enable that though. Could you file a ticket at https://issues.apache.org/jira/browse/TS?
>
> J
I was meaning to say something about this the other day, but I was sleep-deprived, and then didn't get around to it. So I'll give a brain dump now rather than stay quiet.
I've already played around with TCP Fast Open a bit but not in TrafficServer. I've got as far as modifying wget and my own microcurl implementation to support sending TCP Fast Open
requests and modifying the lighttpd web server to accept TCP Fast Open requests.
I ran into an issue with kernel headers not having support for TCP Fast Open - and manually kludging. I also checked around a bit, and couldn't find any servers other than a few google
ones that support TCP Fast Open. www.google.com, www.gmail.com being prime examples. Chrome/chromium are existing clients around, but obviously not as easy to do controlled testing
from.
When using Google Chrome it's quite obvious the difference in performance even just viewing Cacti graphs remotely. But sometimes requesting files seemed to not be any faster - I am
suspecting that there could be some kind of shaping systems that expecting the bandwidth usage to slowly go up rather than the initial reponse to be a burst of packets - but I didn't
look into it further, and it didn't seem to be all the time.
I didn't come across anything about accepting all listen sockets automatically, but that sounds interesting. From what I gather most problems are dictated by the client, the primary
concern being that PUT/POST requests could double-up. From what I gathered last time Chrome hasn't been fixed yet to support not using TCP Fast open for such requests, and also hasn't
been enabled for using TCP Fast Open for explicit proxies.
Unfortunately my current development environment involves using an explicit proxy over a local area network connection which won't benefit much from server-side tcp fast open, and would
mean kludging the data to take another path to use transparent proxying still to little advantage other than testing that it's not breaking. And so I'm more interesting in looking to
get initiating TCP Fast Open connections going rather than hosting them.
Which means that the other problem comes up, which means you have to make sure the data path can easily support initating connections whilst already having the data of the request to
make. I haven't looked into TrafficServer deep enough to see how hard this is but I jumped from curl to wget as a test client, as wget made it easier.
The listening part is basically simple - an optimisation can be done to see if the request is already available when the TCP connection is accepted, but even without that, an extra go
about on a select/poll loop will still lead to better performance than no tcp fast open support. And as far as setting the socket option, I'd like to see an arguement per socket just
to try enabling it with a fallback path.
It'd also be useful to see support in http_load. I supppose starting with global enable on tcp fast open enable, and then adding support to http_load would be a good starting point.
Ben.
Re: TCP Fast Open (TFO) in Traffic Server
Posted by James Peach <jp...@apache.org>.
On Jan 20, 2014, at 8:27 AM, Alex Garzão <al...@azion.com> wrote:
> Hello,
>
> Are any plans to support TCP Fast Open (TFO) in ATS?
I'm not aware of anyone currently working on this.
On my reading of the kernel docs, you can enable TFO on all listen sockets automatically; that should let you experiment without any ATS changes. If you want ATS to set the TCP_FASTOPEN socket option, that's a pretty easy change; you'd want to plumb a configuration variable to enable that though. Could you file a ticket at https://issues.apache.org/jira/browse/TS?
J