一種數據分發方法及裝置製造方法
2023-11-07 14:12:42 2
一種數據分發方法及裝置製造方法
【專利摘要】本發明公開了一種數據分發方法及裝置，方法包括：解析來自用戶終端的GTPU報文，得到用於請求資源的HTTP請求報文，並判斷其數據請求方式是否為HTTP壓縮方式；當判斷結果是HTTP壓縮方式時，將所述報文直接發送至伺服器，否則，將其報文請求方式設置為HTTP壓縮方式，並發送至伺服器；將伺服器回應的HTTP應答報的數據格式設置為與所述HTTP請求報文的數據請求方式相適應的數據格式，並發送至用戶終端。本發明可以顯著減少Backhaul的帶寬消耗和空口的帶寬消耗。
【專利說明】一種數據分發方法及裝置
【技術領域】
[0001]本發明涉及一種基於HTTP壓縮的數據分發方法及裝置。
【背景技術】
[0002]隨著移動網際網路和智慧型手機的快速發展，手機上網瀏覽已經成為一種日益普遍的方式，隨之帶來的問題是對於基站的流量是成倍的正常。多UE(User Equipment下指智慧型手機)同時接入基站瀏覽網頁時對於空口帶寬的消耗很大。
[0003]現有的商業網際網路中，客戶端和伺服器之間採用HTTP協議進行通訊。如圖1所示，為了減輕網絡中流量的壓力，採用了 HTTP中壓縮技術。瀏覽器在請求資源時，會將支持的壓縮格式通過HTTP頭中的屬性欄位提交給伺服器，伺服器用瀏覽器支持的壓縮算法對內容進行壓縮後再傳送給瀏覽器，瀏覽器解壓後展示內容給用戶。當然，伺服器中大量的壓縮計算必然會消耗CPU從而影響效率，可以通過中間伺服器的方式來解決此問題，在此不再贅述。
[0004]在現有的基站系統中，UE請求資源通過空口到達基站時，基站只是負責透傳該請求到核心網，從核心網中獲取數據再透傳給UE。在這個過程中，基站對於UE的請求沒有做任何處理，UE的請求方式可以是壓縮方式也可以是非壓縮方式，核心網返回的數據可以是壓縮的也可以是非壓縮的。對於非壓縮方式的請求方式和返回的數據，對於空口帶寬和Backhaul帶寬的消耗是比較大的。
【發明內容】
[0005]本發明的目的在於提供一種數據分發方法及裝置，能更好地解決UE以非壓縮方式請求數據時空口帶寬和Backhaul帶寬的消耗過大問題。
[0006]根據本發明的一個方面，提供了一種數據分發方法，包括:
[0007]解析來自用戶終端的GPRS隧道協議用戶面報文，得到用於請求資源的HTTP請求報文，並判斷其數據請求方式是否為HTTP壓縮方式；
[0008]當判斷結果是HTTP壓縮方式時，將所述報文直接發送至伺服器，反之，將其報文請求方式設置為HTTP壓縮方式，並發送至伺服器；
[0009]將伺服器回應的HTTP應答報文的數據格式設置為與所述HTTP請求報文的數據請求方式相適應的數據格式，並發送至用戶終端。
[0010]優選地，根據通過解析所述HTTP請求報文所得到的數據請求方式，判斷所述報文的請求方式是否為HTTP壓縮方式。
[0011 ] 優選地，當判斷所述HTTP請求報文的數據請求方式不是HTTP壓縮方式時，在所述報文的報文頭中添加壓縮屬性，並經由核心網發送至伺服器。
[0012]優選地，若伺服器回應的HTTP應答報文的數據格式為HTTP非壓縮方式，而所述HTTP請求報文的數據請求方式為HTTP壓縮方式，則提取所述HTTP應答報文中的應答數據，並將所述數據壓縮後添加到新的HTTP應答報文中發送至用戶終端。[0013]優選地，若伺服器回應的HTTP應答報文的數據格式為HTTP壓縮方式，而所述HTTP請求報文的數據請求方式為HTTP非壓縮方式，則提取所述HTTP應答報文中的應答數據，並將所述數據解壓後添加到新的HTTP應答報文中發送至用戶終端。
[0014]優選地，若伺服器回應的HTTP應答報文的數據格式為HTTP壓縮方式，而所述HTTP請求報文的數據請求方式為HTTP壓縮方式，則將所述HTTP應答報文直接發送至用戶終端。
[0015]優選地，若伺服器回應的HTTP應答報文的數據格式為HTTP非壓縮方式，而所述HTTP請求報文的數據請求方式為HTTP非壓縮方式，則將所述HTTP應答報文直接發送至用戶終端。
[0016]根據本發明的另一方面，提供了一種數據分發裝置，包括:
[0017]上行數據解析模塊，用於接收來自用戶終端的用於請求資源的HTTP請求報文；
[0018]代理請求模塊，用於判斷所述報文的數據請求方式是否為HTTP壓縮方式，並當判斷所述報文的數據請求方式是HTTP壓縮方式時，將所述報文直接發送至伺服器，否則，將所述報文的數據請求方式修改為HTTP壓縮方式，經由核心網發送至伺服器；
[0019]下行數據解析模塊，用於接收伺服器響應所述HTTP請求報文的HTTP應答報文；
[0020]代理回應模塊，用於將所述HTTP應答報文的數據格式設置為與所述HTTP請求報文的數據請求方式相適應的數據格式，
[0021]優選地，所述代理回應模塊用於在所述HTTP請求報文的數據請求方式為HTTP壓縮方式，所述HTTP應答報文的數據格式為HTTP非壓縮方式時，提取所述HTTP應答報文中的應答數據，並將所述數據壓縮後添加到新的HTTP應答報文中發送至用戶終端。
[0022]優選地，所述代理回應模塊用於在所述HTTP請求報文的數據請求方式為HTTP非壓縮方式，所述HTTP應答報文的數據格式為HTTP壓縮方式時，提取所述HTTP應答報文中的應答數據，並將所述數據解壓後添加到新的HTTP應答報文中發送至用戶終端。
[0023]與現有技術相比較，本發明的有益效果在於:
[0024]1、UE的數據請求方式為HTTP非壓縮方式時，基站或基站控制器將其強制處理為HTTP壓縮方式，伺服器返回的也是壓縮數據，從而顯著減少了 Backhaul的帶寬消耗；
[0025]2、UE的數據請求方式為HTTP壓縮方式，伺服器返回的數據是非壓縮數據時，基站或基站控制器將數據壓縮處理後發送至UE，從而顯著減少空口的帶寬消耗。
【專利附圖】
【附圖說明】
[0026]圖1是現有技術提供的商業網際網路中的數據請求方式示意圖；
[0027]圖2是本發明實施例提供的基於HTTP壓縮的數據分發方法流程圖；
[0028]圖3是本發明實施例提供的3G制式下基於HTTP壓縮的數據分發裝置示意圖；
[0029]圖4是本發明實施例提供的4G制式下基於HTTP壓縮的數據分發系統示意圖；
[0030]圖5是本發明實施例提供的代理請求數據分發流程圖；
[0031]圖6是本發明實施例提供的代理回應數據分發請求的流程圖。
【具體實施方式】
[0032]以下結合附圖對本發明的優選實施例進行詳細說明，應當理解，以下所說明的優選實施例僅用於說明和解釋本發明，並不用於限定本發明。[0033]圖2是本發明實施例提供的基於HTTP壓縮的數據分發方法流程圖，如圖2所示，包括:
[0034]基站或基站控制器解析來自用戶終端的GPRS隧道協議用戶面報文(即GTPU報文)，得到用於請求資源的HTTP請求報文，解析所述HTTP請求報文，根據解析得到的數據請求方式，判斷所述報文的請求方式是否為HTTP壓縮方式。
[0035]當判斷結果是HTTP壓縮方式時，將所述報文直接發送至伺服器，否則，將其報文請求方式設置為HTTP壓縮方式，即在所述報文的報文頭中添加壓縮屬性後發送至伺服器。
[0036]對於伺服器響應的HTTP應答報文，基站或基站控制器將所述HTTP應答報文的數據格式設置為與所述HTTP請求報文的數據請求方式相適應的數據格式，並發送至用戶終端。具體地說，基站或基站控制器收到伺服器響應的HTTP應答報文後，若所述HTTP請求報文的數據請求方式為HTTP壓縮方式，所述HTTP應答報文的數據格式為HTTP非壓縮方式，則提取所述HTTP應答報文中的應答數據，並將所述數據壓縮後添加到新的HTTP應答報文中發送至用戶終端；若所述HTTP請求報文的數據請求方式為HTTP非壓縮方式，所述HTTP應答報文的數據格式為HTTP壓縮方式，則提取所述HTTP應答報文中的應答數據，並將所述數據解壓後添加到新的HTTP應答報文中發送至用戶終端；若所述HTTP請求報文的數據請求方式為HTTP壓縮方式，所述HTTP應答報文的數據格式為HTTP壓縮方式，則將所述HTTP應答報文直接發送至用戶終端；若所述HTTP請求報文的數據請求方式為HTTP非壓縮方式，所述HTTP應答報文的數據格式為HTTP非壓縮方式，則將所述HTTP應答報文直接發送至用戶終端。
[0037]圖3是本發明實施例提供的3G制式下基於HTTP壓縮的數據分發裝置示意圖，如圖3所示，包括位於基站或基站控制器側的以下部分:
[0038]上行數據解析模塊，用於接收來自用戶終端的用於請求資源的HTTP請求報文。具體地說，上行數據解析模塊獲取GTPU中的數據包，去掉其相關的GTPU包頭之後，提取其中的HTTP請求報文。
[0039]代理請求模塊，用於判斷所述報文的數據請求方式是否為HTTP壓縮方式，並當判斷所述報文的數據請求方式是HTTP壓縮方式時，將所述報文直接發送至伺服器，否則，將所述報文的數據請求方式修改為HTTP壓縮方式，經由核心網發送至伺服器。也就是說，代理請求模塊解析提取的HTTP請求報文，解析在請求報文中是否需要支持壓縮格式，若支持壓縮格式，則直接將請求報文發送給伺服器；若不支持壓縮格式，則採用TCP透明代理修改HTTP請求報文，在請求報文中強制添加壓縮屬性，發送給伺服器。
[0040]下行數據解析模塊，用於接收伺服器響應所述HTTP請求報文的HTTP應答報文。也就是說，下行數據解析模塊主要是截獲伺服器回應的數據，提取其中的HTTP應答報文。
[0041]代理回應模塊，用於將所述HTTP應答報文的數據格式設置為與所述HTTP請求報文的數據請求方式相適應的數據格式，並發送至用戶終端。進一步說，所述代理回應模塊在所述HTTP請求報文的數據請求方式為HTTP壓縮方式，所述HTTP應答報文的數據格式為HTTP非壓縮方式時，提取所述HTTP應答報文中的應答數據，並將所述數據壓縮後添加到新的HTTP應答報文中發送至用戶終端；所述代理回應模塊在所述HTTP請求報文的數據請求方式為HTTP非壓縮方式，所述HTTP應答報文的數據格式為HTTP壓縮方式時，提取所述HTTP應答報文中的應答數據，並將所述數據解壓後添加到新的HTTP應答報文中發送至用戶終端。也就是說，代理回應模塊提取HTTP應答報文中的數據格式是否是壓縮的，並參照HTTP請求的是否是需要壓縮的數據，分為四種情況來分別處理。I)若請求為壓縮方式，應答數據的也為壓縮方式，則直接將下行報文發送至發送隊列中；2)若請求為壓縮方式，應答為非壓縮方式，則提取報文中的數據至緩衝區中，將數據壓縮，採用TCP透明代理修改HTTP應答報文，將壓縮後的數據添加到新的應答報文中，發送至發送隊列中；3)若請求為非壓縮方式，應答為壓縮方式，則提取報文中的數據至緩衝區中，將數據解壓，採用TCP透明代理修改HTTP應答報文，將解壓後的數據添加到新的應答報文中，發送至發送隊列中；4)若請求為非壓縮方式，應答數據也為非壓縮方式，則直接將下行報文發送至發送隊列中。
[0042]圖4是本發明實施例提供的4G制式下基於HTTP壓縮的數據分發系統示意圖，如圖4所示，UE和eNodeB之間採用空口進行通信，本發明通過在基站側增加的上行數據解析模塊截取UE給eNodeB的數據，提取出GTPU報文，解析後提取HTTP請求報文；代理請求模塊解析HTTP請求報文中是否支持壓縮方式並作相關的後續處理；下行數據解析模塊主要是獲取伺服器發送過來的數據包，提取其中的HTTP應答報文；代理回應模塊主要是依據HTTP中應答報文是否是壓縮格式以及原始的HTTP請求時是否支持壓縮格式來做不同的處理。
[0043]圖5是本發明實施例提供的代理請求數據分發流程圖，如圖5所示，包括:
[0044]步驟5.1:提取用戶HTTP請求中的URL，解析用戶的HTTP請求報文，若請求報文中包含「Accept-Encoding」屬性欄位或者是「Content-Encoding」屬性欄位,將屬性值存放至全局變量QryCompressFormat中，轉至步驟5.2,否則,轉至步驟5.3 ；
[0045]步驟5.2:依據URL解析出請求對應的伺服器IP位址，直接給伺服器發送資源請求，流程結束。
[0046]步驟5.3:採用TCP透明代理構造新的HTTP請求報文，在報文頭中強制添加壓縮屬性:「Accept-Encoding = gzip, deflate」,採用gzip壓縮格式向伺服器請求數據,流程結束。
[0047]圖6是本發明實施例提供的代理回應數據分發請求的流程圖，如圖6所示，包括:
[0048]步驟6.1:從全局變量QryCompressFormat中提取用戶請求HTTP方式；
[0049]步驟6.2:提取資源的格式，通過解析伺服器回應的HTTP應答報文，若「Accept-Encoding」屬性欄位或者是「Content-Encoding」屬性欄位,則說明回應的數據格式是壓縮方式，保存該屬性欄位後面的值到變量AskCompressFormat中，即為回應數據壓縮算法；否則，則說明回應的數據格式是不支持壓縮的；
[0050]步驟6.3:判斷當前用戶的數據請求方式，若為HTTP壓縮方式，轉至步驟6.4;否則，轉至步驟6.5;
[0051]步驟6.4:判斷當前資源格式，若為HTTP壓縮方式，轉至步驟6.6 ;否則，轉至步驟
6.7 ；
[0052]步驟6.5:判斷當前資源格式，若為壓縮，轉至步驟5.10 ;否則，轉至步驟6.13 ；
[0053]步驟6.6:將下行數據輸出到發送隊列，流程結束。
[0054]步驟6.7:獲取下行的HTTP應答報文中的數據部分，存放至緩衝區，採用壓縮算法QryCompressFormat對數據進行壓縮；
[0055]步驟6.8:採用TCP透明代理構造新的HTTP回應報文；
[0056]步驟6.9:在新報文中添加壓縮後的數據，輸出到發送隊列，流程結束。[0057]舉例說明:UE1通過壓縮方式來請求Server中的數據,但是Server中回應的是非壓縮的數據。如果不用此發明中的方法在基站側將Server中回應的數據按照UEl請求的方式進行壓縮，則將該數據發送到UEl時就會消耗更多的空口帶寬。
[0058]步驟6.10:獲取下行的HTTP應答報文中的數據部分，存放至緩衝區，採用壓縮算法AskCompressFormat對數據進行解壓；
[0059]步驟6.11:採用TCP透明代理構造新的HTTP回應報文；
[0060]步驟6.12:在新的回應報文中添加解壓後的數據，輸出到發送隊列，流程結束。
[0061]舉例說明:UE2通過非壓縮方式來請求Server中的數據。如果不用此發明中的方法在基站側將請求方式強制變成壓縮方式，則Server回應請求時的數據是非壓縮的，在核心網傳送到基站時就會消耗更多的Backhaul帶寬。
[0062]步驟6.13:將下行數據輸出到發送隊列，流程結束。
[0063]儘管上文對本發明進行了詳細說明，但是本發明不限於此，本【技術領域】技術人員可以根據本發明的原理進行各種修改。因此，凡按照本發明原理所作的修改，都應當理解為落入本發明的保護範圍。
【權利要求】
1.一種數據分發方法，其特徵在於，包括: 解析來自用戶終端的GPRS隧道協議-用戶面報文，得到用於請求資源的HTTP請求報文，並判斷其數據請求方式是否為HTTP壓縮方式； 當判斷結果是HTTP壓縮方式時，將所述報文直接發送至伺服器，反之，則將其報文請求方式設置為HTTP壓縮方式後發送至伺服器； 將伺服器同應的HTTP應答報文的數據格式設置為與所述HTTP請求報文的數據請求方式相適應的數據格式，並發送至用戶終端。
2.根據權利要求1所述的方法，其特徵在於，根據通過解析所述HTTP請求報文所得到的數據請求方式，判斷所述報文的請求方式是否為HTTP壓縮方式。
3.根據權利要求2所述的方法，其特徵在於，當判斷所述HTTP請求報文的數據請求方式不是HTTP壓縮方式時，在所述報文的報文頭中添加壓縮屬性，並經由核心網發送至伺服器。
4.根據權利要求3所述的方法，其特徵在於，若伺服器回應的HTTP應答報文的數據格式為HTTP非壓縮方式，而所述HTTP請求報文的數據請求方式為HTTP壓縮方式，則提取所述HTTP應答報文中的應答數據，並將所述數據壓縮後添加到新的HTTP應答報文中發送至用戶終端。
5.根據權利要求3所述的方法，其特徵在於，若伺服器回應的HTTP應答報文的數據格式為HTTP壓縮方式，而所述HTTP請求報文的數據請求方式為HTTP非壓縮方式，則提取所述HTTP應答報文中的應答數據，並將所述數據解壓後添加到新的HTTP應答報文中發送至用戶終端。
6.根據權利要求3所述的方法，其特徵在於，若伺服器回應的HTTP應答報文的數據格式為HTTP壓縮方式，而所述HTTP請求報文的數據請求方式為HTTP壓縮方式，則將所述HTTP應答報文直接發送至用戶終端。
7.根據權利要求3所述的方法，其特徵在於，若伺服器回應的HTTP應答報文的數據格式為HTTP非壓縮方式，而所述HTTP請求報文的數據請求方式為HTTP非壓縮方式，則將所述HTTP應答報文直接發送至用戶終端。
8.一種數據分發裝置，其特徵在於，包括: 上行數據解析模塊，用於接收來自用戶終端的用於請求資源的HTTP請求報文； 代理請求模塊，用於判斷所述報文的數據請求方式是否為HTTP壓縮方式，並當判斷所述報文的數據請求方式是HTTP壓縮方式時，將所述報文直接發送至伺服器，否則，將所述報文的數據請求方式修改為HTTP壓縮方式，經由核心網發送至伺服器； 下行數據解析模塊，用於接收伺服器響應所述HTTP請求報文的HTTP應答報文； 代理回應模塊，用於將所述HTTP應答報文的數據格式設置為與所述HTTP請求報文的數據請求方式相適應的數據格式，並發送至用戶終端。
9.根據權利要求8所述的裝置，其特徵在於，所述代理回應模塊用於在所述HTTP請求報文的數據請求方式為HTTP壓縮方式，所述HTTP應答報文的數據格式為HTTP非壓縮方式時，提取所述HTTP應答報文中的應答數據，並將所述數據壓縮後添加到新的HTTP應答報文中發送至用戶終端。
10.根據權利要求8所述的裝置，其特徵在於，所述代理回應模塊用於在所述HTTP請求報文的數據請求方式為HTTP非壓縮方式，所述HTTP應答報文的數據格式為HTTP壓縮方式時，提取所述HTTP應答報文中的應答數據，並將所述數據解壓後添加到新的HTTP應答報文中發送 至用戶終端。
【文檔編號】H04L29/08GK103582012SQ201210278753
【公開日】2014年2月12日 申請日期:2012年8月7日 優先權日:2012年8月7日
【發明者】華學勤, 黃鈞, 周志雄, 崔卓 申請人:中興通訊股份有限公司