On Fri, Dec 20, 2013 at 10:06:59PM +0100, Alex wrote:
> On 2013-12-20 21:19, Maxim Konovalov wrote:
> > On 12/19/13 1:59 PM, athalas wrote:
> >> Where would we find documentation on the "fastopen" parameter?
> >>
> > http://nginx.org/r/listen
>
> In the documentation above it's pointed out that the server needs to
> tolerate the possibility of receiving duplicate initial SYN segments. I
> am not exactly sure on what level I would ensure that the server
> performs properly in this regard. According to the draft on TFO
> (http://tools.ietf.org/html/draft-cheng-tcpm-fastopen-00.html), 2.1.:
>
> Rather than trying to capture all the dubious SYN packets to make TFO
> 100% compatible with TCP semantics, we've made a design decision
> early on to accept old SYN packets with data, i.e., to allow TFO for
> a class of applications that are tolerant of duplicate SYN packets
> with data, e.g., idempotent or query type transactions. We believe
> this is the right design trade-off balancing complexity with
> usefulness. There is a large class of applications that can tolerate
> dubious transaction requests.
>
> For this reason, TFO MUST be disabled by default, and only enabled
> explicitly by applications on a per service port basis.
>
> Wouldn't it be the responsibility of nginx (the application) to handle
> duplicate SYNs?

It's the property of the Web application, not the server (nginx).

Please see section 3.1 of
http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/37517.pdf
for a less formal explanation of when it's safe to enable TFO:

: We found that to manage stale or duplicate SYN packets would
: add significant complexity to our design, and thus we decided
: to accept old SYN packets with data in some rare cases; this
: decision restricts the use of TFO to applications that are
: tolerant to duplicate connection / data requests. Since a
: wide variety of applications can tolerate duplicate SYN packets
: with data (e.g. those that are idempotent or perform query-style
: transactions), we believe this constitutes an appropriate tradeoff.

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx