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

本文链接：https://blog.csdn.net/m0_74352571/article/details/139141961

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

一、停止-等待协议

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

在这里插入图片描述

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

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

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

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

第二种情况——超时重传

在这里插入图片描述

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

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

第三种情况——确认丢失

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

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

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

此情况过程如下图所示：

在这里插入图片描述

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

第四种情况（确认迟到）

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

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

在这里插入图片描述