• <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滑動(dòng)窗口易錯(cuò)處,后來者戒之!

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

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

            評(píng)論

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

            滑動(dòng)窗口?這么翻的中文有點(diǎn)怪異吧。recvbuf和sendbuf不就是“接收緩沖區(qū)”和"發(fā)送緩沖區(qū)"么?  回復(fù)  更多評(píng)論   

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

            呵呵,滑動(dòng)窗口英文名稱是“sliding-window”是TCP協(xié)議的一部分,因其大小根據(jù)對(duì)方的ACK來動(dòng)態(tài)調(diào)整,故稱之為滑動(dòng)窗口,這個(gè)稱呼應(yīng)該是很貼切很形象的,并且目前幾乎所有關(guān)于網(wǎng)絡(luò)的書籍都會(huì)翻譯成滑動(dòng)窗口。recvbuf和sendbuf是為了說明程序中設(shè)置的buffer大小和滑動(dòng)窗口的關(guān)系我特意加上去的,不然估計(jì)有不少人像我之前一個(gè)同事一樣只知道設(shè)置接收緩沖區(qū)和發(fā)送緩沖區(qū),而不知道它們真正執(zhí)行的過程 @kaka  回復(fù)  更多評(píng)論   

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

            受教了~~ @peakflys  回復(fù)  更多評(píng)論   

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

            不錯(cuò) 確實(shí)如此  回復(fù)  更多評(píng)論   

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

            "僅保證對(duì)方TCP接收緩沖收到數(shù)據(jù)了,但不保證對(duì)方應(yīng)用程序取到數(shù)據(jù)了".
            ack可以保證app接收到了data. 如果app接收tcp的數(shù)據(jù)之前退出, tcp會(huì)恢復(fù)rst, 而非ack, 從而保證server明白, app沒有收到data.  回復(fù)  更多評(píng)論   

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

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

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

            “一個(gè)socket有兩個(gè)滑動(dòng)窗口(一個(gè)sendbuf、一個(gè)recvbuf),兩個(gè)窗口的大小是通過setsockopt函數(shù)設(shè)置的”
            滑動(dòng)窗口和 sendbuf/recvbuf 到底是不是一回事?滑動(dòng)窗口是動(dòng)態(tài)改變大小的,sendbuf/recv/buf 難道也是 動(dòng)態(tài)改變大???  回復(fù)  更多評(píng)論   

            <2015年2月>
            25262728293031
            1234567
            891011121314
            15161718192021
            22232425262728
            1234567

            導(dǎo)航

            統(tǒng)計(jì)

            公告

            人不淡定的時(shí)候,就愛表現(xiàn)出來,敲代碼如此,偶爾的靈感亦如此……

            常用鏈接

            留言簿(4)

            隨筆分類

            隨筆檔案

            文章檔案

            搜索

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

            久久久久99这里有精品10| 狠狠人妻久久久久久综合蜜桃| 欧美午夜A∨大片久久| 久久精品国产亚洲Aⅴ香蕉| 久久人妻少妇嫩草AV蜜桃| 精品国产乱码久久久久软件| 狠狠88综合久久久久综合网| 精品久久国产一区二区三区香蕉| 久久免费看黄a级毛片| 久久99国产精品久久| 亚洲AV伊人久久青青草原| 久久99精品综合国产首页| 久久精品国产亚洲Aⅴ香蕉| 国产精品无码久久久久久| 亚洲国产天堂久久综合| 国产精品久久久久久久 | 中文无码久久精品| 97久久国产亚洲精品超碰热| 欧美久久久久久精选9999| 精品国产乱码久久久久久郑州公司| 国产免费久久精品99久久| 99久久99久久| 久久亚洲私人国产精品vA| 日本久久中文字幕| 久久久WWW免费人成精品| 青草影院天堂男人久久| 久久婷婷五月综合色高清| 久久99热这里只频精品6| 久久久久无码专区亚洲av| 国产精品久久久99| 久久精品亚洲乱码伦伦中文| 91精品国产综合久久精品| 久久丫精品国产亚洲av不卡 | 精品久久亚洲中文无码| 久久久久久一区国产精品| 国产福利电影一区二区三区久久久久成人精品综合 | 思思久久99热只有频精品66| 久久综合成人网| 亚洲精品美女久久久久99小说| 久久久久国产精品三级网| 久久久久女教师免费一区|