• <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 閱讀(5306) 評論(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 難道也是 動態改變大小?  回復  更多評論   

            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            導航

            統計

            公告

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

            常用鏈接

            留言簿(4)

            隨筆分類

            隨筆檔案

            文章檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            婷婷久久香蕉五月综合加勒比| 亚洲AV日韩精品久久久久久| 久久久久99精品成人片三人毛片| 999久久久国产精品| 国产精品一区二区久久精品涩爱| av色综合久久天堂av色综合在| 久久99久久99精品免视看动漫| 一本久久a久久精品综合夜夜| 婷婷久久精品国产| 99久久无色码中文字幕| 日韩精品无码久久一区二区三| 亚洲狠狠婷婷综合久久蜜芽| 国产福利电影一区二区三区久久久久成人精品综合 | 亚洲va久久久噜噜噜久久狠狠 | 国产美女亚洲精品久久久综合| 香蕉久久一区二区不卡无毒影院| 国产精品久久婷婷六月丁香| 久久国产精品免费一区二区三区| 中文字幕无码久久久| 国产成人香蕉久久久久| 久久精品国产亚洲77777| 中文字幕久久亚洲一区| 韩国三级中文字幕hd久久精品| 99精品国产99久久久久久97| 午夜精品久久久内射近拍高清| 久久免费精品视频| 日本强好片久久久久久AAA | 狠狠色噜噜狠狠狠狠狠色综合久久| 久久国产热这里只有精品| 成人综合伊人五月婷久久| 久久香综合精品久久伊人| 亚洲欧洲久久久精品| 久久精品中文字幕第23页| 国产激情久久久久影院老熟女| 99久久精品国产免看国产一区| 久久99热只有频精品8| 999久久久免费精品国产| 久久免费视频观看| segui久久国产精品| 久久久无码精品亚洲日韩软件| 精品乱码久久久久久夜夜嗨 |