流水线协议
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的基石。