Three-way handshake in Computer Networks - Deep Dive

Overview - Three-way handshake

What is it?

The three-way handshake is a process used in computer networks to establish a reliable connection between two devices before they start communicating. It involves three steps where both devices exchange special messages to agree on starting communication. This ensures that both sides are ready and synchronized to send and receive data. It is a fundamental part of the Transmission Control Protocol (TCP).

Why it matters

Without the three-way handshake, devices might start sending data without knowing if the other side is ready, leading to lost or corrupted information. This handshake guarantees that both devices agree on connection parameters, making communication reliable and ordered. It is essential for everyday internet activities like browsing websites, sending emails, or streaming videos, where data must arrive correctly and in order.

Where it fits

Before learning the three-way handshake, you should understand basic networking concepts like what a network connection is and the role of protocols. After mastering it, you can explore how data is transferred reliably over networks, error handling, and advanced TCP features like connection termination and congestion control.

Mental Model

Core Idea

The three-way handshake is a step-by-step agreement process where two devices say 'hello' and confirm readiness before exchanging data.

Think of it like...

It's like two people on a phone call saying 'Hello?', then 'Hello, I hear you!', and finally 'Great, let's talk!' before starting a conversation.

┌───────────────┐       ┌───────────────┐
│   Client      │       │   Server      │
└──────┬────────┘       └──────┬────────┘
       │ SYN (Hello)             │
       │────────────────────────>│
       │                         │
       │             SYN-ACK (Hello, I hear you!)
       │<────────────────────────│
       │                         │
       │ ACK (Great, let's talk!) │
       │────────────────────────>│
Connection Established

Build-Up - 7 Steps

1

Foundation

Understanding Network Connections

Concept: Introduce what a network connection is and why devices need to communicate reliably.

A network connection is like a communication link between two devices, such as your computer and a website server. For data to travel correctly, both devices must agree to talk and understand each other. Without this agreement, messages can get lost or misunderstood.

Result

Learners understand the need for a reliable communication setup before data exchange.

Knowing that devices need to coordinate before talking helps grasp why a handshake process is necessary.

2

Foundation

Basics of TCP Protocol

Concept: Explain that TCP is a protocol that manages reliable communication between devices.

TCP stands for Transmission Control Protocol. It ensures that data sent over the internet arrives complete and in order. TCP manages starting and ending connections and checks for errors during data transfer.

Result

Learners recognize TCP as the protocol responsible for reliable communication.

Understanding TCP's role sets the stage for learning how it establishes connections using the handshake.

3

Intermediate

Step One: Client Sends SYN

🤔Before reading on: Do you think the client or server starts the connection? Commit to your answer.

Concept: The client initiates the connection by sending a SYN message to the server.

The client sends a special message called SYN (synchronize) to the server. This message asks the server if it is ready to start communication and includes an initial sequence number to track data.

Result

The server receives a request to start a connection and knows the client's starting point.

Understanding that the client initiates the handshake clarifies how connections begin.

4

Intermediate

Step Two: Server Responds with SYN-ACK

🤔Before reading on: Does the server immediately accept the connection or ask for confirmation? Commit to your answer.

Concept: The server replies with a combined SYN and ACK message to acknowledge the client's request and offer its own sequence number.

The server sends back a SYN-ACK message. SYN means it wants to synchronize too, and ACK means it acknowledges the client's SYN. This message confirms the server is ready and shares its own sequence number.

Result

The client knows the server received its request and is ready to communicate.

Knowing the server both acknowledges and initiates synchronization explains the handshake's two-way nature.

5

Intermediate

Step Three: Client Sends ACK to Confirm

🤔Before reading on: Does the client need to confirm the server's readiness? Commit to your answer.

Concept: The client sends an ACK message to confirm it received the server's SYN-ACK, completing the handshake.

The client sends an ACK (acknowledgment) message back to the server. This tells the server that the client received its message and agrees to start communication. After this, the connection is established.

Result

Both devices are synchronized and ready to exchange data reliably.

Understanding the final confirmation step ensures clarity on how both sides agree to communicate.

6

Advanced

Why Sequence Numbers Matter

🤔Before reading on: Do you think sequence numbers are just random or serve a purpose? Commit to your answer.

Concept: Sequence numbers track the order of data packets to ensure correct delivery and reassembly.

Each SYN and ACK message includes a sequence number. These numbers help both devices keep track of data sent and received. If packets arrive out of order or get lost, sequence numbers allow devices to detect and fix these problems.

Result

Reliable and ordered data transfer becomes possible over the network.

Knowing sequence numbers prevent data mix-ups highlights the handshake's role beyond just saying hello.

7

Expert

Handling Connection Issues and Security

🤔Before reading on: Can the handshake be exploited or fail? Commit to your answer.

Concept: The handshake can be targeted by attacks or fail due to network problems, requiring safeguards.

Attackers can misuse the handshake to overload servers (SYN flood attacks) by sending many SYN requests without completing the handshake. Networks also face delays or lost messages that can interrupt the handshake. Techniques like SYN cookies and retransmissions help protect and maintain connections.

Result

Connections remain secure and reliable even under attack or poor network conditions.

Understanding vulnerabilities and protections reveals the handshake's complexity in real-world networks.

Under the Hood

The three-way handshake works by exchanging TCP segments with specific flags: SYN to request synchronization, SYN-ACK to acknowledge and synchronize, and ACK to confirm. Each segment carries sequence numbers to track data order. The TCP stack in the operating system manages these exchanges, updating connection states from CLOSED to SYN-SENT, SYN-RECEIVED, and ESTABLISHED. This state machine ensures both sides agree on connection parameters before data transfer begins.

Why designed this way?

The handshake was designed to solve the problem of unreliable networks where packets can be lost, duplicated, or arrive out of order. By requiring explicit synchronization and acknowledgment, TCP ensures both devices start communication in a known state. Alternatives like one-way connection attempts were unreliable and prone to errors. The three-step process balances reliability with efficiency, minimizing overhead while confirming readiness.

┌───────────────┐       ┌───────────────┐
│   Client      │       │   Server      │
├───────────────┤       ├───────────────┤
│ State: CLOSED │       │ State: LISTEN │
│               │       │               │
│ Send SYN      │       │               │
│ ────────────> │       │               │
│ State: SYN-SENT│      │               │
│               │       │ Receive SYN   │
│               │       │ Send SYN-ACK  │
│               │       │ State: SYN-RECEIVED
│               │       │ <─────────────│
│ Receive SYN-ACK│      │               │
│ Send ACK      │       │               │
│ State: ESTABLISHED│    │ Receive ACK  │
│               │       │ State: ESTABLISHED
│               │       │               │

Myth Busters - 4 Common Misconceptions

Quick: Does the three-way handshake send actual data packets? Commit to yes or no.

Common Belief: The handshake sends the first data packets to start communication.

Reality: The handshake only exchanges control messages (SYN, SYN-ACK, ACK) to establish the connection; actual data is sent afterward.

Why it matters: Confusing handshake messages with data can lead to misunderstanding how connections are set up and cause errors in network programming.

Quick: Is the handshake always successful on the first try? Commit to yes or no.

Common Belief: The handshake always completes smoothly without retries.

Reality: Network issues can cause handshake messages to be lost or delayed, requiring retransmissions and timeouts.

Why it matters: Assuming perfect conditions ignores real-world network problems and can cause developers to overlook error handling.

Quick: Does the server start the handshake? Commit to yes or no.

Common Belief: The server initiates the handshake by sending the first message.

Reality: The client always starts by sending the SYN message; the server responds.

Why it matters: Misunderstanding roles can confuse network design and troubleshooting.

Quick: Can the handshake protect against all network attacks? Commit to yes or no.

Common Belief: The handshake fully secures the connection from attacks.

Reality: The handshake can be exploited by attacks like SYN floods; additional security measures are needed.

Why it matters: Overestimating handshake security risks leaving systems vulnerable.

Expert Zone

1

The initial sequence numbers are not random but carefully chosen to prevent replay attacks and ensure uniqueness over time.

2

TCP stacks implement timers and retransmission strategies during the handshake to handle packet loss without user intervention.

3

Some modern protocols optimize or replace the three-way handshake to reduce latency, but TCP's method remains the most widely used for reliability.

When NOT to use

The three-way handshake is not suitable for connectionless protocols like UDP, which do not establish connections before sending data. For applications needing faster setup with less overhead, protocols like QUIC use different handshake methods. In highly secure environments, additional authentication layers are used on top of TCP.

Production Patterns

In real networks, the handshake is monitored for anomalies to detect attacks. Load balancers and firewalls often track handshake states to allow or block connections. Developers use handshake completion as a trigger to allocate resources or start application-level protocols. Network tools analyze handshake timing to diagnose latency or packet loss.

Connections

Handshake in Human Communication

Similar pattern of mutual agreement before interaction

Understanding the three-way handshake as a formal agreement process helps appreciate how communication protocols ensure readiness and trust before exchanging information.

TCP Connection Termination

Builds on the handshake concept but for closing connections

Knowing how connections start with a handshake clarifies the importance of a similar multi-step process to close connections cleanly and avoid data loss.

Cryptographic Handshakes (e.g., TLS Handshake)

Builds on TCP handshake by adding security negotiation

Recognizing that cryptographic handshakes extend the basic TCP handshake helps understand how secure connections are established over the internet.

Common Pitfalls

#1 Assuming data can be sent immediately after SYN is sent.

Wrong approach:

Client sends data right after sending SYN without waiting for SYN-ACK.

Correct approach:

Client waits for SYN-ACK, then sends ACK before starting data transfer.

Root cause:

Misunderstanding that the handshake must complete before data exchange.

#2 Ignoring retransmissions when handshake messages are lost.

Wrong approach:

Client sends SYN once and gives up if no response is received.

Correct approach:

Client retransmits SYN after timeout until SYN-ACK is received or max retries reached.

Root cause:

Not accounting for unreliable network conditions causing packet loss.

#3 Confusing roles and letting server initiate connection.

Wrong approach:

Server sends SYN to client to start connection.

Correct approach:

Client always initiates by sending SYN; server responds with SYN-ACK.

Root cause:

Misunderstanding client-server roles in TCP connections.

Key Takeaways

The three-way handshake is a crucial process that ensures both devices agree and are ready before exchanging data over a network.

It involves three steps: client sends SYN, server replies with SYN-ACK, and client confirms with ACK, establishing a reliable connection.

Sequence numbers in handshake messages help track data order and prevent errors during communication.

The handshake can face network issues and security threats, so additional mechanisms exist to handle these challenges.

Understanding the handshake is foundational for grasping how reliable and secure internet communication works.