TCP Working: 3-Way Handshake & Reliable Communication

Introduction: The Chaos of Unregulated Communication

Imagine trying to send a 1000-piece puzzle to your friend through the mail, but there are no rules:

• Some pieces might get lost in transit

• Pieces might arrive in random order

• Some pieces might arrive twice

• Pieces might get damaged or broken

• Your friend might not even be home to receive them

• You'd have no way of knowing which pieces arrived

This would be frustrating and nearly impossible to complete, right?

This is exactly what happens when computers try to communicate over networks without proper protocols. Data gets broken into small chunks called packets, and without rules governing their transmission, chaos ensues.

Enter TCP - the protocol that brings order to this chaos.

What is TCP?

TCP (Transmission Control Protocol) is one of the fundamental protocols that powers the internet. It's a set of rules that two computers follow to establish a reliable connection and exchange data safely.

Think of TCP as a reliable courier service for your data. While other protocols (like UDP) are like throwing letters in the wind and hoping they arrive, TCP is like a meticulous postal service that:

• Confirms delivery of every package

• Ensures packages arrive in the correct order

• Resends lost packages automatically

• Checks that packages aren't damaged

• Makes sure the recipient is ready to receive

Where is TCP Used?

TCP is used whenever reliability matters more than speed:

• Web browsing (HTTP/HTTPS runs on TCP)

• Email (SMTP, IMAP, POP3)

• File transfers (FTP, SFTP)

• Remote access (SSH, Telnet)

• Database connections

Basically, any time you can't afford to lose data, TCP is there working behind the scenes.

Problems TCP is Designed to Solve

Let's understand the specific challenges TCP addresses:

1. Packet Loss

Networks are imperfect. Routers get overloaded, cables have interference, WiFi signals weaken. Packets can simply disappear during transmission.

TCP's Solution: Tracks every packet and requests retransmission if something goes missing.

2. Out-of-Order Delivery

Packets might take different routes through the internet. Packet 3 might arrive before Packet 1.

TCP's Solution: Numbers each packet and reassembles them in the correct order at the destination.

3. Duplicate Packets

Sometimes networks accidentally send the same packet twice.

TCP's Solution: Uses sequence numbers to detect and discard duplicates.

4. Data Corruption

Electrical noise or hardware issues can flip bits in your data during transmission.

TCP's Solution: Uses checksums to detect corrupted data and requests retransmission.

5. Flow Control

A fast sender might overwhelm a slow receiver with more data than it can process.

TCP's Solution: Implements flow control mechanisms to match the sender's speed to the receiver's capacity.

6. Connection State

How do two computers know they're both ready to communicate?

TCP's Solution: The 3-way handshake establishes a connection before any data is sent.

---

The TCP 3-Way Handshake: Starting the Conversation

Before any data can be exchanged, TCP requires both sides to agree to communicate. This happens through a 3-way handshake.

The Phone Call Analogy

Think about making a phone call:

1. You dial and the phone rings: "Hello, are you there?"

2. Friend answers: "Yes, I'm here! Can you hear me?"

3. You confirm: "Yes, I can hear you. Let's talk!"

Now you both know the connection is working and you can start your conversation.

TCP does exactly this, but with special packets called SYN and ACK.

Why Do We Need This Handshake?

The handshake achieves several critical things:

• Confirms both sides are ready to communicate

• Synchronizes sequence numbers (more on this later)

• Negotiates parameters like maximum packet size

• Establishes initial state for the connection

Without this handshake, Computer A might start sending data to Computer B, but Computer B might not be ready, or might not even exist!

Step-by-Step: How the 3-Way Handshake Works

Let's walk through the handshake in detail. We'll call our two computers Client (the one initiating the connection) and Server (the one receiving the connection request).

Step 1: SYN (Synchronize)

Client → Server: SYN

What happens:

The Client wants to establish a connection with the Server. It sends a special packet with the SYN flag set to 1.

What this packet says:

• "Hi Server, I want to start a connection with you"

• "My starting sequence number is X" (let's say 1000)

• "Are you there and ready to talk?"

Key information in the SYN packet:

• SYN flag = 1: This marks it as a synchronization request

• Sequence number = 1000: This is the Client's initial sequence number (randomly chosen)

• Port numbers: Source port (Client) and destination port (Server)

Client's state after sending SYN: SYN-SENT (waiting for response)

Step 2: SYN-ACK (Synchronize-Acknowledge)

Server → Client: SYN-ACK

What happens:

The Server receives the SYN packet and, if it's willing to accept the connection, sends back a packet with both SYN and ACK flags set.

What this packet says:

• "Hi Client, I received your SYN with sequence number 1000"

• "I acknowledge it! I'm expecting your next byte to be 1001"

• "My starting sequence number is Y" (let's say 5000)

• "I'm ready to communicate with you!"

Key information in the SYN-ACK packet:

• SYN flag = 1: Server is also synchronizing

• ACK flag = 1: Server is acknowledging the Client's SYN

• Sequence number = 5000: Server's initial sequence number

• Acknowledgment number = 1001: Server expects the next byte from Client to be 1001 (Client's sequence + 1)

Server's state after sending SYN-ACK: SYN-RECEIVED (waiting for final acknowledgment)

Step 3: ACK (Acknowledge)

Client → Server: ACK

What happens:

The Client receives the SYN-ACK and sends a final acknowledgment back to the Server.

What this packet says:

• "Server, I received your SYN-ACK with sequence number 5000"

• "I acknowledge it! I'm expecting your next byte to be 5001"

• "Connection established! Let's start exchanging data."

Key information in the ACK packet:

• ACK flag = 1: Acknowledging the Server's SYN-ACK

• Sequence number = 1001: Client's next sequence number

• Acknowledgment number = 5001: Client expects the next byte from Server to be 5001

Both Client and Server state: ESTABLISHED (connection is now active!)

Visual Representation

Understanding Sequence Numbers and Acknowledgments

You might be wondering: "Why all these numbers? What's the point?"

Sequence Numbers: Keeping Track of Data

Every byte of data sent over TCP is numbered. This allows TCP to:

• Detect missing data: If bytes 1000-1999 arrive, then 3000-3999, we know 2000-2999 are missing

• Reassemble out-of-order packets: Even if packets arrive scrambled, TCP can put them back in order

• Prevent duplicate processing: If the same bytes arrive twice, TCP knows to ignore the duplicate

Example:

Imagine you're sending the message "HELLO WORLD" (11 bytes):

Packet 1: Seq=1000, Data="HELLO " (6 bytes)
Packet 2: Seq=1006, Data="WORLD" (5 bytes)

Even if Packet 2 arrives before Packet 1, the receiver can reassemble the correct message using the sequence numbers.

Acknowledgment Numbers: Confirming Receipt

The acknowledgment number tells the sender which byte the receiver expects next. This confirms that all previous bytes were received successfully.

Example:

Sender sends: Seq=1000, Data="HELLO " (6 bytes)
Receiver responds: Ack=1006 (meaning "I got bytes 1000-1005, send 1006 next")

If the receiver sends Ack=1003, the sender knows only bytes 1000-1002 were received, and it needs to resend from byte 1003.

How Data Transfer Works in TCP

Now that the connection is established, let's see how actual data flows.

The Send-Acknowledge Cycle

TCP follows a simple pattern:

1. Sender transmits data with a sequence number

2. Receiver processes the data and checks for errors

3. Receiver sends an acknowledgment indicating what it received

4. Sender moves on to next data or retransmits if needed

Example Data Transfer

Let's say the Client wants to send a file to the Server:

Step 1:
Client → Server: Seq=1001, Data="First chunk" (100 bytes)

Step 2:
Server → Client: Ack=1101 ("Got it! Send byte 1101 next")

Step 3:
Client → Server: Seq=1101, Data="Second chunk" (100 bytes)

Step 4:
Server → Client: Ack=1201 ("Got it! Send byte 1201 next")

This continues until all data is transferred.

Bidirectional Communication

TCP connections are full-duplex, meaning both sides can send and receive simultaneously. Each direction has its own sequence numbers.

Client → Server: Seq=1001, Data="Request", Ack=5001
Server → Client: Seq=5001, Data="Response", Ack=1101

Both sides are sending data and acknowledging what they receive.

How TCP Ensures Reliability

TCP has several mechanisms to ensure your data arrives correctly:

1. Checksums: Detecting Corruption

Every TCP packet includes a checksum - a mathematical value calculated from the data. The receiver recalculates this checksum and compares it to the one sent. If they don't match, the data was corrupted in transit.

What happens:

• Corrupted packet is discarded

• No acknowledgment is sent

• Sender retransmits the packet after a timeout

2. Acknowledgments: Confirming Receipt

As we've seen, receivers send acknowledgments for data they receive successfully. This tells the sender: "Yes, I got that, send the next part."

Cumulative acknowledgments: An Ack of 2000 means "I've received all bytes up to 1999."

3. Timeouts and Retransmission

When the sender transmits data, it starts a retransmission timer. If it doesn't receive an acknowledgment before the timer expires, it assumes the packet was lost and sends it again.

Example:

Client sends: Seq=1000, Data="Hello"
[Timer starts]
...
[Packet gets lost in the network]
...
[Timer expires]
Client resends: Seq=1000, Data="Hello"
Server receives it and sends: Ack=1005

Dynamic timeout: TCP is smart - it adjusts timeout values based on network conditions. Fast networks get shorter timeouts; slow networks get longer ones.

4. Sequence Numbers: Ensuring Order

Even if packets arrive out of order, TCP uses sequence numbers to reassemble them correctly.

Example:

Sender transmits:
  Packet 1: Seq=1000, Data="The "
  Packet 2: Seq=1004, Data="quick "
  Packet 3: Seq=1010, Data="brown "

Receiver gets them in this order: Packet 2, Packet 3, Packet 1

Using sequence numbers, receiver reconstructs: "The quick brown "

5. Duplicate Detection

If a packet arrives twice (maybe due to a late retransmission), TCP recognizes it as a duplicate using sequence numbers and discards it.

6. Flow Control: Window Size

TCP prevents a fast sender from overwhelming a slow receiver using a sliding window mechanism.

How it works:

The receiver advertises a window size - the amount of data it can currently buffer.

Receiver says: "My window size is 5000 bytes"
Sender thinks: "I can send up to 5000 bytes before waiting for an ack"

As the receiver processes data and frees up buffer space, it increases the window size. If the receiver gets overwhelmed, it decreases the window size, slowing down the sender.

Example:

Receiver: Window=10000 bytes (I can handle 10KB)
Sender: Sends 10KB of data
Receiver: Processing... Window=2000 bytes (I'm getting full!)
Sender: Sends only 2KB more
Receiver: Processed some data, Window=8000 bytes (More room now)
Sender: Sends 8KB more

This elegant mechanism prevents buffer overflows and packet loss due to receiver overload.

How TCP Handles Packet Loss

Let's see what happens when packets go missing:

Scenario: Packet Loss

Step 1:
Client sends: Seq=1000, "Packet 1" ✓ (arrives)
Client sends: Seq=1100, "Packet 2" ✗ (lost!)
Client sends: Seq=1200, "Packet 3" ✓ (arrives)

Step 2:
Server receives Packet 1 → Sends Ack=1100
Server receives Packet 3 → But expects 1100, not 1200!
Server sends: Ack=1100 (duplicate ACK - still waiting for 1100)

Step 3:
Client receives duplicate Ack=1100
Client thinks: "Server didn't get Packet 2"
Client retransmits: Seq=1100, "Packet 2"

Step 4:
Server receives Packet 2 → Now has all three packets
Server sends: Ack=1300 (acknowledging all data)

Fast Retransmit

TCP doesn't always wait for a timeout. If the sender receives three duplicate acknowledgments, it immediately retransmits the missing packet. This is called fast retransmit and significantly improves performance.

How a TCP Connection is Closed

Just like the handshake to establish a connection, there's a process to close it gracefully. This is called the 4-way handshake (or FIN handshake).

Why Do We Need a Proper Closure?

• Ensures all data has been transmitted and acknowledged

• Frees up resources (ports, memory) on both sides

• Prevents "half-open" connections

The 4-Way Close Handshake

Step 1: FIN from Client

Client → Server: FIN

What it means:

• "I have no more data to send"

• "But I can still receive data from you"

Client state: FIN-WAIT-1

Step 2: ACK from Server

Server → Client: ACK

What it means:

• "I acknowledge your FIN"

• "I might still have data to send, give me a moment"

Server state: CLOSE-WAIT Client state: FIN-WAIT-2

At this point, the connection is half-closed. The Server can still send data to the Client.

Step 3: FIN from Server

Server → Client: FIN

What it means:

• "I'm done sending data too"

• "Ready to close the connection completely"

Server state: LAST-ACK

Step 4: ACK from Client

Client → Server: ACK

What it means:

• "I acknowledge your FIN"

• "Connection fully closed"

Client state: TIME-WAIT then CLOSED Server state: CLOSED

Visual Representation

Why Four Steps Instead of Three?

Unlike the opening handshake, the closing handshake has four steps because:

• The Server might still have data to send after receiving the Client's FIN

• Each side needs to independently signal it's done sending

• This allows for a graceful shutdown where both sides finish their work

Abrupt Connection Termination: RST

Sometimes a connection needs to be terminated immediately without the graceful handshake. This is done using a RST (Reset) packet.

When RST is used:

• A packet arrives for a connection that doesn't exist

• Application crashes

• Security issues detected

• Timeout on a half-open connection

Client → Server: RST
(Connection immediately terminated, no acknowledgment needed)

Putting It All Together: A Complete TCP Session

Let's trace a complete web request to see all these pieces working together:

Scenario: Visiting a Website

You type www.example.com in your browser and hit Enter.

Phase 1: Connection Establishment (3-Way Handshake)

1. Browser → Server: SYN (seq=1000)
   "I want to connect to your web server on port 80"

2. Server → Browser: SYN-ACK (seq=5000, ack=1001)
   "Connection accepted, let's sync up"

3. Browser → Server: ACK (ack=5001)
   "Ready to communicate!"

Connection ESTABLISHED

Phase 2: Data Transfer (HTTP Request)

4. Browser → Server: seq=1001, "GET / HTTP/1.1\r\nHost: www.example.com\r\n\r\n"
   "Send me your homepage"

5. Server → Browser: ack=1068
   "Got your request, processing..."

6. Server → Browser: seq=5001, "<html><body>Welcome...</body></html>" (1500 bytes)
   "Here's the webpage"

7. Browser → Server: ack=6501
   "Got the webpage, thanks!"

Phase 3: Connection Closure (4-Way Handshake)

8. Browser → Server: FIN (seq=1068)
   "I'm done sending requests"

9. Server → Browser: ACK (ack=1069)
   "Acknowledged your FIN"

10. Server → Browser: FIN (seq=6501)
    "I'm done sending the webpage"

11. Browser → Server: ACK (ack=6502)
    "Acknowledged, connection closed"

Connection CLOSED

Throughout this entire process:

• Sequence numbers tracked every byte

• Acknowledgments confirmed receipt

• Checksums verified data integrity

• Timeouts protected against packet loss

• Flow control prevented buffer overflow

All of this happened in milliseconds, completely transparent to you!

TCP vs UDP: When to Use Each

Now that you understand TCP, it's worth knowing there's another transport protocol called UDP (User Datagram Protocol).

UDP: The Fast but Unreliable Option

UDP is like sending postcards:

• No connection establishment

• No acknowledgments

• No retransmissions

• No order guarantees

• Much faster and lower overhead

When to Use TCP:

• Web browsing: Can't afford to lose parts of a webpage

• Email: Messages must arrive complete and intact

• File transfers: Every byte matters

• Banking transactions: Reliability is critical

• SSH/Remote access: Commands must be received correctly

When to Use UDP:

• Live video streaming: A few lost frames are acceptable, but lag is not

• Online gaming: Speed matters more than perfect accuracy

• DNS queries: Simple request-response, easy to retry if needed

• VoIP calls: A tiny bit of audio loss is better than delays

Key principle: Use TCP when correctness matters most; use UDP when speed matters most.

Common TCP Concepts and Terms

MSS (Maximum Segment Size)

The largest amount of data that can be sent in a single TCP segment. Typically around 1460 bytes.

MTU (Maximum Transmission Unit)

The largest packet size a network can handle. TCP adjusts its segment size to fit within the MTU.

Round-Trip Time (RTT)

The time it takes for a packet to go from sender to receiver and back. TCP uses this to calculate timeout values.

Congestion Control

TCP slows down when it detects network congestion (packet loss) to prevent making the problem worse. Algorithms include Slow Start, Congestion Avoidance, and Fast Recovery.

Keep-Alive

Periodic messages sent to keep a connection active and detect if the other side has crashed or become unreachable.

Nagle's Algorithm

Combines small packets into larger ones to improve efficiency, at the cost of slight latency.

Real-World Example: Downloading a File

Let's trace what happens when you download a 1 MB file:

1. Connection Setup

3-way handshake establishes connection (~1.5 RTT)

2. HTTP Request

Your browser: "GET /file.zip HTTP/1.1"
Server ACKs: "Got your request"

3. Data Transfer

Server sends 1 MB in ~700 packets (assuming 1460 byte MSS)
Each packet is numbered sequentially
Your computer ACKs groups of packets
If packet 237 is lost, duplicate ACKs trigger fast retransmit
TCP adjusts sending rate based on network conditions

4. Connection Close

4-way FIN handshake closes connection

Behind the Scenes

• ~700 packets sent

• ~700 acknowledgments received

• Sequence numbers tracked 1,048,576 bytes

• Checksums verified on every packet

• Retransmissions handled any packet loss

• Flow control prevented buffer overflow

• Congestion control adapted to network conditions

All this complexity is hidden from you - you just see a progress bar!

Common TCP Issues and Troubleshooting

1. Connection Timeout

Symptom: Connection takes forever or fails

Possible causes:

• Server is down

• Firewall blocking SYN packets

• Network routing issues

Debug: Check if SYN packets are reaching the server

2. Slow Data Transfer

Symptom: Downloads are slower than expected

Possible causes:

• High packet loss causing frequent retransmissions

• Small window size limiting throughput

• Network congestion

• High latency (large RTT)

Debug: Monitor packet loss rate and retransmission count

3. Connection Drops

Symptom: Connection suddenly terminates

Possible causes:

• Server sent RST packet

• NAT/firewall timeout

• Application crash

• Network interruption

Debug: Look for RST or FIN packets

4. Half-Open Connections

Symptom: Connection appears stuck

Possible causes:

• One side crashed without sending FIN

• Firewall dropped FIN packets

• Network partition

Debug: Use TCP keep-alive to detect dead connections

Conclusion: The Unsung Hero of the Internet

TCP is one of the most important protocols in computer networking, yet it works so well that most people never think about it. Every time you:

• Load a webpage

• Send an email

• Download a file

• Stream a movie

• Connect to a database

• Access a remote server

TCP is there, quietly ensuring your data arrives safely, in order, and intact.

Key Takeaways

1. TCP provides reliable, ordered, error-checked delivery of data between applications

2. The 3-way handshake (SYN, SYN-ACK, ACK) establishes connections

3. Sequence numbers and acknowledgments ensure all data arrives correctly

4. Retransmissions and timeouts handle packet loss

5. Flow control prevents overwhelming the receiver

6. The 4-way handshake (FIN, ACK, FIN, ACK) closes connections gracefully

7. TCP trades speed for reliability - use UDP when you need speed over correctness