EMZETT.Flow Control
In short: A mechanism that prevents a fast sender from flooding a slower recipient with data, by dynamically adjusting the transmission rate.
In more detail: Without flow control, a recipient with a limited buffer could lose data if it arrives faster than it can be processed. TCP regulates this via a “sliding window”, with which the recipient signals to the sender how much data it can currently still accept.
In Depth
The sliding-window method
The sliding-window method, through which TCP implements flow control, works in principle like this: every ACK from the recipient contains, besides the pure acknowledgement, a “receive window” (rwnd) — the statement of how many more bytes the recipient can currently still take into its buffer before the application reads and processes them. The sender may only ever have as much unacknowledged data “in flight” at the same time as this window allows, and has to pause as soon as the window is full:
Sender: Receiver (rwnd=4000):
-------- 4000 bytes of data --->
<-------- ACK, rwnd=0 (buffer full) ---
(sender pauses, waits for the window to open)
<-------- ACK, rwnd=2000 (buffer partly emptied) ---
-------- 2000 bytes of data --->
If the receive buffer is emptied by the application more slowly than new data arrives (e.g. because the application is currently busy with something else, such as an expensive database query), the reported window automatically shrinks — in the extreme case down to 0, which stops the sender completely until the recipient reports space again. In this state the sender periodically repeats small “window probes” in order to notice as soon as capacity is free again, without risking unnecessarily large amounts of data.
Flow control vs. congestion control
A clear distinction from congestion control is important — the two mechanisms are often confused: flow control protects the RECEIVER from overload, based on its actual reported buffer capacity — a purely local problem between exactly two endpoints. Congestion control, on the other hand, protects the NETWORK in between from overload, based on observed data loss or rising latency as an indirect congestion signal — a problem that potentially affects many connections at once that share the same lines and routers. Both mechanisms work in TCP in parallel and independently of each other (with separate window sizes, the receive window for flow control and the congestion window for congestion control), but TOGETHER they limit how much data the sender may actually send at once — whichever of the two windows is smaller applies.
Flow control beyond TCP
The basic principle also appears outside TCP: USB, PCIe and many other hardware bus systems implement their own flow control mechanisms to prevent a fast device from overwhelming a slower one with data. The same concept can also be found at the application level (for example in some streaming protocols or message queues) under a different name — often called “backpressure”, when a downstream system explicitly signals to an upstream one to send more slowly because it would otherwise be overloaded.