可靠数据传输（rdt）的原理★★ ★ ★ ★

background：

rdt在应用层、传输层和数据链路层都很重要

是网络Top 10问题之一

信道的不可靠特点决定了可靠数据传输协议（ rdt ）的复杂性

rdt所要面临的问题(也是人面临的问题) ：

==在下层提供的服务不可靠的情况下，本层的协议机制、协议实体要通过哪些时空资源的安排、要靠哪些机制的安排，要向上层提供可靠的服务。==

可靠数据传输：问题描述

图片中的

rdt_send() 和 deliver_data( ) 是本层和上层的接口

udt_send() 和 udt_rcv( ) 是本层协议实体跟下层的原语的形式

原语：上层使用下层服务的形式

底层的可靠性与否决定了上层rdt的复杂性。

逻辑的理解过程：

渐增式地开发可靠数据传输协议（ rdt ）的发送方和接收方
只考虑单向数据传输 - 但控制信息是双向流动的！
双向的数据传输问题实际上是2个单向数据传输问题的综合
使用有限状态机 (FSM) [描述协议工作状态的转移之类的]来描述发送方和接收方

Rdt1.0：在可靠信道上的可靠数据传输

下层的信道是完全可靠的

没有比特出错
没有分组丢失

发送方和接收方的FSM

发送方将数据发送到下层信道
接收方从下层信道接收数据

发送方发送package
接收方接收后，校验是否出错，如果不出错那么就发送一个控制报文（ACK），发送方就不用做什么了
如果出错，那么就发送一个控制报文（NCK）, 然后发送方再将副本传输过去（检错重传）

Rdt2.0：具有比特差错的信道

Rdt1.0 的问题：

下层信道可能会出错：将分组中的比特翻转。可以用校验和来检测比特差错
怎样从差错中恢复：

Rdt2.0 的改进：

采用差错控制编码进行差错检测

发送方差错控制编码、缓存
接收方使用编码检错
接收方的反馈：控制报文（ACK，NAK）：接收方->发送方
发送方收到反馈相应的动作

有限状态机（FSM）描述：

发送方发送package
接收方接收后，校验是否出错，如果不出错那么就发送一个控制报文（ACK），发送方就不用做什么了
如果出错，那么就发送一个控制报文（NCK）, 然后发送方再将副本传输过去（检错重传）

Rdt2.0：没有差错时的操作

rdt2.0：有差错时

rdt2.0的致命缺陷！-> rdt2.1

如果ACK/NAK出错？发送方该如何？

发送方不知道接收方发生了什么事情！然后也不知道如果操作

如何处理：

引入新的机制：序号（有点麻烦，因为要发送两次确认是否重复）

发送方在每个分组中加入序号
如果ACK/NAK出错，发送方重传当前分组
接收方丢弃（不发给上层）重复分组

如果发送方出错：

停止等待协议： 发送方发送一个分组，然后等待接收方的关于这个分组的应答

如果ACK/NAK出错，接收方如何处理？

必须检测接收到的分组是否是重复的

注意：接收方并不知道发送方是否正确收到了其ACK/NAK

发送方：

在分组中加入序列号
两个序列号（0，1）就足够了
- 一次只发送一个未经确认的分组
必须检测ACK/NAK是否出错（需要EDC ）
状态数变成了两倍
- 必须记住当前分组的序列号为0还是1

接收方：

必须检测接收到的分组是否是重复的

状态会指示希望接收到的分组的序号为0还是1

注意：接收方并不知道发送方是否正确收到了其ACK/NAK

没有安排确认的确认

如果说本次发送出错了。然后接收方就给出 nak，但是发送方没有停止等待继续发送错误的，因为要实现重复校验，所以发送方将下一次的data发送过去了，结果就是接收方需要0 ，但是你发送了个1。

所以上述的问题还是难以解决。我们就需要引入2.2

rdt2.1的运行

接收方不知道它最后发送的ACK/NAK是否被正确地收到

发送方不对收到的ack/nak给确认，没有所谓的确认的确认；
接收方发送ack，如果后面接收方收到的是：
- 老分组p0？则ack 错误
- 下一个分组？P1，ack正确

rdt2.2：无NAK的协议

*功能同rdt2.1，但只使用ACK(ack 要编号）*
接收方对最后正确接收的分组发ACK，以替代NAK
接收方必须显式地包含被正确接收分组的序号
当收到重复的ACK（如：再次收到ack0）时，发送方与收到NAK采取相同的动作：重传当前分组
为后面的一次发送多个数据单位做一个准备
- 一次能够发送多个
- 每一个的应答都有：ACK，NACK；麻烦
- 使用对前一个数据单位的ACK，代替本数据单位的nak
- 确认信息减少一半，协议处理简单