Skip to content
Sliding Window & Flow Control
step 1/5

Reading — step 1 of 5

Read

~2 min readReliability & Flow Control

Sliding Window and Flow Control

Send one segment, wait for its ACK, send the next: that is stop-and-wait, and it caps throughput at one segment per round trip. On a 50 ms link that is a few dozen KB/s no matter how fat the pipe. TCP does better by keeping many segments in flight at once — a sliding window.

The sender tracks two edges over the sequence space:

  acked          in flight        may send yet     future
--------|====================|------------------|--------
     SND.UNA              SND.NXT           SND.UNA+SND.WND
        <----------------- window ----------------->
  • SND.UNA — oldest byte sent but not yet acknowledged (left edge).
  • SND.NXT — next new byte to send.
  • SND.WND — the window size, so the right edge sits at SND.UNA + SND.WND.

Bytes in flight are SND.NXT - SND.UNA. The rule is simple and absolute: you may transmit new data only while in_flight < SND.WND. Each ACK advances SND.UNA, which slides the whole window forward and frees room to send more.

Whose window is it?

SND.WND is not your choice — it is the number the receiver advertises in the Window field of every segment it sends you. That is flow control: the receiver says "I have this much free buffer; do not send more than this," and a fast sender is forced to respect a slow receiver instead of overflowing it. (This is a different limit from congestion control, covered later, which is about the network's capacity, not the peer's buffer.)

Zero window and the deadlock it invites

If the receiver's application stops reading, its buffer fills and it advertises WND = 0 — "stop." The sender halts. But window updates ride in ordinary ACKs, and if the ACK that later re-opens the window is lost, both sides wait forever: the receiver thinks it told the sender to resume; the sender never heard it. TCP breaks the standoff with the zero-window probe — the stalled sender periodically sends a one-byte segment to force the receiver to re-advertise its current window.

Window scaling

The Window field is only 16 bits, so the largest window it can express is 65,535 bytes. On a gigabit link with 100 ms RTT the bandwidth-delay product is over 12 MB — a 64 KB window would leave the pipe 99% empty. The window scale option, agreed once during the handshake, multiplies every advertised window by 2^N (N up to 14), lifting the ceiling to a gigabyte. Without it, high-speed long-distance TCP is impossible.

The trap

The most common sliding-window bug is computing "space left" wrong. It is SND.WND - (SND.NXT - SND.UNA), not SND.WND - SND.NXT. The window is measured from the unacknowledged edge, not from wherever you happen to be sending. Get that subtraction wrong under load and you will either stall a healthy connection or blow past the receiver's buffer and trigger a storm of retransmissions.

Discussion

Ask a question, share an insight, or help someone who’s stuck.

Sign in to post a comment or reply.

Loading…