TCP Flow Control and Windowing

The Problem: A Fast Sender, a Slow Receiver

If a sender transmits data faster than a receiver can process it, the receiver's incoming buffer fills up and starts dropping data - wasting bandwidth on data that has to be resent. Flow control exists so the receiver can tell the sender exactly how much it's ready to accept.

The Receive Window: A Running Capacity Signal

Every TCP acknowledgment includes a "window size" value: the amount of additional data, in bytes, the receiver is currently willing to accept before its buffer fills up.

Receiver's buffer: [ used ][ used ][      free space      ]
Window size advertised to sender: however much free space remains

How the Sender Uses This Information

The sender is only allowed to have that many unacknowledged bytes "in flight" at once. If the receiver's window shrinks (because its buffer is filling up), the sender must slow down and send less at a time - and if the window grows again, the sender can speed back up.

Why It's Called a "Sliding" Window

Sent & Acked | Sent, awaiting Ack | Allowed to send next | Not yet allowed
             <------ current window ------>
                        (the window "slides" forward as acknowledgments arrive)

As earlier bytes get acknowledged, the window slides forward, allowing new bytes to be sent - a continuously adjusting balance between how much data is safely "in flight" and how much the receiver can currently handle.

Why This Matters in Practice

Flow control is what prevents a fast server from overwhelming a slow mobile device on a weak connection, automatically throttling the data rate to match what the receiver can actually keep up with - all without either side needing to guess a fixed speed in advance.