可靠传输具体实现

可靠传输具体实现:

主要实现方式有:

  • 停止-等待协议SW
  • 回退N帧协议GBN
  • 选择重传协议SR

这三种可靠传输实现机制的基本原理并不仅限于数据链路层,可以应用到计算机网络体系结构的各层协议中。

1.停止-等待协议Sw(Stop-and-Wait)

收发双方基于互联网通信

image-20220920203602910

发送方给接收方发送数据分组,接收方收到后进行差错检测,如果确认无误就接收并给发送方发送一个确认收到的分组,简称ACK,发送方要接收到该ACK后才能接着发送下一个分组,同时在接收到ACK之前发送方本次发送的数据缓存也不会删除

image-20220920203717985

如果发送方发送的数据产生了误码,那么接收方丢弃改分组并给发送方发送否认分组,简称为NAK

image-20220920203848615

发送方接收到NAK后就知道先前发送的数据出现误码,发送方会重新发送先前的数据

image-20220920204056192
意外情况
1.发送方发送的数据在传递过程中丢失了

接收方收不到数据分组,就不会发送ACK或NAK。如果不采取其他措施,发送方就会一直处于等待接收方ACK或NAK的状态。

解决办法:超时重传

可以在发送方发送完一个数据分组时,启动一个超时计时器。若到了超时计时器所设置的重传时间而发送方仍收不到接收方的任何ACK或NAK,则重传原来的数据分组,这就叫做超时重传。

一般可将重传时间选为略大于“从发送方到接收方的平均往返时间”

image-20220920204451741
2.接收方发送的ACK丢失了

因为发送方没有收到ACK所以触发超时重传机制,发送方再次发送一样的数据,但是接收方已经成功收到过一次改数据了,再次接收的话会导致接收重复数据

解决方法:发送方加上序号

为避免分组重复这种传输错误,必须给每个分组带上序号。

对于停止-等待协议,由于每发送一个数据分组就停止等待,只要保证每发送一个新的数据分组,其发送序号与上次发送将数据分组的序号不同就可以了,因此用一个比特来编号就够了。

当接收方接收到相同序号的数据就会将其丢弃并给发送方发送一个ACK,发送方接收到该ACK后就会开始发送其他的数据

image-20220920205051466
3.接收方发送的ACK迟到了

如果接收方发送的ACK并没有丢失而是迟到了一会但仍然触发了超时重传,那么发送方就会先发送一遍旧的数据(data0),而发送方刚发送,接收方迟到的ACK就赶到了,那么发送方就会接着发送下一条数据(data1),由于data1和data0几乎是同时发送的,所以这两条数据只要有一条成功到达接收方都会被接收然后接收方发送ACK,那么data1就算没有被收到也会被双方忽略

解决办法:接收方加上序号

如果发送方收到了两条一样序号的ACK那么会忽略新收到的这条,注意新发送的数据虽然是data0,但是和第一次发送的data0并不是同一条数据,而是因为序号比特只有一位所以只能表示0或1,实际上该数据应该是data2

信道利用率
image-20220920222033185

当往返时延RTT远大于数据帧发送时延TD时(例如使用卫星链路),信道利用率非常低。若出现重传,则对于传送有用的数据信息来说,信道利用率还要降低。

2.回退N帧协议GBN

为什么要使用回退N帧协议?

停止-等待协议Sw的缺点:

image-20220920225803336

如果采用流水线发送在相同的时间内能够大幅提高传输效率,这时就要用到回退N帧协议

image-20220920225829762
回退N帧协议实现
  1. 采用3个比特给分组编序号,即序号0~7;
  2. 发送窗口的尺寸WT的取值:1<w,<2^3- 1=7,本例取WT=5
image-20220920230459278
  1. 接收窗口的尺寸WR的取值:WR=1;
image-20220920230530654

发送方不再是一次发送一个分组,而是一次性发送发送窗口数量的分组,如本例中发送窗口大小为5那么第一次连续发送0,1,2,3,4分组;接收方首先会比较接收分组的编号和接收窗口是否相同然后才接收,每接受一个分组,滑动窗口就往后移动一次并且发送对应的ACK返回

image-20220920230807068

发送方每接收一个ACK滑动窗口也往后移动一格直到移动5格,然后将收到确认的分组从缓存中删除

image-20220920230900895
累计确认

接收方不一定要对收到的数据分组逐个发送确认,而是可以在收到几个数据分组后((由具体实现决定)对按序到达的最后一个数据分组发送确认。ACKn表示序号为n及以前的所有数据分组都已正确接收。

例如发送方接收到ACK4后就算没有接收到ACK3以及之前的ACK也会继续执行

意外情况
1.发送方发送的小组中有一个出现了误码

由于数字5对应的分组出现误码导致此分组被丢弃,而后续的6,7,0,1因为与接收窗口对应的分组匹配不上导致也不会被接受

image-20220920231342817

接收方检测到出错后向发送方发送当前接收窗口上一个传输成功的分组的ACK,也就是ACK4

image-20220920231616827

发送方收到重复的确认,就知道之前所发送的数据分组出现了差错,于是可以不等超时计时器超时就立刻重传!

至于收到几个重复确认就立刻重传,由具体实现决定。

假设本例中发送方收到4个ACK后还不会进行立即重传而是等待超时重传,那么发送方还需要重新发送5个分组,这就是所谓的回退N帧

image-20220920231916452

可见,当通信线路质量不好时,回退N帧协议的信道利用率并不比停止=等待协议高。

2.发送窗口超过上限7

若Wr超过取值范围,例如WT=8,会出现什么情况?

因为发送窗口为8,所以发送方会发送0-7的分组

image-20220920232235268

接收方接收后向发送方发送ACK7

image-20220920232318251

假设回去的路径上出现了差错导致ACK7丢失了,那么会触发发送方的超时重传机制,发送方会重新发送0-7的分组

image-20220920232444225

而接收方此时接收窗口正好指向0,因此接收窗口就认为这是下一次数据导致滑动窗口向后执行,所以设置发送窗口一定要小于7

image-20220920232809315
总结
image-20220921154545953

3.选择重传协议SR

为什么要使用选择重传协议?

回退N帧协议的接收窗口尺寸WR只能等于1,因此接收方只能按序接收正确到达的数据分组。

一个数据分组的误码就会导致其后续多个数据分组不能被接收方按序接收而丢弃(尽管它们无乱序和误码)。这必然会造成发送方对这些数据分组的超时重传,显然这是对涌信咨源的极大浪费。

为了进一步提高性能,可设法只重传出现误码的数据分组。因此,接收窗口的尺寸W:不应再等于1(而应大于1),以便接收方先收下失序到达但无误码并且序号落在接收窗口内的那些数据分组,等到所缺分组收齐后再一并送交上层。这就是选择重传协议。

注意:
选择重传协议为了使发送方仅重传出现差错的分组,接收方不能再采用累积确认,而需要对每个正确接收到的数据分组进行逐一确认!

选择重传协议实现
  • 采用3个比特给分组编序号,即序号0~7;
  • 发送窗口的尺寸Wr的取值:1<WT≤2^(3-1)=4,本例取WT=4
  • 接收窗口的尺寸WR的取值:WR=WT=4;

发送窗口发送0,1,2,3分组,其中2号分组未被接收那么也不会影响同期发送的0,1,3分组,由于2号分组没有收到所以接收方的滑动窗口不能继续向后滑动,接收窗口对已经接收的3号分组打上已接收的标签

image-20220921150118013

接收方将0,1,3的ACK返回给发送方

image-20220921150804524

因为收到了0和1分组发送方将滑动窗口向后移动两格,发送方虽然接受了3号分组但是滑动窗口不能向后移动因为它之前的2号分组没有按序到达,但是会将3号分组打上一个确认标记让3号不会超时重发

image-20220921151315110

因为2号分组大概率还没触发超时重传,所以先发送4号,5号分组,接收方接收到后将4,5分组打上确认标签,同时返回4,5的ACK,发送方接收到后把4,5分组打上确认标签,此时等待发送方2号分组触发超时重传

image-20220921151805896

2号分组重新发送后,接收方的滑动窗口可以向后直接移动4格,然后发送2号分组的ACK,发送方滑动窗后也向后移动4格

image-20220921152152188
意外情况
发送窗口的大小大于2^(3-1)=4

假设我们将发送窗口设置为5,那么发送方一次性发送0,1,2,3,4,接收方收到后滑动窗口向后移动5格并发送这5个的ACK,但是在传输过程中0号分组的ACK丢失了

image-20220921153831530

发送窗口将1,2,3,4打上确认标签同时等待0号窗口超时重传

image-20220921154023580

重传0号分组后接收方无法判断该分组是上一次的0号分组还是这一次的就会造成分组重复

image-20220921154122850
总结
image-20220921154320385
  • 0
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值