本發(fā)明提供了一種針對移動互聯(lián)網(wǎng)應(yīng)用的自適應(yīng)式的HTTP消息壓縮方法，涉及移動互聯(lián)網(wǎng)應(yīng)用，HTTP協(xié)議，HTTP壓縮，尤其涉及一種適用于小文本消息的壓縮方法。

背景技術(shù)：

隨著智能移動設(shè)備和移動互聯(lián)網(wǎng)應(yīng)用的飛速發(fā)展，HTTP幾乎已經(jīng)快成為一種通用的Web標(biāo)準(zhǔn)，Web Services、REST、Open API、OAuth等等都是基于HTTP協(xié)議的。它已經(jīng)不僅僅是Hyper Text的傳輸標(biāo)準(zhǔn)了，幾乎所有數(shù)據(jù)的傳輸(多媒體、XML、JSON)都可以采用HTTP只需要按照web開發(fā)流程就可以快速，穩(wěn)定，高效的架起一個服務(wù)器了。

技術(shù)實現(xiàn)要素：

本發(fā)明的目的在于針對現(xiàn)有的移動互聯(lián)網(wǎng)產(chǎn)品前后端消息交互方式，提供一種根據(jù)傳輸內(nèi)容大小不同而采取不同壓縮方式的壓縮方法，一定程度地壓縮前后端交互過程中經(jīng)由網(wǎng)絡(luò)傳輸?shù)腍TTP消息，從而有效地節(jié)約手機端的流量消耗。

本發(fā)明的目的是通過以下技術(shù)方案來實現(xiàn)的：在移動端與服務(wù)端進(jìn)行HTTP消息傳遞時，對待傳輸?shù)南Ⅲw的大小進(jìn)行計算，提供自適應(yīng)的消息壓縮方法，根據(jù)消息體大小不同，判斷采用不同壓縮方式進(jìn)行壓縮，將壓縮后的消息發(fā)送到消息接收方，消息接收方通過解壓方法將消息解壓成實際需要的消息格式。具體包括以下步驟：

(1)消息發(fā)送方的HTTP消息壓縮：消息發(fā)送方提供兩種不同的壓縮方法，第一種為基于LZ77算法以及哈夫曼編碼的壓縮方法，第二種為基于二進(jìn)制編碼的壓縮方法。消息發(fā)送方采用一種自適應(yīng)的方式進(jìn)行消息壓縮，即自動選擇上述兩種壓縮方法中的一種進(jìn)行消息壓縮，并修改HTTP頭信息中的Content-Type信息，以標(biāo)識消息經(jīng)由何種壓縮方法壓縮，將處理后的消息發(fā)送到消息接收方。

(2)消息接收方的HTTP消息解壓縮：消息接收方獲取到HTTP消息后，根據(jù)頭信息中的Content－Type，將消息體進(jìn)行解壓縮，恢復(fù)原始消息體內(nèi)容，并且修改HTTP頭信息中的Content－Type為原始消息格式。

進(jìn)一步地，所述步驟(1)中自適應(yīng)的方式選擇壓縮方法具體為：同時采用兩種壓縮方法壓縮消息體，隨后將二者的壓縮結(jié)果進(jìn)行比較，選取壓縮效果好的進(jìn)行傳輸，這種方式能夠更精準(zhǔn)的節(jié)約帶寬，但是一定程度上會增加消息發(fā)送端的計算資源消耗以及增加了壓縮消息所消耗的時間。

進(jìn)一步地，所述步驟(1)中自適應(yīng)的方式選擇壓縮方法具體為：制定一個閾值，根據(jù)消息體大小在哪一個區(qū)間而采用不同的壓縮方式。經(jīng)過調(diào)研和反復(fù)實驗，第一種壓縮方法對大文本壓縮效果較好，對小于一定大小的文本壓縮效果較差甚至無效果；第二種壓縮方法對小文本壓縮效果較好，對大于一定大小的文本壓縮效果較差甚至無效果。基于以上實驗結(jié)論，將原始消息體大小與閾值進(jìn)行比較，大于閾值則采用第一種壓縮方法進(jìn)行壓縮，小于閾值則采用第二種壓縮方法進(jìn)行壓縮。所述閾值的范圍為[2kb,5kb]。

進(jìn)一步地，所述基于LZ77算法以及哈夫曼編碼的壓縮方法具體為：對原始文本進(jìn)行LZ77算法壓縮后，再進(jìn)行動態(tài)的哈夫曼編碼壓縮；所述LZ77算法壓縮具體為：如果文本中有兩塊內(nèi)容相同的話，那么只要知道前一塊的位置和大小，就可以確定后一塊的內(nèi)容。進(jìn)而采用兩者之間的距離與相同內(nèi)容的長度這樣一對信息，來替換后一塊內(nèi)容，由于替換后的內(nèi)容長度會小于被替換內(nèi)容的大小，所以文本得到了壓縮；所述哈夫曼編碼壓縮具體為：哈夫曼編碼為一種可變字長的編碼方式，把文本中一定位長的值看作符號，比如把8位長的256種值，也就是字節(jié)的256種值看作是符號。根據(jù)這些符號在文件中出現(xiàn)的頻率，對這些符號重新編碼。對于出現(xiàn)次數(shù)非常多的，用較少的位來表示，對于出現(xiàn)次數(shù)非常少的，用較多的位來表示，這樣編碼后，文本的一些部分位數(shù)變少了，一些部分位數(shù)變多了，由于變小的部分比變大的部分多，整個文本的大小還是會減小，所以文本得到了壓縮。

進(jìn)一步地，所述基于二進(jìn)制編碼的壓縮方法具體為：傳統(tǒng)的HTTP消息序列化方式一般采用字節(jié)流或字符流傳輸，例如目前常見的JSON或XML等格式，這種序列化方式是將對象屬性以鍵值對的形式組織成字符串的一種編碼過程，為描述數(shù)據(jù)結(jié)構(gòu)而增加了很多且重復(fù)的屬性字符串以及標(biāo)點符號，從體積上看會比原始內(nèi)容增加很多。這也意味著字節(jié)流或字符流的序列化方式在傳輸內(nèi)容上有較大的可壓縮空間。二進(jìn)制序列化方式，則是直接將對象的內(nèi)存映射抽取出來直接形成二進(jìn)制流，相比之下省略了JSON或XML格式下冗余的屬性信息占用的傳輸空間，從而使HTTP消息體大小得到了壓縮。

本發(fā)明的有益效果是：本發(fā)明提供一種根據(jù)傳輸內(nèi)容大小不同而采取不同壓縮方式的壓縮方法，一定程度地壓縮前后端交互過程中經(jīng)由網(wǎng)絡(luò)傳輸?shù)腍TTP消息，從而有效地節(jié)約手機端的流量消耗。

附圖說明

圖1是本發(fā)明的采用擇優(yōu)策略的自適應(yīng)壓縮方法的消息發(fā)送端流程示意圖；

圖2是本發(fā)明的采用閾值策略的自適應(yīng)壓縮方法的消息發(fā)送端流程示意圖；

圖3是本發(fā)明的自適應(yīng)壓縮方法的消息接收端流程示意圖。

具體實施方式

下面結(jié)合附圖詳細(xì)描述本發(fā)明，本發(fā)明的目的和效果將變得更加明顯。

本發(fā)明一種針對移動互聯(lián)網(wǎng)應(yīng)用節(jié)約帶寬的自適應(yīng)式的HTTP消息壓縮方法，具體實施方式包括以下步驟：

(1)消息發(fā)送端進(jìn)行消息壓縮的流程，在實際應(yīng)用中，根據(jù)采用不同的自適應(yīng)壓縮策略而略有不同。

采用兩種壓縮方式并行壓縮，根據(jù)壓縮效果擇優(yōu)發(fā)送的策略下的流程如圖1所示，首先并行進(jìn)行兩種壓縮方式對消息體進(jìn)行壓縮，一種是基于LZ77算法或變體算法以及哈夫曼編碼的壓縮方法，可選用GZIP壓縮方式實現(xiàn)，GZIP方法是對原始文本進(jìn)行LZ77變體算法壓縮后，再進(jìn)行動態(tài)的哈弗曼編碼壓縮的一種方法；另一種是基于二進(jìn)制編碼的壓縮方法，可采用Google Protocol Buffer(以下簡稱為GPB)編碼格式來實現(xiàn)。比較兩種壓縮方法的壓縮結(jié)果，選擇壓縮后體積更小的結(jié)果發(fā)送。

采用消息體大小閾值策略的流程如圖2所示，消息發(fā)送端提供一個攔截器，首先在消息發(fā)送之前，計算原始消息體的大小，以二進(jìn)制位為單位，根據(jù)消息體大小判斷采用何種消息壓縮方式。消息發(fā)送端的攔截器提供兩種不同的壓縮方式，一種是基于LZ77算法或變體算法以及哈夫曼編碼的壓縮方法，可選用GZIP壓縮方式實現(xiàn)，GZIP方法是對原始文本進(jìn)行LZ77變體算法壓縮后，再進(jìn)行動態(tài)的哈弗曼編碼壓縮的一種方法；另一種是基于二進(jìn)制編碼的壓縮方法，可采用Google Protocol Buffer(以下簡稱為GPB)編碼格式來實現(xiàn)。

采用閾值策略的自適應(yīng)方法時，需要制定一個閾值，作為選用何種壓縮方案的依據(jù)。經(jīng)過反復(fù)實驗，已發(fā)現(xiàn)GZIP壓縮方法對小于一定大小的文本內(nèi)容壓縮效果較差，GPB編碼方法對大于一定大小的文本壓縮效果較差。判定閾值可以設(shè)定為[2kb,5kb]，優(yōu)選2kb，即待傳輸消息體的大小大于2kb，則調(diào)用GZIP壓縮方法進(jìn)行壓縮，待傳輸消息體大小小于2kb，則調(diào)用GPB壓縮方法將原始內(nèi)容轉(zhuǎn)換成GPB編碼格式。

采用根據(jù)壓縮效果擇優(yōu)的策略，可以確保體積壓縮最小化，以更加精確的節(jié)約網(wǎng)絡(luò)傳輸流量，另一方面則會更多的消耗計算資源以及增加了消息壓縮所用的時間。采用閾值策略的自適應(yīng)壓縮方法，根據(jù)經(jīng)驗預(yù)測大概率下應(yīng)采用何種壓縮方法能使壓縮結(jié)果最優(yōu)，可以很好的節(jié)約壓縮消耗的時間成本與計算資源，更加省電以及降低網(wǎng)絡(luò)延時。在實際實施中，可結(jié)合實際需求，具體情況具體分析，綜合考慮選擇何種自適應(yīng)壓縮策略。

壓縮后的消息需要在頭信息中修改消息類型屬性，以便消息接收方判定消息體是經(jīng)由何種壓縮方式壓縮的。之后消息發(fā)送端將處理好的HTTP消息發(fā)送給消息接收端。

(2)消息接收端進(jìn)行消息解壓縮的流程如圖2所示，消息接收端提供一個攔截器，首先，在獲取到HTTP消息時，解析頭信息，根據(jù)消息格式不同，相應(yīng)的調(diào)用不同的解壓縮方法對收到的消息體進(jìn)行解壓縮：相對于步驟(1)，消息接收端的攔截器提供兩種不同的解壓縮方法，消息格式判定為GZIP編碼時，調(diào)用GZIP解壓縮方法將消息體轉(zhuǎn)換成原始消息格式，并修改HTTP頭信息中的消息格式為原始消息格式；消息格式判定為GPB編碼時，調(diào)用GPB解壓縮方法將消息體轉(zhuǎn)換成原始消息格式，并修改HTTP頭信息中的消息格式為原始消息格式。攔截器將轉(zhuǎn)換后的HTTP消息發(fā)送給真正的消息接收接口。

進(jìn)一步地，在實際應(yīng)用中，手機端與服務(wù)端需要雙向進(jìn)行消息壓縮與解壓縮，即手機端應(yīng)用既要作為步驟(1)所述的消息發(fā)送方，又要作為步驟(2)所述的消息接收方；服務(wù)端也是同理。所以，手機端與服務(wù)端都需要同時配有消息壓縮攔截器和消息解壓縮攔截器。