低速串行鏈路上的TCPIP頭部壓縮（2）

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)糟糕的編譯器(lousyUnixpclearcase/" target="_blank" >cc)影響)的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