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

            TCP滑動窗口易錯處,后來者戒之!

                前段時間研究分布式時寫了一個可擴展的服務器組程序,服務器組之間通信時老是達不到想要的性能。后來抓包排查,原來是TCP滑動窗口引起的問題,本來是很基礎的東西,奈何當初沒有太在意,導致錯誤的產生,現在詳細寫出來,忘不太清楚者警惕!
               滑動窗口的基本情況我有必要廢話一下。TCP通信為了保證可靠性,每次發送的數據都需要得到對方的ACK才確認對方收到了(僅保證對方TCP接收緩沖收到數據了,但不保證對方應用程序取到數據了),這時如果每次發送一次就要停下來等著對方的ACK消息,顯然是一種極大的資源浪費和低下的效率,這時就有了滑動窗口的出現。
            發送方的滑動窗口維持著當前發送的幀序號,已發出去幀的計時器,接收方當前的窗口大小(由接收方ACK通知,大體等于接收緩沖大小-未處理的消息包),接收方滑動窗口保存的有已接收的幀信息、期待的下一幀的幀號等,至于滑動窗口的具體工作原理這里就不說了。
               一個socket有兩個滑動窗口(一個sendbuf、一個recvbuf),兩個窗口的大小是通過setsockopt函數設置的,現在問題就出在這里,通過抓包顯示,設置的窗口大小沒有生效,最后排查發現setsockopt函數是后來加上的,寫到了listen函數的后面,這樣每次accept出的socket并沒有繼承得到主socket設置的窗口大小,無語啊……
               解決辦法:setsockopt函數提前到listen函數之前,這樣在服務器程序啟動監聽前recvbuf就已經有了,accept后的鏈接得到的就是recvbuf了,啟動程序運行,抓包顯示窗口已經是指定的大小了。
               網絡編程其實很簡單,任何人都可以寫出一套自己的服務器框架,但是細節決定成敗,性能的高低有時候就是幾個小細節決定的(當然這里說的這個問題是個編程錯誤,不屬于可優化的細節問題)

            posted on 2012-11-29 14:17 peakflys 閱讀(5307) 評論(7)  編輯 收藏 引用 所屬分類: 服務器

            評論

            # re: TCP滑動窗口易錯處,后來者戒之![未登錄] 2012-11-29 16:35 kaka

            滑動窗口?這么翻的中文有點怪異吧。recvbuf和sendbuf不就是“接收緩沖區”和"發送緩沖區"么?  回復  更多評論   

            # re: TCP滑動窗口易錯處,后來者戒之! 2012-11-30 09:48 peakflys

            呵呵,滑動窗口英文名稱是“sliding-window”是TCP協議的一部分,因其大小根據對方的ACK來動態調整,故稱之為滑動窗口,這個稱呼應該是很貼切很形象的,并且目前幾乎所有關于網絡的書籍都會翻譯成滑動窗口。recvbuf和sendbuf是為了說明程序中設置的buffer大小和滑動窗口的關系我特意加上去的,不然估計有不少人像我之前一個同事一樣只知道設置接收緩沖區和發送緩沖區,而不知道它們真正執行的過程 @kaka  回復  更多評論   

            # re: TCP滑動窗口易錯處,后來者戒之![未登錄] 2012-11-30 10:35 kaka

            受教了~~ @peakflys  回復  更多評論   

            # re: TCP滑動窗口易錯處,后來者戒之![未登錄] 2012-12-03 13:26 春秋十二月

            不錯 確實如此  回復  更多評論   

            # re: TCP滑動窗口易錯處,后來者戒之![未登錄] 2012-12-24 04:41 Sunny

            "僅保證對方TCP接收緩沖收到數據了,但不保證對方應用程序取到數據了".
            ack可以保證app接收到了data. 如果app接收tcp的數據之前退出, tcp會恢復rst, 而非ack, 從而保證server明白, app沒有收到data.  回復  更多評論   

            # re: TCP滑動窗口易錯處,后來者戒之! 2012-12-24 15:32 peakflys

            ack是TCP機制提供的一種接收反饋,對端接收發送的數據包會自動反饋回一個ack,這個過程上層app是沒有參與的,所以單從一個ack來看是不知道對端app有沒有取到剛才傳送的數據,但是也有一個辦法可以大體上猜到對端的使用,就是根據多個ack反饋,由窗口大小的改變來揣測。舉個例子,對端窗口大小為65530個字節,我現在傳過去10個字節,對端回復一個ack,但是這個ack不代表剛才傳的10個字節對端app已經取到,但是如果我現在再傳10個字節,如果對端回復的ack中window大小是65520,這時我可以猜出剛才傳的數據已經被對端app取到了,這也就是原文中的意思:對端反饋回來ack,只代表對端接收到了數據,不代表上層應用程序取到了數據。@Sunny
              回復  更多評論   

            # re: TCP滑動窗口易錯處,后來者戒之! 2013-12-01 14:29 Marvin

            “一個socket有兩個滑動窗口(一個sendbuf、一個recvbuf),兩個窗口的大小是通過setsockopt函數設置的”
            滑動窗口和 sendbuf/recvbuf 到底是不是一回事?滑動窗口是動態改變大小的,sendbuf/recv/buf 難道也是 動態改變大小?  回復  更多評論   

            <2012年7月>
            24252627282930
            1234567
            891011121314
            15161718192021
            22232425262728
            2930311234

            導航

            統計

            公告

            人不淡定的時候,就愛表現出來,敲代碼如此,偶爾的靈感亦如此……

            常用鏈接

            留言簿(4)

            隨筆分類

            隨筆檔案

            文章檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            欧美性大战久久久久久| 国产精品久久久久久福利漫画| 久久夜色tv网站| 久久久WWW成人免费精品| 中文字幕久久亚洲一区| 久久亚洲精品中文字幕| 国产精品久久久久久吹潮| 香蕉久久夜色精品国产小说| 国产福利电影一区二区三区久久久久成人精品综合 | 亚洲国产欧美国产综合久久 | 草草久久久无码国产专区| 日韩精品久久久久久久电影| 无码人妻少妇久久中文字幕蜜桃| 91精品国产综合久久香蕉 | 欧美va久久久噜噜噜久久| segui久久国产精品| 国内精品久久久久影院免费| 午夜精品久久久久久影视riav| 免费观看久久精彩视频| 无码国内精品久久人妻蜜桃| 午夜视频久久久久一区| 国产激情久久久久影院| 久久久久亚洲av成人无码电影 | 日韩人妻无码精品久久免费一| 日韩精品无码久久一区二区三| 久久精品亚洲精品国产色婷| 国产69精品久久久久APP下载| 久久精品国产亚洲av瑜伽| 99久久国产宗和精品1上映| 国产精品久久一区二区三区 | 久久久久久午夜成人影院| 一本一道久久综合狠狠老| 久久亚洲中文字幕精品有坂深雪 | 久久无码人妻一区二区三区| 久久久青草青青亚洲国产免观| 久久精品国产亚洲av麻豆色欲| 精品永久久福利一区二区| 久久久久国产精品嫩草影院| 久久精品国产亚洲av麻豆蜜芽 | 久久天堂电影网| 久久影院综合精品|