Flow Control and the Sliding Window

Flow control answers one narrow question: how does a fast sender avoid drowning a slow receiver? A 10 Gbps server streaming to a phone that can only process data so quickly will overflow the phone's buffer and force drops unless something paces it. TCP's answer is the receive window — the receiver advertises, in every ACK, exactly how much buffer space it has free, and the sender is forbidden from having more unacknowledged data in flight than that.

The crucial thing to keep straight is what flow control is not. It protects the receiver, not the network. A separate mechanism — congestion control, the next topic — protects the shared links in between. The amount a sender may transmit is bounded by the smaller of these two limits: the receive window (rwnd) and the congestion window (cwnd). Confusing the two sends you tuning the wrong knob when throughput disappoints.

The Receive Window

The receive window (rwnd) is a 16-bit field in every TCP header carrying the receiver's currently free buffer space in bytes. As the application drains data out of the socket, the window opens; as the buffer fills because the application is slow to read, the window shrinks. The sender reads this number on each ACK and never lets its in-flight unacknowledged bytes exceed it — pure end-to-end pacing, decided entirely by how fast the receiver consumes.

Being 16 bits, the raw field maxes out at 65535 bytes. On a fast, high-latency link that ceiling is brutal: with a 64 KB cap and a 100 ms round trip, a single connection tops out near 5 Mbps no matter how much bandwidth the path actually has, because the sender must stop and wait for an ACK after every 64 KB. That limit is the entire reason window scaling exists.

The Sliding Window

The window slides: as ACKs confirm older bytes, the left edge advances, and as the receiver frees buffer, the right edge advances, so the sender continuously injects new data without waiting for each segment to be confirmed individually. At any instant the unacknowledged data in flight is bounded by the window size, but within that bound the sender keeps the pipe full — this pipelining is what makes TCP fast despite acknowledging everything.

The actual limit on in-flight data is the minimum of cwnd and rwnd. If the receiver advertises 256 KB but congestion control has the cwnd at 64 KB, the sender may have only 64 KB outstanding — the network is the binding constraint. If the cwnd has grown to 1 MB but the receiver advertises 64 KB, the receiver is the binding constraint. Reading which of the two is smaller tells you immediately whether to fix the receiver's buffers or the path.

# window-scale factor, send/recv windows, and the two limits
ss -tie
# ... wscale:7,7 ... cwnd:128 ... rcv_space:262144 ...
#       ^scale shift   ^cwnd (network limit)  ^receiver buffer
# the autotuning ceilings that cap how large rwnd can grow
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem

Window Scaling

Window scaling is the TCP option that lifts the 64 KB ceiling. Negotiated once, in the SYN of the handshake, it defines a left-shift applied to the advertised window — a scale of 7 multiplies it by 128, lifting the effective maximum to roughly 8 MB, and the protocol's largest legal shift of 14 reaches roughly 1 GB. Without it, no amount of buffer tuning helps, because the 16-bit field simply cannot express a larger number.

This matters on long-fat networks — paths with high bandwidth and high latency, where the bandwidth-delay product (the data that fits "in flight") exceeds 64 KB. A 1 Gbps transcontinental link with an 80 ms RTT has a BDP near 10 MB; capped at 64 KB it would run at under 1% of capacity. Because scaling is set only in the handshake, a connection that negotiated it badly cannot be fixed mid-stream — the fix is correct buffer ceilings before the connection opens.

Zero-Window and Silly-Window

When a receiver's buffer fills completely, it advertises a zero window — "send nothing more." The sender stops and periodically probes with a one-byte segment until the receiver reopens the window. A zero window is a clear signal that the receiving application is not reading fast enough; it is not loss, not congestion, and chasing it as a network problem wastes time. Read the window field and the cause is unambiguous.

The silly-window syndrome is the pathological case where the window reopens in tiny increments — a few bytes at a time — and the sender responds with tiny segments, spending more on headers than payload. TCP defends against it on both ends: the receiver delays advertising a larger window until it can offer a meaningful chunk, and the sender (via Nagle's algorithm) coalesces small writes. The two together keep a slow-draining receiver from degenerating into header-dominated dribble.