基于混合tcp-udp的http協(xié)議實現(xiàn)方法

《基于混合tcp-udp的http協(xié)議實現(xiàn)方法》由會員上傳分享，免費在線閱讀，更多相關(guān)內(nèi)容在學術(shù)論文-天天文庫。

1、基于混合TCP-UDP的HTTP協(xié)議實現(xiàn)方法摘要：目前，用于Web頁面訪問的應(yīng)用都是基于HTTP應(yīng)用協(xié)議的，而在下層則使用傳輸控制協(xié)議（TCP）作為傳輸協(xié)議；但TCP并不適合于短會話，即只有少量的數(shù)據(jù)交換的情況。因為建立、撤銷TCP鏈接的開銷即使對于短會話也是必需的。在用于PDA（個人數(shù)字助理）中瀏覽器的設(shè)計中，根據(jù)無線網(wǎng)絡(luò)延遲大、帶寬窄的特點提出了一種混合TCP-UDP傳輸協(xié)議的方法來解決這一問題。本方法使用UDP作為短會話時的傳輸層協(xié)議，而對于有大量數(shù)據(jù)需要傳輸時則使用TCP作為傳輸層的協(xié)議。這樣，對于短會話可以避免TCP的額外開銷，而對于長會話又可以得到由TCP提供的可靠傳輸和擁塞

2、控制。關(guān)鍵詞：TCPUDPHTTPPDA引言　　超文本傳輸協(xié)議（HTTP）是目前通過Internet進行信息交換最主要的方式。HTTP協(xié)議是建立在請求/響應(yīng)(request/response)模型上的。首先由客戶建立一條與服務(wù)器的TCP鏈接，并發(fā)送一個請求到服務(wù)器，請求中包含請求方法、URI、協(xié)議版本以及相關(guān)的MIME(MultipurposeInternetMailExtensions)樣式的消息。服務(wù)器響應(yīng)一個狀態(tài)行，包含消息的協(xié)議版本、一個成功和失敗碼以及相關(guān)的MIME式樣的消息(包含服務(wù)器的信息、資源實體的信息和可能的資源內(nèi)容)。圖1給出了HTTP協(xié)議實現(xiàn)的一個簡單模型。HTTP

3、/1.0為每一次HTTP的請求/響應(yīng)建立一條新的TCP鏈接，因此一個包含HTML內(nèi)容和圖片的頁面將需要建立多次的短期的TCP鏈接。一次TCP鏈接的建立將需要3次握手。另外，為了獲得適當?shù)膫鬏斔俣龋瑒t需要TCP花費額外的回路鏈接時間（RTT）。每一次鏈接的建立需要這種經(jīng)常性的開銷，而其并不帶有實際有用的數(shù)據(jù)，只是保證鏈接的可靠性，因此HTTP/1.1提出了可持續(xù)鏈接的實現(xiàn)方法。HTTP/1.1將只建立一次TCP的鏈接而重復(fù)地使用它傳輸一系列的請求/響應(yīng)消息，因此減少了鏈接建立的次數(shù)和經(jīng)常性的鏈接開銷?！　】沙掷m(xù)鏈接減少了每次TCP鏈接建立的時間，但是一個空閑的TCP鏈接將需要一個Socke

4、t和相應(yīng)的存儲緩沖區(qū)。一個Socket緩沖區(qū)的最小長度必須大于一個TCP包的最大長度，即64KB，而且很多實現(xiàn)方法在鏈接建立時將預(yù)分配一些緩沖區(qū)?？捎玫腟ocket的數(shù)量是有限的，很多基于BSD的操作系統(tǒng)對于能夠同時打開的鏈接數(shù)都有一個缺省的最大值。　　無線掌上設(shè)備PDA的應(yīng)用（如瀏覽器）特點表現(xiàn)在：①因為頁面是針對掌上設(shè)備制作的，一般在1K~2K字節(jié)，比較小；②目前無線通信網(wǎng)絡(luò)的帶寬很窄，GSM的數(shù)據(jù)信道帶寬只有9.6K。當前Web頁面的訪問大多通過HTTP協(xié)議，并使用TCP作為下層的傳輸控制協(xié)議。但不幸的是，TCP并不適合短會話的應(yīng)用情況，不同于現(xiàn)在采用的使用單一TCP傳輸協(xié)議進行數(shù)

5、據(jù)傳輸?shù)姆绞?。本文提出了采用動態(tài)選擇傳輸層協(xié)議（TCP、UDP）的方法來改善取回頁面的延遲、網(wǎng)絡(luò)擁塞以及服務(wù)器的負荷?！　∵@種混合TCP-UDP的方法結(jié)合兩個方面的優(yōu)點：首先，對于需要比較少數(shù)據(jù)傳輸?shù)那闆r，它將使用UDP作為傳輸層的協(xié)議，從而避免了TCP鏈接的多次握手開銷；另外，對于需要較多數(shù)據(jù)傳輸?shù)那闆r，它將使用可靠的帶有重排序和擁塞控制的TCP協(xié)議作為傳輸層的協(xié)議。混合TCP-UDP的實現(xiàn)方法只需要對應(yīng)用層的改動，而操作系統(tǒng)的核心代碼不用任何更改。僅采用UDP協(xié)議的缺點在于，需要在應(yīng)用層建立一套類似于TCP復(fù)雜的控制協(xié)議，從而進行重排序和擁塞控制來保證傳輸?shù)目煽啃浴?背景　　HTTP

6、是一個請求/響應(yīng)協(xié)議，客戶端的應(yīng)用程序通過提供一個URL可以從服務(wù)器上得到所需的數(shù)據(jù)。HTTP可以用來訪問各種不同類型的資源，其中包括文本、圖形、影音、可執(zhí)行文件、數(shù)據(jù)庫查詢結(jié)果等等?！　D2給出了在客戶端發(fā)起HTTPGET請求后，在客戶端和服務(wù)器之間進行數(shù)據(jù)包交換的示意。圖中只有兩個數(shù)據(jù)包是有用的（即攜帶了數(shù)據(jù)）：一個是HTTPGET請求，另一個是HTTP的響應(yīng)。其它的都是TCP用來進行握手操作的數(shù)據(jù)包。為了減輕Web服務(wù)器的負荷，經(jīng)常采用重定向機制。這樣從服務(wù)器發(fā)來的重定向響應(yīng)報文是很短的數(shù)據(jù)包。使用TCP作為傳輸協(xié)議需要至少7個數(shù)據(jù)包，而使用UDP則只需要2個數(shù)據(jù)包就足夠了。2設(shè)計

7、　　我們使用混合傳輸層的方法即對于少量數(shù)據(jù)傳輸?shù)逆溄硬捎肬DP，而對于大量數(shù)據(jù)傳輸?shù)逆溄硬捎肨CP作為傳輸層協(xié)議。這樣對于短鏈接而言就避免了TCP經(jīng)常性的握手開銷，而對于長鏈接則仍可獲得TCP的優(yōu)點，如超時重傳、擁塞控制、錯誤恢復(fù)機制等。這種方法中，客戶端首先嘗試使用UDP作為傳輸層的協(xié)議，如果對于所請求的URLUDP并不適合，則再次使用TCP鏈接。這種方法提供了以下保證◇如果初始的UDP數(shù)據(jù)包丟失，將采用TCP重新鏈接而不會受到影