3.3 可靠数据传输的原理

原创已于 2025-10-14 21:24:22 修改 · 209 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#网络

于 2025-10-10 22:24:38 首次发布

计算机网络专栏收录该内容

41 篇文章

订阅专栏

1.信道

2.可靠数据传输简介

3.RDT 1.0

4.RDT 2.0

5.RDT 2.1

6.RDT 2.2

7.RDT 3.0

1.信道

信道表示数据传输的路, 从物理层开始存在并发挥作用

信道是不可靠的(比如丢失或出错)

1).比特差错

a.比喻: 你在纸上抄写一段长长的数字(比如0010110...), 因为疲劳或笔误, 不小心把其中一个0写成了1; 这就是比特差错

b.专业解释: 信号在物理信道中传输时, 会受到各种干扰(热噪声、电磁干扰等), 导致接收端收到的二进制位(比特)与发送端

发送的不一致; 比如发送的是1, 接收到的却是0

2).数据丢失或损坏

a.比喻: 运送货物的卡车在路上遇到了剧烈颠簸, 导致车上的几个箱子掉出来摔坏了(数据丢失), 或者箱子里的货物被震得乱

七八糟(数据损坏)

b.专业解释: 严重的干扰、信号衰减、连接中断等, 可能导致整个数据帧或数据包完全无法被识别或接收, 或者在传输过程中

变得支离破碎

3).拥塞

a.比喻: 在上下班高峰期, 所有汽车都想同时开上高速公路, 结果导致大堵车; 汽车(数据)无法按时到达目的地

b.专业解释: 当网络上的数据量超过信道(或中间网络设备, 如路由器)的处理能力时, 就会发生拥塞; 路由器缓冲区会被填

满, 导致后续的数据包被丢弃

4).乱序

a.比喻: 你给朋友寄了三封信(A, B, C), 分别走了不同的邮路; 结果朋友收到的顺序是B -> A -> C

b.专业解释: 在网络中, 数据包可以经由不同的路径到达目的地; 由于各路径的延迟不同, 后发出的数据包可能会先到达, 导

致接收端收到的数据包顺序与发送端发出的顺序不一致

5).重复

a.比喻: 你发送了一个请求, 但由于没收到确认, 你以为对方没收到, 于是又发了一次; 结果对方收到了两份一模一样的请求

b.专业解释: 这通常是由上层的重传机制引起的; 当发送方在一定时间内没有收到接收方的确认时, 它会认为数据包已经丢失

于是重新发送, 但有时原数据包只是延迟了, 并未丢失, 这就会导致接收方收到重复的数据

2.可靠数据传输简介

可靠数据传输(Relia Data Transfer, RDT)要解决的问题是: 在一个不可靠的底层信道上, 要实现可靠的数据传输

在这里插入图片描述

3.RDT 1.0

在可靠信道上的数据传输: 下层的信道是完全可靠的, 没有比特出错和分组丢失; 发送方发的是什么数据, 接收方接收的是

什么数据; 发送方只需封装数据, 接收方只需解封装数据

在这里插入图片描述

4.RDT 2.0

RDT 2.0中下层信道可能会出错(比如: 将分组中的比特翻转), 用"校验和"来检测比特差错

1).问题: 怎样从差错中恢复

a.确认(ACK): 接收方显式地告诉发送方分组已经被正确接收

  - "接收方已经成功收到了序号为n的数据包"

b.否定确认(NAK): 接收方显示地告诉发送方分组发生了差错, 发送方收到NAK后, 发送方重传分组 

  - "接收方刚刚收到的数据包是坏的, 请重传你上次发的包"

接收方会回复给发送方"控制报文(ACK, NAK)"

在这里插入图片描述

5.RDT 2.1

a.RDT 2.0存在一个缺陷, 那就是ACK/NAK本身就是错误的? 导致发送方不知道接收方发生了什么事情, 引入了新的机制序号 

b.发送方在每个分组中加入序号, 如果ACK/NAK出错, 发送方重传当前分组; 接收方收到重复分组会丢弃

c.发送方发送一个分组, 然后等待接收方的应答, 因此称为停等协议

d.序列号是0, 1交替替换

1).对于发送方要处理的情况

a.回复包已损坏

  - 动作: 重传当前状态对应的数据包(pkt0或pkt1)
  
  - 原因: 无法分辨是ACK还是NAK, 最安全的做法是重传

b.回复包完好且是NAK

  - 动作: 重传当前状态对应的数据包
  
  - 原因: 接收方明确要求重传

c.回复包完好, 且是ACK, 其序号n等于当前等待的序号

  - 动作: 状态转换, 离开当前等待状态, 变为"就绪"状态, 可以接收上层的新数据
  
  - 原因: 当前数据包传输成功

2).对于接收方要处理的情况

a.数据包已损坏

  - 动作: 发送NAK

  - 原因: 明确通知发送方, 刚发的包是坏的, 请重传

b.数据包完好, 且序号等于当前期待号, 接收到了正确数据

c.数据包完好, 但序号等于[非期待序号](即重复包)

  - 动作: 发送ACK n(这里的 n 是这个重复包自身的序号)
  
  - 原因: 这表示"我收到了一个重复的旧包, 看来你没收到我上次发的ACK, 我再发一次ACK给你"

  - 注意: 接收方此时状态保持不变, 因为它没有收到新数据

6.RDT 2.2

RDT2.2功能类似于RDT2.1, 通过ACK + 序列号代替NAK; "对于当前序号的反向确认通过上一次序号的正向确认实现"

在这里插入图片描述

当发送方接收到了上一次序号的ACK确认, 会重新发送上次发的包

7.RDT 3.0

Rdt 2.2已经解决了比特错误和确认包错误的问题, 但是还有一个致命问题: 如果数据包或确认

包丢了, 发送方和接收方会永远等下去, 整个通信就卡死了; Rdt 3.0引入超时重传的机制

假设: 发送方发送了一个带序列号的数据包

启动计时器: 发送方在发出数据包的同时, 启动一个倒计时器

等待三种可能

a.最佳情况: 在计时器超时前, 收到了对应的ACK; 皆大欢喜, 发送方取消计时器, 发送下一个

数据包

b.情况一: 数据包丢失

数据包在路上丢了, 接收方根本没收到, 自然不会回任何ACK; 发送方的计时器会超时, 发送方

判定:"包可能丢了", 于是重传这个数据包

c.情况二: ACK包丢失

接收方收到了数据包, 也回了ACK, 但ACK在路上丢了; 发送方的计时器同样会超时, 发送方同

样判定:"包可能丢了", 于是重传这个数据包

注意: 此时接收方会收到一个重复的数据包(因为序列号和上一个一样), 但得益于Rdt 2.2的机

制, 接收方会直接丢弃这个重复包, 并再次回传同一个ACK, 以便让发送方知道"我已经收到了

"请继续"