互聯(lián)網(wǎng)大文件的快速傳輸方法

暫無

互聯(lián)網(wǎng)大文件的快速傳輸方法\n技術(shù)領(lǐng)域\n[0001] 本發(fā)明涉及網(wǎng)絡(luò)通信技術(shù)領(lǐng)域，尤其涉及一種互聯(lián)網(wǎng)大文件的快速傳輸方法。\n背景技術(shù)\n[0002] 隨著互聯(lián)網(wǎng)的迅猛發(fā)展，當前網(wǎng)絡(luò)應(yīng)用中多媒體數(shù)據(jù)的傳輸共享需求越來越大，各種文件數(shù)據(jù)必須能夠快速實現(xiàn)網(wǎng)絡(luò)共享，而多媒體數(shù)據(jù)通常數(shù)據(jù)量大，尤其是隨著用戶對視頻清晰度要求的不斷提高，視頻文件數(shù)據(jù)量急劇增加，使得有效的實現(xiàn)大文件傳輸服務(wù)的需求更加迫切。\n[0003] 傳統(tǒng)的互聯(lián)網(wǎng)文件傳輸服務(wù)中的數(shù)據(jù)傳輸在應(yīng)用層有多種形式，如FTP，HTTP等，但是在傳輸層一般使用TCP協(xié)議，而TCP協(xié)議為一種可靠連接，為了保證零丟包付出的代價是傳輸效率的下降；由于網(wǎng)絡(luò)擁塞和流量控制沒有進行優(yōu)化，導(dǎo)致丟包后加重了重傳的負荷，不僅加劇了網(wǎng)絡(luò)擁塞也降低了傳輸速度；基于TCP的數(shù)據(jù)傳輸，會給終端帶來相當大的系統(tǒng)開銷。\n[0004] 盡管目前存在一些技術(shù)對傳統(tǒng)的FTP服務(wù)進行改善，有些集中在應(yīng)用層方面，例如友好的用戶界面、增加書簽、命令歷史記錄和目錄下載等；有些改進是在傳輸性能方面，例如Web100項目主要對TCP的性能進行優(yōu)化，在傳輸端和接收端都增加了性能診斷功能，能在網(wǎng)絡(luò)傳輸?shù)娜魏螘r刻做出調(diào)整；而Grid FTP項目的主要目的是為高帶寬的廣域網(wǎng)上實現(xiàn)高效、安全和可靠的數(shù)據(jù)傳輸協(xié)議，是現(xiàn)有的FTP標準的一個子集，加入了對TCP緩沖區(qū)和TCP窗等細節(jié)上的改進。\n[0005] 然而對于互聯(lián)網(wǎng)中快速增加的大量的多媒體數(shù)據(jù)，如何在帶寬一定的情況下，合理的、有效的、最大限度的利用有限帶寬提高大文件傳輸共享速度是當前亟待解決的問題之一。\n發(fā)明內(nèi)容\n[0006] 本發(fā)明的目的是提供一種互聯(lián)網(wǎng)大文件的快速傳輸方法，在現(xiàn)有帶寬有限的互聯(lián)網(wǎng)絡(luò)環(huán)境下，充分利用網(wǎng)絡(luò)、服務(wù)器與客戶端的資源，快速傳輸共享大文件數(shù)據(jù)。\n[0007] 為達到上述目的，本發(fā)明采用如下的技術(shù)方案：\n[0008] 互聯(lián)網(wǎng)大文件的快速傳輸方法，包括以下步驟：\n[0009] ①服務(wù)器開始提供服務(wù)后，客戶端使用TCP協(xié)議與服務(wù)器進行網(wǎng)絡(luò)連接，同時客戶端將用戶設(shè)置的初始參數(shù)通知服務(wù)器；\n[0010] ②計算客戶端與服務(wù)器之間的往返時延RTT，探測網(wǎng)絡(luò)狀況，服務(wù)器根據(jù)往返時延RTT調(diào)整數(shù)據(jù)塊大小和數(shù)據(jù)塊延時，并通知客戶端；\n[0011] ③服務(wù)器根據(jù)網(wǎng)絡(luò)狀況和預(yù)設(shè)參數(shù)確定文件傳輸相關(guān)初始設(shè)置后，建立UDP連接，隨機分配UDP端口，并通知客戶端，客戶端隨即建立UDP連接，并與服務(wù)器建立數(shù)據(jù)傳輸通道；\n[0012] ④數(shù)據(jù)傳輸過程中，采用自適應(yīng)的網(wǎng)絡(luò)流量和擁塞控制機制，保證數(shù)據(jù)塊大小自適應(yīng)和數(shù)據(jù)塊延時自適應(yīng)，實現(xiàn)傳輸過程中的吞吐量最大化；\n[0013] ⑤數(shù)據(jù)傳輸過程中，采用丟包重傳機制對傳輸過程中丟失的數(shù)據(jù)包和CRC錯誤的數(shù)據(jù)包進行重傳，直到客戶端接收了待傳輸文件數(shù)據(jù)的全部數(shù)據(jù)包為止。\n[0014] 步驟①中所述初始參數(shù)包括Alpha、分析窗大小、初始數(shù)據(jù)塊大小、是否數(shù)據(jù)塊自適應(yīng)調(diào)整、數(shù)據(jù)包大小和是否指定接收端口。\n[0015] 步驟④中服務(wù)器在數(shù)據(jù)傳輸初期，為了避免網(wǎng)絡(luò)阻塞，采取TCP慢啟動方式，并設(shè)置慢啟動門限。\n[0016] 步驟④中所述數(shù)據(jù)塊大小自適應(yīng)，采用指數(shù)遞增/遞減方式或者線性遞增/遞減方式，所述數(shù)據(jù)塊延時自適應(yīng)，依賴數(shù)據(jù)接收成功率，所述數(shù)據(jù)塊大小自適應(yīng)和所述數(shù)據(jù)塊延時自適應(yīng)采用組合應(yīng)用方式。\n[0017] 步驟⑤中所述丟包重傳機制是在所有文件數(shù)據(jù)發(fā)送一遍之后再對丟失的數(shù)據(jù)進行丟包重傳。\n[0018] 本發(fā)明具有以下優(yōu)點和積極效果：\n[0019] 1)靈活運用TCP協(xié)議的可靠性與UDP協(xié)議的快速性；\n[0020] 2)能夠大幅度提高有限帶寬環(huán)境下大文件的傳輸速度。\n附圖說明\n[0021] 圖1是本發(fā)明提供的互聯(lián)網(wǎng)大文件的快速傳輸方法的傳輸過程示意圖。\n[0022] 圖2是本發(fā)明數(shù)據(jù)分析窗示意圖。\n[0023] 圖3是本發(fā)明數(shù)據(jù)塊大小自適應(yīng)調(diào)整方法流程圖。\n[0024] 圖4是本發(fā)明丟包重傳示意圖。\n[0025] 圖5是本發(fā)明重傳數(shù)據(jù)包重新組裝示意圖。\n[0026] 其中，\n[0027] 11-服務(wù)器端文件系統(tǒng)、12-服務(wù)器、13-客戶端、14-用戶、15-客戶端文件系統(tǒng)、\n16-TCP連接、17-UDP連接；21-數(shù)據(jù)塊尺寸、22-數(shù)據(jù)包、23-數(shù)據(jù)塊延時；41-丟失數(shù)據(jù)包序號。\n具體實施方式\n[0028] 下面以具體實施例結(jié)合附圖對本發(fā)明作進一步說明：\n[0029] 本發(fā)明提供的互聯(lián)網(wǎng)大文件的快速傳輸方法具體采用如下的技術(shù)方案，下面結(jié)合圖1首先對本發(fā)明的工作機制進行詳細描述。\n[0030] 服務(wù)器端文件系統(tǒng)11為服務(wù)器12端的文件系統(tǒng)，服務(wù)器端文件系統(tǒng)15為客戶端\n13端的文件系統(tǒng)，客戶端13提供了用戶接口以方便和用戶交互，服務(wù)器12和客戶端13通過發(fā)出特定的控制命令建立TCP連接16，進一步在數(shù)據(jù)傳輸過程中建立UDP連接。\n[0031] 本發(fā)明與傳統(tǒng)的FTP工作機制上不同，即FTP在控制命令和數(shù)據(jù)傳輸兩個端口上都使用TCP協(xié)議進行傳輸，而本方法中，控制命令使用TCP協(xié)議傳輸，大量的文件數(shù)據(jù)使用UDP協(xié)議傳輸，從而大幅度提高了傳輸速度，減少傳統(tǒng)方法中因使用TCP協(xié)議傳輸大量文件數(shù)據(jù)而產(chǎn)生的龐大的網(wǎng)絡(luò)和系統(tǒng)資源開銷。\n[0032] 本發(fā)明提供的互聯(lián)網(wǎng)大文件的快速傳輸方法可以適用于Internet/LAN/WAN/WLAN等多種網(wǎng)絡(luò)；具體實施時，只需網(wǎng)絡(luò)遵循TCP/IP協(xié)議，可以使用TCP和UDP發(fā)送和接收數(shù)據(jù)，無需擔(dān)心異構(gòu)網(wǎng)絡(luò)所造成的障礙。\n[0033] 本發(fā)明提供的互聯(lián)網(wǎng)大文件的快速傳輸方法，具體采用如下步驟：\n[0034] ①服務(wù)器開始提供服務(wù)后，客戶端使用TCP協(xié)議與服務(wù)器進行網(wǎng)絡(luò)連接，同時客戶端將用戶設(shè)置的初始參數(shù)通知服務(wù)器；\n[0035] 客戶端向服務(wù)器請求共享目錄路徑和該目錄信息，其中包括所有文件名和文件大小。服務(wù)器收到請求后處理請求，并將相應(yīng)信息發(fā)送給客戶端；\n[0036] 客戶端與服務(wù)器的連接采用TCP協(xié)議，在傳輸文件數(shù)據(jù)前，客戶端將用戶設(shè)置的初始參數(shù)通知服務(wù)器，這些初始參數(shù)包括Alpha、分析窗大小、初始數(shù)據(jù)塊大小、是否數(shù)據(jù)塊自適應(yīng)調(diào)整、數(shù)據(jù)包大小和是否指定接收端口等。\n[0037] 下面對上述涉及的一些概念進行簡要介紹：所謂Alpha值為用戶預(yù)設(shè)數(shù)據(jù)接收率；所謂分析窗(analysis window)是指客戶端接收的特定長度的一段數(shù)據(jù)，分析這些數(shù)據(jù)可以得出表征當前傳輸情況的各種參數(shù)值，如數(shù)據(jù)包接收率、數(shù)據(jù)塊大小、數(shù)據(jù)塊延時和數(shù)據(jù)包大小等；所謂數(shù)據(jù)塊大小(block size)是指一次發(fā)送的數(shù)據(jù)包(packet)數(shù)量；所謂包大小(packet size)是指每次發(fā)送的字節(jié)數(shù)，不超過MTU的大小，一旦確定后，傳輸過程中不再變化。\n[0038] 作為本發(fā)明的一個實施例，可以作如下的取值：Alpha值可設(shè)為0.96、分析窗可設(shè)為200、初始數(shù)據(jù)塊大小可設(shè)為8、包大小可設(shè)為1472、可指定接收端口為4096，數(shù)據(jù)塊大小和數(shù)據(jù)塊延時在傳輸過程中自動調(diào)整以適應(yīng)網(wǎng)絡(luò)狀況變化。\n[0039] ②計算客戶端與服務(wù)器之間的往返時延RTT，探測網(wǎng)絡(luò)狀況，服務(wù)器根據(jù)往返時延RTT調(diào)整數(shù)據(jù)塊大小和數(shù)據(jù)塊延時，并通知客戶端；\n[0040] 所謂的往返時延RTT是指客戶端發(fā)送計算RTT命令的同時開始計時，直到收到服務(wù)器立即產(chǎn)生對該命令的響應(yīng)。因此，根據(jù)RTT即可了解服務(wù)器與客戶端之間的大致網(wǎng)絡(luò)狀況。\n[0041] ③服務(wù)器根據(jù)網(wǎng)絡(luò)狀況和預(yù)設(shè)參數(shù)確定文件傳輸相關(guān)初始設(shè)置后，建立UDP連接，隨機分配UDP端口，并通知客戶端，客戶端隨即建立UDP連接，并與服務(wù)器建立數(shù)據(jù)傳輸通道；\n[0042] 服務(wù)器與客戶端使用UDP協(xié)議進行數(shù)據(jù)傳輸，充分發(fā)揮UDP的快速傳輸優(yōu)勢，傳輸過程中若存在數(shù)據(jù)包丟失的情況，客戶端將丟失數(shù)據(jù)包的編號發(fā)給服務(wù)器，但服務(wù)器并不立即對其進行重傳。\n[0043] ④數(shù)據(jù)傳輸過程中，采用自適應(yīng)的網(wǎng)絡(luò)流量和擁塞控制機制，保證數(shù)據(jù)塊大小自適應(yīng)和數(shù)據(jù)塊延時自適應(yīng)，實現(xiàn)傳輸過程中的吞吐量最大化；\n[0044] 服務(wù)器在數(shù)據(jù)傳輸初期，為了避免網(wǎng)絡(luò)阻塞，采取了TCP類似的慢啟動方式，并設(shè)置了慢啟動門限。由于客戶端預(yù)設(shè)了分析窗大小，在分析窗內(nèi)可以得出數(shù)據(jù)塊大小、數(shù)據(jù)塊延時的時間長短和數(shù)據(jù)包接收率，并將這些分析得出的參數(shù)反饋給服務(wù)器，服務(wù)器根據(jù)擁塞控制與流量控制機制對發(fā)送速度和發(fā)送間隔進行相應(yīng)的調(diào)整，保證得到最大的吞吐量。\n[0045] 數(shù)據(jù)塊大小自適應(yīng)策略，可以采用指數(shù)遞增/遞減方式或者線性遞增/遞減方式，數(shù)據(jù)塊延時自適應(yīng)，依賴數(shù)據(jù)接收成功率；數(shù)據(jù)塊大小自適應(yīng)和所述數(shù)據(jù)塊延時自適應(yīng)這兩種策略采用組合應(yīng)用方式。\n[0046] 圖2所示為數(shù)據(jù)分析窗示意圖，當分析窗為200時，客戶端每收到200個數(shù)據(jù)包后，就對這一段數(shù)據(jù)進行分析，在分析窗內(nèi)可以得出數(shù)據(jù)塊尺寸21大小、數(shù)據(jù)塊延時的時間23長短和數(shù)據(jù)包22接收率，并將這些分析得出的參數(shù)反饋給服務(wù)器，服務(wù)器根據(jù)本發(fā)明的擁塞控制與流量控制方法對發(fā)送速度和發(fā)送間隔進行相應(yīng)的調(diào)整，保證得到最大的吞吐量。\n[0047] 圖3所示為數(shù)據(jù)塊大小自適應(yīng)調(diào)整方法流程圖，其中oldRate為上一次數(shù)據(jù)包接收率；newRate為當前數(shù)據(jù)包接收率；ssthresh為慢啟動門限，本發(fā)明的一個實施例可取慢啟動門限為2048。數(shù)據(jù)塊大小自適應(yīng)調(diào)整方法描述如下：\n[0048] 如果數(shù)據(jù)包接受率(newRate)大于用戶預(yù)設(shè)數(shù)據(jù)接收率Alpha，且數(shù)據(jù)塊大小(blocksize)在慢啟動門限(ssthresh)之下，而且當前數(shù)據(jù)包接受率(newRate)大于上一次數(shù)據(jù)包接受率(oldRate)，則數(shù)據(jù)塊大小依照式1指數(shù)增加(increase exponentially)。\n[0049] blocksizei＝φi×blocksize0，i＝1，2，... (式1)\n[0050] 其中，φ＝2。\n[0051] 如果數(shù)據(jù)塊大小低于慢啟動門限，但是當前數(shù)據(jù)包接受率降至上一次數(shù)據(jù)包接受率之下，則數(shù)據(jù)塊大小依照式2線性減少(decrease linearly)。\n[0052] blocksizei＝blocksize0-λi，i＝1，2，... (式2)\n[0053] 其中，λ＝1。\n[0054] 如果數(shù)據(jù)塊大小高于慢啟動門限，同時當前數(shù)據(jù)包接受率高于上一次數(shù)據(jù)包接受率，則數(shù)據(jù)塊大小依照式3線性增加(increase linearly)。\n[0055] blocksizei＝blocksize0+λi，i＝1，2，... (式3)\n[0056] 其中，λ＝1。\n[0057] 反之當數(shù)據(jù)塊大小高于慢啟動門限但當前數(shù)據(jù)包接受率低于上一次數(shù)據(jù)包接受率，則數(shù)據(jù)塊大小依照式2線性減少；\n[0058] 其他情況下，數(shù)據(jù)塊大小依照式4指數(shù)減少(decrease exponentially)。\n[0059] blocksizei＝φ-1×blocksize0，i＝1，2，... (式4)\n[0060] 其中φ＝2。\n[0061] 數(shù)據(jù)塊延時自適應(yīng)調(diào)整方法如式5、式6所示：\n[0062] (式5)\n[0063] (式6)\n[0064] 例如，由式5得，發(fā)送110個數(shù)據(jù)包，接收到100個數(shù)據(jù)包，下一次數(shù)據(jù)塊延時Delayi+1為上一次延時Delayi的1.1×α倍，其中α通過公式6進行不斷的平滑調(diào)整，β為0～1之間的常數(shù)，例如，設(shè)β為0.7時，α將會減小為上一次的0.94倍。\n[0065] 在某些情況下，數(shù)據(jù)塊大小自適應(yīng)模式和數(shù)據(jù)塊延時自適應(yīng)模式可相互切換。例如，如果當前是數(shù)據(jù)塊大小自適應(yīng)模式，而且數(shù)據(jù)塊已經(jīng)小到無法進一步減少，數(shù)據(jù)塊大小自適應(yīng)模式將自動切換為數(shù)據(jù)塊延時自適應(yīng)模式。\n[0066] ⑤數(shù)據(jù)傳輸過程中，采用丟包重傳機制對傳輸過程中丟失的數(shù)據(jù)包和CRC錯誤的數(shù)據(jù)包進行重傳，直到客戶端接收了待傳輸文件數(shù)據(jù)的全部數(shù)據(jù)包為止；\n[0067] 丟包重傳機制是將待傳輸?shù)奈募?shù)據(jù)按照UDP協(xié)議分割成數(shù)據(jù)包大小的包，每個包都依次編號，第一次將這些包依次發(fā)送一遍，客戶端在接收過程中，把傳輸過程中丟失的數(shù)據(jù)包和CRC錯誤的數(shù)據(jù)包的編號記錄下來，要求服務(wù)器將這些丟失的包重新發(fā)送。如此循環(huán)，直到客戶端接收了待傳輸文件數(shù)據(jù)的全部數(shù)據(jù)包，\n[0068] 圖4所示為丟包重傳示意圖，當客戶端發(fā)現(xiàn)丟包時，不需要立即要求服務(wù)器重新發(fā)送該數(shù)據(jù)包，而是將丟失數(shù)據(jù)包的序號41記錄下來，當服務(wù)器將所有數(shù)據(jù)包依次發(fā)送一遍后，客戶端將丟失數(shù)據(jù)包的序號41通知服務(wù)器要求重發(fā)，如此循環(huán)，如圖5重傳數(shù)據(jù)包重新組裝示意圖所示，直到客戶端接收完所有數(shù)據(jù)包后，再將各數(shù)據(jù)重裝到文件相應(yīng)的位置。