Summary

  • RFC 7413 let a returning client send application data with a server-issued cookie in the SYN, allowing a server to process the request before TCP's three-way handshake finished.
  • The mechanism could save as much as one round trip, but SYN data could be replayed; applications unable to tolerate duplicate first requests were expressly excluded.
  • Fast Open therefore depended on more than a switch: cookie-key operation, limits on pending work, path-specific negative caching and an ordinary-handshake fallback were all part of the design.

The first packet normally asks a question only TCP can answer: may this connection begin? With TCP Fast Open, that packet could also carry the application's first request. On a path with a usable cookie, the server did not have to wait for the third handshake packet before placing those bytes in front of the application. The request arrived before the connection was fully confirmed.

That change was small in packet count and large in semantics. TCP's three-way handshake synchronizes sequence numbers, establishes state and helps separate a new connection from an old duplicate. RFC 7413, published as an Experimental specification in December 2014, deliberately relaxed one consequence of that boundary. Data in the SYN could be consumed during the handshake. For a short exchange, doing useful work one round trip earlier could matter more than optimizing the steady state of a long connection.

Fast Open did not make that first flight unconditional. A client first used an ordinary connection to request a cookie. The server returned an opaque message-authentication tag in the SYN-ACK, and the client cached it. On a later connection, the client placed the cookie and application data in its SYN. A server that validated the cookie could acknowledge the SYN and data, deliver the data to the application, and even send response bytes before the handshake completed. A server that rejected the cookie ignored the early data and continued with an ordinary handshake.

The cookie was a proof of recent reachability, not an application identity or authorization token. RFC 7413 describes it as a server-generated MAC normally tied to the source IP address. The TCP option can carry a cookie from 4 to 16 bytes. The client treats it as opaque; the server controls generation, validation and expiry. Rotating the secret key invalidates old cookies, while temporarily accepting more than one key can soften a rotation boundary. That makes key lifetime and overlap operational choices, not merely cryptographic details.

The central cost was replay. Ordinary TCP does not deliver SYN data to the application before the handshake because an old or duplicated SYN can survive the state that once explained it. Fast Open accepted that the first application bytes might occasionally be delivered more than once. The RFC therefore says TFO must not be enabled by default and must be requested per service port. A client or server that cannot tolerate duplicate SYN data must not use it.

This is why idempotency belongs in the transport story. A read-like request can often be repeated without changing durable state. A payment, mutation or unprotected POST cannot safely assume that one arrival means one execution. Application-level transaction identifiers can make repetition detectable, but the cookie itself does not provide exactly-once processing. The saved round trip is earned only when the application understands the semantics of the bytes it advances.

Pre-handshake work also changes the server's exposure. A valid cookie permits application processing before the client has completed the handshake. That can spend CPU, memory and response bandwidth earlier than ordinary TCP. RFC 7413 therefore defines a count of pending Fast Open requests and requires disabling Fast Open for new requests when the configured limit is exceeded. The fallback is intentionally conservative: discard the early data, acknowledge the SYN, and let ordinary SYN-flood defenses and the normal handshake regain control.

The network between endpoints could veto the optimization without understanding it. Some middleboxes drop SYN packets that contain payload or unfamiliar options. RFC 7413 tells a client whose SYN timer fires to retransmit without data and the Fast Open option. It also requires negative responses to be cached and recommends temporarily disabling TFO on the affected source-address, destination-address and port path. A fast path that repeatedly pays a timeout is not fast; remembering failure is part of the feature.

Even on a compatible path, the first application unit must fit in the available initial segment for the full benefit. TCP option space, the cached maximum segment size and the size of the request constrain what can advance. Large first messages still wait for later packets. Reusing established connections remains valuable, because a service built from too many short connections can spend more on setup and weaken congestion feedback even while each opening looks locally quicker.

The protocol history is therefore not a simple victory of fewer round trips. Fast Open moved an application decision across a transport boundary. In return for earlier work, the service had to know which requests could repeat, how cookie secrets changed, how much unconfirmed work it would admit, when a path had rejected the experiment and how quickly it could return to ordinary TCP. The durable contribution of RFC 7413 was to make that bargain explicit.

Sources