计网基础-传输层之可靠数据传输rdt
现实中，很多的信道，其实是不可靠的。
什么是可靠？不错、不丢、不乱。
可靠数据传输协议
1、可靠数据传输对应用层、传输层、链路层都很重要
2、网络前十大问题之一
3、信道的不可靠特性决定了rdt的复杂性
可靠数据传输可以从不同的角度理解，
以下是从提供的服务来看：
（a）provided service
红线上：应用层，发送进程和接收进程
红线下：传输层，提供可靠数据传输服务
注意，理论上底层提供的信道传输服务是安全可靠的，但在实现中并不是
以下是从服务的实现来看
（b）service implementation
注意，此时底层是一个不可靠的信道，unreliable channel
rdt基本结构
1、rdt_send()：单向，说明上层调用下层之后就不管了
2、udt_sen()：双向，对于不可靠信道传输需要控制数据流动
3、rdt_rcv()：双向，对于不可靠信道传输需要控制数据流动
4、deliver_data()：单向，说明底层接收方的传输协议把所有的工作做好之后，才把数据正确的交付给上层
注意，以下各rdt版本中只考虑单向数据传输，但控制信息是双向流动的，
并且，利用状态机FSM（状态、事件、活动，状态在圆圈里，事件在线上，活动在线下）刻画传输协议
rdt1.0可靠信道上的可靠数据传输
注意，由于100%可靠，所以，只需发，无需控制，所以FSM有限状态机独立
rdt2.0产生位错误bit error的信道（只有该因素）
底层信道可能产生位错误
问题：接收方要知道收到分组错没错？如果错了得想办法重传？或者恢复？
解决：告诉接收方，合作处理
（1）检测位错误：udp的校验和方法
（2）从错误中恢复
ACK：acknowledgements
NAK：NegativeAcknowledgment
注意，基于上述（1）和（2）的重传机制的rdt协议称为ARQ（Automatic Repeat reQuest）
rdt2.0引入的新机制：差错检测（1）、接收方反馈控制信息（2）、重传（2）
FSM：
注意，发送方一个状态wait for call from above不够了，需要加一个等待对方（接受方）控制消息的状态wait for ack or nak；另外，在接收方仍为一个状态，但是增加了一个事件，判断收到的是否分组发生错误，可以使用udt_send(NAK)或者udt_send(ACK)发送给发送发
rdt2.1、2.2
rdt2.1：
发现rdt2.0的缺陷：当ACK或者NAK出错发送方是无法处理的，
因此加入新的机制，那就是序列号机制。
rdt2.2：
将NAK去掉（不需要），用ACK确认最后的一个分组，可以代替它
rdt3.0信道既会发生错误，也可能会丢失分组
当发送的过程中丢包了，发送方则一直等待和接收方没有反应
当发送方发送的数据到了接收方，发过来的ACK丢了
…