标签：协议 发送窗口 重传 可靠 发送 传输 3.4 分组 接收
3.4.1 基本概念
假如接收端检测到了有一个帧出现错误，那就告诉发送方：哥们，有一个帧出错了，麻烦重发一下。
试想一下这样一种情况，假如接收方告诉发送方的话是有误的，欺骗的，那会引起更大的灾难。
后面我们会介绍三种实现可靠传输的方法。
一般情况下，有线链路的误码率比较低，为了减少开销，并不要求数据链路层向上层提供可靠传输服务，即使出现误码，可靠传输的问题由上层处理。
无线链路易受干扰，误码率较高，因此要求数据链路层必须向上层提供可靠传输服务。
3.4.1 停止-等待协议
发送方每发送完一个分组后，就停止发送下一个分组。并且缓存还不能清掉，等到接收到接收方的确认ACK那就清掉缓存，并且发送下一个分组。如果接收方发送的是否认NAK没有收到，那就重发。
但是实际情况更复杂，我们来看下面这种情况。一开始传输的时候就出现错误，并且接收方收不到，也就不会发ACK或者NAK，那这样就一直等着。破冰的办法就是超时计时器。比往返时间略大一点，超时了还没收到回复，那就重传。
既然发送方发送的数据分组可能丢失，那我接收方发送的接收分组也可能会丢失。这必然会造成超时重传。假设这个重传的也达到了接收方，那么问题来了，接收方如何判断该数据分组是不是重复的呢？
为了避免出现分组重复，必须给分组带上序号。
通过确认分组丢失的情况，引出了给确认分组编号的操作。
请大家思考一下：既然数据分组需要编号，那么确认分组是否也需要编号呢？
如果我们的确认迟到了，发送方到点重传了，收到重复确认，那他怎么知道是对1还是0的确认呢？所以得编号
需要说明的是：对于数据链路层的点对点信道，往返时间比较固定，不会出现确认迟到的情况。因此，如果只在数据链路层实现停止等待协议，不用给确认分组编号。
注意事项：
练习题：
3.4.2 回退N帧协议
我们可以看出，停止等待协议信道利用率很低，并且如果发生超时重传的话，信道利用率更低，所以我们可以用流水线的方式发送数据分组，一次发5个，提高信道的利用率
那么我们的回退N帧协议GBN（Go -Back -N）就是在流水线的基础上设计的。利用发送窗口来限制发送方可发送的数据分组的个数。在发送窗口里面的数据分组可被连续发送，而不必等待。
发送窗口的尺寸记为WT。
如果WT的值取1就是停止等待协议。如果WT的值超过取值范围的上限，则会造成严重的错误。
接收窗口的大小为Wr：对于回退N帧协议，其取值只能为1。
我们先来看最简单的没差错的情况：
发送方按序发送，接收方一个一个接收，每接收一个，接收窗口就向前滑动一个位置。并给发送方发送所接收分组的确认分组。
发送方每接收一个接收方的ACK，发送窗口就向前滑动一个位置。
并且发送方可以将已发送的分组缓存清除，接收方呢就将已接收的分组交付给上层去处理。
接下来我们看看累积确认的概念：使用后退N帧协议的接收方，可以使用累积确认的机制。也就是我接收方不必啰嗦的每个都发个收到。而是收到5个分组之后再说一句收到5个了。ACKn表示N以及之前的分组全部都接收了。
使用累积的一个优势：比如你先发一个ACK1，之后又发了一个ACK4，ACK1在路上丢失了，但是最后我发送方还是接收到ACK4，不会因为ACK1的丢失而发生重传。还有其他优点：减少接收方的开销，减少网络资源的占用等。
使用累积确认的缺点：不能及时的反映接收方已经接收的信息。
我们来看一种出错的情况：发送方发送的数据1丢失了，5670跟着受到牵连，也不被接收方接收。那超时之后引起重传，重传的话我5670这四个倒霉蛋又被重传了一次。可见网络不好的时候，回退N帧协议的信道利用率不见得要比停止等待协议的好。
接下来我们看一看发送窗口尺寸超出上限会怎么样：
现在我Wt是8，我序号编的是0-7，接收方接收到之后，发送ACK7，但是ACK7在路上丢失了，没有正确达到发送方，超时之后，发送方重传0-7，此时接收方一看，丫的，这0-7到底是重传的还是新的啊，我也看不出来。
回退N帧协议名字的由来：一人犯错，牵连全家。
练习题：
因为该协议的发送窗口和接收窗口是不断滑动的，所以又叫滑动窗口协议。
3.4.3 选择重传协议SR
回退N帧协议的接收窗口只能为1，因此接收方只能按序接收正确达到的数据分组。
一颗老鼠屎会坏了一锅汤，前面只要有一个接收有误，那后面的就不能被正确接收，引起超时重传，对通信资源造成浪费。
那么我们可不可以只重传出错的那个分组，不连累其它人呢？
那我的接收窗口就不应该为1，应该大于1，哪些没错的就接受让他们先在接收方休息，只重传出错的那个，等重传的到达后他们再一起送到上一层去。这个就是选择重传协议。
需要注意：你如果想要发送方发送出错的那个分组，那你接收方就不能再采用累积确认的机制了。应该是对每一个正确到达的分组逐一确认。
这个协议需要注意的就是发送窗口和接收窗口大小的设计
如果发送窗口和接受窗口的尺寸超过了范围。那也会引起上面的新旧不分的问题
发送方发了0-4，接收方接收到0-4之后自己的滑动窗口就向前移动了，然后发ACK给发送方，但是ACK0丢失了。一段时间超时了，发送方重发0，但是此时滑动窗口已经不再是当年那个滑动窗口了，此时的0非当年的0。
练习题：
3号帧题目没说啥，那就别考虑他。
标签：协议,发送窗口,重传,可靠,发送,传输,3.4,分组,接收 来源： https://www.cnblogs.com/YXBLOGXYY/p/15399748.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。