• <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>
            隨筆-380  評(píng)論-37  文章-0  trackbacks-0

            Problem:

            • 1 client 1 server, connected with non-block tcp socket. Linux 2.6.*+.
            • Client 寫入大概 3k 數(shù)據(jù)到 socket。
            • Write()正確返回實(shí)際寫入字節(jié)數(shù)。
            • Server 什么也收不到。

            Causes:

            • 發(fā)送端 MTU稍大于路由器上的MTU設(shè)置
            • 通知發(fā)送端需要拆包的ICMP在某處被殺掉了
            • 發(fā)送端不停的重發(fā)包

            設(shè)置了DF標(biāo)志的ip包當(dāng)遇到路由器的MTU比包小的時(shí)候,不會(huì)被路由器拆包。而路由器發(fā)送icmp消息到發(fā)送端,通知它應(yīng)該拆包。

            但icmp消息被防火墻攔截下來(lái)。

            環(huán)境和現(xiàn)象:
            這個(gè)例子中,MTU在client和server都是1500.

            dump出來(lái)的包如下:

            客戶端看到的:
            發(fā)送了2個(gè)包,后1個(gè)包成功,第1個(gè)過(guò)大而不停的被發(fā)送:

            17:23:06.933574 IP (tos 0×0, ttl 64, id 57558, offset 0, flags [DF], proto: TCP (6), length: 1500) 10.54.40.43.43145 > 10.29.14.74.http: ., cksum 0×5096 (incorrect (-> 0×5c4e), 0:1448(1448) ack 1 win 46

            17:23:06.933580 IP (tos 0×0, ttl 64, id 57559, offset 0, flags [DF], proto: TCP (6), length: 730) 10.54.40.43.43145 > 10.29.14.74.http: P, cksum 0×4d94 (incorrect (-> 0×3933), 1448:2126(678) ack 1 win 46

            17:23:07.167049 IP (tos 0×0, ttl 64, id 57560, offset 0, flags [DF], proto: TCP (6), length: 1500) 10.54.40.43.43145 > 10.29.14.74.http: ., cksum 0×5096 (incorrect (-> 0×5b5b), 0:1448(1448) ack 1 win 46

            17:23:07.634922 IP (tos 0×0, ttl 64, id 57561, offset 0, flags [DF], proto: TCP (6), length: 1500) 10.54.40.43.43145 > 10.29.14.74.http: ., cksum 0×5096 (incorrect (-> 0×5987), 0:1448(1448) ack 1 win 46

            接受端看到的:
            只有730大小的包接受成功

            17:23:08.605622 IP (tos 0×0, ttl 59, id 57559, offset 0, flags [DF], proto: TCP (6), length: 730) 202.108.3.204.43145 > 10.29.14.74.http: P, cksum 0×9d5b (correct), 1448:2126(678) ack 1 win 46

            解決方法:
            調(diào)整發(fā)送端機(jī)器的配置:(任選1個(gè))

            在網(wǎng)絡(luò)層上:
            Decrease mtu on network adapter:

            ifconfig eth* mtu 1400

            操作系統(tǒng)配置:
            Clear the default ‘MTU discovery’ flag with sysctl:

            net.ipv4.ip_no_pmtu_disc = 1

            或在應(yīng)用程序里:
            Set socket option ‘IP_MTU_DISCOVER’ with setsockopt(2) to clear ‘DF’ flag of IP package.

            Reference:

            1. DF flag of IP package Header
            2. Internet Control Message Protocol
            3. IP fragmentation
            4. MTU or Maximum transmission unit
            5. IP programming
            6. Path MTU Discovery
            7. sysctl

            Thanks:

            esx kobe steve

            來(lái)自:http://blog.developers.api.sina.com.cn/?p=672
            原文:http://drdr-xp-tech.blogspot.com/2009/04/black-hole-socket-problem.html

            posted on 2010-01-28 18:47 小王 閱讀(5313) 評(píng)論(1)  編輯 收藏 引用 所屬分類: 網(wǎng)絡(luò)通訊

            評(píng)論:
            # re: Socket程序開(kāi)發(fā),發(fā)送端寫入數(shù)據(jù)成功,接收端收不到數(shù)據(jù)的現(xiàn)象分析 2012-11-20 14:28 | 歲月漫步
            有點(diǎn)看不懂啊  回復(fù)  更多評(píng)論
              
            av无码久久久久不卡免费网站| 嫩草影院久久99| 要久久爱在线免费观看| 97久久婷婷五月综合色d啪蜜芽| 97精品依人久久久大香线蕉97| 久久精品国产第一区二区三区| 浪潮AV色综合久久天堂| 国产99久久久久久免费看| 亚洲国产成人精品女人久久久 | 国产精品成人久久久| 久久久无码精品亚洲日韩蜜臀浪潮| 久久精品成人免费网站| 日本五月天婷久久网站| 国内精品伊人久久久久影院对白 | 久久精品国产亚洲77777| 久久强奷乱码老熟女| 久久人人爽人人爽人人AV| 国产毛片久久久久久国产毛片| 99久久精品免费看国产一区二区三区| 久久婷婷国产麻豆91天堂| 亚洲人成电影网站久久| 欧美激情精品久久久久| 久久久国产精品亚洲一区| 伊人伊成久久人综合网777| 99久久精品国产一区二区蜜芽| 精品多毛少妇人妻AV免费久久 | 久久国产精品无码一区二区三区 | 久久人人爽人人人人爽AV| 一级做a爰片久久毛片人呢| 久久精品www人人爽人人| 国产毛片欧美毛片久久久| 无码人妻久久一区二区三区蜜桃 | 狠狠久久亚洲欧美专区| 久久综合久久自在自线精品自| 国产精品久久婷婷六月丁香| 久久人人超碰精品CAOPOREN | 成人国内精品久久久久影院VR| 狠狠色丁香久久婷婷综| 91精品国产高清久久久久久io| 久久国产精品无码HDAV| 精品国产乱码久久久久久1区2区 |