TCP flow control

Imagine pouring water into a friend's cup while they drink from it. If you pour faster than they can drink, the cup overflows and water is wasted. The polite thing is to watch how full the cup is and slow your pour to match. TCP flow control is exactly this: it stops a fast sender from sending data faster than the receiver can take it in, so the receiver's buffer never overflows and bytes aren't dropped for lack of room.

The mechanism is the advertised receive window. The receiver keeps a buffer for incoming bytes that the application hasn't read yet. In every segment it sends back, it advertises, in the window field of the TCP header, how much free space remains in that buffer. The sender is not allowed to have more unacknowledged data in flight than that advertised window. As the receiving application reads bytes out of the buffer, space frees up, the receiver advertises a larger window, and the sender may push more. If the buffer fills, the receiver advertises a window of zero and the sender pauses, periodically probing until the window reopens.

Why it matters: flow control matches sender speed to one specific bottleneck — the receiver's capacity to consume data. It's worth being precise about what it is not: flow control protects the receiver, while congestion control protects the network in between. They are separate mechanisms with separate signals (an advertised window from the receiver versus inferred congestion from loss or delay), and TCP obeys both at once, sending no more than the smaller of the two limits allows. Mixing them up is one of the most common conceptual errors about TCP.