[發明專利]一種窄帶串行鏈路TCP報文頭部壓縮的改進方法

有效

• 申請號: 201410015437.2
• 申請日: 2014-01-14
• 公開（公告）號: CN103746930B
• 公開（公告）日: 2017-09-19
• 發明（設計）人: 李世釗;康宗緒;瞿輝;鄭直;李云峰;于進強;郝青峰
• 申請（專利權）人: 重慶金美通信有限責任公司
• 主分類號: H04L12/801
• 分類號: H04L12/801;H04L12/851;H04L12/741
• 代理公司: 暫無信息
• 代理人: 暫無信息

技術領域

本發明涉及一種適用于窄帶串行鏈路TCP/IP的報文頭部壓縮方法。該方法可以實現對TCP/IP協議報文的壓縮和解壓縮，從而減少鏈路中傳輸的開銷，節約鏈路帶寬資源。

背景技術

CTCP頭壓縮遵循RFC1144協議，該方案由LBL實驗室的Van Jacobson在1990年2月發明。這是一種在低速串行鏈路上能夠提高TCP/IP頭標傳輸效率的基本壓縮方法。它可以將40字節的TCP/IP頭標壓縮到4字節。該方法采用計時超時的差錯恢復機制，因此不適合在來回響應時間較長的鏈路上使用。

IPHC頭壓縮遵循RFC2507協議HJ，該方案由瑞典Lulea大學的Dr Stephen，Dr Mikael等在1999年2月提出。IPHC頭壓縮是對CTCP稍作改進后的一種常規的IP頭標壓縮方案，它可以壓縮任意的IP、TCP和UDP頭。它適合在低速和中速鏈路上壓縮數據業務。

目前的TCP/IP壓縮方法都是依據同一個流的數據報頭之間的相關性進行壓縮的，存在的問題是當發送節點發送的數據報文在鏈路上丟失，解壓端將無法接收到這個壓縮報文，也就無法更新上下文。但是壓縮端進行壓縮處理的過程中已經更新了上下文信息。對于后續報文，壓縮端將會根據新的上下文進行壓縮，但解壓端卻仍然使用舊上下文來解壓，如果上下文不及時同步，重構的IP報文在一段時間內都不正確。

發明內容

為解決上述問題，本發明提供如下技術方案，該方法包括如下模塊：

鏈路質量檢測模塊：定時檢查和預測鏈路質量情況，用于決策壓縮處理方式及時將鏈路質量情況通告給QoS模塊；QoS模塊：在壓縮端是根據當前鏈路質量情況對報文進行流量整形和限速處理。在解壓端需保證頭部請求報文優先于其他報文，目的盡可能使兩端上下文同步。決策模塊：決定壓縮和解壓是標準RFC協議的處理方式還是改進后的方式處理；壓縮模塊：按照標準協議正確地壓縮處理；改進的壓縮模塊：對現有的壓縮報文基礎上進行改進，能夠減少1字節的傳輸；解壓模塊：按照標準RFC正確解壓；改進的解壓模塊：對改進后的壓縮報文正確地解壓，重構IP報文后上送到IP層。

本發明的有益效果是：通過對鏈路的監控預測技術和QoS使壓縮端和解壓端的上下文盡可能保持一致；并對原有壓縮報文的改進，使現有技術中的CTCP報文能夠進一步得到壓縮，節約帶寬，提高傳輸效率。

附圖說明

圖1、本發明壓縮/解壓模塊分解圖。

圖2、現有CTCP壓縮報文格式。

圖3、改進CTCP壓縮報文格式。

圖4、壓縮端流程圖。

圖5、解壓端流程圖。

具體實施方式

下面結合附圖對本發明實施中的技術方案做出說明。附圖用于幫助理解實施例的技術方案。圖4和圖5是壓縮端和解壓端的流程圖。主要處理步驟如下。

壓縮端的處理流程：

步驟1.對于要發送的TCP報文，首先由壓縮端的鏈路檢測模塊對鏈路質量進行檢測，將

將鏈路質量情況通告給QoS模塊。

步驟2.決策模塊決定是否可以按標準RFC處理，如果可以，跳至步驟6；否則，跳至步驟3。

步驟3. 通過CID在上下文列表中查找，如果沒有找到該CID的上下文信息，則發送全頭部報文。

步驟4. 如果是壓縮報文，構造壓縮報文。結合圖2，虛框內字段是在壓縮報文中攜帶的內容，經過對原有TCP頭部壓縮報文分析，其中C比特屬于必須攜帶的字段，而U比特和P比特屬于不會頻繁出現的字段，而I、S、A和W比特是在同一報文流中的不同壓縮報文中發生變化的，對于這幾個比特的常用變化組合和點對點鏈路層協議域的類型相結合，將變化比特通過協議域字段攜帶出去，這樣壓縮端不需要將變化域字節攜帶出去，僅僅將變化量攜帶出去即可。改進后的壓縮報文格式參見圖3，報文字段位置和原來的壓縮報文格式相同。例如I 、S 和A發生變化則將鏈路層協議字段封裝成0x60，該字段同時也標識出哪些比特發生變化，解壓端通過協議域進行不同處理。 通過上面處理能夠在原來的壓縮報文基礎上節約一個字節。

步驟5.發送壓縮報文。如果更新了壓縮端的上下文而沒有更新解壓端的上下文會導致兩端的信息不同步，所以在這里不去更新壓縮端上下文信息，而是將上下文信息標識為“不可用”狀態，同時通知QoS模塊進行流量控制和壓縮報文優先級保障處理。等到下一次接收到IP報文，通過重新發送全頭部信息來保證壓縮端和解壓端的上下文同步。

步驟6.按照標準RFC協議進行處理。

解壓端的處理流程：