本發(fā)明涉及但不限于物聯(lián)網(wǎng)通信技術(shù)，尤指一種實現(xiàn)數(shù)據(jù)傳輸?shù)姆椒把b置。

背景技術(shù)：

物聯(lián)網(wǎng)(iot，internetofthings)是當(dāng)前通信技術(shù)發(fā)展的重大趨勢。近年來，一方面，無論是第三代合作伙伴計劃(3gpp)等大型規(guī)范組織，還是各國網(wǎng)絡(luò)運營商，終端廠商，都開始向低端挖掘，以尋求低速率，低帶寬，低耗電的技術(shù)方向。另一方面，物聯(lián)網(wǎng)對終端功耗的要求非?？量獭Ｒ虼?，提高數(shù)據(jù)傳輸效率，降低功耗，延長終端設(shè)備的電池使用時間，是一個重要的研究方向。

再者，物聯(lián)網(wǎng)應(yīng)用場景的數(shù)據(jù)傳輸具有特殊性。

比如：物聯(lián)網(wǎng)終端功能上的針對性決定了其傳輸數(shù)據(jù)包的規(guī)律性。如用于定位的tracker類裝置與網(wǎng)絡(luò)側(cè)交互的數(shù)據(jù)包大部分是用戶的位置信息；用于計量的水電氣表即meter類裝置，與網(wǎng)絡(luò)側(cè)交互的數(shù)據(jù)包大部分是計量數(shù)據(jù)的統(tǒng)計信息。而相對于移動終端如手機等這種復(fù)雜設(shè)備而言，這些物聯(lián)網(wǎng)終端傳輸?shù)臄?shù)據(jù)的格式和類型相對都比較單一。

又如：物聯(lián)網(wǎng)上行數(shù)據(jù)包內(nèi)容比例較大。無線物聯(lián)網(wǎng)終端和傳感器是緊密相關(guān)的，通常都具有數(shù)據(jù)采集并上報服務(wù)器的特性。如抄表器定期發(fā)送計量數(shù)據(jù)、定位器上報位置信息等等。與移動終端如手機、ipad類產(chǎn)品在數(shù)據(jù)量上以及用戶意圖上以接收即下行數(shù)據(jù)為主不同的是，物聯(lián)網(wǎng)終端常常需要上報傳感器采集到的數(shù)據(jù)，因此上行數(shù)據(jù)的比例相對比較大，終端常常會在用戶不主動干預(yù)的情況下，周期性、自發(fā)的與網(wǎng)絡(luò)進行交互，一般是長年累月的不間斷工作，這樣一來，數(shù)據(jù)的總量就會非常龐大。而且相對于接收來說，發(fā)送數(shù)據(jù)對于接收而言，對終端的功耗更大，因此，對物聯(lián)網(wǎng)上行數(shù)據(jù)傳輸?shù)膬?yōu)化，對于整體系統(tǒng)的功耗優(yōu)化是非常有意義的。

再如：物聯(lián)網(wǎng)應(yīng)用通常是客戶端/服務(wù)器結(jié)構(gòu)。應(yīng)用提供商通常需要提供終端和應(yīng)用服務(wù)器。隨著技術(shù)上對物聯(lián)網(wǎng)不斷深入的研究，也出現(xiàn)了一些優(yōu)化傳輸方面的新方案，但是基本上都需要終端和無線側(cè)網(wǎng)元的配合才能實現(xiàn)，即需要網(wǎng)絡(luò)運營商提供特殊硬件支持。這種技術(shù)實現(xiàn)起來相當(dāng)復(fù)雜，一般需要國際大型協(xié)議組織和設(shè)備制造商大力推動才有可能實現(xiàn)。

相關(guān)技術(shù)方案中，基本就是標(biāo)準(zhǔn)的傳輸控制協(xié)議/網(wǎng)際協(xié)議(tcp/ip)和3gpp的無線協(xié)議傳輸方案。針對物聯(lián)網(wǎng)特性，3gpp在增強機器類通信(emtc)協(xié)議和基于蜂窩的窄帶物聯(lián)網(wǎng)(nb-iot，narrowbandinternetofthings)協(xié)議中也提出了一些針對傳輸方面的特性優(yōu)化，比如：通過信令面?zhèn)鬏斝?shù)據(jù)，以減少終端從空閑(idle)態(tài)到連接態(tài)的無線承載建立次數(shù)，加快發(fā)送等。

在3gpp標(biāo)準(zhǔn)中，對于降功耗和優(yōu)化傳輸效率的方法基本都有兩個特性，第一是需要終端底層硬件支持，實現(xiàn)復(fù)雜；第二是需要終端和網(wǎng)絡(luò)側(cè)都有相應(yīng)的功能模塊實現(xiàn)才能支持，但是，這些是需要標(biāo)準(zhǔn)組織推動，網(wǎng)絡(luò)運營商支持才能實現(xiàn)的功能，成本很高。

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

為了解決上述技術(shù)問題，本發(fā)明提供一種數(shù)據(jù)傳輸方法及裝置，能夠簡單地實現(xiàn)實際傳輸?shù)臄?shù)據(jù)量的減少，而且成本低。

為了達到本發(fā)明目的，本發(fā)明提供了一種數(shù)據(jù)傳輸方法，包括：

利用預(yù)先獲得的壓縮策略對待發(fā)送的第一數(shù)據(jù)包進行處理，刪除第一數(shù)據(jù)包中根據(jù)所述壓縮策略指定的重復(fù)數(shù)據(jù)；

將處理后的所述第一待數(shù)據(jù)包生成待發(fā)送的第二數(shù)據(jù)包，其中所述第二數(shù)據(jù)包中包括用于指示根據(jù)所述壓縮策略刪除重復(fù)數(shù)據(jù)的修改記錄字段；

將所述第二數(shù)據(jù)包發(fā)送給接收端。

可選地，所述利用預(yù)設(shè)的壓縮策略對待發(fā)送的第一數(shù)據(jù)包進行處理之前，還包括確認(rèn)所述接收端支持壓縮傳輸能力，包括：

向所述接收端發(fā)送查詢請求，接收到所述接收端的回應(yīng)后確定所述接收端支持壓縮傳輸能力；或者，

查詢與所述接收端的數(shù)據(jù)傳輸記錄，根據(jù)存儲記錄確定所述接收端支持壓縮傳輸能力。

可選地，所述方法還包括：

當(dāng)確認(rèn)所述接收端不支持壓縮傳輸能力時，對所述第一數(shù)據(jù)包不進行處理，直接發(fā)送給所述接收端。

可選地，所述利用預(yù)先獲得的壓縮策略對待發(fā)送的第一數(shù)據(jù)包進行處理，刪除第一數(shù)據(jù)包中壓縮策略指定的重復(fù)數(shù)據(jù)包括：

周期性將所述第一數(shù)據(jù)包和所述壓縮策略中與第一數(shù)據(jù)包的目的地址一致的規(guī)則進行比較，檢查該第一數(shù)據(jù)包中的字段或內(nèi)容是否與該規(guī)則中描述的相應(yīng)字段或內(nèi)容相同；

如果相同，刪除該第一數(shù)據(jù)包中所述字段或者內(nèi)容。

可選地，所述壓縮策略包括協(xié)議類規(guī)則或內(nèi)容類規(guī)則；所述協(xié)議類規(guī)則是通過協(xié)議類型來區(qū)分的規(guī)則，所述內(nèi)容類規(guī)則是通過應(yīng)用類型來區(qū)分的規(guī)則；

所述利用預(yù)先獲得的壓縮策略對待發(fā)送的第一數(shù)據(jù)包進行處理，刪除第一數(shù)據(jù)包中壓縮策略指定的重復(fù)數(shù)據(jù)包括：

如果所述壓縮策略中存儲有與所述第一數(shù)據(jù)包的目的地址一致的協(xié)議類規(guī)則，或者，如果所述壓縮策略中未存儲與所述第一數(shù)據(jù)包的目的地址一致的協(xié)議類規(guī)則，但存儲有與所述第一數(shù)據(jù)包的目的地址一致的內(nèi)容類規(guī)則，則，周期性將所述第一數(shù)據(jù)包和所述協(xié)議類規(guī)則進行比較，檢查該第一數(shù)據(jù)包中的字段或內(nèi)容是否與該協(xié)議類規(guī)則描述中的相應(yīng)字段或內(nèi)容相同；如果相同，刪除該第一數(shù)據(jù)包中的所述字段或內(nèi)容。

可選地，所述修改記錄字段設(shè)置在所述第二數(shù)據(jù)包的負(fù)載的開始部分；

所述修改記錄字段包括三個部分：

規(guī)則使能指示，用于表示該修改記錄字段所在的數(shù)據(jù)包是否已執(zhí)行過所述對待發(fā)送的數(shù)據(jù)包進行處理的步驟；

規(guī)則類型指示，用于表示對所述數(shù)據(jù)包的處理所采用的規(guī)則的類型；

規(guī)則號，用于表示對所述數(shù)據(jù)包的處理所使用的規(guī)則。

本申請還提供了一種數(shù)據(jù)傳輸方法，包括：

收到來自發(fā)送端的第二數(shù)據(jù)包，檢查出第二數(shù)據(jù)包中攜帶有用于指示根據(jù)所述壓縮策略刪除重復(fù)數(shù)據(jù)的修改記錄字段；

根據(jù)該修改記錄字段以及生成的壓縮策略對第二數(shù)據(jù)包進行恢復(fù)處理，以生成第一數(shù)據(jù)包。

可選地，還包括：

周期性的檢測所述第二數(shù)據(jù)包，生成指定有重復(fù)數(shù)據(jù)的所述壓縮策略。

可選地，所述生成壓縮策略包括：

對所述第二數(shù)據(jù)包周期性或連續(xù)采樣，對預(yù)設(shè)數(shù)量個第二數(shù)據(jù)包中的每個字段進行比對，提取出相同的字段信息作為所述壓縮策略指定的重復(fù)數(shù)據(jù)；或者，

對特定應(yīng)用程序的端口進行采樣，對從該端口連續(xù)收到預(yù)設(shè)數(shù)量個第二數(shù)據(jù)包進行數(shù)據(jù)部分的比對，提取出相同的數(shù)據(jù)內(nèi)容作為所述壓縮策略指定的重復(fù)數(shù)據(jù)。

可選地，如果所述壓縮策略發(fā)生變化，所述方法還包括：

向所述發(fā)送端發(fā)送更新請求消息，更新請求消息中攜帶有發(fā)生變化的規(guī)則和對應(yīng)的規(guī)則號，以及新規(guī)則的內(nèi)容。

可選地，所述修改記錄字段設(shè)置在所述第二數(shù)據(jù)包的負(fù)載的開始部分；

所述修改記錄字段包括三個部分：

規(guī)則使能指示，用于表示該修改記錄字段所在的數(shù)據(jù)包是否已執(zhí)行過所述對接收到的所述數(shù)據(jù)包進行處理的步驟；

規(guī)則類型指示，用于表示對所述數(shù)據(jù)包的處理所采用的規(guī)則的類型；

規(guī)則號，用于表示對所述數(shù)據(jù)包的處理所使用的規(guī)則。

可選地，所述根據(jù)該修改記錄字段以及生成的壓縮策略對數(shù)據(jù)包進行恢復(fù)處理，以生成第一數(shù)據(jù)包包括：

如果所述修改記錄字段中的規(guī)則使能指示有效，則根據(jù)接收到的所述數(shù)據(jù)包的源地址和所述修改記錄字段中的規(guī)則類型、規(guī)則號，查找所述服務(wù)器中對應(yīng)的壓縮策略，并利用該壓縮策略指定的重復(fù)數(shù)據(jù)恢復(fù)接收到的所述第二數(shù)據(jù)包得到所述第一數(shù)據(jù)包。

本申請又提供了一種數(shù)據(jù)傳輸裝置，包括壓縮模塊、處理模塊、發(fā)送模塊，以及用于存儲壓縮策略的第一存儲模塊；其中，

壓縮模塊，用于利用第一存儲模塊中的壓縮策略對待發(fā)送的第一數(shù)據(jù)包進行處理，刪除第一數(shù)據(jù)包中壓縮策略指定的重復(fù)數(shù)據(jù)；

處理模塊，用于將處理后的所述第一待數(shù)據(jù)包生成待發(fā)送的第二數(shù)據(jù)包，其中所述第二數(shù)據(jù)包中包括用于指示根據(jù)所述壓縮策略刪除重復(fù)數(shù)據(jù)的修改記錄字段；

發(fā)送模塊，用于發(fā)送第二數(shù)據(jù)包。

可選地，所述裝置還包括：檢測模塊，用于確認(rèn)所述接收端支持壓縮傳輸能力并觸發(fā)所述壓縮模塊進行處理；其中確認(rèn)所述接收端支持壓縮傳輸能力包括：

向所述接收端發(fā)送查詢請求，接收到所述接收端的回應(yīng)后確定所述接收端支持壓縮傳輸能力；或者，

查詢與所述接收端的數(shù)據(jù)傳輸記錄，根據(jù)存儲記錄確定所述接收端支持壓縮傳輸能力。

可選地，所述檢測模塊還用于：當(dāng)確認(rèn)所述接收端不支持壓縮傳輸能力時，對所述第一數(shù)據(jù)包不進行處理，直接發(fā)送給所述接收端。

可選地，所述壓縮模塊具體用于：

周期性將所述第一數(shù)據(jù)包和所述壓縮策略中與所述第一數(shù)據(jù)包的目的地址一致的規(guī)則進行比較，檢查該第一數(shù)據(jù)包中的字段后內(nèi)容是否與該規(guī)則描述中的相應(yīng)字段或內(nèi)容相同；

如果相同，刪除該第一數(shù)據(jù)包中的所述字段或內(nèi)容。

可選地，所述壓縮策略包括協(xié)議類規(guī)則或內(nèi)容類規(guī)則；所述協(xié)議類規(guī)則是通過協(xié)議類型來區(qū)分的規(guī)則，所述內(nèi)容類規(guī)則是通過應(yīng)用類型來區(qū)分的規(guī)則；

所述壓縮模塊具體用于：

如果所述壓縮策略中存儲有與所述第一數(shù)據(jù)包的目的地址一致的協(xié)議類規(guī)則，或者，如果所述壓縮策略中未存儲與所述第一數(shù)據(jù)包的目的地址一致的協(xié)議類規(guī)則，但存儲有與所述第一數(shù)據(jù)包的目的地址一致的內(nèi)容類規(guī)則，則，周期性將所述第一數(shù)據(jù)包和所述協(xié)議類規(guī)則進行比較，檢查第一數(shù)據(jù)包中的字段或內(nèi)容是否與該協(xié)議類規(guī)則描述中的相應(yīng)字段或內(nèi)容相同；如果相同，刪除該第一數(shù)據(jù)包中的所述字段或內(nèi)容。

可選地，所述修改記錄字段設(shè)置在所述第二數(shù)據(jù)包的負(fù)載的開始部分；

所述修改記錄字段包括三個部分：

規(guī)則使能指示，用于表示該修改記錄字段所在的數(shù)據(jù)包是否已執(zhí)行過所述對待發(fā)送的數(shù)據(jù)包進行處理的步驟；

規(guī)則類型指示，用于表示對所述數(shù)據(jù)包的處理所采用的規(guī)則的類型；

規(guī)則號，用于表示對所述數(shù)據(jù)包的處理所使用的規(guī)則。

本申請再提供了一種終端，包括上述任一項所述的數(shù)據(jù)傳輸裝置。

與現(xiàn)有技術(shù)相比，本申請至少包括：利用預(yù)先獲得的壓縮策略對待發(fā)送的第一數(shù)據(jù)包進行處理，刪除第一數(shù)據(jù)包中根據(jù)所述壓縮策略指定的重復(fù)數(shù)據(jù)；將處理后的所述第一待數(shù)據(jù)包生成待發(fā)送的第二數(shù)據(jù)包，其中所述第二數(shù)據(jù)包中包括用于指示根據(jù)所述壓縮策略刪除重復(fù)數(shù)據(jù)的修改記錄字段；將所述第二數(shù)據(jù)包發(fā)送給接收端。通過本發(fā)明提供的實現(xiàn)數(shù)據(jù)傳輸?shù)姆椒ǎ瑒h除了待發(fā)送的數(shù)據(jù)包中重復(fù)發(fā)送的信息，減少了實際傳輸?shù)臄?shù)據(jù)量。本發(fā)明方法并不需要額外的硬件支持，就簡單地實現(xiàn)了實際傳輸?shù)臄?shù)據(jù)量的減少，從而節(jié)約了成本。

本發(fā)明的其它特征和優(yōu)點將在隨后的說明書中闡述，并且，部分地從說明書中變得顯而易見，或者通過實施本發(fā)明而了解。本發(fā)明的目的和其他優(yōu)點可通過在說明書、權(quán)利要求書以及附圖中所特別指出的結(jié)構(gòu)來實現(xiàn)和獲得。

附圖說明

此處所說明的附圖用來提供對本發(fā)明的進一步理解，構(gòu)成本申請的一部分，本發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的不當(dāng)限定。在附圖中：

圖1為本發(fā)明實施例中實現(xiàn)數(shù)據(jù)傳輸?shù)囊环N方法的流程圖；

圖2為本發(fā)明實施例中實現(xiàn)數(shù)據(jù)傳輸?shù)牧硪环N方法的流程圖；

圖3為本發(fā)明實現(xiàn)數(shù)據(jù)傳輸?shù)姆椒ㄖ袑崿F(xiàn)壓縮傳輸能力查詢與壓縮策略同步的實施例的流程示意圖；

圖4為本發(fā)明實施例中協(xié)議類規(guī)則的結(jié)構(gòu)的示意圖；

圖5為本發(fā)明實施例中內(nèi)容類規(guī)則的結(jié)構(gòu)的示意圖；

圖6為本發(fā)明實施例中解壓信息的結(jié)構(gòu)的示意圖；

圖7為本發(fā)明實現(xiàn)數(shù)據(jù)傳輸?shù)牡谝粚嵤├牧鞒虉D示意圖；

圖8為本發(fā)明實現(xiàn)數(shù)據(jù)傳輸?shù)牡诙嵤├牧鞒虉D示意圖；

圖9為本發(fā)明實現(xiàn)數(shù)據(jù)傳輸?shù)囊环N裝置的組成結(jié)構(gòu)示意圖；

圖10為本發(fā)明實現(xiàn)數(shù)據(jù)傳輸?shù)牧硪环N裝置的組成結(jié)構(gòu)示意圖。

具體實施方式

為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚明白，下文中將結(jié)合附圖對本發(fā)明的實施例進行詳細(xì)說明。需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互任意組合。

圖1為本發(fā)明實施例中實現(xiàn)數(shù)據(jù)傳輸?shù)囊环N方法的流程圖，圖2所示方法可以適用于發(fā)送端如終端側(cè)，如圖1所示，包括以下步驟：

步驟100：利用預(yù)先獲得的壓縮策略對待發(fā)送的第一數(shù)據(jù)包進行處理，刪除第一數(shù)據(jù)包中壓縮策略指定的重復(fù)數(shù)據(jù)。

其中，壓縮策略包括若干條規(guī)則，用來對比發(fā)送端即將發(fā)送的數(shù)據(jù)包是否包含有與之前發(fā)送的數(shù)據(jù)包有重復(fù)內(nèi)容的依據(jù)信息，也是接收端用來恢復(fù)接收到的壓縮后的第二數(shù)據(jù)包以形成原始的第一數(shù)據(jù)包的依據(jù)信息。

可選地，本步驟可以包括：

發(fā)送端有待發(fā)送的第一數(shù)據(jù)包時，周期性將第一數(shù)據(jù)包和壓縮策略中與待發(fā)送的第一數(shù)據(jù)包的目的地址一致的規(guī)則進行比較，檢查該第一數(shù)據(jù)包中的字段或內(nèi)容是否與該規(guī)則描述中的相應(yīng)字段或內(nèi)容相同；

如果相同即檢查第一數(shù)據(jù)包中的相關(guān)的字段或內(nèi)容與壓縮策略相匹配，刪除該第一數(shù)據(jù)包中的所述字段或內(nèi)容即與之前發(fā)送的數(shù)據(jù)包重復(fù)的內(nèi)容。

可選地，如果檢查出該數(shù)據(jù)包中的上述字段或內(nèi)容與該規(guī)則描述中的相應(yīng)字段或內(nèi)容不相同，則刪除壓縮策略中的該條規(guī)則。

可選地，壓縮策略至少包括：主要通過協(xié)議類型來區(qū)分的協(xié)議類規(guī)則，和主要通過應(yīng)用類型來區(qū)分的內(nèi)容類規(guī)則。

一個發(fā)送端針對一個目的ip地址，最多可包含兩類規(guī)則，一個是協(xié)議類規(guī)則，一個是內(nèi)容類規(guī)則。這兩類規(guī)則內(nèi)，協(xié)議類規(guī)則中包含一條或一條以上協(xié)議類的規(guī)則，內(nèi)容類規(guī)則中包含一條或一條以上內(nèi)容類的規(guī)則。一類規(guī)則內(nèi)的多條規(guī)則以不相同的數(shù)字標(biāo)記，稱為規(guī)則號。

發(fā)送端如終端針對不同的目的ip地址，可以有多個壓縮策略；而接收端如服務(wù)器針對不同終端，也有多個壓縮策略。一個服務(wù)器和一個終端之間，具有對應(yīng)的壓縮策略，且服務(wù)器的壓縮策略中各規(guī)則的規(guī)則號和終端的壓縮策略中對應(yīng)的規(guī)則的規(guī)則號完全一致。

當(dāng)壓縮策略包括協(xié)議類規(guī)則和內(nèi)容類規(guī)則時，步驟100具體包括：

發(fā)送端有待發(fā)送的第一數(shù)據(jù)包時，如果壓縮策略中存儲有與待發(fā)送的第一數(shù)據(jù)包的目的地址一致的協(xié)議類規(guī)則，周期性將待發(fā)送的以數(shù)據(jù)包和壓縮策略中與待發(fā)送的數(shù)據(jù)包的目的地址一致的協(xié)議類規(guī)則進行比較，檢查該第一數(shù)據(jù)包中的字段或內(nèi)容內(nèi)容是否與該協(xié)議類規(guī)則描述中的相應(yīng)字段或內(nèi)容相同；如果相同即檢查第一數(shù)據(jù)包中的相應(yīng)字段或內(nèi)容與壓縮策略相匹配，刪除該第一數(shù)據(jù)包中的相應(yīng)字段或內(nèi)容即與之前發(fā)送的數(shù)據(jù)包重復(fù)的內(nèi)容；

如果壓縮策略中未存儲與待發(fā)送的第一數(shù)據(jù)包的目的地址一致的協(xié)議類規(guī)則，但存儲有與待發(fā)送的第一數(shù)據(jù)包的目的地址一致的內(nèi)容類規(guī)則，則周期性將待發(fā)送的第一數(shù)據(jù)包和壓縮策略中與待發(fā)送的第一數(shù)據(jù)包的目的地址一致的內(nèi)容類規(guī)則進行比較，檢查該第一數(shù)據(jù)包中的指定內(nèi)容是否與該內(nèi)容類規(guī)則描述中的相應(yīng)內(nèi)容相同；如果相同即檢查第一數(shù)據(jù)包中的指定字段或內(nèi)容與壓縮策略相匹配，刪除該第一數(shù)據(jù)包中的相應(yīng)字段或內(nèi)容即與之前發(fā)送的數(shù)據(jù)包重復(fù)的內(nèi)容。

步驟100中，在存在待發(fā)送的數(shù)據(jù)包之后，對待發(fā)送的數(shù)據(jù)包進行處理之前，還包括：

查詢接收端是否支持壓縮傳輸能力。具體包括：

向所述接收端發(fā)送查詢請求，接收到所述接收端的回應(yīng)后確定所述接收端支持壓縮傳輸能力；或者，

查詢與所述接收端的數(shù)據(jù)傳輸記錄，根據(jù)存儲記錄確定所述接收端支持壓縮傳輸能力。

對于第一種查詢方式，發(fā)送端向接收端發(fā)送查詢請求，如果發(fā)送端沒有收到查詢響應(yīng)，則認(rèn)為該接收端不支持壓縮傳輸能力；如果發(fā)送端收到查詢響應(yīng)，則認(rèn)為該接收端支持壓縮傳輸能力。

對于第二種查詢方式，如果發(fā)送端中存儲有與接收端進行數(shù)據(jù)傳輸?shù)挠涗洠矣涗涳@示該接收端支持壓縮傳輸能力，繼續(xù)執(zhí)行步驟100；

如果發(fā)送端中未存儲與該接收端進行數(shù)據(jù)傳輸?shù)挠涗?，則表明該發(fā)送端是首次與該待發(fā)送的第一數(shù)據(jù)包對應(yīng)的目的ip地址進行通信，發(fā)送端需要通過控制通路查詢接收端是否支持壓縮傳輸能力：對于支持壓縮傳輸能力的額手段，繼續(xù)執(zhí)行步驟100中的對待發(fā)送的第一數(shù)據(jù)包進行處理的步驟；對不支持壓縮傳輸能力的接收端，結(jié)束本發(fā)明的流程，待發(fā)送的數(shù)據(jù)包采取相關(guān)技術(shù)中的普通數(shù)據(jù)傳輸方式發(fā)送。

較佳地，為了避免網(wǎng)絡(luò)原因?qū)е孪l(fā)送失敗，查詢接收端是否支持壓縮傳輸能力還可以包括：

發(fā)送端按照預(yù)先設(shè)置的時間間隔如2秒向服務(wù)器發(fā)送預(yù)設(shè)次數(shù)如3次查詢請求，如果發(fā)送端沒有收到任何查詢響應(yīng)，則認(rèn)為該接收端不支持壓縮傳輸能力；如果發(fā)送端收到至少一個查詢響應(yīng)，則認(rèn)為該接收端支持壓縮傳輸能力?？蛇x地，時間間隔和發(fā)送次數(shù)可以根據(jù)具體應(yīng)用場景進行配置。

步驟100之前還包括：

發(fā)送端通過控制通路獲取來自接收端的壓縮策略。即實現(xiàn)了接收端與發(fā)送端之間的壓縮策略中規(guī)則的同步。進一步地，發(fā)送端獲得壓縮策略后，可以向接收端返回確認(rèn)信息。其中，控制通路是從tcp/ip的層面而言的，是區(qū)分于傳輸實際用戶數(shù)據(jù)的通路；控制通路指的不是3gpp無線協(xié)議棧的控制面，控制通路仍是隸屬于用戶面的。這里，可以通過預(yù)先設(shè)置的固定的端口來確定控制通路。

步驟101：將處理后的所述第一待數(shù)據(jù)包生成待發(fā)送的第二數(shù)據(jù)包，其中所述第二數(shù)據(jù)包中包括用于指示根據(jù)所述壓縮策略刪除重復(fù)數(shù)據(jù)的修改記錄字段。

其中，修改記錄字段中的信息用于表示終端是按照壓縮策略中的哪條規(guī)則對數(shù)據(jù)包進行處理的。修改記錄字段占用一個字節(jié)。該修改記錄字段可以設(shè)置在待發(fā)送的數(shù)據(jù)包的負(fù)載(payload)的開始部分。

可選地，修改記錄字段可以包括三個部分：

規(guī)則使能指示，用于表示該修改記錄字段所在的數(shù)據(jù)包是否已經(jīng)過步驟100的處理，比如：如果已經(jīng)過處理，則規(guī)則使能指示有效，可以設(shè)置為1，如果未經(jīng)過處理，則規(guī)則使能指示無效，可以設(shè)置為0；

規(guī)則類型指示，用于表示對數(shù)據(jù)包的處理所采用的規(guī)則的類型，比如，為0表示是采用協(xié)議類規(guī)則對數(shù)據(jù)包進行處理的，為1表示是采用內(nèi)容類規(guī)則對數(shù)據(jù)包進行處理的；

規(guī)則號，用于表示對數(shù)據(jù)包的處理所使用的是哪條規(guī)則。

通過圖1所示的本發(fā)明提供的實現(xiàn)數(shù)據(jù)傳輸?shù)姆椒ǎ瑒h除了待發(fā)送的數(shù)據(jù)包中重復(fù)發(fā)送的信息，減少了實際傳輸?shù)臄?shù)據(jù)量；由于減少了實際傳輸?shù)臄?shù)據(jù)量，對運營商網(wǎng)絡(luò)的用戶面還有減輕負(fù)載的作用，因此，本發(fā)明技術(shù)方案的產(chǎn)品化是非常容易的。本發(fā)明方法直接應(yīng)用在終端和服務(wù)器這兩個最終節(jié)點之間，對網(wǎng)絡(luò)運營商也是透明的，因此可直接應(yīng)用，并不需要運營商額外增加軟硬件成本，也不需要額外的硬件支持，因此，簡單地實現(xiàn)了實際傳輸?shù)臄?shù)據(jù)量的減少，從而節(jié)約了成本。

圖2為本發(fā)明實施例中實現(xiàn)數(shù)據(jù)傳輸?shù)牧硪环N方法的流程圖，圖2所示方法可以適用于服務(wù)器端，如圖2所示，包括：

步驟200：收到來自發(fā)送端的第二數(shù)據(jù)包，檢查出第二數(shù)據(jù)包中攜帶有用于指示根據(jù)所述壓縮策略刪除重復(fù)數(shù)據(jù)的修改記錄字段。

步驟201：根據(jù)該修改記錄字段以及生成的壓縮策略對第二數(shù)據(jù)包進行恢復(fù)處理，以生成第一數(shù)據(jù)包。

修改記錄字段為接收到的數(shù)據(jù)包的payload的開始部分。如果修改記錄字段中的規(guī)則使能指示有效，則根據(jù)第二數(shù)據(jù)包的源ip地址和修改記錄字段中的規(guī)則類型、規(guī)則號信息，查找接收端的對應(yīng)壓縮策略，并利用該壓縮策略指定的重復(fù)數(shù)據(jù)對第二數(shù)據(jù)包進行恢復(fù)處理，以生成原始的第一數(shù)據(jù)包。

可選地，接收端對接收到的數(shù)據(jù)包進行恢復(fù)處理之前，還包括：

接收端通過控制通路如預(yù)先設(shè)置的端口向發(fā)送端發(fā)送壓縮策略。進一步地，接收端收到來自發(fā)送端的確認(rèn)信息。舉例來看，服務(wù)器周期性如以2秒為周期，向客戶端重復(fù)發(fā)送攜帶有壓縮策略的同步請求消息，并在收到來自終端的確認(rèn)信息如一條同步請求響應(yīng)消息時即認(rèn)為同步完成；如果未收到來自終端的確認(rèn)信息如同步請求響應(yīng)消息，則會持續(xù)發(fā)送同步請求消息，直到終端完成同步并收到來自終端的同步請求響應(yīng)消息為止。

可選地，當(dāng)接收端收到來自發(fā)送端的查詢接收端是否支持壓縮傳輸能力的查詢請求，如果自身支持，則向發(fā)送端回復(fù)查詢響應(yīng)。

通過圖2所示的本發(fā)明提供的實現(xiàn)數(shù)據(jù)傳輸?shù)姆椒ǎ瑒h除了待發(fā)送的數(shù)據(jù)包中重復(fù)發(fā)送的信息，減少了實際傳輸?shù)臄?shù)據(jù)量。本發(fā)明方法并不需要額外的硬件支持，就簡單地實現(xiàn)了實際傳輸?shù)臄?shù)據(jù)量的減少，從而節(jié)約了成本。

本發(fā)明實現(xiàn)數(shù)據(jù)傳輸?shù)姆椒ㄟ€包括：

接收端周期性的檢測收到的第二數(shù)據(jù)包，生成壓縮策略；通過控制通路將生成的指定有重復(fù)數(shù)據(jù)的壓縮策略發(fā)送給發(fā)送端。即實現(xiàn)了接收端與發(fā)送端之間的壓縮策略中規(guī)則的同步。

可選地，接收端在檢測過程中可以采取學(xué)習(xí)的方式生成壓縮策略。對數(shù)據(jù)包的學(xué)習(xí)可以周期性或連續(xù)采樣，對預(yù)設(shè)數(shù)量個數(shù)據(jù)包中的每個字段進行比對，提取出相同的字段信息作為壓縮策略指定的重復(fù)數(shù)據(jù)；或者，對特定應(yīng)用程序的端口進行采樣，如果從這個端口連續(xù)收到預(yù)設(shè)數(shù)量個數(shù)據(jù)包進行數(shù)據(jù)部分的比對，提取出相同的數(shù)據(jù)內(nèi)容作為壓縮策略指定的重復(fù)數(shù)據(jù)。比如：服務(wù)器每收到連續(xù)的同一協(xié)議類型的預(yù)設(shè)數(shù)量如3個數(shù)據(jù)包，就對這3個數(shù)據(jù)包中的每個字段進行比對，提取出相同的字段信息作為成壓縮策略指定的重復(fù)數(shù)據(jù)；對特定應(yīng)用程序的端口如2001端口進行采樣，如果從這個端口連續(xù)收到預(yù)設(shè)數(shù)量如3個數(shù)據(jù)包進行數(shù)據(jù)部分的比對，提取出相同的數(shù)據(jù)內(nèi)容作為成壓縮策略指定的重復(fù)數(shù)據(jù)。

如果接收端的壓縮策略發(fā)生了變化，本發(fā)明方法還包括：

接收端向發(fā)送端發(fā)送更新請求消息，更新請求消息中攜帶有發(fā)生變化的規(guī)則和對應(yīng)的規(guī)則號，以及新規(guī)則的具體內(nèi)容等新的規(guī)則信息。即實現(xiàn)了接收端與發(fā)送端之間的壓縮策略中規(guī)則的同步。

而發(fā)送端收到更新請求消息，獲取更新請求消息中攜帶的新的規(guī)則信息，對壓縮策略中的相應(yīng)規(guī)則進行更新，并向接收端返回更新請求響應(yīng)。

較佳地，為了避免網(wǎng)絡(luò)原因?qū)е孪l(fā)送失敗，服務(wù)器按照預(yù)先設(shè)置的時間間隔如2秒向終端重復(fù)發(fā)送更新請求消息。只要收到一次來自終端的更新請求響應(yīng)，則認(rèn)為更新完成；如果未收到來自終端的更新請求響應(yīng)，則服務(wù)器會持續(xù)發(fā)送更新請求消息，直到收到來自終端的更新請求響應(yīng)。

通過圖2所示的本發(fā)明提供的實現(xiàn)數(shù)據(jù)傳輸?shù)姆椒?，刪除了待發(fā)送的數(shù)據(jù)包中重復(fù)發(fā)送的信息，減少了實際傳輸?shù)臄?shù)據(jù)量；由于減少了實際傳輸?shù)臄?shù)據(jù)量，對運營商網(wǎng)絡(luò)的用戶面還有減輕負(fù)載的作用，因此，本發(fā)明技術(shù)方案的產(chǎn)品化是非常容易的。本發(fā)明方法直接應(yīng)用在終端和服務(wù)器這兩個最終節(jié)點之間，對網(wǎng)絡(luò)運營商也是透明的，因此可直接應(yīng)用，并不需要運營商額外增加軟硬件成本，也不需要額外的硬件支持，因此，簡單地實現(xiàn)了實際傳輸?shù)臄?shù)據(jù)量的減少，從而節(jié)約了成本。

下面結(jié)合具體實施例對本發(fā)明技術(shù)方案進行詳細(xì)描述。

圖3為本發(fā)明實現(xiàn)數(shù)據(jù)傳輸?shù)姆椒ㄖ袑崿F(xiàn)壓縮傳輸能力查詢與壓縮策略同步的實施例的流程示意圖，本實施例中，通過控制通路來實現(xiàn)壓縮傳輸能力查詢與壓縮策略同步。本實施例中假設(shè)通過指定的特定的兩個端口來定義控制通路，在這兩個端口之間傳輸?shù)臄?shù)據(jù)均視為控制數(shù)據(jù)。控制通路傳送的數(shù)據(jù)主要是終端和服務(wù)器之間的壓縮傳輸能力的查詢請求/查詢響應(yīng)，以及規(guī)則同步時的具體規(guī)則內(nèi)容。本實施例中，在規(guī)則同步完成后，一個終端和一個服務(wù)器之間，最多各自具有協(xié)議類規(guī)則和內(nèi)容類規(guī)則各一對。即一對終端和服務(wù)器之間具有一一對應(yīng)的壓縮策略。如圖3所示，包括：

步驟300～步驟301：終端在開始和一個新的服務(wù)器通信前，會通過控制通路向服務(wù)器發(fā)送查詢請求以查詢服務(wù)器是否支持壓縮傳輸能力；服務(wù)器確認(rèn)后向終端返回查詢響應(yīng)。

本實施例中，終端可以通過預(yù)先設(shè)置的端口3717和服務(wù)器的端口3718進行通信，視為數(shù)據(jù)通路。終端通過端口3717向服務(wù)器的端口3718發(fā)送一個tcp包，數(shù)據(jù)部分含有查詢請求，服務(wù)器收到該查詢請求后，通過端口3718向終端回復(fù)一個tcp包，數(shù)據(jù)部分?jǐn)y帶查詢響應(yīng)，即表示服務(wù)器支持壓縮傳輸能力。

較佳地，為了防止網(wǎng)絡(luò)狀態(tài)波動導(dǎo)致消息發(fā)送失敗，終端可以間隔性的發(fā)送3次查詢請求，如每次間隔2秒鐘。如果3次都未收到來自服務(wù)器的查詢響應(yīng)，則認(rèn)為是服務(wù)器不支持壓縮傳輸；如果支持，服務(wù)器會向終端返回查詢響應(yīng)如確認(rèn)(ok)消息。

步驟302～步驟303：支持壓縮傳輸能力的服務(wù)器周期性的解析和統(tǒng)計收到的ip數(shù)據(jù)包，形成或更新壓縮策略中的規(guī)則。如果服務(wù)器的壓縮策略中的規(guī)則發(fā)生了變化，服務(wù)器向終端發(fā)送更新請求消息，在更新請求消息中攜帶有發(fā)生變化的規(guī)則和對應(yīng)的規(guī)則號，以及新的規(guī)則的具體內(nèi)容等。

步驟304：終端收到更新請求消息時，獲取更新請求消息中攜帶的新的規(guī)則信息，對壓縮策略中的相應(yīng)規(guī)則進行更新，并向服務(wù)器返回更新請求響應(yīng)。

同樣，較佳地，為了避免網(wǎng)絡(luò)原因?qū)е孪l(fā)送失敗，服務(wù)器可以按照預(yù)先設(shè)置的時間間隔如2秒向終端重復(fù)發(fā)送更新請求消息。只要收到一次來自終端的更新請求響應(yīng)，則認(rèn)為更新完成；如果未收到來自終端的更新請求響應(yīng)，則服務(wù)器會持續(xù)發(fā)送更新請求消息，直到收到來自終端的更新請求響應(yīng)。

圖4為本發(fā)明實施例中協(xié)議類規(guī)則的結(jié)構(gòu)的示意圖，如圖4所示，協(xié)議類規(guī)則可以以規(guī)則表的形式體現(xiàn)，規(guī)則表中容納了多條協(xié)議類規(guī)則。終端針對每個服務(wù)器的ip地址，維護一個協(xié)議類規(guī)則表，該協(xié)議類規(guī)則表中的規(guī)則都是針對同一個服務(wù)器的；在終端結(jié)束和該服務(wù)器的通信后，將會釋放針對該服務(wù)器的所有規(guī)則信息。位于同一規(guī)則表中的多條規(guī)則，具有唯一的規(guī)則號以區(qū)分開來。同理，服務(wù)器中也存儲有和終端存儲的規(guī)則表內(nèi)容類似的協(xié)議類規(guī)則表，唯一不同的是服務(wù)器中規(guī)則表的ip地址是終端的ip地址，服務(wù)器為每個終端維護一個協(xié)議類的規(guī)則表，該規(guī)則表中的規(guī)則號以及規(guī)則描述與終端存儲的是一致的。以圖4為例，列出了終端中存儲的3條規(guī)則，這3條規(guī)則的類型分別是超文本傳輸協(xié)議(http)get請求類型，因特網(wǎng)控制報文協(xié)議(icmp)ping請求類型，域名系統(tǒng)(dns)請求類型。每條規(guī)則中最多支持對兩個字段的重復(fù)描述，通過字段名/長度/值(field/len/value)的格式的方法進行描述。

圖5為本發(fā)明實施例中內(nèi)容類規(guī)則的結(jié)構(gòu)的示意圖，如圖5所示，與協(xié)議類規(guī)則類似，內(nèi)容類規(guī)則可以以規(guī)則表的形式體現(xiàn)，終端針對每個服務(wù)器ip地址維護一個內(nèi)容類的規(guī)則表，其中容納了多條內(nèi)容類規(guī)則，同一個規(guī)則表中，每條規(guī)則由唯一的規(guī)則號來區(qū)別。

服務(wù)器在生成和維護內(nèi)容類規(guī)則時，為不同ip地址的終端維護不同的內(nèi)容類規(guī)則表。對于同一個終端，會區(qū)分不同應(yīng)用發(fā)來的不同數(shù)據(jù)流。區(qū)分?jǐn)?shù)據(jù)流有很多種方式，比如可以采用端口號來區(qū)分。在與一個終端進行數(shù)據(jù)交互的過程中，服務(wù)器檢測每個端口號，如在端口m上收到的數(shù)據(jù)將使用規(guī)則m進行匹配，在端口n上收到的數(shù)據(jù)使用規(guī)則n來進行匹配，這樣避免了每收到一個數(shù)據(jù)包都要遍歷規(guī)則表中的所有規(guī)則的問題。在終端和服務(wù)器上的內(nèi)容類規(guī)則表中，端口號字段填充的都是服務(wù)器的端口號。另外，由于物聯(lián)網(wǎng)應(yīng)用中的數(shù)據(jù)傳輸過程中，某固定類型的端口上，通常發(fā)送的是固定格式和固定信息類型的數(shù)據(jù)。如gps信息，儀表數(shù)據(jù)，車輛狀態(tài)信息等等，因此，如圖5所示，本發(fā)明實施例中的內(nèi)容類的規(guī)則表的規(guī)則描述方法可以通過偏移值/長度/值(offset/len/value)的方法來描述。

圖6為本發(fā)明實施例中解壓信息的結(jié)構(gòu)的示意圖，解壓信息可以攜帶在待發(fā)送的數(shù)據(jù)包的一個字節(jié)的修改記錄字段中，如圖6所示，展示了修改記錄字段的字段格式。本發(fā)明的終端在利用壓縮策略對待發(fā)送的數(shù)據(jù)包進行處理，刪除數(shù)據(jù)包中壓縮策略指定的重復(fù)數(shù)據(jù)之后，會生成一個字節(jié)的修改記錄字段信息，并將該修改記錄字段放在該數(shù)據(jù)包的數(shù)據(jù)部分的首部；而服務(wù)器收到數(shù)據(jù)包后，會根據(jù)該修改記錄字段的信息對數(shù)據(jù)包進行恢復(fù)。因此該修改記錄字段是非常重要的。以圖6為例，修改記錄字段包含三個字段：1個比特bit的規(guī)則使能指示，表示該修改記錄字段所在的數(shù)據(jù)包是否已經(jīng)過上述利用壓縮策略對待發(fā)送的數(shù)據(jù)包進行的處理，本實施例中，如果已經(jīng)過處理，則規(guī)則使能指示有效，可以設(shè)置為1，如果未經(jīng)過處理，則規(guī)則使能指示無效，可以設(shè)置為0；1個bit的規(guī)則類型指示，本實施例中，為0表示該數(shù)據(jù)包處理依據(jù)的規(guī)則是協(xié)議類規(guī)則，為1表示依據(jù)的規(guī)則是內(nèi)容類規(guī)則；以及表示對數(shù)據(jù)包的處理所使用的是哪條規(guī)則的規(guī)則號。為了最大程度節(jié)省空間，并考慮到實際物聯(lián)網(wǎng)場景中可能用到的規(guī)則數(shù)目，這里將規(guī)則數(shù)目最大設(shè)為64即規(guī)則號的取值范圍為0～64。因此，該修改記錄字段的最后6個bit可用于記錄規(guī)則號。

圖7為本發(fā)明實現(xiàn)數(shù)據(jù)傳輸?shù)牡谝粚嵤├牧鞒虉D示意圖，本實施例中，如果找到匹配的協(xié)議類規(guī)則，待發(fā)送的數(shù)據(jù)包首先經(jīng)過協(xié)議類規(guī)則的處理，處理后跳過內(nèi)容類規(guī)則處理流程，直接發(fā)送；如果沒有找到匹配的協(xié)議類規(guī)則，將進入內(nèi)容類規(guī)則處理流程。如圖7所示，包括：

步驟700：用戶設(shè)備(ue)收到上層應(yīng)用發(fā)來的ip包，獲取目的ip地址和上層協(xié)議類型。

步驟701～步驟702：檢查ue是否保存有與該目的ip地址對應(yīng)的傳輸記錄，如果有，則讀取記錄，根據(jù)讀取的記錄確定該服務(wù)器是否支持壓縮傳輸機制，如果記錄顯示該服務(wù)器支持壓縮傳輸，進入步驟704；如果沒有對應(yīng)的傳輸記錄，說明ue是首次與該目的ip地址對應(yīng)的服務(wù)器進行通信，需要先查詢該服務(wù)器是否支持壓縮傳輸，進入步驟703。

步驟703：判斷目的ip地址對應(yīng)的服務(wù)器是否支持壓縮傳輸能力，如果不支持，進入步驟710；如果支持，進入步驟704。

步驟704：記錄顯示該目的ip地址對應(yīng)的服務(wù)器是否支持壓縮傳輸能力，如果是支持壓縮傳輸能力的，進入步驟705；如果是不支持壓縮傳輸能力的，進入步驟711。

步驟705：檢查是否存在對應(yīng)該目的ip地址的協(xié)議類規(guī)則，如果存在，進入步驟706；如果不存在，進入步驟713。

步驟706～步驟707：判斷是否到達檢測周期，本發(fā)明實施例中，可以通過如定時器t1或計數(shù)器c1來判定。如果未到達檢測周期，則不檢測，進入步驟707繼續(xù)計時或計數(shù)并返回步驟706；如果到達檢測周期，進入步驟708。

本實施例中，如果采用定時器，那么可以設(shè)置每10秒檢測一次，如果采用計數(shù)器，那么可以設(shè)置每5個數(shù)據(jù)包檢測一次。具體的閾值是可以根據(jù)具體應(yīng)用需求，通過調(diào)整定時器t1或計數(shù)器c1的值來改變。

步驟708～步驟709：檢測ip包中的字段內(nèi)容，判斷是否與對應(yīng)規(guī)則描述中的len和value內(nèi)容相匹配，如果二者相同即匹配，重置定時器t1或計數(shù)器c1，進入步驟710；如果二者不相同即不匹配，進入步驟712。

步驟710：按照規(guī)則處理ip包，刪除重復(fù)數(shù)據(jù)，生成修改記錄字段，并填充到原始的ip包中，修改更新ip包頭部信息。

步驟711：將原始ip包不加處理的傳遞給無線協(xié)議棧發(fā)送給服務(wù)器。結(jié)束本流程。此時，可以采用相關(guān)技術(shù)中的普通數(shù)據(jù)傳輸方式發(fā)送數(shù)據(jù)包及對所述第一數(shù)據(jù)包不進行處理，直接發(fā)送給所述接收端。

步驟712：刪除ue本地的該條協(xié)議類規(guī)則。

步驟713：轉(zhuǎn)入將該ip包按內(nèi)容類規(guī)則處理的流程進行進一步的處理。

圖8為本發(fā)明實現(xiàn)數(shù)據(jù)傳輸?shù)牡诙嵤├牧鞒虉D示意圖，本實施例是按內(nèi)容類規(guī)則處理數(shù)據(jù)包的流程圖。執(zhí)行圖8所示流程的數(shù)據(jù)包，是經(jīng)過了協(xié)議類規(guī)則篩選而沒有符合要求的協(xié)議類規(guī)則的數(shù)據(jù)包。如圖8所示，包括：

步驟800：ue收到上層應(yīng)用的原始ip包，獲取目的ip地址和端口；檢查是否有針對該目的ip地址和端口的內(nèi)容類規(guī)則，如果沒有，進入步驟805；如果存在對應(yīng)的內(nèi)容類規(guī)則，進入步驟802。

步驟802：檢查ip包中特定位置的內(nèi)容，是否與對應(yīng)的規(guī)則中描述的內(nèi)容相同，如果相同，進入步驟803；如果不同，進入步驟804。

步驟803：按照規(guī)則處理ip包，刪除重復(fù)數(shù)據(jù)，生成修改記錄字段，并填充到原始的ip包中，之后進入步驟806。

步驟804：刪除ue本地的該條內(nèi)容類規(guī)則。

步驟805：生成修改記錄字段并填充為全0，將生成的修改記錄字段填充到原始的ip包中。

步驟806：向服務(wù)器發(fā)送修改后的ip包。

為了更好的理解本發(fā)明提出的數(shù)據(jù)壓縮傳輸方法，下面結(jié)合實際場景對本發(fā)明提供的技術(shù)方案的應(yīng)用進行詳細(xì)描述。本實施例中的ue以一個帶定位功能的智能手表為例進行說明。該手表會定時以用戶數(shù)據(jù)報協(xié)議(udp)包的形式向服務(wù)器發(fā)送ue所在經(jīng)緯度。也會間歇性的和網(wǎng)絡(luò)進行http交互，獲取新聞簡訊等業(yè)務(wù)內(nèi)容。如果采用現(xiàn)有技術(shù)，那么，用戶上層應(yīng)用的每個數(shù)據(jù)包都會通過無線協(xié)議棧發(fā)送到網(wǎng)絡(luò)側(cè)，也就是說，應(yīng)用產(chǎn)生多少數(shù)據(jù)量，終端就發(fā)送多少數(shù)據(jù)量。而采用了本發(fā)明提供的技術(shù)方案，可明顯減少實際傳輸?shù)臄?shù)據(jù)量，具體實現(xiàn)詳細(xì)描述如下：

假設(shè)用戶當(dāng)前在以陜西省西安市鐘樓為中心，一環(huán)路以內(nèi)活動。如下表1所示的數(shù)據(jù)包片段是智能手表依次向網(wǎng)絡(luò)發(fā)送的ip包信息(本實施例中，下行包已經(jīng)被過濾掉，這里僅顯示上行的數(shù)據(jù)包)。序號和時間戳是疊加累計的，源ip是終端的ip地址，目的ip是服務(wù)器的ip地址。類型表示ip層以上的協(xié)議類型，本實施例中分別是http和udp兩種。http的用于和服務(wù)器的80端口之間通信，獲取圖片，新聞等等雜項業(yè)務(wù)內(nèi)容。udp包是終端發(fā)向服務(wù)器2001端口的，其中攜帶的信息是固定格式的，是終端的gps經(jīng)緯度信息，例如(34.2606986937,108.9444049731)。這些數(shù)據(jù)包的詳細(xì)數(shù)據(jù)體將在后面展示。

表1

假設(shè)表1中1號http包的負(fù)載內(nèi)容如下：

其中，每行代表一個字段，冒號左邊的是字段名稱，冒號右邊的是字段的值?？梢姡?號http數(shù)據(jù)包含有多個字段，每個字段均含有特定的信息。比如，user-agent字段描述終端用的什么操作系統(tǒng)(包括版本號)和瀏覽器(包括版本號)信息，accept-charset字段的信息則描述了瀏覽器支持的字符集，等等。關(guān)于其中各字段的名稱和意義，是http協(xié)議的標(biāo)準(zhǔn)規(guī)范，這里不再贅述。

假設(shè)表1中2號http包的負(fù)載內(nèi)容如下：

假設(shè)表1中5號http包的負(fù)載內(nèi)容如下：

在服務(wù)器分析統(tǒng)計這些數(shù)據(jù)包時，會統(tǒng)計出user-agent和accept-charset兩個字段始終沒有變化，因此，服務(wù)器將生成一個針對此httpget請求的，且針對源ip所對應(yīng)的這個終端的協(xié)議類規(guī)則信息，并與終端進行同步，同步后，終端保存的協(xié)議類規(guī)則信息如表2所示：

表2

如表2所示，其中包括有一條規(guī)則即p-policy1，規(guī)則p-policy1的協(xié)議類型是http(get)類，還包括有兩個字段的規(guī)則描述，即user-agent字段和accept-charset字段，這兩個字段的內(nèi)容分別在規(guī)則中列出。實際上，發(fā)往該服務(wù)器的httpget請求中的user-agent字段和accept-charset字段的內(nèi)容是不發(fā)生變化的。

這樣，后續(xù)在ue傳輸符合httpget類型的上述1、2、5號ip包過程中，將會利用規(guī)則p-policy1刪去ip包中的這兩個字段，并在ip包的負(fù)載payload數(shù)據(jù)部分的首字節(jié)加上1個字節(jié)的修改記錄字段，以告知服務(wù)器該ip包是經(jīng)過壓縮處理的，同時告訴服務(wù)器使用的是哪個規(guī)則進行壓縮處理的，以便于服務(wù)器恢復(fù)。本實施例中，假設(shè)修改記錄字段的值是0x81，每一位的分布如表3所示，規(guī)則使能指示的取值為1，表示該ip包已被壓縮處理過；規(guī)則類型的取值為0，表示依據(jù)的規(guī)則是協(xié)議類規(guī)則；規(guī)則號代表了規(guī)則的編號，這個號碼在ue和服務(wù)器是統(tǒng)一的，本實施例中假設(shè)是1。

表3

類似地，智能手表發(fā)送的第3、4、6號包是udp包，假設(shè)是同一個應(yīng)用發(fā)出的終端的gps信息，均發(fā)往服務(wù)器203.209.232.6的端口2001。這三個消息攜帶的數(shù)據(jù)內(nèi)容如下：

假設(shè)表1中3號udp包攜帶的經(jīng)緯度是(34.2606986937,108.9444049731)，如表4中所示，假設(shè)位于陜西省西安市蓮湖區(qū)北院門1號：

表4

假設(shè)表1中4號udp包攜帶的經(jīng)緯度是(34.2584512637,108.9618120072)，如表5中所示，假設(shè)位于陜西省西安市碑林區(qū)西三道巷22號：

表5

假設(shè)表1中6號udp包攜帶的經(jīng)緯度是(34.2516250929,108.9479900409)，如表6中所示，假設(shè)位于陜西省西安市碑林區(qū)順城南路東段：

表6

服務(wù)器周期性的統(tǒng)計端口2001上收到的udp包，將針對該終端的ip生成一個內(nèi)容類規(guī)則信息，并通過同步將該內(nèi)容規(guī)則信息同步給終端，終端保存內(nèi)容類規(guī)則信息如表7所示：

表7

如表7所示，目前只有一個規(guī)則c-policy1，規(guī)則號為1。規(guī)則c-policy1描述了兩個內(nèi)容字段的情況，分別位于相對于ip數(shù)據(jù)包負(fù)載payload數(shù)據(jù)偏移值為8和21、長度分別為4和6的兩端數(shù)據(jù)，內(nèi)容如表7所示，分別為“34.2”和“.108.9”。之所以會產(chǎn)生這兩段數(shù)據(jù)，是因為該終端的用戶在一段時間內(nèi)的活動范圍是在鐘樓、城墻內(nèi)的活動范圍。普通用戶在一段時間內(nèi)，在一個特定范圍內(nèi)活動，這種場景是非常常見的，因此這種情況的內(nèi)容類規(guī)則也是容易生成的。

這樣，后續(xù)在ue傳輸符合規(guī)則c-policy1的ip包的過程中，將會利用規(guī)則c-policy1刪去udp內(nèi)容中的這兩個字段，并在ip包負(fù)載payload數(shù)據(jù)部分的首字節(jié)加上1個字節(jié)的修改記錄字段，以告知服務(wù)器該ip包是經(jīng)過壓縮處理的，同時告訴服務(wù)器使用的是哪個規(guī)則進行壓縮處理的，以便于服務(wù)器恢復(fù)。本實施例中，假設(shè)修改記錄字段的值是0xc1，每一位的分布如表8所示，規(guī)則使能指示的取值為1，表示該ip包應(yīng)用了規(guī)則；規(guī)則類型的取值為1，表示規(guī)則是內(nèi)容類規(guī)則；規(guī)則號代表了規(guī)則的編號，這個號碼在ue和服務(wù)器是統(tǒng)一的，本實施例中假設(shè)是1。

表8

至此，這兩種規(guī)則均已生成。然后服務(wù)器會和ue進行規(guī)則同步。在規(guī)則同步后，ue在發(fā)送7號httpget包時，會按httpget協(xié)議類規(guī)則對其進行壓縮處理，去掉協(xié)議中指定的項，處理后的包內(nèi)容如表9所示，表9中劃掉的信息是不傳輸?shù)?，相比原始?shù)據(jù)包，少傳輸145字節(jié)的內(nèi)容。即每個數(shù)據(jù)包都縮減掉36.7％的數(shù)據(jù)量。采用本發(fā)明的壓縮傳輸方案后，去除了重復(fù)內(nèi)容，提高了傳輸效率。

表9

從這個ip包的角度看，壓縮前后的情況如表10所示，表10中下部分被斜杠劃掉的字段：

表10

ue在發(fā)送8號udp數(shù)據(jù)包時，會按照內(nèi)容類規(guī)則去掉指定的數(shù)據(jù)，處理后的包內(nèi)容如表11所示，表11中劃掉的信息是不傳輸?shù)摹＞唧w如表12所示下部分所示，本實施例中刪除的數(shù)據(jù)為“34.2”和“.108.9”，處理后的ip數(shù)據(jù)包內(nèi)容如下，相比原始數(shù)據(jù)包，少傳輸9字節(jié)的內(nèi)容。即每個數(shù)據(jù)包縮減掉32.1％的數(shù)據(jù)量。采用本發(fā)明的壓縮傳輸方案后，去除了重復(fù)內(nèi)容，提高了傳輸效率。

表11

表12

上述結(jié)合實際場景對本發(fā)明提供的技術(shù)方案的應(yīng)用的實施例中，在規(guī)則生成后，隨著ue持續(xù)的工作，發(fā)包的數(shù)量會越來越多，利用本發(fā)明提供的技術(shù)方案在節(jié)省資源的效果上也會越來越顯著。

本發(fā)明還提供一種計算機可讀存儲介質(zhì)，存儲有計算機可執(zhí)行指令，所述計算機可執(zhí)行指令用于執(zhí)行本發(fā)明任一項的實現(xiàn)數(shù)據(jù)傳輸?shù)姆椒ā?/p>

圖9為本發(fā)明實現(xiàn)數(shù)據(jù)傳輸?shù)囊环N裝置的組成結(jié)構(gòu)示意圖，如圖9所示，至少包括壓縮模塊、處理模塊、發(fā)送模塊，以及用于存儲壓縮策略的第一存儲模塊；其中，

壓縮模塊，用于利用第一存儲模塊中的壓縮策略對待發(fā)送的第一數(shù)據(jù)包進行處理，刪除第一數(shù)據(jù)包中壓縮策略指定的重復(fù)數(shù)據(jù)；

處理模塊，用于將處理后的所述第一待數(shù)據(jù)包生成待發(fā)送的第二數(shù)據(jù)包，其中所述第二數(shù)據(jù)包中包括用于指示根據(jù)所述壓縮策略刪除重復(fù)數(shù)據(jù)的修改記錄字段；

發(fā)送模塊，用于發(fā)送第二數(shù)據(jù)包。

其中，壓縮策略包括若干條規(guī)則，用來對比發(fā)送端即將發(fā)送的第一數(shù)據(jù)包是否包含有與之前發(fā)送的數(shù)據(jù)包有重復(fù)內(nèi)容的依據(jù)信息。

可選地，壓縮模塊具體用于：

有待發(fā)送的第一數(shù)據(jù)包時，周期性將所述第一數(shù)據(jù)包和所述壓縮策略中與所述第一數(shù)據(jù)包的目的地址一致的規(guī)則進行比較，檢查該第一數(shù)據(jù)包中的字段后內(nèi)容是否與該規(guī)則描述中的相應(yīng)字段或內(nèi)容相同；

如果相同即檢查第一數(shù)據(jù)包中的指定的字段或內(nèi)容與壓縮策略相匹配，刪除該第一數(shù)據(jù)包中的所述字段或內(nèi)容即與之前發(fā)送的數(shù)據(jù)包重復(fù)的內(nèi)容。

可選地，壓縮模塊還用于：如果檢查出該數(shù)據(jù)包中的上述字段或內(nèi)容與該規(guī)則描述中的相應(yīng)字段或內(nèi)容不相同，則刪除壓縮策略中的該條規(guī)則。

可選地，壓縮策略至少包括：主要通過協(xié)議類型來區(qū)分的協(xié)議類規(guī)則，和主要通過應(yīng)用類型來區(qū)分的內(nèi)容類規(guī)則。相應(yīng)地，

壓縮模塊具體用于：

有待發(fā)送的第一數(shù)據(jù)包時，如果壓縮策略中存儲有與待發(fā)送的第一數(shù)據(jù)包的目的地址一致的協(xié)議類規(guī)則，周期性將待發(fā)送的數(shù)據(jù)包和壓縮策略中與待發(fā)送的第一數(shù)據(jù)包的目的地址一致的協(xié)議類規(guī)則進行比較，檢查該數(shù)據(jù)包中的字段或內(nèi)容是否與該協(xié)議類規(guī)則描述中的相應(yīng)字段或內(nèi)容相同；如果相同即檢查第一數(shù)據(jù)包中的指上述字段或內(nèi)容與壓縮策略相匹配，刪除該第一數(shù)據(jù)包中的昂書字段或內(nèi)容即與之前發(fā)送的數(shù)據(jù)包重復(fù)的內(nèi)容；

如果壓縮策略中未存儲與待發(fā)送的第一數(shù)據(jù)包的目的地址一致的協(xié)議類規(guī)則，但存儲有與待發(fā)送的第一數(shù)據(jù)包的目的地址一致的內(nèi)容類規(guī)則，則周期性將待發(fā)送的第一數(shù)據(jù)包和壓縮策略中與待發(fā)送的第一數(shù)據(jù)包的目的地址一致的內(nèi)容類規(guī)則進行比較，檢查該第一數(shù)據(jù)包中的指定內(nèi)容是否與該內(nèi)容類規(guī)則描述中的相應(yīng)字段或內(nèi)容相同；如果相同即檢查第一數(shù)據(jù)包中的上述字段或內(nèi)容與壓縮策略相匹配，刪除該數(shù)據(jù)包中的上述字段或內(nèi)容即與之前發(fā)送的數(shù)據(jù)包重復(fù)的內(nèi)容。

可選地，本發(fā)明裝置還包括檢測模塊，用于確認(rèn)所述接收端支持壓縮傳輸能力，如果支持壓縮傳輸能力，觸發(fā)壓縮模塊進行處理；其中確認(rèn)所述接收端支持壓縮傳輸能力包括：

向所述接收端發(fā)送查詢請求，接收到所述接收端的回應(yīng)后確定所述接收端支持壓縮傳輸能力；或者，

查詢與所述接收端的數(shù)據(jù)傳輸記錄，根據(jù)存儲記錄確定所述接收端支持壓縮傳輸能力；

進一步地，

如果未存儲與服務(wù)器進行數(shù)據(jù)傳輸?shù)挠涗洠瑒t表明終端是首次與該待發(fā)送的數(shù)據(jù)包對應(yīng)的目的ip地址進行通信，通過控制通路查詢服務(wù)器是否支持壓縮傳輸能力：對于支持壓縮傳輸能力的服務(wù)器，觸發(fā)壓縮模塊進行處理；當(dāng)確認(rèn)所述接收端不支持壓縮傳輸能力時，對所述第一數(shù)據(jù)包不進行處理，直接發(fā)送給所述接收端。

較佳地，為了避免網(wǎng)絡(luò)原因?qū)е孪l(fā)送失敗，查詢接收端是否支持壓縮傳輸能力還可以包括：

發(fā)送端按照預(yù)先設(shè)置的時間間隔如2秒向服務(wù)器發(fā)送預(yù)設(shè)次數(shù)如3次查詢請求，如果發(fā)送端沒有收到任何查詢響應(yīng)，則認(rèn)為該接收端不支持壓縮傳輸能力；如果發(fā)送端收到至少一個查詢響應(yīng)，則認(rèn)為該接收端支持壓縮傳輸能力。可選地，時間間隔和發(fā)送次數(shù)可以根據(jù)具體應(yīng)用場景進行配置。

本發(fā)明裝置還包括：獲取模塊，用于通過控制通路獲取來自接收端的壓縮策略。即實現(xiàn)了接收端與發(fā)送端之間的壓縮策略中規(guī)則的同步。

進一步地，獲取模塊還用于：獲得壓縮策略后，可以向接收端返回確認(rèn)信息。

其中，控制通路是從tcp/ip的層面而言的，是區(qū)分于傳輸實際用戶數(shù)據(jù)的通路；控制通路指的不是3gpp無線協(xié)議棧的控制面，控制通路仍是隸屬于用戶面的。這里，可以通過預(yù)先設(shè)置的固定的端口來確定控制通路。

可選地，修改記錄字段設(shè)置在所述第二數(shù)據(jù)包的負(fù)載的開始部分。

可選地，修改記錄字段可以包括三個部分：

規(guī)則使能指示，用于表示該修改記錄字段所在的數(shù)據(jù)包是否已經(jīng)過步驟100的處理，比如：如果已經(jīng)過處理，則規(guī)則使能指示有效，可以設(shè)置為1，如果未經(jīng)過處理，則規(guī)則使能指示無效，可以設(shè)置為0；

規(guī)則類型指示，用于表示對數(shù)據(jù)包的處理所采用的規(guī)則的類型，比如，為0表示是采用協(xié)議類規(guī)則對數(shù)據(jù)包進行處理的，為1表示是采用內(nèi)容類規(guī)則對數(shù)據(jù)包進行處理的；

規(guī)則號，用于表示對數(shù)據(jù)包的處理所使用的是哪條規(guī)則。

可選地，發(fā)送模塊可以是emtc/nb-iot無線協(xié)議棧。

通過圖9所示的本發(fā)明提供的實現(xiàn)數(shù)據(jù)傳輸?shù)难b置，刪除了待發(fā)送的數(shù)據(jù)包中重復(fù)發(fā)送的信息，減少了實際傳輸?shù)臄?shù)據(jù)量；由于減少了實際傳輸?shù)臄?shù)據(jù)量，對運營商網(wǎng)絡(luò)的用戶面還有減輕負(fù)載的作用，因此，本發(fā)明技術(shù)方案的產(chǎn)品化是非常容易的。本發(fā)明裝置直接應(yīng)用在終端和服務(wù)器這兩個最終節(jié)點之間，對網(wǎng)絡(luò)運營商也是透明的，因此可直接應(yīng)用，并不需要運營商額外增加軟硬件成本，也不需要額外的硬件支持，因此，簡單地實現(xiàn)了實際傳輸?shù)臄?shù)據(jù)量的減少，從而節(jié)約了成本。

本發(fā)明還提供一種終端，包括上述圖9相關(guān)的任一項實現(xiàn)數(shù)據(jù)傳輸?shù)难b置。

圖10為本發(fā)明實現(xiàn)數(shù)據(jù)傳輸?shù)牧硪环N裝置的組成結(jié)構(gòu)示意圖，如圖10所示，至少包括：接收模塊、解壓模塊，以及用于存儲壓縮策略的第二存儲模塊；其中，

接收模塊，用于收到來自發(fā)送端的第二數(shù)據(jù)包，檢查出第二數(shù)據(jù)包中攜帶有用于指示根據(jù)所述壓縮策略刪除重復(fù)數(shù)據(jù)的修改記錄字段；

解壓模塊，用于根據(jù)該修改記錄字段以及第二存儲模塊中存儲的壓縮策略對第二數(shù)據(jù)包進行恢復(fù)處理，以生成第一數(shù)據(jù)包。

本發(fā)明裝置還包括：生成模塊、同步模塊；其中，

生成模塊，用于周期性的檢測收到的數(shù)據(jù)包，生成壓縮策略；

同步模塊，用于通過控制通路將生成的指定有重復(fù)數(shù)據(jù)的壓縮策略發(fā)送給發(fā)送端。

可選地，生成模塊具體用于：

對預(yù)設(shè)數(shù)量個第二數(shù)據(jù)包周期性或連續(xù)采樣，對預(yù)設(shè)數(shù)量個第二數(shù)據(jù)包中的每個字段進行比對，提取出相同的字段信息作為壓縮策略指定的重復(fù)數(shù)據(jù)；或者，對特定應(yīng)用程序的端口進行采樣，如果從這個端口連續(xù)收到預(yù)設(shè)數(shù)量個第二數(shù)據(jù)包進行數(shù)據(jù)部分的比對，提取出相同的數(shù)據(jù)內(nèi)容作為壓縮策略指定的重復(fù)數(shù)據(jù)。

進一步地，生成模塊還用于：壓縮策略發(fā)生變化，將更新的壓縮策略同步給發(fā)送端。

可選地，解壓模塊具體用于：

如果修改記錄字段中的規(guī)則使能指示有效，則根據(jù)數(shù)據(jù)包的源ip地址和修改記錄字段中的規(guī)則類型、規(guī)則號信息，查找服務(wù)器存儲的對應(yīng)壓縮策略，并利用該壓縮策略指定的重復(fù)數(shù)據(jù)對第二數(shù)據(jù)包進行恢復(fù)處理，以生成原始的第一數(shù)據(jù)包。

本發(fā)明還提供一種服務(wù)器，包括上述圖10相關(guān)的任一項實現(xiàn)數(shù)據(jù)傳輸?shù)难b置。

以上所述，僅為本發(fā)明的較佳實例而已，并非用于限定本發(fā)明的保護范圍。凡在本發(fā)明的精神和原則之內(nèi)，所做的任何修改、等同替換、改進等，均應(yīng)包含在本發(fā)明的保護范圍之內(nèi)。