TCP Three-Way Handshake
Imagine you're a network engineer troubleshooting a slow application — or worse, studying for the CCNA 200-301 exam. The TCP three-way handshake is the foundation of reliable communication on the Internet. It's how every web page, email, and file transfer starts. Cisco tests this mechanism under exam objective 1.5 (Network Fundamentals) because understanding it is essential for analyzing packet captures, configuring firewalls, and diagnosing connectivity issues. Master this, and you'll have a huge advantage in both the exam and real-world networking.
Jump to a section
The Three-Way Handshake as a Phone Call
Think of the TCP three-way handshake like making a phone call between two people, Alice and Bob. Alice wants to have a conversation with Bob, but she needs to make sure Bob is ready and willing to talk. She picks up the phone and dials Bob's number — that's the SYN packet. The phone rings at Bob's end. Bob answers the call — that's the SYN-ACK. But wait: just answering doesn't guarantee the line is clear. Bob also says "Hello?" to confirm he hears Alice. Alice then replies "Hello, Bob!" — that's the ACK. Now both parties know the connection is established, and they can start their conversation (the data transfer). If Bob were busy, he'd send a busy signal (RST) instead of answering. If the phone rang and no one answered, Alice would hang up and try again later (timeout and retransmission). This analogy captures the essential sequence: SYN (dialing), SYN-ACK (answering with confirmation), ACK (final acknowledgment). Just like a phone call, TCP ensures both sides are ready before any actual data flows, preventing confusion and lost information.
How It Actually Works
What is the TCP Three-Way Handshake?
TCP (Transmission Control Protocol) is a connection-oriented protocol, meaning it establishes a virtual circuit between two endpoints before any data is exchanged. The three-way handshake is the process that sets up this connection. It ensures that both devices are present, willing to communicate, and have agreed on initial sequence numbers (ISNs) for reliable data transfer. Without this handshake, TCP would be unreliable — it's the mechanism that provides ordered, error-checked delivery.
Why Does It Exist?
The handshake solves three problems: - Synchronization: Both sides agree on starting sequence numbers, which are used to track bytes sent and acknowledge receipt. - Confirmation: The server knows the client exists and is ready to send data; the client knows the server is listening and ready to receive. - Resource Allocation: Both sides allocate buffer space and connection state before data flows, preventing wasted resources on half-open connections.
Step-by-Step Mechanism
The handshake involves three packets exchanged between a client and server. The client typically initiates (e.g., a web browser connecting to a web server).
Step 1: SYN (Synchronize) The client sends a TCP segment with the SYN flag set. This packet includes:
Source port (random ephemeral port, e.g., 49152)
Destination port (well-known port, e.g., 80 for HTTP)
Initial Sequence Number (ISN) — a random 32-bit number (e.g., 1000)
Window size (advertised receive buffer)
Maximum Segment Size (MSS) option (typically 1460 bytes for Ethernet)
The client enters SYN-SENT state.
Step 2: SYN-ACK (Synchronize-Acknowledge) The server receives the SYN, allocates resources, and replies with a segment that has both SYN and ACK flags set. This packet includes:
Acknowledgment Number = client ISN + 1 (e.g., 1001)
Server's own ISN (e.g., 2000)
Window size and MSS
The server enters SYN-RECEIVED state.
Step 3: ACK (Acknowledge) The client receives the SYN-ACK, increments its acknowledgment counter, and sends a segment with the ACK flag set. This packet includes:
Acknowledgment Number = server ISN + 1 (e.g., 2001)
Sequence Number = client ISN + 1 (e.g., 1001)
No data yet (pure ACK)
The client enters ESTABLISHED state. Upon receiving this ACK, the server also enters ESTABLISHED state. Data transfer can now begin.
Key States, Timers, and Defaults
- States: CLOSED, LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED (plus others for termination).
- Timers:
- SYN timeout: Default 60 seconds (on Cisco IOS, via ip tcp synwait-time; default is 30 seconds in some implementations).
- Retransmission: If SYN or SYN-ACK is lost, the sender retransmits after an exponential backoff (initial 1 second, then 2, 4, 8... up to 64 seconds).
- Defaults:
MSS for Ethernet: 1460 bytes (MTU 1500 minus IP header 20 minus TCP header 20).
Window size: 65535 bytes (can be scaled via window scaling option).
Sequence numbers: Random ISN to prevent spoofing (RFC 1948).
IOS CLI Verification Commands
To verify TCP connections on a Cisco router or switch, use:
Router# show tcp brief
TCB Local Address Foreign Address (state)
0x123456 192.168.1.1.80 10.0.0.2.49152 ESTABLISHEDFor detailed TCP connection info:
Router# show tcp tcb 0x123456
Connection state is ESTABLISHED, I/O status: 1, unread input bytes: 0
Local host: 192.168.1.1, Local port: 80
Foreign host: 10.0.0.2, Foreign port: 49152
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x1E2F3A4B):
Timer Starts Wakeups Next
Retrans 5 0 0x0
TimeWait 0 0 0x0
AckHold 3 2 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
iss: 1000 snduna: 1500 sndnxt: 1500 sndwnd: 16384
irs: 2000 rcvnxt: 2500 rcvwnd: 16384
SRTT: 300 ms, RTTO: 600 ms, RTV: 300 ms, KRTT: 0 ms
minRTT: 10 ms, maxRTT: 500 ms, ACK hold: 200 ms
Datagrams (max data segment is 1460 bytes):
Rcvd: 10 (out of order: 0), with data: 5, total data bytes: 500
Sent: 12 (retransmit: 0, fastretransmit: 0), with data: 6, total data bytes: 600Interaction with Related Protocols
TCP vs UDP: TCP uses the handshake; UDP does not. This makes TCP reliable but slower.
Firewalls and ACLs: Stateful firewalls track handshake state. A SYN packet without a corresponding SYN-ACK may be dropped if the firewall doesn't see the reverse flow.
NAT: NAT devices must rewrite sequence numbers and ports, which can interfere with the handshake if not handled properly (e.g., ALG).
DoS Attacks: SYN flood attacks exploit the handshake by sending many SYNs without completing the handshake, exhausting server resources. Mitigation includes SYN cookies.
Walk-Through
Client sends SYN
The client (initiator) chooses an ephemeral source port (e.g., 49152) and the destination port (e.g., 80 for HTTP). It generates a random Initial Sequence Number (ISN), say 1000. The TCP header has the SYN flag set to 1, ACK flag set to 0. The segment also includes options like MSS (1460 bytes). The client then enters the SYN-SENT state and starts a retransmission timer (default 1 second).
Server receives SYN, sends SYN-ACK
The server, in LISTEN state, receives the SYN. It allocates a Transmission Control Block (TCB) and sends a SYN-ACK segment. This segment has both SYN and ACK flags set. The acknowledgment number is the client's ISN plus 1 (1001). The server also picks its own ISN (e.g., 2000). The server enters SYN-RECEIVED state. If the server cannot allocate resources, it may send a RST instead.
Client receives SYN-ACK, sends ACK
The client receives the SYN-ACK. It checks that the acknowledgment number equals its ISN+1 (1001). It then sends an ACK segment with acknowledgment number = server ISN+1 (2001) and sequence number = client ISN+1 (1001). The ACK flag is set, SYN flag is 0. The client enters ESTABLISHED state. Upon receiving this ACK, the server also enters ESTABLISHED state.
Connection established, data transfer begins
Both sides are now in ESTABLISHED state. Data can be sent in both directions. The sequence and acknowledgment numbers are used to track bytes. For example, if the client sends 100 bytes, the next sequence number becomes 1101. The server acknowledges with ACK 1101. This ensures reliable delivery.
Verification with show commands
Use `show tcp brief` to see all TCP connections and their states. Use `show tcp tcb <tcb>` for detailed info on a specific connection, including sequence numbers, timers, and window sizes. This is useful for troubleshooting incomplete handshakes or performance issues.
What This Looks Like on the Job
In a typical enterprise network, the TCP three-way handshake happens thousands of times per second. For example, when employees access a web server in the data center, each HTTP request initiates a new TCP connection. A network engineer might configure a firewall to allow only established connections (stateful inspection). The firewall sees the SYN, SYN-ACK, ACK and creates a state entry. If an attacker sends a SYN packet without completing the handshake (SYN flood), the firewall may use SYN cookies or rate limiting to protect the server.
Another scenario: a network engineer troubleshoots a slow application by capturing packets with Wireshark. They see the three-way handshake but notice a delay between SYN-ACK and ACK. This could indicate a high round-trip time (RTT) or packet loss. They might adjust TCP timers or check for congestion.
When misconfigured, the handshake can fail. For example, if an access control list (ACL) blocks SYN packets but allows ACKs, the server will never receive the initial SYN, so no connection is established. Or if a firewall is not stateful, it may allow inbound SYNs but block returning SYN-ACKs, breaking the handshake. Understanding the handshake helps engineers design correct security policies.
In large-scale deployments, performance considerations include TCP window scaling (to use high-bandwidth links) and selective acknowledgments (SACK) for efficient retransmission. The handshake negotiates these options via TCP options in the SYN and SYN-ACK segments.
How CCNA 200-301 Actually Tests This
For CCNA 200-301 exam objective 1.5, you must be able to describe the three-way handshake, identify the flags in each step, and understand state transitions. The exam often presents a scenario where you must determine which packet is sent next or what state a connection is in.
Common wrong answers: 1. "The client sends SYN-ACK first" — wrong because the client sends SYN, not SYN-ACK. Candidates confuse the roles. 2. "The handshake uses only SYN and ACK, no SYN-ACK" — wrong because the second packet has both flags set. 3. "The connection is established after SYN-ACK" — wrong; it's established only after the final ACK is received by the server. 4. "Sequence numbers start at 0" — wrong; they are random ISNs (though Wireshark shows relative sequence numbers starting at 0 for readability).
Specific values to memorize: Default MSS for Ethernet = 1460 bytes. Default window size = 65535 bytes (without scaling). The SYN flag is only set in the first two packets. The ACK flag is set in the last two packets.
For scenario questions, use this decision rule: If a client wants to connect to a server, the first packet must be SYN from client. If you see a packet with both SYN and ACK, it must be from the server. If you see only ACK, it's the third packet or later data. If you see RST, the connection was rejected.
Be ready to interpret show tcp brief output: the state column shows ESTABLISHED, SYN-SENT, etc. A connection stuck in SYN-SENT means the client sent SYN but didn't get SYN-ACK (maybe firewall blocking). A connection in SYN-RECEIVED means the server got SYN but didn't get final ACK (maybe client didn't respond).
Key Takeaways
TCP three-way handshake: SYN, SYN-ACK, ACK — three packets to establish a connection.
SYN flag set only in first two packets; ACK flag set in second and third packets.
Initial Sequence Numbers (ISNs) are random 32-bit numbers.
Default MSS for Ethernet is 1460 bytes (MTU 1500 minus IP/TCP headers).
Default window size is 65535 bytes (without window scaling).
Show command: 'show tcp brief' to list connections and states.
Connection states: CLOSED, LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED.
SYN timeout default is 30-60 seconds; retransmission with exponential backoff.
Easy to Mix Up
These come up on the exam all the time. Here's how to tell them apart.
TCP Three-Way Handshake
Connection-oriented: establishes a virtual circuit before data transfer.
Three packets: SYN, SYN-ACK, ACK.
Reliable: sequence numbers, acknowledgments, retransmission.
Stateful: endpoints maintain connection state (ESTABLISHED, etc.).
Used for web, email, file transfer.
UDP Connectionless Communication
Connectionless: no handshake; data sent immediately.
No setup packets: just data packets.
Unreliable: no sequencing, no acknowledgments, no retransmission.
Stateless: no connection state maintained.
Used for streaming, DNS, VoIP.
Watch Out for These
Mistake
The client sends SYN-ACK as the first packet.
Correct
The client sends SYN; the server responds with SYN-ACK. The client never sends SYN-ACK.
Candidates mix up the roles because both sides send SYN at different times.
Mistake
The handshake is complete after the SYN-ACK packet.
Correct
The handshake is complete only after the client sends the final ACK and both sides enter ESTABLISHED state.
Candidates think two packets are enough because in a phone call, answering (SYN-ACK) seems to establish the call.
Mistake
Sequence numbers always start at 0.
Correct
Sequence numbers are randomly chosen ISNs (e.g., 1000, 2000). Wireshark shows relative sequence numbers starting at 0 for convenience.
Wireshark displays relative sequence numbers by default, leading to confusion.
Mistake
The ACK flag is set in all three handshake packets.
Correct
The ACK flag is set only in the second (SYN-ACK) and third (ACK) packets, not in the first SYN packet.
Candidates think ACK is always present because TCP is reliable, but the first SYN has no prior segment to acknowledge.
Do You Actually Know This?
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Frequently Asked Questions
What is the purpose of the TCP three-way handshake?
The purpose is to establish a reliable connection between two devices before data transfer. It synchronizes sequence numbers, confirms that both sides are ready, and allocates resources. Without it, TCP could not guarantee ordered, error-checked delivery. Exam tip: remember that the handshake is about synchronization and acknowledgment.
What are the flags used in the three-way handshake?
The flags are SYN (Synchronize) and ACK (Acknowledgment). The first packet has SYN=1, ACK=0. The second has SYN=1, ACK=1. The third has SYN=0, ACK=1. No other flags (like FIN or RST) are used in a normal handshake. Exam tip: know which packets have which flags.
What is an Initial Sequence Number (ISN) and how is it chosen?
The ISN is a random 32-bit number that starts the sequence number field for a TCP connection. It is chosen randomly to prevent spoofing and to avoid conflicts with previous connections. In packet captures, relative sequence numbers are often shown starting from 0, but the actual ISN is random. Exam tip: don't confuse relative with absolute.
What happens if a SYN packet is lost?
If the SYN is lost, the client will not receive a SYN-ACK. The client's retransmission timer will expire (default around 1 second), and it will resend the SYN. This continues with exponential backoff up to a maximum timeout (typically 60 seconds). If no response, the connection attempt fails. Exam tip: this is a common cause of connection timeouts.
How does a stateful firewall handle the three-way handshake?
A stateful firewall tracks the state of each connection. It sees the SYN from the client, creates a state entry, and allows the SYN-ACK back through if it matches the state. It then sees the final ACK and marks the connection as established. Subsequent packets are allowed if they match the state. If a packet doesn't match the expected state (e.g., an unsolicited SYN-ACK), it is dropped. Exam tip: firewalls use this to block spoofed traffic.
What is the difference between SYN flood and normal handshake?
A SYN flood is a DoS attack where an attacker sends many SYN packets with spoofed source IPs, never completing the handshake. The server allocates resources for each half-open connection, eventually exhausting memory. Normal handshake completes all three steps. Mitigation includes SYN cookies, where the server encodes the SYN-ACK info in the sequence number and doesn't allocate resources until the final ACK. Exam tip: know that SYN cookies avoid resource exhaustion.
Can the three-way handshake be used for both IPv4 and IPv6?
Yes, the TCP three-way handshake is identical for IPv4 and IPv6. TCP operates at Layer 4, independent of the Layer 3 protocol. The only difference is the IP header (20 bytes for IPv4, 40 bytes for IPv6). The MSS option may adjust based on the path MTU, but the handshake mechanism remains the same. Exam tip: no need to differentiate between IPv4 and IPv6 for this topic.
Terms Worth Knowing
Ready to put this to the test?
You've just covered TCP Three-Way Handshake — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?