What does the threeway handshake do?

What Does The Threeway Handshake Do: SYN SYN-ACK ACK

Understanding network connection establishment procedures protects data integrity across clients and servers. Exploring fundamental protocol mechanics reveals how devices verify readiness and synchronize sequence numbers before transferring information securely.

What Does the TCP Three-Way Handshake Actually Do?

A TCP/IP three-way handshake is the 3-packet setup that creates a reliable TCP connection: SYN, SYN-ACK, then ACK. It sets sequence numbers, confirms both sides are alive, and why is the 3-way handshake necessary in tcp only then allows data to move.

This protocol forms the absolute foundation of the modern internet. TCP handles approximately 85% of total internet traffic, quietly ensuring your emails, web pages, and API calls arrive intact. But there is one counterintuitive factor about this connection process that 90% of developers overlook - Ill explain it in the Wireshark analysis section below.

The Core Sequence: SYN, SYN-ACK, ACK Explained

To grasp abstract networking concepts, think of the handshake like a strict phone call protocol. You call a friend and say, Hello, can you hear me? Your friend replies, Yes, I hear you, can you hear me? You answer, Yes, I hear you too. Only then do you start sharing actual news.

When I first started analyzing network traffic, I made every rookie mistake possible. I completely ignored the Initial Sequence Numbers (ISN) and just looked at the payload. I spent three days wondering why my custom client kept dropping connections. My eyes were burning from staring at logs at 2 AM. It took me hours of frustration to realize I was sending static sequence numbers instead of randomized ones, causing the server to reject the packets.

Step 1: The SYN (Synchronize) Packet

The client initiates the connection by sending a SYN packet to the server. This packet contains a random Initial Sequence Number. This number acts as a starting marker to track the order of all future data packets.

Step 2: The SYN-ACK (Synchronize-Acknowledge) Packet

The server receives the SYN and responds with a SYN-ACK. It acknowledges the clients sequence number (by adding 1 to it) and sends its own randomized sequence number back to the client. The server is now in a half-open state.

Step 3: The ACK (Acknowledge) Packet

The client receives the SYN-ACK and sends a final ACK packet back to the server, acknowledging the servers sequence number. The connection is now fully established. That is it.

Why is the 3-Way Handshake Necessary in TCP?

Conventional wisdom says two packets should be enough to start talking. If I say hello, and you say hello back, we should be good to go. But in my experience building distributed systems, a two-way handshake leaves the server completely blind to network reality.

If the network severely delays the clients first packet, the client might give up and close its local socket. Eventually, that delayed packet reaches the server. In a two-way system, the server would reply and assume the connection is open, allocating memory for a ghost client that no longer exists. The third packet (ACK) proves the client is still alive and actively waiting for data. Dead wrong.

Real-World Wireshark Analysis: When Things Break

Here is that critical mistake I mentioned earlier: assuming the handshake completes instantly without performance penalties. TLS over TCP adds roughly 2 RTT (Round Trip Times), which delays the first byte of data by 50-100ms in typical global connections. This latency adds up rapidly when your application creates a new connection for every single API request.

Wait a second. You might wonder what happens if one of these packets gets lost in transit. Rarely have I seen a debugging technique this effective: just watch the retransmission timers. If a SYN packet drops, the client waits, typically 1 second, then 3 seconds, then 7 seconds, doubling the delay each time (exponential backoff). Lets be honest, if your API takes 7 seconds to connect, your users have already closed the app.

TCP Connection Establishment vs. UDP

TCP (Transmission Control Protocol) ⭐

Requires the full 3-way handshake before any data can be transferred

Maintains a strict state machine (ESTABLISHED, FIN-WAIT, TIME-WAIT)

Guarantees delivery, ordering, and error-checking of all packets

Web browsing (HTTP/S), database queries, email, file transfers

UDP (User Datagram Protocol)

Zero handshake - sends data immediately to the destination IP

Completely stateless, saving significant server memory

No guarantees - packets can arrive out of order, duplicated, or not at all

Live video streaming, real-time gaming, DNS lookups, IoT sensor data

Debugging the SYN Flood Timeout

Marcus, a systems engineer in Seattle, faced application timeouts every afternoon at 3 PM. His server CPU was perfectly fine, but legitimate users could not connect. The frustration was real - his team was considering a complete platform migration.

First attempt: He added more RAM to the load balancer, assuming it was a capacity issue. It made absolutely no difference. He spent three hours staring at the dashboard with burning eyes, completely lost on what to try next.

He finally ran a packet capture and saw thousands of SYN packets arriving with no matching ACKs from the clients. His server was holding half-open connections until the memory allocation table filled up completely, locking out real users.

He enabled SYN cookies in the Linux kernel and dropped the timeout window. Connection success rates jumped back to 99.9% within ten minutes, and the daily 3 PM timeouts vanished forever. He learned that server metrics lie if you don't look at the network layer.