可靠数据传输原理(rdt)
- rdt2.0:首次支持差错恢复的停等协议
rdt 家族中首个具备 “可靠传输” 雏形的版本,针对存在比特差错的信道设计。核心引入校验和(检测错误)、ACK(确认正确接收)和 NAK(告知分组出错)机制,发送方收到 NAK 后会重传对应分组。但缺陷明显:若 ACK/NAK 分组本身受损,发送方无法判断,会陷入等待僵局,且无序号机制导致无法区分重传分组和新分组。 - rdt2.1:通过序号解决重复分组问题
为修复 rdt2.0 的缺陷,新增分组序列号(0 和 1 交替)。接收方通过序号识别重复分组并直接丢弃,避免错误接收;发送方则按序号依次发送,重传时沿用原序号。协议仍保持停等逻辑,但通过序号机制解决了 ACK/NAK 受损带来的重复接收问题,可靠性进一步提升。 - rdt2.2:取消 NAK,简化反馈机制
它删除了 NAK 机制,仅保留 ACK 并优化其功能 ——ACK 中明确携带 “期望接收的下一个分组序号”。若接收方收到错误分组或序号不匹配,无需发送 NAK,只需重发上一次正确接收分组的 ACK(即重复 ACK)。这种设计减少了反馈分组类型,降低了协议实现复杂度,核心停等逻辑和差错恢复能力保持不变。 - rdt3.0:新增超时重传,解决分组丢失问题
前三个版本仅处理比特差错,未考虑 “分组丢失” 场景(如信道故障导致数据或 ACK 丢失)。rdt3.0 在 rdt2.2 基础上新增定时器机制:发送方发送分组后立即启动定时器,若超时未收到 ACK,默认分组或 ACK 丢失,自动触发重传。它也被称为 “比特交替协议”(序号 0/1 交替),最终实现了 “比特差错 + 分组丢失” 场景下的可靠停等传输,是停等协议的完善版本。
这里说的rdt2.0到3.0也是停等协议
而上面所说的rdt对信道容量大的信道的利用率比较低,整个信道只容纳一个分组的传递,必须确认才发下一个。所以流水线协议就诞生了,他的特征是一次发送多个未经确认的分组,在发送方和接收方都有一个缓冲区。
流水线协议(Pipelined protocol)
分为两种:回退n步协议(GoBackN,GBN协议)和选择性重发协议(Selective Repeat,SR协议)。都基于滑动窗口协议。
记send方window长度为sw,recieve方window长度为rw,
sw=1,rw=1 stop and wait协议
sw>1,rw=1 GBN协议
sw>1,rw>1 SR协议
对GBN,接收窗口大小固定为1,如果接收到的不是窗口内所期望的序列号,则直接抛弃,不会缓存,并返回上一个一个ACK使重发。如果是按序的,则上交应用层。
如果中间出现错误,发送方发送多个分组的一开始就设定了计时器,超时则将当前窗口内的分组全部重发。
对SR,接收窗口大于1,只要到达的分组的序号落在窗口内,就被缓存,并返回一个独立的ACK。当这个被缓存的分组时期望的分组时,则上传应用层,并检查缓存中后续连续的分组,将他们一并上传。
发送方一开始为每一个分组都设定了计时器,如果超时则重发那一个分组,不是像GBN只设定一个,全部重发,而是选择性的重发。
基于两者特征,总结以下优缺点:
GBN:优点是简单,接收方只要一个缓存单元;缺点是当出错了回退n步的代价太大
SR:优点是出错了重传的代价小;缺点是设计复杂,需要的资源多,需要多个缓存单元