摘要

  • 在 Media over QUIC Transport 草案第 22 版中，FORWARD=0 暂停某一条既有订阅的对象传送，但 PUBLISH_DONE 等控制消息仍会继续。
  • 当所有下游订阅者都暂停时，接力节点可以为了预热缓存而让上游订阅继续运行。因此，一张暂停回执不能证明取流、资源消耗或缓存写入已经停止。

观众按下暂停，画面定格，播放器的下行流量下降，服务端也把该订阅标记为暂停。用户看见的是一个动作，链路中间的接力节点却可能作出另一项决定：继续从发布者接收直播轨道，以便恢复播放时少等一段时间。

这不一定是故障。2026年10月1日发布的 draft-ietf-moq-transport-22 明确保留了这种取舍。草案把 MOQT 定义为运行在 QUIC 与 WebTransport 之上的发布/订阅协议。Datatracker 将它列为 Media Over QUIC 工作组的活跃 Internet-Draft。它仍是进行中的工作，不是 RFC，也不能证明任何具名服务已经采用。文件页眉写着 Standards Track，而 Datatracker 当前没有显示预期 RFC 状态；两者都不能被升级解读为批准。

第 22 版首先做的是澄清语言。第 21 版把开关称为取值为 0 或 1 的 Forward State。第 22 版直接说，一条既有订阅处于暂停或未暂停状态，变更记录也写明把 Forward State 表述为订阅暂停。基础机制不是10月1日才出现；新之处在于运行人员终于能用更清楚的词去命名和测试它。

局部规则很严格。订阅暂停时，发布者不发送对象；控制消息并未停摆，其中包括 PUBLISH_DONE。订阅发起方在 PUBLISH 或 SUBSCRIBE 中使用 FORWARD 设置初始值。之后，订阅者用携带 FORWARD=0 的 REQUEST_UPDATE 暂停，用 FORWARD=1 恢复。超出 0 和 1 的值会触发协议违规。

所以，“暂停”并不等于“取消”。在取消、收到 PUBLISH_DONE 或 REQUEST_ERROR 之前，订阅状态仍会保留，并继续受流状态规则约束。暂停也不会把稍纵即逝的补取请求保存到未来。若暂停期间处理 FILL_PARAMETERS，系统不会打开 fill-fetch 流；后来仅仅恢复订阅，也不会自动补开。想在恢复时追补历史，必须重新表达相应请求。

流层的证据也要分开。发送方若在相关对象尚未全部送达前关闭 subgroup 流，就必须重置该流。第 22 版明确把“因为订阅暂停而省略 subgroup 对象”列入此类情况。干净的 FIN 可以支持“从订阅起点开始，这个 subgroup 已完整结束”的判断；重置则说明最后一个已收对象之后可能还有内容。两者都是合法事件，却不是同一种完成凭证。

最重要的权力边界在接力节点。只要某条轨道还有一个下游订阅者未暂停，接力节点就必须维持一条未暂停的上游订阅，才能接收并转发所需对象。但当所有下游订阅者都暂停时，是否暂停上游由接力节点自行决定。

上游继续运行，会开始接收对象并预热缓存，恢复延迟可能降低；代价是发布者和上游资源仍在为当前无人接收的内容工作。暂停上游可以省掉这部分工作，却可能让重新播放变慢。规范没有把这项利益冲突藏起来，而是把决定权留在本地。

因此，界面上的绿色“已暂停”标记，证据范围比围绕它构建的成本或隐私承诺更小。它最多证明某一条订阅在发布者处的协议状态。它不能证明接力节点停止取流、发布者停止工作、缓存停止变化，或计费传输归零。反过来，它也不能证明接力节点一定保持热流；那是本地策略，必须观察上游链路才能确认。

有用的运行记录应有七份：订阅者按顺序发出的暂停意图；发布者确认的当前状态；下游对象确实停止；仍在继续的控制消息；接力节点对上游的策略决定；实测的上游流量与缓存变化；以及恢复后观众真正看见的结果。任何一份都不能代替其余六份。

陆恒的“最小初始规范”在这里给出恰当分工：公共线缆协议要准确说明 FORWARD 改变什么，但不必替所有运营者决定延迟与资源之间的偏好。“运行代码优先”又把证明从配置标签移到上下游的实际字节。“现实分层”则要求把观众看到的静止画面、协议暂停状态、接力缓存和发布者工作分别记录。这是 Daniel Kade 对这些思想的编辑性运用，不是 IETF 或草案作者的立场。

结论并不宏大，却很重要：命令的权力只到它明示的边界。观众可以暂停向自己的传送，却不会因此自动取得接力节点上游策略的控制权。如果产品承诺更多——不取上游、不写缓存、不产生资源费用——就需要另一项可执行控制和另一张可核验回执。

来源