• <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>

            S.l.e!ep.¢%

            像打了激速一樣,以四倍的速度運(yùn)轉(zhuǎn),開心的工作
            簡單、開放、平等的公司文化;尊重個(gè)性、自由與個(gè)人價(jià)值;
            posts - 1098, comments - 335, trackbacks - 0, articles - 1
              C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理

            關(guān)于TCP丟包,斷開的疑問

            Posted on 2009-08-09 15:24 S.l.e!ep.¢% 閱讀(4996) 評(píng)論(3)  編輯 收藏 引用 所屬分類: IOCP
            丟包:以前在局域網(wǎng)內(nèi)做過這樣的試驗(yàn), A機(jī)向B機(jī)不斷地發(fā) 4096Byte的TCP包, 每個(gè)包都有序號(hào), 結(jié)果有部份包B機(jī)收不到
            斷開:直接拔網(wǎng)線(存在假連接),可能要十幾分鐘后才檢測(cè)到

            從TCP的機(jī)制來看,
            TCP的下層會(huì)丟包,但經(jīng)過TCP處理后,提交到應(yīng)用層的包是正確無誤的包
            如果包無應(yīng)答,會(huì)重發(fā),理論上不可能出現(xiàn)丟包。

            至于上面的丟包實(shí)驗(yàn),那時(shí)沒細(xì)究原因,有可能是沒有檢測(cè) Send 成功(程序處理不過來的原故),但是否存在那種被路由器過濾掉而造成丟包,或其它原因造成TCP丟包的可能性?有待進(jìn)一步驗(yàn)證&找資料

            而斷開,只能通過心跳包來解決了。

            Feedback

            # re: 關(guān)于TCP丟包,斷開的疑問  回復(fù)  更多評(píng)論   

            2009-08-10 12:07 by abettor
            TCP提供可靠的連接的意義是指他盡力的提供可靠的連接,但并不到等于永遠(yuǎn)不會(huì)失敗。
            對(duì)于丟包重發(fā),TCP是有限度的,而不是不斷的重發(fā),重發(fā)了X次后仍無響應(yīng),TCP就認(rèn)為中斷了。
            對(duì)于拔網(wǎng)線這種極端的測(cè)試方式,OS一般會(huì)在某次調(diào)用send/recv/select的時(shí)候直接通知應(yīng)用層,而不是繼續(xù)愚鈍的試圖繼續(xù)保障連接。

            # re: 關(guān)于TCP丟包,斷開的疑問  回復(fù)  更多評(píng)論   

            2009-08-10 16:55 by foxriver
            樓上說的不錯(cuò)啊。拔網(wǎng)線在用輪訓(xùn)select時(shí)很容易就能檢測(cè)出來。

            還有關(guān)于丟包,send不是任何時(shí)候都可以全部發(fā)送成功的,如果window buffer填滿了,send會(huì)只發(fā)送一部分,還有在send前,最好先select一下是否可以write的標(biāo)志,這樣更安全些。

            # re: 關(guān)于TCP丟包,斷開的疑問  回復(fù)  更多評(píng)論   

            2009-08-10 17:17 by abettor
            @foxriver
            嚴(yán)重同意。
            需要補(bǔ)充的一點(diǎn)是,有時(shí)候send調(diào)用貌似完全成功,也不代表真的成功了,此時(shí)數(shù)據(jù)包只是提交給了OS的協(xié)議棧而已。很多時(shí)候,雖然socket明顯已經(jīng)斷了,app執(zhí)行send調(diào)用卻并不知道,而是在調(diào)recv的時(shí)候才發(fā)覺。
            select一下還是保險(xiǎn)一些(雖然即使這樣也并非萬無一失)。
            伊人久久大香线焦综合四虎| 精品久久久久久久国产潘金莲| 2021久久精品国产99国产精品| 国产精品久久久久久福利漫画| 国产精品午夜久久| 欧美精品九九99久久在观看| 久久人人爽人人爽人人AV| 狠狠久久综合| 久久久国产精品亚洲一区| 久久伊人精品青青草原日本| 久久国产欧美日韩精品免费| 99久久无码一区人妻| 欧美丰满熟妇BBB久久久| 成人精品一区二区久久久| 久久婷婷五月综合97色| 性高朝久久久久久久久久| 国产精品久久久久9999| 亚洲AV乱码久久精品蜜桃| 久久久国产精品| 精品人妻伦九区久久AAA片69| 91精品国产综合久久精品| 亚洲AV无码久久精品狠狠爱浪潮 | 日本三级久久网| 亚洲国产美女精品久久久久∴| 国产精品久久久久久久app| 久久久久国产一区二区| 99精品久久久久久久婷婷| 91精品国产综合久久婷婷| 国产精品久久影院| 久久精品国产久精国产思思| 一本色道久久88精品综合 | 人人狠狠综合久久亚洲高清| 青青草原综合久久大伊人导航| 91亚洲国产成人久久精品网址| 久久国产精品99国产精| 91视频国产91久久久| 久久不射电影网| 国产综合成人久久大片91| 久久高潮一级毛片免费| 久久五月精品中文字幕| 久久这里都是精品|