TCP: Reliable Data Transfer

What Is TCP?

TCP (Transmission Control Protocol): The way to send data reliably over networks.

Guarantees:

• Data arrives in correct order
• No data lost
• No duplicates
• Failed packets retransmitted automatically

Almost every app uses TCP because reliability matters.

Alternative is UDP: Faster but unreliable. Used for video calls, gaming. Packets can arrive out of order or get lost.

The Three-Way Handshake

Before any data flows, TCP requires setup.

Process:

Step 1: Client → Server: "SYN" (let us connect)

Step 2: Server → Client: "SYN-ACK" (agreed, let us connect)

Step 3: Client → Server: "ACK" (connection established)

Now data can flow.

Visualization:

Client                    Server
  |                         |
  |-------- SYN ----------->|
  |<------ SYN-ACK ---------|
  |-------- ACK ----------->|
  |                         |
  [Connection Ready]

Why This Is Expensive

Each step is a network round-trip.

Example: Client in Mumbai. Server in California. 200ms latency per trip.

Three-way handshake = 3 messages = 600ms before sending any data!

For a single HTTP request: 600ms setup + actual request/response.

This is why connection reuse matters.

The Two-Way Teardown

When done, connection closes.

Process:

Step 1: Client → Server: "FIN" (finished, closing)

Step 2: Server → Client: "ACK" (acknowledged, connection closed)

Sometimes: Server also sends FIN, client sends ACK (four-way).

Typical: Two messages to close connection.

Connections Do Not Auto-Close

Critical fact: TCP connection does NOT automatically close after one request.

Connection stays open until:

1. Either party explicitly closes it
2. Network interruption (router dies, cable unplugged)
3. Timeout from inactivity (configured, often 60 seconds)

This matters: You can reuse one TCP connection for multiple requests!

Connection Reuse: The Performance Win

Without reuse (new connection per request):

Request 1: 3-way handshake + request + response + 2-way teardown
Request 2: 3-way handshake + request + response + 2-way teardown
Request 3: 3-way handshake + request + response + 2-way teardown

Overhead: 15 network messages for 3 requests.

With reuse (keep connection open):

First request: 3-way handshake + request + response
Request 2: request + response (same connection)
Request 3: request + response (same connection)
Final: 2-way teardown

Overhead: 5 network messages total. 3× faster!

Real-World Impact

Scenario: Mobile app loading profile. Needs 5 API calls.

Without reuse:

• Setup: 5 × 3 messages = 15 messages
• Teardown: 5 × 2 messages = 10 messages
• Total: 25 messages overhead

With reuse:

• Setup: 1 × 3 messages = 3 messages
• Teardown: 1 × 2 messages = 2 messages
• Total: 5 messages overhead

5× reduction! This is why connection pooling exists.

TCP Just Delivers Bytes

Important: TCP handles reliable delivery. It does NOT care what data you send.

Analogy: TCP is like postal service. Delivers letters reliably. Does not read content.

What you send over TCP: Totally up to you.

Common choices:

• HTTP (most web apps)
• Custom protocols (Redis, databases)
• WebSockets (real-time apps)

TCP delivers bytes. You define what those bytes mean.

Example: Redis Does Not Use HTTP

Redis uses custom protocol over TCP.

Why? Optimized for key-value operations. Faster than HTTP for its use case.

Takeaway: You can define your own protocol. Just ensure both sides understand it.

When TCP Is Not Used

Video calls (Zoom): Use UDP. Speed matters more than perfection. Dropped frame = minor glitch.

Gaming (Fortnite): Use UDP. Old position data is worthless. Need instant updates.

DNS lookups: Often UDP. Single packet request/response. No need for connection.

Everything else: Probably TCP. Reliability worth the overhead.