摘要

  • LTP 把一个数据块划成需要确认和重传的红色前缀，以及不确认、不重传的绿色后缀。颜色表示传输待遇，不表示内容的紧急度或业务优先级。
  • 发送会话完成只证明所有字节都已发送，且接收报告覆盖了整个红色部分；它不证明绿色部分完整到达，更不证明 Bundle 后续转发或目的应用已经消费。

一条完成消息里其实只有两个事实

设想一批遥测数据即将错过通信窗口。控制元数据必须可靠到达，大体积采样值允许少量缺失。客户端把前者放在红色前缀，把后者放在绿色后缀。几个小时后，发送端出现“session complete”。如果值班人员据此关闭“目的端已收到”的工单，系统就把链路内部回执提升成了端到端事实。

RFC 5326 对完成条件的描述很窄。第一，发送端知道整个数据块的所有字节已经进入实际发送流程；第二，一组接收报告足以证明非空红色前缀全部到达远端 LTP 引擎。绿色后缀不参与第二个条件。它可能全部到达、部分到达，也可能一个字节都没有到达。

同一个状态词因此会随红色长度改变含义。全红数据块的完成意味着整个块得到报告覆盖；红绿混合块只保证前缀；全绿数据块甚至可以在没有数据确认的情况下完成。缺少红色边界的“完成率”不是可靠性指标，而是把不同承诺混在一起的计数。

证据记录至少要包括总长度、请求的红色长度、实际分段后的红色长度、EORP 与 EOB 位置、各报告的覆盖区间、绿色分段到达通知，以及上层协议随后发生了什么。

颜色不是优先级，而是成本授权

RFC 5325 特别提醒，红色不等于更紧急。它只意味着客户端要求这些字节获得链路级确认与重传。哪些内容值得消耗能源、缓存、时隙和往返等待，是应用层作出的选择；LTP 负责忠实执行，不负责猜测内容价值。

红色必须是连续前缀，绿色只能是其后的连续后缀。单个数据分段不能混合两种颜色。当请求边界落在适合链路的分段中间时，实现可以把该分段剩余字节也按红色处理，以减少额外分段。这种“提升”扩大了实际保证范围，不能只保留配置中的理想边界。

协议还用颜色顺序检验一致性。如果接收端已在某一偏移看到绿色，之后又在更高位置看到红色，或在已知红色位置以下看到绿色，分段会被视为错误着色并触发取消。颜色决定可靠性合同的形状，不是展示层可随意替换的标签。

五种通知不能压成一个“已送达”

“初始发送完成”发生在原始红色和绿色分段都已经发送之后。此时丢失的红色分段仍可能等待重传。它只结束第一遍发送。

“红色部分接收”发生在接收端：EORP 已经确定红色长度，而且每个红色字节都在。通知还会说明红色末尾是否也是整个数据块末尾。对混合块而言，“不是”这一位正是边界证据。

绿色数据没有整体确认。接收端客户端针对每个绿色分段得到通知，其中包含偏移、长度以及是否到达 EOB。收到带 EOB 的最后分段，只能证明块的末端位置和该分段本身存在，不能填补之前的绿色空洞。

“发送会话完成”比初始发送完成更强：所有字节已发送，整个红色部分也已由报告证明收到。但它仍然不对绿色作出保证。取消通知则说明会话因对端、错误、重传上限或本地资源压力终止。规范明确指出，发送侧取消时，无法保证目的客户端收到数据块的任何部分。

这些通知由不同主体在不同时间产生。如果数据模型只保留“sent/delivered”，就再也回答不了：远端确认的是哪一段？绿色哪些偏移真正出现？红色重传是否结束？终止是正常闭合还是达到上限？

接收报告只在自己的区间内说话

检查点要求接收端出具报告。报告包含下界、上界以及该范围内已经收到的若干区间。范围以外不是“缺失”，而是该报告没有观察资格。把正向区间抽离边界保存，会让“未收到”和“未覆盖”变成同一种空白。

复杂状态可能需要多个独立报告。发送端对红色完整性的判断，是同一会话内相容区间的并集结论，而不是“看见一份报告”就算成功。百分比同样危险：95% 无法告诉审计者缺口是否包含关键头部，也无法揭示两份报告的边界是否冲突。

报告确认的对象也常被误读。确认分段只携带报告序列号，表示发送端已经收到那份报告，接收端可以停止重发报告。它不是接收端对数据的确认，更不是应用对内容的确认。证据的方向和对象必须一起保存。

超时的时钟由链路环境提供

在间歇链路上，从入队时刻连续计时没有意义。运行环境要告诉 LTP 引擎：向对端和从对端的通信机会何时开始、何时停止，单程光时是多少，预期速率是多少。检查点或报告的计时器在分段真正交给链路时启动，不是在应用提交时启动。

当已知远端停止发送时，相关计时器会暂停；下一个通信窗口出现时再继续。因此，一次超时既可能来自真实丢失，也可能来自过期的接触计划、错误的传播估计、队列信号延迟或正常的链路中断。

谁控制接触计划和这些信号，谁就部分控制协议何时认定尝试失败。若仪表盘只显示“remote timeout”，却不展示本地计划版本和暂停历史，它就在替本地控制者把责任推给远端。

LTP 的终点只是下一层的起点

LTP 引擎编号只在一个封闭通信集合中标识引擎。适配器可以把它映射到 Bundle 端点，但映射方式由实现决定。引擎编号不是自然人、机构、飞行器任务或最终应用的身份证明。

红色部分到达 LTP 客户端，只说明字节跨过了这一条 LTP 链路。Bundle 可能继续存储等待、在后续跳过期、遭遇安全策略拒绝，或永远没有交给目的应用。反过来，一次 LTP 会话失败也不等于任务数据永久丢失；其他副本、接触窗口、路径或应用恢复机制仍可能存在。

RFC 5327 的认证扩展处理来源与抗滥用问题，却不会扩大接收区间。一个经过认证的报告仍可能只覆盖红色前缀。完整性、身份、覆盖范围与业务结果是四个不同维度。

RFC 5326 的发布类别是 Experimental。IESG 说明没有以互联网标准所需的方式全面审查安全、拥塞控制与既有协议交互。文档自身没有流量控制或拥塞控制，不适合无处不在的公共互联网；其当时的 UDP 使用范围限于开发或私有局域网。后续 RFC 提供注册表和 Bundle 演进背景，但不能证明某个现实部署的配置或效果。

来源与证据边界

以上来源证明协议语义、发布状态与相邻架构，不证明当前部署、具体任务结果、绿色后缀完整到达、Bundle 交付或应用消费。