TCP flow control protects the receiver: the receiver advertises a window, and the sender must not have more unacknowledged data in flight than the window allows. It is distinct from congestion control, which protects the network. Flow control is about the receiver’s buffer, not the path’s capacity.
Before you start
You should understand TCP basics and the acknowledgment mechanism. This article covers the receive window and its edge cases.
Step-by-step walkthrough
Step 1: The receiver advertises a window
Each acknowledgment carries a window size, the number of bytes the receiver can still accept. The sender limits in-flight unacknowledged bytes to that window, so a slow application that is not reading its socket causes the window to shrink and the sender to slow down.
Step 2: Control is end to end, not per hop
Flow control is between the two endpoints, regardless of how many routers are in between. It operates alongside congestion control, which adjusts the sending rate based on network signals such as loss. Flow control reacts to the receiver; congestion control reacts to the network.
Step 3: Handle the zero window
If the receiver’s buffer fills, it advertises a zero window and the sender stops. The sender periodically probes, and the receiver sends a window update when it reads data and frees space. A receiver that never reads leads to a stalled but open connection.
Worked scenario
The window shrinks as the receiver’s buffer fills.
sender -> data -> receiver
receiver -> ack, window=64KB # can accept 64KB more
... receiver app slow, buffer fills ...
receiver -> ack, window=0 # sender pauses
receiver app reads -> window=32KB # sender resumesWalk through the example
The window tells the sender how much it may send ahead of acknowledgments. As the receiver’s application falls behind, the buffer fills and the window shrinks to zero, pausing the sender. When the application reads, space frees and the window update resumes the flow. No data is lost; the sender waits.
Common mistake
Confusing flow control with congestion control, so a slow reader is blamed on the network, or a network problem is blamed on the application. The symptoms differ: a zero window points at the receiver, while loss and retransmits point at the network.
Verify the behavior
Run a receiver that stops reading and observe the window shrinking to zero and the sender pausing. Resume reading and confirm the flow continues. Compare with a scenario of packet loss and confirm that retransmissions, not a zero window, are the signal.
Interview exercise
A transfer stalls while the connection stays open. How do you tell flow control from congestion control?
Answer and reasoning
Inspect the advertised window and retransmissions. If the receiver’s window has shrunk to zero and there is little or no loss, it is flow control: the receiving application is not reading fast enough. If the window is open but packets are being retransmitted, it is congestion control reacting to network loss. The window and the retransmit counters separate the two.
Continue learning
Compare transport topics in TCP handshake and latency and bandwidth. Read the RFC 5681 TCP congestion control and try the Networking interview questions.