流量控制与拥塞控制：窗口、慢启动与拥塞避免

两种不同的限制

可靠传输解决丢包与受损，并不意味着发送方应该无限加速。接收应用可能读取很慢，路由器也可能排队溢出。流量控制保护接收方，拥塞控制保护网络；两者分别使用接收窗口$rwnd$与拥塞窗口$cwnd$。

流量控制与接收缓存

接收方用通告窗口告诉发送方当前还能接收多少字节。设缓存容量为$RcvBuffer$，已收到但应用尚未读取的字节数为$Buffered$，简化模型中：

发送方需要扣除已发但未确认的在途字节$Flight$，不能把整个窗口都当作新的可发送额度：

这里忽略窗口缩放、窗口右边界的更新规则与SACK等实现细节。应用读取会释放接收缓存，但发送方只有收到窗口更新后才知道新的额度。

零窗口与持续探测

通告窗口为0时，发送方停止发送正常新数据。若接收方随后开放窗口，而窗口更新丢失，双方可能一直等待。持续定时器触发小型零窗口探测，使接收方再次报告窗口；探测不是无视接收缓存限制的批量发送。

拥塞窗口与反馈

多个发送方共享链路时，过多在途数据会增加排队时延并引起丢包。拥塞窗口限制网络中的未确认字节；ACK提供进展反馈，丢包或显式拥塞通知（ECN）提供拥塞信号。丢包也可能来自无线差错，因此丢包是拥塞推测，不是唯一原因的证明。

理想情况下，窗口限制的吞吐量约为$\min(rwnd,cwnd)/RTT$，但实际还受链路容量、丢包与协议开销限制。接收窗口大不代表网络就能承受同样大的发送速率。

慢启动与拥塞避免

下面使用经典Tahoe/Reno的简化教学模型，窗口单位为最大报文段载荷MSS；实验初始$cwnd=1$ MSS、$ssthresh=8$ MSS，不代表所有现代TCP的初始窗口。

慢启动在每轮RTT获得足够ACK时近似翻倍增长，直至慢启动阈值$ssthresh$。到达阈值后进入拥塞避免，每轮RTT近似增加一个MSS。实际算法按每个ACK更新窗口，实验在阈值处截断一轮增长，突出两个阶段的区别。

这种加性增加与乘性减小（AIMD）在网络反馈中寻找可用容量，而不是预先知道链路带宽。它有助于分享容量，但不保证任意RTT与丢包条件下严格公平。

超时、快速重传与快速恢复

本节将事件前窗口的一半作为新阈值，至少两个MSS。超时后，Tahoe与Reno都将$cwnd$降为一个MSS并重新慢启动。实际阈值计算通常基于丢包时的FlightSize，而不总是等于当前cwnd。

遇到三个冗余ACK时，Tahoe同样回到慢启动。经典Reno进入快速恢复：重传缺失报文段，把$cwnd$临时设为$ssthresh+3$ MSS；确认新数据后缩回$ssthresh$并进入拥塞避免。这里不模拟额外冗余ACK、部分确认或NewReno扩展。

现代网络中也会使用CUBIC等不同的拥塞控制算法。应把本节的经典模型视为理解窗口与反馈的基础，而不是所有系统行为的精确复刻。