摘要

  • RFC 1144 让压缩端和解压端分别保存上一份 IPv4/TCP 首部，只在链路上发送连接标识、变化位图与增量，典型四十字节首部因而可缩至数个字节。
  • 普通首部并未从互联网中消失；受限链路结束前，解压端会恢复完整报文，终端主机无需知道中间发生过压缩。
  • 丢失一个增量会让两端依据不同的过去继续计算，因此 TCP 校验和、toss 状态与非压缩刷新共同构成了必要的恢复合同。

一个字符为什么嫌四十字节太重

1990 年 2 月的 RFC 1144 面向 300 至 19,200 bit/s 的串行链路。最短 IPv4 首部二十字节，最短 TCP 首部也是二十字节。交互终端输入一个字符，会形成 41 字节报文；远端回显又是 41 字节。该文的历史计算表明，仅在 200 毫秒内串行送完这 82 字节，就需要约 4,000 bit/s。

大文件可以靠更长载荷摊薄固定成本，逐字交谈却无法这样做。一个正在发送的大报文还会占住线路，使短小回显继续排队。这里要优化的不是漂亮的压缩比，而是人能否感到远端及时回应。

首部的含义被搬进了状态

Van Jacobson 的起点很克制：首部字段都有用途，不能因为链路慢就把它们宣布为多余。真正重复的是相邻报文中的值。一次 TCP 连接内，源目地址和端口通常不变；序列号、确认号、窗口与 IP Identification 也常按可理解的模式前进。

压缩端为活跃会话保存上一份首部，解压端保存对应副本。小型连接标识 CID 选择状态槽。UNCOMPRESSED_TCP 报文播种或刷新完整上下文；之后的 COMPRESSED_TCP 只携带哪些字段变化的位图、紧凑增量，以及不能推断的值。解压端先重建普通 IPv4/TCP 首部，再把报文交回正常网络处理。

压缩只存在于相邻链路系统之间。路径之外看到的仍是标准 IP 报文，TCP 端点不必加入这套状态机。被省掉的是局部线缆上的重复，不是端到端语义。

可预测变化才是编码表

序列号常按上一报文的数据长度增加，反向确认号也有类似规律；IP Identification 往往只跨一个小步。变化位图说明哪些字段不同，变长编码让小增量占用更少字节。常见的交互回显和单向批量传输还获得专门捷径。

协议同时规定什么时候停止猜测。IP 分片，带 SYN、FIN 或 RST 的报文，没有 ACK 的报文，首部长度改变、选项异常或字段跳变不合预期时，都走安全的完整路径。压缩算法的可信度来自边界，而非对所有流量都声称聪明。

RFC 1144 在自己的轨迹中报告了约三字节的平均压缩首部。这是特定来源的测量，不是今日任意链路的保证。其历史价值在于证明：节省空间的是跨报文连续性，而不是协议设计里凭空多出的废字节。

一次丢失会制造两个过去

增量必须依附同一个基准。如果一个压缩帧丢失，发送侧可能已经更新所存首部，接收侧却仍停在旧版本。下一份增量在两端各自都能计算，却会得到不同报文。

RFC 1144 借用了 TCP 已有的检错与恢复行为。错误重建的序列号或确认号通常会导致 TCP 校验和失败。解压端随后进入 toss 状态，丢弃继续抵达的压缩帧，直至一个非压缩帧重新建立上下文。TCP 的重传与重复 ACK 还能帮助触发刷新，无需为首部压缩另建纠错对话。

校验和不是认证，也不保证所有损坏都无害。它提供的是一条有界退路：既然线上的证据被共同记忆替代，记忆失配就必须能够被发现、停止并重新奠基。

后来的规范把隐含机器写了出来

1999 年的 RFC 2507 把原则概括为：偶尔发送完整首部建立上下文，后续压缩首部引用它并带增量。非 TCP 流获得 generation 与周期刷新，TCP 获得无增量修复、首部请求和乱序处理规则。

状态容量也成为明确限制。有限 CID 被许多流争用时，频繁逐出会形成 CID thrashing，完整首部不断重发，预期收益随之蒸发。保留哪条流的记忆，不再只是实现细节，而是资源分配。

RFC 4413 后来按静态、可推断、可预测与不规则行为分类字段。ROHC 框架及其 TCP profile则面向更容易丢包和乱序的链路，把初始化、状态转换、反馈、刷新与 CRC 保护写得更明确。它们不是 RFC 1144 的线缆兼容升级，却延续同一治理问题：省略的事实究竟由哪份上下文授权恢复。

来源与界限

封闭来源集为 RFC 1144、RFC 2507、RFC 4413、RFC 4995 与 RFC 6846。它们证明机制与文中样例，不证明当前部署率、厂商默认值、普遍收益或每个压缩首部恒为三字节。