Why TCP Needs a Three‑Way Handshake: The Secret Behind Reliable Connections

TCP Three‑Way Handshake Overview

The TCP three‑way handshake establishes a reliable, ordered connection between a client (Device A) and a server (Device B). It consists of three packet exchanges that mutually confirm readiness, agree on initial sequence numbers (ISNs), and allocate resources only after both sides have acknowledged each other.

Step 1 – SYN (Client → Server)

The client initiates the connection by sending a SYN packet:

SYN flag = 1 (identifies the packet as a connection‑initiation request)

seq = x – a randomly chosen initial sequence number for the client’s data stream

Other fields such as window size may be included but are not essential for the handshake logic.

Step 2 – SYN‑ACK (Server → Client)

Upon receiving the SYN, the server replies with a packet that has both SYN and ACK flags set:

SYN flag = 1 – the server’s own connection‑initiation

ACK flag = 1 – acknowledges the client’s SYN

seq = y – a randomly chosen ISN for the server’s data stream

ack = x+1 – tells the client that the next byte it should expect from the client is

x+1

Step 3 – ACK (Client → Server)

The client finalises the handshake by sending an ACK packet:

ACK flag = 1

ack = y+1 – confirms receipt of the server’s SYN‑ACK and indicates that the client will accept data starting at sequence y+1 seq = x+1 – the client’s next data byte number (the SYN consumed x)

Why Three Steps Are Required

A two‑step handshake (SYN → SYN‑ACK) leaves a “ghost invitation” problem: if the client’s final ACK is lost, the server cannot know whether the client is still present and may keep resources allocated for a non‑existent connection. The third ACK gives the server a definitive confirmation before committing buffers, thus preventing resource leakage and protecting against delayed or duplicate SYN packets.

Why a Fourth Handshake Is Unnecessary

Adding a fourth packet would merely repeat the final ACK from the server to the client, providing no new information while increasing latency and network traffic. The three‑step exchange already supplies mutual confirmation of readiness, sequence numbers, and acknowledgment numbers, achieving an optimal balance between safety and efficiency.

Key Technical Points

Both sides generate independent, random ISNs ( x and y) to avoid ambiguity in bidirectional data streams and to protect against old duplicate packets from previous connections.

The acknowledgment number always equals the received sequence number plus one, reflecting the next expected byte.

Resource allocation on the server side occurs only after the third ACK is received; otherwise, the half‑open state times out and is cleared.

After the handshake, the connection is ready for reliable, ordered data transfer, with each side aware of the other's numbering scheme and with both having confirmed that the peer is reachable.