Computer Science: TCP 3-Way Handshake & Sliding Window Flow Control

The physical Internet is a wild, unpredictable landscape. The underlying Internet Protocol (IP) layer offers only best-effort datagram delivery: packets can take divergent geographic routes, arrive out of order, get duplicated by faulty switches, or be discarded without notice when intermediate router buffers overflow.

If application developers had to manually handle retransmissions, duplicate detection, and receiver buffer overflows for every file download or database query, software development would collapse under sheer complexity.

Enter the Transmission Control Protocol (TCP), codified in 1981 by Vint Cerf and Bob Kahn in RFC 793. TCP wraps the unreliable packet-switched wilderness of IP in an abstraction of an in-order, error-checked, reliable bidirectional byte stream.

In this edition, we examine two core pillars of TCP mechanics:

1. The 3-Way Handshake: Why two rounds of communication are mathematically insufficient to establish connection state.
2. Sliding Window Flow Control: How sender and receiver synchronize dynamic buffer capacities without choking or stalling the connection.

1. Why a 3-Way Handshake? (Why Not 2-Way?)

A common interview and systems design question asks: Why does TCP require 3 messages to open a connection instead of 2?

       3-Way Handshake Protocol (RFC 793)
   Client                                  Server
   (CLOSED)                               (LISTEN)
      |                                       |
      |--------- 1. SYN (SEQ=X) ------------->|  (SYN-RECEIVED)
      |                                       |
      |<-------- 2. SYN-ACK (SEQ=Y, ACK=X+1) -|
      |                                       |
 (ESTABLISHED)                                |
      |--------- 3. ACK (SEQ=X+1, ACK=Y+1) -->|  (ESTABLISHED)
      |                                       |

The Peril of the Delayed Duplicate SYN

Suppose TCP used a simple 2-Way Handshake (Client sends SYN $\to$ Server sends ACK, and connection is open).

Imagine a client on a high-latency wireless link sends a SYN request. Due to transient router congestion, the packet gets delayed in network buffers for 30 seconds. The client’s timer expires, giving up and re-trying on a new connection.

Minutes later, that delayed original SYN packet finally arrives at the server. Under a 2-way handshake:

1. The server would receive the stale SYN, believe the client wants to open a brand-new connection, allocate memory buffers, and immediately transition its state to ESTABLISHED.
2. The server would reply with an ACK.
3. But the client has already moved on! It ignores the unexpected ACK.
4. The server is left holding a half-open ghost connection, leaking resources indefinitely.

With a 3-Way Handshake, the server’s SYN-ACK challenges the client to confirm:

• “I received your request for sequence number $X$. My sequence number is $Y$. Please confirm byte $Y+1$.”
• The client, seeing an outdated sequence number, immediately sends an abort RST (Reset) flag, destroying the bogus server state.
• The connection is only activated when both parties have bidirectionally synchronized sequence numbers!

2. Sliding Window Flow Control

Once a connection is established, how fast should the sender transmit data?

If the sender transmits too slowly (e.g. Stop-and-Wait: send 1 packet, wait for ACK, send next packet), transmission throughput drops to near zero across transatlantic links:

If a packet is $1,460\text{ bytes}$ and RTT is $100\text{ ms}$, throughput is limited to a pitiful $14.6\text{ KB/s}$, regardless of whether you have a $10\text{ Gbps}$ fiber link!

To maximize throughput, TCP utilizes a Sliding Window Protocol. The sender is allowed to transmit a continuous pipeline of multiple packets into the network without waiting for intermediate ACKs:

 Sender Buffer:
 [ 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 ]
 |-----------|   |---------------|   |-----------------------------|
  Acked Bytes        In-Flight          Allowed Window (rwnd)          Cannot Send Yet
  (Done)             (Awaiting ACK)     (Usable to send now)           (Blocked)
                 ^                   ^
             Left Edge           Right Edge

The Window Slide Mechanics

1. Window Size ($W = \text{rwnd}$): The receiver includes a 16-bit Window Size field in every return packet, indicating available free buffer bytes.
2. Transmission: The sender may transmit bytes from Left Edge up to Left Edge + rwnd.
3. Sliding: When an ACK arrives acknowledging byte segment $K$, the Left Edge instantly snaps forward to $K+1$. This rightward slide reveals new available slots in the buffer, allowing the sender to pipeline new bytes immediately.
4. Zero Window Probing: If the receiver’s application process is slow at reading data from the socket, rwnd shrinks to 0. The sender stops transmitting and periodically emits 1-byte Zero Window Probes until the receiver process drains its buffer and re-advertises a non-zero window.

3. TCP vs UDP: The Transport Layer Trade-Off

TCP guarantees absolute reliability, order, and congestion fairness, but these guarantees carry real-world penalties:

• Connection Latency: 1 RTT for TCP 3-Way Handshake before any application payload can pass.
• Head-of-Line (HoL) Blocking: If packet #3 is dropped by a router, packets #4, #5, and #6 must wait in the receiver’s TCP buffer and cannot be delivered to the application until packet #3 is retransmitted and acknowledged.

For latency-critical applications like live multiplayer gaming, video conferencing (WebRTC), and DNS lookups, the overhead of TCP is prohibitive. These protocols choose UDP (User Datagram Protocol), which strips away handshakes, sliding windows, and retransmissions in favor of lightweight, unordered packet delivery.

In modern HTTP/3, the industry achieved the ultimate synthesis: building QUIC on top of UDP to combine the encryption speed of TLS 1.3, multiplexed streams without Head-of-Line blocking, and congestion control without legacy operating system kernel bottlenecks.