Why TCP Uses a Three‑Way Handshake (and How the Four‑Way Close Works)

Why TCP Uses a Three‑Way Handshake

Preventing stale connection requests is not the only reason; the real purpose is to reliably exchange initial sequence numbers. Both sides must know each other's starting sequence numbers to acknowledge received data, which cannot be achieved with just two messages.

TCP flag bits (6) :

SYN – synchronize connection

ACK – acknowledgment

PSH – push data

FIN – finish (close)

RST – reset

URG – urgent

Sequence number marks the position of the first byte of data in the overall data stream. Acknowledgment number indicates the next expected sequence number from the peer.

Three‑Way Handshake Steps (example numbers) :

First handshake: Host A sends SYN=1 with a random seq=1234567 to Host B.

Second handshake: Host B replies with SYN=1, ACK=1, ack=1234567+1, and its own random seq=7654321.

Third handshake: Host A sends ACK=1 with ack=7654321+1. After this, both sides have confirmed each other's initial sequence numbers and the connection is established.

Note: SYN and FIN consume one sequence number, while pure ACK does not increment the sequence number.

Four‑Way Termination

The TCP connection close requires four packets:

First FIN: the active closer sends a packet with FIN=1 and seq=X.

Second ACK: the passive side acknowledges with ack=X+1 and its own seq=Z.

Third FIN: the passive side later sends its own FIN=1 with seq=Y and ack=X.

Fourth ACK: the original closer acknowledges with ack=Y+1, completing the termination.

Timeout retransmission (RTO) occurs when an ACK is not received within a certain period, prompting the sender to resend the packet.

Discussion Points

Why does connection establishment need three handshakes while termination needs four?

Why must the TIME_WAIT state last for 2 MSL before moving to CLOSED?

Why can’t a two‑handshake protocol reliably establish a TCP connection?