一种窄带串行链路tcp报文头部压缩的改进方法
【专利摘要】本发明提供一种改进窄带串行链路TCP报文头部压缩方法，该方法包括：链路质量检测模块：定时检查和预测链路质量情况，及时将链路质量情况通告给QoS模块；QoS模块：压缩端是根据当前链路质量情况对报文进行流量整形和限速处理。解压端需保证头部请求报文优先于其他报文。决策模块：决定压缩和解压是否按照改进后的方式处理；改进的压缩模块：对现有的压缩报文基础上进行改进，能够减少1字节的传输；改进的解压模块：对改进后的压缩报文正确地解压，重构IP报文后上送到IP层。本发明的有益增益效果是：通过QoS使压缩端和解压端的上下文尽可能保持一致，通过对原有压缩报文的改进，使现有技术中的CTCP报文能够进一步得到压缩，利用本发明节约带宽，提高传输效率。
【专利说明】—种窄带串行链路TCP报文头部压缩的改进方法
【技术领域】
[0001]本发明涉及一种适用于窄带串行链路TCP/IP的报文头部压缩方法。该方法可以实现对TCP/IP协议报文的压缩和解压缩，从而减少链路中传输的开销，节约链路带宽资源。
【背景技术】
[0002]CTCP头压缩遵循RFCl 144协议，该方案由LBL实验室的Van Jacobson在1990年2月发明。这是一种在低速串行链路上能够提高TCP/IP头标传输效率的基本压缩方法。它可以将40字节的TCP/IP头标压缩到4字节。该方法采用计时超时的差错恢复机制，因此不适合在来回响应时间较长的链路上使用。
[0003]IPHC头压缩遵循RFC2507协议HJ，该方案由瑞典Lulea大学的Dr Stephen, DrMikael等在1999年2月提出。IPHC头压缩是对CTCP稍作改进后的一种常规的IP头标压缩方案，它可以压缩任意的IP、TCP和UDP头。它适合在低速和中速链路上压缩数据业务。
[0004]目前的TCP/IP压缩方法都是依据同一个流的数据报头之间的相关性进行压缩的，存在的问题是当发送节点发送的数据报文在链路上丢失，解压端将无法接收到这个压缩报文，也就无法更新上下文。但是压缩端进行压缩处理的过程中已经更新了上下文信息。对于后续报文，压缩端将会根据新的上下文进行压缩，但解压端却仍然使用旧上下文来解压，如果上下文不及时同步，重构的IP报文在一段时间内都不正确。
【发明内容】
[0005]为解决上述问题，本发明提供如下技术方案，该方法包括如下模块:
链路质量检测模块:定时检查和预测链路质量情况，用于决策压缩处理方式及时将链路质量情况通告给QoS模块；QoS模块:在压缩端是根据当前链路质量情况对报文进行流量整形和限速处理。在解压端需保证头部请求报文优先于其他报文，目的尽可能使两端上下文同步。决策模块:决定压缩和解压是标准RFC协议的处理方式还是改进后的方式处理；压缩模块:按照标准协议正确地压缩处理；改进的压缩模块:对现有的压缩报文基础上进行改进，能够减少I字节的传输；解压模块:按照标准RFC正确解压；改进的解压模块:对改进后的压缩报文正确地解压，重构IP报文后上送到IP层。
[0006]本发明的有益效果是:通过对链路的监控预测技术和QoS使压缩端和解压端的上下文尽可能保持一致；并对原有压缩报文的改进，使现有技术中的CTCP报文能够进一步得到压缩，节约带宽，提高传输效率。
【专利附图】
【附图说明】
[0007]图1、本发明压缩/解压模块分解图。
[0008]图2、现有CTCP压缩报文格式。
[0009]图3、改进CTCP压缩报文格式。[0010]图4、压缩端流程图。
[0011]图5、解压端流程图。
【具体实施方式】
[0012]下面结合附图对本发明实施中的技术方案做出说明。附图用于帮助理解实施例的技术方案。图4和图5是压缩端和解压端的流程图。主要处理步骤如下。
[0013]压缩端的处理流程:
步骤1.对于要发送的TCP报文，首先由压缩端的链路检测模块对链路质量进行检测，
将
将链路质量情况通告给QoS模块。
[0014]步骤2.决策模块决定是否可以按标准RFC处理，如果可以，跳至步骤6 ;否则，跳至步骤3。
[0015]步骤3.通过CID在上下文列表中查找，如果没有找到该CID的上下文信息，则发送全头部报文。
[0016]步骤4.如果是压缩报文，构造压缩报文。结合图2，虚框内字段是在压缩报文中携带的内容，经过对原有TCP头部压缩报文分析，其中C比特属于必须携带的字段，而U比特和P比特属于不会频繁出现的字段，而1、S、A和W比特是在同一报文流中的不同压缩报文中发生变化的，对于这几个比特的常用变化组合和点对点链路层协议域的类型相结合，将变化比特通过协议域字段携带出去，这样压缩端不需要将变化域字节携带出去，仅仅将变化量携带出去即可。改进后的压缩报文格式参见图3，报文字段位置和原来的压缩报文格式相同。例如1、S和A发生变化则将链路层协议字段封装成0x60，该字段同时也标识出哪些比特发生变化，解压端通过协议域进行不同处理。通过上面处理能够在原来的压缩报文基础上节约一个字节。
[0017]步骤5.发送压缩报文。如果更新了压缩端的上下文而没有更新解压端的上下文会导致两端的信息不同步，所以在这里不去更新压缩端上下文信息，而是将上下文信息标识为“不可用”状态，同时通知QoS模块进行流量控制和压缩报文优先级保障处理。等到下一次接收到IP报文，通过重新发送全头部信息来保证压缩端和解压端的上下文同步。
[0018]步骤6.按照标准RFC协议进行处理。
[0019]解压端的处理流程:
步骤1.接收到数据帧后，由决策模块是否可以按照标准协议处理，如果可以，按照标准协议处理；否则按照，改进后的方式处理。
[0020]步骤2.如果是全头部帧，记录该CID的上下文，恢复IP协议号后将数据报文上送给IP层。
[0021]步骤3.如果是压缩帧，如果是原有报文格式，按照标准RFC进行处理；否则，如果链路层协议域是新类型，不是根据变化比特码的处理变化量字段，而是根据链路层协议域的类型字段对头部报文进行正确地解析来恢复上下文，重构IP报文并上送到IP层。
【权利要求】
1.一种改进窄带串行链路TCP报文头部压缩方法，其特征在于:通过对链路的监控预测技术和QoS使压缩端和解压端的上下文尽可能保持同步；并对原有压缩报文的改进，使现有技术中的CTCP报文能够进一步得到压缩，利用本发明可以节约带宽，提高传输效率。
2.根据权利要求1所述的方法，其压缩端特征在于: 步骤1.对于要发送的TCP报文，首先由压缩端的链路检测模块对链路质量进行检测，将将链路质量情况通告给QoS模块； 步骤2.决策模块决定是否可以按标准RFC处理，如果可以，跳至步骤6 ;否则，跳至步骤3 ; 步骤3.通过CID在上下文列表中查找，如果没有找到该CID的上下文信息，则发送全头部报文； 步骤4.如果是压缩报文，构造压缩报文；结合图2，虚框内字段是在压缩报文中携带的内容，经过对原有TCP头部压缩报文分析，其中C比特属于必须携带的字段，而U比特和P比特属于不会频繁出现的字段，而1、S、A和W比特是在同一报文流中的不同压缩报文中发生变化的，对于这几个比特的常用变化组合和点对点链路层协议域的类型相结合，将变化比特通过协议域字段携带出去，这样压缩端不需要将变化域字节携带出去，仅仅将变化量携带出去即可；改进后的压缩报文格式参见图3，报文字段位置和原来的压缩报文格式相同；例如1、S和A发生变化则将链路层协议字段封装成0x60，该字段同时也标识出哪些比特发生变化，解压端通过协议域进行不同处理；通过上面处理能够在原来的压缩报文基础上节约一个字节； 步骤5.发送压缩报文；如果更新了压缩端的上下文而没有更新解压端的上下文会导致两端的信息不同步，所以在这里不去更新压缩端上下文信息，而是将上下文信息标识为“不可用”状态，同时通知QoS模块进行流量控制和压缩报文优先级保障处理；等到下一次接收到IP报文，通过重新发送全头部信息来保证压缩端和解压端的上下文同步； 步骤6.按照标准RFC协议进行处理。
3.根据权利要求1所述的方法，其解压端特征在于: 步骤1.接收到数据帧后，由决策模块是否可以按照标准协议处理，如果可以，按照标准协议处理；否则按照，改进后的方式处理； 步骤2.如果是全头部帧，记录该CID的上下文，恢复IP协议号后将数据报文上送给IP层； 步骤3.如果是压缩帧，如果是原有报文格式，按照标准RFC进行处理；否则，如果链路层协议域是新类型，不是根据变化比特码的处理变化量字段，而是根据链路层协议域的类型字段对头部报文进行正确地解析来恢复上下文，重构IP报文并上送到IP层。
【文档编号】H04L12/741GK103746930SQ201410015437
【公开日】2014年4月23日 申请日期:2014年1月14日 优先权日:2014年1月14日
【发明者】李世钊, 康宗绪, 瞿辉, 郑直, 李云峰, 于进强, 郝青峰 申请人:重庆金美通信有限责任公司