Table of Contents
Overview
The TCP three-way handshake is the process two devices use to establish a reliable connection before sending data. It is a short exchange of control messages that lets both sides agree on starting sequence numbers and confirm that the path between them works in both directions.
Purpose of the Three-Way Handshake
The handshake serves several important goals that are specific to TCP and its reliable nature. First, it allows both endpoints to synchronize their sequence numbers, which are used to order bytes of data in the connection. Second, it confirms that each side can both send and receive packets, so the connection is not one way. Third, it creates a clear start point for the connection, so old, delayed packets from previous connections are less likely to be mistaken for part of a new one.
Without a handshake like this, TCP could not reliably manage ordered, loss-checked data delivery between applications.
The Three Steps
The three-way handshake consists of three TCP segments exchanged between a client and a server. The client is the side that actively initiates the connection, and the server is the side that is passively listening on a port.
You will often see the three messages referred to as:
- SYN
- SYN-ACK
- ACK
In a typical example, the client wants to connect to a web server on TCP port 80 or 443.
Step 1: SYN
The client starts by sending a TCP segment with the SYN flag set to 1. This is often called the SYN segment.
In this first message the client proposes an initial sequence number, usually written as $ISN_{client}$. A sequence number is a 32-bit number that identifies bytes in the TCP stream. The SYN segment itself usually contains no application data, only TCP headers.
The main ideas in this step are:
The client says “I want to start a connection, and here is my starting sequence number.”
From a header point of view, this segment has:
- SYN flag set to 1
- ACK flag set to 0
- Sequence number equal to $ISN_{client}$
The server, if it is listening on the requested port, receives this SYN and moves to prepare a connection for this client.
Step 2: SYN-ACK
If the server accepts the connection, it responds with a second TCP segment that has both SYN and ACK flags set. This is called the SYN-ACK segment.
The server also chooses its own initial sequence number $ISN_{server}$. At the same time, it acknowledges the client’s SYN.
To acknowledge the client, the server sets the acknowledgment number to $ISN_{client} + 1$. The +1 is because the SYN flag itself consumes one sequence number, even though it usually carries no data.
From a header point of view, this segment has:
- SYN flag set to 1
- ACK flag set to 1
- Sequence number equal to $ISN_{server}$
- Acknowledgment number equal to $ISN_{client} + 1$
This step says: “I accept your request, here is my starting sequence number, and I confirm I received your SYN.”
Step 3: ACK
Finally, the client replies with a third TCP segment that has the ACK flag set to 1, and the SYN flag set to 0. This is commonly called the final ACK.
In this segment, the client acknowledges the server’s SYN by setting the acknowledgment number to $ISN_{server} + 1$.
From a header point of view, this segment has:
- ACK flag set to 1
- SYN flag set to 0
- Sequence number equal to $ISN_{client} + 1$ (the next number after its original SYN)
- Acknowledgment number equal to $ISN_{server} + 1$
After this ACK, both sides have:
- Sent their own initial sequence numbers
- Acknowledged the other side’s initial sequence number
At this point the TCP connection is considered established. The client can now send application data, which will start at its next sequence number, and the server can send data using its sequence space.
Example with Numbers
To make the process concrete, imagine a simple example where the client chooses $ISN_{client} = 1000$ and the server chooses $ISN_{server} = 5000$.
The exchange looks like this:
| Step | Sender | SYN | ACK | Seq Number | Ack Number | Meaning |
|---|---|---|---|---|---|---|
| 1 | Client | 1 | 0 | 1000 | (none) | Client asks to start, proposes 1000 |
| 2 | Server | 1 | 1 | 5000 | 1001 | Server accepts, proposes 5000, ACKs 1000 |
| 3 | Client | 0 | 1 | 1001 | 5001 | Client ACKs 5000, connection established |
The important increments are:
- Client’s SYN uses sequence 1000, so server acknowledges with 1001.
- Server’s SYN uses sequence 5000, so client acknowledges with 5001.
In a normal TCP three-way handshake:
- The first packet is SYN with sequence $ISN_{client}$.
- The second packet is SYN-ACK with sequence $ISN_{server}$ and acknowledgment $ISN_{client} + 1$.
- The third packet is ACK with sequence $ISN_{client} + 1$ and acknowledgment $ISN_{server} + 1$.
Connection States During the Handshake
TCP uses named states to keep track of what is happening during the handshake. The exact state names and transitions belong to TCP’s state machine as a whole, but it is useful here to see the basic roles during connection setup.
On the client side:
- Before sending SYN, the client is in the CLOSED state for that connection.
- After sending SYN, the client moves to SYN-SENT.
- After receiving SYN-ACK and sending the final ACK, the client moves to ESTABLISHED.
On the server side:
- Before any SYN arrives, the server listens on a port in the LISTEN state.
- After receiving the SYN and replying with SYN-ACK, the server is in SYN-RECEIVED.
- After receiving the final ACK from the client, the server moves to ESTABLISHED.
When both sides are in ESTABLISHED, normal data transfer can begin.
What Happens After the Handshake
Right after the three-way handshake, the next client packet can contain application data, such as an HTTP request, and will use the next sequence number after the client’s SYN. The server will acknowledge that data by sending ACKs with appropriate acknowledgment numbers. From this point on, the connection uses TCP’s reliable transmission mechanisms, such as retransmission and flow control, which are covered separately.
The three-way handshake is only the beginning of a TCP connection, but it defines a clear and synchronized starting point that all further communication relies on.