3.4-可靠数据传输的基本原理
可靠数据传输原理
什么是可靠
- 不错、不丢、不乱
可靠数据传输协议
- 可靠数据传输对应用层、传输层、链路层都很重要
- 网络Top-10问题
- 信道的不可靠特性决定了可靠数据传输协议（rdt）的复杂性
a-> 从服务的调度看
- 底层提供了一个可靠的信道
b-> 从服务的实现看
- 发送方
- rdt_send()：被上层应用调用，将数据交给rdt以发送给对方
- udt_send()：被rdt调用，在不可靠信道上接收对方传输数据
- 接收方
- deliver_data()：被rdt调用，向上层应用交付数据
- rdt_rcv()：当数据包到达接收方信道时被调用
可靠数据传输协议发展
渐进的设计可靠数据传输协议的发送方和接收方
只考虑单向数据传输
- 但控制信息的双向流动
利用状态机（Finite State Machine，FSM）刻画传输协议
Rdt 1.0：可靠信道上的可靠数据传输
假定底层信道完全可靠
- 不会发生错误（bit error）
- 不会丢弃分组
发送方和接收方的FSM独立
Rdt 2.0 产生位错误的信道
底层信道可能翻转分组中的位（bit）
- 利用 校验和 检测位错误
如何从错误中恢复
- 确认机制（Acknowledgements，ACK）：接收方显示地告知发送方分组以正确接收
- NAK：接收方显示的告知发送方分组有错误
- 发送方收到NAK后，重传分组
基于这种重传机制的rdt协议称为ARQ（Automatic Repeat reQuest）协议
即自动重传请求协议
Rdt2.0中引入的新机制
- 差错检测
- 接收方反馈控制消息：ACK/NAK
- 重传
思考：分组发送错误，接收方会返回ACK or NAK，如果返回的ACK or NAK发生错误，发送方会怎么办？
Rdt 2.0 缺陷
如果ACK or NAK发送错误
- 解决思路
- 为ACK/NAK增加校验和，检错并纠错（这里检错纠错仍有可能错误）
- 收到错误的确认信息不知道发生了什么，添加额外的控制消息（复杂）
- 如果ACK/NAK坏掉，发送方重传（简单方便）
- 简单重传：会产生 重复分组
如何解决重复分组问题
- 序列号（Sequence number）：发送方给每个分组增加序列号
- 接收方丢弃重复分组
Rdt 2.1
Rdt2.1 发送方逻辑
Rdt2.1 接收方逻辑
Rdt 2.2
对于Rdt2.1的思考
- 是否真的需要两种确认消息（ACK+NAK）
- 与rdt 2.1功能相同，但是只使用ACK
- 如何实现
- 接收方通过ACK告知最后一个被正确接收的分组
- 在ACK消息中显示地加入被确认分组的序列号
- 发送方收到重复ACK之后，采取与收到NAK消息相同的动作
- 重传当前分组
Rdt 3.0
信道既可能错误，也可能丢失
校验和+序列号+ack+重传 显然已经不够用了。
方法：发送方等待“合理”时间
- 如果没有收到ack，重传
- 如果因为延迟没有收到ack
- 重传会产生重复（序列号可以解决）
- 接收方需要在ack中显示告知所确认的分组
- 需要定时器
Rdt 3.0发送方FSM
执行示例
Rdt 3.0性能分析
- Rdt 3.0能够正确工作，但是性能很差
- 示例：1Gbps链路，15ms端到端传播延迟，1KB分组
T_{transmit} = \frac{L(packet\ length\ in bits)}{R(transmission\ rate,bps)} = \frac{8kb/pkt}{10^9b/sec} = 8\ microsec
- 发送方利用率：发送方发送时间百分比
U_{sender} = \frac{L/R}{RTT+L/R} = \frac{.008}{30.008} = 0.00027
- 在1Gbps链路上每30毫秒才发送一个分组->33KB/sec
- 网络协议限制了物理资源的利用
Rdt3.0 停等操作
