【计算机网络】可靠传输

举报
黑城笑 发表于 2022/06/10 19:31:17 2022/06/10
【摘要】 本文是湖科大教书匠的计算机网络笔记,主要介绍了可靠传输的内容 感谢大家的观看,求点赞求收藏求评论 欢迎大家关注我的账号:黑城笑 更多技术分享等待大家

1.基本概念

使用差错检测技术(例如循环冗余校验CRC),接收方的数据链路层用过帧尾中的帧检验序列FCS字段的值就可检测出帧在传输过程中是否产生了误码(比特错误)。
当产生误码时接收方的数据链路层是否丢弃帧取决于数据链路层向上层提供的服务类型:

  • 不可靠传输服务仅仅丢弃有误码的帧,其他什么也不做;
  • 可靠传输服务:想办法实现发送端发送什么,接收端就收到什么

一般情况下,有线链路的误码率比较低,为了减小开销,并不要求数据链路层向上提供可靠传输服务。即使出现了误码,可靠传输的问题由其上层处理。
无线链路易受干扰,误码率比较高,因此要求数据链路层必须向上层提供可靠传输服务。
比特差错只是传输差错中的一种。
从整个计算机网络体系结构来看,传输差错还包括分组丢失分组失序以及分组重复
分组丢失、分组失序以及分组重复这些传输差错,一般不会出现在数据链路层,而会出现在其上层。
可靠传输服务并不仅局限于数据链路层,其他各层均可选择实现可靠传输。(如传输层的UDP和TCP)

因为传输差错并不仅仅局限于数据链路层的比特差错,所以上述定义中传输差错中的称呼为分组。

2.三种可靠传输的实现机制

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

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

2.1停止-等待协议SW

数据分组DATA,确认分组ACK,否认分组NAK

2.1.1 错误状况

2.1.1.1确认与否认

发送方每发送完一个数据后,并不能将该数据分组从缓存中删除,只有收到针对该数据分组的确认分组后,才能将其从缓存中删除(因为此分组可能会出现误码
发送方每发送完一个后,就停止发送下一个数据分组,等待来自接收方的确认分组或否认分组,若收到确认分组,则可继续发送下一个数据分组;若收到否认分组,则重发之前发送的那个数据分组。
在这里插入图片描述

2.1.1.2 超时重传

在这里插入图片描述

2.1.1.3 确认丢失

在这里插入图片描述因为是回答丢失,数据其实已经传过一遍了,通过序号接收方确定是否为重复分组,如果为重复分组则进行丢弃,并返回确认分组(避免超时重传),发送方收到确认分组后就可以发送下一个分组了。

2.1.1.4 确认迟到

接收方的回答可能会出现迟到状态,当这个时候发送发误认为超时进行超时重传,在他重传后,接收方的回答回应了它的重传操作,同时接收方收到了发送方的重传将其丢弃并返回了确认分组,如下图所示:
在这里插入图片描述
为防止遇到这种情况,我们将确认分组也进行编号操作,如下图:
在这里插入图片描述注意,下方的DATA0和上方的DATA0是同一分组,由于下一个分组必须等待上一个分组ack后才能继续传递,所以用序号01确定即可,不需要额外的序号。


小结:
在这里插入图片描述

2.1.2 停止-等待协议的信道利用率

图中忽略了接收方对数据分组的处理时延以及发送发对确认分组的处理时延,最下方黑色字体的式子为使用停-等待协议的发送方从发送一个数据分组开始,到可以发送下一个数据分组为止需要耗费的总时间
在这里插入图片描述
一般Ta<<Td,可以将Ta忽略;
当RTT>>TD,信道利用率会非常低

在这里插入图片描述

例题

在这里插入图片描述

2.1.3 总结

像停止-等待协议SW这种自动发送重传的协议我们称它为自动请求重传简称为ARQ
在这里插入图片描述

2.2 回退N帧协议GBN

在这里插入图片描述 回退N帧协议GBN在采用流水线传输发送分组的基础上利用发送窗口限制发送发可连续发送数据分组的个数。(此处是假设采用3比特给分组编序号,并不是值所有的GBN都是只有3bit的分组

在这里插入图片描述

发送窗口的尺寸记为WT,序号发送窗口内的数据可以连续发送,在窗口外的数据不可以发送,当WT=1,则为停止等待协议,WT的值超过取值范围的上限,则会出现严重错误;
在这里插入图片描述

接收窗口的尺寸记为WR,回退N帧协议的Wr只能取1,同停止-等待协议相同,序号落在接收窗口内的数据可以接收,数据落在接收窗口外的数据不能够接收;
在这里插入图片描述

2.2.1 无差错情况

发送方将序号落在发送窗口内的0~4号数据分组依次连续发送出去,成功到达接收方,每接收一个,接收窗口就向前滑动一个位置,并给发送发针对所接收分组的确认分组。
当发送方收到确认分组,则可将收到确认的数据分组从缓存中删除;
接收方则将接收到的分组交付给上层处理。
在这里插入图片描述

2.2.2 累计确认

在这里插入图片描述下图当接收方接收到序号为0和1的数据分组后给发送方发送一个累计确认ACK1,接收完成2~4后给发送发发送一个累计确认ACK4
在这里插入图片描述
若在传输过程中ACK1丢失,则接收方知道,序号为4及之前的数据分组被接收方正确接收了,于是将发送窗口向前滑动5个位置
在这里插入图片描述
所以采用累计确认的优点为:

  • 即使确认分组丢失,发送法也可能不必重传
  • 减少接收方开销
  • 减少对网络资源的占用

如果ACK4丢失,则同停止-等待协议中一样有超时重传操作。

2.2.3 有差错情况

五号出现误码,则接收方丢弃该分组
在这里插入图片描述
后续到达的四个分组的序号和接收方的接收窗口序号不匹配,接收方同样不能接受他们,将它们丢弃,并对之前按需接收的最后一个数据分组进行确认,也就是发送ACK4
在这里插入图片描述
每丢弃一个分组就发送一个ACK4
在这里插入图片描述发送发这次发送了5~1号帧,由于5号帧出现误码,后面的帧都没有收到,所以这次直接重传这5帧;
如果7号帧出现误码,则这次要重传7~1号帧
在这里插入图片描述

2.2.4 发送窗口尺寸问题

若Wt超过取值范围,例如Wt=8,会出现分组重复传输差错。

例题

在这里插入图片描述

2.2.5 总结

在这里插入图片描述

2.3 选择重传协议SR

在这里插入图片描述不同于GBN的是,SR中发送窗口的尺寸是在二的三减一次方以内(而不是二的三次方减一),且SR的接收窗口的取值同发送窗口一致。
在这里插入图片描述发送方将发送窗口内数据分组依次连续发出,它们经过互联网到达接收方,但其中二号数据丢失,只要序号落入接收窗口内且无误码的数据分组,接收方都会接收(接收方机能接收按序到达无误码的,又能接收失序到达无误码的在这里插入图片描述接收方接收0、1号分组并发送确认分组,接收窗口向前滑动;
接收方接收3号分组并发送3号确认分组,但接收窗口不能向前滑动,因为3号数据分组是未按序到达的数据分组;
发送发每收到一个确认分组,就向前滑动一个位置,发送发接收0、1号确认分组,向前滑动,由于不存在2号确认分组,所以发送窗口停止在2,然后将0、1号数据分组的缓存删除,接收方也将0、1号分组交给上层处理;
在这里插入图片描述
发送方接收3号确认分组,但发送窗口不能向前滑动,发送方还未收到2号确认分组,不过需要记录3号数据分组已收到确认,这样3号分组不会超时重发
在这里插入图片描述
4号5号分组达到接收方,接收方发送4号5号确认分组,但接收窗口不能向前滑动,因为它们是未能按序到达的分组,接收方还未收到2号数据分组
在这里插入图片描述
如果在4号和5号确认分组传输过程中,发送发进行2号超时重传
在这里插入图片描述
4号5号确认分组到达,因为2号确认分组没有到达,发送窗口依旧不能向前滑动,不过可以记录4、5号数据分组已收到确认,发送窗口外的数据无法发送,发送窗口等待2号确认分组
在这里插入图片描述
当2号到达接收方,滑动窗口向前滑动4个位置,接收方发送2号确认分组
在这里插入图片描述
2号确认分组到达发送方,发送窗口前移4个位置
在这里插入图片描述

2.3.1 发送窗口尺寸问题

在这里插入图片描述在这里插入图片描述
可以看见,下图中接收窗口已经向前移动5,并包含新的序号为0的接收窗口
在这里插入图片描述
同样的,也会出现分组重复传输差错

例题

在这里插入图片描述

2.3.2 总结

在这里插入图片描述


链接: 湖科大教书匠:计算机网络微课堂
本文是湖科大教书匠的计算机网络笔记,感谢大家的观看,求点赞求收藏求评论
欢迎大家关注我的账号:黑城笑
更多技术分享等待大家

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。