Ruslan Ermilov ru at
Sat Dec 21 09:53:20 UTC 2013

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?
> >>
> >
> 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
> (, 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
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.

More information about the nginx mailing list