滑动窗口协议

滑动窗口协议

滑动窗口协议是TCP 的一种应用，用于网络数据传输时的流量控制，以避免拥塞的发生

滑动窗口协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认。因此该协议可以加速数据的传输，提高网络吞吐量。

注意事项:

（1）发送方不必发送一个全窗口大小的数据。

（2）来自接收方的一个报文段确认数据并把窗口向右边滑动，这是因为窗口的大小是相对于确认序号的。

（3）窗口的大小可以减小，但是窗口的右边沿却不能够向左移动。

（4）接收方在发送一个ACK前不必等待窗口被填满。

收发方的窗口大小一致

收发方的窗口大小不一致

 

停止等待协议(stop-and-wait)

发送窗口=接收窗口= 1,1个比特就够表示了,所以也叫1比特滑动窗口协议, 发送单帧后必须等待确认，未确认前不能再发送其他数据帧

问题: 发送方交替发送标记为“奇数”和“偶数”的数据包。 发送的确认同样为“奇数”和“偶数”。 假设已经发送了奇数分组的发送 方没有收到奇数确认，而是立即发送下一个偶数分组，在此之后它可能会收到一个确认，为“下一个奇数包”。这将使发送方出现不确定因素：接收方有可能接收到这两个数据包，或者两者都没接收到。

 

 

回退n步协议（GO-BACK-N）

由于停止等待协议效率太低，因此有了回退n-步协议，这也是滑动窗口协议真正的用处，这里发送的窗口大小为n，接受方的窗口仍然为1。具体看下面的图，这里假设n=10： 首先发送方一口气发送9个数据帧，前面两个帧正确返回了，数据帧2出现了错误，这时发送方被迫重新发送2-8这7个帧，接受方也必须丢弃之前接受的3-8这几个帧。 后退n协议的好处无疑是提高了效率，但是一旦网络情况糟糕，则会导致大量数据重发，反而不如上面的停等协议。

 

存在的问题在于，假设我们使用3位序列号，这是HDLC的典型值。 这使得N = 2^3 = 8 由于wr = 1，我们必须限制wt≤7。 这是因为在发送7个数据包之后，有8个可能的结果：0到7个数据包都可能被成功地接收。 这有8种可能性，发送方在确认中需要足够的信息来区分它们。如果发送方发送8个数据包而不等待确认，则可能会发现自己存在和停止等待协议一样的问题：这意味着所有8个数据包都可能被成功接收，亦或是一个都没有被成功接收。

 

选择重传协议（selective repeat）

后退n协议的另外一个问题是，当有错误帧出现后，总是要重发该帧之后的所有帧，毫无疑问在网络不是很好的情况下会进一步恶化网络状况，选择重传协议是对N步回退协议的一种优化

原理：接收端总会缓存所有收到的帧，当某个帧出现错误时，只会要求重传这一个帧，只有当某个序号后的所有帧都正确收到后，才会一起提交给高层应用。重传协议的缺点在于接受端需要更多的缓存。

对比