Why is it called a threeway handshake?

Why is it called a three-way handshake? 3 steps explained

Why is it called a three-way handshake is a crucial question for understanding fundamental network communication security. Gaining this specific foundational knowledge prevents critical misunderstandings about how systems initiate secure contact across infrastructure.
Review the complete connection mechanism below to master these essential digital networking concepts.

Why is it called a three-way handshake?

It is called a three-way handshake because two computers use a three-step process passing three specific messages to agree to talk. Just like two people shake hands to greet each other, the computers exchange SYN, SYN-ACK, and ACK signals to ensure both sides are ready before sending real data.

TCP powers roughly 80% of all global internet traffic, serving as the foundation for everything from loading web pages to checking email.

Lets be honest, networking acronyms are confusing. I remember staring at a Wireshark packet capture during my first junior admin role, completely overwhelmed by the endless stream of SYN and ACK flags scrolling past.

My eyes were burning after three hours of debugging a server timeout. But there is one counterintuitive reason why two steps arent enough that most tutorials completely overlook - I will reveal that critical design choice in the section below about why two steps fail.

The Three Steps Explained Simply

Think of a TCP connection like making a phone call. You do not just start shouting your message the moment you dial. You wait for a hello.

Step 1: SYN (Synchronize)

The client (your computer) sends a message with a SYN flag. This is essentially asking if the other machine can hear the request and open a connection. It includes a random starting sequence number to track packets safely.

Step 2: SYN-ACK (Synchronize-Acknowledgment)

The server receives the request and replies with a SYN-ACK packet. This confirms receipt of the initial request (ACK) and indicates that the server is also ready to talk (SYN). The server provides its own starting sequence number here.

Step 3: ACK (Acknowledgment)

Finally, your computer sends an ACK message back. This confirms receipt of the servers readiness. The connection is now established.

That is it.

The tcp 3-way handshake explained.

Why Three Steps Instead of Two?

Here is that critical design choice I mentioned earlier: proving a two-way street. If the process were only two steps - just SYN then SYN-ACK - the server would never know if its reply actually made it back to the client.

The server would allocate memory for a connection that might already be dead. This typically causes resource exhaustion and crashes under heavy network loads. The third step (ACK) proves both sides can successfully send and receive data.

I used to think network protocols were overly complicated. Turns out, context matters more than I realized. This slight overhead prevents massive server failures by ensuring connections are fully synchronized before allocating massive amounts of RAM.

The Hidden Overhead of the TCP Handshake

Setting up these connections is not entirely free. This next part surprises most people.

The handshake process typically adds about 20-30 milliseconds of latency to every new connection. For a complex website loading 100 different resources, those milliseconds add up quickly. But there is a catch. You do not have to handshake every single time.

In my early days building APIs, I made the rookie mistake of forcing mobile clients to open a new TCP connection for every single data request. The database was choking. The server logs were a mess - a mess that cost us hours of downtime. My hands were literally shaking as I watched the timeout errors spike to 500 per minute on the dashboard while angry customer emails flooded my inbox.

I learned the hard way that utilizing keep-alive headers reduces latency by approximately 40-50% on subsequent requests. These headers keep the initial connection open, bypassing the need to perform the three-step dance repeatedly.

Visualizing the Packet Exchange

Lets visualize this without the jargon. Imagine you are sending a registered letter.

You send the initial letter (SYN). The post office stamps it and sends you a receipt saying they have it and are ready to deliver (SYN-ACK). You sign the receipt and hand it back (ACK). Now, the actual package can be shipped safely.

Rarely have I seen a networking concept perfectly mirror human interaction like this. Every time you load a webpage, your computer is having millions of these tiny, polite conversations.

Research - and Ive read dozens of network specifications on this over the past three years while building custom load balancers - shows that connectionless protocols like UDP work perfectly fine for use cases like gaming or live video streaming where speed matters most, even though the theoretical possibility of dropped packets makes junior developers nervous about data integrity.

TCP Handshake vs. Connectionless UDP

TCP (Transmission Control Protocol)

• Requires the full three-way handshake before any data transfer can begin
• Guaranteed delivery, automatically retransmits any lost or corrupted packets
• Loading websites, sending emails, downloading files, and database queries
• Uses sequence numbers to reassemble packets in the exact order they were sent

UDP (User Datagram Protocol)

• Zero handshake, starts transmitting data packets immediately without checking readiness
• No guarantees, packets can arrive out of order, duplicate, or drop entirely
• Live video streaming, competitive online gaming, and VoIP calls
• No built-in ordering mechanism, applications must handle missing data

The API Timeout Nightmare

TechFlow, a SaaS startup serving 15,000 users, faced severe latency issues. Their mobile app was taking 8 seconds to load the user dashboard, and the engineering team was completely stumped. The server CPU usage was minimal, and the database queries were running in under 10 milliseconds.

They initially blamed the caching layer and spent two weeks writing complex Redis implementations. The first attempt failed completely - the load times barely improved, and the team was burning out from late-night debugging sessions. They were looking in the wrong place entirely.

The breakthrough came when a senior engineer ran a packet trace on the network layer. The mobile app was opening 45 separate TCP connections simultaneously, performing a full three-way handshake for every tiny image, icon, and text file. The network overhead was killing the app.

By implementing HTTP/2 and connection pooling, they multiplexed all requests over a single TCP connection. Load times dropped from 8 seconds to 1.2 seconds, proving that managing handshakes properly is just as important as writing efficient backend code.