Quick Summary
- TCP is connection-oriented: it opens a connection with three messages before any data flows
- The three steps are SYN (client), SYN-ACK (server), and ACK (client) -- after them both ends are ESTABLISHED
- The handshake synchronizes each side's initial sequence number and proves both directions of the link work
The Polite Phone Call Analogy
Imagine calling a friend. You do not just start talking the instant the line connects -- you check that they are actually there and can hear you. The exchange goes something like: "Can you hear me?" -- "Yes, can you hear me?" -- "Yes!" Only after those three confirmations does the real conversation begin.
That little ritual is exactly what TCP does. TCP is a connection-oriented, reliable protocol, which means it never blindly fires data into the void. Before a single byte of your web page, email, or file transfer moves, the two computers complete a three-way handshake to make sure both sides can send and receive.
Why three messages and not two? Because each direction of the conversation has to be confirmed on its own. The first two messages prove the client can reach the server, and the last two prove the server can reach the client. Two messages would only ever confirm one direction -- so TCP needs a third to close the loop.
The handshake does two jobs at once. It synchronizes initial sequence numbers (the counters TCP uses to keep bytes in order and detect anything lost), and it confirms bidirectional reachability. Get this right, and everything built on top of TCP -- the web, email, SSH, database connections -- just works.
The Three Messages at a Glance
Here is the whole handshake in one picture. The client starts with an initial sequence number of x, the server with y. Watch how each ack is simply "the number I received, plus one":
Animated TCP Handshake Stepper
Press Next step to advance the handshake. Watch each message travel, see the exact flags and sequence numbers, and follow how each side's TCP state changes.
Notice the arithmetic. The server's ack=1001 is just the client's seq=1000 plus one --
it means "I received everything up to byte 1000, send me 1001 next." Likewise the client's final
ack=5001 is the server's seq=5000 plus one. Sequence numbers count bytes,
and the SYN flag itself consumes one number, which is why we add one.
The Handshake Step by Step
SYN: The Client Knocks
The client sends a TCP segment with the SYN (synchronize) flag set and its own
initial sequence number, for example seq=1000. No application data rides
along yet. The moment it sends this, the client moves from CLOSED to the
SYN-SENT state and waits for a reply. This is the networking equivalent of "Can you hear me?"
SYN-ACK: The Server Answers
The server, which was sitting in the LISTEN state, replies with a single segment that has
both the SYN and ACK flags set. It picks its own initial sequence number
(seq=5000) and acknowledges the client by setting ack=x+1 (here
ack=1001). The server now enters SYN-RECEIVED. This says "Yes, I hear you --
and can you hear me?"
ACK: The Client Confirms
The client replies with a segment carrying the ACK flag and ack=y+1
(here ack=5001), acknowledging the server's sequence number. Both ends are now in the
ESTABLISHED state. The final "Yes!" is complete, both directions are confirmed, and the
real data exchange can begin -- often the client's very next packet already carries the HTTP request.
Closing: The FIN Goodbye
Tearing a connection down is a separate ritual, usually described as a four-way handshake. One side sends FIN, the other ACKs it, then sends its own FIN, which is ACKed in return. The side that closed first typically lingers in TIME-WAIT for a short while to absorb any straggling packets before the connection is fully forgotten. UDP, by contrast, has no handshake at all -- it just sends.
Where You Meet the Handshake
You trigger three-way handshakes constantly without noticing. Here are three everyday examples:
Loading a Web Page
Every time your browser opens an https:// connection to a server on port 443, it first
completes a TCP three-way handshake. Only after the connection is ESTABLISHED does the TLS
handshake -- and then the actual HTTP request -- ride on top of it.
Connecting Over SSH
When you run ssh server, the very first packets on the wire are SYN, SYN-ACK, and ACK to
port 22. If a firewall silently drops the SYN, you see the connection "hang" -- the handshake never
finishes, so SSH never gets its reliable channel.
Reading a Capture
Open any packet capture in a tool like Wireshark and you will spot the pattern instantly: a SYN, a SYN-ACK, then an ACK, all at the start of a flow. Recognizing it is one of the fastest ways to tell a healthy connection from a stalled one.
Common Mistakes and Misconceptions
The handshake is simple, but a few myths trip people up. Watch out for these:
Thinking Two Messages Are Enough
A common assumption is that a request and a reply (two messages) should suffice. But two messages only confirm one direction of the link. TCP needs the third ACK so the server knows the client received its sequence number too -- otherwise the reverse path is never verified.
Confusing SYN Flood with Normal Traffic
A SYN flood is a denial-of-service attack: the attacker sends a torrent of SYNs and never sends the final ACK, leaving the server holding half-open connections until it runs out of resources. The fix is usually SYN cookies, which let the server stay stateless until the handshake actually completes -- do not mistake a flood for healthy load.
Expecting a Handshake from UDP
UDP is connectionless -- it has no handshake, no sequence numbers, and no built-in acknowledgments. If you are debugging DNS, a video call, or a game and looking for a SYN, you will never find one. Reliability there, if any, is handled by the application, not by UDP itself.
The Flags That Drive It All
Everything above comes down to a handful of one-bit control flags in the TCP header. SYN opens a connection and synchronizes sequence numbers. ACK acknowledges received data by reporting the next byte expected. FIN gracefully closes one direction of the connection. And RST abruptly resets it -- you will see a RST when, for example, you try to connect to a port where nothing is listening, and the other side replies "go away" instead of completing the handshake.
Why the Handshake Makes TCP Reliable
Because both sides agree on starting sequence numbers up front, TCP can number every byte that follows. If a segment goes missing, the gap in the sequence numbers reveals it and the data is retransmitted. If segments arrive out of order, the numbers let the receiver reassemble them correctly. None of that would be possible without the synchronization the three-way handshake provides at the very start.
The bottom line: the TCP three-way handshake is the polite phone call that opens every reliable connection on the internet. SYN, SYN-ACK, ACK -- three small messages that confirm both directions and line up the counters, so the conversation that follows is ordered, complete, and trustworthy.
Frequently asked questions about the TCP three-way handshake
What is the TCP three-way handshake?
The TCP three-way handshake is the process that opens a TCP connection before any data is sent. It uses three segments: the client sends SYN, the server replies with SYN-ACK, and the client replies with ACK. After these three steps both ends are in the ESTABLISHED state and can exchange data reliably.
Why does TCP need three steps instead of two?
Each direction of the connection must be confirmed separately. The SYN and the server's ACK prove the client can reach the server; the server's SYN and the client's ACK prove the server can reach the client. Two messages would confirm only one direction, so a third message is required to synchronize both initial sequence numbers and confirm reachability both ways.
What are SYN and ACK?
SYN and ACK are control flags in the TCP header. SYN (synchronize) requests a new connection and carries an initial sequence number. ACK (acknowledge) confirms receipt of data or a SYN by setting the acknowledgment number to the next byte it expects. The middle segment of the handshake sets both flags at once and is called SYN-ACK.
What is a SYN flood attack?
A SYN flood is a denial-of-service attack in which an attacker sends many SYN segments but never sends the final ACK. The server keeps half-open connections in the SYN-RECEIVED state, consuming memory until it can no longer accept real connections. SYN cookies are a common defense because they let the server stay stateless until the handshake completes.
How is a TCP connection closed?
Closing uses a separate FIN/ACK exchange, often described as a four-way handshake. One side sends FIN, the other ACKs it and later sends its own FIN, which is ACKed in return. The side that closed first usually enters a TIME-WAIT state for a short period to make sure any delayed segments are flushed before the connection is fully gone.
See connection state at work
You just learned how SYN, SYN-ACK, and ACK open a connection. Now trace a TCP connection through a stateful and a stateless firewall, see where the stateless one drops the server's reply, and write the return rule it needs. The lab does not capture packets, so the individual flags stay in the stepper above.
Launch the network lab →