Ever wonder what the little “SYN”, “SYN‑ACK”, “ACK” dance looks like in packet form?
If you’ve ever opened Wireshark and stared at a sea of hex, the three‑way handshake is the first thing you should learn to read. It’s the handshake that guarantees a reliable connection before any data ever travels. And guess what? A solid grasp of it turns a novice into a networking detective.
What Is the Three‑Way Handshake?
When you type a URL, your computer doesn’t just blast data straight to the server. Here's the thing — first, it talks. The three‑way handshake is the conversation that establishes a TCP connection. Think of it as a polite “hello,” “nice to meet you,” “let’s do this” sequence between two devices.
- SYN – “Hey, I want to talk.”
- SYN‑ACK – “Sure, I’m listening.”
- ACK – “Great, let’s start.”
Once that’s done, the data stream can begin. In Wireshark, you’ll see each of those flags in the Flags column.
Why It’s Not Just a Fancy Term
People often think the handshake is a one‑time thing that’s already done by the time they hit a website. In reality, every TCP connection—whether it’s a web page, an email, or a file download—undergoes this exact three‑step process. If any step fails, the connection never starts, and you’ll see errors like “Connection timed out” or “Reset by peer.
Why It Matters / Why People Care
You might ask, “Why should I care about a three‑step handshake?” Because it’s the foundation of all reliable internet traffic.
- Performance: The handshake sets the initial sequence numbers. If the numbers are off, retransmissions pile up.
- Security: Attackers can spoof SYN packets to flood a server (SYN flood). Knowing the handshake helps you spot or defend against such attacks.
- Troubleshooting: When a site loads slowly or fails, the first place to look is often the handshake. Missing or delayed packets can explain the problem.
In practice, a solid understanding of the handshake allows you to read Wireshark logs like a pro, diagnose issues, and even tweak performance That's the part that actually makes a difference. Took long enough..
How It Works (or How to Do It)
Let’s walk through the handshake step‑by‑step, using Wireshark as our visual aid. I’ll assume you’ve already captured traffic on a local network or a VPN tunnel.
1. Start a Capture
Open Wireshark, select the interface that’s connected to the target host, and hit Start.
If you’re only interested in the handshake, apply a filter:
tcp.flags.syn == 1 && tcp.flags.ack == 0
This will show you only the initial SYN packets No workaround needed..
2. Spot the SYN
Look for a packet where Flags shows SYN and ACK is 0. The Info column will read something like “SYN”.
Key fields to note:
- Source IP/Port – your machine.
- Destination IP/Port – the server.
- Sequence Number (Seq) – the starting point for your data stream.
3. The SYN‑ACK Response
The server replies with a packet that has both SYN and ACK set. In the Info column you’ll see “SYN, ACK”.
Important points:
- The Acknowledgment Number (Ack) will be your initial Seq + 1.
- The server’s Sequence Number is its own starting point.
4. The Final ACK
Your client sends back an ACK packet, acknowledging the server’s Seq + 1. The Info will simply say “ACK”.
Practically speaking, at this moment, the TCP connection is fully established. The handshake is over, and data packets can flow freely.
5. Looking at the Flags in Detail
Wireshark displays flags as letters, but you can expand the TCP layer to see each bit:
| Flag | Meaning | Wireshark Symbol |
|---|---|---|
| SYN | Synchronize sequence numbers | S |
| ACK | Acknowledgment field is significant | A |
| FIN | No more data from this side | F |
| RST | Reset the connection | R |
| PSH | Push function | P |
| URG | Urgent pointer is significant | U |
| ECE | ECN-Echo | E |
| CWR | Congestion Window Reduced | C |
During the handshake, you’ll only see SYN, SYN‑ACK, and ACK.
6. Time Stamps and RTT
Wireshark logs timestamps for each packet. By subtracting the timestamp of the SYN from the SYN‑ACK, you get the Round‑Trip Time (RTT). A high RTT can hint at network congestion or distance.
Common Mistakes / What Most People Get Wrong
-
Thinking the handshake is a single packet
Some beginners look at the first packet and assume the connection is ready. It isn’t until the ACK lands that the channel opens. -
Ignoring the sequence numbers
The Seq and Ack fields are the heart of TCP reliability. Skipping them means you miss out on how data alignment works Easy to understand, harder to ignore. That's the whole idea.. -
Assuming “SYN” always means a new connection
In some protocols (like HTTP/2 multiplexing), a SYN can be part of a stream reset. Context matters. -
Overlooking the filter
Without a proper filter, you’ll drown in traffic. The handshake is just a few packets in a busy network. -
Misreading flags
Wireshark can show flags in hex or as letters. Double‑check that you’re looking at SYN (0x02) and not something else Most people skip this — try not to..
Practical Tips / What Actually Works
-
Use a capture filter
Instead of a display filter, try a capture filter liketcp[tcpflags] & tcp-syn != 0 && tcp[tcpflags] & tcp-ack == 0. It grabs only the SYN packets, reducing noise Not complicated — just consistent. Worth knowing.. -
Save a “handshake snapshot”
In Wireshark, right‑click the SYN packet and choose "Follow → TCP Stream". It will isolate the entire conversation, making it easier to see the whole handshake. -
Check for retransmissions
A missing or delayed SYN‑ACK often shows up as a retransmission of the SYN. Look for "Retransmission" in the Info column. -
Compare sequence numbers
Verify that the ACK number in the SYN‑ACK equals the SYN’s Seq + 1. A mismatch can indicate a spoofed or corrupted packet. -
Measure RTT
Use the Statistics → TCP Stream Graphs → Round Trip Time to get a visual of RTT over time. Sudden spikes can signal issues. -
Log for analysis
Export the capture to a CSV and analyze the handshake timestamps and sequence numbers in a spreadsheet. Patterns emerge more clearly there.
FAQ
Q: Why does Wireshark show the same packet twice in the capture?
A: Wireshark records each packet as it arrives at the interface. If you capture on a mirrored port or use a tap, you might see duplicate packets. Filter by tcp.stream to collapse duplicates Nothing fancy..
Q: What if I only see SYN but no SYN‑ACK?
A: That usually means the server didn’t respond—perhaps it’s down, or a firewall is blocking the traffic. Check the network path or try a different port Easy to understand, harder to ignore..
Q: Can I force Wireshark to show only the handshake?
A: Yes, use the display filter tcp.flags.syn==1 && tcp.flags.ack==0 || tcp.flags.syn==1 && tcp.flags.ack==1 || tcp.flags.ack==1 && tcp.flags.syn==0. It pulls the three packets together.
Q: How does a SYN flood attack look in Wireshark?
A: You’ll see a high volume of SYN packets with no corresponding SYN‑ACKs. The server’s response will be missing or minimal Not complicated — just consistent..
Q: Is the handshake the same for HTTPS?
A: Yes, HTTPS starts with the same TCP handshake. After that, the TLS handshake overlays on top of it.
Wrapping It Up
The three‑way handshake is the unsung hero of every internet connection. Think about it: it’s short, it’s simple, but it’s also the gatekeeper that ensures data arrives intact. By learning to read it in Wireshark, you gain a powerful diagnostic tool and a deeper appreciation for the invisible choreography that keeps our digital world running. The next time a page stalls, pause, open Wireshark, and let that little SYN dance tell you what’s really going on.
No fluff here — just what actually works.
