【计算机网络】第三章——停止-等待协议

个人主页：兜里有颗棉花糖
欢迎 点赞👍 收藏✨ 留言✉ 加关注💓本文由 兜里有颗棉花糖 原创
收录于专栏【计算机网络】
本专栏旨在分享学习计算机网络的一点学习笔记，欢迎大家在评论区交流讨论💌

一、停止-等待协议

收发双方基于互联网进行通信，而不是局限在一条点对点的数据链路，纵坐标为时间，如下图所示：

第一种情况——确认与否认

过程：发送方给接收方发送数据分组，接收方受到后对其进行差错检测。若没有误码则接受该数据分组，并给发送方发送确认分组（简称ACK），发送方收到对所发送数据分组的确认分组后，才能发送下一个分组；而如果该数据分组在传输过程中出现了误码，接收方收到后对其进行差错检测并发现了误码，则丢弃该数据分组，并给发送方发送否认分组（简称NAK），发送方收到对所发送数据分组的否认分组后就知道了之前自己所发送的数据分组由于出现差错而被接收方拒绝，于是立即重传该数据分组。因此，发送方每发送一个数据分组后，并不能立刻将该数据分组从缓存中删除，只有收到该数据分组的确认分组后才能将该数据分组从缓存中删除。

故发送方每发送一个数据分组后就停止发送下一个数据分组，等待来自接收方的确认分组或否认分组：如果收到确认分组，则可继续发送下一个数据分组；若收到否认分组，则重发之前发送的那个数据分组。这样就实现了发送方发送什么接收方最终就能收到什么（即可靠传输）。

然而上述过程中的实际情况远远要复杂得多：下面我们来看一种情况。

第二种情况——超时重传

发送方给接收方发送数据分组，然而数据分组在传输过程中丢失了，需要说明的是，对于数据链路层点对点信道而言，不太容易出现数据分组丢失的这种情况，但是对于多个网络通过路由器、互连的复杂互联网环境而言，数据分组这种情况是经常出现的。对于这种情况，接收方做出的反应如下图所示：

如下图所示，发送方超时重传之前所发送的数据分组，接收方正确接收重传的数据分组后，给发送方发送确认分组，发送方收到确认分组后继续发送下一个数据分组；然后接收方正确接收该数据分组后给发送方发送确认分组。到目前为止，貌似基于停止等待，使用确认或否认分组再加上超时重传的手段，就可以实现可靠传输了。但是如果再深入思考一下，目前的这些手段是不足以应对实现可靠传输的其它情况的。

第三种情况——确认丢失

下面我们再来看一种情况：既然发送方发送的数据分组可能丢失，那么接收方发送的确认分组或否认分组就也有可能丢失。例如，发送方发送了一个数据分组，接收方正确接收了该数据分组后，给接收方发送确认分组，但是该确认分组在传输过程中丢失了，这里就会触发发送方对之前所发送数据分组的超时重传，现在假设这个重传的数据分组正确到达了接收方，此时新的问题出现了，接收方如何判断该分组是一个重复的数据分组呢？

为避免分组重复这种传输错误，必须给每个分组带上序号。比如该数据分组的序号是0。对于停止-等待协议，由于每发送一个数据分组就停止等待,只要保证每发送一个新的数据分组，其发送序号与上次发送的数据分组的序号不同就可以了，因此用一个比特来编号就够了（即序号0和1）。

这样，根据数据分组的序号，接收方就可以判断该数据分组是否是一个重复的数据分组了，接收方丢失重复的数据分组，并给接收方发送针对该数据分组的确认分组，以免触发发送方对该数据分组的再次超时重传。发送方收到针对0号数据分组的确认分组，就可以发送下一个数据分组（下一个数据分组的序号为1）了。

此情况过程如下图所示：

接收方正确收到该数据分组后给发送方发送确认分组，我们通过确认分组的丢失情况引出了给数据分组编号的问题，我们可以想一想既然数据分组需要编号，那确认分组需不需要编号呢？下面我们再来看一种情况：

第四种情况（确认迟到）

现在我们来看确认迟到所导致的重复确认的情况。

来看，发送方发送0号数据分组，接收方正确接收后给发送方发送确认分组。由于某些原因，该确认分组迟到了，此时就会触发发送方对0号数据分组的超时重传。在重传的0号数据分组的传输过程中，发送方收到了确认的重复分组，于是发送1号数据分组；而接收方收到重传的0号数据分组后，发现这是一个重复的数据分组，将其丢失并针对该数据分组给发送方发送确认分组，以免发送方再次触发超时重传重传该数据分组。此时此刻又有新的问题出现了，通过下图我们可以看到，这是一个对0号数据分组的重复确认，但是发送方又怎么能够知道呢？所以，如果不采取一些措施的话，发送方此时会误认为这是对一号数据分组的确认。

如果对确认分组也进行编号的话，就可以使发送方避免这种情况的误判。如下图所示，该确认分组的序号是0，发送方收到该数据分组的确认分组后知道这是一个重复的确认分组，将其忽略（如下图所示）。

接下来接收方正确接收数据分组后，给发送方发送针对该数据分组的确认分组，其序号为1；发送方收到该确认分组后继续发送下一个数据分组，序号为0。这里我们要格外注意：此时序号为0的数据分组与之前的那个序号为0的数据分组不是同一个数据分组。

现在，我们通过给确认分组编号的方法解决了确认迟到所导致的重复确认的问题。

需要说明的是，对于数据链路层的点对点信道，往返时间是比较固定的，一般不会出现确认迟到的情况。所以，如果只在数据链路层实现停止-等待协议可以不用给确认分组编号。

小结

二、停止-等待协议的信道利用率

• 如下图所示，横坐标为时间。现在假设收发双方之间是一条直通的信道，发送方发送完一个数据分组后就停止发送，等待接收方对该确认分组的确认。当收到确认分组后就可以发送下一个数据分组，如此反复进行。

• 图中忽略了接收方对数据分组的处理时延以及发送方对确认分组的处理时延。这是停止等待协议的发送方从发送一个数据分组开始，到可以发送写一个数据分组为止所经理的总时间（TD+RTT+TA）。仅仅是在时间TD内，传送的有用的数据是即数据分组。

所以信道的利用率U可用下式来计算。

TA是远小于TD的，所以可以忽略不计。而当RTT远大于TD时，信道利用率会非常低。

三、停止-等待协议信道利用率低

练习

四、总结

像停止-等待协议这种通过确认和重传机制实现的可靠传输协议，常称为自动请求重传协议ARQ，即重传的请求是自动进行的，因为不需要接收方显示地请求发送方重传某个出错的分组。

本文到这里就结束了，希望友友们可以支持一下一键三连哈。嗯，就到这里吧，再见啦！！！