标签：发送 窗口 重传 协议 确认 计算机网络 第十期 接收 考研
流量控制与可靠传输机制
1、数据链路层的流量控制
概念：较高的发送速度和较低接受能力的不匹配，会造成传输出错，因此流量控制也是数据链路层的一项重要工作。
（不止链路层具有此功能，传输层也有此功能，区别在于：
①数据链路层是“点到点“的而传输层是”端到端”的
②数据据链路层流量控制手段是“接受方收不下就不回复确认”而传输层流量控制手段是“接收端给发送端一个窗口公告（告知缓冲区还有多大，后面细讲）“）
大致过程：如果接收方还有余力就回复一个确认帧，类似于猫猫还没吃饱丢回来一个空碗还想吃~
2、流量控制的方法
先放一张滑动窗口相关的图，后面讲传输层的时候会详细讲
在数据链路层中无论哪种协议，窗口大小是不变的。
个人目前对滑动窗口的理解是：给发送方和接收方各设定一个定长的区间，两方此时仅可以不停发送区间中的数据，这相当于用区间控制住了流量，这两个窗口也会因为一些条件向后移动，发送方向后移动一位的条件是收到针对窗口顶的确认帧，而接收方向后移动一位的条件是发送出针对窗口顶的确认帧。
①停止-等待协议
每发送完一个帧就停止发送，等待对方的确认，在收到确认后再发送下一个帧。发送效率非常低。（其实是一种特殊的滑动窗口协议，发送方和接收方的窗口大小都是1）
②滑动窗口协议
1、后退N帧协议GBN（GO-BACK-N）
2、选择重传协议SR（selective repeat）
3、可靠传输、滑动窗口、流量控制
可靠传输：发送端发啥，接收端收啥
流量控制：控制发送速率，使接收方有足够的缓冲空间来接收每一个帧。
滑动窗口解决：
流量控制（收不下就不给确认，想发也发不了）
可靠传输（发送方自动重传，自动重传请求ARQ（Automatic Repeat-reQuest）如果超出响应时间但还是没有接收到确认帧，就会再次重传，后面细讲）
停止-等待协议
1、停止-等待协议究竟是哪一层
以前的硬件、传输条件不好，数据链路层需要承担一部分流量控制和帧检查的任务，因此之前的数据链路层中包含这种协议，之后随着通信条件的变好，数据链路层的职能逐渐下沉逐渐低级，逐渐只需要负责差错检错成帧等功能了，因此传输层对该种协议有了更广泛的使用。
2、停止-等待协议
应用背景：除了比特位错，底层信道还会出现丢包问题，同时也有流量控制的需求。（丢包：物理线路故障、设备故障、病毒攻击、路由信息错误等原因，会导致数据包的丢失。数据包就是广义上的数据对象，在数据链路层就是帧，在网路层就是数据报或分组，在传输层就是报文段）
研究前提：
1、虽然现在常用全双工的通信方式，但为了讨论问题方便，仅考虑一方发送数据（发送方），一方接收数据（接收方）。
2、因为是在讨论可靠传输的原理，所以并不考虑数据是在哪一个层次上传送的。
3、“停止-等待”就是每发送完一个分组或停止发送，等待对方确认，在收到确认后再发送下一个分组。
3、停等协议——无差错情况
理想状态下，因为每次只发送（确认）一个帧，每发送一个数据帧就停止等待，所以只需要区分开相邻的两个帧即可，因此确认帧ACK（Acknowledge character）用1bit来编号（1、0）就可以。
4、停等协议——有差错情况
1、数据帧丢失或检测到帧内数据出错
发送方每发送一次都会启动一个超时计时器，如果超出规定时间还没有接收到该帧的确认帧，就再发送一次当前帧，一直重复。该规定的时间应当比帧传输的平均往返传播时延RTT（Round-Trip Time）更长一些。（因为除了信号在介质中传播所消耗的时延，信号发送需要一定时间，接收方的处理也需要一定时间）
因此为了保证以上机制的实现需要做到：
1、发完一个帧后，必须保留它的副本。
2、数据帧和确认帧必须编号（为了解决帧丢失和帧重复的问题，其实挺简单的思路，你肯定得通过某种东西确认一下发回来的确认帧是你想要的那个确认帧）
2、确认帧ACK丢失
ACK发送的时候丢失，解决机制其实与数据帧丢失的情况一模一样，都需要一个计时器来触发超时重传。
3、ACK迟到（什么都没丢但是确认帧来慢了）
也是同样的超时重传机制，依赖于对帧进行了编号保证收到重复的信息后可以潇洒扔掉（考虑一下最极端的情况，上一个ACK0在发送端发送出了下一个0号帧后才到，会不会造成通信错误？应该不会，所谓信号迟到的时间应该不会超过两个RTT，这也太慢了歪！）
5、停等协议性能分析
优点：逻辑简单，容易分析。
缺点：信道利用率太低。
信道利用率：发送方在一个发送周期内，有效地发送数据所需要的时间占整个发送周期的比率。
信道吞吐率：信道利用率×发送方的发送速率
（这道题解答有一点点问题，它没有考虑确认帧的传输（发送）时延，如果停等协议中确认帧为定长1bit的话，那其实应该考虑这1/4000秒）
所以根据上面的实例计算可以知道，传输时延越短的情况下，信道利用率越低。
后退N帧协议GBN（Go-Back-N）
1、停等协议的弊端
信道利用率实在太低。应该考虑一连多发几个帧，转变如下图所示（流水线技术）。
如果要做到以上的转变需要做到：
1、必须增加序号范围
2、发送方需要缓存多个分组
2、后退N帧协议中的滑动窗口
发送窗口：发送方维持一组连续的允许发送的帧的序号。
接收窗口：接收方维持一组连续的允许接收的帧的序号。
首先讲明一下两个窗口向后移动的条件不太一样，发送窗口向后移动的条件是收到了正确（窗口首端）的确认帧；接收窗口向后移动的条件是发送出了当前（如果长度大于一那就是窗口首端）的的确认帧
3、GBN发送方必须响应的三件事
1、上层的调用
上层要发送数据时，发送方先检查发送窗口是否已满，如果未满，则产生一个帧并将其发送；如果窗口已满，发送方只需将数据返回给上层，暗示上层窗口已满。上层等一会再发送。（实际实现中，发送方可以缓存这些数据，窗口不满时再发送帧）。
2、收到了一个ACK
GBN协议中，对n号帧的确认采用累积确认的方式，标明接收方已经收到n号帧和它之前的全部帧。（采用累积确认的机制可以解决接收方的某一个确认帧丢失的问题（配合后面的超时后退机制共同作用），只要收到了来自后面的确认帧，前面的就默认传输成功了；另外这个机制也可以降低接收方发送确认帧的频率，它不需要对每一个发来的数据都各自返回一个确认帧，而是可以有间隔的发送。有点队列Queue的意思，数据是列好队的不能插队）
3、超时事件
协议的名字为后退N帧/回退N帧，来源于出现丢失和时延过长帧时发送方的行为。就像在等停协议中一样，定时器将再次用于恢复数据帧或确认帧的丢失。如果出现超时，发送方重传所有已发送但未被确认的帧。（所以这个“回退”并不是指的哪个窗口回退，窗口是只进不退的，重复的是窗口内未被确认的帧）
以下灵魂图中描绘的是接收方窗口滑到了“1”号帧的位置等待接收“1”号帧，但发送方的“1”号帧丢失后面接连发送了“2”、“3”、“4”号帧，此时因为既没有“1”号帧的数据也没有关于“1”号帧的确认帧，因此双方进入了一种死锁状态，此时发送方会根据计时器的超时设定，重新从窗口首依次发送“1”、“2”、“3”、“4”号帧。
4、GBN接收方要做的事
1、如果正确收到n号帧，并且按序，那么接收方为n帧发送一个ACK，并将该帧中的数据部分交付给上层（根据前面讲到的解帧操作）
2、其余情况都丢弃帧，并为最近按序接收的帧重新发送ACK（保证发送方准确定位窗口的位置，同时规避掉确认帧丢失的情况）。接收方无需缓存任何失序帧，只需要维护一个信息：expected seq num（下一个按序接收的帧序号，这也是GBN接收方这个单窗口的位置，嗯清晰明了！）（跑题一点，发送方安排了一定的缓存空间，接收方仅维护一个数值index没有安排缓存空间，因此两方的传输逻辑比等停协议在时间上更优化了，如果到后面SR协议两方都安排了缓存空间，在时间上盲猜会更加优化，类似与算法导论中的“空间换时间”？逻辑变复杂但时间优化了，IT的精髓万物归一好吧【感动】）
5、运行中的GBN
前面已经把原理描述地很清楚了，具体过程看一下这个图就能明白：
6、滑动窗口长度
窗口长度并不能无限，若采用n个比特堆帧编号，那么发送窗口的尺寸WT应满足：1<=WT<=2n-1.因为发送窗口尺寸过大，就会使得接收方无法区别新帧和旧帧。
意思就是说如果用两位bit对帧进行编号，那么发送窗口的尺寸应该满足1<=WT<=3，看数字的含义是总比比特位数所表示的最大数据小1，少的这个1是用来区分新帧和旧帧的，与后面的SR放在一起理解的话，发送端窗口的长度需要保证比所有帧号长度小一个接收端窗口的长度，在GBN里也就是1，保证最大帧号与最小帧号收尾不能相见。
7、GBN协议重点总结
1、累计确认（偶尔捎带确认）
2、接收方只按顺序接收帧，不按序就无情丢弃
3、确认序列号最大的、按序到达的帧
习题：
8、GBN协议性能分析
优点：因连续发送数据帧而提高了信道利用率
缺点：在重传时必须把原来已经正确传送的数据帧重传，使传送效率降低
选择重传协议SR（selective repeat）
1、GBN协议的弊端
累计确认机制会导致批量重传的情况，SR协议可以解决此类问题，只重传出错的帧
具体解决方法为：设置单个确认，同时加大接收窗口，设置接收缓存，缓存乱序到达的帧。（SR相比于GBN的优化并不仅仅是在接收方加了一个缓存窗口，而是去掉了累计确认机制，为窗口中的每一个帧都加了计时器，可以做到有针对性的对未确认帧进行重传，提高了传输效率）
2、选择重传协议中的滑动窗口
3、SR发送方必须响应的三件事
1、上层的调用
从上层接收到数据过后，SR发送方检查下一个可用于该帧的序号，如果序号位于发送窗口内，则发送数据帧；否则就像GBN一样，要么将数据缓存，要么返回给上层之后再传输。
2、收到了一个ACK
如果收到ACK，加入该帧序号在窗口内，则SR发送方将那个被确认的帧标记为已接受。如果该帧序号是窗口的下界（最左边第一个窗口对应的序号），则窗口向前移动到具有最小序号的未确认帧处。如果窗口移动了并且有序号在窗口内的未发送帧，则发送这些帧。
3、超时事件
每个帧都有自己的定时器，一个超时事件发生后只重传一个帧。
4、SR接收方要做的事
可以概括为“来者不拒”（窗口内的帧）
SR接收方将确认一个正确接收的帧而不管其是否按序。失序的帧将被缓存，并返回给发送方一个该帧的确认帧【收谁确认谁】，直到所有帧（即序号更小帧）皆被接受为止，这时才可以将一批帧按序交付给上层，然后向前移动滑动窗口。（另外如果收到了某个串口序号外（小于窗口下界）的帧，就返回一个ACK）
5、运行中的SR
具体过程看图就能明白
6、滑动窗口的长度
为了区分新帧和旧帧，窗口的长度不能过大，下图就反映出窗口过大带来的无法区分新帧旧帧的问题。
发送窗口最好等于接收窗口。（个人认为某些特殊情况也不一定非要一样，跟两方的处理速度也有关系）如果发送端过大会数据溢出，过小就失去了SR的意义，利用率上不来。
所以窗口大小设置的公式为：
数学意义理解起来也很简单，2n-1其实就是2n/2，其意义就是窗口不能大于所有帧号长度的一半（因为默认发送长度等于接收长度），保证最大帧号和最小帧号首位不能相见。
7、SR协议重点总结
1、对数据帧逐一确认，收一个确认一个
2、只重传出错帧
3、接收方有缓存
习题1：
很简单不多讲～
标签：发送,窗口,重传,协议,确认,计算机网络,第十期,接收,考研 来源： https://www.cnblogs.com/monkiki/p/15759314.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。