可靠数据的传输（2） 笔记

Rdt2.1和2.2Rdt2.0有什么缺陷？

如果ACK/NAK消息发生了错误/被破坏（corrupt）怎么办？ 1为ACK/NAK加checksum，检验并纠错 2发送方收到被破坏的ACKACK消息发生了错误/被破坏（corrupt）怎么办？
1为ACK/NAK加checksum，检验并纠错
2发送方收到被破坏的ACK/NAK时不知道发生了什么
3如果ACK/NAK坏掉，重传，会累赘了。重复分组了

如何解决重复分组问题？
1加一个序列号（sequence number）：发送方给每个分组加一个序列号 2接收方抛弃重复分组

有两个序列号0和1，发完了序列号为0的分组之后，等待ACK/NAK，坏掉或者NAK重发
接收方

收到一个分组，如果坏了，发一个NAK。。。收到一个分组，没有坏掉，但是收到的序列号是0，想要1，发ack

发送方 0 1 两个序列号就够用了，采用了停等协议，需要校验ACK/NAK是否错误，状态数量翻倍，状态必须记住当前的分组号。

无NAK消息协议

可以在ack消息中显式地加入被确认分组的序列号，发1返0错了重传。

Rdt3.0

如果信道既可能发生错误，也可能丢失分组，怎么办？
发送方等待“合理”时间，如果没有收到ACK，就重传。如果分组或ACK只是延迟而不是丢了，重传会产生重复，序列号机制能够处理重复问题。接收方需要在ACK中显式告知所确认的分组。
需要一个定时器

发送方发送一个packet之后会启动定时器，进入停等，会触发超时event。正确接收转入1状态。。。

未发生丢包情况


ack1丢了，会重传pkt1，重复丢掉一个。
ack1没丢但是定时器设置很短，收到之前就超时了，会重发一个pkt1，

性能分析

1Gbps链路，15ms端到端的传播延迟，1KB分组

协议必须和物理资源相匹配，软硬件的协同设计

产生的原因就是停等操作
RTT(Round-Trip Time): 往返时延，在计算机网络中它也是一个重要的性能指标，它表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延;