滑动窗口与接收方流量控制

形式陈述

TCP可在等待确认时继续发送后续字节，但接收缓存有限。接收方通告窗口rwnd表示从当前ACK位置开始愿意接收的序号范围；发送者据最新有效窗口信息限制新增数据。窗口向右移动使已确认的位置退出、未来位置进入，因而称滑动窗口。

本页用不绕回的展开序号，令 $u=\mathrm{SND.UNA}$ 、 $n=\mathrm{SND.NXT}$ ，最新ACK对应的窗口右端为 $u+w$ 。在没有其他限制且窗口信息已正确更新的快照中，新增发送预算为

\max(0,u+w-n).

若再考虑拥塞窗口 $c$ ，则简化预算为 $\max(0,\min(w,c)-(n-u))$ 。rwnd保护接收方缓存，cwnd限制对共享网络的在途压力；两者不是相同变量。

为明确缓存义务，设接收应用已消费前缀末端为 $q$ ，TCP连续接收末端为 $r$ ，缓存容量为 $C$ 。教学实现为所有位置 $[q,q+C)$ 预留格子，通告右端 $q+C$ ，所以 $w=q+C-r$ 。乱序字节若落在该范围也占其格子。必须保持 $q\le r\le q+C$ ，同一位置的重复包不增加格子数。只有应用消费推动 $q$ ，才在右端增加新容量；发出ACK本身不会删掉尚未被应用读取的字节。

真实TCP还要过滤陈旧窗口更新、处理序号绕回及可能的窗口收缩。接收方不应收缩已经通告的右边界；本页的 $q+C$ 单调方案避免该问题。若窗口变为零，发送者暂停通常的新数据发送，但以零窗口探测及反馈恢复窗口信息，不能永久等待可能已经丢失的唯一一份“窗口打开”通知。

直觉

ACK回答“前面已收到哪里”，窗口回答“后面还预留多少位置”。接收者可能已确认一批数据，却尚未交给应用，因此ACK前进而窗口同时缩小；发送者释放了重传副本，也未必获得更多发送额度。

把接收缓冲变大可以延迟堵塞，但不会让一个永久不读数据的应用突然开始消费。流控把这种下游压力逐步传回发送端。这里滑动的是可接收序号范围；滑动窗口数据流则按时间或最近项数淘汰统计对象，二者不是同一个问题。

例子与边界

发送快照为 $u=1000,n=1600,w=1000$ ，窗口右端2000，允许再发400字节。随后收到ACK=1300、rwnd=700，右端仍是2000，仍只能再发400字节，尽管已有300字节获确认。

再设接收端 $q=1000,r=1600,C=1000$ ，已收未读600字节，所以通告400。若再收400字节而应用仍不读，变为 $r=2000,w=0$ 。应用读去500字节后， $q=1500$ ，右端2500，窗口恢复500。若这个窗口更新包丢失，后续探测促使对端重报当前窗口；零窗口不是连接已死的结论。

对于第一快照，若同时有cwnd=800，在途 $n-u=600$ ，新的共同预算只有 $\min(1000,800)-600=200$ 。只按rwnd扣除在途而忽略cwnd，会多发200字节，忽略已经在途的600则会多发更多。

推论与应用

窗口单位是字节，带宽单位是字节/秒，二者经RTT联系。在理想稳定流水、无损且ACK及时的简化模型中，窗口 $W$ 给出约 $W/\mathrm{RTT}$ 的吞吐上限；要用满速率 $B$ 的链路，窗口至少需覆盖约 $B\times\mathrm{RTT}$ 的在途数据。这是性能模型，不能据此保证排队时延或公平性。

应用背压必须继续约束TCP缓冲之外的队列。若网络线程不停read然后把数据搬入无限应用队列，TCP窗口一直很宽，也可能把进程内存耗尽。

多个流共享一个连接时，还需同时检查各流上限与连接合计。多流信用与最终长度使用单调绝对许可和4+3账本，说明重传不重复计费、RESET仍须按最终长度结算；这与本页TCP的ACK加通告窗口坐标不同。

参考资料

RFC 9293，§§3.8.6–3.8.6.2：窗口管理、右边界收缩与零窗口探测；本页 $q+C$ 是便于证明的固定格子模型。
Peterson、Davie，Computer Networks: A Systems Approach，在线6.2-dev版，§5.2.4：发送/接收前沿与流量控制。

形式陈述 ​

反向链接

形式陈述