| 基於混合TCP-UDP的HTTP協議實現方法 |
| 文章作者：王 超 文章類型：設計應用 文章加入時間：2003年7月30日1:54 |
| 文章出處：單片機及嵌入式系統應用 |
|
引 言
超文本傳輸協議（HTTP）是目前通過Internet進行信息交換最主要的方式。HTTP協議是建立在請求/響應(request/response)模型上的。
 首先由客戶建立一條與服務器的TCP鏈接，併發送一個請求到服務器，請求中包含請求方法、URI、協議版本以及相關的MIME(Multipurpose Internet Mail Extensions)樣式的消息。服務器響應一個狀態行，包含消息的協議版本、一個成功和失敗碼以及相關的MIME式樣的消息(包含服務器的信息、資源實體的信息和可能的資源內容)。圖1給出了HTTP協議實現的一個簡單模型。HTTP/1.0[3]爲每一次HTTP的請求/響應建立一條新的TCP鏈接，因此一個包含HTML內容和圖片的頁面將需要建立多次的短期的TCP鏈接。一次TCP鏈接的建立將需要3次握手。另外，爲了獲得適當的傳輸速度，則需要TCP花費額外的迴路鏈接時間（RTT）。每一次鏈接的建立需要這種經常性的開銷，而其並不帶有實際有用的數據，只是保證鏈接的可靠性，因此HTTP/1.1[4]提出了可持續鏈接的實現方法。HTTP/1.1將只建立一次TCP的鏈接而重複地使用它傳輸一系列的請求/響應消息，因此減少了鏈接建立的次數和經常性的鏈接開銷。
可持續鏈接減少了每次TCP鏈接建立的時間，但是一個空閒的TCP鏈接將需要一個Socket和相應的存儲緩衝區。一個Socket緩衝區的最小長度必須大於一個TCP包的最大長度，即64 KB，而且很多實現方法在鏈接建立時將預分配一些緩衝區。可用的Socket的數量是有限的，很多基於BSD的操作系統對於能夠同時打開的鏈接數都有一個缺省的最大值。
 無線掌上設備PDA的應用（如瀏覽器）[5]特點表現在：① 因爲頁面是針對掌上設備製作的，一般在1 K~2 K字節，比較小；② 目前無線通信網絡的帶寬很窄，GSM的數據信道帶寬只有9.6 K。當前Web頁面的訪問大多通過HTTP協議，並使用TCP作爲下層的傳輸控制協議。但不幸的是，TCP並不適合短會話的應用情況，不同於現在採用的使用單一TCP傳輸協議進行數據傳輸的方式。本文提出了採用動態選擇傳輸層協議（TCP、UDP）的方法來改善取回頁面的延遲、網絡擁塞以及服務器的負荷。
這種混合TCP-UDP的方法結合兩個方面的優點：首先，對於需要比較少數據傳輸的情況，它將使用UDP作爲傳輸層的協議，從而避免了TCP鏈接的多次握手開銷；另外，對於需要較多數據傳輸的情況，它將使用可靠的帶有重排序和擁塞控制的TCP協議作爲傳輸層的協議。混合TCP-UDP的實現方法只需要對應用層的改動，而操作系統的核心代碼不用任何更改。僅採用UDP協議的缺點在於，需要在應用層建立一套類似於TCP複雜的控制協議，從而進行重排序和擁塞控制來保證傳輸的可靠性。
1 背 景
HTTP是一個請求/響應協議，客戶端的應用程序通過提供一個URL可以從服務器上得到所需的數據。HTTP可以用來訪問各種不同類型的資源，其中包括文本、圖形、影音、可執行文件、數據庫查詢結果等等。
圖2給出了在客戶端發起HTTP GET請求後，在客戶端和服務器之間進行數據包交換的示意。圖中只有兩個數據包是有用的（即攜帶了數據）：
一個是HTTP GET請求，另一個是HTTP的響應。其它的都是TCP用來進行握手操作的數據包。爲了減輕Web服務器的負荷，經常採用重定向機制。這樣從服務器發來的重定向響應報文是很短的數據包。使用TCP作爲傳輸協議需要至少7個數據包，而使用UDP則只需要2個數據包就足夠了。
 2 設 計
我們使用混合傳輸層[6]的方法即對於少量數據傳輸的鏈接採用UDP，而對於大量數據傳輸的鏈接採用TCP作爲傳輸層協議。這樣對於短鏈接而言就避免了TCP經常性的握手開銷，而對於長鏈接則仍可獲得TCP的優點，如超時重傳、擁塞控制、錯誤恢復機制等。這種方法中，客戶端首先嚐試使用UDP作爲傳輸層的協議，如果對於所請求的URL UDP並不適合，則再次使用TCP鏈接。這種方法提供了以下保證：
◇ 如果初始的UDP數據包丟失，將採用TCP重新鏈接而不會受到影響。
◇ 如果所鏈接的服務器沒有使用混合傳輸層的實現機制，客戶端將使用TCP重新進行鏈接。
圖3給出了混合TCP、UDP的實現算法。一個採用混合算法的HTTP客戶端首先使用UDP作爲傳輸層的協議發出HTTP GET請求，同時啓動超時定時器。
當服務器處理客戶端發來的請求時，它可以從以下兩點做出選擇：
 ① 如果響應的數據足夠小（比如，可放到一個數據包中），服務器將使用UDP發回響應。像比較小的網頁或HTTP REDIRECT響應就屬於這一類。
② 如果響應的數據很大，無法放進一個UDP數據包中，服務器則要求客戶端使用TCP重試。這可以通過添加一個HTTP的頭部字段來解決如 TCPRETR。
在客戶端，將會出現以下三種情況：
◇ 客戶端從服務器接收到響應。如果響應中包含了所需的HTTP響應，客戶端將對數據進行處理。如果服務器要求客戶端重試，客戶端將使用TCP作爲傳輸層重試。
◇ 如果服務器沒有處理通過UDP傳輸的HTTP包，客戶端就會收到ICMP錯誤消息（目的地址無法到達/協議無法到達）。此時客戶端將會使用TCP重試。
◇ 如果定時器超時，客戶端應使用TCP重試。
圖4給出了在定時器超時情況下，客戶端和服務器之間數據包的交換。這種超時機制提供了可靠性，以及與未使用混合TCP-UDP方法的服務器的兼容性。
 圖5示意了服務器要求客戶端使用TCP重發請求時，客戶端和服務器之間的數據包交換。
3 結 語
混合TCP-UDP方法改善了參與HTTP傳輸的三個方面：客戶端、服務器和網絡。
◇ 對於客戶端而言，可以避免由於TCP而引入的三向握手的時間，從而減少了瀏覽的延遲時間。
◇ 對於服務器而言，由於所需的TCP的鏈接數量減少，從而降低了由於建立、維護、撤銷TCP鏈接所帶來的服務器的負荷。
◇ 對於網絡而言，由於TCP控制數據包的減少從而減少了網絡的擁塞。
|
