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

            隨筆分類

            隨筆檔案

            文章檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            精品久久久久久无码中文字幕一区 | 91精品日韩人妻无码久久不卡| 国产一级持黄大片99久久| 91久久精品视频| 久久婷婷五月综合97色| 国内精品久久久久久麻豆| 欧美亚洲国产精品久久高清| 国产成人久久精品激情| 色综合久久88色综合天天 | 久久亚洲私人国产精品vA | 怡红院日本一道日本久久 | 国产Av激情久久无码天堂| 97超级碰碰碰碰久久久久| 人妻无码αv中文字幕久久琪琪布| 精品国产91久久久久久久| 国产激情久久久久久熟女老人| 国产无套内射久久久国产| 九九精品99久久久香蕉| 尹人香蕉久久99天天拍| 久久九九久精品国产| 2022年国产精品久久久久| 亚洲第一极品精品无码久久| 日本加勒比久久精品| 亚洲综合精品香蕉久久网97| 波多野结衣中文字幕久久| 人妻精品久久无码区| 亚洲AV日韩AV天堂久久| 亚洲国产日韩综合久久精品| 亚洲AⅤ优女AV综合久久久| 久久亚洲国产精品123区| 国产女人aaa级久久久级| 精品多毛少妇人妻AV免费久久| 国产精品久久久久…| 91久久精一区二区三区大全| 久久无码人妻一区二区三区 | 国产成人精品久久亚洲高清不卡| 无码AV波多野结衣久久| 亚洲中文字幕无码一久久区| 亚洲乱码中文字幕久久孕妇黑人| 久久精品国产亚洲av麻豆图片| 久久久www免费人成精品|