A situation
Before you tell a friend something important on the phone, you check that they are there: “Hello, can you hear me?” “Yes, can you hear me?” “Yes.” Only then do you start talking. TCP does the same thing before it sends any data. This short exchange is the three-way handshake.
What it is
The handshake is made of three segments, each named after the flags it carries:
- SYN: the client asks to open a connection and sends its initial sequence number (ISN), the starting point for numbering its bytes.
- SYN-ACK: the server agrees. It sends its own ISN (SYN) and acknowledges the client's SYN (ACK).
- ACK: the client acknowledges the server's SYN. The connection is now open in both directions.
Press play to watch the handshake.
The numbers in each message
Real ISNs are large, hard-to-guess numbers. To keep this example readable, the client starts at 1000 and the server at 5000. Tap a message to see its fields.
- Client next byte:
- 1001
- Server next byte:
- 5001
Connection states
Each side keeps track of where it is in the process. This is called its connection state. You will see these names in netstat output and in firewall logs.
| State | Who | Meaning |
|---|---|---|
LISTEN | Server | Waiting for a SYN on a port |
SYN-SENT | Client | Sent a SYN; waiting for a SYN-ACK |
SYN-RECEIVED | Server | Received a SYN and sent a SYN-ACK; waiting for the final ACK |
ESTABLISHED | Both | Handshake done; data can flow both ways |
Why three messages?
Each side has its own sequence numbers, and each side must know that the other has received its starting number. That needs a SYN and an ACK in each direction: four jobs. The server puts its SYN and its ACK in the same segment, so the four jobs fit into three messages.
Random ISNs matter too. If every connection started at 0, an old, delayed segment from a previous connection could be mistaken for new data. A random starting number also makes it much harder for an attacker to guess the numbers and inject fake segments.
If nothing is listening on the port, the server replies to the SYN with an RST (reset) instead of a SYN-ACK. If a firewall silently drops the SYN, the client gets no reply at all. It sends the SYN again a few times, then gives up with a timeout.
How to verify it
A Cisco router can test whether a TCP port answers: run telnet with an IP address and a port number, and the router tries to open a TCP connection to that port. The output below is based on Cisco documentation, not captured from a lab device.
R1#telnet 203.0.113.10 443 Trying 203.0.113.10, 443 ... Open
disconnect.R1#telnet 203.0.113.10 8080 Trying 203.0.113.10, 8080 ... % Connection refused by remote host
Check yourself
A client opens a connection with a SYN that has sequence number 7000. Which acknowledgement number is in the server's SYN-ACK?
You test a web server on port 8080. Your client sends a SYN and immediately gets an RST back. What does this most likely mean?
A server has received a SYN and sent its SYN-ACK, but the client's final ACK has not arrived yet. Which state is the server in?