相关专题：
马光星
摘要:本文介绍了压缩多个IP首部的方法。该方法能用于IPV6的基本首部和扩展首部,TCP和UDP首部，IPV4首部和封装的IPV6及IPV4首部。典型的UDP和TCP包的首部能压缩到4-7个字节,包括2个字节UDP或TCP校验和。这样就去掉了较大IP首部的很多负面影响并允许在低速和中速链路上有效地使用带宽。该压缩算法专为有一定包丢失率的链路设计的。如,无线链路和使用调制解调器的链路。
关健词：首部，压缩，链路，IPV6，TCP，UDP。
1.引言
在低速和中速链路上进行首部压缩能起到如下作用：
(1)减少互动响应时间
对于很低速的链路,由于发送大的首部需要时间,字符的返回时间可能大于100-200ms。100-200ms是人们能够容忍的感觉不到系统迟缓的最长时间。
(2)允许用较小的包传送大量数据有好的线路效率
当互动(如,Telnet)和大量业务(如,FTP)混合时,由于在小包里载大量数据,在大量数据包后,捕获带互动数据的包时,减少了等待时间。在此情况下,对于FTP业务使用长度小的包,全部解决本地问题。当处理很多小包时,将减少网上的负载。更好的解决方法是在较慢的链路上将大包分段。
(3)对时延敏感的低速数据业务允许用较小的包
对于此应用,如,语音,如果包很大,用数据填充包的时间是重要的。要得到较低的端到端时延,小包是优越的。未压缩首部,最小可能的IPV6/UDP首部长48个字节,用每秒50包的速率消耗19.2kbit/s。每秒50包相当于在每个包中有20ms的语音取样值。如,支持移动的遂道或路由首部将增加首部的带宽消耗10-20kbit/s。如,用GSM编码的13 kbit/s,与实际语音取样需要的带宽相比较,压缩能有效地减少需要的带宽约1.7kbit/s。这能使更高质量的语音在14.4kbit/s和28.8kbit/s modems上传输。
(4)减少首部开销
在中速链路上大量传送的TCP分段的通用长度今天是512个字节。例如,由于使用移动IP,在隧道方式中,TCP分段的IPV6/IPV6/TCP首部是100字节。首部压缩将减少首部的开销,对于IPV6/TCP,从19.5 %减少到小于1%。对于线路速度这是重要的增益,高达几 mbit/s。IPV6规范规定了路径MTU(Maximum Transmission Unit)发现,因此,用IPV6大量传送大于512字节的TCP分段。直到用1400字节的分段(RFC 894以太网封装允许1500字节的净载荷,其中100字节用于IP首部),首部压缩减少了IPV6首部的开销从7.1%到0.4%。
(5)在有丢失的链路上减少包的丢失率
由于每个包只发送较少比特,对于给定的差错率,包的丢失率将是较小的。在此描述的机理,用于点到点链路,但允许扩展到多路接入链路和组播。对于TCP包,文件[5]的机理用于从丢失中恢复。两个附加的机理增加了在有丢失的链路上,首部压缩的效率。对于非TCP包,压缩缓慢地开始和周期地刷新,改变上下关系的首部丢失后,允许抛弃包的周期最小。
2.压缩原理和方法
首部压缩依靠很多字段不变或在同一包流的相邻包之间很少改变。两个包之间不改变的字段都不需要发送。常有小的改变或可预测的值,如,TCP的顺序号能用增量编码,因此,对于这样的字段需要的比特数大量减少。只有常常改变和随机的字段,如,校验和或认证数据,需要在每个首部中发送。首部压缩的普遍原理是偶尔发送一个有全首部的包；随后的压缩首部参考由全首部建立的上下关系和上下关系可能包含的增量改变。首部压缩方案不需要在相同包流中的所有包的首部通过压缩链路。然而,对于TCP包流,两个随后首部之间的差别可能变的更不规则并能减少压缩率。
该首部压缩方案在第一跳或最后一跳以及网络中间链路上都是有用的。当很多包流(几百个)跨越链路时,被叫做CID(context identifier)的波动现象可能发生,在首部很少能够与现存的上下关系匹配的地方,则必须发送不压缩的全首部。
对于非TCP包流几乎首部的所有字段都是常数。TCP的很多字段是常数和其他变化小,可预测的值。要开始包流的首部压缩,在链路上发送载有(CID)的全首部。压缩器和解压器存储全首部的大多数字段作为上下关系。上下关系是由首部的常值字段(不需要在链路上全部发送)或两相邻首部之间改变很小(因此,只用几个比特发送与前面发送的绝对值的差)的字段组成。
在包流中常值字段的任何改变,将引起压缩器发送全首部,更改解压器的上下关系。只要在压缩器和解压器中的上下关系相同,就能精确地恢复为压缩前的首部。然而,如果全首部或压缩首部在传输中有丢失,解压器的上下关系若不作适当修改可能过时。将不能正确地恢复首部。
2.1.包的类型
该压缩方法使用除IPV6外4种类型的包。链路层包的类型和包中前4比特值的结合唯一的确定包的类型。FULL-HEADER--是指有未压缩首部的包,包括一个CID和(若非TCP首部)一个代“G”(generation)。对于由CID识别的包流,它能建立或刷新上下关系。 COMPRESSED-NON-TCP--是指有压缩首部的非TCP包。压缩首部由一个CID(识别解压使用的上下关系),G(检测不一致的上下关系)和首部的随机变化的字段组成。COMPRESSED-TCP--是指有压缩TCP首部的包,包含一个CID,一个识别改变字段的标志字节和改变字段与前面值差的编码。
COMPRESSED-TCP-NODELTA--是指有压缩TCP首部的包,正常发送所有字段,当与前面的值不同时,发送as-is代替。只在响应来自解压器的首部请求时发送这类包。当作为重传结果时不必发送它。
2.2.TCP包流中丢失包时
因为使用与前面TCP首部的差异压缩TCP首部,丢失一个压缩首部或全首部,由于解压使用的上下关系没有适当地增加,将引起以后压缩的首部不能正确的解压。一个压缩TCP首部的丢失将引起以后解压的TCP首部的顺序号k次中断,k是丢失段的数量。当TCP校验和可靠的捕获到顺序号"off-by-k"次差错时,TCP接收器丢弃不正确解压的TCP首部的包。TCP的修复机理实际上是重发丢失的分段并且当重发时,压缩器检测TCP首部。假设重发是由于解压器的压缩状态失配,压缩器重发全首部。在有较高丢失率的中速链路上这是重要的,如,无线。在链路上不可接收的包丢失后,由于上下关系不一致,丢弃超时的包。
2.3.在UDP和其他非TCP 包流中丢失包时
UDP包和其他非TCP包(象TCP包一样)由于校验和没有很好地保护,不能正确的解压。没有变成“ off-by-k”的顺序号和实际校验和保护失败。UDP校验和只包含净载荷,UDP首部和伪首部。伪首部包括源地址和目的地址,传输协议类型和包的长度。除这些字段外,UDP校验和不包含IPV6首部的大部分。然而,其他非TCP首部缺乏完整的校验和,如,分段首部。
为了避免非TCP首部的不正确解压,用G识别非TCP包流的上下关系的每个版本,G是由建立和刷新上下关系的全首部携带的一个小数码。压缩首部携带用于解压的上下关系的G值。当解压器注意到压缩首部携带一个G值而不是包流的上下关系的G时,上下关系未到期而必须丢弃或存储该包,直到全首部建立起正确的上下关系。对于非TCP包流用相同的编码,压缩非TCP首部不改变上下关系。因此,一个压缩首部丢失以后,带有压缩首部的包仍然有效。只有当全首部的上下关系与前面的全首部的上下关系不同时这个G才改变。意思是只有全首部实际改变上下关系时,丢失一个全首部将使解压器的上下关系过时。
G字段占6比特,因此,G值重复64次后,就改变上下关系。要避免差错突发或其他临时破坏后不正确的解压,在MIN-WRAP秒后,压缩器一定不能再用相同的G值。拆除解压器MIN-WRAP秒或更多时,解压前必须等待下一个全首部。驱动后,压缩非TCP首部前,压缩器必须至少等待MIN-WRAP秒。压缩器改变另一个CID或发送规则的首部要经过MIN-WRAP秒后。
2.3.1.压缩缓慢开始
要允许解压器从改变上下关系的一个全首部的丢失中快速恢复,在上下关系改变后,按指数增量周期地发送全首部。这项技术避免了其它压缩方案使用的压缩器和解压器之间消息的交换。压缩器保持每个非TCP包流的一个变量,F-PERIOD保持追踪两个全首部之间可发送多少个压缩首部。当非TCP包流的首部改变时,因此,它的上下关系改变,发送一个全首部和F-PERIOD置1。在压缩缓慢开始时,每次发送一个全首部要两倍F-PERIOD。
2.3.2.周期的首部刷新
如果接收器丢失了上下关系要避免丢失太多的包,有一个上限F-MAX-PERIOD,在两次首部刷新之间,可以发送的有压缩首部的非TCP包的数量。如果发送该包流的最后一个全首部后,发送了F-MAX-PERIOD压缩首部,必须发送一个全首部。对于低数据速率的包流要避免长期拆线,也有一个上边界F-MAX-TIME,在非TCP包流中两个全首部之
间的时间。自从发送一个全首部后,如果对此包流发送一个包的传输时间超过F-MAX-TIME秒,必须发送全首部。
2.3.3.发送全首部的规则
当对非TCP包流发送全首部时,由压缩器决定能使用的下列伪编码。编码维持两个变量：
C-NUM--自从最后的全首部发送后,发送压缩首部的计数。
F-LAST--发送最后全首部的时间。
和使用功能current-time()返回当前时间min(a,b)
返回最小的a和b
send-full-header过程(),increment-generation-value()和send-compressed-header(),明显要做的事。
If(〈该首部改变上下关系〉)
C-NUM:=0；
F-LAST:=current-time();
F-PERIOD:=1;
increment-generation-value();
send-full-header();
else if(C-NUM≧F-PERIOD)
C-NUM:=0
F-LAST:=current-time();
F-PERIOD:=min(2*F-PERIOD,F-MAX-PERIOD);
Send-full-header();
else if(current-time()>F-LAST+F-MAX-TIME)
c-num:=0;
F-LAST:=current-time();
Send-full-header();
else
c-num:=C-NUM+1;
Send-compressed-header();
end if
3.组织包进入包流
什么样的包可以组织在一起进入压缩的包流。要达到最好的压缩率,同一包流中有类似首部的包应该组织在一起。如果组织失败,压缩首部的性能将变坏,因为压缩算法能够利用的包流中现存的上下关系很少而必须频繁地发送全首部。压缩器可以用任何准则适当的组织包进入包流。确定一个包属于什么包流,压缩器可以1)检验可压缩的子首部链,2)检验跟着可压缩子首部链的上层协议首部的内容,如,ICMP部首或隧道的IPX首部,3)利用从资源管理者得到的信息,如果,资源管理者请求对特定包流进行压缩并提供识别包属于哪个包流的方法,4)利用其他任何相关信息,如果,在一个包流中的选路标志和跳数限制字段在n和n+k之间频繁地改变,压缩器可以组织包进入两个不同的包流。
压缩器不能自由的组织包进入压缩的包流,让一些包保持它们的规则首部和不修改地传送。只要非TCP包流遵循发送全首部时的规则和按规定压缩子首部,解压器能够正确地重组压缩首部,不考虑怎样组织包进入包流。
组织包的准则在此给出压缩器怎样组织包进入压缩包流的选择准则。
定义字段
同一包流中不同包之间相同的首部字段为定义字段,用DEF作为定义字段的标记。定义字段包括流标签,IP首部的源和目的地址,在路由首部中的最终目的地址,下一首部字段,口编号(UDP和TCP)和在认证及加密首部中的安全参数索引(SPI)。
分段包
分段包和未分段包决不能组织在同一包流中。分段首部的标识字段不应该用于识别包流。如果这样,新包的一个分段将引起压缩的缓慢启动。
上层协议标识
为标识包流,应该用识别首部的第一个下一首部字段,即,有相同DEF字段和相同上层协议的所有包应该组织在一起。
跳数限制字段
成熟实现可能监视跳数限制字段和用它作为DEF字段时,它是否频繁地改变。当有频繁的选路标记时可能出现,因此,包通过不同路径跨越因特网。
业务等级字段
IPV6首部的业务等级字段,在有其他相同DEF字段的包之间可能频繁地改变。成熟地实现应该注意到这点并准备用这些字段作为定义字段。
当IP包在隧道方式时,在隧道的入口点用一个附加的IP首部封装他们并发送到隧道的终点。要组织这样的包进入包流,应检验内部首部确定包流。如果不这样做,每次内部IP包的首部改变都将发送全首部。当包在隧道方式时,除识别初始IP字段外,应该考虑识别内部子首部字段一个实现能用其它字段标识,如果用太多的字段标识,由于将用更多的CIDs和当新的包流需要CIDs时,可能用错误的CIDs,性能可能受到损害。如果用太少的字段标识,由于太频繁地改变上下关系,性能也可能受到损害。
4.长度问题
4.1.上下关系标识符(CID)
(CID)可能是8比特或16比特。他们的长度与发现上下关系无关。8比特CID的数值2和16比特CID的数值2是等效的。TCP和非TCP的CID空间是分开的,因此,即使它们有相同的值,TCP CID和非TCP CID决不视为相同的上下关系。当用相同的CIDs比特数时,这是双倍可用的CID空间。对于TCP或非TCP总是可以识别全首部或压缩首部,因此,不会混肴。
对于非TCP包, 8比特CID允许2个字节的最小压缩首部长度,CID用第一字节,长度比特和6个比特G值填入第二字节。对于TCP,CID的长度只能用8个比特。当TCP连接点到点时8个比特是足够的。对于点到点链路,CID的长度不必用16比特；要用于多接入链路,为了CID的有效的选择,可能需要较大的CID空间。
多接入链路的主要困难是几个压缩器共享一个解压器的CID空间。当冲突可能发生时,压缩器不能再独立地选择CID。每个压缩器有一个独立的CID空间可以解决这个问题。有独立的CID空间,要求解压器能识别哪个压缩器发送的压缩包,也许可用链路层信息,如,谁发送的链路层帧。如果,这样的信息不能用,可以自动列举在多接入链路上的所有压缩器和提供它们的编号作为CID的部分。后一种方法需要大的CID空间。
4.2.上下关系的长度
压缩器和解压器简单地实现及它们的存储器要求,应当限制上下关系的长度。然而,当扩展首部链的长度任意时,IPV6首部的长度没有上限。当上下关系基本上是一个存储的首部时,这是一个问题。可配置的参数MAX-HEADER代表上下关系的最大长度,表示能够存储的最长首部作为上下关系。当一个首部大于MAX-HEADER时,只存储它的一部分作为上下关系。一次实现不必压缩大于一个首部的初始MAX-HEADER字节。一次实现不必部分地压缩一个子首部。作为上下关系存储的和压缩首部的部分是最长的整个子首部的初始序列,不大于MAX-HEADER字节。
4.3.全首部的长度
当对于链路的MTU可以优化他们的长度时,避免增加全首部包的长度超过他们的原长度。因此,我们假设链路层实现提供包的长度,我们能用全首部中的长度字段传递CID和G值到解压器。要求链路层不必对净载荷加填充,至少没有能够传送到链路上目的用户的填充。还要求在UDP数据后或隧道中的包不加额外的填充。允许从首部的长度和链路层帧的长度计算长度字段的值。
G需要1个字节和CID需要2个字节。在IPV6基本首部和UDP首部中有2个字节长度字段。在IP首部中,全TCP首部至少有2个字节可用,足够传送8比特CID。如果,多于1个IP首部将有2个以上字节可用。当IPV6扩展首部的顺序不固定和CID值不能与下一首部字段的合法值分离时,我们不能使用相应的方法。
一个IPV6/UDP包将有4个字节可用于传送G和CID,因此,可以使用全部CID长度。分段和加密包流可能只有2个字节可用于传送G和CID。对于这样的包流8比特CIDs可能只用于CID长度。当IPV6用于隧道方式时,至少将有4个字节可用并可用两个CID长度字段。在全首部中第一个长度字段的高字节传送G值。当只有一个长度字段可用时,在低字节中传送8比特CID。当两个长度字段可用时,在第二长度字段中传送CID的最低2个字节和第一长度字段的低字节携带CID的最高字节。
4.3.1.在全TCP首部中长度字段的使用
第一长度字段的使用：
长度字段 LSB of okt nr CID
若可用,第二长度字段的使用:
第二长度字段 LSB of okt nr CID
pkt nr是短包的顺序号。
4.3.2.在非TCP全首部中长度字段的使用
有8比特CID的非TCP全首部:
第一长度字段
O D Generation CID
第二长度字段(若可用)
O Data(if D=1)
有16比特CID的非TCP全首部:
第一长度字段
1 D Generation Data (if D=1)
第二长度字段
CID
第一长度字段的第一比特表示CID的长度。若D是0,数据字段是0。
5.压缩首部的格式
a)压缩TCP的形式(类似于文件)：
在第二字节中后面的标记(IPSAWU)与文件中的意思相同,不考虑IPV6是否携带TCP分段。与CID有关的上下关系保持追踪IP版本和出现什么RANDOM字段。一次实现将从开始搜索上下关系和按顺序插入的RANDOM字段。当他们在原未压缩的首部中按相同顺序出现时,RANDOM字段放在TCP首部的DELTA字段之前。
I标记是0,表示TCP前面的首部不是IPV4。如果O标记置1,TCP首部的选项不同于前面的首部。整个选项字段放在压缩TCP首部的最后面。如果R标记置1,在上下关系和TCP首部中的保留字段(6个比特)或紧接TCP前面的IPV6首部中业务等级字节的比特6或比特7之间有差别。有保留字段和业务等级字段的比特6和比特7的实际值的一个字节放在紧跟RANDOM字段的后面。传送字节的比特0-5是保留字段的实际值,比特6和比特7是在业务等级字段中比特6和7的实际值。如果没有前面的IP首部,比特6和比特7是0。传送有R标记的字节不必更新上下关系。注意：R字节不更新上下关系,如果它更新了上下关系,nTCP校验和不保护从错误的解压首部接收的TCP。由于显式拥塞通知希望频繁地改变业务等级字节比特6和比特7。
b)压缩TCP-NODELTA首部的格式
c)压缩非TCP首部,8比特CID：
d)压缩非TCP首部,16比特CID：
当压缩状态隐含时,G,CID和一个字节选项的数据跟着是相关的RANDOM字段,当在原未压缩首部中出现时,按相同顺序存放,跟着是净载荷。
6.子首部的压缩
在此给出必须遵守的压缩子首部链的规则。可以压缩的子首部包括IPV6基本和扩展首部,TCP首部,UDP首部。可压缩的子首部链从首部的开始处扩展。
a)达到但不包括第一首部不是IPV6基本或扩展首部,TCP首部或UDP首部或
b)达到并包括第一TCP首部,UDP首部,分段首部,封装安全净载荷首部。
任何给定较短的链。如,规则a)和b)都填在一个子首部链中包括分段首部和在隧道末端的IPX包。因此,规则b)给一个较短的链,可压缩的子首部链在分段首部停止。NOCHANGE不希望改变的字段。任何改变都必须发送全首部更新上下关系。DELTA可以经常改变的字段,但通常与前面首部中的字段差别较小,因此,发送前面值的改变而不是当前值。这类压缩只用于TCP包流。
RANDOM 在压缩首部中的该字段必须包括“as-is”,通常由于是不可预测的改变。
INFERRED 该字段包含能从其它数值推测的数值,如,帧长度不必包含在压缩首部中。
分类指的是怎样构造压缩首部。在压缩首部中不出现NOCHANGE或INFERRED字段。压缩器从压缩标识符识别上下关系得到NOCHANGE字段和从链路层实现得到INFERRED字段,如,从链路层的帧长度或从其它字段。在同一包流中与前面包的值不同时,编码为DELTA字段。压缩器必须更新上下关系,在压缩首部中上下关系数值上加适当的数值,得到字段的适合值。在压缩首部中的RANDOM字段必须发送“as-is”。当他们在全首部中出现时,在压缩首部中的RANDOM字段必须按相同的顺序出现。可选择的字段用于识别有DEF标记的包属于什么包流。使用选项准则的压缩器,在两个包之间相应的DEF字段有任何不同,意味着它们属于不同的包流。然而,如果DEF字段在一个包中出现而在另一个包中不出现,这两个包属于不同的包流。
6.1.IPV6首部
版本不变(NOCHAGE)(DEF)
业务等级 不变(NOCHAGE) (可能是DEF)
流标签不变(NOCHAGE)(DEF)
净载荷长度 推测 (INFERRED)
下一首部 不变(NOCHAGE)
跳数限制 不变(NOCHAGE)(可能是DEF)
源地址不变(NOCHAGE)(DEF)
目的地址 不变(NOCHAGE)(DEF)
封装首部的净载荷长度字段必须相应于封装首部的长度值。否则一定不能压缩。
注意：如果IP首部最接近TCP首部,用压缩TCP首部的R标记能够传送业务等级字段的比特7。这样的分类意味着整个IPV6基本首部将被压缩掉。
6.2.IPV6的扩展首部和选项
在包流中出现什么扩展首部和它们的相对顺序希望不变。在任何时间有改变,就必须发送全首部的包。在IPV6基本首部和扩展首部中所有下一首部字段都不变。Hop-by-Hop选项和目的地址选项扩展首部的内容用TLV(Type-Length-Value)“选项”编码:选项类型 选项数据长度 选项数据
对于给定包流中的选项类型和选项数据长度字段假设是固定的,因此,它们属于不变的类型。选项数据是随机的除非另有规定。
填充1选项
0
整个选项不变。
填充N选项
1 选项数据长度 选项数据
所有字段都不变。
6.3.Hop-by-Hop选项首部
下一首部不变
首部扩展长度不变
选项TLV编码值和填充不变。
巨大净载荷选项
前两个字段不变和巨大净载荷长度可推测。(必须由链路层实现提供帧长度)。
注意：压缩携带巨大净载荷选项包的首部是不必要的,因为首部的相对开销是可忽略的。然而,在低和中速链路上发送这样大的包通常是不现实的。
6.4.路由首部
路由首部的所有字段都不变。如果不能识别路由首部,不可能确定最终目的地址,除非分段剩余字段是0,在此情况下目的地址是基本IPV6首部中的最终目的地址。在类型0路由首部中,最后地址是DEF(如果分段剩余>0)。路由首部全部压缩掉。当路由首部的最大长度是392字节时,这是很大的胜利。然而,类型0路由首部有一个24字节的地址用于移动IP。
6.5.分段首部
分段首部的分类如下：
下一首部不变
保留不变
Res随机
M标记随机
分段偏移量随机
标识随机
这样的分类意味着分段首部压缩6个字节。最小IPV6的MTU是1280字节,因此,大多数分段至少是1280字节。压缩分段首部只减少6个字节的开销,分摊在很大的包上,另外需要更复杂的综合压缩方案,压缩分段首部是不值的。
6.6.目的地址选项首部
下一首部不变
首部扩展长度不变
选项TLV编码值和填充不变。
6.7.认证首部
下一首部不变
长度不变
保留不变
SPI不变 (DEF)
认证数据随机
压缩后只剩16个字节的认证数据。
6.8.封装安全净载荷首部(ESP)
在隧道方式中,用ESP首部加密整个IP包,在隧道的入口点加密包以前,可以压缩包的首部。当包来自链路层时,一定可以把IP包和它的长度送入压缩器。当包在随道中能重新排序时,一定要用重新排序机理。
SPI不变
Opaque变换数据随机
能加密而不能压缩SPI后面的数据。
6.9.UDP首部
在[RFC-768]中说明了UDP首部。在子首部前面的IPV6的下一首部是DEF。
源口 不变(DEF)
目的口不变(DEF)
长度推测
校验和随机,除非它是0时不变。
UDP首部的长度字段一定与前面子首部的长度字段相匹配,即,IP长度包含的UDP净载荷后面没有任何填充。UDP首部典型的压缩到2个字节,UDP校验和。当UDP的校验和是0时,定义为不变,这样又节约2个字节。
6.10.TCP首部
TCP首部在[RFC-793]中描述。在子首部前面的下一首部字段是DEF。有两种压缩TCP首部的方法。
6.10.1.有微分编码的压缩
源口不变(DEF)
目的口不变(DEF)
顺序号DELTA
确认号DELTA
偏移量不变
保留DELTA(如果上下关系不同,在标志字节R标志置1并发送绝对值)
Urg,Psh 随机(放在标志字节)
Ack推测到1
Rst,Syn,Fin 推测到0
WindowDELTA(如果窗口改变,在标志字节W置1并发送差值)
校验和随机
紧急指针DELTA(如果紧急指针置1,发送绝对值)
选项,填充DELTA(如果改变选项,O标志置1并发送全部选项和填充)
有TCP首部压缩的包必须指出压缩TCP的类型。这个方法本质上是文件中的微分编码技术,压缩TCP首部字段的位置是不同的,用O标志,R标志,取消C标志。当使用时标选项和选项字段随每个首部改变时,O标志允许压缩TCP首部。DELTA值(除保留字段,选项和填充外)用文件中的编码。传送带R标志的保留字段值不必在压缩器或解压器中更新上下关系。
6.10.2.无微分编码
源口不变(DEF)
目的口不变(DEF)
其余全部随机
有TCP首部压缩的包必须指出压缩TCP-NODELTA的类型。当压缩TCP首部时用相同的CID空间并作为上下关系必须保存首部。能够发送这种类型的包代替全包作为响应一个首部的请求,能够用在重新排序包的链路上和当压缩首部不改变时能够代替全包发送。当首部丢失频率高时,综合压缩器只能转向发送压缩TCP-NODELTA首部。
6.11.最小封装首部[RFC-2004]
协议不变
原始源地址出现(S)不变
保留不变
首部校验和推测(从其它值计算)
原始目的地址不变
原始源地址不变(只有S=1出现)
移动通信很可能使用这个首部。
7.TCP压缩首部丢失率低
由于压缩首部的每个包传送的比特数较少,对于有固定的比特差错率的链路,压缩首部比未压缩首部包的丢失率低。这对于有高比特差错率的无线链路是很有利的。然而,因为TCP首部压缩用微分编码,由于在压缩器中上下关系没有适当增加,单个丢失TCP分段能破坏一个完整的TCP发送窗口。以后解压的首部将不同于压缩前的首部并由于校验和失败,TCP接收器必须丢弃它。TCP在广域网连接中的最后一跳是在中速有丢失的链路上,如,无线LAN,由于时延-带宽的乘积相当大和比特差错率相当高,用传统的首部压缩性能较差。下面介绍两种简单的快速修复上下关系的机理。用这些机理压缩首部,将改善在有丢失及低比特差错率的链路上的通过量。
7.1.两次算法
解压器可以计算TCP校验和,确定是否能适当更新上下关系。如果校验和失败,假设有丢失的分段引起差错,就不能适当更新上下关系。假设丢失分段包含的DELTA与当前值相同,当前分段的DELTA再加到上下关系上,就能更新上下关系。压缩和再计算TCP校验和,解压器检验是否修复成功或是否应该再一次应用DELTA。各种TCP的大量转换器的追踪分析表明,应用当前分段的DELTA一次或两次,将修复在数据流中所有单次丢失的上下关系,在83%和99%之间。对于确认流,由于TCP的延时确认机理,成功率是小的。在确认流中,两次机理,修复丢失的上下关系为53%到99%。这个思想的综合实现能确定是否TCP流的一个确认或数据流并用观察全首部及压缩首部确定分段长度。试验多个分段长度小的DELTA将得到确认流中较高的修复成功率。
7.2.首部请求
对于TCP的确认流两次算法成功率较低,解压器调用另一个修复上下关系机理。当有一个丢失后,解压器修复上下关系失败时,解压器可以选择请求压缩器发送全首部。解压器能够识别压缩器和发送到链路上的包。在这样的链路上,解压器可以给压缩器发送一个CONTEXT-STATE包,指出一个或多个上下关系无效。一个压缩包有一个无效的上下关系,解压器不应该每次发送一个CONTEXT-STATE包,应该限制CONTEXT-STATE包的发送率,避免反向信道的洪峰。一个CONTEXT-STATE包能够指出几个上下关系超期,这项技术应该用于代替发送几个独立的包。下图说明CONTEXT-STATE包的格式：第一个字节是类型码,允许其他压缩协议共享CONTEXT-STATE类型的包。当对TCP首部使用请求该类码时,用数值3,包的其余部分是一个字节CID的计数器和CID序列。在CONTEXT-STATE包的接收方,压缩器必须标记CID无效,保证在那些包流中发送的下一个包是全首部或CONPRESSED-TCP-NODELTA包。首部请求是最优化的,因此,一个CONTEXT-STATE包的丢失不影响TCP首部压缩的正确操作。当CONTEXT-STATE包丢失时,最终将发送一个新的CONTEXT-STATE或TCP超时并重新发送。用首部请求的最大优点是在丢失链路上往返一次后,能修复TCP确认流。这将避免TCP超时和不必要的重传。由于较小的包有较低的丢失率,在两个丢失之间TCP窗口能够增大,因此,将得到较高的通过量。
8.配置参数
首部压缩参数是以规定的方法,在链路层实现时协商的。本首部压缩方案的固定参数是：
MIN-WRAP--G值往返的最小时间,3秒。
下列参数能在压缩器和解压器之间协商。若不协商,就是规定的缺省值。
F-MAX-PERIOD--不发送全首部,可以发送压缩非TCP首部的最大数。
范围--1到65535。
缺省值--256。
F-MAX-TIME--在发送最后全首部后,可以发送不大于F-MAX-TIME秒的压缩首部。
范围--1到255秒。
缺省值--5秒。
注意：当压缩器丢失他的状态时,F-MAX-PERIOD和F-MAX-TIME应该小些。
MAX-HEADER--可以压缩的最大首部长度,以字节为单位。
范围--60到65535字节。
缺省值--168字节,包括：2个IPV6基本首部,1个密钥MD5认证首部,1个
最大长度的TCP首部。
TCP-SPACE--TCP的最大CID值。
范围--3到255。
缺省值--15(给16个CID值)。
NO-TCP-SPACE--非TCP的最大CID值。
范围--3到65535。
缺省值--15(给16个CID值)。
摘自《网络通信世界》
