传输层可靠传输rdt协议

rdt1.0

• 信道完全可靠，不出错不丢包
• 接收方和发送方速率匹配
• 接收方不需要反馈信息给发送方，因为不会出现任何差错

通过状态机刻画这个过程：

rdt2.0

又称停等协议

• 信道不完全可靠，可能出现比特差错，但不丢包
• 所有分组都能按顺序被接收

为了解决差错问题，引入ARQ(Automatic Repeat Request)自动重传协议。

差错检测：接收方检测是否出现比特差错，需要分组增加检验和checkSum字段。

接收方通过反馈ACK，或者NAK 给发送方知道分组是否被正确接收。

接收方： 从网络层接受一个分组，检查检验和，出错则丢弃该分组，返回NAK，分组无错则接收且返回ACK。

发送方： 发送方必须暂时保留已经发送的分组的副本，只有收到确认后才可以清楚该副本。 发送完成后，在等待ACK或NAK状态时，不能发送任何新数据，直到收到接收方返回分组为止。

rdt2.1

rdt2.0存在一个缺陷:如返回的ACK/NAK分组受损，发送方不能理解对方的含义。

解决方法： 当发送方收到含糊不清的ACK或NAK分组时，只简单的重发当前的数据分组

在解决这个问题的同时，又会引入新问题：产生冗余分组，同一个分组收到两次时，接收方无法判断当前分组为新分组还是重传分组。 于是需要给分组添加序号字段。

给每一个分组都添加一个序号字段

• 发送方每发送一个分组序号+1
• 接收方按序号接收，如果本次接收的分组和上一次接收的一样，则为重复分组，将该重复分组丢弃。

序号位数的选择
停等协议只需要一个比特，即0或1两种不同的序号来区分前后相邻的序号，序号通过模2的运算向前运动。即0，1，0，1，0，1…

说明
ACK或NAK分组不需要明确序号，因为假设信道不丢失分组

发送方知道所接受的ACK或NAK分组是对最近发送分组的响应

rdt2.1 : 处理重复分组

• 接收方：
  收到乱序的分组，是重复分组，丢弃，并回发一个ACK
  收到受损的分组，丢弃，并返回NAK

rdt2.2

进一步改进：
接收方接收到受损的分组时，不发送NAK，改为发送一个对前一个正确接收分组的ACK,

发送方接收到对同一个分组的两个ACK，可判断出对方没有正确接收到被两次确认分组后的那一个分组。

rdt3.0

又称为比特交替协议（分组序号在0和1之间交替）

• 会出现比特差错
• 会丢包
• 发送方需要发现丢包以及丢包后如何处理

超时重发：由发送方检测丢包和恢复。
即：发送方发送一个数据后，如果一定时间内未收到ACK，则重传分组

实现：每发送一个分组，就设置开启一个递增（减）计数定时器，超时了就重传分组。

工作流程图：

流水线协议

停等协议能够正常工作，效率却不高，原因在于发送方发送一个分组，就需要停下来等待接收方的反馈，其间信道资源空闲，白白浪费。
基于上面的考虑，引入流水线技术，即允许发送方连续发送多个分组而无需等待确认。

技术要点：

1. 增加序号范围
2. 需要缓存多个分组
3. 发送方至少能缓冲已发送但没有确认的分组（可能需要重传
4. 接收方缓存已正确接收的分组

流水线有两个协议类型： Go-Back-N（回退N步）和 Selective Repeat（选择性重传）

GO-Back-N

也被称为滑动窗口协议，先介绍一个概念：滑动窗口。
发送方维持一个发送窗口，它的意义是：位于窗口内的分组才有被发送出去的资格。且连续发送而不需要等待确认。

如图， 整个序列被划分成4部分，绿色代表已经被确认接收的，黄色是已发送未确认的，蓝色代表未被发送（但有发送资格） ，白色是没有发送资格的。

• 发送方每确认一个分组，就将这个窗口向前滑动一个位置。
• 接收方采用累计确认的方式，在收到几个分组之后，对按序到达的最后一个分组发送确认，这就表示：到这个分组为止的所有分组都被正确接受了。

累计确认的优点： 容易实现，即使确认丢失也不必重传
缺点： 不能向发送方反映接收方已经正确接收的所有分组的消息
如： 发送方发送了5个分组，而中间的第3个分组丢失了，此时接收方只能对前2个分组发出确认，发送方无法知道后面三个分组的下落，只好把后3个分组都重传一次。 这就叫做GBN

GBN运行：

SR 协议

• GBN缺陷： 出错时，要重发出错及其后分组，当窗口大小和带宽时延积都很大时，堵塞管道，影响效率。

• 改进方法：发送方只重传出错（丢失或受损）的分组。（于是引入了SR协议）

• 选择性重传的基本思想：

• 发送方：

1. 连发多个数据分组，停止等待
2. 收到确认ACK，继续发送后面分组；
3. 超时,未收到应答，只重发出错分组。

• 接收方：不按序号接收数据分组
  正确：接收、并交付，发确认ACK；
  出错：丢弃该分组，以后正确分组放入缓存，当出错分组正确收到后，按顺序一起交付。

接收方不按序接收。接收窗口大小 > 1，即只要序号落在接收窗口内的正确分组都可接收。

理解了GBN之后，SR就很好理解了。

最大窗口尺寸

GBN Wt=2^k-1

在GBN协议中，最大的窗口尺寸应该为 2^k-1 (k为序号位数)
使用反证法：
当k=3位时， 序号空间为8即0#~7#，发送方发送 0# ~ 7# 8个分组，停止等待。
接收方如果正常接收，ACK回复全部到达， 则协议正常。
接收方的ACK回复如果全部丢失，此时接收方准备接收新的 0#~7#分组，而发送方超时重传了旧的 0#-7#分组，协议失败。

当序号空间为 0# - 6# 时，协议正常

SR Wt=2^(k-1)

在SR协议中，最大的窗口尺寸应该为 2^(k-1) (k为序号位数) 即序号空间的一半，而不是2^k -1

反证： 设序号为2， 即有0-3

例题

1. 假设使用连续ARQ协议，发送窗口大小是3，而序列范围[0,15],而传输媒体保证在接收方能够按序收到分组。在某时刻，在接收方，下一个期望收到序号是5。 试问：
   ①在发送方的发送窗口中可能有出现的序号组合有哪几种？
   ②接收方已经发送出去的、但在网络中（即还未到达发送方）的确认分组可能有哪些？说明这些确认分组是用来确认哪些序号的分组。

分析：
①期望号收到的序号是5，则说明0-4的分组都正确接收；
如果发送方也接收到了2-4的ACK，则此时窗口内的应该是 [5,6,7]
如果发送方没有接收到2-4中的ACK，则此时发送窗口内的序号有可能为 [3,4,5] , [2,3,4], [4,5,6]

② 可能有2，3，4 ,是用来确认序号为2，3，4的分组。

最后

以上就是机灵指甲油为你收集整理的传输层可靠传输rdt协议的全部内容，希望文章能够帮你解决传输层可靠传输rdt协议所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。