三句话介绍清楚滑动窗口协议/GBN/SR

滑动窗口协议、GBN、SR之间不得不说的故事

首先我们来介绍什么是滑动窗口协议

滑动窗口协议（Sliding Window Protocol），属于TCP协议的一种应用，用于网络数据传输时的流量控制，以避免拥塞的发生。该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输，提高网络吞吐量。关于TCP协议的介绍，可以查看我的另外一条博文《计算机网络自顶向下》知识体系梳理

如果许多客户向主机以很快的速度发送大量的数据包，但是接收方却没有如此高的接收数据的能力，这个时候，我们就要控制发送方的发送速度，控制它不要过快，要求发送方限制它已经发出但未经确认的帧的数目，使得网络传输效率得以提高，滑动窗口协议就是这么来的。
在任何基于自动重发请求进行错误控制的通信协议中，接收方必须确认收到的数据包。
如果发送方在合理的时间内没有收到确认，则重发数据。没有听到确认的发送方不知道接收方是否实际接收到分组（数据可能在传输中丢失或损坏）。如果错误检测显示损坏，则数据包将被接收方忽略，并且不会发送确认。因为网络传输的时延，将有大量时间被用于等待确认，导致传输效率低下。

定义

传输的每个部分被分配唯一的连续序列号，接收方使用数字并以正确的顺序放置接收到的数据包，丢弃重复的数据包并识别丢失的数据。

工作原理

简单来说：第一个和第二个包发送过去后，收到第一个确认包就把第三个包发送过去，图示如下（图片来源于网络）：

在这张图里我们可以看到，灰色1，2，3号包已经发送完毕，并且已经收到了ACK，4，5，6，7号包是黄色的，表示已经发送的，没收到ACK的意思就是也不知道对方接收到了没有，但还没有收到ACK，8，9，10号包是绿色的，表示还未发送，白色部分表示还未读入内存，要等到4-10号包收到ACK后才会有所动作。

发生丢包时

这种情况可能是我们包发过去，对方的ACK丢了；或者是我们的包并没有发生过去，对方没有收到ACK。
此时的情况：一直在等ACK，如果一直等不到ACK发过来，我们就会把读进缓存的ACK包也一起发送过去，但这个时候窗口已经发满了，说一并不能读取12号包，而是在一直等待5号包的ACK。

当ACK包一直发送不过来的情况时

解决方法：超时重传
ACK是要按照顺序发送的，也就是说，必须等到5的ACK收到，才会把6-11的ACK发送过去，这样做的目的是为了保持滑动窗口的顺序。

上图可以看出5号包已经接受ACK，后面的6，7，8号包也发送过去，窗口便继续向后移动。

GBN协议

后退N帧ARQ协议对传统的自动重传请求（ARQ,Automatic Repeat reQues）进行了改进，从而实现了在接收到ACK之前能够连续发送多个数据包。

工作过程

GBN协议中，发送方在发完一个数据帧后，连续发送若干个数据帧，即使在连续发送过程中收到了接收方发来的应答帧，也可以继续发送。且发送方在每发送完一个数据帧时都要设置超时定时器。只要在所设置的超时时间内仍未收到确认帧，就要重发相应的数据帧。如：当发送方发送了N个帧后，若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息，则该帧被判为出错或丢失，此时发送方就不得不重新发送出错帧及其后的N帧

确认过程

接受帧只允许按顺序接受帧。为了减少开销，累计确认允许接收端在连续收到好几个正确的确认帧后，只对最后一个数据帧发确认信息，或者可以在自己有数据要发送时才将对以前正确收到的帧加以捎带确认。这就是说，对某一数据帧的确认就表明该数据帧和这以前所有的数据帧均已正确无误地收到了。