<计算机网络自顶向下> 可靠数据传输的原理(未完成)

可靠数据传输(rdt:Reliable Data Transfer)的原理

  • rdt在应用层,传输层和数据链路层都很重要
  • 是网络TOP10问题之一
  • 信道的不可靠特点决定了可靠数据传输rdt的复杂性
  • rdt_send: 被上层(如应用层)调用,以将数据交付给下方的发送实体
  • udt_send: 被rdt调用,用一将分组放到不可靠的信道上传输到接收方
  • rdt_rcv: 放分组通过信道到达接收方的时候调用(修改下层的错误,传递给上层正确的信息)
  • 下面将渐增的开发rdt的发送方和接收方(上层和下层的接口都定下来以后,如何安排本层协议实体需要做那些动作,安排那些时空资源来向上层提供可靠的服务)
    • 条件;只考虑单项数据传输(但是接收方有可能会返回给发送方控制信息一类的东西,所以控制信息是双向流动的)

    • 双向的数据传输问题实际上黑丝两个单项数据传输问题的综合

    • 使用FSM(有限状态机)来描述发送方和接收方(在某一状态的时候,下一个状态只由下一个事件唯一确定

      |------------------------------------------------------------------------------------------------------|
      | 把可靠传输依靠下层信道比作一个团队领导依靠小弟,下面小弟越没用领导的工作就越复杂,所以需要先假设他们可靠程度高一点,渐增的设计领导的工作这样更加容易一点而不是毫无头绪的直接从头设计领导工作,rdt同理 |

Rdt1.0: 在可靠信道上的可靠数据传输

  • 下层信道是完全可靠的
    • 没有比特出错
    • 没有分组丢失
  • 发送方和接收方的FSM
    • 发送方将数据发送到下层信道
    • 接收方从下层信道接收数据
  • 总的来说rdt1.0要做的就是封装和解封装

Rdt2.0: 具有比特差错的信道

  • 下层信道可能会出错,将分组中的比特翻转

    • 用校验和来检测比特差错
  • 从差错中恢复的办法

    • 确认(ACK):接收方显式的告诉发送方分组已经被正确接受
    • 否定确认(NACK): 接收方显式的告诉发送方发生了差错:发送方收到NAK以后重传分组
  • rdt2.0中的新机制:使用差错控制编码来进行差错检测

    • 发送方差错控制编码、缓存
    • 接收方使用编码检错
    • 接收方的反馈,控制报文(ACK.NAK):接收方->发送方
    • 发送方收到反馈相应的动作
  • rdt2.0致命的缺陷

    • ACK和NACK也有可能出错
    • rdt2.1引入序号可以解决这一点

Rdt2.1:有序号

  • 处理重复:发送方在每个分组中加入序号,如果ACK/NAK出错,发送方重传当前分组

  • 如果序号重复的话,接收方丢掉重复分组,再发一次ACK

  • 这是stop and wait (停等协议):发送方发送一个分组(一次只发送一个分组),然后等待接收方的应答

  • 发送方

    • 在分组中加入序列号,0和1两个序号即可(因为一次只发送一个未经确认的分组)

    • 必须检查ACK/NAK是否出错(需要checksum)

    • 状态数变成了两倍:必须记住当前分组的序列号是0还是1

  • 接收方

    • 必须检测接收到的分组是否是重复的

      • 状态会指示希望收到的分组的序号为0还是1

      • 注意:接收方并不知道发送方是否正确收到了ACN/NAK------没有安排确认的确认

rdt2.2:无NAK的协议

  • 功能同rdt2.1,单只使用ACK(ack要编号)
  • 接收方对最后正确接受的分组法ACK,以替代ACK
    • 接受方必须显示的包含被正确接收分组的序号
  • 当收到重复的ACK(如:再次收到ACK0)的时候,发送方与收到NAK采取相同的动作:重传当前分组
  • 为后面的一次发送多个数据单位做准备
    • 一次能够发送多个,每一个的应答都有:ACK, NACK太麻烦了
    • 使用对前一个数据单位的ACK代替本数据单位的NAK
    • 确认信息减少一半,协议处理简单
  • 2.2和2.1的唯一区别就是2.2没有NAK

Rdt3.0:具有比特差错和分组丢失的信道------超时重传机制

  • 下层信道可能会丢失分组(数据或者ACK)
    • 会死锁:发送的时候分组丢失(比如队列满了包丢失等等)比如发送p1包到接收方,p1中间没了,发送方等待AK,接收方等待p1

    • 机制还不够处理这种状况(下面列出来的只是帮助回忆之前的机制)

      • 检验和
      • 序列号
      • ACK
      • 重传
    • 方法:发送方等待ACK一段合理的时间

      • 发送端超时重传,如果导师没有收到ACK->重传
      • 问题:如果分组(或ACK)只被延迟了
        • 重传将会导致数据重复,但利用序列号一已经可以处理这个问题
        • 接收方必须指明被正确接收的序列号
      • 需要一个倒计数定时器(设置为比正常往返稍微多一点点的时间)
    • 链路层的timeout时间是确定的(往返延迟分布比较集中),传输层timeout时间是适应式的(往返延迟分布比较分散)

      |-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
      | 链路层(数据链路层)定时器设置固定: 链路层通常负责在相邻节点之间进行数据传输,其定时器设置一般较为固定。这是因为在局域网或广域网等较小范围内的链路上,往返延迟相对较低且相对稳定,数据包的传输时间相对可预测。因此,链路层的定时器一般采用固定的超时时间,以适应这种相对稳定的网络环境。 传输层定时器设置适应性强: 传输层负责在端到端的通信中提供可靠的数据传输服务,其定时器设置一般需要更加灵活和适应性强。在互联网等大范围网络中,往返延迟可能会受到多种因素的影响,如网络拥塞、路由器处理延迟、数据包丢失等,导致数据包的传输时间波动较大,难以准确预测。因此,传输层通常采用自适应的超时时间设置策略,如 TCP 中的拥塞控制算法(如慢启动、拥塞避免)和快速重传机制,以根据网络状况动态调整超时时间,从而提高数据传输的效率和可靠性。 |

    • 过早超时(延迟的ACK)也能够正常工作;但是效率较低,一半的分组和确认是重复的,所以设置一个合理的超时时间也是比较重要的;

相关推荐
_.Switch38 分钟前
高级Python自动化运维:容器安全与网络策略的深度解析
运维·网络·python·安全·自动化·devops
2401_8504108339 分钟前
文件系统和日志管理
linux·运维·服务器
qq_2546744140 分钟前
工作流初始错误 泛微提交流程提示_泛微协同办公平台E-cology8.0版本后台维护手册(11)–系统参数设置
网络
JokerSZ.43 分钟前
【基于LSM的ELF文件安全模块设计】参考
运维·网络·安全
UestcXiye2 小时前
《TCP/IP网络编程》学习笔记 | Chapter 3:地址族与数据序列
c++·计算机网络·ip·tcp
一只哒布刘2 小时前
NFS服务器
运维·服务器
qq_421833673 小时前
计算机网络——SDN
计算机网络
小松学前端3 小时前
第六章 7.0 LinkList
java·开发语言·网络
城南vision4 小时前
计算机网络——TCP篇
网络·tcp/ip·计算机网络