專利名稱：基于冗余編碼的http報文傳輸、發(fā)送和接收方法
技術領域：
本發(fā)明涉及一種HTTP報文傳輸技術，尤其涉及內(nèi)容分發(fā)網(wǎng)絡(⑶N網(wǎng)絡)的HTTP 報文傳輸技術。
背景技術：
超文本傳輸協(xié)議(HTTP)是互聯(lián)網(wǎng)上應用最為廣泛的一種網(wǎng)絡協(xié)議，通過HTTP協(xié)議傳輸?shù)腤WW文件對內(nèi)容的正確性有嚴格要求，因此要求可靠傳輸，而HTTP協(xié)議本身沒有規(guī)定實現(xiàn)可靠傳輸?shù)臋C制，因此依賴于TCP協(xié)議的可靠傳輸機制。
TCP協(xié)議是一種可靠的面向連接的傳輸層協(xié)議，它通過以下方式來提供HTTP報文傳輸?shù)目煽啃?br> I.發(fā)送端把HTTP報文分割為數(shù)據(jù)塊，并給每一個數(shù)據(jù)塊編號，作為報文發(fā)送。
2.發(fā)送端每發(fā)出一個報文后就為它啟動一個定時器，等待目的端確認收到這個報文。目的端收到一個報文時，它將發(fā)送一個確認。
3.如果不能按時收到確認，它就重發(fā)這個報文。否則繼續(xù)發(fā)送后續(xù)報文。
TCP協(xié)議可以保證HTTP報文傳輸?shù)恼_性，但同時也帶來一些問題。HTTP協(xié)議通常用于在網(wǎng)站服務器和用戶使用的瀏覽器之間傳輸WWW文件，HTTP請求的響應時間將對用戶體驗有重要影響，傳輸時間越長，用戶體驗越差。特別對于內(nèi)容分發(fā)網(wǎng)絡而言，HTTP請求的響應時間是內(nèi)容分發(fā)網(wǎng)絡服務質(zhì)量的重要評價指標之一。TCP協(xié)議可能會延長HTTP報文的傳輸時間
(I )TCP協(xié)議使用三次握手建立連接，會有一定的網(wǎng)絡開銷，對于越小的HTTP消息 (比如302和304響應等)影響越大；
(2)如果發(fā)送的報文丟失或出錯，發(fā)送方需要等到定時器超時后才會重新發(fā)送出錯的報文，會延長HTTP報文的傳輸時間。發(fā)明內(nèi)容
本發(fā)明的目的在于解決上述問題，提供了一種基于冗余編碼的HTTP報文傳輸方法，使得在內(nèi)容分發(fā)網(wǎng)絡中傳輸HTTP報文時避免TCP協(xié)議在三次握手和超時重傳的時間開銷，減少HTTP報文在⑶N網(wǎng)絡中的傳輸時間。
本發(fā)明還提供了一種基于冗余編碼的HTTP報文發(fā)送方法和基于冗余編碼的HTTP 報文發(fā)送方法的接收方法。
本發(fā)明的技術方案為本發(fā)明揭示了一種基于冗余編碼的HTTP報文傳輸方法，包括客戶端發(fā)送HTTP請求報文的流程和服務器接收HTTP請求并發(fā)送響應的流程，其中
客戶端通過UDP協(xié)議，以冗余編碼的方式發(fā)送HTTP請求報文并同時啟動定時器， 若超過定時器所設的時限值之后未收到來自服務器的HTTP響應或者收到不完整的HTTP響應報文，則使用TCP協(xié)議再次發(fā)送HTTP請求報文；
服務器若通過UDP協(xié)議接收到來自客戶端的以UDP協(xié)議發(fā)送的HTTP請求報文，則通過m)P協(xié)議并以冗余編碼的方式發(fā)送HTTP響應，服務器若收到TCP協(xié)議發(fā)送的HTTP請求，則使用TCP協(xié)議發(fā)送HTTP響應。
根據(jù)本發(fā)明的基于冗余編碼的HTTP報文傳輸方法的一實施例，客戶端通過UDP協(xié)議，以冗余編碼的方式發(fā)送HTTP請求報文的過程進一步包括
客戶端對將要發(fā)送的HTTP請求報文進行分片，其中每個分片長度小于UDP負荷的最大長度以使每個分片能夠在一個UDP報文中發(fā)送；
客戶端對每一 HTTP請求報文的所有分片進行冗余編碼，并對獲得的冗余數(shù)據(jù)進行分片，每個分片長度小于UDP負荷的最大長度；
客戶端發(fā)送HTTP請求報文分片和冗余數(shù)據(jù)分片。
根據(jù)本發(fā)明的基于冗余編碼的HTTP報文傳輸方法的一實施例，服務器通過UDP協(xié)議并以冗余編碼的方式發(fā)送HTTP響應的過程進一步包括
服務器對將要發(fā)送的HTTP響應進行分片，其中每個分片長度小于UDP負荷的最大長度以使每個分片能夠在一個UDP報文中發(fā)送；
服務器對每一 HTTP響應的所有分片進行冗余編碼，并對獲得的冗余數(shù)據(jù)進行分片，每個分片長度小于UDP負荷的最大長度；
服務器發(fā)送HTTP響應的分片和冗余數(shù)據(jù)分片。
根據(jù)本發(fā)明的基于冗余編碼的HTTP報文傳輸方法的一實施例，以流水線方式處理HTTP請求報文分片/HT TP響應分片和冗余數(shù)據(jù)分片。
根據(jù)本發(fā)明的基于冗余編碼的HTTP報文傳輸方法的一實施例，服務器通過UDP協(xié)議接收來自客戶端的以UDP協(xié)議發(fā)送的HTTP請求報文的過程進一步包括
服務器接收分片，若接收到所有的HTTP請求報文分片，則停止接收數(shù)據(jù)，并將這些所有的HTTP請求報文分片組裝成HTTP報文，若接收的數(shù)據(jù)中丟失了若干個分片，則判斷是否能夠使用收到的其他HTTP報文分片和冗余數(shù)據(jù)分片計算出丟失的分片數(shù)據(jù)，若能則計算丟失數(shù)據(jù)并組裝成HTTP報文，若不能則等待客戶端使用TCP協(xié)議重新發(fā)送的請求。
本發(fā)明還揭示了一種基于冗余編碼的HTTP報文發(fā)送方法，包括
發(fā)送方對將要發(fā)送的HTTP報文進行分片，其中每個分片長度小于UDP負荷的最大長度以使每個分片能夠在一個UDP報文中發(fā)送；
發(fā)送方對每一 HTTP報文的所有分片進行冗余編碼，并對獲得的冗余數(shù)據(jù)進行分片，每個分片長度小于UDP負荷的最大長度；
發(fā)送方發(fā)送HTTP報文分片和冗余數(shù)據(jù)分片。
根據(jù)本發(fā)明的基于冗余編碼的HTTP報文發(fā)送方法的一實施例，發(fā)送方以流水線方式處理HTTP報文分片，即在分片和計算冗余編碼的同時進行發(fā)送。
本發(fā)明還揭示了一種基于冗余編碼的HTTP報文接收方法，包括
接收方接收HTTP報文分片；
若接收到所有的HTTP報文分片，則停止接收數(shù)據(jù)，并將這些所有的HTTP報文分片組裝成HTTP報文；
若接收的數(shù)據(jù)中丟失了若干個分片，則判斷是否能夠使用收到的其他HTTP報文分片和冗余數(shù)據(jù)分片計算出丟失的分片數(shù)據(jù)；
若能則計算丟失數(shù)據(jù)并組裝成HTTP報文，若不能則等待發(fā)送方使用TCP協(xié)議重新發(fā)送請求。
本發(fā)明對比現(xiàn)有技術有如下的有益效果本發(fā)明的方案是使用UDP協(xié)議和冗余編碼技術在CDN網(wǎng)絡的內(nèi)部節(jié)點之間傳輸HTTP報文，相比于傳統(tǒng)技術，本發(fā)明的方案使得在 ⑶N網(wǎng)絡傳輸HTTP報文時避免TCP協(xié)議在三次握手和超時重傳的時間開銷，減少HTTP報文在⑶N網(wǎng)絡中的傳輸時間。


圖I是傳統(tǒng)的通過TCP協(xié)議進行HTTP報文傳輸?shù)牧鞒虉D。
圖2示出了本發(fā)明的客戶端發(fā)送HTTP請求報文的流程圖。
圖3示出了本發(fā)明的服務器接收HTTP請求并響應的流程圖。
圖4示出了本發(fā)明的使用UDP協(xié)議發(fā)送HTTP報文的流程圖。
圖5示出了本發(fā)明的使用UDP協(xié)議接收HTTP報文的流程圖。
具體實施方式
下面結(jié)合附圖和實施例對本發(fā)明作進一步的描述。
本發(fā)明的基于冗余編碼的HTTP報文傳輸方法的實施例包括圖2所示的客戶端發(fā)送HTTP請求報文的流程和圖3所示的服務器接收HTTP請求并發(fā)送響應的流程。
請參考圖2，以下是客戶端發(fā)送HTTP請求報文的各個步驟的詳細描述。
步驟SlO :客戶端通過UDP協(xié)議，以冗余編碼的方式發(fā)送HTTP請求報文，并同時啟動定時器。
客戶端使用UDP協(xié)議發(fā)送HTTP請求報文的具體過程請參考圖4的描述?？蛻舳丝梢砸粤魉€方式處理HTTP請求報文分片和冗余數(shù)據(jù)分片。
步驟Sll :判斷是否在定時器設定的時限值內(nèi)接收到響應，即響應是否超時。若超時則進入步驟S12處理，否則進入步驟S13處理。
步驟S12 :客戶端使用TCP協(xié)議重新發(fā)送HTTP請求報文，然后進入步驟S15處理。
步驟S13 :客戶端接收來自服務器的以UDP協(xié)議傳輸?shù)腍TTP響應。
客戶端使用UDP協(xié)議接收HTTP響應的過程請參考圖5的描述。
步驟S14 :檢查接收到的HTTP響應是否完整，若不完整則進入步驟S12處理，若完整則進入步驟S16處理。
步驟S15 :客戶端接收來自服務器的以TCP協(xié)議傳輸?shù)腍TTP響應，然后進入步驟 S16處理。
步驟S16 :客戶端處理來自服務器的HTTP響應。
請參考圖3，以下是服務器接收HTTP請求并發(fā)送響應的各個步驟的詳細描述。
步驟S20 :服務器同時監(jiān)聽TCP端口和UDP端口。
步驟S21 :判斷監(jiān)聽到的數(shù)據(jù)的連接類型，若為TCP協(xié)議的連接則進入步驟S22處理，若為UDP協(xié)議的連接則進入步驟S24。
步驟S22 :服務器接收來自客戶端的以TCP協(xié)議傳輸?shù)腍TTP請求。
步驟S23 :服務器使用TCP協(xié)議發(fā)送HTTP響應。
步驟S24 :服務器以UDP協(xié)議接收來自客戶端的通過UDP發(fā)送的HTTP請求。
服務器使用UDP協(xié)議接收HTTP請求的過程請參考圖5所示。
步驟S25 :檢查接收到的HTTP請求是否完整，若不完整則進入步驟S26處理，若完整則進入步驟S27處理。
步驟S26 :服務器丟棄HTTP請求，不進行響應。
步驟S27 :服務器使用UDP協(xié)議發(fā)送HTTP響應。
服務器使用UDP協(xié)議發(fā)送HTTP響應的過程請參考圖4的描述。服務器可以以流水線方式處理HTTP響應分片和冗余數(shù)據(jù)分片。
圖4示出了本發(fā)明的使用UDP協(xié)議發(fā)送HTTP報文的流程。請參考圖4，以下是對發(fā)送方發(fā)送HTTP報文的各個步驟的詳細描述。
步驟S30 發(fā)送方獲取HTTP報文。
這里的HTTP報文可以是圖2中的由客戶端發(fā)送的HTTP請求，也可以是圖3中的由源服務器發(fā)送的HTTP響應。
發(fā)送。
分片。
步驟S31 :發(fā)送方將HTTP報文進行分片。其中每個分片的長度小于UDP負荷的最大長度，保證每一分片在一個UDP報文中步驟S32 :發(fā)送方根據(jù)HTTP報文分片計算冗余編碼數(shù)據(jù)，并把冗余編碼數(shù)據(jù)進行步驟S33 :發(fā)送方發(fā)送HTTP報文分片和冗余編碼數(shù)據(jù)分片。較佳的，發(fā)送方以流水線方式處理HTTP報文分片，即在分片和計算冗余編碼的同時進行發(fā)送。
圖5示出了本發(fā)明的基于冗余編碼的HTTP報文接收方法的流程。請參考圖5，以下是對接收方接收HTTP報文的各個步驟的詳細描述。
步驟S40 :接收方接收HTTP報文分片并啟動定時器。
步驟S41 :判斷等待是否超時，若超時則進入步驟S46處理，若不超時則進入步驟 S42處理。
步驟S42 :檢查是否接收到了完整的HTTP報文分片，若接收到了完整的HTTP報文分片則進入步驟S45處理，否則進入步驟S43和S40進行處理。
步驟S43 :判斷是否能夠根據(jù)現(xiàn)有的數(shù)據(jù)(即接收到的其他HTTP報文分片和冗余數(shù)據(jù)分片)恢復丟失的數(shù)據(jù)。若可以則進入步驟S44處理，否則返回步驟S40處理。
步驟S44:使用收到的其他HTTP報文分片和冗余數(shù)據(jù)分片計算出丟失的分片數(shù)據(jù)。
步驟S45 :根據(jù)完整的HTTP報文分片組裝成HTTP報文。
步驟S46 :相應的處理是指，如果接收到的是HTTP請求則直接丟棄請求(針對服務器接收而言)，如果接收到的是HTTP響應則使用TCP協(xié)議重新發(fā)送HTTP請求(針對客戶端發(fā)送而言)。
上述實施例是提供給本領域普通技術人員來實現(xiàn)和使用本發(fā)明的，本領域普通技術人員可在不脫離本發(fā)明的發(fā)明思想的情況下，對上述實施例做出種種修改或變化，因而本發(fā)明的保護范圍并不被上述實施例所限，而應該是符合權利要求書所提到的創(chuàng)新性特征的最大范圍。
權利要求
1.一種基于冗余編碼的HTTP報文傳輸方法，包括客戶端發(fā)送HTTP請求報文的流程和服務器接收HTTP請求并發(fā)送響應的流程，其中客戶端通過UDP協(xié)議，以冗余編碼的方式發(fā)送HTTP請求報文并同時啟動定時器，若超過定時器所設的時限值之后未收到來自服務器的HTTP響應或者收到不完整的HTTP響應報文，則使用TCP協(xié)議再次發(fā)送HTTP請求報文；服務器若通過UDP協(xié)議接收到來自客戶端的以UDP協(xié)議發(fā)送的HTTP請求報文，則通過 UDP協(xié)議并以冗余編碼的方式發(fā)送HTTP響應，服務器若收到TCP協(xié)議發(fā)送的HTTP請求，則使用TCP協(xié)議發(fā)送HTTP響應。
2.根據(jù)權利要求I所述的基于冗余編碼的HTTP報文傳輸方法，其特征在于，客戶端通過UDP協(xié)議，以冗余編碼的方式發(fā)送HTTP請求報文的過程進一步包括客戶端對將要發(fā)送的HTTP請求報文進行分片，其中每個分片長度小于UDP負荷的最大長度以使每個分片能夠在一個UDP報文中發(fā)送；客戶端對每一 HTTP請求報文的所有分片進行冗余編碼，并對獲得的冗余數(shù)據(jù)進行分片，每個分片長度小于UDP負荷的最大長度；客戶端發(fā)送HTTP請求報文分片和冗余數(shù)據(jù)分片。
3.根據(jù)權利要求I所述的基于冗余編碼的HTTP報文傳輸方法，其特征在于，服務器通過UDP協(xié)議并以冗余編碼的方式發(fā)送HTTP響應的過程進一步包括服務器對將要發(fā)送的HTTP響應進行分片，其中每個分片長度小于UDP負荷的最大長度以使每個分片能夠在一個UDP報文中發(fā)送；服務器對每一 HTTP響應的所有分片進行冗余編碼，并對獲得的冗余數(shù)據(jù)進行分片，每個分片長度小于UDP負荷的最大長度；服務器發(fā)送HTTP響應的分片和冗余數(shù)據(jù)分片。
4.根據(jù)權利要求2或3所述的基于冗余編碼的HTTP報文傳輸方法，其特征在于，以流水線方式處理HTTP請求報文分片/HTTP響應分片和冗余數(shù)據(jù)分片。
5.根據(jù)權利要求I所述的基于冗余編碼的HTTP報文傳輸方法，其特征在于，服務器通過m)P協(xié)議接收來自客戶端的以UDP協(xié)議發(fā)送的HTTP請求報文的過程進一步包括服務器接收分片，若接收到所有的HTTP請求報文分片，則停止接收數(shù)據(jù)，并將這些所有的HTTP請求報文分片組裝成HTTP報文，若接收的數(shù)據(jù)中丟失了若干個分片，則判斷是否能夠使用收到的其他HTTP報文分片和冗余數(shù)據(jù)分片計算出丟失的分片數(shù)據(jù)，若能則計算丟失數(shù)據(jù)并組裝成HTTP報文，若不能則等待客戶端使用TCP協(xié)議重新發(fā)送的請求。
6.一種基于冗余編碼的HTTP報文發(fā)送方法，包括發(fā)送方對將要發(fā)送的HTTP報文進行分片，其中每個分片長度小于UDP負荷的最大長度以使每個分片能夠在一個UDP報文中發(fā)送；發(fā)送方對每一 HTTP報文的所有分片進行冗余編碼，并對獲得的冗余數(shù)據(jù)進行分片，每個分片長度小于UDP負荷的最大長度；發(fā)送方發(fā)送HTTP報文分片和冗余數(shù)據(jù)分片。
7.根據(jù)權利要求6所述的基于冗余編碼的HTTP報文發(fā)送方法，其特征在于，發(fā)送方以流水線方式處理HTTP報文分片，即在分片和計算冗余編碼的同時進行發(fā)送。
8.一種基于冗余編碼的HTTP報文接收方法，包括接收方接收HTTP報文分片；若接收到所有的HTTP報文分片，則停止接收數(shù)據(jù)，并將這些所有的HTTP報文分片組裝成HTTP報文；若接收的數(shù)據(jù)中丟失了若干個分片，則判斷是否能夠使用收到的其他HTTP報文分片和冗余數(shù)據(jù)分片計算出丟失的分片數(shù)據(jù)；若能則計算丟失數(shù)據(jù)并組裝成HTTP報文，若不能則等待發(fā)送方使用TCP協(xié)議重新發(fā)送請求。
全文摘要
本發(fā)明公開了基于冗余編碼的HTTP報文傳輸、發(fā)送和接收方法，使CDN網(wǎng)絡中傳輸HTTP報文時避免TCP協(xié)議在三次握手和超時重傳的時間開銷，減少HTTP報文的傳輸時間。其技術方案為客戶端通過UDP協(xié)議，以冗余編碼的方式發(fā)送HTTP請求報文并同時啟動定時器，若超過定時器所設的時限值之后未收到來自服務器的HTTP響應或者收到不完整的HTTP響應報文，則使用TCP協(xié)議再次發(fā)送HTTP請求報文；服務器若通過UDP協(xié)議接收到來自客戶端的以UDP協(xié)議發(fā)送的HTTP請求報文，則通過UDP協(xié)議并以冗余編碼的方式發(fā)送HTTP響應，服務器若收到TCP協(xié)議發(fā)送的HTTP請求，則使用TCP協(xié)議發(fā)送HTTP響應。
文檔編號H04L1/00GK102917076SQ201210465499
公開日2013年2月6日 申請日期2012年11月16日 優(yōu)先權日2012年11月16日
發(fā)明者洪珂, 郭文強, 程豪 申請人:網(wǎng)宿科技股份有限公司