百度百科：滑动窗口机制
知乎：TCP协议的滑动窗口具体是怎样控制流量的？

滑动窗口机制

滑动窗口协议是传输层进行流控的一种措施，接收方通过通告发送方自己的窗口大小，从而控制发送方的发送速度，从而达到防止发送方发送速度过快而导致自己被淹没的目的，并且滑动窗口分为接收窗口和发送窗口。

滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序列号代表了那些已经被发送，但是还没有被确认的帧，或者是那些可以被发送的帧。

要了解滑动窗口机制必须回顾ACK的作用。我们知道如果接收方成功的接收到数据，那么会回复一个ACK数据，其中ACK中包含两个非常重要的信息：

  • 期望接收下一字节的序号n。
  • 当前滑动窗口的大小m。

而ACK所携带的滑动窗口的大小m便是我们滑动窗口机制中的主角了，由它来负责机制的通信。通信过程下图所示：

java限流 滑动窗口算法实现 滑动窗口限流原理_滑动窗口协议

滑动窗口基本原理

  • 对于TCP会话的发送方，任何时候在其发送缓存内的数据都可以分为4类，“已经发送并得到对端ACK的”，“已经发送但还未收到对端ACK的”，“未发送但对端允许发送的”，“未发送且对端不允许发送”。“已经发送但还未收到对端ACK的”和“未发送但对端允许发送的”这两部分数据称之为发送窗口。

    当收到接收方新的ACK对于发送窗口中后续字节的确认是，窗口滑动，滑动原理如下图。

    当收到ACK=36时窗口滑动。
  • 对于TCP的接收方，在某一时刻在它的接收缓存内存在3种。“已接收”，“未接收准备接收”，“未接收并未准备接收”（由于ACK直接由TCP协议栈回复，默认无应用延迟，不存在“已接收未回复ACK”）。其中“未接收准备接收”称之为接收窗口。发送窗口与接收窗口关系TCP是双工的协议，会话的双方都可以同时接收、发送数据。TCP会话的双方都各自维护一个“发送窗口”和一个“接收窗口”。其中各自的“接收窗口”大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。各自的“发送窗口”则要求取决于对端通告的“接收窗口”，要求相同。

    • java限流 滑动窗口算法实现 滑动窗口限流原理_滑动窗口协议_02

滑动窗口实现面向流的可靠性

  • 最基本的传输可靠性来源于“确认重传”机制。
  • TCP的滑动窗口的可靠性也是建立在“确认重传”基础上的。
  • 发送窗口只有收到对端对于本段发送窗口内字节的ACK确认，才会移动发送窗口的左边界。
  • 接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传。
  • 应用程序在需要（如内存不足）时，通过API通知TCP协议栈缩小TCP的接收窗口。然后TCP协议栈在下个段发送时包含新的窗口大小通知给对端，对端按通知的窗口来改变发送窗口，以此达到减缓发送速率的目的。