基于混合TCP-UDP的HTTP協(xié)議實(shí)現方法論文
摘要：目前，用于Web頁(yè)面訪(fǎng)問(wèn)的應用都是基于HTTP應用協(xié)議的，而在下層則使用傳輸控制協(xié)議（TCP）[1]作為傳輸協(xié)議；但TCP并不適合于短會(huì )話(huà)，即只有少量的數據交換的情況。因為建立、撤銷(xiāo)TCP鏈接的開(kāi)銷(xiāo)即使對于短會(huì )話(huà)也是必需的。 在用于PDA（個(gè)人數字助理）中瀏覽器的設計中，根據無(wú)線(xiàn)網(wǎng)絡(luò )延遲大、帶寬窄的特點(diǎn)提出了一種混合TCP-UDP傳輸協(xié)議的方法來(lái)解決這一問(wèn)題。本方法使用UDP[2]作為短會(huì )話(huà)時(shí)的傳輸層協(xié)議，而對于有大量數據需要傳輸時(shí)則使用TCP作為傳輸層的協(xié)議。這樣，對于短會(huì )話(huà)可以避免TCP的額外開(kāi)銷(xiāo)，而對于長(cháng)會(huì )話(huà)又可以得到由TCP提供的可靠傳輸和擁塞控制。
關(guān)鍵詞：TCP UDP HTTP PDA
引 言
超文本傳輸協(xié)議（HTTP）是目前通過(guò)Internet進(jìn)行信息交換最主要的方式。HTTP協(xié)議是建立在請求/響應(request/response)模型上的。首先由客戶(hù)建立一條與服務(wù)器的TCP鏈接，并發(fā)送一個(gè)請求到服務(wù)器，請求中包含請求方法、URI、協(xié)議版本以及相關(guān)的MIME(Multipurpose Internet Mail Extensions)樣式的消息。服務(wù)器響應一個(gè)狀態(tài)行，包含消息的協(xié)議版本、一個(gè)成功和失敗碼以及相關(guān)的MIME式樣的消息(包含服務(wù)器的信息、資源實(shí)體的信息和可能的資源內容)。圖1給出了HTTP協(xié)議實(shí)現的一個(gè)簡(jiǎn)單模型。HTTP/1.0[3]為每一次HTTP的請求/響應建立一條新的TCP鏈接，因此一個(gè)包含HTML內容和圖片的頁(yè)面將需要建立多次的短期的TCP鏈接。一次TCP鏈接的建立將需要3次握手。另外，為了獲得適當的傳輸速度，則需要TCP花費額外的回路鏈接時(shí)間（RTT）。每一次鏈接的建立需要這種經(jīng)常性的開(kāi)銷(xiāo)，而其并不帶有實(shí)際有用的數據，只是保證鏈接的可靠性，因此HTTP/1.1[4]提出了可持續鏈接的實(shí)現方法。HTTP/1.1將只建立一次TCP的鏈接而重復地使用它傳輸一系列的請求/響應消息，因此減少了鏈接建立的次數和經(jīng)常性的鏈接開(kāi)銷(xiāo)。
可持續鏈接減少了每次TCP鏈接建立的時(shí)間，但是一個(gè)空閑的TCP鏈接將需要一個(gè)Socket和相應的存儲緩沖區。一個(gè)Socket緩沖區的最小長(cháng)度必須大于一個(gè)TCP包的最大長(cháng)度，即64 KB，而且很多實(shí)現方法在鏈接建立時(shí)將預分配一些緩沖區�？捎玫腟ocket的數量是有限的，很多基于BSD的操作系統對于能夠同時(shí)打開(kāi)的鏈接數都有一個(gè)缺省的最大值。
無(wú)線(xiàn)掌上設備PDA的應用（如瀏覽器）[5]特點(diǎn)表現在：① 因為頁(yè)面是針對掌上設備制作的，一般在1 K~2 K字節，比較��；② 目前無(wú)線(xiàn)通信網(wǎng)絡(luò )的帶寬很窄，GSM的數據信道帶寬只有9.6 K。當前Web頁(yè)面的訪(fǎng)問(wèn)大多通過(guò)HTTP協(xié)議，并使用TCP作為下層的.傳輸控制協(xié)議。但不幸的是，TCP并不適合短會(huì )話(huà)的應用情況，不同于現在采用的使用單一TCP傳輸協(xié)議進(jìn)行數據傳輸的方式。本文提出了采用動(dòng)態(tài)選擇傳輸層協(xié)議（TCP、UDP）的方法來(lái)改善取回頁(yè)面的延遲、網(wǎng)絡(luò )擁塞以及服務(wù)器的負荷。
這種混合TCP-UDP的方法結合兩個(gè)方面的優(yōu)點(diǎn)：首先，對于需要比較少數據傳輸的情況，它將使用UDP作為傳輸層的協(xié)議，從而避免了TCP鏈接的多次握手開(kāi)銷(xiāo)；另外，對于需要較多數據傳輸的情況，它將使用可靠的帶有重排序和擁塞控制的TCP協(xié)議作為傳輸層的協(xié)議�；旌蟃CP-UDP的實(shí)現方法只需要對應用層的改動(dòng)，而操作系統的核心代碼不用任何更改。僅采用UDP協(xié)議的缺點(diǎn)在于，需要在應用層建立一套類(lèi)似于TCP復雜的控制協(xié)議，從而進(jìn)行重排序和擁塞控制來(lái)保證傳輸的可靠性。
1 背 景
HTTP是一個(gè)請求/響應協(xié)議，客戶(hù)端的應用程序通過(guò)提供一個(gè)URL可以從服務(wù)器上得到所需的數據。HTTP可以用來(lái)訪(fǎng)問(wèn)各種不同類(lèi)型的資源，其中包括文本、圖形、影音、可執行文件、數據庫查詢(xún)結果等等。
圖2給出了在客戶(hù)端發(fā)起HTTP GET請求后，在客戶(hù)端和服務(wù)器之間進(jìn)行數據包交換的示意。圖中只有兩個(gè)數據包是有用的（即攜帶了數據）：一個(gè)是HTTP GET請求，另一個(gè)是HTTP的響應。其它的都是TCP用來(lái)進(jìn)行握手操作的數據包。為了減輕Web服務(wù)器的負荷，經(jīng)常采用重定向機制。這樣從服務(wù)器發(fā)來(lái)的重定向響應報文是很短的數據包。使用TCP作為傳輸協(xié)議需要至少7個(gè)數據包，而使用UDP則只需要2個(gè)數據包就足夠了。
2 設 計
我們使用混合傳輸層[6]的方法即對于少量數據傳輸的鏈接采用UDP，而對于大量數據傳輸的鏈接采用TCP作為傳輸層協(xié)議。這樣對于短鏈接而言就避免了TCP經(jīng)常性的握手開(kāi)銷(xiāo)，而對于長(cháng)鏈接則仍可獲得TCP的優(yōu)點(diǎn)，如超時(shí)重傳、擁塞控制、錯誤恢復機制等。這種方法中，客戶(hù)端首先嘗試使用UDP作為傳輸層的協(xié)議，如果對于所請求的URL UDP并不適合，則再次使用TCP鏈接。這種方法提供了以下保證：
◇ 如果初始的UDP數據包丟失，將采用TCP重新鏈接而不會(huì )受到影響。
◇ 如果所鏈接的服務(wù)器沒(méi)有使用混合傳輸層的實(shí)現機制，客戶(hù)端將使用TCP重新進(jìn)行鏈接。
圖3給出了混合TCP、UDP的實(shí)現算法。一個(gè)采用混合算法的HTTP客戶(hù)端首先使用UDP作為傳輸層的協(xié)議發(fā)出HTTP GET請求，同時(shí)啟動(dòng)超時(shí)定時(shí)器。
當服務(wù)器處理客戶(hù)端發(fā)來(lái)的請求時(shí)，它可以從以下兩點(diǎn)做出選擇：
�、� 如果響應的數據足夠�。ū热�，可放到一個(gè)數據包中），服務(wù)器將使用UDP發(fā)回響應。像比較小的網(wǎng)頁(yè)或HTTP REDIRECT響應就屬于這一類(lèi)。
�、� 如果響應的數據很大，無(wú)法放進(jìn)一個(gè)UDP數據包中，服務(wù)器則要求客戶(hù)端使用TCP重試。這可以通過(guò)添加一個(gè)HTTP的頭部字段來(lái)解決如 TCPRETR。
在客戶(hù)端，將會(huì )出現以下三種情況：
◇ 客戶(hù)端從服務(wù)器接收到響應。如果響應中包含了所需的HTTP響應，客戶(hù)端將對數據進(jìn)行處理。如果服務(wù)器要求客戶(hù)端重試，客戶(hù)端將使用TCP作為傳輸層重試。
◇ 如果服務(wù)器沒(méi)有處理通過(guò)UDP傳輸的HTTP包，客戶(hù)端就會(huì )收到ICMP錯誤消息（目的地址無(wú)法到達/協(xié)議無(wú)法到達）。此時(shí)客戶(hù)端將會(huì )使用TCP重試。
◇ 如果定時(shí)器超時(shí)，客戶(hù)端應使用TCP重試。
圖4給出了在定時(shí)器超時(shí)情況下，客戶(hù)端和服務(wù)器之間數據包的交換。這種超時(shí)機制提供了可靠性，以及與未使用混合TCP-UDP方法的服務(wù)器的兼容性。
圖5示意了服務(wù)器要求客戶(hù)端使用TCP重發(fā)請求時(shí)，客戶(hù)端和服務(wù)器之間的數據包交換。
3 結 語(yǔ)
混合TCP-UDP方法改善了參與HTTP傳輸的三個(gè)方面：客戶(hù)端、服務(wù)器和網(wǎng)絡(luò )。
◇ 對于客戶(hù)端而言，可以避免由于TCP而引入的三向握手的時(shí)間，從而減少了瀏覽的延遲時(shí)間。
◇ 對于服務(wù)器而言，由于所需的TCP的鏈接數量減少，從而降低了由于建立、維護、撤銷(xiāo)TCP鏈接所帶來(lái)的服務(wù)器的負荷。
◇ 對于網(wǎng)絡(luò )而言，由于TCP控制數據包的減少從而減少了網(wǎng)絡(luò )的擁塞。