摘要

  • MPPC 要求 PPP 两端维持同一段 8192 字节滑动历史；每枚 MPPC 包携带 12 位一致性计数，用来暴露丢包或顺序异常。
  • 计数不符时，接收端丢弃该包并发送 Reset-Request。发送端清空压缩历史，在下一枚包上置 FLUSHED；接收端据此清空历史并采用该包的计数，因此不需要 Reset-Ack。
  • 这份证据只证明新的压缩历史边界。它不补回丢失数据，也不证明可靠交付、载荷完整性、对端身份、授权或应用完成。

没有等回来的确认包

RFC 1962 的通用 CCP 恢复像一笔控制事务：解压端发出 Reset-Request 后，继续丢弃压缩包，直到收到标识符匹配的 Reset-Ack，再把解压器恢复到初始状态。

RFC 2118 为 MPPC 选择了另一份收据。接收端看到的计数不是预期值时，先丢包，再发 Reset-Request。压缩端收到请求后清空历史，并在下一枚 MPPC 包上置 FLUSHED。解压端看到该标记，清空自己的历史，把包中计数作为新基准。同步由此恢复，却没有发生 Reset-Ack 交换。

这意味着恢复证据进入了正在运行的数据流：下一枚能够独立解码的包，本身就是新 epoch 的起点。但它不能回写过去。它不证明 Reset-Request 曾以何种路径到达，不恢复缺失包，也不说明上层应用最终收到了内容。

18 号选项只打开一项特定变换

MPPC 并非 PPP 的默认属性。它通过 CCP Type 18、Length 6 的选项协商，四字节 Supported Bits 中只有最低位用于表达希望启用 MPPC；最终无法达成一致时就不压缩。今天的 IANA PPP 注册表 仍把 CCP 选项 18 记为 Microsoft PPC。

只有 PPP 进入 Network-Layer Protocol 阶段、CCP 进入 Opened 状态之后，MPPC 数据包才能出现。压缩数据报使用 PPP Protocol 0x00FD，而 CCP 控制协议本身使用 0x80FD。前者标识压缩数据路径，却不能单独命名算法；算法身份来自此前的选项协商。

MPPC 只处理 0x0021 到 0x00FA 的 PPP Protocol 值，其他协议绕过压缩器并保留原编号。因此，协商成功证明的是一项可用能力，不是“每个包均已压缩”，更不是业务已经完成。

8192 字节记忆让相邻包彼此依赖

MPPC 使用连续的 LZ 历史。发送 8192 字节压缩数据后，除非发生 flush，压缩器可以利用完整的 8192 字节窗口。节省带宽的原因正是后来包能引用较早包学到的内容；代价则是双方必须保存同一份记忆。

包头给出了几条精确界线。A 位即 FLUSHED，表示发送端在生成本包前初始化历史，本包不依赖旧 epoch。B 位把历史指针移回缓冲区起点，并且每发送 8192 字节压缩数据至少出现一次。C 位说明当前数据是否压缩。这些位描述压缩表示和历史状态，不描述传输或应用状态。

数据膨胀也会触发新边界。如果压缩结果反而更大，发送端用未压缩的 MPPC 包发送原始数据；下一次重新压缩前，它必须清空历史，并在下一枚包上置 FLUSHED。避免当前包变大的同时，也放弃了已积累的上下文。

十二位计数找到断点，却不验证内容

一致性计数从零开始，每枚 MPPC 包加一，在 4095 后回绕。接收端将实收值与预期值比较，不一致就说明步骤缺失或次序异常。RFC 2118 因此说 MPPC 不要求可靠链路；RFC 1663 虽定义了可靠 PPP 模式，但本机制通常不需要那份开销。

同一段文字也明确要求包按顺序到达，否则历史无法重新同步。“不要求可靠链路”并不等于任意重排无害。一致的计数更不是内容校验：坏数据、实现缺陷或后续交付失败都可能发生在计数正常时。RFC 2118 的安全考虑只写明“本文不讨论安全问题”，没有提供机密性、密码学完整性、身份、授权或防重放属性。

一项带许可说明的历史机制

RFC 2118 于 1997 年 3 月以 Informational 发布，并非 Internet Standard。其许可章节把 MPPC 的用途限定在为 MPPC/PPP 互操作而实现 PPP 的产品，并指向 Stac Electronics 的许可。这能说明当时的运行表面，却不能证明今天的许可、专利或部署状况。

对信号的克制解释来自 Heng Lu 的 Running-Code Primacy 与 Minimum Initial Specification：让每一层只承担自己能够验证的最小主张。18 号选项记录能力协商，0x00FD 标识数据路径，计数暴露顺序差异，Reset-Request 请求修复，而下一枚 FLUSHED 包建立新历史。它们都没有权力替安全层或应用层宣布结果。

来源与证据边界

主要记录包括 RFC Editor 的 RFC 2118 HTML、纯文本版本、信息页与勘误入口，以及 RFC 1962、RFC 1661、RFC 1663和 IANA PPP 注册表。Heng Lu 的文章用于约束解释，不替代协议史料。这些来源证明规范行为与文档身份，不证明当前部署、性能、许可、安全性或某一真实数据包的应用结果。