How TCP Fast Open Uses a Cookie to Reduce Handshake Delay
TCP Fast Open can place data in a later connection’s SYN after a server cookie is obtained, potentially saving one RTT. The mechanism remains experimental and has replay, compatibility, and resource risks.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
TCP Fast Open (TFO) is a mechanism designed to send application data during TCP’s initial connection exchange. IETF RFC 7413 says that, when applicable, sending data earlier can save up to one round-trip time (RTT) compared with waiting for the ordinary three-way handshake. RFC 7413 is Experimental, not a Standards Track specification. It does not promise lower latency on every connection or immediate application processing by every server.
What changes from an ordinary TCP handshake
In ordinary TCP, a client sends SYN, receives SYN-ACK, and sends ACK to establish the connection; application data follows. For a short request, the RTT required to open a new connection can be a substantial part of the wait. With a valid server cookie, TFO lets a client include data and the cookie in a SYN. If the server accepts it, the data can reach the application and a response can start before the handshake is fully complete.
This is not a replacement for TCP or a way to remove every round trip. It moves the first application data earlier in the initial exchange. RFC 7413 describes a potential saving of up to one RTT when the conditions fit. The actual result depends on whether a connection is reused, request size, network path, server support, and intermediary behavior. Later communication proceeds as a normal TCP connection.
Obtain a cookie first, then reuse it
Before a client can perform TFO, it requests a cookie by sending a SYN with an empty Fast Open cookie field. A supporting server can return a cookie in the Fast Open option of SYN-ACK. The client caches it and can present it with data in a later SYN. After validating the cookie, the server may deliver that SYN data to the application and send response data before the handshake finishes.
The first connection to a server therefore does not automatically save an RTT; it may be used to obtain the cookie. The server can expire a cookie. The request must also fit the path and packet constraints. If SYN data is not acknowledged or an intermediary drops the option, the client may retransmit data in the ACK or fall back to a regular handshake. RFC 7413 addresses negative responses and timeouts so a client does not keep retrying an incompatible path indefinitely.
Applications must tolerate duplicate initial data
Because SYN data can reach an application before the connection is fully established, rare retransmission or duplicate-SYN cases can cause the application to see the same initial data more than once. RFC 7413 explicitly identifies this change in TCP semantics and warns against using TFO for operations that cannot tolerate replay.
A read-like request and an operation that could charge a card or create an order twice have different consequences. Applications need idempotent handling or duplicate detection where necessary. The performance opportunity does not make every request safe to process early.
Server controls, middleboxes, and security
RFC 7413 says TFO should not be enabled by default; an application must explicitly request it for a service port. The server validates cookies and limits pending Fast Open requests. Even a valid-cookie SYN consumes server resources, so excessive requests can create CPU and memory pressure. When a configured limit is reached, the server can temporarily fall back to ordinary TCP for new requests.
Firewalls, NATs, load balancers, and other middleboxes may drop SYN options or data. Along such a path the benefit may disappear or retransmission may add delay. Packet size and the initial congestion window also affect how much data can be sent. Before deployment, test compatibility, load limits, and fallback behavior on the actual service and path.
Expert perspective: separate protocol design from deployment status
RFC 7413 is an IETF Experimental document from December 2014. It specifies cookie exchange, early data acceptance, replay concerns, resource limits, and fallback. LWN’s 2012 technical article provides historical implementation context for the cookie flow and APIs; its statements about Linux rollout describe that period and are not evidence of current support on every operating system. Verify support in the current kernel, library, and server documentation and measure the actual path.
TFO is therefore an optional optimization that may move a suitable small request earlier on a returning path. Its value depends on request safety, implementation support, and network compatibility, which should be tested together.