The sliding window protocol is how a sender puts more than one unacknowledged frame on the wire at a time, instead of sending one frame and idling until its acknowledgment comes back. That single change is what makes reliable data transfer usable at real network speeds rather than crawling at the pace of one round trip per frame. It shows up at the data link layer in classic ARQ protocols and, in a more elaborate form, inside TCP itself.
What changed in 2026
- It remains the backbone of TCP flow control, even as QUIC and HTTP/3 add their own stream-level flow control on top — the underlying idea of bounding in-flight data by a window has not gone away, it has been layered.
- Understanding it became more relevant to tuning modern systems, since diagnosing throughput problems on long, fast links still comes back to window size and the bandwidth-delay product.
- Simplified ARQ variants remain common in constrained networks — low-power and IoT link layers still implement small-window Go-Back-N or Selective Repeat schemes because they are cheap to run on limited hardware.
The problem: stop-and-wait wastes the pipe
In the simplest reliable protocol, a sender transmits one frame and waits for its acknowledgment before sending the next. On a link with any real round-trip delay, the sender spends most of its time idle — the wire could carry many more frames in the time it takes one acknowledgment to return. The fix is not a faster wire; it is allowing multiple frames to be outstanding at once.
How the window mechanism works
Both sender and receiver track a window: a range of sequence numbers currently valid to send or accept. The sender can transmit any frame within its window without waiting for an individual acknowledgment first. As acknowledgments arrive confirming earlier frames, the window slides forward, allowing new frames to be sent. The receiver similarly tracks which sequence numbers it is willing to buffer, and advertises that capacity back to the sender — this advertised size is what keeps a fast sender from overrunning a slow receiver's buffer.
Go-Back-N vs Selective Repeat
| Approach |
On detecting a lost frame |
Efficiency |
Complexity |
| Go-Back-N |
Retransmits the lost frame and every frame after it |
Lower — wastes bandwidth resending already-received frames |
Simple; receiver only tracks the next expected sequence number |
| Selective Repeat |
Retransmits only the specific lost frame |
Higher — no redundant retransmission |
More complex; receiver must buffer out-of-order frames |
Where this shows up today
TCP's receive window field, present in every segment, is a direct implementation of this idea — it tells the sender how much unacknowledged data the receiver is currently willing to buffer. This is distinct from TCP congestion control, which separately limits how much data the sender puts on the wire based on inferred network conditions; flow control protects the receiver, congestion control protects the network. Below the transport layer, protocols like HDLC and many link-layer implementations in constrained IoT hardware still use small, explicit sliding windows with Go-Back-N or Selective Repeat.
Common pitfalls and misconceptions
Confusing this with the sliding window array/string technique. The algorithmic sliding window taught for coding interviews — moving two pointers across an array to avoid rescanning a subrange — shares a name with this protocol and nothing else. One is a data structure traversal technique; this is a network reliability mechanism.
Assuming a bigger window is always faster. A window sized far beyond the bandwidth-delay product of the link does not add throughput, and on a lossy link it can make each loss event more expensive to recover from.
Treating flow control and congestion control as the same mechanism. They solve different problems and are usually implemented as two separate limits, with the sender's actual send window being the smaller of the two.
FAQ
What is the bandwidth-delay product, and why does it matter here?
It is the link's bandwidth multiplied by its round-trip time — effectively how much data can be "in the pipe" at once. A window smaller than this value leaves the link underused; matching the window to it maximizes throughput without overrunning the receiver.
Does modern TCP still use Go-Back-N or Selective Repeat?
TCP's behavior is closer to Selective Repeat in spirit, using selective acknowledgment options to identify exactly which segments arrived, though its full mechanism is more elaborate than either classic scheme alone.
Is this the same thing as the sliding window algorithm used in coding interviews?
No. That is an algorithmic technique for scanning arrays or strings without rescanning overlapping ranges. This is a network protocol for reliable, efficient data transfer. The shared name is a coincidence of terminology, not a shared concept.
Why not just make the window infinitely large?
Receiver buffer space is finite, and on a lossy link a very large window means more data must be retransmitted or held pending reorder after a loss event, which can hurt rather than help real throughput.
Where to go next