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

背景技術：

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

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

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

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

再如：物聯(lián)網(wǎng)應用通常是客戶端/服務器結構。應用提供商通常需要提供終端和應用服務器。隨著技術上對物聯(lián)網(wǎng)不斷深入的研究，也出現(xiàn)了一些優(yōu)化傳輸方面的新方案，但是基本上都需要終端和無線側網(wǎng)元的配合才能實現(xiàn)，即需要網(wǎng)絡運營商提供特殊硬件支持。這種技術實現(xiàn)起來相當復雜，一般需要國際大型協(xié)議組織和設備制造商大力推動才有可能實現(xià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標準中，對于降功耗和優(yōu)化傳輸效率的方法基本都有兩個特性，第一是需要終端底層硬件支持，實現(xiàn)復雜；第二是需要終端和網(wǎng)絡側都有相應的功能模塊實現(xiàn)才能支持，但是，這些是需要標準組織推動，網(wǎng)絡運營商支持才能實現(xiàn)的功能，成本很高。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

可選地，還包括：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

所述壓縮模塊具體用于：

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

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

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

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

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

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

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

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

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

附圖說明

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

圖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ī)則的結構的示意圖；

圖5為本發(fā)明實施例中內容類規(guī)則的結構的示意圖；

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

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

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

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

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

具體實施方式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

較佳地，為了避免網(wǎng)絡原因導致消息發(fā)送失敗，查詢接收端是否支持壓縮傳輸能力還可以包括：

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

步驟100之前還包括：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

表1

假設表1中1號http包的負載內容如下：

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

假設表1中2號http包的負載內容如下：

假設表1中5號http包的負載內容如下：

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

表2

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

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

表3

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

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

表4

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

表5

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

表6

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

表7

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

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

表8

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

表9

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

表10

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

表11

表12

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

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

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

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

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

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

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

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

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

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

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

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

壓縮模塊具體用于：

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

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

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

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

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

進一步地，

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

較佳地，為了避免網(wǎng)絡原因導致消息發(fā)送失敗，查詢接收端是否支持壓縮傳輸能力還可以包括：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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