第三单元的协议能把字节重新拼成消息，也能让回执沿另一条消息路径返回。今天我们每天使用的通信系统，在这个起点之外又安排了什么？
预计用时：45 分钟。这里给出实现路线与选择依据；课程里的失信通道仍是同一进程中的教学模拟。
以浏览器提交一条任务为例，一条常见路线是：应用形成对象，序列化成请求，通过已建立的连接传给服务，服务解析后执行数据库事务，再生成响应。第一次联系服务还可能涉及名称解析、连接建立与安全协商；已有连接可能复用，所以每次点击不一定重新经历全部步骤。
应用关心“这是哪条任务”；传输层关心如何交付数据；网络层关心如何把数据送往目标；链路负责相邻节点间的传递。分层允许更换某层的实现，同时保持上层一部分约定。但上层的成功不能仅由下层替它证明。
第三单元的 reply_to 关联一条应用消息。TCP 确认的数据到达状态，不会替代“这笔业务已经提交”的确认。即使网络传输可靠，服务也可能在收到请求之后、业务提交之前退出。
| 路线 | 提供的基础能力 | 应用仍需负责 |
|---|---|---|
| TCP 上的字节流 | 在连接有效等条件下提供有序、可靠的字节交付语义 | 消息边界、业务结果、连接恢复后的请求去重 |
| UDP 数据报 | 保留数据报边界，机制较少 | 按用途处理丢失、乱序、拥塞与消息大小 |
| QUIC | 基于 UDP 的安全传输协议，提供多条流等能力 | 业务确认、权限、应用重试与处理语义 |
| HTTP 请求/响应 | 方法、状态、头与内容的共同约定 | 某个业务接口的实际承诺 |
| 消息代理或持久队列 | 生产者与消费者之间的缓冲、分发及配置相关的持久性 | 消费者何时确认、重复处理、副作用与积压 |
HTTP/1.1、HTTP/2 和 HTTP/3 的传输组织不同；HTTP/3 使用 QUIC。QUIC 的独立流可以避免不同流之间因为同一处传输丢失而全部受同样的有序字节流阻塞，但仍共享带宽、拥塞控制等资源。一句“更先进所以总是更快”不足以做选型。原始协议可查 RFC 9000：QUIC。
设想客户端请求扣减库存：请求到服务，数据库提交，响应途中连接断开。客户端只知道没有得到确认。重连解决了“重新有一条通道”，还没有解决“该不该再扣一次”。
这时第一章的操作编号仍然有用：重试保留同一编号，服务把编号、输入和业务结果放在能维护其约束的存储中。若业务还要跨多个服务，单库事务的范围已经不够，需要补充消息推进、补偿或其他协调协议，并明确可能暴露的中间状态。
持久队列也要回答同样的问题。消费者处理成功后、发出确认前退出，消息可能再次交付；若先确认再处理，又可能在处理前退出而丢掉业务动作。把重复检测与本地业务提交放进同一边界，是一条常见路线，但跨外部副作用时要重新分析。
长度字段解决边界；普通哈希帮助比较内容；带密钥的认证机制帮助验证来源或完整性；加密帮助保护机密性。它们不能互换。
现代网络常用成熟的 TLS 等机制建立受保护的通信。连接的身份与应用账户仍有区别：你联系到了正确的服务，并不意味着当前用户可以读所有记录。把权限检查放回数据访问处，才能连接第一章的对象边界与信任要求。
完成一份两页以内的路线说明，选择“离线日记”“多人任务表”或“通知服务”之一。第一页画出数据落点、变化如何到达页面、请求与回执如何经过通道；第二页记录三种故障及恢复动作。
复核者应能沿一次具体操作走完全程。至少明确：某个“成功”由谁发出，依据是什么；采用的现代机制解决哪项新要求；多付出了什么存储、通信或维护成本。若只是列技术名字，还需要补一次数据的旅程。
这三节描绘的是并存的演进路线：文件、数据库、复制，刷新、流式更新、协作，字节流、多路流、队列。它们由不同用途推动，无法排成唯一的升级阶梯。现有最小实验仍是可以逐行核查的起点，扩展系统需要自己的验证。
我们已经能问清一项系统保证。接下来要问：它究竟花了多少工作？为什么有时增加代码、增加中间步骤，反而得到更好的计算？
进入 第二章：同一个答案，为什么要绕这么远？。让数据的旅程继续缩小到一台机器内部。