Few things are as fundamental to reliable network communication as the TCP 3-Way Handshake. This process is how your devices build trust and sync up before they start sending data. It’s not just about getting basic connections working; it’s the essential groundwork for countless tools and protocols you use daily, like Nmap, HTTP, and DNS, all of which rely on TCP's reliability.
This guide breaks down how the TCP handshake works, why it's so vital for network reliability, how it's different from UDP, and how it powers real-world network protocols and even security scanning techniques.
Table of contents
Transmission Control Protocol (TCP) is designed to give you reliable, ordered, and error-checked communication between two devices. Unlike connectionless protocols like UDP, which just fire off data without any agreement, TCP requires a structured process to formally set up a session before any application data is sent. That's where the 3-Way Handshake comes in.
It's a simple, three-step negotiation:
Once this final ACK is sent, both the client and server move to the ESTABLISHED state, and reliable application data can start flowing.
This quick exchange is the core of the TCP handshake. It aligns the state on both the client and server, making sure subsequent data arrives in the correct order without issues.
|
Step |
Direction |
Flags |
Purpose |
|---|---|---|---|
|
1 |
Client → Server |
SYN |
Propose connection, send client's Initial Sequence Number (ISN), suggest options (like MSS). |
|
2 |
Server → Client |
SYN, ACK |
Acknowledge client's ISN, send server's ISN, negotiate options. |
|
3 |
Client → Server |
ACK |
Acknowledge server's ISN. Both sides are now ESTABLISHED. |
The final ACK usually doesn't carry any application data. The Initial Sequence Numbers (ISNs) are randomized for security, and each side always acknowledges the other's ISN plus one. This simple math keeps the byte streams synchronized, ensuring your data arrives in order.
This simple exchange ensures both ends are synchronized — like a firm handshake before beginning a conversation.
The client starts the connection by sending a TCP packet with the SYN flag set. This packet also includes a proposed Initial Sequence Number (ISN). It's basically saying: "I’d like to start a conversation."
This first step confirms the client is ready and requests synchronization.
The server gets the SYN, then replies with a packet that has both the SYN and ACK flags set.
At this point, the server has set aside resources for the connection and is waiting for the client's final confirmation.
Finally, the client sends one last ACK packet back to the server. This confirms it received the server’s SYN-ACK. Once this happens, the connection is officially open, and both sides can start sending data reliably.
The handshake isn't just about packet exchanges; it's about moving both the client and server through defined connection states:
|
Phase |
Client State |
Server State |
|---|---|---|
|
Before connection |
CLOSED |
LISTEN |
|
Step 1: SYN sent |
SYN-SENT |
LISTEN |
|
Step 2: SYN-ACK received |
ESTABLISHED (after sending its ACK) |
SYN-RECEIVED |
|
Step 3: ACK sent |
ESTABLISHED |
ESTABLISHED |
This synchronized sequence ensures both ends agree on sequence numbers and are ready to communicate, setting the stage for ordered, reliable data transfer.
The handshake is your connection's essential setup and early-warning system. It confirms both ends can send and receive data, syncs their sequence numbers for ordering, and negotiates important performance options. If handshake timing is off or failures spike, users will feel the pain (slow websites, failed connections) even before any actual application data is sent. Monitoring TCP handshake health is fundamental to ensuring your applications are available.
Without this handshake, TCP couldn't guarantee data integrity—a trade-off protocols like UDP deliberately make for speed and lower overhead.
The handshake confirms both endpoints can send and receive, aligns sequence numbers, and negotiates options that influence performance. If handshake timing is erratic or failures spike, users experience slow page loads or failed connections before any application data appears. Watching handshake health is an early-warning signal for network, security, or server readiness issues.
Both TCP and UDP operate at the transport layer, but they make different promises. TCP pays an upfront cost with its 3-way handshake to guarantee order, reliability, and recovery from packet loss. UDP skips this ceremony for speed and minimal overhead.
|
Feature |
TCP |
UDP |
|---|---|---|
|
Connection Type |
Connection-oriented |
Connectionless |
|
Handshake |
Yes (3-Way) |
No |
|
Reliability |
GuaranGuaranteed delivery (retransmits) |
Best-effort (no guarantees) |
|
Ordering |
Maintains sequence |
No order guarantee |
|
Overhead |
Higher (larger headers) |
Lower (smaller headers) |
|
Common Uses |
HTTP, HTTPS, SMTP, SSH |
DNS, VoIP, Gaming, Streaming |
Every time you browse a website, your browser initiates a TCP handshake to confirm the server’s readiness before sending HTTP requests.
Tools like Nmap, on the other hand, use synthetic handshake signals to probe servers for open ports or vulnerabilities, often without completing the connection at all.
This ensures that the connection is stable and ready for data transfer.
Nmap (Network Mapper) is a powerful tool for network discovery and security auditing. It uses TCP handshake behavior to detect open ports and map network states efficiently.
Performs the complete 3-way handshake with a target port.
Sends only a SYN packet and waits for a response.
Because the handshake is never completed, SYN scans are faster and stealthier — ideal for reconnaissance.
By analyzing TCP flag responses (SYN, ACK, RST), Nmap identifies whether ports are open, closed, or filtered, helping network engineers pinpoint security gaps and optimize configurations.
Understanding the handshake is vital for:
The handshake is the start of every TCP session. Seeing these packets in Wireshark or firewall logs gives you a direct look into your network's behavior.
Begin with the handshake RTT (SYN→SYN‑ACK) and how quickly the final ACK follows; both are your readiness pulse. Keep an eye on SYN retransmit rate and overall handshake failure rate (connections that never reach ESTABLISHED). If RSTs spike, you’re being refused rather than delayed. Compare current time‑to‑ESTABLISHED against a known baseline to separate path noise from real regressions. Finally, confirm negotiated options (MSS, Window Scale, SACK), because they materially affect throughput and loss recovery once the session starts moving data.
Quick Checks: Make sure the service is listening on the server (ss -ltnp or netstat -plnt on Linux). Check your firewall rules. Test PMTU discovery. If all else fails, capture packets on both ends to see what's happening on the path.
The TCP/IP 3-Way Handshake is the foundation for reliable, ordered communication. By understanding how SYN, SYN-ACK, and ACK packets work together, you as a network engineer can get much better at diagnosing connectivity problems, securing your network, and tuning application performance. Tools like Nmap rely on these principles for smart network scanning, proving that knowing this handshake is key to managing and optimizing modern networks.
Its primary purpose is to establish a reliable, synchronized connection between two devices. It confirms both are reachable and ready for data exchange and synchronizes their sequence numbers for ordered data delivery.
The three steps are SYN, SYN-ACK, and ACK. The client sends a SYN to propose a connection. The server acknowledges with a SYN-ACK. The client confirms with a final ACK, moving both sides to the ESTABLISHED state for reliable data flow.
The TCP connection is in the ESTABLISHED state. Congestion control mechanisms begin to govern data flow, and application data begins to flow in an ordered, reliable stream. Later, the connection is terminated with a separate four-packet FIN/ACK exchange.
If the 3-way handshake fails, a TCP connection will not be established, and no application data can be transferred.
Nmap sends SYN packets to target ports and watches for SYN-ACK replies to identify open ports. It may complete the full handshake (Connect scan) or stop halfway (stealthy SYN scan) to gather this information.
Window Scaling is a TCP option extending the receive window size beyond 65,535 bytes, crucial for high throughput on high-bandwidth, high-latency paths. Larger windows allow more data "in flight," fully utilizing available bandwidth. Window Scaling is negotiated during the 3-way handshake.
Understanding the handshake is critical for configuring firewalls and intrusion detection systems (IDS). It allows you to recognize and block abnormal connection attempts (like SYN floods) and conduct more effective network forensics.
No. TCP’s connection setup is identical over IPv4 or IPv6. The IP layer changes addressing and header format, but the TCP state machine and the three-packet SYN, SYN-ACK, ACK ceremony remain the same.
No. TLS/SSL runs on top of TCP. First, a reliable TCP connection is established using the standard 3-way handshake. Then, the TLS handshake begins over that established TCP connection to negotiate ciphers and exchange keys before any encrypted application data flows.
A SYN flood is a Denial of Service (DoS) attack where an attacker sends a large number of SYN packets but never completes the handshake with the final ACK. This forces the server to keep many half-open connections in its memory, eventually exhausting resources and preventing new, legitimate connections.
SYN floods can be mitigated by enabling features like SYN cookies on the server, allowing it to handle SYN requests without immediately allocating memory. Other methods include right-sizing and monitoring the SYN backlog, applying per-IP or per-prefix rate limits on firewalls/load balancers, and using upstream DDoS protection to filter out abusive traffic.
Stacks use a randomized, time‑varying function (per RFC guidance, e.g., RFC 6528) that mixes a secret with the 4‑tuple (src/dst IP and port) so ISNs are unpredictable and resistant to spoofing and replay, while still monotonically advancing over time.