5可配置参数及调节
5.1压缩配置
与头部压缩有关的配置参数有两个：特定链路上是否应该发送压缩数据包，假如发
送，要预留（reserve）多少个状态槽（即要保存的数据包头部的数量）。还有一个链路
层配置参数，即数据包最大长度或者MTU，一个前端（front-end）配置参数，与头部压
缩(headercompression)一起作用的数据部分的压缩（datacompression）。压缩配置在本
章节讨论。MTU和数据压缩在后两个章节介绍。
有些主机（例如low-endPC）可能没有足够的处理器和内存资源来实现这种压缩。
也有极少数链路或应用程序特征使得头部压缩成为不必要或不希望的。很多现有的SLIP
链路当前不使用这种头部压缩方法。基于互操作性的考虑，答应头部压缩的串行链路IP
driver应该包含某种用户可配置以禁止这种头部压缩的标志(见附录B.2)（注31）。
假如答应压缩，则压缩器必须确保不发送可能被解压器丢掉的connectionnumber(状
态结构的索引)，例如，假如解压器有16个状态槽而压缩器使用20个就会产生一个“黑
洞”（blackhole，注32）；同样，假如解压器答应压缩器使用的槽太少，LRU分配器将
崩溃（thrash），大多数的数据包将被作为UNCOMPRESSEDTCP发送。太多的槽和内存
又造成浪费。
过去这些年在对不同的槽的大小进行研究后，作者发现，当多窗口工作站上的多个
窗口同时使用或者工作站作为其它3台或更多机器的网关时，8个槽将崩溃(thrash，也就
是说，性能大大降级)。16个槽出现崩溃情况还没碰到过(这可能仅仅是因为9600bps的
链路分成多于16路已经超负荷（overloaded）以至于槽的循环导致的性能降级可被忽略
不计了)。
每一个槽必须足够大以容纳128字节的最大TCP/IP头部（注33），所以16个槽占用
2KB内存。对于当前的4MB的内存条中，2KB似乎只是很小的一部分，所以作者建议使
用下面的配置规则：
(1) 假如帧协议不答应协商，压缩器和解压器应该提供16个槽，即从0到15。
注31．PPP协议（参考文献[9]）答应端协商压缩协议，所以不存在互操作的问题。但是，应
该答应系统治理程序在各端控制协商压缩协议是“on”还是“off”。显然，压缩协议缺省
应该为'off'，直到协商为'on'。
注32．严格说来，把连接号作为阵列的索引没有站得住脚的原因。假如解压器的状态保存在
一个散列表或相关结构中，连接号将作为要害字（key），而不是索引，解压器的槽太少将
使性能只是严重下降并不会崩溃（failingaltogether）。但是，联合的（associative）结构本
质上将花费更多的代码，CPU时间代价更高，假如给定每个槽的很小的代价(128字节的内
存)，似乎在解压器方设计槽阵列和（可能是隐式地）传输阵列的大小是合理的。
注33．最大头部长度，即64字节的IP和64字节的TCP，协议设计时就固定了的。
Jacobson[Page19]
RFC1144CompressingTCP/IPHeadersFebruary1990
(2)假如帧协议答应协商，应该协商从1到256的双方都感到合适的槽数（注34）。假如没
有协商槽数，或者直到协商完毕之前，双方都应假设是16。
(3)假如你对两端所有机器的所有链路进行完全的控制，并且任何机器和链路都不会在你
的控制之外与其他机器通信，你就可以随便对它们进行配置，而忽略上面的限制。但
是当你的东方专政崩溃（eastern-blockdictatorshipcollapses，就像它们最终的结果那
样），注重一个巨大的，嘈杂的而且不是非凡仁慈的因特网社会将很乐意向想倾听的
人指出你已经错误地配置了你的系统，它现在不可操作。
5.2选择最大传输单元（MTU）
从第二章的讨论中我们看到，似乎很有必要对有可能存在交互式流量和多个活动连
接的链路的数据包的最大长度（MTU）进行限制。(以保持竞争该链路的不同连接得到
良好的交互响应)。一个很自然的问题是“这会对吞吐量产生多少影响?”回答是它不会
影响。
图8显示了使用（实线表示）和不使用头部压缩（虚线表示）的MTU与吞吐量的关
系（注35）。点划线（垂直方向）显示了2400,9600和19200bps的200ms数据包所对应的
MTU。注重假如使用头部压缩，2400bps的链路还有合理的响应时间并有合理的吞吐量
(83%)（注36）。
图9显示了链路效率随着链路速度上升时的关系，假设总是选用200ms的MTU(注
37)。性能曲线的拐点大约为2400bps。速度小于该点时，效率对速度（或者MTU，因为
两者线性相关）的微小变化很敏感，好的效率以牺牲好的响应时间来作为代价。速度高
于2400bps，曲线平滑，效率与速度和MTU相对无关。也就是说，同时得到较好的响应
时间和较高的链路效率是可能的。
为了说明问题，注重对于一条9600bps链路使用头部压缩，MTU超过200字节将不
会带来任何好处：假如MTU提高到576，平均延迟提高188%，而吞吐量才提高了3%(从
96%-99%)。
注34：仅答应一个槽将可能使压缩器的代码更复杂。实现应该尽量避免仅提供一个槽，并且
假如协商仅用一个槽，压缩器实现可以禁止（disable）压缩。
注35：竖轴是链路速度的百分比。例如，“95”表示链路带宽的95%分给了用户数据，也就
是说，在9600bps的链路上用户将看到数据传输的速率为9120bps。在计算相对吞吐量时包
含了封装时加到TCP/IP的压缩头部的链路层（帧）的四个字节。采用200ms的数据包是假设
链路是异步的，每个字符使用10个比特（8个数据位，1个开始，1个停止，无奇偶校验）。
注36．但是，2400bps链路所要求的40字节的TCPMSS可能强迫检查（stress-test）你的TCP
实现。
注37．对于一个典型的异步链路来说,为200ms。MTU仅是链路速度的0.02倍（以位/秒为单
位）。
Jacobson[Page20]
RFC1144CompressingTCP/IPHeadersFebruary1990
5.3与数据压缩的交互
自20世纪80年代以来，快速、有效的数据压缩算法如Lempel-Ziv（参考文献[7]）以
及其程序如BerkeleyUnix中的compress程序，得到广泛的应用。在使用低速线路或距离
很长的线路时，通常在发送数据前对数据进行压缩。对于拨号连接，压缩一般在modem
中进行,而独立于通信主机。由一些很有趣的问题是：(1)假如给定一个很好的数据压缩
器，头部压缩是否还有必要？(2)头部压缩能与数据压缩一起发生作用？(3)数据压缩是
在头部压缩之前还是之后进行？（注38）
为了研究(1)，对典型的telnet对话中用户一方出现的446个TCP/IP包进行Lempel-Ziv
压缩。因为数据包由击键获得，大多数数据包仅包含一个字节的数据再加上40字节的头
部。也就是说，该实验本质上对TCP/IP头部进行L-Z压缩的结果进行了评估(measured)。
压缩率(未压缩数据与压缩后数据之比)为2.6。换句话说，头部平均从40字节减少到16字
注38：问题的答案是，对于想跳过本章其余部分的读者，分别回答'yes','no'或者'either'。
Jacobson[Page21]
RFC1144CompressingTCP/IPHeadersFebruary1990
节。虽然这是个很好的压缩，但距离对相同数据进行头部压缩所产生的具有良好响应时
间的5字节和3字节(压缩率为13.3)而言还差的很远。
第二和第三个问题更复杂一些。为了研究这两个问题，对FTP的几个数据包有和没
有头部压缩以及有和没有L-Z压缩进行了分析（注39）。L-Z压缩在输出数据流的两个地
方进行（如图10所示）：(1)在数据被提交给TCP进行封装前（与在“应用”层完成的压
缩相似），(2)在数据封装之后(与modem中的数据压缩相似)，表1综述了按前面章节原
理（256字节MTU或216字节MSS；共368个数据包）传输78，776个字节的ASCII文本文
件（Unixcsh.l用户手册入口）的结果（注40）。以下10个测试的压缩率列在表中（从左
注39：telnet用户一方的数据量太少，从数据压缩中受益不大，相反被压缩算法所增加的（必
需的）延时所影响。telnet计算机一方的统计和容量和（ASCII）FTP的相似，所以下面得出
的通用结果适用于所有的10个文件。
注40：这里描述的十个实验各自对十个ASCII文件（4个长的e-mail消息，3个UnixC源程序
和3个Unix用户手册入口），不同文件得出的结果惊人地相似，下面给出的结论适用于所有
的10个文件。
Jacobson[Page22]
RFC1144CompressingTCP/IPHeadersFebruary1990
到右，从上到下）：
● 数据文件(无压缩或封装)
● 数据→L–Z压缩
● 数据→TCP/IP封装
● 数据→L–Z压缩→TCP/IP
● 数据→TCP/IP→L–Z
● 数据→L–Z→TCP/IP→L–Z
● 数据→TCP/IP→头部压缩
● 数据→L–Z→TCP/IP→头部压缩
● 数据→TCP/IP→头部压缩→L–Z
● 数据→L–Z→TCP/IP→头部压缩→L–Z
无数据压缩
LZondata
LZonwire
L-Zonboth
原始数据
+TCP封装
W/头部压缩
1.00
0.83
0.98
2.44
2.03
2.39
——
1.97
2.26
——
1.58
1.66
表1：ASCII文本文件压缩率
表1的第一列表明数据封装在TCP/IP中时数据“膨胀”（eXPand）了19%（压缩了0.83），
而封装在头部压缩后的TCP/IP时“膨胀”了2%。（注41）
注41．这可从相关头部大小中得到：TCP/IP为256/216，头部压缩为219/216。
Jacobson[Page23]
RFC1144CompressingTCP/IPHeadersFebruary1990
第一行表明L–Z压缩对这种数据很有效，把其压缩为原始大小的一半不到。第4列解释了
众所周知的事实：对于压缩后的数据进行L–Z压缩是错误的。第二、第三行的第二、第
三列有很感爱好的信息。这两列表明数据压缩的好处盖过（overwhelm）了封装的代价，
即使是对直接的TCP/IP(straightTCP/IP)进行压缩。它们还表明在封装数据之前进行压缩
比在帧/modem层压缩要稍微好一点。但是差别很小——对TCP/IP和头部压缩的封装，
分别为3%和6%（注42）。
表2显示了对122，880字节二进制文件（即Sun-3ps可执行文件）进行同一个实验的
结果。虽然原始数据几乎没有压缩，结果从质量上看与ASCII数据相同。一个明显的变
化在第2行中：假如进行TCP/IP封装，在modem中进行压缩比在源（source）进行压缩要
好3%(显然，Sun二进制文件和TCP/IP头部有相似的统计结果)。但是假如有头部压缩（第
3行），结果与ASCII数据相似——在modem中压缩比在源头压缩要差3%（注43）。
无数据压缩
L-Zondata
L-Zonwire
L-Zonboth
原始数据
1.00
1.72
——
——
+TCP封装
0.83
1.43
1.48
1.21
W/头部封装
0.98
1.69
1.64
1.28
表2：二进制文件的压缩率
注42：差别是由于TCP/IP数据包与ASCII文本非常不同的的字节样式（bytepattern）。任何
使用Markov源文件模型的压缩方案，如Lempel-Ziv，在完全不同源文件交叉存取时将变得更
糟糕。假如这两个源的相对比例改变，也就是说提高MTU，两处压缩器的性能差异将减小。
但是减小的速度非常慢—MTU提高400%(从256到1024)仅使数据和ModemL-Z之间的差从
2.5%降到1.3%。
注43．在源进行压缩还有其他原因：使更少的数据包被封装，更少的字符被送到modem。作
者认为“在Modem中压缩数据”的选择应该避免，除非碰到很难处理的某些厂商专有的操
作系统中。
Jacobson[Page24]
RFC1144CompressingTCP/IPHeadersFebruary1990
机器
每个包的平均处理时间(μs)
压缩
解压缩
Sparcstation-1
Sun4/260
Sun3/60
Sun3/50
HP9000/370
HP9000/360
DEC3100
Vax780
Vax750
CCITahoe
24
46
90
130
42
68
27
430
800
110
18
20
90
150
33
70
25
300
500
140
表3：压缩代码的执行时间
6性能评估
压缩代码的一个实现目标，是力求足够简单以能在典型的1989工作站上以ISDN
速度（64Kbps）运行。64Kbps即每个字节122μs，所以随意地把120μs作为压缩/解压
缩程序执行时间的目标（注44）。
作为压缩代码的一部分，开发了一个“记录跟踪驱动”的实验程序（trace-driven
exerciser）。最初用它来比较不同的压缩协议选项，然后在不同结构的计算机上测试代
码运行的结果，以及在性能“提高”后进行回归测试（regressiontests）。对该测试程
序进行小小的改动便可得到一个有用的评估工具（注45）。表3显示了作者所能用到的
所有机器上压缩代码运行的时间(这些时间通过一个混合的telnet/ftp流量跟踪取得)。除
了被(a)错误的字节序(b)糟糕的编译器(lousyUnixpcc)影响)的Vax结构计算机之外，所
有的机器本质上都达到了120μs的目标
.
注44：时间选择并不是完全随意的：解压缩一般在各帧之间的“标志”字符（inter-frame'flag'
character）时间进行，所以在压缩运行于与串行链路输入中断相同的优先级的系统中，选用
比一个字符时间长得多的时间将导致接收方来不及接收（overrun）。并且，使用当前平均5
个字节的帧(指线路上的帧，包括压缩后的头部和帧)，花费1个字节时间的压缩/解压缩最多
能使用可用时间的20%，这似乎是一件很划算的事情。
注45：测试程序和测量时间的程序在附录A的可通过ftp获得的数据包中，文件为tester.c和
timer.c。
Jacobson[Page25]
RFC1144CompressingTCP/IPHeadersFebruary1990
7致谢
作者非常感谢由PhillGross担任主席的InternetEngineeringTaskForce（因特网工程
任务攻坚组）的成员，他们给予作者很多鼓励并认真审阅本手稿。几个耐心的beta测试
员，尤其是SamLeffler和CraigLeres，记录并修改了最初的实现中的问题。Cynthia
Livingston和CraigPartridge仔细阅读本文档的部分草案并提出很多改进意见。最后当然
还不止，Telebitmodem公司，尤其是MikeBallard，从一开始便鼓励作者写这篇文档，
已经并且现在还是串行线和拨号IP的支持者
参考文献
[1]BINGHAM,J.A.C.Modem设计的理论和实践（TheoryandPracticeofModemDesign）
JohnWiley&Sons,1988.
[2]CAREY,M.B.,CHAN,H.-T.,DESCLOUX,A.,INGLE,J.F.,ANDPARK,K.I.1982/83endOffice
connectionstudy:Analogvoiceandvoicebanddatatransmissionperformancecharacterization
ofthepublicswitchednetwork.BellSystemTechnicalJournal63,9(Nov.1984).
[3]CHIAPPA,N.,1988.Privatecommunication.
[4]CLARK,D.D.ThedesignphilosophyoftheDARPAInternetprotocols.InProceedingsof
SIGCOMM'88(Stanford,CA,Aug.1988),ACM.
[5]FARBER,D.J.,DELP,G.S.,ANDCONTE,T.M.AThinwireProtocolforconnectingpersonal
computerstotheInternet.ARPANETWorkingGroupRequestsforComment,DDNNetwork
InformationCenter,SRIInternational,MenloPark,CA,Sept.1984.RFC-914.
[6]KENT,C.A.,ANDMOGUL,J.Fragmentationconsideredharmful.InProceedingsofSIGCOMM
'87(Aug.1987),ACM.
[7]LEMPEL,A.,ANDZIV,J.Compressionofindividualsequencesviavariable-rateencoding.
IEEETransactionsonInformationTheoryIT-24,5(June1978).
[8]NAGLE,J.CongestionControlinIP/TCPInternetworks.ARPANETWorkingGroupRequests
forComment,DDNNetworkInformationCenter,SRIInternational,MenloPark,CA,Jan.
1984.RFC-896.
[9]PERKINS,D.Point-to-PointProtocol:Aproposalformulti-protocoltransmissionofdatagrams
overpoint-to-pointlinks.ARPANETWorkingGroupRequestsforComment,DDNNetwork
InformationCenter,SRIInternational,MenloPark,CA,Nov.1989.RFC-1134.
[10]POSTEL,J.,Ed.InternetProtocolSpecification.SRIInternational,MenloPark,CA,Sept.
1981.RFC-791.
[11]POSTEL,J.,Ed.TransmissionControlProtocolSpecification.SRIInternational,MenloPark,
CA,Sept.1981.RFC-793.
[12]ROMKEY,J.ANonstandardforTransmissionofIPDatagramsOverSerialLines:Slip.
ARPANETWorkingGroupRequestsforComment,DDNNetworkInformationCenter,SRI
International,MenloPark,CA,June1988.RFC-1055.
[13]SALTHOUSE,T.A.Theskilloftyping.ScientificAmerican250,2(Feb.1984),128–135.
Jacobson[Page26]
RFC1144CompressingTCP/IPHeadersFebruary1990
[14]SALTZER,J.H.,REED,D.P.,ANDCLARK,D.D.End-to-endargumentsinsystemdesign.ACM
TransactionsonComputerSystems2,4(Nov.1984).
[15]SHNEIDERMAN,B.DesigningtheUserInterface.Addison-Wesley,1987.
Jacobson[Page27]
RFC1144CompressingTCP/IPHeadersFebruary1990
