流水线协议

Rdt3.0在停等操作的过程中浪费了大量的时间：

从而在Rdt 3.0上引入了流水线机制：为了提高资源利用率

流水线协议：
允许发送方在收到ACK之前连续发送多个分组，更大的序列号范围，同时发送方和/或接收方需要更大的存储空间以缓存分组。

滑动窗口协议

滑动窗口协议：发送方和接收方各有一个缓存数组，发送方存放着：已发送且成功确认包序号、已发送未确认包序号 ，未发送包序号。接收方存放着：已接受包序号、正在接收包序号、未接收包序号。每个数组有个两个扫描指针，开头和结尾，一起向后扫描，两者形成一个窗口，所有被称为窗口协议。

滑动窗口协议主要有两种协议：

• GBN（回退N重传协议）
• SR（选择重传协议）

窗口：允许使用的序列号范围，窗口尺寸为N：最多有N个等待确认的消息

滑动窗口：随着协议的运行，窗口在序列号空间内向前滑动

我们现在来分别讲一下这两种协议：

GBN协议

• 分组头部包含k-bit序列号
• 窗口尺寸为N，最多允许N个分组没有确认
• 确认ACK：确认到序列号n的分组均已被正确接收，可能收到重复ACK。
• 为传输的分组设置计时器（timer），若超时Timeout：重传序列号大于等于n，还未收到ACK的所有分组。

我们来看一下GBN协议的处理过程：

如果遇到问题了，会回退所有窗口内的分组。

窗口大小为4，发送方发送数据包0，1，2，3，然后进入等待状态，其中数据包2丢失，接收方返回Ack0，1，窗口滑动继续发送包4，5，此时包2计时超时，默认数据包2没有收到，按照GBN，发送方重新发送数据包2，3，4，5。这里可以看出数据包重复了。

SR协议

• 接收方对每个分组单独进行确认, 设置缓存机制，为了缓存乱序到达的分组，发送方就不会再次发送，限制已发送且未确认的分组。
• 如果计时器到点, 仅重传该个未确认的数据报
• 发送方窗口，N个连续的序列号， 发送者在流水线中最多有 N 个未确认的数据报

我们来看一下SR协议的工作过程：

滑动窗口的大小为4，发送数据包0，1，2，3，窗口满了，停止发送，等待确认，其中数据包2丢失，依次确认数据包0，1，同时窗口向后移，依次发送数据包4，5，当数据包2超时，发送方会再次发送数据包2，同时缓存乱序到达的3，4，5，当接收完数据包2后，滑动窗口后移，发送方继续发送数据包。

因此我们来对比一下：

对比GBN和SR

• GBN：
  • 简单，所需资源少（接收方一个缓存单元）
  • 但是一旦出错，回退N步代价很大
• SR：
  • 出错时重传一个代价小
  • 复杂，所需要的资源很大（接收方需要缓存多个缓存单元）

适用范围

• 出错率低：比较适合GBN，出错非常罕见，没有必要用复杂的SR，为罕见的事件做日常的准备和复杂处理

• 链路容量大（延迟大、带宽大）：比较适合SR而不是GBN，一点出错代价太大

总结

• 停等(stop-and-wait )协议：发送方发送数据，然后等待接收方通过ACK或者NAK反馈
• 流水线协议(Pipelined protocols)：允许发送方发送多个分组而无需等待确认
• 解决流水线的差错恢复有两种基本方法（滑动窗口协议）：
  • 回退N步(Go-Back-N，GBN)：回退N步，接收方则是只接受最小的未接受帧，对错序到达帧，都丢弃
  • 选择重传(selective repeat，SR)：只重传丢失的帧，乱序到达的帧缓存起来

因此对于可靠性，我们可以做出以下结论：

RDT协议解决了可靠性的问题，它引入了：

• 校验和
• 序号
• 确认应答机制

而滑动窗口协议解决了因为RDT协议而导致的效率底下问题，它引入了：

• 流水线发送数据
• 滑动窗口机制 – 发送缓冲区，接收缓冲区

所以接下来，我们可以开始正式介绍TCP协议了，RDT，SR协议是TCP的基石。