摘要

  • History Number 选择的是协商后的压缩缓冲区；每个历史各自维护顺序、检查与复位状态，不同历史之间没有共同排序要求。
  • C/U=0 只说明本包数据以原样传输。在 Process-Uncompressed 下，发送端和接收端仍会用它更新历史，所以“未压缩”不等于“未改变状态”。
  • 序列号发现定义内的缺口或乱序，LCB 检查压缩数据解码后的单字节异或值，Reset-Ack 建立新的共同起点；三者都不能补回丢包，也不能证明 PPP 上层已收到数据。

一个看似什么都没做的包

观察者看到 C/U 位为 0，很容易在记录里写下“压缩旁路”。RFC 1967 却要求先看另一个协商值：Process Mode。若选择 Process-Uncompressed，原样数据仍进入双方的 LZS 历史。当前包没有节省字节，下一包却可能依赖它留下的上下文。

若 Process Mode 为 None，接收端不得用未压缩包修改历史；发送端若先尝试压缩、已经改过历史，随后决定发送原样数据，就必须在处理下一数据报前清空该历史。于是同一个 C/U=0 包可能对应“继续记忆”或“放弃记忆”两种完全不同的后续状态。

这正是 RFC 1967 最值得保留的历史细节。RFC Editor 记录与 IETF Datatracker确认它于 1996 年 8 月以 Informational 发布；它明确不构成互联网标准。

DCP 把恢复信号带进数据路径

RFC 1967 在 Stac LZS 上加入 DCP 头。其直接前身是后来成为 RFC 1974 的非 DCP Stac LZS 方案。DCP 的一字节头同时承载压缩/未压缩标志、Reset-Request、Reset-Ack 与控制/数据位；在 PPP 用法中，控制/数据位必须为 0，只有复位请求的包也被归作数据包。

这与 RFC 1962 的通用 CCP 控制交换不同。RFC 1967 的 R-R 与 R-A 属于某个 History Number，而且在同一包的数据之前处理。复位信号可以与反方向的正常数据共存，局部故障无需冻结整条链路。

History Count 决定故障半径

History Count 为 0 时，每个数据报开始前都清空唯一缓冲区，发送端在所有包上设置 R-A。这样不依赖前包，也不要求跨包按序到达，但逐包压缩通常牺牲压缩率。

值为 1 时，两端各维持一份持续历史；大于 1 时，每个历史都有独立缓冲区、错误检测状态和信令状态。同一 History Number 内必须按序，不同编号之间无需排序。编号字段在少于两个历史时消失，2 至 255 时为一字节，256 及以上为两字节；只要任一方向使用多历史，双方所有压缩包和未压缩包都必须携带相同宽度的字段。

文档说一个历史“可以”代表一个逻辑连接。这不是业务身份定义。编号没有声明客户、会话、五元组或交易，监控系统不能凭它自动完成这些归因。

反扩张其实是跨时间的取舍

Stac LZS 最多可扩张 12.5%。如果结果加头部超过对端 MRU，发送端必须选择未压缩 LZS-DCP。Process Mode 为 None 时，可以承受当前扩张以保留历史，也可以发送原样数据并清空历史。Process-Uncompressed 提供第三条路：当前不扩张，历史也不丢，因为双方从原样数据同步更新。

因此，反扩张不只是包长优化，它在“本包带宽”和“未来压缩上下文”之间分配成本。另一 ACTIVE 任务研究 RFC 1977 的 BSD Compress、LZW 与 CLEAR；本文不借用那套字典与码宽语义。

序列号与 LCB 不是一个绿灯

一字节序列号按每个历史独立，从 1 开始并按模 256 递增，只出现在含数据的包里。非预期的下一值触发该历史的接收失败。它说明顺序不符合规则，不检查内容。

LCB 则把 0xFF 与原始未压缩数据报的每个字节逐一异或，接收端解压后重算。它只用于压缩数据，RFC 1967 禁止在未压缩数据包上携带它。一字节异或存在碰撞，也不是密码学完整性机制。链路 FCS、RFC 1663 的可靠编号模式、DCP 序列号与 LCB 各自覆盖不同边界。

IANA PPP 编号表仍列出 0x00FD、0x00FB 与 0x80FD。编号登记证明分配，不证明当前部署、所用参数或任何一次交付。

Reset-Ack 是起点收据，不是恢复收据

接收失败后，接收端针对失败历史发送 R-R。对端收到后先清空该历史的压缩器，再等待一个有数据的包设置 R-A；若暂时无数据，它就等待。R-A 的严格含义是：本包数据进入压缩变换之前，指定历史处于清空状态。

等待期间，该历史后续到达的数据被丢弃，直到 R-A 出现；请求方可能需要重发 R-R。R-A 不重置发送端序列计数器，接收端从 R-A 包重新校准自己的期望值。其他历史和反方向可继续工作。

这个设计让双方从共同空历史继续，却不恢复已经丢失、错误或乱序的数据报。完成解压以后，RFC 1661 意义下的 PPP 接收与上层交付仍需独立证据。RFC 1990 的多链路片段顺序、B/E 位与重组也属于另一问题，不能把其序列号与 History Number 混为一谈。

RFC Editor 的勘误入口在本次采集时未返回可用正文，因此本文不声称 RFC 1967 没有勘误。文档自身还说未讨论安全问题；本文不推导加密、认证或防篡改能力。

Heng Lu 的 Running-Code Primacy提醒我们把规范与实际运行分开；Minimum Initial Specification要求字段只承担可本地验证的最小语义；Reality Layers解释为什么符号不能替代结果；Reality, Not Advocacy要求如实描述结构。这些文字是编辑方法，不是 RFC 1967 的协议史来源。