模块二 · 运输层
从零构造可靠传输协议
如果数据会损坏、丢失或重复，怎样让接收方按顺序交付一次？先推导需要的机制，后面的章节再学习TCP具体怎样实现。
本章要解决的问题：如果数据会损坏、丢失或重复，怎样让接收方按顺序交付一次？先推导需要的机制，后面的章节再学习TCP具体怎样实现。
本章的证据来源：教材§3.4，纸书131–148页。本轮在本机原始笔记工程找到并阅读了rdt-sim脚本及已有输出，核对了模型、计时和随机种子；本次未重新运行，网站未打包这些附件，数字不作为一般性能结论。
先从一个例子理解概念
发送方要把“第一张、第二张、第三张”图片交给接收方。如果第二张丢了，接收方不能把第三张误当作第二张；如果第二张被重发两次，也不能向应用交付两份。
可靠交付与编号
可靠交付的目标是在约定模型中处理损坏、丢失和重复等问题，向上层提供正确、有序、非重复的数据。序号帮助接收方识别当前数据与重复数据。
讨论可靠性时必须给出通道条件。如果通道永远不恢复，协议无法凭空交付数据。真实TCP可能以错误结束连接，不能承诺所有内容在任何故障下最终都送达。
确认、超时与重传
ACK（确认）是接收方发回的反馈。超时是等候超过设定时间仍无所需确认；重传是重新发送。没有确认不唯一意味着数据丢了，也可能是ACK丢失或迟到。
第一步：先说清模型
教材逐步放宽假设：先考虑理想通道，再引入比特损坏，随后考虑数据或ACK丢失。检错码、反馈、序号与计时器随问题逐步引入，不需要学生先背TCP。
本章把“序号”定义为教学中的段编号。后面的TCP则按字节编号，不能把两种ACK约定直接混用。
原脚本设10段、单向延迟5 tick、两个方向丢失概率20%、超时22 tick、窗口4，每次种子为1000+i，重复200次。它没有有限链路的序列化发送成本，可在同一tick发送多个段；有反馈策略受4000 tick运行上限限制，无反馈策略则固定在7 tick停止，即使数据不完整。
不做反馈：有数据缺失的风险
在只考虑独立数据丢失、每段到达概率0.8的模型中，10段全部到达的概率为：
0.8^10 ≈ 10.7%旧稿称200次模拟中成功率10.5%。这个样本比例与理论值接近，最多说明它没有明显偏离这个简单预测；不能证明模型或代码正确，也不能说不存在随机波动。
10.7%还依赖独立性等假设。若丢失成串相关、发生损坏或乱序，不能直接套同一个表达式。
加ACK和重传：为何还需要序号
发送段2 → 接收方收到并交付
返回ACK → ACK在途中丢失
发送方超时 → 再发段2如果接收方无法识别重复，就会把段2再次交付。序号使它知道“这是已交付的旧段”，不重复交付，同时重新反馈确认。
停等让发送方一次只等待一个未确认数据单元。简化交替比特协议还需约定初始状态、确认语义和通道条件；处理损坏时也要检错，不是只加一个序号就解决所有问题。
正确设计在这些模型条件下可以保持交付不重复等性质，但有限次模拟“100%成功”不是证明。有限重试、永久断路或未处理的错误会影响最终交付。
加流水线：为什么一个段在途可能不够
流水线允许多个尚未确认的数据单元在途；窗口限制可以同时存在的数量。
在RTT相对单段发送时间很大时，停等需要反复等往返，发送链路可能大段时间空闲。加窗口有助于利用容量，但真实吞吐还依赖速率、窗口、丢失与拥塞等条件，不能只说“停等永远慢34倍”。
之前学习的目标吞吐量×RTT，正好提示持续发送需要多少未确认数据。后续《滑动窗口与流量控制》再解释TCP窗口的具体限制。
回退N步与选择重传
累积确认在本章段编号约定中，用ACK n表示0到n均已按序接收。TCP确认号采用“下一个期望字节”的约定，后续再学。
| 协议模型 | 接收方 | 超时后的发送方行为 |
|---|---|---|
| 回退N步（GBN） | 只接受按序段，丢弃乱序段，给累积确认 | 从最早未确认段起重传相应未确认段 |
| 选择重传（SR） | 在接收窗口内缓存乱序段，分别确认 | 重传相应未确认或超时的段 |
GBN中“某段到过接收方”不等于“已被保存并交付”，它可能作为乱序段被丢弃。SR通常可以减少这类重复发送，但需额外状态、缓存、计时及序号空间约束。
TCP仍使用累积确认；SACK可补充接收方已收到的字节区间信息。TCP不是直接等同于教材的SR协议，也不是把“累积确认”和“逐段确认”二选一。
历史模拟数字怎么读
以下为旧稿转述，本次未重新运行：
| 策略 | 旧稿完成时间/tick | 旧稿平均发送段数 | 旧稿成功比例 |
|---|---|---|---|
| 无反馈 | 7.0 | 10.0 | 10.5% |
| 停等 | 241.9 | 15.7 | 100.0% |
| GBN | 102.5 | 18.4 | 100.0% |
| SR | 106.6 | 15.7 | 100.0% |
脚本将包括不完整传输的停止时间一起求平均。无反馈的7 tick不是可靠完成同一任务的时间，所以不能与停等比较“慢34倍”。不同策略虽从相同初始种子出发，随机数消耗路径仍不同；没有序列化成本时，也不能把多发几个段解释成提高真实链路利用率。102.5与106.6的差别不能证明GBN普遍更快，需要合理模型与统计比较。
代码自检应同时检查交付顺序、重复、丢失、ACK语义、计时器及终止条件。发现不符合模型预期的结果，应检查实现和模型假设，不能简单宣布“正确率不是100%，所以必有某一个指定bug”。
后续如何对应到TCP
| 本章问题 | 后续机制 |
|---|---|
| 识别数据与重复 | TCP字节序号 |
| 表达已按序收到 | 累积确认号 |
| 等不到确认时恢复 | 重传超时及相关恢复机制 |
| 允许多个未确认字节 | 发送窗口 |
| 补充已收到的非连续区间 | SACK选项 |
可靠传输、流量控制、拥塞控制解决不同问题：正确交付、接收方承受能力、网络承受能力。实际TCP中三者协同工作，不能说互不影响。
本章小结
| 结论 | 条件 |
|---|---|
| 序号、ACK、检错与计时器对应具体通道问题 | 按教材模型逐步引入 |
| 0.8^10约10.7% | 10次独立数据到达、没有其他失败因素 |
| 样本比例接近理论不能证明实现正确 | 有限次模拟有波动 |
| 停等在大RTT/发送时间比下可能利用率低 | 需明确模型速率与时序 |
| GBN与SR在确认、缓存与重传策略上不同 | 不能由一次模拟得出通用快慢排序 |
| TCP字节序号和SACK与教材段编号模型有区别 | 后续学习具体标准 |
| 已核对代码和存档，未重新运行，不预测真实TCP性能 | 无序列化成本，停止时间包含失败样本 |
自测题
7 题 · 先自己答，再展开对照
ACK丢失后，为什么需要序号？
数据可能已交付而ACK丢了，发送方超时重传。序号帮助接收方识别已交付数据、避免重复交付并再次确认。停等什么时候可能利用率很低？
当一次往返比单段发送时间长得多，一次只允许一个未确认段，会花很多时间等待。不是每个场景都同样慢，还需速率、包长和RTT等条件。累积确认有什么作用？本章ACK n与TCP确认号是否同一约定？
较新的累积确认可覆盖较旧确认的丢失。本章ACK n表示已收到至段n；TCP确认号表示下一个期望字节，不能直接混用。一次模拟SR完成时间比GBN稍长，能证明GBN通常更快吗？
不能，需要复核实现、随机样本、相同条件和统计误差。SR可减少某些不必要重传，但整体完成时间还受模型参数和实现影响。200次模拟与理论值接近、或都成功，能证明协议实现完全正确吗？
不能。接近理论只说明该样本不明显偏离预测，有限成功运行不能验证全部状态或证明永远完成；还需推导、边界与模型检查。可靠传输、流量控制与拥塞控制分别解决什么？
可靠传输处理数据正确、有序、非重复交付；流量控制避免接收方承受不了；拥塞控制避免过度压迫网络。三者目标不同，但共同影响实际传输。模拟出现不符合预期的交付错误，应该检查什么？
同时检查模型条件、序号和接收状态、重复交付、ACK语义、计时器、重试限制及停止条件。永久断路与实现错误都要区分，不能预设只有一个原因。
参考资料与适用范围
- 《计算机网络：自顶向下方法（原书第8版）》§3.4.1–3.4.4，纸书131–148页（PDF150–167页）：可靠传输模型、停等、流水线、GBN与SR。
- RFC 9293 §3.3：TCP字节序号与确认
- RFC 2018 §1–3：TCP选择确认提供已收到的区间
修订核对日期：2026-10-13。原脚本和输出已作静态核对，数值仍是未在本次重新运行的历史观察，性质为模拟而非真实链路测量。模型里的可靠性论证须包含通道、检错、时序与故障假设。