摘要

  • CCP 配置选项表达的是接收方愿意或能够解压的算法；两个方向可以各选一种不同算法，也可以只有一个方向启用压缩，无法达成一致时该方向退回不压缩传输。
  • Configure-Ack 只确认一次具体请求，0x00FD 只标记“压缩数据报”而不携带算法身份，Reset-Ack 只结束匹配的重置交换；它们都不能单独证明数据完整、丢包恢复、链路可靠或应用交付。

把一条 PPP 链路想成两条共用铜线、方向相反的传送带。每条带子的终点各自保管一本字典。发件人能否使用某种缩写，不取决于自己写不写得出，而取决于另一端能不能把它还原。这是 RFC 1962 最容易被“双方已协商”四个字掩盖的结构。

1996 年 6 月发布的 RFC 1962 定义了压缩控制协议 CCP。它不规定唯一压缩算法，而是规定如何配置、启用、停用算法，以及如何可靠地通报压缩器与解压器失步。RFC 2153 后来更新了厂商扩展的通用封装，但没有改变这种分向结构。

能力声明指向接收方

PPP 必须先进入网络层协议阶段，CCP 才能交换控制包；过早到达的 CCP 包应被静默丢弃。即便如此，压缩数据也要等到 CCP 进入 Opened 状态后才能发送。

CCP 选项描述接收方愿意或能够用来解压的数据格式。接收方可以给出多个候选，最后为进入自己的那个方向选定一个主要算法。反方向由另一个接收方独立决定。因此，链路两端可以因速度、内存、成本或许可条件不同而采用不同算法，也可以只压缩单向流量。

失败路径同样明确：不认识的选项必须 Configure-Reject；认识算法但参数不可接受，则 Configure-Nak，并返回可以接受的值。如果所有算法都被拒绝，这个方向不启用压缩，链路继续以普通格式工作。局部不兼容并不自动升级为整条链路失效。

Configure-Ack 的证据边界

CCP 借用了 LCP 的交换机制和状态机。按 RFC 1661，Configure-Ack 是对一份有效 Configure-Request 的肯定答复。它能证明对端在那个时刻接受了那组精确的选项字节；不能证明以后出现的任意报文一定用了这套实现。

若要把 Ack 与后续数据连接起来，记录至少需要请求和应答标识符、方向、原始选项、参数、状态时代，以及双方确实到达 Opened 的证据。中途可能发生重协商；厂商 OUI 能指向一个扩展空间，却不能保证两个二进制程序对 subtype 和 values 的理解一致。

RFC 1915 还保留了另一段历史：CCP/ECP 的推进面对多种专利算法，需要程序性 variance。这能解释标准化环境，不能证明某个算法实际部署、性能达标或互通成功。

0x00FD 故意不说算法是谁

CCP 打开后，PPP Protocol 字段 0x00FD 表示 Compressed Datagram。在 multilink 中，如果压缩发生在分流之前，仍是 bundle 级状态；如果每条物理链路单独压缩，则数据使用 0x00FB，控制使用 0x80FB。IANA 至今登记这些值。

RFC 1962 明确说：这个字段表示报文经过压缩，却不表示用什么算法压缩。因为每个方向同时只有一个主要算法，接收方必须把 0x00FD 与当前方向、当前时代的 CCP 状态拼在一起解释。离开控制交换，只剩两字节的抓包无法选择正确解码器。

“Compressed” 也不保证长度变短。有些输入会膨胀；超出 PPP Information 字段上限时，可以退回原生协议报文，或使用算法支持的分段。它描述处理类别，而不是节省比例。

识别失步是另一项责任

带历史的压缩对丢包尤其敏感：少一个块，双方字典此后都可能不同。通用 CCP 头没有统一的 CRC。RFC 1962 要求每种算法提供判断数据是否可靠通过的方法，或者要求使用 RFC 1663 之类的可靠传输；同时强烈建议验证解压后的数据，或识别失步的压缩器/解压器组合。

具体 profile 说明了为何不能从 0x00FD 猜细节。RFC 1974 的 Stac LZS 可使用序列号、LCB 或 CRC，并维护多个 history；RFC 1967 的 LZS-DCP 又有自己的 reset 位和校验方式。看到压缩标记，只能回答“它自称进入压缩路径”，不能回答“校验已经通过”。

重置状态，不是追回时间

当接收方发现解压失败，它发送 Code 14 Reset-Request。在收到预期标识符的有效 Code 15 Reset-Ack 之前，后续压缩包要被丢弃；请求可以用同一标识符重发。

对端收到请求后，把自己的发送压缩器清到初始状态，并复制标识符返回 Ack。原接收方随后把解压器清到相同起点。这样只修复出错方向，反向流量无需停下。

但共同起点不会让已丢弃的数据报重现。Reset-Ack 不能证明下一包 CRC 正确、其他 history 正常、底层链路可靠，也不能证明 TCP 或应用完成了重传。它是一张同步回执，不是业务恢复回执。

一份薄协议留下的厚教训

按 Heng Lu 的“运行代码优先”去读，RFC 的价值在于让可执行边界变得清楚，而不是让文档替代现实。CCP 的最小公共层规定包类型、选项处理、打开条件与重置动作；选择算法、参数和是否压缩，留给各接收方的本地能力与自愿采用。

因此证据也应逐级保留：网络层阶段、分向请求、匹配 Ack、Opened、实际启用的压缩器、报文标记、算法特定校验、匹配重置、重置后首个有效数据报、端点接收与应用结果。RFC 1962 的韧性不来自一句“链路已恢复”，而来自允许一侧准确承认自己的字典已不可用，并把损害关在这一侧。

Sources