[TCP/IP] 滑动窗口

什么是滑动窗口？

滑动窗口机制是TCP协议的一种流量控制和防拥塞的机制。

滑动窗口的工作原理？

简单来讲，就是接收方和发送方分别保留一块缓冲区，作为接收和发送数据来使用，发送数据过程中，如果发送方发的快了，处理方处理不过来，缓冲区放不下了，接收方就会通过消息交互告诉发送方，慢点发，等接收方处理完，可接收了，又会通知发送方可以继续发送了，通过这种方式来防止由于双方能力不一致导致的拥塞和丢包。

工作原理举例，以发送方为例

老规矩，先上图，直观看一下

滑动窗口组成

可以看到，滑动窗口被分成了四部分，分别代表滑动窗口工作过程中数据的4种分类或者叫状态。从左到右依次为：

第一部分：已经被对方成功接收的数据；

第二部分：已经发送还没有收到ack的数据；

第三部分：可以发送但是尚未发送的数据；

第四部分：暂时不能发送的数据。

蓝色框里包含了第二和第三两部分数据，这部分实际上是正在被发送的数据，所以蓝框部分也被称为发送窗口；

下面我们以图示的第二部分数据为例，来说明一下滑窗的几种工作情形。为便于描述确认过程和滑窗移动，我们将第二部数据分成三小段，分别是32-39 40-45 46-51.

正常发送和接收

数据32-39已经被成功发送了，并且接收方也收到了对应的数据，这时候接收方会给发送方回复ack确认ack 40，告诉发送端数据已经收到，同时会携带剩余接收窗口的大小，比如是10个字节。此时发送窗口就会向右移动8个字节，将32-39放入第一部分数据，同时将52-59放入第三部分，准备发送；这就完成了一次数据的正常发送和确认过程。

流量控制，防止拥塞

之后发送端开始发送数据，我们看第三部分数据，46-59，共14个字节，但是上一步中接收方通告的报文中告诉发送方，当前接收窗口只剩10个字节，所以发送方本次最多只会发送10个字节，接收到这10个字节之后，接收端可能就会向发送端回复一个窗口为0的报文，告诉发送端先不要发送了，没有地方放了。通过这种方式来实现流量控制，防止接收端拥塞丢包。

那你可能会问，为啥接收端的窗口会变小或者为0呢？这是因为，tcp接收到数据之后，会存放到缓冲区，等待应用来读取，如果应用读取慢了，数据就可能在缓冲区存放一段时间，所以可能会出现占满缓冲区的情况，等把数据读走了，接收端会通知发送端窗口可用并告知大小，发送端就又可以开始发送数据了，周而复始。

报文丢失，超时重传

继续看，我们共发送了三部分数据：32-39 40-45 46-51。32-39已经被ack确认过了，但是后边的两组还没有确认，假如在传输过程中40-45丢失了，接收方只收到了46-51，那会怎么处理呢？接收端接收到46-51之后，首先会将数据保存起来，等待40-45，但是由于这部分数据丢失，接收方一直不可能收到，所以也不能回复ack给发送方。发送方得不到ack，无法判断数据是否被正确收到，滑窗就不能向右移动，无法继续发送数据，如何解决这个问题呢？对了，答案就是定时器。发送方在发送数据之后会启动一个重传定时器，定时器超时之前如果收到ack，就把定时器停掉就可以了。定时器超时还没有收到ack，那么发送方就认为数据传送丢失，开始重新发送没有被ack确认过的数据，这就是超时重传机制。

这里注意一点：虽然46-51没有丢失，但是发送方无法判断具体是哪些数据丢失了，所以会把所有发出没有被确认的数据统一重传一遍。