已发送但未确认的数据量 ≤ 接收窗口大小（RWND）  

TCP的滑动窗口与流量控制机制详解 1. 问题背景 TCP需要实现可靠传输和流量控制。可靠传输依赖确认重传机制，但若发送方每发送一个报文段就等待确认，效率极低（类似“停止等待协议”）。流量控制则需解决 接收方处理速度不及发送方 的问题，避免数据淹没接收方。滑动窗口机制同时解决这两个问题。 2. 核心概念：滑动窗口 滑动窗口本质是 发送方和接收方各自维护的一个缓冲区范围 ，用于限制可发送/可接收的数据量。 发送窗口（Send Window, SWND） ：发送方允许连续发送但未确认的数据范围。 接收窗口（Receive Window, RWND） ：接收方当前可接收的数据范围（由接收方缓存剩余空间决定）。 关键点 ： 窗口内的序号代表可发送或已发送但未确认的数据。 窗口会随着确认的到达向前“滑动”（即移动左边界）。 窗口大小由接收方通过TCP头部的 Window 字段动态通知发送方。 3. 窗口的组成与滑动过程 以发送窗口为例，其结构分为三部分（假设窗口大小为4个报文段）： 已发送且已确认 （窗口左侧，不再属于窗口） 已发送但未确认 （窗口内左侧部分） 未发送但可发送 （窗口内右侧部分，需等待窗口滑动或新空间） 未发送且不可发送 （窗口右侧，需等待窗口滑动） 滑动示例 ： 初始：发送窗口序号范围 [ 1, 4 ]（大小=4），假设所有数据未发送。 步骤1：发送序号1-2，窗口内变为 [ 已发1-2 | 可发3-4 | 不可发5+ ]。 步骤2：收到对序号1的确认，窗口右移，新范围 [ 3, 6 ]（大小不变）。 此时可发送序号3-4（原可发部分）和5-6（新加入窗口部分）。 4. 流量控制的实现 接收方通过TCP头部的 Window 字段告知发送方当前剩余接收缓存大小（即接收窗口大小）。发送方需保证： 动态调整过程 ： 接收方处理应用层数据后，接收缓存空出，更新RWND。 接收方在下次确认报文（ACK）中携带新RWND值。 发送方收到后调整发送窗口上限，避免发送过多数据。 特殊场景——零窗口（Zero Window） ： 若接收方缓存满，RWND=0，发送方会暂停发送。 为防止死锁，发送方启动 零窗口探测（Zero Window Probe, ZWP） ，定期发送1字节数据触发ACK，以获取最新RWND。 5. 与拥塞控制的区别 流量控制 ：解决发送方与接收方之间的速度不匹配（基于接收方能力）。 拥塞控制 ：解决网络路径的过载问题（基于网络状态）。 实际发送窗口大小取 min(RWND, CWND) （CWND为拥塞窗口）。 6. 技术细节与优化 窗口缩放选项（Window Scale Option） ： TCP头部 Window 字段仅16位，最大RWND=64KB。 在高速网络中不够用，通过握手阶段协商缩放因子（左移位数），支持最大1GB窗口。 糊涂窗口综合征（Silly Window Syndrome, SWS） ： 若接收方每次只释放少量缓存，导致发送方传输小报文，降低效率。 解决：接收方采用“延迟通知”（等缓存空出一定比例再更新RWND），发送方避免发送小数据（Nagle算法）。 7. 总结 滑动窗口通过动态调整发送/接收数据的范围，实现了： 可靠性 ：对窗口内数据进行批量确认和重传。 效率提升 ：允许连续发送多个报文段。 流量控制 ：依赖RWND反馈机制保护接收方。 此机制是TCP核心设计之一，需结合拥塞控制共同理解实际数据传输逻辑。