滑動視窗（sliding window）

想像一長排編號的包裹，加上一個會移動的取景框，每次只框住其中幾個——就是你目前還沒收到確認前，被允許出貨的那幾個。當最早被框住的包裹確認送達後，取景框就往前滑，露出下一個。那個移動的取景框就是滑動視窗：發送方在任一時刻可以讓多少序號在途中（尚未確認），並隨著確認回來而往前推進。

發送方與接收方都各維護一個視窗。發送方的視窗裝著它已送出但還沒被確認的訊框；當編號最小的訊框被 ACK，視窗就往上滑，發送方便可在頂端送出一個新訊框。接收方的視窗則描述它目前願意接受哪些進來的序號。視窗的「大小」限制了同時能有多少資料未被確認，而這單一個數字掌控著吞吐量：太小，連結就閒著等 ACK（停止等待的毛病）；夠大，連結就持續保持塞滿。

正確的視窗大小和頻寬延遲乘積綁在一起——也就是連結的資料率乘以它的往返時間，亦即同時能有多少位元在途中。要讓管子塞滿，你會希望視窗至少有那麼大；這正是為什麼一條又快又長途的連結（高頻寬、高延遲）需要大視窗才跑得好，也是為什麼過小的視窗會連快速連線都掐住。後退 N 與選擇性重送都是滑動視窗協定，而 TCP 在流量控制與壅塞控制上都用滑動視窗。一個常見的混淆：視窗限制的是「未確認」的資料量，而不是你「總共」能送多少。