How does the TCP handshake, teardown, and flow control work?

Question

IT Interview Practice · Accepted Answer

TCP establishes a connection with a **3-way handshake**, closes it with a **4-way teardown**, and keeps data flowing safely with **flow control** and **congestion control**. The handshake synchronizes each side's starting sequence number so both can track and acknowledge every byte:

```text
   3-WAY HANDSHAKE (open)                4-WAY TEARDOWN (close)
 Client            Server              Client            Server
   │──── SYN ───────▶│                   │──── FIN ───────▶│
   │◀── SYN, ACK ────│                   │◀──── ACK ───────│
   │──── ACK ───────▶│                   │◀──── FIN ───────│
   │   connected     │                   │──── ACK ───────▶│
```

**Flow control** stops a fast sender from overwhelming a slow receiver. Each side advertises a **receive window** — how many bytes it currently has buffer space for — in every ACK. The sender may have at most one window of unacknowledged data in flight (a **sliding window**); if the receiver's window shrinks to zero, the sender pauses. This is a *receiver-driven* limit.

**Congestion control** is different: it protects the *network* (not the receiver) from overload. TCP maintains a **congestion window** that grows on success and shrinks on packet loss (loss is read as a congestion signal). Algorithms like slow start and CUBIC ramp up gradually, then back off when loss appears:

```text
cwnd
 │        /\        /\
 │       /  \      /  ...   loss → halve/back off, then probe up again
 │      /    \    /
 │  ___/      \__/
 └───────────────────────▶ time
```

The actual amount TCP sends is `min(receive window, congestion window)` — bounded by both the receiver and the network.

## Why it matters

This question separates candidates who memorized "SYN-SYN/ACK-ACK" from those who understand *why* TCP is reliable. The handshake, sequence numbers, and ACKs are the mechanism behind ordering and retransmission; flow and congestion control are why a single connection can't drown a slow client or collapse a shared link. This directly explains real-world behavior — connection setup latency (one round trip before any data), why throughput ramps up rather than starting at full speed, and why loss on a long-distance link tanks performance — all of which you reason about when tuning or debugging networked systems.

Why it matters

Related questions