1. <tt id="5hhch"><source id="5hhch"></source></tt>
    1. <xmp id="5hhch"></xmp>

  2. <xmp id="5hhch"><rt id="5hhch"></rt></xmp>

    <rp id="5hhch"></rp>
        <dfn id="5hhch"></dfn>

      1. 基于混合TCP-UDP的HTTP協(xié)議實(shí)現(xiàn)方法

        時(shí)間:2024-08-04 22:36:47 理工畢業(yè)論文 我要投稿
        • 相關(guān)推薦

        基于混合TCP-UDP的HTTP協(xié)議實(shí)現(xiàn)方法

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

        引 言

          超文本傳輸協(xié)議(HTTP)是目前通過(guò)Internet進(jìn)行信息交換最主要的方式。HTTP協(xié)議是建立在請(qǐng)求/響應(yīng)(request/response)模型上的。首先由客戶(hù)建立一條與服務(wù)器的TCP鏈接,并發(fā)送一個(gè)請(qǐng)求到服務(wù)器,請(qǐng)求中包含請(qǐng)求方法、URI、協(xié)議版本以及相關(guān)的MIME(Multipurpose Internet Mail Extensions)樣式的消息。服務(wù)器響應(yīng)一個(gè)狀態(tài)行,包含消息的協(xié)議版本、一個(gè)成功和失敗碼以及相關(guān)的MIME式樣的消息(包含服務(wù)器的信息、資源實(shí)體的信息和可能的資源內(nèi)容)。圖1給出了HTTP協(xié)議實(shí)現(xiàn)的一個(gè)簡(jiǎn)單模型。HTTP/1.0[3]為每一次HTTP的請(qǐng)求/響應(yīng)建立一條新的TCP鏈接,因此一個(gè)包含HTML內(nèi)容和圖片的頁(yè)面將需要建立多次的短期的TCP鏈接。一次TCP鏈接的建立將需要3次握手。另外,為了獲得適當(dāng)?shù)膫鬏斔俣龋瑒t需要TCP花費(fèi)額外的回路鏈接時(shí)間(RTT)。每一次鏈接的建立需要這種經(jīng)常性的開(kāi)銷(xiāo),而其并不帶有實(shí)際有用的數(shù)據(jù),只是保證鏈接的可靠性,因此HTTP/1.1[4]提出了可持續(xù)鏈接的實(shí)現(xiàn)方法。HTTP/1.1將只建立一次TCP的鏈接而重復(fù)地使用它傳輸一系列的請(qǐng)求/響應(yīng)消息,因此減少了鏈接建立的次數(shù)和經(jīng)常性的鏈接開(kāi)銷(xiāo)。

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

          無(wú)線掌上設(shè)備PDA的應(yīng)用(如瀏覽器)[5]特點(diǎn)表現(xiàn)在:① 因?yàn)轫?yè)面是針對(duì)掌上設(shè)備制作的,一般在1 K~2 K字節(jié),比較;② 目前無(wú)線通信網(wǎng)絡(luò)的帶寬很窄,GSM的數(shù)據(jù)信道帶寬只有9.6 K。當(dāng)前Web頁(yè)面的訪問(wèn)大多通過(guò)HTTP協(xié)議,并使用TCP作為下層的傳輸控制協(xié)議。但不幸的是,TCP并不適合短會(huì)話的應(yīng)用情況,不同于現(xiàn)在采用的使用單一TCP傳輸協(xié)議進(jìn)行數(shù)據(jù)傳輸?shù)姆绞。本文提出了采用?dòng)態(tài)選擇傳輸層協(xié)議(TCP、UDP)的方法來(lái)改善取回頁(yè)面的延遲、網(wǎng)絡(luò)擁塞以及服務(wù)器的負(fù)荷。

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

        1 背 景

          HTTP是一個(gè)請(qǐng)求/響應(yīng)協(xié)議,客戶(hù)端的應(yīng)用程序通過(guò)提供一個(gè)URL可以從服務(wù)器上得到所需的數(shù)據(jù)。HTTP可以用來(lái)訪問(wèn)各種不同類(lèi)型的資源,其中包括文本、圖形、影音、可執(zhí)行文件、數(shù)據(jù)庫(kù)查詢(xún)結(jié)果等等。

          圖2給出了在客戶(hù)端發(fā)起HTTP GET請(qǐng)求后,在客戶(hù)端和服務(wù)器之間進(jìn)行數(shù)據(jù)包交換的示意。圖中只有兩個(gè)數(shù)據(jù)包是有用的(即攜帶了數(shù)據(jù)):一個(gè)是HTTP GET請(qǐng)求,另一個(gè)是HTTP的響應(yīng)。其它的都是TCP用來(lái)進(jìn)行握手操作的數(shù)據(jù)包。為了減輕Web服務(wù)器的負(fù)荷,經(jīng)常采用重定向機(jī)制。這樣從服務(wù)器發(fā)來(lái)的重定向響應(yīng)報(bào)文是很短的數(shù)據(jù)包。使用TCP作為傳輸協(xié)議需要至少7個(gè)數(shù)據(jù)包,而使用UDP則只需要2個(gè)數(shù)據(jù)包就足夠了。

        2 設(shè) 計(jì)

          我們使用混合傳輸層[6]的方法即對(duì)于少量數(shù)據(jù)傳輸?shù)逆溄硬捎肬DP,而對(duì)于大量數(shù)據(jù)傳輸?shù)逆溄硬捎肨CP作為傳輸層協(xié)議。這樣對(duì)于短鏈接而言就避免了TCP經(jīng)常性的握手開(kāi)銷(xiāo),而對(duì)于長(zhǎng)鏈接則仍可獲得TCP的優(yōu)點(diǎn),如超時(shí)重傳、擁塞控制、錯(cuò)誤恢復(fù)機(jī)制等。這種方法中,客戶(hù)端首先嘗試使用UDP作為傳輸層的協(xié)議,如果對(duì)于所請(qǐng)求的URL UDP并不適合,則再次使用TCP鏈接。這種方法提供了以下保證:

        ◇ 如果初始的UDP數(shù)據(jù)包丟失,將采用TCP重新鏈接而不會(huì)受到影響。

        ◇ 如果所鏈接的服務(wù)器沒(méi)有使用混合傳輸層的實(shí)現(xiàn)機(jī)制,客戶(hù)端將使用TCP重新進(jìn)行鏈接。

          圖3給出了混合TCP、UDP的實(shí)現(xiàn)算法。一個(gè)采用混合算法的HTTP客戶(hù)端首先使用UDP作為傳輸層的協(xié)議發(fā)出HTTP GET請(qǐng)求,同時(shí)啟動(dòng)超時(shí)定時(shí)器。

          當(dāng)服務(wù)器處理客戶(hù)端發(fā)來(lái)的請(qǐng)求時(shí),它可以從以下兩點(diǎn)做出選擇:

        基于混合TCP-UDP的HTTP協(xié)議實(shí)現(xiàn)方法

        【基于混合TCP-UDP的HTTP協(xié)議實(shí)現(xiàn)方法】相關(guān)文章:

        基于MapObjects控件的鷹眼圖實(shí)現(xiàn)方法03-07

        基于Monte Carlo方法的通信仿真實(shí)現(xiàn)及應(yīng)用研究03-30

        基于CPLD的RS485通信實(shí)現(xiàn)方法研究03-07

        基于圖像的OMR技術(shù)的實(shí)現(xiàn)03-07

        高等教育基于網(wǎng)絡(luò)的創(chuàng)造性學(xué)習(xí)的優(yōu)勢(shì)及實(shí)現(xiàn)方法03-27

        基于SIP協(xié)議的forking功能的研究和實(shí)現(xiàn)03-21

        混合動(dòng)力汽車(chē)混合度設(shè)計(jì)方法研究03-07

        基于PQRM的PACS系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)03-07

        基于XMLSchema的元數(shù)據(jù)方案實(shí)現(xiàn)03-21

        国产高潮无套免费视频_久久九九兔免费精品6_99精品热6080YY久久_国产91久久久久久无码

        1. <tt id="5hhch"><source id="5hhch"></source></tt>
          1. <xmp id="5hhch"></xmp>

        2. <xmp id="5hhch"><rt id="5hhch"></rt></xmp>

          <rp id="5hhch"></rp>
              <dfn id="5hhch"></dfn>