• 3.4、可靠传输


    1、基本概念

    image-20221124204257611

    使用 差 错 检 测 技 术 \color{red}差错检测技术 (例如循环冗余校验 CRC ),接收方的数据链路层就可检测出帧在传输过程中是否产生了 误 码 \color{red}误码 (比特错误)。

    数据链路层向上层提供的服务类型

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

    例如:

    • 接收方可以发送给发送发一个通知帧,告诉它:“之前发送的帧产生了误码,请重发”。
    • 发送方收到通知后,重发之前产生了误码的那个帧即可

    若通知帧也出现了误码,又会怎么样呢?

    image-20221124204647113


    一般情况下, 有 线 链 路 \color{red}有线链路 线误码率比较低,为了减小开销,并 不 要 求 数 据 链 路 层 \color{red}不要求数据链路层 向上提供 可 靠 \color{red}可靠 传输服务。即使出现了误码,可靠传输的问题由其上层处理。

    无 线 链 路 \color{red}无线链路 线易受干扰,误码率比较高,因此 要 求 数 据 链 路 层 \color{red}要求数据链路层 必须向上层提供 可 靠 \color{red}可靠 传输服务。

    image-20221124204850127


    比 特 差 错 \color{red}比特差错 只是传输差错中的一种。

    从整个计算机网络体系结构来看,传输差错还包括 分 组 丢 失 \color{red}分组丢失 分 组 失 序 \color{red}分组失序 以及 分 组 重 复 \color{red}分组重复

    分组丢失、分组失序以及分组重复这些传输差错,一般不会出现在数据链路层,而会出现在其上层。

    可 靠 传 输 服 务 并 不 仅 局 限 于 数 据 链 路 层 \color{red}可靠传输服务并不仅局限于数据链路层 ,其他各层均可选择实现可靠传输。

    例如:

    image-20221124210149621

    可靠传输的实现比较复杂,开销也比较大,是否使用可靠传输取决于应用需求。

    1.1、分组丢失

    主机 H6 给主机 H2 发送的分组到达了路由器 R5

    由于此时 R5 的输入队列快满了。

    R5 根据自己的分组丢弃策略将该分组丢弃

    image-20221124205251230

    1.2、分组失序

    主机 H6 给主机 H2 发送了 3 3 3 个分组。

    它们并未按照发送顺序依次到达 H2。(最先发送的分组未必最先到达)

    fenzushixu

    1.3、分组重复

    主机 H6 给主机 H2 发送的分组。由于某些原因在网路中滞留了,没有及时到达 H2

    这可能造成了 H6H2 的超时重发,重发的分组到达了 H2。一段时间后,滞留在网络中的那个分组又到达了 H2

    这又会造成分组重复的传输差错

    image-20221124210000914


    注意:

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

    2、停止-等待协议 SW

    每发送一个数据分组就进行停止等待

    2.1、误码情况

    若收发双方基于互联网进行通信,而不是局限在一条点对点的数据链路。

    • 发送方给接收方发送数据分组,接收方收到后对其进行差错检测。

    • 若没有误码,则接受该分组,并给发送方发送确认分组,简称为 ACK

    • 发送方收到对所发送方数据分组的确认分组后,才能发送下一个数据分组。

    • 假设这个数据分组在传输过程中出现了误码.

    • 接收方收到后对其进行差错检测。发现了误码,则丢弃该数据分组

    • 并给发送发发送否认分组(NAK

    • 发送方收到所发送数据分组的否认分组后,就知道了之前自己所发送的数据分组出现了差错而被接收方拒绝

    • 于是立刻重传该数据分组

    • 因此,发送方每发送一个数据分组后,并不能立刻将该数据分组从缓存中删除,只有在收到针对该数据分组的确认分组后,才能将其从缓存中删除

    image-20221124222521017


    2.2、数据丢失情况

    发送方发送的数据分组丢失

    image-20221124222720924


    2.3、确认/否认丢失情况

    接收方发送的确认或否认分组就也有可能丢失

    image-20221124223012248

    接收方丢弃重复的数据分组,并给发送方发送针对该数据分组的确认分组。

    以免发送方对该数据分组的再次超时重传

    image-20221124223153857


    2.4、确认分组迟到情况

    由于某些原因,该确认分组迟到了,这必然会导致发送方对 0 0 0 号数据分组的超时重传

    在重传的 0 0 0 号分组的传输过程中,发送方收到了迟到的确认分组,于是发送 1 1 1 号分组

    image-20221124223642413

    发送方如何知道这是一个对 0 0 0号分组的重复确认

    若不采取其他措施,发送会误认为这是对 1 1 1 号数据分组的确认。

    若对确认分组也进行编号,就可以使发送方避免这种误判

    image-20221124223933496

    因此,若只在数据链路层实现停止-等待协议,可以不用给确认分组编号

    2.5、注意事项

    • 接收端检测到数据分组有误码时,将其丢弃并等待发送方的超时重传。

      • 但对于误码率较高的点对点链路,为使发送方 尽 早 重 传 \color{red}尽早重传 也 可 给 发 送 方 发 送 N A K 分 组 \color{red}也可给发送方发送 NAK 分组 NAK
    • 为了让接收方能够判断所收到的数据分组是否是重复的,需要给 数 据 分 组 编 号 \color{red}数据分组编号

      • 由于停止-等待协议的停等特性, 只 需 1 个 比 特 编 号 \color{red}只需 1 个比特编号 1就够了,即编号 0 0 0 1 1 1
    • 为了让发送方能够判断所收到的 ACK 分组是否是重复的,需要给 A C K 分 组 编 号 \color{red}ACK 分组编号 ACK,所用比特数量 与 数 据 分 组 编 号 所 用 比 特 数 量 一 样 \color{red}与数据分组编号所用比特数量一样

      • 数据链路一般不会出现 ACK 分组迟到的情况,因此在 数 据 链 路 层 实 现 停 止 − 等 待 协 议 可 以 不 用 给 A C K 分 组 编 号 \color{red}数据链路层实现停止-等待协议可以不用给ACK分组编号 ACK
    • 超时计时器设置的 重 传 时 间 \color{red}重传时间 应仔细选择。

      • 一般可将重传时间选为 略 大 于 “ 从 发 送 方 到 接 收 方 的 平 均 往 返 时 间 ” 。 \color{red}略大于“从发送方到接收方的平均往返时间”。

      • 数据链路层点对点的往返时间比较确定,重传时间比较好设定。

      • 然而在运输层,由于端到端往返时间非常不确定,设置合适的重传时间有时并不容易。

    2.6、信道利用率

    image-20221124233946227

    T D T_D TD :发送方发送数据分组所耗费的发送时延 TD(仅仅在 T D T_D TD 内才用来传送有用的数据,也就是数据分组)

    R T T RTT RTT:收发双方之间的往返时间 R T T RTT RTT

    T A T_A TA:接受方发送确认分组所耗费的发送时延 T A T_A TA

    此处忽略了就收方对数据分组的处理时延,以及发送方对确认分组的处理时延


    image-20221124234140773

    当 往 返 时 延 R T T 远 大 于 数 据 帧 发 送 时 延 T D 时 ( 例 如 使 用 卫 星 链 路 ) , 信 道 利 用 率 非 常 低 。 \color{red}当往返时延RTT远大于数据帧发送时延T_D时(例如使用卫星链路),信道利用率非常低。 RTTTD使)

    若出现重传,则对于传送有用的数据信息来说,信道利用率还要降低。

    为了克服停止-等待协议信道利用率很低的缺点,就产生了另外两种协议

    • 即后退N帧协议 GBN 和 选择重传协议 SR

    2.7、习题

    image-20221124234338730

    解析:

    • image-20221124235720717

    3、回退 N 帧协议 GBN

    image-20221125165404085

    此协议在流水线传输的基础上,利用发送窗口限制发送方可连续发送数据分组的个数


    收发双发各自的分组序号,当序号增加到 7 7 7 时,下一个序号又从 0 0 0 开始。

    发送方维持一个发送窗口,序号落在发送窗口内的数据分组可被连续发送,而不必等收到接受方的相应确认分组后再发送

    image-20221125170534673

    1 < W T ≤ 2 3 − 1 1 < W_T \le 2^3 - 1 1<WT231 :其中的 3 3 3 是构成分组序号的比特数量。

    • W T = 1 W_T = 1 WT=1,则是停止-等待协议
    • W T W_T WT 超过取值范围的上限,则会造成严重的错误

    对于回退 N N N 帧协议, W R W_R WR 只能为 1 1 1

    3.1、无差错情况

    发送方将序号落在发送窗口内的 0 − 4 0 - 4 04 号数据分组,依次连续发送出去

    他们经过互联网的传输正确到达了接收方。

    接收方按序接受他们,每接收一个,接收窗口就向前滑动一个位置,并给发送方发送针对所接受分组的确认分组

    image-20221125171222698

    发送方每接收一个,发送窗口就向前滑动一个位置

    • 这样就有新的序号落入了发送窗口。发送方可以将确认的数据分组从缓存中删除了。

    而接收方可以择机将已接受的数据分组交付上层处理

    3.2、累计确认

    image-20221125171747660

    发送方将序号落在发送窗口内的 0 − 4 0 - 4 04 号数据分组,依次连续发送出去。

    他们经过互联网的传输正确到达了接收方。

    接收方按序接受他们:

    • 当接收完 0 0 0 号和 1 1 1 号数据分组后,给发送方发送了一个累计确认 ACK1
    • 当接收完 2 − 4 2 - 4 24 号数据分组后,给发送方发送了一个累计确认 ACK4

    假设 ACK1 再传输过程中丢失了,ACK4 正确到达了发送方。

    发送方接受 ACK4 后就知道了序号为 4 4 4 及之前的数据分组已被接收方正确接收了。

    • 于是将发送窗口向前滑动 5 5 5 个位置
    • 这样就有新的序号落入了发送窗口。发送方可以将确认的数据分组从缓存中删除了。

    而接收方可以择机将已接受的数据分组交付上层处理

    image-20221125172418788

    例如:

    • 本例中 ACK1 丢失了,但并没有造成 1 1 1 号数据分组的超时重传。

    使用累计确认还有其他好处

    • 例如:可以减少接收方的开销,减少对网络资源的占用

    缺点

    • 不能向发送方及时反应出接收方已经正确接收的数据分组信息

    3.3、有差错情况

    发送方将序号落在发送窗口内的这 5 5 5 个数据分组依次连续发送出去

    他们经过互联网的传输到达了接收方。

    假设他们再传输过程中受到了干扰,其中 5 5 5 号数据分组出现了误码

    • 接收方通过数据分组中的检错码发现了错误,于是丢弃该数据分组

    • 而后序到达的这 4 4 4 个数据分组的序号与接受窗口的序号不匹配

      image-20221125173944538

    • 接收方同样也不能接受他们,将他们丢弃

    • 接收方并对之前按序接受的最后一个数据分组进行确认,(也就是发送 ACK4

    • 每丢弃一个数据分组,就发送一个 ACK4

    • 4 4 4ACK4 经过互联网的传输到达了发送方

    image-20221125173445004


    假设收到这 4 4 4 个重复的确认并不会触发发送方立刻重传。

    一段时间后,超时计时器出现超时,发送方将发送窗口内已发送过的这些数据分组全部重传。

    image-20221125174557829


    image-20221125184751077

    发送方将序号落在发送窗口内的这 0 − 7 0 -7 07 8 8 8 个数据分组依次连续发送出去

    他们经过互联网的传输到达了接收方。

    接收方按序正确接受他们后,给发送方发回累积确认 ACK7

    假设 ACK7 在传输过程中丢失了,这将导致发送方的超时重传。

    • 重传的 0 − 7 0 -7 07 号数据分组到达接收方。

    image-20221125185209897

    • 进而会产生分组重复这种传输差错。

    因此,发送窗口的尺寸不能超过其上限

    3.4、小结

    image-20221125185506189

    image-20221125190343547

    3.5、习题

    image-20221125185630595

    解析:

    • image-20221125190227423

    4、选择重传协议 SR

    image-20221125190608544

    4.1、工作原理

    收发双发各自的分组序号,当序号增加到 7 7 7 时,下一个序号又从 0 0 0 开始。

    发送方维持一个发送窗口,序号落在发送窗口内的数据分组可被连续发送,而不必等收到接受方的相应确认分组后再发送

    说明:

    • 若每个序号 等于 一个数据分组,那么发送方将在发送窗口的序号直接发送出去,不需要找的过程
    • 若这是分组序号表,那么发送方找到对应的数据分组发送出去

    image-20221125191703128

    1 < W T ≤ 2 3 − 1 1 < W_T \le 2^3 - 1 1<WT231 :其中的 3 3 3 是构成分组序号的比特数量。

    • W T = 1 W_T = 1 WT=1,则是停止-等待协议
    • W T W_T WT 超过取值范围的上限,则会造成严重的错误

    发送方将序号落在发送窗口内的这 4 4 4 个数据分组依次连续发送出去

    他们经过互联网的传输到达了接收方。

    但是其中的 2 2 2 号数据分组丢失了,只要序号落入接收窗口内且无误码的数据分组,接收方都会接受

    • 接收方接受 0 0 0 号和 1 1 1 号数据分组,并发送 0 0 0 号和 1 1 1 号确认分组。

    • 接受窗口向前滑动两个位置,这样就有 4 4 4 5 5 5 这两个新的序号进入接收窗口。

    • 接收方接受 3 3 3 号数据分组,并发送 3 3 3 号确认分组,但接受窗口不能向前滑动

      • 因为 3 3 3 号数据分组是未按序到达的数据分组。

    image-20221125192238937

    这些确认分组经过互联网的传输到达了发送方。

    • 发送方每按序收到一个确认分组,发送窗口就向前滑动一个位置。
    • 发送方接受 0 0 0 号和 1 1 1 号确认分组,发送窗口向前滑动两个位置。
    • 这样就有 4 4 4 5 5 5 这两个新的序号落入发送窗口。
    • 发送方将序号落入发送窗口的 4 4 4 号和 5 5 5 号数据分组发送出去。
    • 发送方现在可以将已经收到确认的 0 0 0 号和 1 1 1 号数据分组从发送缓存中删除了

    而接收方可以择机将已接受的 0 0 0 号和 1 1 1 号数据分组交付上层处理

    image-20221125192705109

    发送方接受 3 3 3 号数据分组,但是发送窗口不能向前滑动。

    • 因为这是一个未按序到达的确认分组
    • 发送方还未收到它之前的 2 2 2 号确认分组。
    • 需要记录 3 3 3 号数据分组已收到确认。这样该数据分组就不会超时重发

    4 4 4 号和 5 5 5 号分组到达接收方。接收方并接受他们,并发送 4 4 4 号和 5 5 5 号确认分组

    但是接受窗口不能向前滑动。

    • 因为这是一个未按序到达的数据分组,接收方还未收到它们之前的 2 2 2 号数据分组。

    image-20221125193053698


    假设在 4 4 4 号和 5 5 5 号确认分组的传输过程中,发送方针对 2 2 2 号数据分组的重传计时器超时了。

    发送方重传 2 2 2 号数据分组。

    image-20221125193307237

    4 4 4 号和 5 5 5 号确认分组陆续到达发送方。

    发送方接受他们,但是发送窗口不能向前滑动

    • 因为它们是未按序到达的确认分组,发送方还未收到它们之前的 2 2 2 号确认分组。
    • 需要记录 4 4 4 号和 5 5 5 号数据分组已收到确认,这样它们就不会超时重发。

    发送方之前重传的 2 2 2 号数据分组到达接受方

    • 接收方接受该数据分组,并发送 2 2 2 号确认分组。
    • 接收窗口现在可以向前滑动 4 4 4 个位置,这样就有 6 , 7 , 0 , 1 6,7,0,1 6701 这四个新的序号落入接收窗口。

    image-20221125193655880

    2 2 2 号确认分组经过互联网的传输到达发送方。

    发送方接受该确认分组,

    • 发送窗口现在可以向前滑动 4 4 4 个位置,这样就有 6 , 7 , 0 , 1 6,7,0,1 6701 这四个新的序号落入发送窗口。
    • 发送方现在就可以继续将这四个序号的数据分组依次发送出去了。

    image-20221125193853623

    4.2、尺寸问题

    image-20221125194420253

    若发送窗口和接收窗口的尺寸超过了他们的取值范围

    image-20221125194622158

    发送方将序号落在发送窗口内的 0 − 4 0-4 04 5 5 5 个数据分组依次连续发送出去

    他们经过互联网的传输到达了接收方。

    • 接收方接受他们,并发送 0 − 4 0-4 04 号确认分组
    • 接受窗口向前滑动 5 5 5 个位置,这样就有 5 , 6 , 7 , 0 , 1 5,6,7,0,1 56701 这五个新的序号落入发送窗口。

    image-20221125194812131

    这些确认分组经过互联网的传输到达了发送方。

    • 但其中的 0 0 0 号确认分组丢失了
    • 发送方接受 1 − 4 1-4 14 号确认分组,并记录 1 − 4 1-4 14 号数据分组已收到确认。
    • 发送窗口不能向前移动

    image-20221125195040028

    一段时间后, 0 0 0 号数据分组的重传计时器超时了。

    • 发送方重传 0 0 0 号数据分组

    该数据分组经过互联网的传输到达了接收方。

    • 其序号 0 0 0 落在接受窗口内,接收方会接受它

    • 但是,接收方先前已经正确接收过该数据分组了。

      如果现在还要接受,那就会出现分组重复这种传输差错。

    • 接收方无法分辨新、旧数据分组

    image-20221125195509811

    4.3、小结

    image-20221125195816528

    4.4、习题

    image-20221125200048285

    解析:

    • image-20221125200927557
  • 相关阅读:
    开源创新突破之旅,开放原子开源大赛激励科技前行(4月13-14日获奖名单公布)
    JavaScrip笔记(1)
    Flutter的oktoast插件详解
    Chrome插件精选 — 扩展管理插件
    C语言 - 四种方法解决杨辉三角问题
    代码随想录算法训练营第23期day24|回溯算法理论基础、77. 组合
    Android 10.0 展讯工厂测试模式USB调试开关的分析
    OC-错误提示
    Python实现PDF、WORD文档中文本抽取
    并查集(Disjoint Set)
  • 原文地址:https://blog.csdn.net/qq_67720621/article/details/128044575