在以往的網(wǎng)絡傳輸中，我們都知道經(jīng)典的HTTP傳輸協(xié)議，但其本身的請求建立和響應過程非常容易造成失敗。那么，這里我們就提出了應用混合TCP UDP協(xié)議的相關(guān)概念來解決這方面內(nèi)容。

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

圖1給出了HTTP協(xié)議實現(xiàn)的一個簡單模型。HTTP/1.0為每一次HTTP的請求/響應建立一條新的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的鏈接而重復地使用它傳輸一系列的請求/響應消息，因此減少了鏈接建立的次數(shù)和經(jīng)常性的鏈接開銷。

可持續(xù)鏈接減少了每次TCP鏈接建立的時間，但是一個空閑的TCP鏈接將需要一個Socket和相應的存儲緩沖區(qū)。一個Socket緩沖區(qū)的最小長度必須大于一個TCP包的最大長度，即64 KB，而且很多實現(xiàn)方法在鏈接建立時將預分配一些緩沖區(qū)?？捎玫腟ocket的數(shù)量是有限的，很多基于BSD的操作系統(tǒng)對于能夠同時打開的鏈接數(shù)都有一個缺省的最大值。

無線掌上設備PDA的應用（如瀏覽器）特點表現(xiàn)在：

① 因為頁面是針對掌上設備制作的，一般在1 K~2 K字節(jié)，比較?。?/p>

② 目前無線通信網(wǎng)絡的帶寬很窄，GSM的數(shù)據(jù)信道帶寬只有9.6 K。

當前Web頁面的訪問大多通過HTTP協(xié)議，并使用TCP作為下層的傳輸控制協(xié)議。但不幸的是，TCP并不適合短會話的應用情況，不同于現(xiàn)在采用的使用單一TCP傳輸協(xié)議進行數(shù)據(jù)傳輸?shù)姆绞健１疚奶岢隽瞬捎脛討B(tài)選擇傳輸層協(xié)議（TCP UDP協(xié)議）的方法來改善取回頁面的延遲、網(wǎng)絡擁塞以及服務器的負荷。

這種混合TCP UDP協(xié)議的方法結(jié)合兩個方面的優(yōu)點：首先，對于需要比較少數(shù)據(jù)傳輸?shù)那闆r，它將使用UDP作為傳輸層的協(xié)議，從而避免了TCP鏈接的多次握手開銷；另外，對于需要較多數(shù)據(jù)傳輸?shù)那闆r，它將使用可靠的帶有重排序和擁塞控制的TCP協(xié)議作為傳輸層的協(xié)議?；旌蟃CP UDP協(xié)議的實現(xiàn)方法只需要對應用層的改動，而操作系統(tǒng)的核心代碼不用任何更改。僅采用UDP協(xié)議的缺點在于，需要在應用層建立一套類似于TCP復雜的控制協(xié)議，從而進行重排序和擁塞控制來保證傳輸?shù)目煽啃浴?/p>