FUNDAMENTALS · MECHANISM WALKTHROUGH

TCP Three-Way Handshake
And What If the Third Packet Never Arrives

why it takes exactly three packets, not two — and the half-open state that exists in between, which is both a normal transient condition and the exact thing a SYN flood attack abuses.

SYN (CLIENT ISN)→ SYN-ACK (SERVER ISN)→ HALF-OPEN→ ACK→ ESTABLISHED→ IF ACK LOST: RETRANSMIT→ BACKOFF → GIVE UP

01 The Full Sequence — Worked Example

Client Sends SYN

The client (192.168.1.50:51234) sends a segment with the SYN flag set and a randomly chosen Initial Sequence Number (ISN) — randomized specifically so an attacker can't predict it and inject or hijack the session.

SYN

Server Allocates Half-Open State

The server (93.184.216.34:443) receives the SYN and allocates a small amount of memory in its SYN backlog for this specific pending connection — before it has any confirmation the client actually exists and will complete the handshake.

Backlog

Server Sends SYN-ACK

The server replies with its own SYN flag and its own randomized ISN, plus an ACK acknowledging the client's ISN+1. This is exactly why it's a three-way handshake, not two — each direction needs its own sequence number established and acknowledged independently.

SYN-ACK

Checkpoint — Half-Open, Waiting

Right now the server has committed backlog memory for a connection it hasn't fully confirmed. This transient state is completely normal under regular network latency — but it's also precisely the resource a SYN flood attack exploits: send many SYNs, never complete any of them, and exhaust the server's backlog until legitimate connections can't get a slot.

Checkpoint

Client Sends ACK — The Third Packet

The client receives the SYN-ACK and replies with an ACK acknowledging the server's ISN+1. This packet typically carries no data.

ACK

Connection Established

The server receives the ACK, moves the connection from the half-open backlog into its accept queue, and the application's accept() call can now return this socket. Both sides have synchronized sequence numbers; data can flow in either direction.

Established

Scenario — The Third Packet (ACK) Is Lost

Now the actual question: the client's ACK never reaches the server — dropped in transit, or the client crashed the instant after sending SYN. From the server's side, these two causes are indistinguishable; all it knows is it's still waiting.

Loss

Server Retransmits the SYN-ACK

After a retransmission timeout (RTO) — dynamically calculated from measured round-trip time, commonly starting around 1 second — the server assumes its own SYN-ACK might have been lost and retransmits it, still holding the half-open state.

Retransmit

Exponential Backoff and Eventual Timeout

If still no ACK arrives, the server retries a limited number of times (commonly 5 on Linux by default), doubling the wait between each attempt. After the final retry fails, the server gives up, tears down the half-open connection, and frees the backlog slot.

Backoff

The Nuance — Data Can Complete the Handshake Implicitly

If the client genuinely did receive the SYN-ACK and believes the connection is already established (only its outbound ACK was lost), it may start sending real data immediately. If that data arrives at the server carrying the correct acknowledgment number, many TCP stacks accept it as implicit confirmation and finalize the connection anyway — the handshake can self-heal without ever needing a bare, standalone ACK retransmission.

Self-Heal

The Security Angle — SYN Cookies

Because SYN flood attacks abuse exactly the half-open state from step 4, the standard defense is SYN cookies: instead of allocating real backlog memory on receiving a SYN, the server encodes the connection's necessary state into the SYN-ACK's own sequence number and allocates nothing until a valid ACK actually returns — eliminating the exhaustible resource the attack targets.

SYN Cookies

02 How to Explain This in an Interview

Say why it's "three-way," not "two-way," precisely. Both directions need an independently acknowledged sequence number — SYN, SYN-ACK, and ACK are each doing distinct acknowledgment work, not just a greeting handshake.
Name the half-open state before you're asked about the failure case. Bringing it up proactively, and connecting it to SYN flood attacks, shows you understand the mechanism's security implications, not just its happy path.
Be precise that the server can't distinguish "ACK lost" from "client crashed." Its behavior — retransmit, backoff, eventually give up — is identical either way, which is itself worth stating explicitly.
Mention the implicit-completion nuance if you have room. That real data can silently complete a handshake whose final ACK was lost is a genuinely advanced, often-overlooked detail.
Close the security thread with SYN cookies if it's a security-adjacent interview. It's the natural, expected follow-up to any half-open-state discussion.

03 Follow-Up / Gotcha Questions

Q Why does the server retransmit the SYN-ACK instead of just giving up immediately?

A Packet loss on the internet is a normal, expected occurrence, not necessarily a sign the client is gone — retrying gives a legitimate but momentarily-lossy connection a real chance to complete. Giving up on the very first missed ACK would make TCP connections fail constantly under completely ordinary network conditions.

Q What is a SYN flood, and how do SYN cookies actually defend against it?

A A SYN flood sends a high volume of SYNs, often from spoofed source addresses, and never completes any of them — exhausting the server's finite SYN backlog so legitimate connections can't get a slot. SYN cookies avoid allocating any real state at SYN time at all; the necessary information is encoded cryptographically into the SYN-ACK's sequence number itself, and only reconstructed if a valid ACK actually comes back — so there's no exhaustible resource to flood.

Q Can a connection actually complete even if the client's ACK is lost?

A Yes, in practice — if the client believes the handshake finished and sends real data right away, and that data reaches the server with a valid acknowledgment number, many TCP implementations treat it as sufficient proof the handshake completed and proceed normally, without ever needing to see a bare ACK segment specifically.

Q Why are initial sequence numbers randomized instead of just starting at a fixed value?

A A predictable ISN would let an off-path attacker guess or compute the sequence numbers needed to inject forged data into a connection or spoof one entirely, without ever seeing the actual traffic. Randomization (per RFC 6528) makes this kind of blind injection/hijacking attack impractical.

Q What's the difference between the SYN backlog and the accept queue?

A The SYN backlog holds half-open connections — SYN received, ACK not yet seen. The accept queue holds fully-established connections waiting for the application to call accept() and start using them. A connection moves from one queue to the other exactly at the moment its final ACK is received.

Q Does TCP Fast Open change any of this?

A TCP Fast Open allows a client that has previously connected to include actual application data in its very first SYN, using a cryptographic cookie from a prior connection to prove legitimacy — letting data flow before the handshake formally completes for repeat connections. It's an optimization layered on top of the same three-way structure, not a replacement for it, and only applies to hosts that have connected before.

04 Quick-Fire Glossary

Term	Meaning
ISN	Initial Sequence Number — randomized per connection to prevent prediction-based attacks
Half-Open Connection	A connection where SYN-ACK was sent but the final ACK hasn't been received yet
SYN Backlog	The queue of half-open connections a server holds pending state for
Accept Queue	The queue of fully-established connections waiting for the application to accept them
RTO	Retransmission Timeout — dynamically calculated from measured RTT, governs when to resend
Exponential Backoff	Doubling the wait time between successive retransmission attempts
SYN Flood	A DoS technique exhausting the SYN backlog by never completing handshakes
SYN Cookies	A defense encoding connection state into the SYN-ACK sequence number instead of allocating real backlog memory
TCP Fast Open	An optimization allowing data in the initial SYN for previously-seen connections
RFC 6528	The specification governing secure, randomized TCP initial sequence number generation