一種基于分布式代理服務器的自適應上傳加速方法
【技術(shù)領(lǐng)域】
[0001] 本發(fā)明涉及一種基于分布式代理服務器的自適應上傳加速方法，屬于網(wǎng)絡技術(shù)領(lǐng) 域。
【背景技術(shù)】
[0002] 隨著微信、微博、視頻共享等網(wǎng)絡服務的普及，上行流量近來增長趨勢明顯。像下 行加速技術(shù)使用CDN方法類似，利用緩存技術(shù)對上行流量進行加速也是目前常用的一種加 速手段。該方法的本質(zhì)是在距離用戶最近的網(wǎng)路設備上部署緩存服務器，將用戶上傳的文 件先緩存到本地緩存服務器上，最后由本地緩存服務器使用有線網(wǎng)絡將用戶數(shù)據(jù)上傳到用 戶指定的目標服務器上。由于緩存服務器距離用戶近，傳輸路徑短，因此丟包率低、傳輸速 率大，降低了用戶在上傳上所花費的時間，尤其是移動無線用戶，加速效果明顯。
[0003] 針對傳輸信道好、待上傳文件小的情況，有人提出了選擇性上傳技術(shù)，即在啟動傳 輸之前根據(jù)待上傳文件的大小、信道情況等因素對本次上傳進行信道評估，根據(jù)評估結(jié)果 決定是不是使用緩存。與普通加速方式相比，該方法降低了不必要的緩存操作，提高了緩存 使用效率，但同時增加了一個信道評估處理過程，會給系統(tǒng)帶來一定負荷，同時還會增加一 個信道檢測時間，不利于對及時性要求較高的上傳業(yè)務。尤其是針對一段時間內(nèi)保持相對 穩(wěn)定的有線通信鏈路，這種頻繁的檢測是不必要的。
[0004] 另外，上傳服務器部署在用戶附近，雖然有利于減少用戶在上傳上所花費的時間， 但是從用戶啟動發(fā)送到目標服務器成功接收到數(shù)據(jù)，整個上傳完成需要的時間不一定減 少，甚至有時候會因為額外操作而增加。這是因為緩存部署在用戶附近，與目標服務器的距 離不一定得到減少。

【發(fā)明內(nèi)容】

[0005] 針對現(xiàn)有技術(shù)中存在的技術(shù)問題，本發(fā)明的目的在于提供一種基于分布式代理服 務器的自適應上傳加速方法，其特征是包括以下步驟：
[0006] 用戶端上傳中間件向上傳加速代理服務器（以下簡稱代理服務器）提交上傳請 求，該上傳請求包括文件大小、目的IP地址等信息。
[0007] 代理服務器檢查自身當前可用于接收用戶數(shù)據(jù)的緩存服務器的數(shù)量，并將上述緩 存服務器的IP地址下發(fā)給用戶端上傳中間件（以下簡稱用戶端中間件）。
[0008] 用戶端中間件接收代理服務器下發(fā)的緩存服務器的IP地址，并根據(jù)緩存服務器 IP地址的數(shù)量將待上傳文件拆分為同樣多的文件分片，采用多路傳輸技術(shù)將上述分片分別 上傳到緩存服務器上，如圖1所示。
[0009] 緩存服務器將自身收到的文件分片發(fā)送給代理服務器，代理服務器將收到的文件 分片重新組裝成文件。
[0010] 代理服務器根據(jù)待上傳文件的目的IP地址，在本地加速需求度列表中查找對應 的加速需求度e，如圖2所示，如果沒有找到，以廣播的形式向其它代理服務器查詢對應的 加速需求度。
[0011] 如果找到對應的代理服務器和加速需求度，對應的代理服務器將加速需求度的淘 汰值e_dei初始化，并以單播的形式告知查詢者，即廣播查詢的代理服務器。
[0012] 如果沒有收到響應，則負責接收用戶文件的代理服務器廣播通知發(fā)起加速需求度 計算指令，所有代理服務器向上傳請求中的目的IP地址接收端上傳中間件（以下簡稱接收 端中間件）發(fā)送探測報文。
[0013] 接收端中間件按照丟包率最低且最先發(fā)來探測報文的原則選擇最優(yōu)代理服務器， 并向該代理服務器發(fā)送回復。
[0014] 最優(yōu)代理服務器計算加速需求度，初始化后插入本地加速度需求列表，然后以單 播的形式將該加速需求度告知查詢者（即收到請求的代理服務器），該代理服務器保存加 速需求度。
[0015] 負責接收用戶文件的代理服務器將待上傳文件發(fā)送到加速需求度指定的最優(yōu)代 理服務器上。
[0016] 最優(yōu)代理服務器接收待上傳文件，并根據(jù)用戶指定的目的地IP地址，將文件發(fā)送 給接收者，如圖3所示。
[0017] 與現(xiàn)有技術(shù)相比，本發(fā)明的優(yōu)點：
[0018] 由于采用了以上的方案，可實現(xiàn)以下優(yōu)點：1)采用分布式代理服務器和多路傳輸 技術(shù)，有利于提高用戶上傳速率，提升用戶上傳體驗。2)采用最優(yōu)傳輸路徑技術(shù)，減少網(wǎng)絡 延遲，提高完成整個上傳過程所需要的時間，有利于及時性要求較高的上傳業(yè)務。3)加速需 求度0唯一對應一條網(wǎng)絡傳輸鏈路，其它用戶向同一目的地上傳文件時，可以立即使用該 加速需求度，避免了重復探測網(wǎng)絡信道，減輕系統(tǒng)負荷。4)對0設置生命值，在生命值到時 以后，系統(tǒng)更新該上傳加速需求度，提高加速需求度的精確性。5)對0設置淘汰值，對于長 期不使用的0，系統(tǒng)會將其刪除，減輕系統(tǒng)冗余度。6)以代理服務器和緩存服務器的結(jié)構(gòu) 方式，有利于減低系統(tǒng)部署成本。7)以加速中間件的形式，用戶和網(wǎng)絡服務提供商只需要將 相應的中間件嵌入到自己的程序當中，無需更改現(xiàn)有系統(tǒng)和設備，最大程度的與現(xiàn)有系統(tǒng) 兼容。8)組播、單播相結(jié)合的加速需求度管理法，有利于加速需求度的計算、學習、更新、刪 除等操作，增強系統(tǒng)耦合性與健壯性。
【附圖說明】
[0019] 圖1為基于分布式代理服務器的自適應上傳加速系統(tǒng)；
[0020] 圖2為上傳加速需求度結(jié)構(gòu)；
[0021] 圖3為上傳加速處理時序圖；
[0022] 圖4為自適應上傳加速系統(tǒng)架構(gòu)；
[0023] 圖5為加速需求度計算流程圖；
[0024] 圖6為加速需求度學習流程圖；
[0025] 圖7為分布式自適應上傳加速數(shù)據(jù)處理流程圖。
【具體實施方式】
[0026] 下面結(jié)合附圖對本發(fā)明進行進一步詳細描述。
[0027] 本實施例系統(tǒng)架構(gòu)如圖4所示，包含用戶端中間件、代理服務器、緩存服務器和接 收端中間件。其中，用戶端中間件分為：
[0028] 1)分片處理模塊：根據(jù)代理服務器的要求，將待上傳的文件才分為多個文件分 片。
[0029] 2)多路傳輸模塊：發(fā)起多路鏈接，并將文件分片以多路傳輸?shù)姆椒òl(fā)送到指定的 緩存服務器上。
[0030] 代理服務器和緩存服務器是自適應上傳加速系統(tǒng)的核心設備，其中，代理服務器 分為：
[0031] l)Web服務器模塊：用于處理網(wǎng)絡請求和網(wǎng)絡數(shù)據(jù)收發(fā)。
[0032] 2)加速需求度模塊：系統(tǒng)核心模塊之一，管理和計算上傳加速需求度，包括計算 加速需求度、學習加速需求度、更新加速需求度、刪除加速需求度。
[0033] 3)探測報文接收模塊：負責接收來自接收端上傳中間件發(fā)送的探測回復。
[0034] 4)探測報文發(fā)送模塊：負責探測報文的組裝，并將探測報文發(fā)送給指定的接收 端。
[0035] 5)數(shù)據(jù)處理模塊：系統(tǒng)核心模塊之一，用于處理數(shù)據(jù)業(yè)務，包括處理用戶的請求、 用戶信息管理、啟動發(fā)送、重新組裝分片等。
[0036] 緩存服務器提供基于網(wǎng)絡連接的數(shù)據(jù)緩存服務，主要是接收用戶端上傳中間件的 連接請求，并將用戶發(fā)送的文件分片緩存到本地。同時，根據(jù)代理服務器的要求，將自身緩 存的分片發(fā)送給代理服務器上。
[0037] 接收端中間件負責監(jiān)聽代理服務器發(fā)送的探測報文，根據(jù)丟包率、網(wǎng)絡延遲選擇 最優(yōu)服務器，分為三個部分：
[0038] 1)探測報文接收模塊：持續(xù)監(jiān)聽代理服務器發(fā)送的探測報文，并將接收到的報文 轉(zhuǎn)發(fā)給處理模塊。
[0039] 2)探測報文處理模塊：根據(jù)接收到的檢測報文，按照丟包率最低、網(wǎng)絡延遲最小 的標準選出最優(yōu)服務器。
[0040] 3)探測報文發(fā)送模塊：根據(jù)處理模塊的要求，組裝響應報文，并將該報文發(fā)送給 最優(yōu)代理服務器。
[0041] A、加速需求度|3計算
[0042] 代理服務器組裝20個10字節(jié)長的IP探測報文，MAC數(shù)據(jù)域全部置零，IP探測報 文的序列號從0-19依次遞增。IP報文的源地址是代理服務器的IP地址，目的地址是接收 端中間件的IP地址。
[0043] 接收端中間件收到探測報文以后，統(tǒng)計丟包率，選出丟包率最低的代理服務器；對 于丟包率一樣的，按照接收完成時間排序，最先接收完成的為最優(yōu)代理服務器，向最優(yōu)代理 服務器回復檢測響應。探測響應IP報文長度為10個字節(jié)，MC數(shù)據(jù)域全部置零，源地址是 接收端中間件的IP地址，目的地址是最優(yōu)代理服務器的IP地址。
[0044] 最優(yōu)代理服務器接收到探測響應以后，按照下列公式計算加速需求度：
[0046]其中：
[0047] L :待傳輸報文的MAC幀長度
[0048] Gwl :傳輸鏈路吞吐量
[0049] H :待傳輸報文的MAC層和IP層開銷
[0050] R。:傳輸鏈路的誤比特率
[0051] 已:傳輸鏈路的丟包率，即，重傳發(fā)生的概率
[0052]