Rdt1.0：（理想化）
假定底层信道完全可靠：
不会发送错误（bit eror）：传输中1,0可能会变换
不会丢弃分组
发送方和接受方得到FSM独立，不需要纠错信息的交互
调用事件/活动
Rdt2.0：（引入不可靠信道-->产生位错误的信道）
产生错误时，和发送方信息交互，重新发送正确的数据包
底层信道可能翻转分组中的位（bit）
如利用校验和检测位错误
如何从错误中恢复？
确认机制（Acknowledgements，ACK）：接受方显式地告知发送当分组以正确接收
NAK：接收方显式地告知发送方分组有错误
发送方收到NAK后，重传分组
Rdt2.0缺陷：
如果ACK/NAK消息发生错误/被破坏？
1.为ACK/NAK增加校验和（成本大）
2.发送方增加额外的控制消息，（消息也可能坏掉）
3.如果ACK/NAK坏掉，发送方重传
不能简单的重传：产生重复分组
如何解决重复：
增加序列号：发送方给每个分组增加序列号，接收方丢弃重复的分组
Rdt2.1和2.2：（信道不可靠，ACK/NAK损坏）
发送方：
接收方：
如果接受方接受的包没有被损坏，但是跟预期的序列号不同？
发送的（0，1）基于平等协议
Rdt2.2：无NAK消息协议，只使用ACK
如何实现？：接收方通过ACK告知最后一个被正确接收的分组
在ACK消息中显式地加入被确认分组的序列号
发送方收到重复ACK之后，采取与收到NAK消息相同的动作
重传当前分组
Rdt 3.0：
如果信道既可能发生错误，也可能丢失分组，怎么办？
“校验和+序列号+ACK+重传”不够用
方法：发送方等待“合理”的时间
如果没有收到ACK。重传
如果分组或ACK只是延迟而不是丢了（重复，序列号机制能够处理，接收方需要在ACK中显式告知所确认的分组）
需要定时器
机制1;
机制2：
Rdt3.0性能分析：
Rdt3.0能够正确工作，但性能差，网络协议限制了物理资源的利用。
