标签：发送 发送窗口 协议 GBN 确认 3.6 后退 接收

3.6 后退N帧协议 （GBN）

停等协议的弊端

发送方

1.必须增加序号范围。

2.发送方需要缓存多个分组。

接收方：

相比之下 很闲

后退N帧协议中的滑动窗口

• 发送窗口最大为2^n-1
• 接收窗口大小为1

GBN发送方

1.上层的调用

上层要发送数据时，发送方先检查发送窗口是否已满，如果未满，则产生一个帧并将其发送;如果窗口已满，发送方只需将数据返回给上层，暗示上层窗口已满。上层等一会再发送。(实际实现中，发送方可以缓存这些数据，窗口不满时再发送帧)。

⒉.收到了一个ACK

GBN协议中，对n号帧的确认采用累积确认的方式，标明接收方已经收到n号帧和它之前的全部帧。

3.超时事件

协议的名字为后退N帧/回退N帧，来源于出现丢失和时延过长帧时发送方的行为。

就像在停等协议中一样，定时器将再次用于恢复数据帧或确认帧的丢失。

如果出现超时，发送方重传所有已发送但未被确认的帧。

GBN接收方

• 如果正确收到n号帧，并且是按序的，那么接收方为n帧发送一个ACK，并将该帧中的数据部分交付给上层。
• 其余情况都丢弃帧，并为最近按序接收的帧重新发送ACK。接收方无需缓存任何失序帧，只需要维护一个信息：expectedseqnum（下一个按序接收的帧序号）。

GBN运行举例

假设发送窗口尺寸为4

出现超时：发送方重传所有已发送但未被确认的帧。

可以看出，GBN协议还是很任性哈，就像个挑食的小孩子，没有得到想要那个ACK，你来什么其他的都给丢掉~~

滑动窗口长度

若采用n个比特对帧编号，那么发送窗口的尺寸W 应满足：1≤ W≤2^n-1。

• 因为发送窗口尺寸过大，就会使得接收方无法区别新帧和旧帧
• 发送窗口尺寸太小，传输速率慢

GBN协议性能分析

优点

因连续发送数据帧而提高了信道利用率

缺点

在重传时必须把原来已经正确传送的数据帧重传，使传送效率降低。

GBN协议重点总结

• 累积确认（偶尔捎带确认)
• 接收方只按顺序接收帧,不按序则无情丢弃
• 确认序列号最大的、按序到达的帧
• 发送窗口最大为2^n-1。接收窗口大小为1

例

题1

数据链路层采用了后退N帧(GBN )协议，发送方已经发送了编号为0~7的帧。当计时器超时时，若发送方只收到0、2、3号帧的确认，则发送方需要重发的帧数是( )。

解：

已经收到3号帧的确认，则已经收到0123，故重新发送4、5、6、7帧，所以要重发的帧数为4。

题2

主机甲与主机乙之间使用后退N帧协议（GBN )传输数据，甲的发送窗口尺寸为1000，数据帧长为1000字节，信道带宽为100Mb/s，乙每收到一个数据帧立即利用一个短帧（忽略其传输延迟）进行确认，若甲、乙之间的单向传播时延是50ms，则甲可以达到的最大平均数据传输率约为( 80Mb/s)。

解：

甲发送一次完整的数据帧的耗时：

\[\frac{1000\times 1000B}{100Mb/s }= 80us \]

一个数据帧的发送时间：T = 发送时延+ 传播时延 X 2 = 100.08ms

数据传输率：

\[\frac{1000\times 1000B}{100.08ms }≈ 10MB/s≈80MB/s \]

标签：发送,发送窗口,协议,GBN,确认,3.6,后退,接收
来源： https://www.cnblogs.com/tupo/p/16115244.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。