• <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)一些(雖然即使這樣也并非萬無一失)。
            久久精品亚洲男人的天堂| 久久天天躁夜夜躁狠狠躁2022| 亚洲精品乱码久久久久久按摩 | 久久中文娱乐网| 一本大道加勒比久久综合| 久久久久综合中文字幕| 日韩精品无码久久久久久| 国产2021久久精品| 欧美午夜精品久久久久免费视 | 亚洲性久久久影院| 久久久久久久99精品免费观看| 久久午夜综合久久| 精品久久久久久综合日本| 欧美激情一区二区久久久| 亚洲精品高清久久| 亚洲成色www久久网站夜月| 久久久久这里只有精品 | 亚洲精品第一综合99久久| 亚洲一本综合久久| 丁香五月网久久综合| 久久精品日日躁夜夜躁欧美| 久久久久一本毛久久久| 91精品国产色综久久 | 日本精品久久久久久久久免费| 久久91亚洲人成电影网站| 午夜精品久久久久久毛片| 久久精品国产亚洲AV蜜臀色欲| 色综合久久88色综合天天 | 久久播电影网| 无码任你躁久久久久久| 久久伊人影视| 亚洲精品国产自在久久| 日韩久久无码免费毛片软件| 久久人人爽人人爽人人片AV东京热| 51久久夜色精品国产| 国产精品禁18久久久夂久| 久久综合九色综合网站| 99久久人妻无码精品系列| 国产成人无码久久久精品一| 久久美女人爽女人爽| 久久狠狠一本精品综合网|