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

            loop_in_codes

            低調(diào)做技術(shù)__歡迎移步我的獨(dú)立博客 codemaro.com 微博 kevinlynx

            tcp要點(diǎn)學(xué)習(xí)-數(shù)據(jù)發(fā)送一

            Author : Kevin Lynx

            1. 什么是delayed ack algorithm
               delayed ack algorithm也就是<TCP/IP詳解>中所謂的"經(jīng)受時(shí)延的確認(rèn)"(翻譯得真饒舌 = =||)。在RFC1122中提到delayed ack
               的概念:
              

              "
                  A host that is receiving a stream of TCP data segments can
                  increase efficiency 
            in both the Internet and the hosts by
                  sending fewer than one ACK (acknowledgment) segment per data
                  segment received; 
            this is known as a "delayed ACK" [TCP:5].
                
            "


               我在之前提到過,TCP在收到每一個(gè)數(shù)據(jù)包時(shí),都會(huì)發(fā)送一個(gè)ACK報(bào)文給對(duì)方,用以告訴對(duì)方"我接收到你剛才發(fā)送的數(shù)據(jù)了"。并
               且會(huì)在報(bào)文的確認(rèn)號(hào)字段中標(biāo)志希望接收到的數(shù)據(jù)包。

               但是,如你所想,如果為每一個(gè)接收到的報(bào)文都發(fā)送一個(gè)ACK報(bào)文,那將會(huì)增加網(wǎng)絡(luò)的負(fù)擔(dān)。于是,為了解決這個(gè)問題,delayed
               ack被提出。也就是說,實(shí)現(xiàn)了delayed ack的TCP,并不見得會(huì)對(duì)每一個(gè)接收到的數(shù)據(jù)包發(fā)送ACK確認(rèn)報(bào)文。

               實(shí)際情況是,TCP延遲發(fā)送這個(gè)ACK。延遲多久?<TCP/IP詳解>中說的是200ms,在RFC1122中說的則是500ms。delayed ack有時(shí)候
               還會(huì)附加到數(shù)據(jù)報(bào)文段一起發(fā)送,如果在延遲時(shí)間內(nèi)有報(bào)文段要發(fā)送的話,如果沒有,那么當(dāng)延遲時(shí)間到時(shí),就單獨(dú)發(fā)送ACK。

               在另一份文檔中,作者講到delayed ack的好處:
               a) to avoid the silly window syndrome;
               b) to allow ACKs to piggyback on a reply frame if one is ready to go when the stack decides to do the ACK;
               c) to allow the stack to send one ACK for several frames, if those frames arrive within the delay period.

               a) 所謂的糊涂窗口綜合癥(別人都這樣翻譯的,似乎有點(diǎn)搞笑:D)
               b) 將ACK與將要發(fā)送的數(shù)據(jù)報(bào)文一起發(fā)送
               c) 一個(gè)ack確認(rèn)多個(gè)報(bào)文段,如果這幾個(gè)報(bào)文段在延遲時(shí)間內(nèi)到達(dá)

            2. 什么是Nagle algoritm ?
               簡(jiǎn)而言之,nagle算法主要目的是減少網(wǎng)絡(luò)流量,當(dāng)你發(fā)送的數(shù)據(jù)包太小時(shí),TCP并不立即發(fā)送該數(shù)據(jù)包,而是緩存起來直到數(shù)據(jù)包
               到達(dá)一定大小后才發(fā)送。(improving the efficiency of TCP/IP networks by reducing the number of packets that need to
               be sent over the network.)

               關(guān)于這個(gè)算法,我覺得wikipedia上講的比較好。具體點(diǎn)說,當(dāng)上層提交數(shù)據(jù)給TCP時(shí),TCP覺得你的數(shù)據(jù)太小了(套用一般的例子,
               如果你要發(fā)送1一個(gè)字節(jié)的數(shù)據(jù),當(dāng)附加上TCP和IP頭后,數(shù)據(jù)包通常就會(huì)增加到41字節(jié),那么這顯然是低效的),就緩存你的數(shù)據(jù),
               當(dāng)數(shù)據(jù)緩存到一定長度后,如果之前發(fā)送的數(shù)據(jù)得到了ACK確認(rèn)且接收方有足夠空間容納數(shù)據(jù),就發(fā)送這些數(shù)據(jù),否則繼續(xù)等待。

               wikipedia上給了一段nagle的偽代碼:

            if there is new data to send
                 
            if the window size >= MSS and available data is >= MSS
                   send complete MSS segment now
                 
            else
                   
            if there is unconfirmed data still in the pipe
                     enqueue data 
            in the buffer until an acknowledge is received
                   
            else
                     send data immediately
                   end 
            if
                 end 
            if
               end 
            if 

               
               TCP socket提供了關(guān)閉nagle算法的接口,你可以通過TCP_NODELAY選項(xiàng)決定是否開啟該算法。不過MSDN上建議不要關(guān)閉此算法。如果
               你發(fā)送的數(shù)據(jù)不至于很小的話(<40byte),我也不建議你關(guān)閉。

            posted on 2008-05-22 15:42 Kevin Lynx 閱讀(3141) 評(píng)論(1)  編輯 收藏 引用 所屬分類: network

            評(píng)論

            # re: tcp要點(diǎn)學(xué)習(xí)-數(shù)據(jù)發(fā)送一[未登錄] 2012-06-06 16:42 春秋十二月

            交互式程序如telnet和rlogin是關(guān)閉nagle算法的典型應(yīng)用  回復(fù)  更多評(píng)論   

            久久久久国产| 热久久最新网站获取| 久久亚洲日韩精品一区二区三区| 偷窥少妇久久久久久久久| 伊人久久一区二区三区无码| 久久天天躁狠狠躁夜夜2020一 | 久久精品国产AV一区二区三区| 国产精品一区二区久久精品涩爱| 亚洲va中文字幕无码久久不卡| 久久99久久99小草精品免视看| 亚洲国产成人精品91久久久| 久久精品www人人爽人人| 精品久久久久久国产三级| 亚洲精品乱码久久久久久蜜桃图片 | 办公室久久精品| 久久91综合国产91久久精品| 亚洲欧美另类日本久久国产真实乱对白 | 99久久综合狠狠综合久久| 午夜肉伦伦影院久久精品免费看国产一区二区三区 | 91视频国产91久久久| 国产免费福利体检区久久| 亚洲中文字幕无码久久2017| 精品国产一区二区三区久久蜜臀| 国产精品女同久久久久电影院| 国产亚洲美女精品久久久2020| 久久性精品| 日本精品久久久久久久久免费| 国产亚洲成人久久| 99久久精品免费| 青青草原综合久久大伊人精品| 精品少妇人妻av无码久久| 久久久久99精品成人片欧美| 久久亚洲中文字幕精品一区| 一级女性全黄久久生活片免费 | 麻豆精品久久久一区二区| 国内精品九九久久久精品| 久久综合香蕉国产蜜臀AV| 久久久久AV综合网成人| 狠狠色丁香婷综合久久| 69SEX久久精品国产麻豆| 999久久久国产精品|