【计算机网络 | 第二十二篇】一文搞懂「滑动窗口」与流量控制

文章目录一、 为什么需要滑动窗口从阻塞到并发二、 图解发送方的窗口结构三、 窗口是怎么“滑动”的滑动与发送规则1. 发送规则2. 滑动规则与“累计确认”机制四、 窗口大小由谁决定流量控制相关小结在计算机网络中TCP 的可靠性与性能优化是绕不开的重点。很多同学在背诵八股文时其中很重要的「滑动窗口」机制保障了网络通信的效率本文我们抛开枯燥的定义结合 Java 并发编程中的队列思想把 TCP 滑动窗口的引入原因、窗口结构、滑动规则以及流量控制一次性彻底捋清。一、 为什么需要滑动窗口从阻塞到并发要理解滑动窗口首先要明白没有它的时候TCP 是怎么工作的。在最原始的 TCP 模型中采用的是停等协议Stop-and-Wait发送方发一个数据包必须原地等待接收方的 ACK 确认收到确认后才能发下一个包。☕ 类比这就像 Java JUC 里的SynchronousQueue同步队列容量为 0。生产者发送方放进去一个元素必须阻塞等待消费者接收方拿走才能继续放下一个。在网络延迟RTT较高的传输中这种“一问一答”的模式会导致大量时间浪费在等待网络传输上带宽利用率极低。为了解决效率问题TCP 引入了滑动窗口Sliding Window机制。它的本质是允许发送方在未收到全部 ACK 的情况下连续发送多个数据包。☕ 类比引入滑动窗口后TCP 就像换成了一个ArrayBlockingQueue有界阻塞队列。生产者可以一口气往队列里塞满数据连续发送只要队列没满就不需要阻塞等待。消费者慢慢处理处理完一个就腾出一个空位ACK 确认窗口滑动生产者就可以继续塞数据。这样极大地提升了网络吞吐量。二、 图解发送方的窗口结构图片参考小林coding以发送方的视角来看TCP 内部维护了一个发送缓存字节流队列。滑动窗口就像一个“框”框住了当前正在处理的数据。整个发送缓存区被划分为了4 个绝对明确的区域已发送且已确认已出窗位于窗口最左侧。这部分数据已经成功抵达接收方并收到 ACK可以从发送缓存中安全清除了。已发送但未确认窗口内左侧已经发往网络中但还没收到接收方的 ACK 回执。如果超时这部分数据可能会被重传。未发送但允许发送窗口内右侧也叫可用窗口。这部分数据还在本地但由于没有超过接收方的处理上限随时可以立即发送。未发送且不允许发送未入窗位于窗口最右侧。因为超出了接收方当前的处理能力超出了窗口大小必须乖乖在本地等着暂时不能发送。 总结所谓的“滑动窗口”其实就是包含了上述第 2 部分 第 3 部分的数据区间。三、 窗口是怎么“滑动”的滑动与发送规则窗口的运作机制核心在于两个动作发送与滑动。1. 发送规则只要窗口内的“可用窗口第3部分”大于 0发送方就可以肆无忌惮地往网络中发送数据。随着数据的发送可用窗口的额度逐渐消耗直到变为 0此时发送方必须停止发送阻塞等待 ACK。2. 滑动规则与“累计确认”机制当发送方收到接收方发来的 ACK 确认报文时窗口就会向右滑动。滑动动作收到 ACK 后原本处于“第2部分已发未确认”的数据变成“第1部分已确认”移出窗口。同时窗口整体右移将右侧“第4部分”的新数据纳入“第3部分可用窗口”。 核心优化累计确认TCP 接收方不必对每一个包都回复 ACK而是回复一个期望收到的下一个字节的序号。例如哪怕发送方没有收到ACK 600但只要收到了ACK 700发送方就会立刻明白“ok接收方已经完美收到了 700 之前的所有数据”这种机制不仅减少了 ACK 报文的数量还能完美容忍中间某些 ACK 报文在网络中丢失的情况避免了不必要的重传。四、 窗口大小由谁决定流量控制相关发送方的窗口能不能无限大当然不能。如果发送方像机关枪一样发数据接收方的内存缓冲区满了处理不过来多出来的数据只能被丢弃导致严重的丢包重传。因此发送方的窗口大小是由接收方决定的在每次 TCP 通信时接收方会在 TCP 报文头部的Window窗口大小字段中填入自己当前剩余的接收缓冲区大小。发送方收到后会严格按照这个数值来调整自己的发送窗口大小确保发送窗口 ≤ 接收窗口。这就是 TCP 的流量控制通过动态调整滑动窗口的大小让发送方的发送速率完美匹配接收方的处理能力既不让网络空闲也不把接收方撑死。小结TCP 的滑动窗口核心点引入原因为了解决原始“停等协议”一问一答导致的低效率滑动窗口允许在未收到 ACK 前连续发送多个数据包大幅提升网络吞吐量。窗口结构发送方缓存被分为 4 个部分已发送已ACK、已发送未ACK、未发送可发送、未发送不可发送。窗口本身包含了中间两部分。滑动机制依靠累计确认机制收到 ACK 后窗口整体右移释放已确认数据纳入新数据入窗。累计确认还能有效应对部分 ACK 丢失的问题。流量控制滑动窗口的大小由接收方通过 TCP 报文头的Window字段动态通告以此限制发送方的发送速率避免接收方缓冲区溢出实现端到端的流量控制。