可靠数据传输的原理

可靠数据传输（rdt）的原理

• rdt在应用层、传输层和数据链路层都很重要
• 网络Top 10问题之一
• 信道的不可靠特点决定了可靠数据传输协议（ rdt ）的复杂

可靠数据传输：问题描述

rdt_send(): 被上层（如应用层）调用，以将数据交付给下方发送实体
udt_send(): 被rdt调用，用以将分组放到不可靠的信道上传输到接收方
udt_rcv(): 当分组通过信道到达接收方时被调用
deliver_data(): 被rdt调用，将数据交付给上层

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

• 下层的信道是完全可靠的
  • 没有比特出错
  • 没有分组丢失
• 发送方和接收方的FSM
  • 发送方将数据发送到下层信道
  • 接收方从下层信道接收数据
    

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

• 下层信道可能会出错：将分组中的比特翻转
  • 用校验和来检测比特差错
• 问题：怎样从差错中恢复：
  • 确认(ACK)：接收方显式地告诉发送方分组已被正确接收
  • 否定确认( NAK): 接收方显式地告诉发送方分组发生了差错
    • 发送方收到NAK后，发送方重传分组
• rdt2.0中的新机制：采用差错控制编码进行差错检测
  • 发送方差错控制编码、缓存
  • 接收方使用编码检错
  • 接收方的反馈：控制报文（ACK，NAK）：接收方->发送方
  • 发送方收到反馈相应的动作

rdt2.0：FSM描述

rdt2.0：没有差错时的操作

rdt2.0：有差错时

rdt2.0的致命缺陷！-> rdt2.1

如果ACK/NAK出错？

• 发送方不知道接收方发生了什么事情！
• 发送方如何做？
  • 重传？可能重复
  • 不重传？可能死锁(或出错)
• 需要引入新的机制
  • 序号
    处理重复：
• 发送方在每个分组中加入序号
• 如果ACK/NAK出错，发送方重传当前分组
• 接收方丢弃（不发给上层）重复分组
  

rdt2.1：讨论

发送方：

• 在分组中加入序列号
• 两个序列号（0，1）就足够了
  • 一次只发送一个未经确认的分组
• 必须检测ACK/NAK是否出错（需要EDC ）
• 状态数变成了两倍
  • 必须记住当前分组的序列号为0还是1
    接收方：
• 必须检测接收到的分组是否是重复的
  • 状态会指示希望接收到的分组的序号为0还是1
• 注意：接收方并不知道发送方是否正确收到了其ACK/NAK
  • 没有安排确认的确认
    
    接收方不知道它最后发送的ACK/NAK是否被正确地收到
• 发送方不对收到的ack/nak给确认，没有所谓的确认
• 接收方发送ack，如果后面接收方收到的是：
  • 老分组p0？则ack 错误
  • 下一个分组？P1，ack正确

rdt2.2：无NAK的协议

• 功能同rdt2.1，但只使用ACK(ack 要编号）
• 接收方对最后正确接收的分组发ACK，以替代NAK
  • 接收方必须显式地包含被正确接收分组的序号
• 当收到重复的ACK（如：再次收到ack0）时，发送方与收到NAK采取相同的动作：重传当前分组
• 为后面的一次发送多个数据单位做一个准备
  • 一次能够发送多个
  • 每一个的应答都有：ACK，NACK；麻烦
  • 使用对前一个数据单位的ACK，代替本数据单位的nak
  • 确认信息减少一半，协议处理简单
    

rdt3.0：具有比特差错和分组丢失的信道

新的假设：下层信道可能会丢失分组（数据或ACK）

• 会死锁
• 机制还不够处理这种状况：
  • 检验和
  • 序列号
  • ACK
  • 重传
    方法：发送方等待ACK一段合理的时间
• 发送端超时重传：如果到时没有收到ACK->重传
• 问题：如果分组（或ACK ）只是被延迟了：
  • 重传将会导致数据重复，但利用序列号已经可以处理这个问题
  • 接收方必须指明被正确接收的序列号
  • 需要一个倒计数定时器
    链路层的timeout时间确定的传输层timeout时间是适应式的