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): 往返时延，在计算机网络中它也是一个重要的性能指标，它表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延;