停止等待协议（SW）——可靠传输协议的实现机制一

本博客参考视频链接：
https://www.bilibili.com/video/BV1x4411d7HU?p=25

SW（Stop and Wait）停止等待协议

这里通过把SW可能遇到的问题，把SW分成四个小部分来讲，即该协议使用过程中可能会遇到的问题以及该协议如何解决此类问题。

1.确认与否认

首先，每次发送方都只发一个数据分组，接收方对数据分组进行差错检测，检验是否有误码。
如果没有误码，那么给发送方发送ACK确认分组；
如果有误码，则丢弃分组，并给发送方发送NAK否认分组。

2.超时重传

但其实，数据分组在传输过程中并不会那么一帆风顺，数据分组有可能在半路上遇到一个已经满了的路由器等情况，此时路由器会毫不犹豫地丢失该分组，如此便会产生数据分组被丢失，发送方等不到接收方的ACK或者NAK。
所以，我们需要给每次的数据分组的传输提供一个超时计时器，若到了超时计时器所设置的重传时间，而发送方仍收不到接收方的ACK或NAK，则重传原来的数据分组。
一般可将重传时间选为略大于“从发送方到接收方的平均往返时间”

3.确认丢失

现在，假设一下，如果是接收方的ACK在传输过程中丢失，又该怎么办呢？
此时，我们知道这肯定会触发发送方的超时计时器，让发送方重传，可是，刚才发送方的数据分组其实已经被接收方成功接收了。
这个时候，我们就需要给用一个比特位给每个数据分组一个序号（0或1），如此，当重新传输数据分组0的时候，接收方检测到这个数据分组0跟刚才的数据分组0是同一个，就果断丢弃该数据分组，并重发一个ACK给发送方。
这里为什么可以只用0和1呢，主要还是因为停止等待协议的特性，即每发送完一个数据分组便等待发送方的ACK或者NAK，因此，其实只需要让接收方知道这个重新发过来的分组是不是刚才已经接收过的分组就可以了。

4.确认迟到

上面，我们知道发送方发送的数据分组需要序号，那么接收方发送的ACK是否需要序号呢，答案是肯定的。
发送方给接收方发送一个数据分组，接收方可能接收并给发送方发送ACK，此时，如果ACK遇到某些问题，导致该ACK迟到了，那么有可能会触发发送方的超时重发，此时，发送方又发了一个DATA0，接收方误以为是之前的ACK丢包而重发一个ACK，如果没有给ACK编号的话，那么DATA0的两个ACK到达发送方的时候，发送方会误以为DATA1的ACK到了，如此反复，后边是否正确接收数据分组就对不上号了。
因此，也必须给ACK多开辟一个比特位进行编号（0或1），让发送方知道这个ACK到底是丢包没传过来，还是迟到没传过来；并对该结果进行抉择（接收还是忽略）。
值得注意的是：
1.下图中有三个DATA0，前两个DATA0是同一个数据分组，而第三个DATA0则是另一个数据分组。
2.对于数据链路层的点对点信道，往返时间比较固定，不会出现迟到确认迟到的情况。因此，如果只在数据链路层使用停止等待协议，我们可以不给ACK编号。

5.总结

1.接收方检测到数据分组有误码时，将其丢弃并等待发送方的超时重传。但对于误码率高的点对点的链路，为使发送方尽早重传，也可给发送方发送NAK分组。
2.为了让接收方能够判断所收到的数据分组是否是重复的，需要给数据分组编号。由于SW的停等特性，只需1个比特编号(0或1)即可。
3.超时计时器设置的重传时间应仔细选择，一般可将重传时间选为略大于“从发送方到接收方的平均往返时间”。
3.1.在数据链路层点对点的往返时间比较确定，重传时间比较好设定
3.2.而在传输层，由于端到端往返时间非常不确定，设置合适的重传时间有时并不容易

6.SW的信道利用率

下图中，
T_D是发送方发送数据分组耗费的发送时延
RTT是收发双方之间的往返时延
T_A是接收方发送确认分组所耗费的发送时延（远小于T_D，经常忽略不计）

信道利用率计算公式如下：

7.例题

7.1.

7.2.
解题过程如下：


解得x的值为800bit，故答案选D