Why Does a TCP Client Send RST When SYN‑ACK Ack Number Mismatches?

In a typical TCP three‑way handshake, a client sends a SYN packet with an initial sequence number (e.g., seq=100). If an older SYN packet with a lower sequence number (e.g., seq=90) reaches the server first, the server will acknowledge that older SYN and reply with a SYN‑ACK whose acknowledgment number is 90+1.

When the client finally receives this SYN‑ACK, it notices that the acknowledgment number does not match the one it expects ( 100+1). To avoid establishing a connection based on stale state, the client immediately sends a RST packet to the server, indicating that the connection should be reset.

The server, upon receiving the RST, discards the old connection that was in the SYN_RECEIVED state. Later, the correct SYN packet (seq=100) arrives, and the normal three‑way handshake proceeds, establishing the TCP connection successfully.

This behavior illustrates one of the core reasons for the three‑way handshake: it prevents old or duplicate connection attempts from confusing the protocol state, ensuring reliable synchronization of sequence numbers.

Why not simply drop the unexpected SYN‑ACK? If the client were to discard the packet, both sides would wait for retransmissions, triggering timeout mechanisms that can take 10–20 seconds before the connection is finally closed. The stale server‑side connection would continue to occupy the four‑tuple, blocking the new connection from being confirmed because a server not in LISTEN state responds to any SYN with a challenge ACK rather than establishing a new connection.

Therefore, the client takes responsibility for terminating the old server connection by sending RST, allowing the new connection to be set up quickly.

Client sends SYN (seq=100).

Older SYN (seq=90) reaches server first; server replies with SYN‑ACK (ack=90+1).

Client receives mismatched SYN‑ACK and sends RST.

Server receives RST and drops the stale connection.

Correct SYN (seq=100) finally arrives; handshake completes.