• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            isware

            [轉(zhuǎn)]tcp不能保證數(shù)據(jù)傳輸?shù)娜f無一失

              ■tcp認(rèn)識(shí)的誤區(qū)


              應(yīng)用開發(fā)人員常常遇到這樣的困惑:為什么用tcp寫的應(yīng)用還會(huì)出現(xiàn)數(shù)據(jù)丟失呢?很多人都以為tcp 協(xié)議可以確保數(shù)據(jù)的傳輸,但事實(shí)上沒有任何一種協(xié)議可以做到這一點(diǎn)。tcp所能做只是傳輸數(shù)據(jù),如果失敗了,它會(huì)通知你,但它無法告訴你有多少數(shù)據(jù)沒有被正確傳送。

              tcp 協(xié)議中的應(yīng)答機(jī)制使得發(fā)送方的tcp棧確保接收方tcp棧收到了數(shù)據(jù)。

              tcp包頭包括32位的順序碼和應(yīng)答碼,順序碼是在連接建立時(shí)隨機(jī)產(chǎn)生的,并隨著傳輸?shù)淖止?jié)數(shù)遞增。當(dāng)數(shù)據(jù)被接收時(shí),接收方的tcp棧會(huì)給發(fā)送方發(fā)送應(yīng)答碼, 如果發(fā)送方?jīng)]收到應(yīng)答碼, 它就會(huì)重發(fā)該數(shù)據(jù)。發(fā)方和收方的順序碼是各自獨(dú)立的。


              ■tcp是一個(gè)窗口式的協(xié)議


              tcp是一個(gè)窗口式的協(xié)議。tcp包頭數(shù)據(jù)中也包含窗口的大小,它告訴遠(yuǎn)端再傳多少數(shù)據(jù)后就必須停止。窗口大小實(shí)際上就是緩存區(qū)的大小,當(dāng)緩沖區(qū)滿的 時(shí)候,窗口就會(huì)關(guān)閉。當(dāng)發(fā)送方收到的應(yīng)答中窗口大小為零時(shí),它會(huì)自動(dòng)停止發(fā)送。發(fā)送方會(huì)記住自己發(fā)送了多少數(shù)據(jù),即使沒有收到窗口大小為零的應(yīng)答,它也不 會(huì)發(fā)送大于緩沖區(qū)的數(shù)據(jù)。

              通常接收方應(yīng)答這些數(shù)據(jù)時(shí),應(yīng)用會(huì)不斷讀數(shù)據(jù),這樣窗口就經(jīng)常處于開放狀態(tài)。

              導(dǎo)致窗口關(guān)閉的最常見原因是i/o阻塞。這通常是臨時(shí)性的,一般i/o通暢后,緩存(窗口)會(huì)自動(dòng)開放。第二個(gè)原因就是應(yīng)用代碼中的bug使得接收應(yīng)用程序忽略了連接,重要的不在于接收方讀沒讀數(shù)據(jù),而在于發(fā)送方在收到應(yīng)答后是否正確地發(fā)送了數(shù)據(jù)。


              ■tcp的緩存機(jī)制


              發(fā)送tcp棧在收到應(yīng)答前必須對(duì)數(shù)據(jù)進(jìn)行緩存,而應(yīng)用程序在調(diào)用tcp棧發(fā)送數(shù)據(jù)時(shí)并不知道數(shù)據(jù)已經(jīng)在緩存區(qū)了。只要發(fā)送tcp棧還有空間,它就會(huì)接收來自應(yīng)用的數(shù)據(jù)并進(jìn)行緩存。一旦緩存滿了導(dǎo)致應(yīng)用程序無法繼續(xù)發(fā)送,它就會(huì)認(rèn)為有問題了。

              如果問題是發(fā)送tcp棧沒有收到應(yīng)答,那么它會(huì)重發(fā),等待應(yīng)答的時(shí)間會(huì)越來越長(zhǎng),直至最終放棄并重新建立連接。重新連接后本地緩存會(huì)清空,并通知應(yīng)用 程序。但是至于有多少數(shù)據(jù)在緩存區(qū)沒有收到應(yīng)答仍不得而知。本地tcp棧無法知道遠(yuǎn)端是否收到了數(shù)據(jù),也不知道是否收到了遠(yuǎn)端應(yīng)答。

              如果問題是窗口關(guān)閉了,那么發(fā)送tcp棧會(huì)定期發(fā)送窗口探針來探測(cè)接收方窗口是否開放。接收tcp棧必須應(yīng)答窗口探針包。應(yīng)答包含當(dāng)前窗口大小。在收到探針應(yīng)答前,發(fā)送tcp棧只能等待。


              ■路在何方


              也許有人會(huì)說:既然如此,為何還要用tcp協(xié)議?如果應(yīng)用中必須包括數(shù)據(jù)標(biāo)識(shí)和應(yīng)答,為什么不用udp協(xié)議?tcp的優(yōu)勢(shì)在于你不必?fù)?dān)心數(shù)據(jù)傳輸機(jī) 制,如果數(shù)據(jù)包在傳輸過程中由于路由的關(guān)系,其到達(dá)順序被打亂,接收tcp棧會(huì)將這些數(shù)據(jù)包按其順序碼重新排列,從而保證了數(shù)據(jù)的正確性。而如果采用 udp的話,則應(yīng)用中必須設(shè)法提供所有這些機(jī)制。

              如果發(fā)生了傳輸線路中斷,僅有應(yīng)用層的應(yīng)答是不夠的。按照應(yīng)用層應(yīng)答機(jī)制,在重建連接后,發(fā)送方會(huì)重發(fā)那些沒有收到應(yīng)答的數(shù)據(jù)包,但是有可能雖然這些 應(yīng)答丟了,可數(shù)據(jù)卻到達(dá)了,并已用于應(yīng)用程序。為了防止這種情況,發(fā)送應(yīng)用方需保存沒被接收應(yīng)用應(yīng)答的數(shù)據(jù)段的標(biāo)識(shí) ,接收應(yīng)用方也應(yīng)保存自己已接收和處理過的數(shù)據(jù)段的標(biāo)識(shí)。當(dāng)重建連接時(shí),發(fā)送方將發(fā)送第一個(gè)沒有收到應(yīng)答的數(shù)據(jù)段,或者詢問接收方最后發(fā)出的應(yīng)答進(jìn)行確 認(rèn)。為了確保數(shù)據(jù)傳輸?shù)臒o誤, 應(yīng)該保證接收應(yīng)用方保存的數(shù)據(jù)段標(biāo)識(shí)在應(yīng)用重啟或系統(tǒng)癱瘓時(shí)仍能安然無恙。

              盡管tcp協(xié)議十分優(yōu)秀,但它并不能確保數(shù)據(jù)數(shù)據(jù)傳輸萬無一失。

            posted on 2011-07-21 15:08 艾斯維亞 閱讀(2158) 評(píng)論(0)  編輯 收藏 引用


            只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            91精品久久久久久无码| 青青久久精品国产免费看| 久久综合五月丁香久久激情| 人人狠狠综合久久亚洲88| 超级碰久久免费公开视频| 欧美国产精品久久高清| 伊人久久大香线蕉亚洲| 国产精品一区二区久久不卡| 国产精品女同一区二区久久| 色婷婷久久综合中文久久一本| 手机看片久久高清国产日韩| 少妇高潮惨叫久久久久久| 国产免费久久精品99久久| 99久久精品免费看国产一区二区三区| 99久久er这里只有精品18| 色天使久久综合网天天| 国产精品一区二区久久精品无码 | 久久亚洲日韩看片无码| 综合久久精品色| 一本色道久久HEZYO无码| 欧美日韩精品久久久久| 久久久中文字幕日本| 久久夜色撩人精品国产| 久久亚洲国产中v天仙www | 国内高清久久久久久| 婷婷久久五月天| 99久久成人国产精品免费| 国产精品久久久久影院嫩草| 久久99精品国产99久久6男男| 午夜欧美精品久久久久久久| 99久久99久久久精品齐齐| 久久久久久极精品久久久| 久久精品国产精品亚洲精品 | 一本久道久久综合狠狠爱| 国产精品99久久99久久久| 中文国产成人精品久久亚洲精品AⅤ无码精品 | 中文字幕久久波多野结衣av| 久久精品国产91久久麻豆自制| 久久综合偷偷噜噜噜色| 久久精品国产亚洲AV不卡| 久久综合久久久|