摘要

  • RFC 3269 将可靠组播视为一组依赖应用需求的设计，而不是一种适用于所有场景的传输协议。它把“构建模块”方法变成文档契约：可复用模块必须披露自身范围、接口、依赖和失效边界，完整协议实例则必须说明整个系统。
  • 它的核心警告是组合性问题：两个组件分别成对工作，并不保证三者合在一起仍能工作。因此，可复用性是设计目标，不是兼容性、安全性、部署或采用的证明。

模块化背后的边界问题

可靠组播传输（RMT）面对的是实际需求差异。大规模文件分发、交互协作和流媒体，对组规模、延迟、顺序、发送方数量以及能否接受不完整交付的要求并不相同。RFC 2357 已将这种差异和拥塞外部性列为审查协议提案的理由。RFC 3269 回答的是另一个问题：既然没有一种协议适合所有需求，那么设计者在复用其中某个部件之前，必须知道什么？

它并未假装每个模块彼此独立。RFC 3269 指出，有些构建模块依赖具体上下文。A 与 B 组合可能有效，B 与 C 组合也可能有效，但 A、B、C 全部组合后却可能失败。在一种配对中看不到的依赖，加入第三个模块后可能变成不兼容。架构图上的一个方框，并不能证明模块边界真实存在。

因此，模块规范需要解释为何采用这种粒度，描述功能和外部接口、适用场景、已知失效及其检测方式、环境限制和模块冲突，并说明适用的安全与代码点问题。相关时，数据包字段以及对其他模块的要求也必须写清楚。这样，后续设计者才能判断模块是否适合新场景，而不是从名称推断它可以随处复用。

组件不等于组装后的协议

RFC 3269 又为“协议实例”设定了一道边界：这是把多个模块组合成完整协议的文档。它必须说明目标应用和规模、包含与排除的环境、已知弱点、架构、选用的模块、模块如何连接，以及取舍依据。它还必须给出完整算法和数据包格式，不能让实现者猜测抽象模块规范没有交代的细节。

符合性声明明确了“完整”这一主张的单位：协议实例及其引用的构建模块文档，应共同完整定义一个符合较早 RFC 2357 要求的可运行 RMT 协议。这并没有把 RFC 3269 变成测试报告，也没有保证不同实现能够互操作。它规定的是，在“可运行协议”这一说法可被评估之前，文档必须让读者检查什么。

数据包格式的一条规则尤其说明了它的界线：RMT 协议实例最初必须定义基于 UDP 的承载方式；是否值得分配专用 IP 协议号，则推迟到协议已经得到充分部署和理解之后。也就是说，RFC 把设计完整性、稀缺编号分配和后续采用证据区分开来。这是一条规范边界，不是某个协议已大规模部署的证明。

RFC 3048 描述了 RMT 如何区分可复用模块与协议特有的核心。RFC 3269 为作者补上了让这一区分变得清晰的文档义务。2009 年，RFC 5651 在更新早期 LCT 构建模块规范时明确表示遵循 RFC 3269 指南，这是可追溯的文档传承实例。这条引用说明方法之间存在承接关系，但不能证明普遍合规或部署结果。

其历史意义不应简化成“模块化会成功”。RFC 3269 要求复用必须伴随范围披露，并把完整性放在组装后的协议层面，而非单个模块各自的说明中。它可以让作者公开更多供审查的设计信息，却无法仅凭声明保证多份规范组合后安全运行。

来源