Eliminating the Handshake Tax
Every TCP connection begins with a three-way handshake: SYN → SYN-ACK → ACK. Only after this exchange can the client send its first byte of application data. On a 170ms RTT link, this means every new connection pays a 170ms tax before a single byte of useful data moves. For a web page that opens 20–50 TCP connections, this adds up to seconds of wasted time.
TCP Fast Open (TFO), standardized in RFC 7413, eliminates this tax for repeat connections by allowing data to be sent inside the SYN packet itself.
How TFO works:
First connection (cookie acquisition):
1. Client sends SYN with a TFO option requesting a cookie.
2. Server generates a cryptographic cookie (keyed to the client's IP address) and returns it in the SYN-ACK.
3. Client stores the cookie for future connections.
Subsequent connections:
1. Client sends SYN + TFO cookie + HTTP request data (all in one packet).
2. Server validates the cookie, accepts the data immediately, and begins processing the request.
3. Server sends SYN-ACK + response data.
4. The handshake completes in parallel with the application exchange.
Net result: One full RTT eliminated from every repeat connection.
TFO is off by default and is enabled per kernel with a setting that controls whether it applies as a client, a server, or both.
Security consideration: TFO data arrives before the handshake is complete, meaning the server processes data from a source whose IP has not yet been confirmed via the ACK. The cookie mitigates replay attacks (a replayed SYN with stale data will be processed at most once), but TFO is not appropriate for non-idempotent requests. HTTP GET requests are safe; POST requests that trigger side effects are not. Most TFO implementations in HTTP stacks handle this automatically by only using TFO for safe methods.
Interviewers sometimes ask: "What are the security risks of TCP Fast Open?" The key answer is that TFO data can be replayed — an attacker who captures a SYN+cookie+data packet can retransmit it. The cookie limits this to a single replay (the server will reject a second use of the same cookie), but non-idempotent operations (like a payment POST) could be triggered once by a replay. The correct mitigation is to only use TFO for idempotent operations, which HTTP/1.1 GET and HEAD requests are by definition.
Key Point: TFO saves one full RTT per repeat connection by piggybacking application data on the SYN packet. It is most impactful on high-latency links and applications that open many short-lived connections, such as HTTP/1.1 APIs.