云南龙网

  1. 首页 > 云知道 > >

2 低速串行链路上的TCPIP头部压缩( 三 )

云知道


间的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：二进制文件的压缩率

推荐阅读


上一篇：怎样给山羊梳绒才合适

下一篇：如何清除电热水器内的水垢