Flow Control & Sliding Window

RoadmapsCore CS

Scenario

Imagine drinking from a firehose. No matter how thirsty you are, you can only swallow so fast before the water simply blasts you in the face. Computers face the exact same problem when a fast server sends data to a slow smartphone.

Mental model

A dynamic buffer system where the receiver constantly tells the sender exactly how much more data it can handle.

TCP Flow Control prevents a fast sender from overwhelming a slow receiver. It uses a 'Sliding Window'—a moving frame that tracks unacknowledged packets and available buffer space, ensuring the sender pauses before the receiver's memory overflows.

Explanation

In any network connection, the sender and receiver might operate at drastically different speeds. A high-end server connected to fiber optics can transmit data gigabytes per second, while a budget smartphone on a weak cellular signal might only be able to process a few megabytes per second. If the server transmits at full speed, the smartphone's network buffer will quickly overflow, causing it to drop incoming packets. TCP Flow Control exists entirely to solve this speed mismatch.

The mechanism powering Flow Control is the Receive Window. When the receiver establishes a connection and acknowledges packets, it includes a 'Window Size' value in the TCP header. This number explicitly tells the sender: 'I currently have X bytes of free space in my buffer.' As the receiving application reads data out of the buffer, space frees up. As new packets arrive from the network, space fills up. The receiver constantly updates the sender with this fluctuating window size.

To optimize transmission, TCP uses a concept called the Sliding Window. Instead of sending one packet and waiting for an acknowledgment (which would be agonizingly slow), the sender is allowed to transmit a whole batch of packets simultaneously—up to the limit of the receiver's declared Window Size. Visualize a window frame sliding over a long sequence of data bytes. As the sender receives ACKs for early packets, the left edge of the window 'slides' forward, permitting new, later packets on the right edge to be transmitted.

If the receiving application freezes or processes data too slowly, its buffer will fill completely. In response, the receiver will advertise a Window Size of 0. This is known as a Zero Window. The sender immediately stops transmitting payload data and waits. Periodically, the sender will shoot over tiny 'probe' packets to check if the window has opened up again. Once the receiver's application catches up and clears the buffer, it advertises a non-zero window, and the sliding window resumes its forward march.

Key points

Common mistakes

Glossary

network buffer
A small, temporary storage area in a device's memory where incoming data waits patiently to be processed.
TCP Flow Control
A digital communication rule that ensures a fast sender doesn't overwhelm a slow receiver by sending too much data too quickly.
speed mismatch
A situation where one device can send information much faster than the other device can receive and understand it.

Recall questions

Questions & answers

A system metrics dashboard shows a server's network connection is entirely stalled, but the CPU and network bandwidth are near zero. Packet captures show the client constantly returning TCP Window Size: 0. What is the root cause?

The client-side application is deadlocked or running too slowly.

Approach: The network and server are fine. A Zero Window means the client OS is receiving data, but the client application isn't reading it out of the OS buffer, causing it to fill up.

Why does TCP use a sliding window instead of a 'stop-and-wait' protocol (send one packet, wait for ACK, send next packet)?

Throughput and efficiency.

Approach: Stop-and-wait severely limits throughput, especially on high-latency networks. A sliding window allows multiple packets to be in transit simultaneously, fully utilizing network bandwidth.

Continue learning

Previous: TCP vs UDP

Return to Core CS Roadmap