TCP Fast Open (TFO) mechanism is described in https://tools.ietf.org/html/rfc7413
Other considerations can be found in this white paper.
TFO is currently available available on Linux (full implementation in 4.1), OS X 10.12 and server side will be available for FreeBSd 10/11. There are differences between the implementations described below.
Patches for ldns, NSD and Unbound can be found in our Stash repo, which currently support TFO as implemented on Linux.
https://portal.sinodun.com/stash/projects/TDNS/repos/tcp_fast_open_patches/browse
Note that getdns 1.0 supports TFO on Linux and OS X.
To use these patches:
Download the source code from the relevant repository
Apply the relevant patch
IMPORTANT! Run autoreconf
Add –enable-tcp-fastopen to the configure options
make & make install as normal
TCP fastopen [I-D.ietf-tcpm-fastopen] (TFO) allows data to be
carried in the SYN packet (and optionally in the SYN-ACK). It therefore
saves up to one RTT compared to standard TCP. TFO clients request a
server cookie in the initial SYN packet at the
start of a new connection. The server returns a cookie in its SYN-ACK.
The client caches the cookie and reuses it when opening subsequent
connections to the same server. The cookie is stored by the client’s TCP
stack (kernel) and persists if either the client or server processes are
restarted. TFO also falls back to a regular TCP handshake gracefully.
Requesting Fast Open Cookie in connection 1:
TCP A (Client) TCP B(Server)
______________ _____________
CLOSED LISTEN
#1 SYN-SENT ----- <SYN,CookieOpt=NIL> ----------> SYN-RCVD
#2 ESTABLISHED <---- <SYN,ACK,CookieOpt=C> ---------- SYN-RCVD
(caches cookie C)
Performing TCP Fast Open in connection 2:
TCP A (Client) TCP B(Server)
______________ _____________
CLOSED LISTEN
#1 SYN-SENT ----- <SYN=x,CookieOpt=C,DATA_A> ----> SYN-RCVD
#2 ESTABLISHED <---- <SYN=y,ACK=x+len(DATA_A)+1> ---- SYN-RCVD
#3 ESTABLISHED <---- <ACK=x+len(DATA_A)+1,DATA_B>---- SYN-RCVD
#4 ESTABLISHED ----- <ACK=y+1>--------------------> ESTABLISHED
#5 ESTABLISHED --- <ACK=y+len(DATA_B)+1>----------> ESTABLISHED
Adding support for this to existing name server implementations is relatively easy, but does require source code modifications. It is also controlled via various kernel parameters documented below.
On the client, the call to connect() is replaced with a call to sendmsg() or sendto() with the flags parameter set to MSG_FASTOPEN.
For non-blocking socket it returns the number of bytes buffered and sent in the SYN packet.
If the cookie is available it will send the data before returning.
If the cookie is not available locally, it returns -1 with errno EINPROGRESS, and sends a SYN with TFO cookie request automatically. The caller needs to write the data again when the socket is connected with a call to send() or similar.
Subsequent writes on this socket must also be done with send() or similar. A subsequent call with sendto() will return the error EISCONN.
connectx(fd, &endpoints, SAE_ASSOCID_ANY,
CONNECT_DATA_IDEMPOTENT | CONNECT_RESUME_ON_READ_WRITE,
NULL, 0, NULL, NULL)
The Linux implementation follows the pattern suggested in the appendix of the RFC for maximum backwards compatibility, however the OS X API offers some advantages because TFO can be used in conjunction with libraries that require a ‘connected’ file descriptor to be available (e.g. OpenSSL). The hope is the Linux API will be extended to offer both modes (no FreeBSD client implemented yet).
The kernel parameter net.ipv4.tcp_fastopen controls TFO and since 4.1 has been set to 1 by default. This enables client mode but not server mode. To act in pure server mode set the integer value to 2. To enable both client and server mode, set it to 3, for example:
sysctl -w net.ipv4.tcp_fastopen=2
The analogous kernel parameter is net.inet.tcp.fastopen but is set to 3 by default. The fastopen backlog and fallback minimum can also be set via kernel parameter.
The parameter net.inet.tcp.clear_tfocache can be used to reset the TFO back-off when problems are encountered (this can be helpful when testing).
The implementations have slightly different behaviour on the wire. Observations from testing include: