How the TCP Three-Way Handshake Works
Before any data moves, TCP opens the connection with three messages. Follow the SYN, SYN-ACK and ACK across the two lifelines and see how client and server agree on where their data streams begin.
Before any data moves, TCP opens the connection with three messages. Follow the SYN, SYN-ACK and ACK across the two lifelines and see how client and server agree on where their data streams begin.
The three-way handshake is how TCP opens a connection. Before a client and server exchange any real data, they send three short messages — SYN, SYN-ACK and ACK — to agree on starting sequence numbers and confirm that each can reach the other.
TCP is a reliable, ordered protocol: it promises that data arrives complete and in order. The handshake is the first step that makes that promise possible, by synchronising the two directions of the conversation.
A handshake is a sequence in time, not a picture of a device. Two vertical lifelines and three arrows show exactly who says what, in which order, and where each message is coming from — the natural way to read a protocol exchange.
The client picks a random starting sequence number, x, and sends it in a SYN message. This is not a request for data — it is an offer: "my stream will begin at x; can we talk?" The client then waits, in the SYN-SENT state.
The server, which has been listening, replies. Its message does two jobs at once: it acknowledges the client by returning ack = x + 1, and it sends its own starting number y. Because it both synchronises and acknowledges, it is called a SYN-ACK.
The client acknowledges the server's number with ack = y + 1. This third message tells the server that the client received the reply, so now both directions of the link are confirmed to work.
As the messages cross, each endpoint moves through its states — closed, SYN-SENT, LISTEN, SYN-RECEIVED — until both arrive at ESTABLISHED. The states are how each side tracks where in the handshake it currently is.
Only after the third message does application data travel. From here on, every byte is numbered and acknowledged, so the receiver can reorder and detect gaps. The handshake itself is complete and is not repeated per packet.
Two would let the client confirm the server is reachable, but not confirm to the server that the client received its reply. The third message tells the server the client heard it, so both sides know the channel works in both directions before data is sent.
SYN means synchronise: it carries an initial sequence number to align the two data streams. ACK means acknowledge: it says the sender has received everything up to this point and expects the next number to be this. One message can be both, as in SYN-ACK.
TCP numbers every byte so the receiver can put them back in order and detect gaps. The handshake agrees on the starting numbers, so each side knows what to expect and can request retransmission if something is missing.
It is resent. If the SYN gets no reply the client retries after a timeout; if the final ACK is lost, the server resends its SYN-ACK. The handshake is itself reliable, so a lost message only costs time.
No. The handshake happens once, when the connection opens. After that, data packets flow without repeating it, until the connection is closed at the end.