TransportIntermediate

Flow control vs congestion control

“What is the difference between flow control and congestion control in TCP? Who is each one protecting, and how does the sender know the limit?”

What this tests

  • Two distinct mechanisms with two distinct signals
  • Receiver window vs congestion window and min() of both
  • Recognising each one’s symptom in production

Answers by level

Read the beginner answer first and notice what is missing.

Flow control protects the receiver. The receiver advertises in every ACK how much buffer space it has left — the receive window, rwnd — and the sender may never have more than that many unacknowledged bytes in flight. If the application stops reading from the socket, the buffer fills, rwnd shrinks to zero, and the sender stops entirely (probing occasionally with window probes). The signal is explicit and exact; nobody guesses.

Congestion control protects the network. No router tells the sender how much capacity is left, so the sender infers it: it keeps a congestion window, cwnd, grows it while ACKs arrive (exponentially in slow start, then linearly), and cuts it when it detects loss (duplicate ACKs, timeouts) or, with modern algorithms, rising RTT (BBR) or ECN marks. The effective limit at any moment is min(rwnd, cwnd) — whichever side is scarcer.

They fail differently and you diagnose them differently. A zero window (ss -ti shows a tiny rcv_wnd on the peer, tcpdump shows win 0) means the receiving application is slow — a slow consumer, a blocked thread, a full downstream — and the fix is in that application (backpressure). A small `cwnd` with retransmissions (ss -ti shows cwnd:14 retrans:…) means the path is lossy or congested, and the fix is in the network or in the algorithm (BBR, parallel streams), not in the application. Both make a transfer slow with idle CPUs on both ends; only one of them is your code.

Green flags · Red flags

Strong green flag · Relates zero windows to application backpressure and says "that one is my code; the other one is the path".
Green flags
  • Receiver vs network; explicit window vs inferred window
  • Says effective window = min(rwnd, cwnd)
  • Describes the zero-window symptom and the loss/cwnd symptom separately
  • Knows the bandwidth-delay product and window scaling
  • Names an algorithm (CUBIC, BBR) and what it reacts to
Red flags
  • Treats them as one mechanism with two names
  • Thinks the network tells the sender the available bandwidth
  • Cannot say what a zero window means
  • Believes a bigger buffer is the fix for a slow consumer

Follow-up questions

F1
A transfer between two idle servers over a 1 Gbit/s link runs at 9 Mbit/s with 3% loss. Which control is limiting?
F2
A transfer to a client runs slowly and tcpdump shows win 0 from the client. Which control?
F3
Why does a connection that idled for a minute start slowly again?

Scenario

A streaming export endpoint stalls for exactly the slowest clients, and the server’s worker threads pile up in write(). Explain which window is at play, why threads block, and what an event-driven server would do instead.

Learn this topic