可靠传输的实现机制——回退N帧协议GBN(Go Back N)
作者:互联网
可靠传输的实现机制——回退N帧协议GBN(Go Back N)
- 因为使用停等协议的发送方式,在发送过程中,信道利用率很低,如果出现超时重传,则信道利用率更低
- 如果可以同时发送很多个数据分组,采用一种流水线式的传输方式,可以调高信道的利用率
过程分析
- 采用三个比特给分组编序号,既序号为0~7
- 发送窗口的大小为07,接收窗口的大小也为07
- 序号落在发送窗口内的数据分组可以被连续发送,不必等到收到接收方的确认分组后再发送
- 发送窗口的尺寸几位Wt,1<Wt<=2的位数次方-1。这里的位数是给分组编号的位数,在本例中为3,本例中取Wt=5
- wt=1则为停等协议
- wt取值超过上限,会发生严重错误
- 接收窗口的尺寸几位Wr,对于回退N帧协议,Wr为1
无差错情况
- 发送方发送0~4号数据分组,依次发送出去,经过传输到达接收方,没有出现任何错误
- 每接收一个,接收方就将滑动窗口移动一个位置,并向发送方发送针对所接收分组的确认分组
- 发送方成功接收到了接收方的确认分组,发送方每接收一个,就将发送窗口向前移动一个位置。
- 发送方可以将受到确认的数据分组从缓存中删除了
- 接收方可以将已接收的数据分组交付上层处理
累积确认:
-
接收方不需要给收到的数据分组逐个发送确认,而是可以在收到几个数据分组后对按序到达的最后一个数据分组发送确认,ACKn表示序号为n及之前的所有数据分组都已经成功接收
-
缺点:
- 即使确认分组丢失,发送方也可能不必重传!
- 不能向发送方及时反映出接收方已经正确是接受的数据分组信息
-
优点:减小接收方的开销,减少对网络资源的占用!
有差错情况
- 发送方发送的5号报文出现误码,接收方将其丢弃,并向发送方发送ACK4
- 之后的报文因为与接收窗口不对应,故也无法接收,依次向发送方发送四个ACK4.
- 发送方收到重复的确认,就知道之前所发送的数据分组出现了差错,于是可以不等超时计时器就立刻重传!
- 至于收到几个重复确认就立刻重传,由具体的实现决定
在本例中,虽然6 7 0 1的分组已经成功到达了接收方,但是因为5号分组出现误码,他们也受到牵连,而不被接受,发送方还要重传这些数据分组,这既是所谓的Go-Back-N(回退N帧)
- 可见,当通信线路质量不好时,回退N帧协议的利用率也并不比停-等协议要好
如果Wt超过上限会如何?
- 如果Wt=8,发送方依次将0~7,八个分组发送给接收方,接收方收到分组后发送了ACk7作为累计确认。
- 但是这个ACK7在传输过程中丢失了,这时启动了发送方的超时重传。
- 此时发送方继续发送0~7号分组,此时接收方的接收窗口刚好停在0处,此时也可以接受该分组,但是这个分组已经在前面接受过了,就导致了分组重复。
故:当发送窗口过大时,会导致接收方无法分辨新旧分组,导致分组重复的错误,所以发送窗口的尺寸不可以超过其上限
小结:
发送方:
- 发送窗口的Wt的取值范围是1<Wt<=2的n次方-1,其中n是构成分组序号的比特数量
- wt=1时,是停等协议
- wt>2的n次方-1时:接收方无法分辨新旧分组
- 发送方可在未接收放确认分组的情况下,将序号落在发送窗口内的多个数据分组全部发送出去
- 发送方只有在收到对已发送数据分组的确认时,发送窗口才能向前相应滑动
- 发送方收到多个确认时,可在重传计时器超时前尽早开始重传,这个由具体的实现决定
- 发送方发送窗口内某个已发送的数据分组产生超时重发时,其后续的发送窗口内且已发送的数据分组也必须全部重传,也就是回退N帧名字的由来
接收方
- 接收方的接收窗口Wr的取值只能为1,因此接收方只能安序接收数据分组
- 接收方只能接受序号落在接收窗口内且无误码的数据分组,并且将接收窗口向前滑动一个位置,与此同时给发送方发回相应的确认分组。为了减小开销,接收方不一定每收到一个按序到达且无误码的数据分组就给发送方发回一个确认分组
- 而是可以在连续收到好几个按序到达且无误码的数据分组后(由具体实现决定),才针对最后一个数据分组发送确认分组,这称为累积确认
- 或者可以在自己有数据分组要发送时才对之前按序接收且无误码的数据分组进行稍带确认
- 接收方收到 按序到达的数据分组,处丢弃外,还要对最后按序接收的数据分组进行确认
小例题
标签:发送窗口,重传,GBN,确认,Back,发送,分组,Go,接收 来源: https://blog.csdn.net/qq_45778676/article/details/116099353