• <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),開心的工作
            簡(jiǎn)單、開放、平等的公司文化;尊重個(gè)性、自由與個(gè)人價(jià)值;
            posts - 1098, comments - 335, trackbacks - 0, articles - 1
              C++博客 :: 首頁(yè) :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理

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

            Posted on 2009-08-09 15:24 S.l.e!ep.¢% 閱讀(4977) 評(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)用層的包是正確無(wú)誤的包
            如果包無(wú)應(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次后仍無(wú)響應(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)一些(雖然即使這樣也并非萬(wàn)無(wú)一失)。
            欧美性猛交xxxx免费看久久久| 久久人妻少妇嫩草AV无码专区| 久久国产精品二国产精品| 久久精品国产精品亚洲艾草网美妙| 99久久国产免费福利| 久久久久久久综合日本| yy6080久久| 久久久久久综合一区中文字幕| 国产AⅤ精品一区二区三区久久 | 久久99精品久久久久久水蜜桃| 久久久久无码精品国产app| 久久亚洲国产精品成人AV秋霞| 亚洲色大成网站www久久九| 国产午夜精品理论片久久影视| 精品99久久aaa一级毛片| 久久精品免费一区二区| 久久国产精品国产自线拍免费| 狠狠人妻久久久久久综合蜜桃| 亚洲熟妇无码另类久久久| 成人精品一区二区久久| 亚洲人成精品久久久久| 99久久www免费人成精品| 久久精品人妻中文系列| 国产真实乱对白精彩久久| 蜜臀av性久久久久蜜臀aⅴ | 久久久久亚洲AV无码网站| 国产呻吟久久久久久久92| 中文字幕无码精品亚洲资源网久久| 日本免费久久久久久久网站| 成人综合久久精品色婷婷| 精品久久久久久无码中文字幕| 久久人人爽人人爽人人AV| 亚洲精品tv久久久久| 99久久精品免费看国产免费| 亚洲精品午夜国产VA久久成人| 久久久精品波多野结衣| 青青国产成人久久91网| 久久精品中文无码资源站| 久久精品极品盛宴观看| 久久久久国产精品麻豆AR影院| 久久久精品一区二区三区|