[nsd-users] How does NSD use TFO (TCP Fast Open)?

[Anand Buddhdev]

On 09/06/2020 16:05, Wouter Wijngaards via nsd-users wrote:

Hi Wouter,

> NSD uses TCP fast open for servicing clients.  That is downstream
> connections.  It is an authoritative server.  If enabled NSD uses it for
> TCP streams, and also for TLS streams.

Okay, thanks. That's clear.

> No it does not.  NSD does perform session reuse, using the same tcp
> stream again for XFR requests from a server, or asking multiple XFRs at
> the same time.

Okay, also clear. Thank you.

>>> Does NSD generate and provide TFO cookies to clients that request them?
> 
> No, but I guess the system may do that, when TFO is enabled with a
> socket option.  But NSD can perform OCSP stapling with tls-service-ocsp,
> if you want that.

Correct. The TFO cookie is handled by the kernel, and not by individual 
applications.

>>> Is there any downside to enabling TFO? If not, why isn't it enabled by
>>> default?
> 
> The option is there because the functionality is not present in all
> kernels.  If you want it by default, that mostly depends on people with
> older kernels and how that fails, if our users have recent systems we
> could enable it by default I guess.
> 
> In many cases the user has to enable TFO support in the kernel of the
> system with admin commands, you can see them in documentation, and I
> think it is a surprise to enable the TFO in NSD by default for users
> that have not enabled it?

This is true. On our CentOS servers, for example, TFO is not on by 
default. It has to be enabled. Also, if we want TFO to work well, then 
all the servers behind a load-balancer must provide the same cookie.

As for the compile option... maybe it could just be on by default, so 
the code is compiled in. However, NSD would not turn it on at runtime, 
unless an option like "tcp-fast-open" is set to "yes".

The way it's currently coded, if NSD is compiled with tcp-fastopen, then 
it always tries to use it. I know it won't work unless the appropriate 
kernel option is set, but it leaves the user with no control. The ideal 
setup would be if the code were compiled it by default (unless 
explicitly disabled at compile time with --disable-tcp-fastopen), and 
then make NSD turn it on or off based on a config option.

Regards,
Anand