本發(fā)明屬于數(shù)據(jù)處理領域，尤其涉及一種數(shù)據(jù)上傳方法、裝置及系統(tǒng)。

背景技術(shù)：

目前，用戶通過客戶機向互聯(lián)網(wǎng)數(shù)據(jù)中心(internetdatacenter，簡稱idc)上傳數(shù)據(jù)主要有以下兩種方式：

(1)客戶機向idc直接上傳：客戶機與idc之間建立連接，通過建立的連接向idc直接上傳數(shù)據(jù)。如圖1所示，其為現(xiàn)有的客戶機直接向idc上傳數(shù)據(jù)的示意圖。

實際應用中，客戶機與idc之間的物理距離可能比較遠，導致客戶機與idc之間的往返傳輸時間(roundtriptime，簡稱rtt)比較長。當rtt比較長時，往往導致客戶機與idc之間建立連接的時候耗時較長，而且處于無線場景下建連的難度更大。而且由于rtt比較長，在tcp發(fā)送窗口沒有達到帶寬時延乘積(bandwidthdelayproduct，簡稱bdp)情況下，上傳吞吐量比較低。進一步地，由于rtt比較長，客戶機和idc之間的路由跳數(shù)就會比較多，丟包率較高。

(2)通過內(nèi)容分發(fā)網(wǎng)絡(contentdeliverynetwork，簡稱cdn)進行中轉(zhuǎn)：cdn設置在客戶機與idc之間，客戶機首先將待上傳的數(shù)據(jù)上傳到cdn上，cdn向客戶機返回一個上傳成功的消息，然后cdn將接收到的數(shù)據(jù)進行壓縮或者轉(zhuǎn)換后轉(zhuǎn)發(fā)給idc。如圖2所示，其為現(xiàn)有的客戶機通過cdn向idc上傳數(shù)據(jù)的示意圖。

在cdn中轉(zhuǎn)方式下，cdn需要對上傳的數(shù)據(jù)進行中間落地存儲，當存儲上傳數(shù)據(jù)的服務器出現(xiàn)宕機時，可能出現(xiàn)數(shù)據(jù)丟失的情況。cdn將接收到的上傳數(shù)據(jù)存儲結(jié)束后客戶機就能接收到cdn返回上傳成功的 消息，此時，數(shù)據(jù)還停留在cdn節(jié)點上，并未到達互聯(lián)網(wǎng)數(shù)據(jù)中心。而且當出現(xiàn)存儲上傳數(shù)據(jù)的服務器宕機導致丟失數(shù)據(jù)時，此時雖然客戶機上傳成功，但是上傳的數(shù)據(jù)卻不存在。

由于cdn需要落地存儲數(shù)據(jù)，可能出現(xiàn)數(shù)據(jù)熱點問題。實際應用中，大部分磁盤寫入效率不高，會增加數(shù)據(jù)上傳的總延時。為了加速轉(zhuǎn)發(fā)上傳的數(shù)據(jù)，時cdn需要壓縮或者轉(zhuǎn)換處理上傳的數(shù)據(jù)，實際存儲的數(shù)據(jù)和上傳的數(shù)據(jù)并不一樣，而且導致數(shù)據(jù)上傳的耗時較長。

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

本發(fā)明提供一種數(shù)據(jù)上傳方法、裝置及系統(tǒng)，用于解決現(xiàn)有客戶機向互聯(lián)網(wǎng)數(shù)據(jù)中心idc上傳數(shù)據(jù)時存在耗時較長的問題。

為了實現(xiàn)上述目的，本發(fā)明提供了一種數(shù)據(jù)上傳方法，包括：

代理模塊接收客戶機基于流式上傳技術(shù)上傳的數(shù)據(jù)；

所述代理模塊基于流式上傳技術(shù)將所述數(shù)據(jù)上傳到互聯(lián)網(wǎng)數(shù)據(jù)中心idc；

其中，所述代理模塊部署的位置滿足預設條件，其中所述預設條件為：客戶機基于所述代理模塊向所述idc上傳數(shù)據(jù)所耗費的最小時長小于等于所述客戶機直接向所述idc上傳數(shù)據(jù)耗費的最小時長。

為了實現(xiàn)上述目的，本發(fā)明提供了一種數(shù)據(jù)上傳裝置，包括：

接收單元，用于接收客戶機基于流式上傳技術(shù)上傳的數(shù)據(jù)；

上傳單元，用于基于流式上傳技術(shù)將所述數(shù)據(jù)上傳到互聯(lián)網(wǎng)數(shù)據(jù)中心idc；

其中所述數(shù)據(jù)上傳裝置的部署位置滿足預設條件，其中所述預設條件為：客戶機基于所述數(shù)據(jù)上傳裝置向所述idc上傳數(shù)據(jù)所耗費的最小時長小于等于所述客戶機直接向所述idc上傳數(shù)據(jù)耗費的最小時長。

為了實現(xiàn)上述目的，本發(fā)明提供了一種數(shù)據(jù)上傳系統(tǒng)，包括：

客戶機，用于向通過代理模塊向互聯(lián)網(wǎng)數(shù)據(jù)中心idc上傳數(shù)據(jù)；

所述代理模塊，用于接收所述客戶機基于流式上傳技術(shù)上傳的所述數(shù)據(jù)，以及基于流式上傳技術(shù)將所述數(shù)據(jù)上傳到所述idc上；

所述idc，用于接收所述代理模塊轉(zhuǎn)發(fā)的所述客戶機上傳的所述數(shù)據(jù)；

其中，所述代理模塊部署的位置滿足預設條件，其中所述預設條件為：所述客戶機基于所述代理模塊向所述idc上傳數(shù)據(jù)所耗費的最小時長小于等于所述客戶機直接向所述idc上傳數(shù)據(jù)耗費的最小時長。

本發(fā)明提供的數(shù)據(jù)上傳方法、裝置及系統(tǒng)，通過在客戶機與互聯(lián)網(wǎng)數(shù)據(jù)中心idc之間就近部署代理模塊，代理模塊分別與客戶機和互聯(lián)網(wǎng)數(shù)據(jù)中心idc基于流式上傳技術(shù)傳輸數(shù)據(jù)。本實施例中，通過增加代理模塊來縮短用戶到idc之間的往返傳輸時間rtt，rtt變短后，則相應地提高數(shù)據(jù)的傳輸速度，而且代理模塊基于流式傳輸上傳數(shù)據(jù)，不再需要對數(shù)據(jù)進行落地存儲和轉(zhuǎn)換，節(jié)省資源和時間，進一步地提高上傳的速度。

附圖說明

圖1為現(xiàn)有的客戶機直接向idc上傳數(shù)據(jù)的示意圖；

圖2為現(xiàn)有的客戶機通過cdn向idc上傳數(shù)據(jù)的示意圖；

圖3為本發(fā)明實施例一的數(shù)據(jù)上傳方法的流程示意圖；

圖4為本實施例一的數(shù)據(jù)上傳方法的應用示意圖之一；

圖5為本實施例一的數(shù)據(jù)上傳方法的應用示意圖之二；

圖6為本實施例一的數(shù)據(jù)上傳方法的應用示意圖之三；

圖7為本實施例一的數(shù)據(jù)上傳方法的應用示意圖之四；

圖8為本實施例一的數(shù)據(jù)上傳方法的應用示意圖之五；

圖9為本發(fā)明實施例二的數(shù)據(jù)上傳方法的流程示意圖；

圖10為本發(fā)明實施例三的數(shù)據(jù)上傳裝置的結(jié)構(gòu)示意圖；

圖11為本發(fā)明實施例四的數(shù)據(jù)上傳系統(tǒng)的結(jié)構(gòu)示意圖。

具體實施方式

下面結(jié)合附圖對本發(fā)明實施例提供的數(shù)據(jù)上傳方法、裝置及系統(tǒng)進行詳細描述。

實施例一

如圖1所示，其為本發(fā)明實施例一的數(shù)據(jù)上傳方法的流程示意圖。該數(shù)據(jù)上傳方法包括以下步驟：

s101、代理模塊接收客戶機基于流式上傳技術(shù)上傳的數(shù)據(jù)。

本實施例中，客戶機(client)與互聯(lián)網(wǎng)數(shù)據(jù)中心idc之間部署有一個代理模塊，通過該代理模塊實現(xiàn)客戶機向idc上傳數(shù)據(jù)。本實施例中的代理模塊可以是代理服務器也可以是設置在其他服務器上的執(zhí)行代理功能的程序模塊(proxy)。

部署代理模塊需要滿足以下預設條件：客戶機基于部署的代理模塊向互聯(lián)網(wǎng)數(shù)據(jù)中心idc上傳數(shù)據(jù)的最小時長小于等于客戶機直接向互聯(lián)網(wǎng)數(shù)據(jù)中心idc上傳數(shù)據(jù)所耗費的最小時長。代理模塊的部署的位置就是代理模塊在傳輸鏈路中的位置，本實施例中，用代理模塊與客戶機之間的rtt來表示代理模塊與客戶機之間的傳輸距離，用代理模塊與互聯(lián)網(wǎng)數(shù)據(jù)中心idc之間的rtt，來表示代理模塊與互聯(lián)網(wǎng)數(shù)據(jù)中心idc之間的傳輸距離。

例如，客戶機直接向互聯(lián)網(wǎng)數(shù)據(jù)中心idc上傳數(shù)據(jù)時，客戶機與互聯(lián)網(wǎng)數(shù)據(jù)中心idc所需的數(shù)據(jù)傳輸時間為第一往返傳輸時間rtt1，而客戶機與互聯(lián)網(wǎng)數(shù)據(jù)中心idc的連接建立時間至少為一個rtt1，則客戶機直接向互聯(lián)網(wǎng)數(shù)據(jù)中心idc上傳數(shù)據(jù)所耗費的最小時長為2rtt1?？蛻魴C通過部署的代理模塊向互聯(lián)網(wǎng)數(shù)據(jù)中心idc上傳數(shù)據(jù)時，客戶機與代理模塊所需的數(shù)據(jù)傳輸時間為第二往返傳輸時間為rtt2，代理模塊與互聯(lián)網(wǎng)數(shù)據(jù)中心idc所需的數(shù)據(jù)傳輸時間為第三往返傳輸時間為rtt3。客戶機與代理模塊之間的連接建立時間至少一個rtt2，則客戶機基于代理模塊向互聯(lián)網(wǎng)數(shù)據(jù)中心idc上傳數(shù)據(jù)所耗費的最小時長為2rtt1+rtt3。預設條件為：2rtt2+rtt3≤2rtt1。

本實施例中，客戶機與代理模塊之間采用傳輸控制協(xié)議(transmissioncontrolprotocol，簡稱tcp)方式進行連接，代理模塊與互聯(lián)網(wǎng)數(shù)據(jù)中心idc之間采用長連接方式進行連接。其中，代理模塊與互聯(lián)網(wǎng)數(shù)據(jù)中心idc之間的長連接使用專線或者連接保障技術(shù)，以減 少代理模塊與數(shù)據(jù)網(wǎng)絡中心之間的丟包率。

一般情況下，當代理模塊與互聯(lián)網(wǎng)數(shù)據(jù)中心idc或者客戶機之間因為故障或者異常情況出現(xiàn)丟包時，代理模塊會降低傳輸速度，如果要想恢復上次的傳輸速率，則需要一個rtt的時間，這樣代理模塊與客戶機以及互聯(lián)網(wǎng)數(shù)據(jù)中心idc所需的rtt越短，代理模塊與互聯(lián)網(wǎng)數(shù)據(jù)中心idc以及客戶機之間的速率恢復越快，進而更加有利于數(shù)據(jù)的加速傳輸。

當客戶機試圖向互聯(lián)網(wǎng)數(shù)據(jù)中心idc上傳數(shù)據(jù)時，客戶機就會與代理模塊建立tcp連接，當連接建立完成后，客戶機基于流式上傳技術(shù)向代理模塊發(fā)送數(shù)據(jù)。

s102、代理模塊基于流式上傳技術(shù)將所述數(shù)據(jù)上傳到互聯(lián)網(wǎng)數(shù)據(jù)中心idc。

代理模塊與互聯(lián)網(wǎng)數(shù)據(jù)中心idc之間采用長連接，當代理模塊與互聯(lián)網(wǎng)數(shù)據(jù)中心idc之間長連接建立完成之后，在代理模塊與互聯(lián)網(wǎng)數(shù)據(jù)中心idc完成一次數(shù)據(jù)讀寫之后，它們之間的長連接會繼續(xù)保持，并不會主動關(guān)閉，后續(xù)的讀寫操作可以繼續(xù)使用這個處于保持狀態(tài)的長連接。

本實施例中，每當客戶機請求向代理模塊上傳數(shù)據(jù)后，代理模塊與互聯(lián)網(wǎng)數(shù)據(jù)中心idc之間不再需要耗費時間重新建立連接，從而節(jié)省了建立連接所需的一個rtt。

實際應用中，設備之間的連接從開始建立到該連接達到可使用的最大帶寬，需要耗費一定的時間。而長連接的方式可以讓發(fā)送窗口保持在bdp附近，這樣就無需不斷重復從開始建立到該連接達到可使用的最大帶寬的過程，從而節(jié)省了上述從開始建立到該連接達到可使用的最大帶寬過程所需耗費的時間。

在接收到數(shù)據(jù)后，代理模塊并不對數(shù)據(jù)進行任何處理，直接基于流式上傳技術(shù)直接將接收到的數(shù)據(jù)上傳到idc上。本實施例中，基于流式上傳技術(shù)上傳數(shù)據(jù)，代理模塊不需要進行中間存儲，這樣不會出現(xiàn)在cdn中存儲數(shù)據(jù)的服務器出現(xiàn)宕機而導致數(shù)據(jù)丟失的情況，而且不需要對數(shù)據(jù)落地存儲，避免出現(xiàn)數(shù)據(jù)熱點問題。進一步地，代理模塊不需要對數(shù)據(jù)進行轉(zhuǎn)換，以將數(shù)據(jù)縮小加速傳輸速度，相應地，互聯(lián)網(wǎng)數(shù)據(jù)中心idc 就可以直接存儲客戶機的源數(shù)據(jù)。而且基于流式上傳技術(shù)傳輸數(shù)據(jù)，當客戶機上傳完所有的數(shù)據(jù)后，相應地互聯(lián)網(wǎng)數(shù)據(jù)中心也就接收到了該數(shù)據(jù)，兩者是實時同步的。

此處需要說明，本實施例中的客戶機向互聯(lián)網(wǎng)數(shù)據(jù)中心上傳的數(shù)據(jù)的數(shù)據(jù)量大小需要控制在14kb～5mb范圍內(nèi)，在該范圍內(nèi)的數(shù)據(jù)基于代理模塊上傳的速度較快。

本實施例中，設定上傳耗時為rt，用戶系統(tǒng)初始發(fā)送窗口值為initwnd，用戶帶寬為bandwidth，上傳的數(shù)據(jù)大小為filesize，客戶機到互聯(lián)網(wǎng)數(shù)據(jù)中心所在服務器的往返傳輸時間為rttofclienttoidc，客戶機到代理模塊所在服務器的往返傳輸時間為rttofclienttoproxy，代理模塊所在服務器到互聯(lián)網(wǎng)數(shù)據(jù)中心所在服務器的往返傳輸時間為rttofproxytoidc，發(fā)送窗口上升到滿帶寬需要消耗的rttofclient數(shù)量為n，帶寬延時積bdp，以2為底數(shù)的對數(shù)函數(shù)log。

設定在不丟失包的傳輸條件，分別對客戶機直接將數(shù)據(jù)上傳到互聯(lián)網(wǎng)數(shù)據(jù)中心idc的方式以及本實施例中提供的數(shù)據(jù)上傳方法的上傳耗時進行測試。

客戶機直接將數(shù)據(jù)上傳到互聯(lián)網(wǎng)數(shù)據(jù)中心idc方式的上傳耗時：

當bdp小于initwnd時，無需提升發(fā)送窗口的帶寬，發(fā)送窗口可以在允許使用的最大帶寬進行上傳，此時上傳耗時為：

rt＝filesize/bandwidth+rttofclienttoidc

當數(shù)據(jù)大小小于滿帶寬時發(fā)送窗口可傳輸?shù)臄?shù)據(jù)大小情況下，此時上傳耗時為：

rt＝(log(filesize/initwnd)+2)*rttofclienttoidc

當數(shù)據(jù)大小大小滿帶寬時發(fā)送窗口可傳輸?shù)臄?shù)據(jù)大小情況下，此時上傳耗時為：

n＝log(bdp/initwnd)

rt＝((filesize-2^(n-1)*initwnd)/bandwidth)+(n+1)*rttofclienttoidc

本實施例中提供的數(shù)據(jù)上傳方法的上傳耗時：

當bdp小于initwnd時，無需提升發(fā)送窗口的帶寬，發(fā)送窗口可以在 允許使用的最大帶寬進行上傳，此時上傳耗時為：

rt＝filesize/bandwidth+rttofclienttoproxy+rttofproxytoidc

當數(shù)據(jù)大小小于滿帶寬時發(fā)送窗口可傳輸?shù)臄?shù)據(jù)大小情況下，此時上傳耗時為：

rt＝(log(filesize/initwnd)+2)*rttofclienttoproxy+rttofproxytoidc

當數(shù)據(jù)大小大于滿帶寬時tcp窗口可傳輸?shù)臄?shù)據(jù)大小情況下，此時上傳耗時為：

n＝log(bdp/initwnd)

rt＝((filesize-2^(n-1)*initwnd)/bandwidth)+(n+1)*rttofclienttoproxy+rttofproxytoidc

由上述公式可以計算出常見帶寬下，不同數(shù)據(jù)大小的上傳耗時。

圖4～圖8為不同數(shù)據(jù)大小在不同帶寬下的上傳耗時的示意圖。圖中的實驗結(jié)果基于代理模塊到客戶機之間的rtt為5ms，代理模塊到到idc的rtt為30ms，客戶機到idc的rtt為30ms得到的。

圖4其為數(shù)據(jù)大小為10kb時不同帶寬下上傳耗時的示意圖。

圖5其為數(shù)據(jù)大小為50kb時不同帶寬下上傳耗時的示意圖。

圖6其為數(shù)據(jù)大小為100k時不同帶寬下上傳耗時的示意圖。

圖7其為數(shù)據(jù)大小為1mb時不同帶寬下上傳耗時的示意圖。

圖8其為數(shù)據(jù)大小為5mb時不同帶寬下上傳耗時的示意圖。

由上述公式和圖4～圖8可以得出以下結(jié)論：

當帶寬小于500kb時候，本實施例提供的基于代理模塊的數(shù)據(jù)上傳方法無加速效果，反而與現(xiàn)有的直接上傳相比存在一定的時延，增加的時延為一個客戶機到代理模塊的往返傳輸時間。

本實施例提供的基于代理模塊的數(shù)據(jù)上傳方法加速效果隨著帶寬增大越明顯。

在常用的帶寬(4mb～100mb)范圍內(nèi)，待傳輸?shù)臄?shù)據(jù)越大，本實施例提供的基于代理模塊的數(shù)據(jù)上傳方法加速效果越不明顯，

而且在實際應用中，加速效果會在用戶不同帶寬以及網(wǎng)絡的不同擁塞情況會下有不同。當網(wǎng)絡中出現(xiàn)丟包情況，由于代理模塊的rtt比較小， 發(fā)送窗口的恢復速度會比較快，所以在網(wǎng)絡不穩(wěn)定的情況下會有優(yōu)勢。

研發(fā)人員使用linuxtc工具模擬了常用帶寬下丟包10％～30％傳輸環(huán)境，得出如下結(jié)論：當超過30％的丟包率時基本無法成功上傳數(shù)據(jù)，在丟包情況下，測試結(jié)果隨機性太大，但本實施例提供的基于代理模塊的數(shù)據(jù)上傳方法比直接上傳有30％到3倍的性能提升。

在實驗測試后，可以得出代理模塊對14kb以下的加速效果不明顯，對14kb～2mb大小內(nèi)加速效果會越來越明顯，當文件超過5m以上，加速效果又會減小。

為了更好地理解本實施例提供的數(shù)據(jù)上傳方法，舉例說明：

在客戶機與idc之間增加一個代理模塊，代理模塊與客戶機之間采用tcp連接，與idc之間保持長連接。

客戶機需要上傳20kb的文件，設置傳輸數(shù)據(jù)為一個rtt內(nèi)傳輸10kb。r0＝30ms，r1＝5ms，r2＝25ms。其中，客戶機到idc的rtt為r0，客戶機到代理模塊的rtt為r1，代理模塊到idc的rtt為r2。

首先根據(jù)r0、r1和r2以及預設條件得到一個目標節(jié)點，將代理設置在該目標節(jié)點上?？蛻魴C通過tcp連接基于流式上傳技術(shù)向代理模塊發(fā)送數(shù)據(jù)，當發(fā)送窗口大小為10時，客戶機需要通過兩個r1將數(shù)據(jù)發(fā)完，而客戶機與代理建立tcp連接還需要1個r1，則客戶機從建立連接到將數(shù)據(jù)到代理上共用3個r1，代理還需要將數(shù)據(jù)發(fā)送到idc，需要消耗一個r2。則總耗時為：3*r1+r2＝40ms。而且在該示例中，代理模塊分別與客戶機和idc之間采用流式上傳技術(shù)，則不需要中間落地存儲，而且不需要壓縮轉(zhuǎn)換處理，相對于通過cdn轉(zhuǎn)發(fā)不僅節(jié)省存儲空間，而且減少耗時。

而通過直接上傳的方式，客戶機需要1個r0時間建立連接，用兩個r0時間發(fā)送數(shù)據(jù)，則總耗時3*r0＝90ms?；诒緦嵤├峁┑姆椒ㄉ蟼鲾?shù)據(jù)，能夠比直接上傳方式節(jié)省一半的時間，提高上傳的時效性。

本實施例提供的數(shù)據(jù)上傳方法，通過在客戶機與互聯(lián)網(wǎng)數(shù)據(jù)中心之間就近部署代理模塊，代理模塊分別與客戶機和互聯(lián)網(wǎng)數(shù)據(jù)中心idc基于流式上傳技術(shù)傳輸數(shù)據(jù)。本實施例中，通過增加代理模塊來縮短用戶 到idc之間的往返傳輸時間rtt，rtt變短后，則相應地提高數(shù)據(jù)的傳輸速度，而且代理模塊基于流式上傳技術(shù)完成數(shù)據(jù)的上傳，代理模塊不再需要對接收到數(shù)據(jù)進行落地存儲和轉(zhuǎn)換，節(jié)省資源和時間，進一步提高上傳的速度。

實施例二

如圖9所示，其為本發(fā)明實施例二的數(shù)據(jù)上傳方法的流程示意圖。該數(shù)據(jù)上傳方法包括以下步驟：

s201、在滿足預設條件的節(jié)點上部署代理模塊。

在客戶機與互聯(lián)網(wǎng)數(shù)據(jù)中心，設置一個滿足預設條件的節(jié)點，在該節(jié)點上部署代理模塊。可選地，為了節(jié)省部署的成本，部署代理模塊的節(jié)點可以復用cdn中的節(jié)點，而且復用cdn的節(jié)點，由于cdn覆蓋范圍較廣，部署了代理模塊的節(jié)點可以同時兼顧到更多客戶機，由于cdn的節(jié)點較多，能夠在大范圍內(nèi)部署代理模塊。其中預設條件可參見上述實施例一中相關(guān)內(nèi)容的記載，此處不再贅述。

在部署完代理模塊后，在部署完代理模塊后，客戶機與代理模塊通過tcp連接建立連接，代理模塊通過長連接與互聯(lián)網(wǎng)數(shù)據(jù)中心idc連接。本實施例中，代理模塊與互聯(lián)網(wǎng)數(shù)據(jù)中心idc之前的長連接個數(shù)是變化的，代理模塊可以根據(jù)帶寬占用情況，動態(tài)地調(diào)整長連接的個數(shù)。當帶寬充足時，設置多個長連接，可以更快地上傳數(shù)據(jù)。當帶寬不足時，則相應地減少長連接的個數(shù)。

s202、代理模塊接收客戶機基于流式上傳技術(shù)上傳的數(shù)據(jù)。

s203、代理模塊對接收到的數(shù)據(jù)進行緩存。

本實施例中，代理模塊可以對接收的數(shù)據(jù)進行緩存，其中，代理模塊將數(shù)據(jù)緩存在內(nèi)存中，并不需要對數(shù)據(jù)進行落地存儲。

s204、代理模塊通過與互聯(lián)網(wǎng)數(shù)據(jù)中心idc之間的長連接將發(fā)送窗口維持在與可利用帶寬匹配的大小，以使緩存后的數(shù)據(jù)通過發(fā)送窗口一次性發(fā)送完成

用戶可以基于客戶機上設置發(fā)送窗口的初始大小，一般情況下，在客戶機與代理模塊建立連接之初，發(fā)送窗口的初始大小為默認設置，該 設置可以由用戶通過相應的應用程序進行設置。但是在tcp連接建立后，客戶機隨著數(shù)據(jù)不斷地發(fā)送成功后，客戶機中的操作系統(tǒng)可以不斷地嘗試將發(fā)送窗口增大，以使發(fā)送窗口的大小調(diào)整到與可利用帶寬匹配的大小。當客戶機與代理模塊之間的發(fā)送窗口調(diào)整到合適大小后，相應的，代理模塊通過與互聯(lián)網(wǎng)數(shù)據(jù)中心idc之間的長連接，將代理模塊與互聯(lián)網(wǎng)數(shù)據(jù)中心idc之間的發(fā)送窗口維持到一個合適的大小，該合適大小可以保證代理模塊將緩存的數(shù)據(jù)能夠一次性通過發(fā)送窗口。本實施例中，由于代理模塊和互聯(lián)網(wǎng)數(shù)據(jù)中心idc之間進行長連接，從而使得代理模塊與網(wǎng)絡數(shù)中心idc之間的發(fā)送窗口可以維持在一個穩(wěn)定的大小，不會隨著代理模塊與客戶機之間的發(fā)送窗口的調(diào)整而不斷地變化。

s205、代理模塊在緩存的數(shù)據(jù)的數(shù)據(jù)量達到閾值后，將緩存的數(shù)據(jù)同時上傳到idc。

本實施例中，為緩存的數(shù)據(jù)的數(shù)據(jù)量預設一個閾值，緩存后的數(shù)據(jù)的數(shù)據(jù)量要在該閾值內(nèi)，當緩存的數(shù)據(jù)量達到閾值后，將緩存的數(shù)據(jù)同時上傳到互聯(lián)網(wǎng)數(shù)據(jù)中心idc中。例如，緩存后的數(shù)據(jù)量小于等于代理模塊與idc之前的帶寬時延乘積(bandwidthdelayproduct，簡稱bdp)。

s206、代理模塊清除緩存的數(shù)據(jù)。

本實施例中，代理模塊將數(shù)據(jù)緩存在內(nèi)存中，當數(shù)據(jù)發(fā)送出去后，則可以對緩存的數(shù)據(jù)進行清除，釋放內(nèi)存空間。代理模塊并不需要將緩存的數(shù)據(jù)進行落地存儲，節(jié)省資源。

s207、代理模塊接收idc返回的上傳完成指示。

s208、代理模塊將上傳完成指示轉(zhuǎn)發(fā)給客戶機。

其中，上傳完成指示是由idc在接收到由代理模塊上傳完所有數(shù)據(jù)后發(fā)送的。

在通過cdn中轉(zhuǎn)的方案中，當客戶機將數(shù)據(jù)上傳到cdn后，就可以接收到上傳完成的指示，但是此時互聯(lián)網(wǎng)數(shù)據(jù)中心idc并未接收到該數(shù)據(jù)。而本實施例中互聯(lián)網(wǎng)數(shù)據(jù)中心在接收完所有數(shù)據(jù)后，將會生成一個上傳完成指示并發(fā)送給代理模塊，代理模塊接收到該上傳完成指示后，將該上傳完成指示返回給客戶機。

本實施例提供的數(shù)據(jù)上傳方法，通過在客戶機與互聯(lián)網(wǎng)數(shù)據(jù)中心之間就近部署代理模塊，代理模塊分別與客戶機和互聯(lián)網(wǎng)數(shù)據(jù)中心idc基于流式上傳技術(shù)傳輸數(shù)據(jù)，本實施例中，通過增加代理模塊來縮短用戶到idc之間的往返傳輸時間rtt，rtt變短后，則相應地提高數(shù)據(jù)的傳輸速度，而且代理模塊基于流式上傳技術(shù)完成數(shù)據(jù)的上傳，代理模塊不再需要對接收到數(shù)據(jù)轉(zhuǎn)換，節(jié)省時間，進一步地提高上傳速度。進一步地，代理模塊在內(nèi)存中對數(shù)據(jù)進行緩存，并同時將緩存的數(shù)據(jù)一次性上傳到互聯(lián)網(wǎng)數(shù)據(jù)中心idc中，不再對數(shù)據(jù)進行落地存儲，節(jié)省資源。

實施例三

如圖10所示，其為本發(fā)明實施例三的數(shù)據(jù)上傳裝置的結(jié)構(gòu)示意圖。該數(shù)據(jù)上傳裝置包括：接收單元11和上傳單元12。

其中，接收單元11，用于接收客戶機基于流式上傳技術(shù)上傳的數(shù)據(jù)。

上傳單元12，用于基于流式上傳技術(shù)將所述數(shù)據(jù)上傳到互聯(lián)網(wǎng)數(shù)據(jù)中心idc。

本實施例中，數(shù)據(jù)上傳裝置部署的位置滿足預設條件，其中所述預設條件為：客戶機基于所述數(shù)據(jù)上傳裝置向所述idc上傳數(shù)據(jù)所耗費的最小時長小于等于所述客戶機直接向所述idc上傳數(shù)據(jù)耗費的最小時長。

接收單元11與所述客戶機之間采用tcp方式進行連接。

上傳單元12與所述idc之間采用長連接方式進行連接。

上傳單元12，還用于動態(tài)調(diào)整與所述idc之間長連接的個數(shù)。

上傳單元12，具體用于對接收到的所述數(shù)據(jù)進行緩存，在緩存的所述數(shù)據(jù)的數(shù)據(jù)量達到閾值后，將緩存的所述數(shù)據(jù)同時上傳到所述idc，清除緩存的所述數(shù)據(jù)。

上傳單元12，還用于通過與所述idc之間的長連接將發(fā)送窗口的大小維持在與可利用帶寬匹配的大小，以使緩存后的所述數(shù)據(jù)通過所述發(fā)送窗口一次性發(fā)送完成。

緩存的所述數(shù)據(jù)的數(shù)據(jù)量小于等于所述數(shù)據(jù)上傳裝置與所述idc之間的帶寬時延乘積bdp。

接收單元11，還用于接收所述idc返回的上傳完成指示；其中，所 述上傳完成指示是由所述idc在接收到由所述數(shù)據(jù)上傳裝置上傳完所有數(shù)據(jù)后發(fā)送的。

上傳單元12，還用于將所述上傳完成指示轉(zhuǎn)發(fā)給所述客戶機。

數(shù)據(jù)上傳裝置部署在節(jié)點上，所述節(jié)點為所述idc中的節(jié)點。

所述客戶機向所述idc上傳的所述數(shù)據(jù)的數(shù)據(jù)量范圍為14kb～5mb。

本實施例中，在客戶機與互聯(lián)網(wǎng)數(shù)據(jù)中心之間就近部署數(shù)據(jù)上傳裝置，該數(shù)據(jù)上傳裝置分別與客戶機和互聯(lián)網(wǎng)數(shù)據(jù)中心idc基于流式上傳技術(shù)傳輸數(shù)據(jù)。本實施例中，通過增加數(shù)據(jù)上傳裝置來縮短用戶到idc之間的往返傳輸時間rtt，rtt變短后，則相應地提高數(shù)據(jù)的傳輸速度，而且數(shù)據(jù)上傳裝置基于流式上傳技術(shù)完成數(shù)據(jù)的上傳，不再需要對接收到數(shù)據(jù)轉(zhuǎn)換，節(jié)省時間。進一步地，該數(shù)據(jù)上傳裝置在內(nèi)存中對數(shù)據(jù)進行緩存，并同時將緩存的數(shù)據(jù)一次性上傳到互聯(lián)網(wǎng)數(shù)據(jù)中心idc中，不再對數(shù)據(jù)進行落地存儲，不僅節(jié)省資源，而且提高上傳的速度。

實施例四

如圖11所示，其為本發(fā)明實施例四的數(shù)據(jù)上傳系統(tǒng)的結(jié)構(gòu)示意圖。該數(shù)據(jù)上傳系統(tǒng)包括：客戶機1和代理模塊2和互聯(lián)網(wǎng)數(shù)據(jù)中心idc3。

其中，客戶機1，用于向通過代理模塊2向互聯(lián)網(wǎng)數(shù)據(jù)中心idc3上傳數(shù)據(jù)。

代理模塊2，用于接收客戶機1基于流式上傳技術(shù)上傳的所述數(shù)據(jù)，以及基于流式上傳技術(shù)將所述數(shù)據(jù)上傳到互聯(lián)網(wǎng)數(shù)據(jù)中心idc3上。

互聯(lián)網(wǎng)數(shù)據(jù)中心idc3，用于接收代理模塊2轉(zhuǎn)發(fā)的客戶機1上傳的所述數(shù)據(jù)。

其中，代理模塊2部署的位置滿足預設條件，其中所述預設條件為：客戶機1基于代理模塊2向互聯(lián)網(wǎng)數(shù)據(jù)中心idc3上傳數(shù)據(jù)所耗費的最小時長小于等于客戶機1直接向互聯(lián)網(wǎng)數(shù)據(jù)中心idc3上傳數(shù)據(jù)耗費的最小時長。

本實施例中，代理模塊2為上述實施例三中的數(shù)據(jù)上傳裝置，關(guān)于代理模塊2的結(jié)構(gòu)，可參見上述實施例中數(shù)據(jù)上傳裝置的結(jié)構(gòu)。

代理模塊2與客戶機1之間采用tcp方式進行連接，與互聯(lián)網(wǎng)數(shù)據(jù) 中心idc3之間采用長連接方式進行連接。

代理模塊2，還用于動態(tài)調(diào)整與互聯(lián)網(wǎng)數(shù)據(jù)中心idc3之間長連接的個數(shù)。

代理模塊2，具體用于對接收到的所述數(shù)據(jù)進行緩存，在緩存的所述數(shù)據(jù)的數(shù)據(jù)量達到閾值后，將緩存的所述數(shù)據(jù)同時上傳到互聯(lián)網(wǎng)數(shù)據(jù)中心idc3，以及清除緩存的所述數(shù)據(jù)。

代理模塊2，具體用于通過與互聯(lián)網(wǎng)數(shù)據(jù)中心idc3之間的長連接將發(fā)送窗口維持在與可利用帶寬匹配的大小，以使緩存后的所述數(shù)據(jù)通過所述發(fā)送窗口一次性發(fā)送完成。

其中，緩存的所述數(shù)據(jù)的數(shù)據(jù)量小于等于代理模塊2與互聯(lián)網(wǎng)數(shù)據(jù)中心idc3之間的帶寬時延乘積bdp。

互聯(lián)網(wǎng)數(shù)據(jù)中心idc3，還用于向代理模塊2返回上傳完成指示；其中，上傳完成指示是由互聯(lián)網(wǎng)數(shù)據(jù)中心idc3在接收到由代理模塊2上傳完所有數(shù)據(jù)后發(fā)送的。

代理模塊2，還用于接收互聯(lián)網(wǎng)數(shù)據(jù)中心idc3返回的所述上傳完成指示，以及將所述上傳完成指示轉(zhuǎn)發(fā)給客戶機1。

客戶機1，還用于接收所述上傳完成指示。

代理模塊2部署在節(jié)點上，所述節(jié)點為互聯(lián)網(wǎng)數(shù)據(jù)中心idc3中的節(jié)點。

客戶機1向互聯(lián)網(wǎng)數(shù)據(jù)中心idc3上傳的所述數(shù)據(jù)的數(shù)據(jù)量范圍為14kb～5mb。

關(guān)于代理模塊2與客戶機1和互聯(lián)網(wǎng)數(shù)據(jù)中心3之間的交互過程，可參見上述實施例中相關(guān)內(nèi)容的記載，此處不再贅述。

本實施例中，在客戶機與互聯(lián)網(wǎng)數(shù)據(jù)中心之間就近部署代理模塊，該代理模塊分別與客戶機和互聯(lián)網(wǎng)數(shù)據(jù)中心idc基于流式上傳技術(shù)傳輸數(shù)據(jù)，基于流式上傳技術(shù)完成數(shù)據(jù)的上傳。本實施例中，通過增加代理模塊來縮短用戶到idc之間的往返傳輸時間rtt，rtt變短后，則相應地提高數(shù)據(jù)的傳輸速度，而且代理模塊不再需要對接收到數(shù)據(jù)轉(zhuǎn)換，節(jié)省時間。進一步地，該代理模塊在內(nèi)存中對數(shù)據(jù)進行緩存，并同時將緩 存的數(shù)據(jù)一次性上傳到互聯(lián)網(wǎng)數(shù)據(jù)中心idc中，不再對數(shù)據(jù)進行落地存儲，節(jié)省資源，而且提高上傳的速度。

本領域普通技術(shù)人員可以理解：實現(xiàn)上述各方法實施例的全部或部分步驟可以通過程序指令相關(guān)的硬件來完成。前述的程序可以存儲于一計算機可讀取存儲介質(zhì)中。該程序在執(zhí)行時，執(zhí)行包括上述各方法實施例的步驟；而前述的存儲介質(zhì)包括：rom、ram、磁碟或者光盤等各種可以存儲程序代碼的介質(zhì)。

最后應說明的是：以上各實施例僅用以說明本發(fā)明的技術(shù)方案，而非對其限制；盡管參照前述各實施例對本發(fā)明進行了詳細的說明，本領域的普通技術(shù)人員應當理解：其依然可以對前述各實施例所記載的技術(shù)方案進行修改，或者對其中部分或者全部技術(shù)特征進行等同替換；而這些修改或者替換，并不使相應技術(shù)方案的本質(zhì)脫離本發(fā)明各實施例技術(shù)方案的范圍。