TCP头部压缩.doc

TCP header compression 一、思想： 整个IP、TCP首部,在一个连接中，有一半的信息是可能不改变的，如图中阴影部分所示“ 除此之外，还可以从中提取其它几个字节。注意到任何合理的链路帧协议将告诉接收者所接收消息的长度，由此Total Length（第2、3字节）也是多余的；然后，header checksum域（第10和11字节）用来保护各跳（individual hops）不处理“脏的”（corrupted）IP头部, 这样要发送的头部信息有16字节。所有这些字节在对话的整个过程中都有可能发生变化但它们不会同时改变。例如在FTP数据传输过程中仅仅 packet ID, sequence number 和checksum 在发送者——接收者方向变化，仅有packet ID, ack, checksum 可能还有window, 在接收者——〉发送者方向发生变化。有了每个方向上上一次发送的数据包的拷贝，发送者可以算出当前数据包中哪些域发生变化，然后发送一个比特掩码后跟变化 的域来表明变化的部分发生了哪些变化。 如果发送者仅发送变化的域，上面的方案可得到平均10个字节左右的头部。但是，值得一看的是这些域的变化情况：典型地，数据包ID由每发送一个包就增加1的计数器得到，也就是说，当前数据包与前一个数据包的ID之差应该是一个很小的正整数，通常小于 256 (一个字节)并且经常等于1。对于从发送方传来的数据包，当前数据包中的顺序号（sequence number）将等于前一个数据包的顺序号加上前一个数据包的数据量(假设数据包按顺序到达)。因为IP数据包最大为64K，顺序号的变化必须小于216(两个字节)。因此，如果传送的是变化的域之差(deference)而不是这些域自身，每一个数据包可以节省另外三四个字节。 这就使我们向5个字节头部的目标迈进。考虑几个特殊情况可使我们得到两种最常见情形下的3个字节的头部——交互式击键流量和批量数据传输——但基本的压缩方案是上面的差分编码（differential coding）。 二、处理细节： Compressor () { //压缩方 数据包进入压缩程序; If (数据包为非TCP包　OR 数据包不能被压缩){ 给数据包打上 TYPE IP的标记; 将数据包传送给Framer; } Else If (在数据包头部阵列中查找到与之匹配的连接){ 压缩数据包; 将原始数据包头放到阵列中; 将压缩后的数据包标记成Compressed TCP传到Framer中; } Else{ 丢弃阵列中最旧的表项; 将数据包头放到阵列中; 将数据包标记成uncompressed TCP传到framer中 } } Decompressor () { //解压方 收到数据包，查看类型; If (数据包类型为TYPE IP) 简单地透传; Else If(数据包类型为uncompressed tcp){ 从ip protocol中提取连接号; 存储iproto tcp; 把连接号设为TCP/IP头部阵列的索引值; 拷贝数据包头到索引值所对应的槽中; } Else{ //即数据包类型为compressed TCP 以连接号作为查到上一个TCP/IP头部的索引值; 用压缩数据包中的信息来更新上一个数据包的头部; 构建新包，还原数据; } } 三、三种数据包的分析 压缩程序把进来的每一个数据包转换成TYPE IP, UNCOMPRESSED TCP或者COMPRESSED TCP数据包。 1.TYPE IP数据包是输入数据包未加修改的拷贝，处理它不会改变压缩程序的状态。 2.UNCOMPRESSED TCP数据包除了IP Protocol（第9个字节）从‘6’（TCP协议）改为连接号connection number外与输入数据包相同。另外，与连接号关联的状态槽被输入数据包的IP和TCP头部更新，连接号记为本串行链路的last connection sent （对下面的C压缩程序而言）。 3.COMPRESSED TCP 数据包包含初始数据包的数据（如果初始数据包有数据的话），但是IP和TCP头部已完全被一个新的经过压缩的头部取代，连接状态槽和last connection sent 被输入数据包中像UNCOMPRESSED TCP那样更新。 四、压缩前后数据对比 前： serial0/0 input: 44 ff 03 00 21 45 00 00 28 2b 3d 00 00 ff 06 7c 71 81 ff 90 20 serial0/0 input: 53 ff 03 00 21 45 00 00