nginx-1.5.8

[Ruslan Ermilov]

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.