專利名稱：一種大數(shù)據(jù)量文件的網(wǎng)絡下載方法
技術(shù)領(lǐng)域：
本發(fā)明屬于計算機網(wǎng)絡技術(shù)領(lǐng)域，具體地說，本發(fā)明涉及一種大數(shù)據(jù)量文件的 高效網(wǎng)絡下載方法。
背景技術(shù)：
隨著計算機技術(shù)的發(fā)展，數(shù)據(jù)文件的數(shù)據(jù)量不斷增大，尤其是高清媒體的曰益 普及，使得人們經(jīng)常需要下載大數(shù)據(jù)量文件。而如何在一定網(wǎng)絡帶寬環(huán)境下實現(xiàn)大 數(shù)據(jù)量文件(如高清媒體文件，該類文件平均容量達到4G以上)高效、完整的下載 并在本地并進行播放將會是個不小的難題。而目前下載中使用的較為廣泛的有 TCP(Transmission Control Protocol )和UDP(User Datagram Protocol)網(wǎng)絡協(xié)議。
傳輸控制協(xié)議(TCP)協(xié)議主要用于在主機間建立一個虛擬連接，以實現(xiàn)高可靠 性的數(shù)據(jù)包交換。IP協(xié)議可以進行IP數(shù)據(jù)包的分割和組裝，但是通過IP協(xié)議并不 能清楚地了解到數(shù)據(jù)包是否順利地發(fā)送給目標計算機。而TCP協(xié)議在其傳輸模式中， 會在將數(shù)據(jù)包成功發(fā)送給目標計算機后要求發(fā)送一個確認；如果在某個時限內(nèi)沒有 收到確認，那么TCP將重新發(fā)送數(shù)據(jù)包。另外，在傳輸?shù)倪^程中，如果接收到無序、 丟失以及被破壞的數(shù)據(jù)包，TCP還可以負責恢復，最常用的方式就是只要不得到確 認，就重新發(fā)送數(shù)據(jù)報，直到得到對方的確認為止。
TCP協(xié)議可以提供一條可靠的傳輸途徑，所以在目前對傳輸數(shù)據(jù)要求較高的一 些場合均以TCP協(xié)議為主，以保證數(shù)據(jù)的正確、完整性。但如果在面對大量終端與 服務器實現(xiàn)TCP傳輸時，由于服務器要負責實現(xiàn)全部的容錯機制，因此極大地增加 了服務器的各種開銷，這對于服務器來說將是一個很大的負擔。
用戶數(shù)據(jù)報協(xié)議(UDP)是TCP/IP協(xié)議組的一個組成部分。它的創(chuàng)立是為了向 應用程序提供一條訪問IP的無連接功能的途徑。TCP和UDP都使用IP。 UDP的設(shè) 計允許應用程序創(chuàng)建數(shù)據(jù)報，以及將它們編址到訪問應用程序或進程的端口。 UDP 的基本作用就是向一個IP分組增加一個應用程序進程的端口地址。
可以看出UDP較之TCP簡單了很多，只要把數(shù)據(jù)發(fā)送出去而不管發(fā)送端是否成 功收到數(shù)據(jù)，因此傳輸速度較快。但是該協(xié)議對于可能出現(xiàn)的丟包無容錯機制，無 法保證數(shù)據(jù)傳輸?shù)耐暾?，即無法保證可靠的數(shù)據(jù)傳輸。
考慮到高清媒體容量大的特性，終端與服務器之間的下載就是一個大容量數(shù)據(jù)傳輸?shù)倪^程，在這過程中不僅要考慮到數(shù)據(jù)傳輸?shù)耐暾赃€要兼顧到數(shù)據(jù)傳輸?shù)乃?率問題，TCP雖然可靠，但自身的容錯特性會造成一定程度上造成數(shù)據(jù)的重復傳輸， 且過多的協(xié)議握手也對速率造成了一定的影響，在面對大量數(shù)據(jù)傳輸?shù)臅r候，服務 器負載較重；UDP雖然能比較有效的解決服務器負載問題，擁有較快的數(shù)據(jù)傳輸速 度，但UDP是面對無連接的，對網(wǎng)絡丟包未做容錯處理，因此，不能提供可靠的數(shù) 據(jù)傳輸。

發(fā)明內(nèi)容
本發(fā)明的目的是提供一種在保證數(shù)據(jù)傳輸可靠的基礎(chǔ)上實現(xiàn)大數(shù)據(jù)量文件高效 率傳輸?shù)木W(wǎng)絡下載方法。并且，該網(wǎng)絡下載方法能夠根據(jù)網(wǎng)絡丟包率自動選擇數(shù)據(jù) 下載方式及容錯機制，從而進一步保證了數(shù)據(jù)傳輸?shù)母咝院驼_性，滿足各種不 同網(wǎng)絡丟包率的環(huán)境下的需要。
為實現(xiàn)上述發(fā)明目的，本發(fā)明提供了一種大數(shù)據(jù)量網(wǎng)絡下載的方法，該方法涉 及服務器和終端，所述服務器具有控制線程和數(shù)據(jù)線程，所述終端具有控制線程和
數(shù)據(jù)線程，所述大數(shù)據(jù)量文件的網(wǎng)絡下載方法包括下列步驟
1) 服務器和終端運行控制線程進行協(xié)議信息交互，完成服務器和終端的控制端 口協(xié)議間的握手-，
2) 步驟1)結(jié)束后，服務器和終端運行數(shù)據(jù)線程，完成服務器和終端的數(shù)據(jù)端 口的握手；
3) 通過數(shù)據(jù)線程在服務器和終端的數(shù)據(jù)端口之間傳輸數(shù)據(jù)文件；
4) 在數(shù)據(jù)文件傳輸完畢后重新運行控制線程。
采用上述方案，當握手成功，數(shù)據(jù)端口直接進行數(shù)據(jù)的下載，控制端口不再干 涉，僅當當前文件傳輸完畢再由控制端口接管并進行下一個文件的下載流程或者進 入等待用戶觸發(fā)狀態(tài)，中間數(shù)據(jù)傳遞節(jié)省了不必要的握手，從而有效的改善數(shù)據(jù)傳 輸速率。
上述技術(shù)方案中，所述步驟l)中，進行協(xié)議信息交互時，當協(xié)議信息發(fā)起端在 發(fā)出協(xié)議信息后，在預先設(shè)定的時間閾值內(nèi)未收到接收端對所述協(xié)議信息的回復， 則所述協(xié)議信息發(fā)起端重發(fā)該協(xié)議信息。
上述技術(shù)方案中，所述時間閾值為200ms。
上述技術(shù)方案中，所述步驟3)中，還需要根據(jù)網(wǎng)絡丟包狀況自適應釆取重發(fā)、 補發(fā)策略，動態(tài)選擇相對應的下載方式。當終端所收到數(shù)據(jù)報文的包序號與該終端 進行本次網(wǎng)絡下載的應用程序的內(nèi)部計數(shù)器的計數(shù)值不匹配時，根據(jù)二者之差選擇觸發(fā)重發(fā)機制或補發(fā)機制獲取丟失的數(shù)據(jù)報文，以保證數(shù)據(jù)傳輸?shù)母咝约叭蒎e性。 進一步地，所述步驟3)包括下列子步驟
31) 服務器向終端發(fā)送數(shù)據(jù)報文；
32) 所述終端接收并解析數(shù)據(jù)報文，獲得所收到數(shù)據(jù)報文的包序號，并與該終 端進行本次網(wǎng)絡下載的應用程序的內(nèi)部計數(shù)器做比較，如果所述包序號減去內(nèi)部計 數(shù)器計數(shù)值為0，則進行數(shù)據(jù)的存儲；如果所述包序號減去內(nèi)部計數(shù)器計數(shù)值的差值 大于等于3，則進入步驟33);如果所述包序號減去內(nèi)部計數(shù)器計數(shù)值的差值小于3， 則進入步驟34);
33) 所述終端向服務器發(fā)送重發(fā)請求，重發(fā)請求中攜帶重發(fā)起始包序號，所述
重發(fā)起始包序號等于內(nèi)部計數(shù)器的當前值，同時所述終端對接下來所收到的數(shù)據(jù)報
文一律丟棄，直到所述包序號減去內(nèi)部計數(shù)器計數(shù)值的差值為o，所述數(shù)據(jù)文件的指
針根據(jù)當前包序號進行位置偏移；
34) 所述終端接收當前數(shù)據(jù)報文，然后文件指針根據(jù)包序號進行偏移并存儲數(shù) 據(jù)，內(nèi)部計數(shù)器值改為當前接收到的包序號，中間所跳過的包序號作為補發(fā)包序號 存入補發(fā)隊列；所述終端向服務器發(fā)送補發(fā)請求，補發(fā)請求攜帶補發(fā)包序號；
35) 服務器在收到重發(fā)請求后，根據(jù)終端傳遞上來的所述重發(fā)起始包序號重新 定位內(nèi)部文件指針并從所述重發(fā)起始包序號處起重新發(fā)送數(shù)據(jù)報文；
36) 服務器在收到補發(fā)請求后，內(nèi)部文件繼續(xù)往下順序偏移，同時服務器在子 線程中對傳遞上來要求補發(fā)的包號立即進行補發(fā)處理，終端如果收到小于當前計數(shù) 器的包序號，判斷該包序號是否與補發(fā)隊列中某一補發(fā)包序號相等，如果相等，則 從補發(fā)隊列中刪除該補發(fā)包序號。
上述技術(shù)方案中，所述步驟34)中，當補發(fā)隊列中的補發(fā)包序號超過某一極值 時，終端向服務器端發(fā)送降速命令以減少服務器發(fā)送數(shù)據(jù)包的頻率。
上述技術(shù)方案中，所述終端每完成一定數(shù)目的數(shù)據(jù)包下載即向服務器發(fā)送一個 在線接收心跳報文；如果所述服務器連續(xù)三次沒有收到終端的心跳報文，則服務器 停止本次下載。
與現(xiàn)有技術(shù)相比，本發(fā)明的優(yōu)點在于
結(jié)合TCP協(xié)議與UDP協(xié)議的長處，既具有TCP協(xié)議下數(shù)據(jù)傳輸?shù)目煽啃?，?具備UDP協(xié)議下服務器負載輕，數(shù)據(jù)傳輸快的特點，特別值得說明的是終端可根據(jù) 不同網(wǎng)絡的丟包狀況，自適應改變數(shù)據(jù)傳輸策略，具備各個網(wǎng)絡環(huán)境下較強的適應 能力，尤其是在網(wǎng)絡丟包嚴重(公網(wǎng)環(huán)境，丟包率在20%左右)或是數(shù)據(jù)擁塞的環(huán) 境下能夠表現(xiàn)出較強的數(shù)據(jù)接收能力(詳見測試圖2)。實踐證明，本發(fā)明的下載速度平均可達網(wǎng)絡帶寬的70%至80% 。
另外，本發(fā)明核心代碼量僅占18.5KB，代碼精簡，高效，尤其符合嵌入式平臺 的代碼空間要求。


圖1是本發(fā)明實現(xiàn)大數(shù)據(jù)量下載的程序流程圖。
具體實施例方式
下面結(jié)合附圖1和具體實施方式
對本發(fā)明作進一步詳細描述
本發(fā)明提供的基于嵌入式平臺的高清媒體網(wǎng)絡下載方法，包括(1)雙方約定應 用層各個標志位，采用胖客戶機模式；(2)功能模塊化，采用雙線程機制，其中一 線程負責控制協(xié)議握手，而另一線程負責數(shù)據(jù)端口握手，兩個端口采用不同的容錯 策略，針對性強，有效提升數(shù)據(jù)傳輸速率；(3)雙線程的運行方式模擬DMA通道策 略，在控制端口成功握手后由數(shù)據(jù)端口來完全接管數(shù)據(jù)的傳輸直至文件傳輸結(jié)束； (4)根據(jù)網(wǎng)絡丟包率自適應采取重發(fā)、補發(fā)策略，選擇相對應的下載方式，保證數(shù) 據(jù)傳輸?shù)母咝浴?br> 雙方在應用層約定各個標志位來進行協(xié)議的握手和數(shù)據(jù)的下載，為有效減輕服 務器負載，采用胖客戶機模式，終端負責絕大部分的操作，有效減輕服務器負載。
雙方根據(jù)約定填充報文標志位并發(fā)送，接收方同樣根據(jù)約定解析出數(shù)據(jù)，固定 的，雙方約定應用層的第3個字節(jié)來唯一確定消息的類型，同時，為方便今后消息 類型的擴展，可以采用二級消息類型目錄；約定第5，第6個字節(jié)為發(fā)送數(shù)據(jù)包的長 度(包括包頭在內(nèi))，以檢測數(shù)據(jù)包的完整性，如果解析出來的數(shù)據(jù)報文長度與頭部 Head.length長度不符，則認為所發(fā)報文不正確。
分配兩個獨立的線程分別進行控制端口和數(shù)據(jù)端口的操作，控制端口在成功進 行握手后便由數(shù)據(jù)端口來接手數(shù)據(jù)的傳輸，中間無需控制端口的干涉，較TCP協(xié)議 而言節(jié)省了大量的握手時間，當數(shù)據(jù)傳輸完成再由控制端口來接管當前操作(即由 控制線程接管CPU)。
控制端口的容錯采用超時機制，即當發(fā)送端在發(fā)送消息200ms后還未收到接收 方的回應，便判斷信息發(fā)送超時，進行重發(fā)操作。
數(shù)據(jù)端口的容錯可根據(jù)網(wǎng)絡丟包率的情況自動選擇容錯機制，具體如下-(1)在接收到數(shù)據(jù)報文后，解析出包號(可以根據(jù)約定的應用層中的標志位來 判斷所收到的包序號)，并與文件內(nèi)部計數(shù)器(內(nèi)部計數(shù)器指的是終端進行本次下載的應用程序為當前正在下載的文件所設(shè)置的內(nèi)部計數(shù)器)相比較，如果符合，則是 所要求的數(shù)據(jù)包，可進行文件的寫操作，如果包號與文件計數(shù)器不符，則說明發(fā)生 丟包，根據(jù)網(wǎng)絡丟包率進行容錯機制選擇。
(2) 當從數(shù)據(jù)報文解析出來的包號與內(nèi)部文件計數(shù)器差值大于或等于3時，觸 發(fā)重發(fā)機制，終端丟棄已接收到的數(shù)據(jù)報文直到所需包號的到來，服務器則根據(jù)傳 遞上來的包號重新定位文件內(nèi)部指針并立即推送數(shù)據(jù)。
(3) 當從數(shù)據(jù)報文解析出來的包號與內(nèi)部文件計數(shù)器差值小于3時，觸發(fā)補發(fā) 機制，終端接受已經(jīng)傳遞過來的數(shù)據(jù)報文，文件指針根據(jù)解析出來的包號進行偏移 存儲，同時終端建立補發(fā)隊列，進行補發(fā)請求，服務器收到補發(fā)請求后并不改原文 件發(fā)送指針位置，而是在子線程中利用另一文件指針進行補發(fā)包的快速定位和補發(fā)。 與重發(fā)機制所不同的是，補發(fā)機制中，終端接收當前數(shù)據(jù)報文，同時文件指針根據(jù) 包序號進行偏移并存儲數(shù)據(jù)，內(nèi)部計數(shù)器值改為當前接收到的包序號，這樣有效的 節(jié)省了數(shù)據(jù)的重復傳遞，提升了數(shù)據(jù)傳輸?shù)男省?br> 終端在收到比文件計數(shù)器小的包號便會判斷是否與補發(fā)隊列中某一包號相符， 如果相符，則說明補發(fā)成功，該包號做出隊操作。進一步地，為避免網(wǎng)絡丟包率較 高可能造成的補發(fā)隊列的溢出，當補發(fā)隊列超過某一極值時，根據(jù)約定的補發(fā)等級， 終端會采用動態(tài)調(diào)整降速策略向服務器端發(fā)送降速命令，以適應目前補發(fā)隊列的長 度并減少服務器發(fā)送數(shù)據(jù)包的頻率。
當終端收到尾包，判斷當前補發(fā)隊列是否為空，如果此時補發(fā)隊列為空，則通 過控端口發(fā)送下載完成請求，服務器響應并停止傳送數(shù)據(jù)，至此整個傳輸過程結(jié)束； 如若補發(fā)隊列非空則進行補發(fā)操作，則重復進行補發(fā)隊列的判斷直至為空，表明數(shù) 據(jù)己下載完整。
進一步地，本實施例中還采用了數(shù)據(jù)報文智能反饋機制當終端數(shù)據(jù)線程每收
到服務器100個數(shù)據(jù)報文(每個報文1316 Bytes)時，終端的控制線程則向服務器發(fā) 送一個在線接收心跳報文，服務器根據(jù)接收到的心跳報文判斷終端是否正常在線接 收；服務器連續(xù)三次沒有收到終端的心跳報文，服務器認為終端離線，立即終止此 次數(shù)據(jù)下載。這種反饋機制可以有效防止某臺網(wǎng)絡終端出現(xiàn)故障離線時，導致的數(shù) 據(jù)大量堆積在終端路由器端而造成的網(wǎng)絡擁塞現(xiàn)象并且浪費服務器資源。
權(quán)利要求
1、一種大數(shù)據(jù)量文件的網(wǎng)絡下載方法，涉及服務器和終端，所述服務器具有控制線程和數(shù)據(jù)線程，所述終端具有控制線程和數(shù)據(jù)線程，所述大數(shù)據(jù)量文件的網(wǎng)絡下載方法包括下列步驟1)服務器和終端運行控制線程進行協(xié)議信息交互，完成服務器和終端的控制端口協(xié)議間的握手；2)步驟1)結(jié)束后，服務器和終端運行數(shù)據(jù)線程，完成服務器和終端的數(shù)據(jù)端口的握手；3)通過數(shù)據(jù)線程在服務器和終端的數(shù)據(jù)端口之間傳輸數(shù)據(jù)文件；4)在數(shù)據(jù)文件傳輸完畢后重新運行控制線程。
2、 根據(jù)權(quán)利要求l所述的大數(shù)據(jù)量文件的網(wǎng)絡下載方法，其特征在于，所述步 驟l)中，進行協(xié)議信息交互時，當協(xié)議信息發(fā)起端在發(fā)出協(xié)議信息后，在預先設(shè)定 的時間閾值內(nèi)未收到接收端對所述協(xié)議信息的回復，則所述協(xié)議信息發(fā)起端重發(fā)該 協(xié)議信息。
3、 根據(jù)權(quán)利要求2所述的大數(shù)據(jù)量文件的網(wǎng)絡下載方法，其特征在于，所述時 間閾值為200ms。
4、 根據(jù)權(quán)利要求l所述的大數(shù)據(jù)量文件的網(wǎng)絡下載方法，其特征在于，所述步 驟3)中，當終端所收到數(shù)據(jù)報文的包序號與該終端進行本次網(wǎng)絡下載的應用程序的 內(nèi)部計數(shù)器的計數(shù)值不匹配時，根據(jù)二者之差選擇觸發(fā)重發(fā)機制或補發(fā)機制獲取丟 失的數(shù)據(jù)報文。
5、 根據(jù)權(quán)利要求l所述的大數(shù)據(jù)量文件的網(wǎng)絡下載方法，其特征在于，所述步 驟3)中，包括下列子步驟31) 服務器向終端發(fā)送數(shù)據(jù)報文；32) 所述終端接收并解析數(shù)據(jù)報文，獲得所收到數(shù)據(jù)報文的包序號，并與該終 端進行本次網(wǎng)絡下載的應用程序的內(nèi)部計數(shù)器做比較，如果所述包序號減去內(nèi)部計 數(shù)器計數(shù)值為O，則進行數(shù)據(jù)的存儲；如果所述包序號減去內(nèi)部計數(shù)器計數(shù)值的差值 大于等于3，則進入步驟33);如果所述包序號減去內(nèi)部計數(shù)器計數(shù)值的差值小于3， 則進入步驟34);33) 所述終端向服務器發(fā)送重發(fā)請求，重發(fā)請求中攜帶重發(fā)起始包序號，所述 重發(fā)起始包序號等于內(nèi)部計數(shù)器的當前值，同時所述終端對接下來所收到的數(shù)據(jù)報 文一律丟棄，直到所述包序號減去內(nèi)部計數(shù)器計數(shù)值的差值為O，所述數(shù)據(jù)文件的指針根據(jù)當前包序號進行位置偏移；34) 所述終端接收當前數(shù)據(jù)報文，然后文件指針根據(jù)包序號進行偏移并存儲數(shù) 據(jù)，內(nèi)部計數(shù)器值改為當前接收到的包序號，中間所跳過的包序號作為補發(fā)包序號 存入補發(fā)隊列；所述終端向服務器發(fā)送補發(fā)請求，補發(fā)請求攜帶補發(fā)包序號；35) 服務器在收到重發(fā)請求后，根據(jù)終端傳遞上來的所述重發(fā)起始包序號重新 定位內(nèi)部文件指針并從所述重發(fā)起始包序號處起重新發(fā)送數(shù)據(jù)報文；36) 服務器在收到補發(fā)請求后，內(nèi)部文件繼續(xù)往下順序偏移，同時服務器在子 線程中對傳遞上來要求補發(fā)的包號立即進行補發(fā)處理，終端如果收到小于當前計數(shù) 器的包序號，判斷該包序號是否與補發(fā)隊列中某一補發(fā)包序號相等，如果相等，則 從補發(fā)隊列中刪除該補發(fā)包序號。
6、 根據(jù)權(quán)利要求5所述的大數(shù)據(jù)量文件的網(wǎng)絡下載方法，其特征在于，所述步 驟34)中，當補發(fā)隊列中的補發(fā)包序號超過某一極值時，終端向服務器端發(fā)送降速 命令以減少服務器發(fā)送數(shù)據(jù)包的頻率。
7、 根據(jù)權(quán)利要求l所述的大數(shù)據(jù)量文件的網(wǎng)絡下載方法，其特征在于，所述終 端每完成一定數(shù)目的數(shù)據(jù)包下載即向服務器發(fā)送一個在線接收心跳報文;如果所述 服務器連續(xù)三次沒有收到終端的心跳報文，則服務器停止本次下載。
全文摘要
本發(fā)明提供了一種大數(shù)據(jù)量文件的網(wǎng)絡下載的方法，該方法涉及服務器和終端，所述服務器具有控制線程和數(shù)據(jù)線程，所述終端具有控制線程和數(shù)據(jù)線程，所述大數(shù)據(jù)量文件的網(wǎng)絡下載方法包括下列步驟1)服務器和終端運行控制線程進行協(xié)議信息交互，完成服務器和終端的控制端口協(xié)議間的握手；2)步驟1)結(jié)束后，服務器和終端運行數(shù)據(jù)線程，完成服務器和終端的數(shù)據(jù)端口的握手；3)通過數(shù)據(jù)線程在服務器和終端的數(shù)據(jù)端口之間傳輸數(shù)據(jù)文件；4)在數(shù)據(jù)文件傳輸完畢后重新運行控制線程。本發(fā)明能夠高效地可靠地傳輸數(shù)據(jù)，特別適合于大數(shù)據(jù)量文件的網(wǎng)絡下載。
文檔編號H04L29/06GK101651676SQ200910091939
公開日2010年2月17日 申請日期2009年9月1日 優(yōu)先權(quán)日2009年9月1日
發(fā)明者梁 潘, 王勁林, 胡建良, 峰 鄧, 齊向東 申請人:北京中科智網(wǎng)傳媒技術(shù)有限公司;中國科學院聲學研究所