云南龙网

  1. 首页 > 云知道 > >

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

云知道

【2 低速串行链路上的TCPIP头部压缩】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，就像它们最终的结果那
样），注重一个巨大的，嘈杂的而且不是非凡仁慈的因特网社会将很乐意向想倾听的

推荐阅读


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

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