可靠数据传输原理(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:优点是出错了重传的代价小；缺点是设计复杂，需要的资源多，需要多个缓存单元