Skip to content
AdminKit

TCP Fast Open (TFO)

TCP Fast Open (TFO), defined in RFC 7413, lets a client send data in the SYN packet of a repeat connection to a server it talked to before, using a server-issued cookie to prove the request isn't forged, saving up to one round trip. AdminKit's port check tests whether a TCP port is reachable before TFO's latency saving even matters.

By AdminKit team, Netbase JSC · Updated

TCP Fast Open (TFO), defined in RFC 7413, is a TCP extension that lets a client include application data in the SYN packet of a repeat connection to a server it has connected to before, instead of waiting for the full SYN / SYN-ACK / ACK handshake to finish before sending its first byte of data. The mechanism relies on a cookie: on an initial connection, a client requests a TFO cookie from the server via a TCP option; the server issues one, and on later connections the client includes both the cookie and its early application data in the SYN packet itself. The server validates the cookie before accepting that early data as genuine, which is what stops an attacker spoofing a victim’s source address from forging a request — it can’t produce a cookie the server hasn’t already issued to the real client. A connection to a server the client has never talked to before always completes a normal handshake first, since there’s no cookie yet to present. TFO targets a different bottleneck than Multipath TCP (RFC 8684), which spreads one connection’s data across more than one network path rather than shortening the handshake itself, and a stalled handshake caused by an oversized packet is more often a path MTU discovery problem than anything TFO addresses. TFO’s SYN-based cookie exchange is conceptually related to the defense mechanism behind SYN cookies: both validate a piece of state carried in the SYN exchange before a server commits real resources to the connection.

TCP Fast Open is part of AdminKit’s IP & network cluster; the full AdminKit glossary lists other related terms.

Frequently asked questions

How does TCP Fast Open save time compared to a normal TCP handshake?

It lets a client send application data in the SYN packet of a repeat connection, instead of waiting for the SYN / SYN-ACK / ACK handshake to finish first, saving up to one round trip for connections to a server the client has talked to before.

What stops an attacker from forging the TFO cookie to open spoofed connections?

A server only accepts early data in a SYN if it carries a valid cookie the server itself issued to that client on an earlier connection, so an attacker spoofing a victim's source address can't produce a cookie the server hasn't already handed to the real client.

Does TCP Fast Open work on a brand-new connection to a server the client has never talked to?

No -- the first connection to a given server always completes a normal handshake so the client can obtain a TFO cookie; fast-open data can only be sent starting with later connections that present that cookie.

Is TCP Fast Open the same kind of optimization as Multipath TCP?

No -- Multipath TCP (RFC 8684) addresses a different bottleneck, spreading one connection's data across more than one network path, while TCP Fast Open targets the handshake latency of a single-path connection.