Rdt2.1 和 Rdt2.2的详细解释

Rdt2.1 和 Rdt2.2的详细解释
- - 这俩为啥会出现？
  - 解决之道
    - Rdt 2.1
    - Rdt2.2

可靠数据传递中Rdt1.0, Rdt2.0, Rdt3.0 都很好理解，但是就是这两个毒瘤一直在我脑袋里面刺痛着我，经过一段时间的总结，我相信我能给大家一个比较好理解的解释。

这俩为啥会出现？

既然大版本好是2.0，我们可以回忆一下2.0阶段做了什么事情

Rdt2.0中增加了检验纠错的结构，也就是应答。

sequenceDiagram
sender -->> receiver: 发送消息（备注：你看看对不对？）(跳转到等待态)
receiver -->> sender: 啊对对对，这玩意是我想要的(receiver验货，正常ACK返回)
sender -->> sender: 爷终于放心了，可以发下一个了(状态回溯到初始状态)
receiver -->> sender: 不对啊，我不收(异常NAK)
sender -->> receiver: 重发

按理来说这个过程非常自然啊，receiver检验，sender等待，整个流程走完了，数据也发出去了，如果数据异常，sender也能够重发，但是问题就在于，如果象征着异常数据的标志NAK也错了，象征着正常数据的ACK也错了，sender该如何判断？？？？它唯一的相信的东西没了！！这个流程自然说不通了。

上述流程要完美发生就必须要求ACK,NAK绝对不能出错

可以事实上，非常容易出错，好在我们还是有解决办法的

解决之道

书中给出了三条解决之道：

通过另外的响应规则来应对突发情况，但是这个策略很明显有问题，如果另外的响应也错了怎么办？，所以书中没有考虑这个策略

加一堆校验码，让NAK，ACK拥有自我救赎的能力（自己把自己纠正过来，即使错了），可行，但是划不来，新的校验数据无疑会增大报文的体积，减低传输的效率

冗余报文响应（这个名字是我按照我的理解起的，建议以书为标准 - 重发）：故名思义

graph LR
ACK不合法 --> 重发
NAK不合法 --> 重发
NAK拒绝 --> 重发
重发 --> 直到格式合法了数据正常了

Rdt 2.1

从发送端入手，虚线部分：

发送端先是不管三七二十一把数据封装起来了，然后填上了0标志位和校验和发送到发送端，自己进入等待状态。

此时接收到来自发送端的数据，接收端也从等待状态进入到wait for 1 from below, 并且向发送发抛出了一个数据，内部有ACK，表示接受

如果接收方接受到了这个完整的ACK，那么就是Rdt2.0的节奏了，这里假设ACK错了，不合法，由于接收方接收到了一个不合法的数据，那么自然就重发

此时接收方还在等待1状态，一检查，发现发送发又给我发了一份数据，那我没办法啊，只能又发一个ACK回去，

如此往复直到发送方接收到数据之后，状态转移，向接受发发送了一个带有1的报文，若接受方也能接受，那么就皆大欢喜了

接受方和发送方都回到了最初状态了，一次传递结束了！！！

很容易不是吗？

注意点：发送发和接收方都在考验彼此，一旦对面的数据给的不合法，或者发现了错误，就会通知对方，让对方重发一次，直到双方通信完成，状态回到初始态时候终止。

也许你会问，那这种等待，想Rdt2.0 那样不是也行吗？为啥得这样做呢，这么多状态，不会眼花吗？

其实这两个状态是有道理的，

Rdt2.0 中接受方只有一个状态，就是初始态，但是初始态无法辨识当前接收方是否出现了问题，所以必须给接收方多安排一个状态。

如此发送方也必须调整一下，

发送方从 0 - 1 - 0

接收方也从 0 - 1 - 0

当其中一方或者几方处于1状态时，必然意味着出现了意外状况，就可以实现干预了。

Rdt2.2

Rdt2.2 的思想与Rdt2.1 是相同的，只是简化了步骤，其实根本不需要发NAK，只需要发ACK，区别在于带上不同的标志以区分不同的阶段

graph LR
NAK --> ACK_0
NAK不合法
ACK --> ACK_1

如此就简化了既要判断ACK，又要判断NAK的复杂场面，

只要报文不合法就重发，只要ACK 带的值不是我想要的，你也得给我重发！！