摘要

  • BTPU 面向无法回传重传请求的单向链路，允许发送方在不同链路层 PDU 中重复完全相同的消息。
  • Transfer End 只给出最后一个分段索引；接收方必须实际拿到 0..N 的全部分段，才能在本地认定传输完整。

发送器把同一块数据一次次推入只能向前的链路。副本增加了机会，但没有一个副本会回头报告结果。9 月 7 日发布的 draft-ietf-dtn-btpu-04，正是为不可靠、基于帧的单向链路设计的大型二进制对象传输机制；它通常承载 BPv7 Bundle，也不要求 IP 服务。

协议把“接收完整”定义得很窄。属于同一 Transfer 的分段共用一个 32 位编号，Segment Index 从零递增。Transfer End 携带最后一个分段及其索引 N。只有当接收方拥有 0..N 全部索引并完成拼接，才会把重组后的 Bundle 交给上层继续处理。

这条规则没有越过观察边界。发送方发出 Transfer End，不等于接收方看到它；接收方看到结尾，也不能补回此前丢失的分段；完成重组，更不等于 BPv7 解析、CRC 或 BPSec 校验通过。上层接受之后，转发、端点交付与应用确认仍各有自己的记录。

BTPU 不伪造反馈，而是公开使用冗余。任何消息都可重复，但重复件必须是已经发出消息的精确副本。不同分段可采用不同次数；离线链路分析、本地可靠性等级或带外信号都可能影响策略。草案没有声称三次、十次或任何固定次数能在所有环境保证成功。

滑动 Transfer Window 也只是状态边界。它限制同时进行的编号范围，在 32 位编号回绕或短时失去信号后帮助辨别新旧状态。窗口大小必须带外配置；草案暂时建议 16，同时明示这个数字仍需工作组讨论。状态因超出窗口被丢弃，只说明接收方如何管理内存，不能证明业务义务已完成。

BTPU 重复、链路层冗余与纠删码同样不能揉成一个“可靠性”数字。可选的 Bundle Length Hint 只是帮助预留内存；期望长度不是已收到的字节。协议本身也不保护消息，安全要由下层或 BPSec 等上层提供，而完整性仍不等于交付。

部署章节写出了最重要的限制：BTPU 不可靠，也没有适合确认传输成功的带内返回路径。任何确认系统都必须经由一条逻辑上独立的接收方到发送方路径。协议还不提供拥塞控制；若底层没有相应能力，就不能把它部署到可能拥塞的公共互联网。

来源