1. 可靠数据传输协议的前世今生第一次接触可靠数据传输协议Reliable Data Transfer简称rdt是在十多年前的一个网络编程项目里。当时为了确保数据能准确无误地传输我翻遍了各种资料最终在《计算机网络自顶向下方法》这本书中找到了答案。rdt协议就像网络世界的快递员负责把数据包裹安全送达目的地。简单来说rdt协议要解决的核心问题是如何在不可靠的底层信道上实现可靠的数据传输。想象一下你给朋友寄快递可能会遇到包裹损坏比特差错、快递丢失丢包等问题。rdt协议就是一套确保对方能完整收到快递的解决方案。从rdt1.0到rdt3.0的演进过程就像快递服务的升级史rdt1.0假设快递永远不会丢也不会坏理想情况rdt2.0发现快递可能会损坏增加了验货和退换机制rdt3.0不仅考虑损坏还预防快递丢失加入了超时重发功能2. rdt1.0理想世界的简单协议2.1 基本假设与工作原理rdt1.0建立在一个美好的假设上底层信道完全可靠。就像在一个永远不会丢件、包裹永远完好的快递系统中协议设计变得异常简单。发送端的工作流程等待上层应用传来数据将数据打包成分组packet把分组扔进信道继续等待下一个数据接收端的工作流程从信道接收分组解包取出数据把数据交给上层应用继续等待下一个分组2.2 有限状态机解析发送端FSM只有两个状态等待上层调用rdt_send(data)等待发送udt_send(packet)接收端FSM更简单等待下层调用rdt_rcv(packet)这个版本虽然简单但在实际网络环境中几乎无法使用因为现实世界的网络信道总是存在各种问题。记得我第一次实现rdt1.0时数据传输成功率低得可怜这才意识到现实网络有多残酷。3. rdt2.0应对比特差错的解决方案3.1 校验和与确认机制rdt2.0开始面对现实信道可能存在比特差错。就像快递包裹可能在运输过程中被损坏我们需要一套验货机制。关键技术改进校验和checksum给数据加上防伪码接收方可以验证数据完整性ACK/NAK机制接收方通过确认(ACK)或否认(NAK)反馈给发送方发送端新增了等待ACK的状态发送数据后进入等待状态收到ACK继续发送下一个数据收到NAK重传当前数据3.2 状态机详解发送端FSM新增状态等待ACK或NAK如果收到NAK就重传接收端FSM也变得更复杂检查数据是否正确正确则发送ACK错误则发送NAK我在实际项目中遇到过一个问题ACK/NAK本身也可能在传输中出错。比如ACK变成NAK导致发送方错误重传。这就是rdt2.0的致命缺陷。4. rdt2.1与rdt2.2确认机制的优化4.1 序列号机制的引入rdt2.1通过引入序列号sequence number解决了ACK/NAK受损的问题。就像给每个快递包裹编号即使退货单丢了也能通过编号确认是哪个包裹需要重发。关键改进点数据分组携带0/1交替的序列号接收方通过序列号判断是否是重复分组ACK也携带对应的序列号4.2 从NAK到带编号的ACKrdt2.2进一步简化完全移除了NAK通过ACK0和ACK1来隐式表达确认或否认发送方通过ACK编号判断是否需要重传实际编码时我发现这种设计大大简化了状态机的复杂度。发送方只需要检查ACK编号是否正确而不需要处理两种不同类型的反馈。5. rdt3.0应对丢包的终极方案5.1 定时器与超时重传rdt3.0面对最恶劣的网络环境既可能出错又可能丢包。解决方案是引入定时器发送分组后启动定时器超时未收到ACK就重传正确收到ACK就关闭定时器这就像快递员送件时开始计时如果太久没收到签收确认就默认快递丢失需要重新投递。5.2 发送端FSM的完整演进rdt3.0发送端状态机是最复杂的新增超时状态需要管理定时器的启动和停止处理可能的重复ACK我在实现时踩过一个坑忘记在收到正确ACK后停止定时器导致大量不必要的重传。正确的做法是每次状态转换都要明确定时器的操作。5.3 接收端的设计考量虽然很多资料没明确给出rdt3.0接收端FSM但根据协议逻辑它与rdt2.2接收端基本相同。因为丢包问题主要由发送方的定时器解决接收方只需确保正确识别重复分组通过序列号发送对应编号的ACK在实际网络编程中理解这些FSM的状态转换逻辑至关重要。我建议初学者可以手绘这些状态机标注每个转换的条件和动作这样能更直观地理解协议工作原理。