摘要

  • PDU-Concat 把多个通常较短的 PDU 放进同一个 SNDU，只记录一次共同的 ULE 类型，并在地址存在时让全组共享一个 NPA；效率收益因此与共同校验、共同丢弃同时出现。
  • 可审计的运行证据必须分别记录入组、等待、发出、完整性检查、成员长度闭合、提取、下游转发和高层接受，不能用其中一个绿色结果替代整个链条。

如果五个数据单元分别装进五个信封，每个信封都要写一次类型和目的地址。RFC 5163 的 PDU-Concat 把它们装进一只大信封：共同信息只写一次，每个成员只留下自己的长度和内容。

这看上去只是压缩管理成本。真正的变化却更深：接收端不再先判断五个独立信封，而是先判断一个共同外壳能否被可靠拆开。第五个成员若声称自己比剩余空间更长，前四个成员即使各自完整，也已经进入同一个无法闭合的账本。

被省掉的字段变成共享约束

PDU-Concat 是 ULE Next-Header 注册表中的强制扩展类型 3。外层基本头部给出整个 SNDU 的长度；PDU-Concat-Type 只出现一次，所有成员必须属于同一个 ULE 类型，也不允许递归再套一层 PDU-Concat。每个成员用 15 位长度指出自己的字节数，成员之间不要求按 16 位或 32 位边界对齐。

SNDU 若带有 NPA 目的地址，接收端必须把同一个地址关联到组内所有 PDU；若没有地址，所有成员都按无 NPA 处理。位于 PDU-Concat 之前的扩展，例如 TimeStamp，也作用于整个组合体，而不是分别证明每一个成员的时间。

共同 NPA 可以帮助接收端一次过滤掉不属于自己的整组数据，却不是安全身份。RFC 4259 明确说，这种过滤只是弱安全措施，可能由软件重配，性质近似以太网的混杂接收。它不认证发送者，不授权负载，也不证明各成员拥有相同的 IP 层目的地或业务事务。

外层完整，不等于内层可分

接收端首先要确认自己支持 PDU-Concat-Type。不支持的类型必须丢弃，并应记录 PDU-Type 错误。随后它按顺序提取成员，验证每个成员长度，并确保全部已处理长度之和等于 SNDU 基本头部声明的长度。

RFC 5163 对两个异常使用了不同强度的规范词。如果总长度与成员大小不一致，接收端应当丢弃整个 SNDU，并应记录 PDU-Concat 大小不匹配。如果某成员声明的长度超过尚未处理的剩余字节，接收端则绝不能转发这个残缺 PDU。前者是 SHOULD，后者是 MUST NOT；可靠报道不能把两者混成同一强度。

CRC 也不能替代这本内账。ULE 为每个 SNDU 校验 CRC-32；分片 GSE 的 CRC 位于最后一个分片，重组后被移除。校验成功只能说明被保护的字节符合该完整性范围，不能说明内部成员边界相互吻合、类型受到支持或 NPA 与本接收端匹配。

因此，一条完整证据链至少包括：封装器接纳同类型成员、等待阈值或大小条件触发发送、外层重组与完整性通过、扩展和成员类型被识别、每个长度都落在剩余空间内、总和闭合、完整成员被提取并转发、上层逐一接受。IANA 编号只证明类型已经分配；CRC 只证明自身覆盖范围；链路层提取也不等于应用完成。

等待时间也是包头的一部分

要凑出一组，封装器必须等待。RFC 要求 PDU Packing Threshold 有上界，并建议它可配置。等待更久可能提高效率，却会增加抖动，也可能提高受损概率；若阈值内没有新 PDU 到达，已经排队的全部成员必须立即发出。

标准没有给出适用于所有业务的数值。领导层真正要批准的不是“开启聚合”这一个开关，而是一个预算：节省多少包头字节、减少多少重复处理，换来多少额外等待，以及一次外层失败最多会牵连多少原本独立的 PDU。

TS-Concat 用固定大小展示了同一原则。它承载一个或多个 188 字节的 MPEG-2 TS 包；剩余长度若不能整除 188，接收端必须丢弃全部封装的 TS 包。聚合不是天然不安全，但它明确选择了共同成败的粒度。

可跳过的选项与不可跳过的语法

RFC 4326 让可选扩展携带可推导长度，所以不了解该选项的接收端仍可跳过。RFC 5163 的 TimeStamp 就是可选扩展：接收端可以处理，也可以跳过，但必须继续解析并转发 PDU。它的微秒计数只有在发送方时钟同步时才可能支持单向时延测量；要推导丢包还需发送方的其他信息。

PDU-Concat 改变了剩余字节的分段语法，不能照样跳过。强制性意味着“不理解就不能安全继续解析”，而不是“理解后一定成功”。这正是协议能力、格式有效、完成转发与最终业务结果必须分开记录的原因。

来源