The TCP three-way handshake, why three?

I believe we all heard at least once the term three-way handshake, it describes the process of opening a TCP connection in three steps:

  1. The client sends an SYN message to the server – indicates the desire of the client to open a connection.
  2. The server sends ACK+SYN messages to the client – indicates the server received the message and is now wants to open a connection with the client.
  3. The client sends ACK to the server – indicates that the client received the server ACK+SYN messages.

Take a look again at step 2, why it’s not enough for the server to return ACK to mark the connection as open? after all, sending ACK will tell the client that the message has been received by the server…

The answer to that relies on one of the most important properties of a TCP connection – reliability, which is the ability of the connection to preserve the order of the data sent between the parties.

To preserve the order of the data, both the client and the server generate a random number called the ISN (Initial Sequence Number), and every new message that is sent increments the sequence number by 1.

So back to our original question, at step one, the SYN message that the client sends contains the ISN of the client, so the server can keep track of the order of the messages that the client sends. At step two, the server sends ACK to acknowledge that he now knows the ISN of the client, and also sends an SYN message that contains the ISN of the server, so the client can keep track of the order of the messages that the server sends (Remember: TCP is a bi-directional protocol 🙂 ). Then at step thee the client sends ACK to the server so he can know that the client received its sequence number.

Notice that at step two the server sends ACK and SYN messages at the same packet, this is because the ACK and SYN are just binary flags inside the TCP header.

In conclusion, the SYN and ACK are sent only once, at each direction of the connection, and now both of the parties have the sequence number of each other which makes the connection reliable.

Food for thought: If the ISN will not be random but 0, we still don’t need the third step.
Why can’t it be 0? I’ll leave that for you 🙂
https://en.wikipedia.org/wiki/TCP_sequence_prediction_attack

Write a Comment