四、可靠数据传输协议

可靠数据传输原理

  • 可靠:不错、不丢、不乱
  • 信道的不可靠特性决定了可靠数据传输协议(rdt)的复杂性

基本结构(接口)

  • rdt_send将上层数据交给rdt协议,将事情交给传输层。单向箭头表示上层网络应用单向调用传输层协议,只调用一次(交给TCP了)。
  • udt_send()被rdt调用,不可靠信道指的是网络层地IP协议。双向箭头
  • rdt_rcv:当数据包到达接收方信道时被调用。会触发接收方的rdt协议。双向箭头。
  • deliver_data:交付数据。并且是可靠的交付数据。也是单项的,意味着可靠数据传输协议将所有的事情做好以后才把数据正确的交付给上层。

传输协议的刻画

  • 利用状态机刻画。

RDT1.0

  • 底层信道完全可靠。
  • 故发送方和接收方相互独立,无耦合关系。
  • 发送方:当上层调用产生事件rdt_send时,data为欲交付的数据。采取活动:创建分组packet,调用udt_send发送数据。
  • 接收方:等待下层的调用。从分组中将数据提取,由于信道完全可靠不需要检测数据是否出现异常,因此直接向上层deliver即可。

Rdt2.0

  • 研究信道对象:底层信道可能翻转分组中的位(bit);
  • 利用校验和检测位错误
  • 如何恢复:需要引入新的消息。
    • ACK机制:接收方显式告诉发送方分组已经正确接收。
    • NAK:错误接收。
    • 发送方收到NAK后重传即可
  • 称为ARQ协议。差错检测(包括但不限于校验和),接收方反馈控制消息。(ACK,NAK)。重传。

描述:

  • 发送方需要两个状态,称为停等协议
  • 发送方处于左侧状态时,如果收到上层应用层的调用,于是协议打包数据,加上校验和,然后调用udt_send发送数据。进入右边的状态。
  • 当发送端处于右侧状态时,如果收到isNAK,则重发,还是处于该状态。
  • 否则如果收到ACK,重新回到左侧的状态。
  • 接收方仅单个状态,当rdt_rcv被调用时检查校验位。如果检查正确,那么提取数据,向上层交付,并且告诉发送方ACK。否则发送NAK。

Rdt2.1和Rdt2.2

  • 如果ACK/NAK消息发生错误/被破坏(corrupted)会怎么样?

    • 如果坏掉,则重传,但直接重传会造成重复分组问题。
    • 方案:发送方为每个分组增加序列号。接收方丢弃重复分组。

Rdt 2.1发送方

  • 在状态1,上层数据加上校验和和序列号0打包并发送,转移到状态2
  • 在状态2,如果接收到的数据(ACK或NAK)被破坏那么重新发送数据。停留在状态2.(请求接收方再说一遍,重新发送一次序列号为0的数据)
  • 在状态2,如果数据没有被破坏并且收到的ACK,那么转移到状态3.
  • 在状态3,发送序列号为1的数据(加上校验和等信息),转移到状态4;
  • 状态4和状态2形式上对称

Rdt2.1接收方

  • 处于状态1,期望得到序列号为0的数据
  • 处于状态2,期望得到序列号为1的数据
  • 在状态1如果收到的数据校验和异常,那么发送NAK
  • 在状态1如果收到序列号为1的数据(与期望不一致),那么重新发送一次ACK给发送方,但并不向应用层交付数据。(避免了重复分组)
  • 在状态1如果收到序列号为0的数据(与期望得到的一致),那么发送ACK转而状态2期望得到序列号为1的数据,同时需要向应用层交付得到的数据。

对比2.1和2.0

Rdi 2.2 无NAK消息协议

  • 在ACK消息中显式的加入最后一个被正确接收的分组的序列号。
  • 发送方收到重复ACK之后,采取与收到NAK消息相同的动作
  • 注意在接收方收到错误的数据或该数据不是期望的数据(序列号为0)时,均利用刚刚从状态1到状态0转换时打包好的(ACK1和checksum)告知发送方重新发送期望的数据(序列号为0的数据)

RDT3.0-等待合理的时间

工作机制

  • 如果信道可能发生分组的丢失该如何处理呢?

    • 如果发送方分组丢失,如果采用上述协议,发送方不会收到接收方任何发过来的信息。就会一直处于某个状态中无线等待。
  • 解决方案:发送方等到合理长度的时间。
    • 如果没收到则重传
    • 如果分组或ACK只是延迟而不是丢失,组序列号能有效解决重复发送的问题。
    • 需要一个定时器

  • 如图所示,在应用层请求协议传输数据后,协议发送数据,计时器启动。转到期望ACK0的状态
  • 如果处在ACK0且计时器超时(分组可能丢失),那么重新发送分组。计时器复位。
  • 这里有个比较subtle的地方,看到接收到的ACK为1(即对应NAK)或ACK被破坏时,不做任何操作。而是等待计时器超时再重新发送;

典型场景:

  • 无丢包情况
  • 丢包情况:等待到计时器超时重新传递分组;
    ![在这里插入图片描述](https://img-blog.csdnimg.cn/29a86965003446d58ac5f
  • ACK丢失情况:pk1到达了receiver,发送ACK1,但丢失。重传PK1,即接受方收到了两次。以序列号机制处理(不上载数据)重复分组。
  • ACK1没有丢失,但由于定时器再收到ACK1之前就超时了。(能够处理重复分组)。发完第二个pk0处于如图所示的状态。这里重复的ACK1的处理方式:参照状态机是直接忽略?忽略后能够正常处理ACK0。

性能分析


流水线机制

  • 为每个输送中的分组添加一个唯一的序号
  • 发送方和接收方两段也许不得不缓存多个分组

滑动窗口协议-GBN(后退N帧)

  • 协议的模拟网站:GBN模拟

  • 分组头部包含k-bit序列号

  • 窗口尺寸为N,最多允许N个分组未确认。

    • 意思是流水线中的未确认分组数不能超过某个最大允许数量N
  • 绿色表示已经确认的序列号

  • 黄色表示已经发送但还未被确认的序列号;send_base表示最小的这类序列号。

  • 蓝色表示还没有使用的序列号。nextseqnum指向最小的这类序列号

  • 定义ACK(n):ACK(n) :ACK(n): 确认到序列号n(包含n)的分组均已被正确接收

    • 表示序列号n,n−1,n−2⋯1n,n-1,n-2\cdots 1n,n−1,n−2⋯1的所有分组都被成功接收。
  • 假定第n个分组发生了超时事件(超时Timeout(n)事件): 重传序列号大于等于n,还未收到ACK的所有分组

发送方(扩展的有穷状态自动机)

  • timer应该是一个全局计时器。发送方仅有的一个计时器。

  • 注意base指向第一个还没有确认的分组,seqnum指向第一个空闲序列号

  • 初始时base == 1,nextseqnum = 1

  • 如果nextseqnum<base+N,则意味着窗口还没有用完(还有可以使用的nextseqnum)。还可以接着发送分组。如果base和nextseqnum相同,则启动定时器。

    • 如果窗口已经用完了,则直接refuse掉欲新发送的数据
  • Timeout事件

    • 首先重启计时器
    • 将所有已发送但还没有确认的分组重新发送一遍(即[base,seqnum-1]的所有分组)
  • 收到接收消息:

    • 令base指向最后已经确认的序列号(即返回的序列号)的下一个序列号(即下一个还未被确认的序列号) ;

      • 因为这意味着最后确认的序列号及其前面的序列号都进行了确认。
      • 这意味着窗口进行了滑动。(窗口固定大小N,向前滑动了一个单位,注意上面的状态的if判断条件(nextseqnum<base+N)
    • 关注这里计时器的行为:
      • if条件为真:表明没有已经发送但是未被确认的分组,停止计时器。
      • if条件为加:表明仍有已发送但是还未被确认的分组,定时器被重新启动
      • 而在第一步(窗口没用完发送数据时)start_timer开始启动而且仅在窗口中没有任何东西时启动的(也就是发送第一个分组时)。这时这个第一个分组还未被接收。因此此时start_timer可以看作针对于这个分组的计时器。
      • 一旦收到ACK即接收消息时,计时器重新启动且此时base会指向ACK组序号加1的分组(即最早已发送,但未确认的分组)。
      • 注意上述对于Timer重启的条件的总结。可以得出这里的全局计时器可看作是:最早的已发送但未确认的分组所使用的计时器

GBN接收方

  • ACK机制: 发送拥有最高序列号的、已被正确接收的分组的ACK;维护变量expectedseqnum当前期望收到的序列号。

  • 如右上角所示,如果当前收到了一个分组并且没坏,并且这个分组是当前所期望的:那么上载数据。并令期望收到的分组序列号+1;
    左侧的代码为初始化

  • 丢弃接收方没有缓存,重新确认序列号最大的、按序到达的分组

  • 默认操作为(例如收到损坏或)发送当前确认的最大的序列号。

    • 此时对于发送方而言,

GBN实例

  • 假定窗口大小为4

    • 发送方一直发送直到pk3,此时窗口已满
    • pk0和pk1都已成功的到达了对方分别发送ACK0和ACK1,pk2丢失了。
    • pk3到达后被丢失。因为现在期望的是2
    • 发送方收到ACK0和ACK1后可以发pk4和pk5。收到ACK1后base被指向2,计时器重启。这时的计时器应该是针对于分组2的计时器;
    • 这时分组2的计时器发生超时,于是从base开始发直到最后一个未确认的分组seqnum - 1
      w

对于GBN协议序号空间和窗口大小的讨论

命题:用n来表示帧头位数,即序号空间大小为2n2^n2n,GBN协议中发送窗口大小为NsN_sNs​,则必有Ns≤2n−1N_s \leq 2^n - 1Ns​≤2n−1

  • 考虑接收方的ACK全挂掉的情形。

滑动g窗口协议-SR协议(selective-repeat)

  • 模拟:SR协议模拟
  • 设窗口长度N为流水线中未完成,未被确认的分组数。
  • 通过让发送方仅重传那些它怀疑在接收方出错(丢失或受损)的分组而避免不必要的重传;
    • 要求接收方逐个确认已经正确收到的分组。

发送方动作

  • 从上层收到数据:

    • 检查下一个可用于该分组的序号。位于窗口内则将数据打包并发送(和GBN一样),否则refuse
  • 超时:
    • 每个分组都拥有自己的定时器。使得超时发生后只发送一个分组。
  • 收到ACK:
    • 如果序号在窗口内,将那个被接收方确认的分组标记为已经接受
    • 如果该分组序号为send_base,则此指针向前移动到具有最小序号的未确认分组处

接收方动作:

  • 正确收到窗口内即[recv_base,recv_base + N - 1]的分组。

    • 发送该分组的ACK
    • 如果该分组以前未收到过则缓存该分组;
    • 如果该分组的序号等于接收窗口的基序号,则该分组及其之后连续的分组(已经缓存的)交付给上层。窗口移动到下一个没有被接收到的分组。例如上图中如果此时rcv_base处的分组被收到,那么rcv_base向右移动到下一个灰色的方块处。
  • 正确收到[rev_base - N,rev_base - 1]的分组:
    • 这可能是由于ACK在传输过程中造成了损坏或丢失。
    • 这种情况下需要产生ACK给发送方
    • 为什么是N?笔者有点Intution但还不能给出严格证明
    • 这一步是很重要的,必要性由下面的额图给出:
  • 接收方正确收到数据并发送ACK(黄色块)。按上述算法接收方窗口向前滑动
  • 把那些黄色的ACK全部kill掉。
  • 等待超时后,发送方会重新发送分组
  • 假设此时ACK正确被接收,那么发送方窗口会向前移动

SR协议的实例

观察发送方的时间线:

  • 发送方发送pkt0,pkt1,接收方正确接收到。recv_base向前移动。
  • 发送方发送pkt2但很不幸被丢失了
  • 发送方发送pkt3,由于接收方还没有收到pkt2,于是将pkt3缓存起来。
  • 发送方收到ACK0,窗口向前滑动一格,可以发送pkt4。接收方正确收到并缓存
  • 发送方收到ACK1,窗口向前滑动一个,可以发送pkt5。接收方正确收到并缓存。
  • 发送方收到ACK3,标记3号分组已经被接收。
  • 发送方此时针对于2号的计时器已经超时了,于是重新发送分组2
  • 如果此时接收方正确收到pkt2,那么由于已经收到了3,4,5,于是将这一分组交给上层应用。recv_base移动到下一个未收到的位置。

SR协议的囧境

  • 设分组编号的取值为 0 - 3。即序号空间大小为4 = 222^222.

    • 在发送窗口和接收窗口大小相等的意义下,不满足窗口大小小于或等于序号空间大小的一半
  • 设窗口大小为3。
  • 在情形a中:
    • 发送方发送pkt0-pkt2,接收方均正确接收,ACK也被发送方正确接收。发送pkt3被丢失。
    • 如果此时发送方再发送pkt0,发送的是全新的pkt0;
  • 再情形b中:
    • 发送方发送pkt0-pkt2,接收方均正确接收,但是ACK再返回的途中又挂掉了!
    • 等到发送方的pkt0超时后还是原来的),又将其重发给接收方。 而此时接收方由于窗口中具有0,需要再次接收这个pkt0;重复接收!出现问题。

对于SR协议窗口大小和序号空间关系的讨论

  • 由以上比较可以看出, 当窗口大小(为3)比序号空间(为4,即0,1,2,3)小1时无法工作。事实上,有下面的结论成立:

    • 当接收方窗口大小等于发送方窗口大小时,窗口大小必须小于等于序号空间大小的一半。
    • 在一般情形下,用k来表示帧头位数(则序号空间大小为2k2^k2k),NsN_sNs​为发送方窗口大小,NRN_RNR​为接收方窗口大小。则需要满足下面的式子:
      Ns+NR≤2kN_s + N_R \leq 2^kNs​+NR​≤2k

哈工大计算机网络week4学习总结相关推荐

  1. 哈工大计算机网络WEEK1-2学习总结

    计算机网络week1-2学习总结 一.网络定义 计算机网络是计算机技术与通信技术紧密结合的产物. 互联,自治(无主从关系)的计算机集合. 通过交换网络互联主机. 组成细节角度: Internet:IS ...

  2. 哈工大计算机网络期末复习资料知识点总结

    根据慕课和上课的笔记整理的资料,由于时间跨度较大可能会出现详略不得当和错误等情况,望指正 下载地址:[免费]哈工大计算机网络期末复习资料知识点总结.pdf-网络基础文档类资源-CSDN下载根据慕课和上 ...

  3. 计算机网络实验报告哈工大_哈工大计算机网络实验报告之六

    哈工大计算机网络实验报告之六 计算机网络课程实验报告实验6:利用Ethereal分析IP.ARP 协议及以太网数据帧格式姓名 杨煜 院系 软件学院 学号 1113710319任课教师 李全龙 指导教师 ...

  4. 计算机网络讨论课感悟,计算机网络课程学习心得体会

    计算机网络课程学习心得体会 当我们积累了新的体会时,可以将其记录在心得体会中,这样能够给人努力向前的动力.那么好的心得体会是什么样的呢?下面是小编为大家收集的计算机网络课程学习心得体会,供大家参考借鉴 ...

  5. 河南城建计算机网络试卷,河南城建计算机网络技术学习心得体会.docx

    河南城建计算机网络技术学习心得体会 河南城建计算机网络技术学习心得体会 计算机网络技术学习心得体会 众所周知,21世纪是一个信息经济时代.为适应时代的发展,作为一名即将走出校园参加工作的当代大学生,所 ...

  6. 【计算机网络】学习笔记

    [计算机网络]学习笔记 1. 概论 因特网中的服务 计算机网络特点 计算机网络功能 计算机网络的分类 2. 性能指标 体系结构 ISO/OSI参考模型 3. 物理层 传输媒体 物理层的功能 调制 码元 ...

  7. 哈工大计算机网络-作业讲解

    哈工大计算机网络作业 例题等来源于哈工大李全龙老师,李全龙老师YYDS 计算机网络笔记 我们知道分组交换网络中时延共有四种 处理时延 排队时延 传输时延 传播时延 详细讲解

  8. 计算机网络技术有关的心得体会,计算机网络技术学习心得体会

    计算机网络技术学习心得体会: 1世纪是一个信息经济时代,为适应时代的发展,作为一名当代大 学生,所受的社会压力将比任何时候的大学生都要来得沉重,因此 在校期间,我们必须尽可能的利用好学习时间,尽可能地 ...

  9. 哈工大计算机网络物理层总结

    哈工大计算机网络物理层知识点 6.1 数据通信基础 信源:将消息转换为信号的设备,如计算机等 发送设备:将信源产生的信号进行适当的变换装置,使之适合于在信道中传输.主要包括编码和调制. 信道:信号传输 ...

最新文章

  1. 金山词霸2009牛津版
  2. php批量请求url_php请求url的方法小结
  3. Java 文件上传下载管理器(控制台)
  4. Docker的容器运行时组件Containerd
  5. 南京Uber优步司机奖励政策(12月28日到1月3日)
  6. 将5350 i2c clk设置为gpio 中断模式的方法
  7. mysql docker还是rds_容器化RDS:计算存储分离还是本地存储?
  8. OpenStack 集群部署工具:ProStack
  9. 嵌入式linux屏幕录制,在MAC系统上进行屏幕录制
  10. 用Apache James搭建本地邮件服务器
  11. python模拟足球_使用K-Means算法划分亚洲国家的三个足球梯队
  12. 社交APP软件开发流程解析
  13. 通过ADB命令打开MTK和展讯日志的方法
  14. 【51单片机】(五)矩阵键盘
  15. 微信小程序 获取formId
  16. hadoop框架流程图梳理
  17. 快慢指针慢指针和快指针一定会相遇
  18. 原码、反码、补码、移码 基本介绍
  19. 计算机标准差的按键是什么,在计算器上用标准差键直接求离均差平方和的方法...
  20. htcvr设备计算机配置,【HTC-VIVE】02-设备的安装与配置(上)

热门文章

  1. Parameter 0 of method linkDiscoverers in org.springframework.hateoas.config.HateoasConfiguration
  2. Adobe Photoshop CC 2019 for Mac(版本介绍)
  3. Pytorch的nn.Conv2d()参数详解
  4. 【Kafka】Docker安装kafka、搭建kafka集群
  5. 如何查看当前Ubuntu的版本
  6. EOS智能合约开发系列(17): 神秘的eosio.code
  7. 企业微信生态下的会员管理系统
  8. 目前主流服务器厂商有哪些?都有什么型号
  9. Mac电池显示需要维修
  10. webpack安装使用教程