摘要

  • RFC 3320 为每条信令消息启动独立且受限的通用解压虚拟机，即使解压程序由发送方提供，也不会因此交出无限制的主机控制权。
  • 解压成功本身不能授权持久状态；应用必须先认证解码结果并给出有效的 compartment 标识，SigComp 才能保存新状态或转发反馈。

压缩传送的不只是消息

RFC 3320 于 2003 年 1 月发布，定义了面向 SIP、RTSP 等应用协议的 Signaling Compression（SigComp）。它并不假设通信两端事先安装了完全相同的压缩算法。发送方可以选择算法，并在必要时将字节码放入消息，由接收端的通用解压虚拟机（Universal Decompressor Virtual Machine，UDVM）执行。接收方因而需要接受一定程度的灵活性，同时又不能让远端输入获得对本机的无限制控制。

这样一来，历史问题不只是压缩节省了多少字节，还包括：一条入站消息可以让接收方执行什么计算，又可以让它留下什么记忆。RFC 规定协议边界，却没有证明 SigComp 在现实网络中的部署规模、采用率或带宽收益。它把一部分表达能力交给发送方，但把计算资源的边界，以及哪些信息可以跨消息保留下来的决定，留在接收方手中。

每条消息都有新的执行边界

每条收到的 SigComp 消息都会调用一个新的 UDVM 实例。解压内存按消息受限，每个端点至少必须提供 2048 字节。指令数也受限，并按消息长度和 cycles_per_bit 参数计算：对于 n 字节消息，上限为 (8*n + 1000) * cycles_per_bit；该参数最小值为 16。这些都是逐消息的预算，不是系统总资源公式，更不是对所有拒绝服务风险的免疫保证。

新的虚拟机实例为故障建立了隔离点。一条格式错误或耗尽执行预算的消息，不会自动把后续有效消息困在同一个虚拟机中。接收端不必依赖一个不断累积状态的单一流式解码器。协议提供了明确的重新开始边界，同时又允许经过选择的状态在消息之间共享。这两个设计并不矛盾：执行环境逐条重建，而跨消息记忆需要另一套有条件的控制。

解码和记忆是两种不同的许可

SigComp 将临时解压内存与分配给 compartment 的状态内存分开。应用可以根据通信上下文划分 compartment，并在会话或其他关联结束时关闭它。希望完全无状态运行的端点可以把状态容量设为零。因此，持久化不是解压当前消息的先决条件。

更关键的规则在解压之后。应用取得还原出的消息，可以按所属协议和上下文进行认证。只有应用愿意为消息提供有效的 compartment 标识时，SigComp 层才得到为该 compartment 创建新状态、并把反馈交给压缩端的许可。如果应用无法建立足够信任，就不提供有效标识；此时 UDVM 终止，不保存所请求的状态，也不转发反馈。

这把语义判断放在解压器之外。UDVM 可以证明某段字节是在指定资源边界内生成的，却无法判断信令是否真实、是否属于预期的会话，或是否应该影响未来压缩。应用掌握更多上下文，因此保留最后决定权。RFC 4896 后来澄清了认证与状态创建的关系；它强化的原则是：解码器的输出不是信任决定本身。

访问旧状态需要不同的门槛

这里有一个时序难题：应用可能需要先看到解压后的消息才能认证它，但解压过程本身又可能需要利用旧状态。SigComp 因而把访问既有状态与解压后的应用授权分成两件事。状态标识由状态字节的哈希导出；接收端在让 UDVM 读取相关状态之前，先检查这一标识。即便读取已有状态通过检查，消息解码后要不要保存新状态，仍由应用授权规则决定。

这两道控制回答不同的问题：“这条消息能否读取已建立的压缩状态？”与“认证后的解码结果能否创建或更新持久状态？”它们发生在不同阶段，依据也不同。若把二者合并，就容易误认为规则彼此冲突。更准确的理解是：先以受保护的状态访问让解码继续，再等待应用在掌握明文含义后决定是否产生新的跨消息影响。

后续规范补足了相邻问题

RFC 3321 增加扩展操作和确认机制；在不可靠传输上，发送方依赖远端状态之前，需要处理确认问题。RFC 4077 规定了报告解压失败的否定确认机制。RFC 5049 为 SIP 应用 SigComp 给出专门要求，这些 SIP 规则不能泛化为所有 SigComp 使用场景。RFC 4464 是使用指南，RFC 4465 则收集了极端测试案例。它们说明该设计需要解释、失败反馈及应用配置文件，但本身并不能证明部署普及或性能收益。

RFC 3320 留下的核心是权力分工：消息可以请求一次受限计算；应用判断其含义是否可信到足以成为影响未来消息的记忆。将两步分开，接收方的资源边界与信任边界才会清晰可见，也不会让“已经解压”悄悄等同于“已经记住”。

来源