<dfn id="w48us"></dfn><ul id="w48us"></ul>
  • <ul id="w48us"></ul>
  • <del id="w48us"></del>
    <ul id="w48us"></ul>
  • 基于混合TCP-UDP的HTTP協議實現方法

    時間:2024-08-04 22:36:47 理工畢業論文 我要投稿
    • 相關推薦

    基于混合TCP-UDP的HTTP協議實現方法

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

    引 言

      超文本傳輸協議(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請求,同時啟動超時定時器。

      當服務器處理客戶端發來的請求時,它可以從以下兩點做出選擇:

    基于混合TCP-UDP的HTTP協議實現方法

    【基于混合TCP-UDP的HTTP協議實現方法】相關文章:

    基于MapObjects控件的鷹眼圖實現方法03-07

    基于Monte Carlo方法的通信仿真實現及應用研究03-30

    基于CPLD的RS485通信實現方法研究03-07

    基于圖像的OMR技術的實現03-07

    高等教育基于網絡的創造性學習的優勢及實現方法03-27

    基于SIP協議的forking功能的研究和實現03-21

    混合動力汽車混合度設計方法研究03-07

    基于PQRM的PACS系統設計與實現03-07

    基于XMLSchema的元數據方案實現03-21

    主站蜘蛛池模板: 亚洲一区精品中文字幕| 欧美精品v国产精品v日韩精品| 久久91精品久久91综合| 国产精品久久久久久影院| 午夜精品美女写真福利| 国产亚洲精品成人a v小说| 四虎国产精品永久在线看| 老司机午夜精品视频资源| 99热精品在线观看| 国产成人精品久久亚洲| 日韩精品成人亚洲专区| 久久精品国产清高在天天线| 999国内精品永久免费观看| 国产成人精品久久| 亚洲精品乱码久久久久久自慰| 岛国精品一区免费视频在线观看| 日本一区二区三区精品中文字幕| 久久久久久极精品久久久| 久久成人国产精品| 国产精品福利在线观看免费不卡 | 国产精品视频a播放| 国产精品夜色视频一级区| 一本久久a久久精品亚洲| 国产精品一区二区不卡| 久久久精品久久久久久| 福利姬在线精品观看| 欧美久久久久久午夜精品| 国产人成精品午夜在线观看| 亚洲精品一二区| 亚洲韩国精品无码一区二区三区| 久久国产精品久久久| 欧美精品色婷婷五月综合| 91精品国产乱码久久久久久| 欧美成人精品欧美一级乱黄一区二区精品在线 | 精品视频一区二区三区在线观看| 久久精品亚洲男人的天堂| 国产精品原创巨作av女教师| 免费短视频软件精品一区二区| 99久久久精品| 亚洲精品~无码抽插| 国产亚洲精品无码专区|