TCP 3-Way Handshake Explained — SYN, SYN-ACK, ACK (CCNA)

Every reliable connection on the internet — HTTPS to your bank, an SSH into a router, a file uploaded to Google Drive — starts with the same three packets. The TCP 3-way handshake is how two endpoints agree they can talk before either one sends real data.

CCNA candidates memorize SYN → SYN-ACK → ACK. That’s enough to pass a multiple-choice question. It’s not enough for the interview question every senior engineer eventually asks: “Why exactly three packets? Why not two? Why not four?”

This post answers that — and everything else you need to actually understand what Wireshark shows you when you capture a session.

The one-line idea

Both ends need to prove they can send and receive before they trust each other with real payload. Two packets prove one direction, four packets are wasteful, three is the minimum that proves both.

For the full protocol picture — segments, sliding windows, flow control — see the TCP vs UDP topic page. This post is the handshake specifically.

Why three packets — not two, not four

Think of it as a phone call.

Packet 1 — SYN (client → server). Client says “can you hear me? I’d like to start counting from sequence number 4823.”

Packet 2 — SYN-ACK (server → client). Server says two things at once: “yes, I heard you (ack your seq)” AND “can YOU hear me? I’d like to start counting from sequence number 9174.”

Packet 3 — ACK (client → server). Client says “yes, I heard your number too.”

Why not two? Because after two packets, the server has no confirmation that the client received the server’s initial sequence number. If packet 2 got lost, the server would think the session was up while the client had no idea. Data would go into a void.

Why not four? Because packet 2 does double duty — it acknowledges packet 1 AND opens the reverse direction. Splitting that into two packets adds an unnecessary round trip.

Three is the mathematical minimum that establishes bidirectional trust. That’s the interview answer.

What each packet actually carries

Every TCP segment has a header with these fields. The handshake uses a specific combination on each:

Two details that trip people up:

1. The initial sequence numbers (ISNs) x and y are random, chosen independently by each side. This isn’t cosmetic — it prevents an attacker from guessing them and injecting fake segments (this attack still exists; TCP ISN randomization is a defense).
2. The acknowledgment number x+1 means “I received your byte x, and I’m expecting x+1 next”. The +1 throws people off because SYN doesn’t carry data — but the SYN flag itself consumes one sequence-space slot.

What Wireshark actually shows

Capture any TCP session and you’ll see three back-to-back rows for the handshake. Here’s a real capture pattern (client 10.0.0.5 → server 172.20.1.10:443):

No. Time     Source        Dest         Protocol Info
1   0.000    10.0.0.5      172.20.1.10  TCP      55212 → 443 [SYN] Seq=0 Win=64240
2   0.031    172.20.1.10   10.0.0.5     TCP      443 → 55212 [SYN, ACK] Seq=0 Ack=1
3   0.031    10.0.0.5      172.20.1.10  TCP      55212 → 443 [ACK] Seq=1 Ack=1
4   0.032    10.0.0.5      172.20.1.10  TLSv1.3  Client Hello

Wireshark shows Seq=0 because it defaults to relative sequence numbers for readability — the raw ISN is a huge random number, and displaying Seq=3872910845 on every row is unreadable. Turn off relative mode (Edit → Preferences → Protocols → TCP → uncheck "Relative sequence numbers") if you want the real values.

Notice packet 4 — the TLS Client Hello — arrives 32 microseconds after packet 3. The handshake was complete, so real data started flowing immediately.

State transitions — the connection lifecycle

Each side of a TCP connection is a small state machine. During the handshake:

On a Cisco router, you can see this table live:

Router# show tcp brief
TCB       Local Address           Foreign Address        (state)
647A3B10  10.0.0.5.55212          172.20.1.10.443        ESTAB
647A3D40  10.0.0.5.55213          172.20.1.10.443        SYNSENT

The SYNSENT line is a session waiting for the server’s reply. If it sits there for 30 seconds, the SYN got lost or a firewall silently dropped it.

How the handshake fails (and what you’ll see)

Four common failure patterns, and how to spot each:

1. SYN sent, nothing back. Firewall dropping silently, or destination unreachable. On the client: SYNSENT in show tcp brief. Eventually a timeout. No RST from the server.

2. RST from server on the SYN. The port is closed. The server’s stack is up, but no application is listening on that port. Fix: start the service, or check you’re hitting the right port.

3. SYN-ACK never seen because of asymmetric routing. The server replied, but the return path goes through a different firewall that doesn’t have state and drops the reply. Fix in the network, not the endpoint.

4. Handshake completes, then the connection idles and dies. That’s not a handshake failure — that’s a firewall or NAT device aging out the session. Look at NAT & PAT translation timeouts if a stateful device is in the path.

The #1 mistake — assuming completed handshake means healthy session

A completed 3-way handshake only proves the two endpoints can exchange packets. It says nothing about:

• Whether the application on top of TCP is actually working (a listener might accept the socket then hang)
• Whether MTU is right (small packets can complete a handshake; large packets that need fragmentation might still fail — see MTU + fragmentation)
• Whether TLS will succeed (the TCP handshake is BEFORE the TLS handshake, which has its own failure modes)

If a curl test hangs after “connected”, the TCP handshake succeeded and the problem is above layer 4. Skip re-checking firewall rules — check the app.

The interview question that weeds out fake engineers

“A TCP client sends SYN. Two seconds later it sends another SYN with the same source port. What can you conclude?”

The fake answer: “The first SYN was retransmitted.”

The real answer: It’s not a retransmission — it’s a new attempt with the same 4-tuple (source IP, source port, dest IP, dest port). Retransmissions of the same SYN use the same sequence number and reset the retransmit timer; a “new” SYN 2 seconds later means either the client’s TCP stack decided the first attempt died, OR the SYN was actually retransmitted (with the same seq) and Wireshark is showing you two identical packets.

If the seq numbers match → retransmission. If they don’t → new attempt.

Real network engineers open Wireshark and check the sequence number. Textbook answers gloss over it.

Try it yourself (10 minutes)

Fire up any of the Packet Tracer labs with two hosts and a router. From one host:

PC1> telnet 192.168.1.1 23
Trying 192.168.1.1...

On the router at the exact same moment:

Router# debug ip tcp transactions
Router# show tcp brief

You’ll see the connection go SYNSENT → ESTAB in real time. Kill the telnet client and watch it go through the FIN-WAIT / TIME-WAIT teardown (that’s the other handshake — a four-packet closer — which is a topic for another post).

Cheat strip

• Three packets = the minimum to prove bidirectional communication
• SYN, SYN-ACK, ACK = flag combinations on packets 1, 2, 3
• ISNs are random for each side — security feature, not cosmetic
• x+1 in the Ack field — the SYN flag itself consumes 1 seq slot even though it carries no data
• Completed handshake ≠ working application — TCP just proved the pipe exists

The bigger picture

The 3-way handshake is trivial to memorize and lethal to misunderstand. Every “network isn’t working” ticket you’ll ever get either happens before the handshake (firewall/routing), during it (asymmetric paths, MSS mismatch), or after it (application, MTU, timeouts). Knowing which of the three tells you where to look — and saves you from re-checking things that aren’t broken.

Ready to build the operator instincts that get you hired?

Passing the CCNA is one thing. Reading a Wireshark trace, spotting an asymmetric-routing dropped SYN-ACK, and calling it in 30 seconds — that’s what US Junior Network Engineer interviews test.

At PacketMentor we build those instincts, one lab at a time. 👉 Book your free 20-minute 1:1 mentorship discovery call today.