可靠数据传输原理
可靠数据传输的实现问题在应用层，运输层，网络层，链路层普遍存在，本节在一般情境下讨论可靠数据传输。
为上层实体提供的服务抽象：数据可通过可靠信道传输。
可靠信道
1.不错 数据流中的比特不会反转
2.不乱 所有数据包按其发送顺序交付
3.不丢 数据包不会丢失
可靠数据传输协议设计
- 渐进地设计可靠数据传输协议的发送方和接收方
- 只考虑单向数据传输，但控制信息双向流动
- 利用状态机刻画传输协议
接口
可靠数据传输协议基本结构.png
Rdt 1.0——底层信道完全可靠
假定
- 底层信道完全可靠，即底层信道不错，不乱，不丢
状态机
发送方.png
接收方.png
Rdt 2.0——底层信道可能有位错误
假定
- ！底层信道可能翻转分组中的位，但假定接收方的反馈报文不会发送错误
- 底层信道不乱不丢
应对机制
差错检测
一种使得接收方可以确认分组是否含比特差错的机制
- 利用校验和检测位错误
- ACK:接收方显式通知发送方分组已正确接收
- NAK:接收方显式通知发送方分组存在差错
差错恢复
- 发送方得知分组出错后（收到NAK），重传分组
- 基于这种重传机制的rdt协议称为自动重传请求协议（Automatic Repeat reQuest,ARQ）
停—等协议
发送方发出一个分组后，等待接收方的反馈（ACK或NAK），在等待状态下，发送方不会发出新的分组
新机制
- 差错检测
- 接收方反馈控制消息: ACK/NAK
- 重传
状态机
发送方.png
接收方.png
Rdt 2.1——接收方反馈可能受损
假定
- ！底层信道可能翻转分组中的位，特别的，接收方的反馈报文也可能发生错误
- 底层信道不乱不丢
应对机制
差错检测
- 为ACK/NAK增加校验和
差错恢复
- 发送方收到受损的接收方反馈报文后，重传当前分组
冗余分组问题
- 发送方对受损ACK或NAK直接重传分组的策略，引入了冗余分组，为处理冗余分组：
发送方对分组编号，接收方记住上一个收到的分组编号，此处只需{0,1}编号；
接收方收到重复的分组时，丢弃分组并发送该分组的ACK；
新机制
- 增加了对反馈报文的差错检测机制和差错恢复机制
- 引入了冗余分组问题
- 为每个分组增加了序列号{0，1}
状态机
发送方.png
接收方.png
Rdt 2.2——无NAK消息协议
假定
同Rdt 2.1
- 底层信道可能翻转分组中的位
- 底层信道不乱不丢
目标
- 在设计上消除反馈报文NAK以实现简化
新机制
- 取消NAK
- 接收方在反馈报文ACK中加入对应分组的编号
-
冗余ACK策略
接收方收到错误分组i+1后，发送一个对分组i的ACK;
发送方收到对分组i的两个ACK后，可断定接收方没有正确接收分组i+1,故应重传分组i+1
状态机
状态机片段
Rdt 3.0——底层信道可能丢失分组
假定
- 底层信道可能翻转分组中的位
- ！底层信道可能丢失分组
- 底层信道不乱，即分组被按其发送顺序接收。
关注点
- 如何检测丢包，丢包发生后如何处置
丢包检测与恢复
- 发送方等待合理时间，若该时间内未收到ACK,则重传分组
可能的情况：
- 发送方发送的数据分组丢失
- 接收方发送的ACK分组丢失
- 数据分组或ACK分组传输的时延过长
冗余
- 接收方发送的ACK分组丢失会引发发送方重传，其结果是接收方收到冗余数据分组
- 发送方发送的数据分组传输时延过长会引发发送方重传，其结果是接收方收到冗余数据分组
- 接收方发送的ACK分组传输的时延过长会引发发送方重传，其结果是发送方收到冗余ACK
以上冗余状况都可以依靠分组编号机制解决
状态机
发送方.png
分析
Rdt 3.0能够正确工作，但性能很差
原因在于停等机制，大部分的时间发送方都在等待对上一个分组的确认
由于停等机制，信道上的分组几乎不可能乱序，故rdt3.0是可以实际工作的，问题在于效率过低
