• <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>
            隨筆 - 7  文章 - 6  trackbacks - 0
            <2015年8月>
            2627282930311
            2345678
            9101112131415
            16171819202122
            23242526272829
            303112345

            常用鏈接

            留言簿(1)

            隨筆檔案

            文章分類

            搜索

            •  

            積分與排名

            • 積分 - 33035
            • 排名 - 610

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

            To understand the backlog argument, we must realize that for a given listening socket, the kernel maintains two queues :
            要明白backlog參數(shù)的含義,我們必須明白對(duì)于一個(gè)listening socket,kernel維護(hù)者兩個(gè)隊(duì)列:

            1.An incomplete connection queue, which contains an entry for each SYN that has arrived from a client for which the server is awaiting completion of the TCP three-way handshake. These sockets are in the SYN_RCVD state .
            1.一個(gè)未完成連接的隊(duì)列,此隊(duì)列維護(hù)著那些已收到了客戶端SYN分節(jié)信息,等待完成三路握手的連接,socket的狀態(tài)是SYN_RCVD

            2.A completed connection queue, which contains an entry for each client with whom the TCP three-way handshake has completed. These sockets are in the ESTABLISHED state
            2.一個(gè)已完成的連接的隊(duì)列,此隊(duì)列包含了那些已經(jīng)完成三路握手的連接,socket的狀態(tài)是ESTABLISHED

            The backlog argument to the listen function has historically specified the maximum value for the sum of both queues.
            backlog參數(shù)歷史上被定義為上面兩個(gè)隊(duì)列的大小之和

            Berkeley-derived implementations add a fudge factor to the backlog: It is multiplied by 1.5
            Berkely實(shí)現(xiàn)中的backlog值為上面兩隊(duì)列之和再乘以1.5

            When a SYN arrives from a client, TCP creates a new entry on the incomplete queue and then responds with the second segment of the three-way handshake: the server's SYN with an ACK of the client's SYN (Section 2.6). This entry will remain on the incomplete queue until the third segment of the three-way handshake arrives (the client's ACK of the server's SYN), or until the entry times out. (Berkeley-derived implementations have a timeout of 75 seconds for these incomplete entries.)
            當(dāng)客戶端的第一個(gè)SYN到達(dá)的時(shí)候,TCP會(huì)在未完成隊(duì)列中增加一個(gè)新的記錄然后回復(fù)給客戶端三路握手中的第二個(gè)分節(jié)(服務(wù)端的SYN和針對(duì)客戶端的ACK),這條記錄會(huì)在未完成隊(duì)列中一直存在,直到三路握手中的最后一個(gè)分節(jié)到達(dá),或者直到超時(shí)(Berkeley時(shí)間將這個(gè)超時(shí)定義為75秒)

            If the queues are full when a client SYN arrives, TCP ignores the arriving SYN (pp. 930–931 of TCPv2); it does not send an RST. This is because the condition is considered temporary, and the client TCP will retransmit its SYN, hopefully finding room on the queue in the near future. If the server TCP immediately responded with an RST, the client's connect would return an error, forcing the application to handle this condition instead of letting TCP's normal retransmission take over. Also, the client could not differentiate between an RST in response to a SYN meaning "there is no server at this port" versus "there is a server at this port but its queues are full."
            如果當(dāng)客戶端SYN到達(dá)的時(shí)候隊(duì)列已滿,TCP將會(huì)忽略后續(xù)到達(dá)的SYN,但是不會(huì)給客戶端發(fā)送RST信息,因?yàn)榇藭r(shí)允許客戶端重傳SYN分節(jié),如果返回錯(cuò)誤信息,那么客戶端將無法分清到底是服務(wù)端對(duì)應(yīng)端口上沒有相應(yīng)應(yīng)用程序還是服務(wù)端對(duì)應(yīng)端口上隊(duì)列已滿這兩種情況

            posted on 2010-02-07 19:43 許海斌 閱讀(18819) 評(píng)論(2)  編輯 收藏 引用

            FeedBack:
            # re: 總算明白了tcp/ip協(xié)議listen函數(shù)中backlog參數(shù)的含義 2011-07-21 09:37 shan
            是這樣的么?如果backlog取5,那么這兩個(gè)隊(duì)列的大小是如何分配的呢?  回復(fù)  更多評(píng)論
              
            # re: 總算明白了tcp/ip協(xié)議listen函數(shù)中backlog參數(shù)的含義 2015-08-21 11:40 AutumnLight
            @shan
            linux的實(shí)現(xiàn)是不一樣的,在Linux下,backlog指定的是complete queue的大小,而incomplete queue的大小可以由系統(tǒng)管理員在 /proc/sys/net/ipv4/tcp_max_syn_backlog下進(jìn)行統(tǒng)一配置。
            你可以看一看這篇文章。
            http://veithen.github.io/2014/01/01/how-tcp-backlog-works-in-linux.html  回復(fù)  更多評(píng)論
              

            只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            免费观看成人久久网免费观看| 91久久国产视频| 久久久网中文字幕| 国产亚洲精品久久久久秋霞| 国产成人久久精品麻豆一区 | 91精品国产色综久久| 国产精品久久久久久影院| 国产毛片欧美毛片久久久| 久久免费观看视频| 亚洲国产精品一区二区久久hs | 亚洲精品成人网久久久久久| 久久精品日日躁夜夜躁欧美| 亚洲中文精品久久久久久不卡| 99久久人妻无码精品系列蜜桃 | 久久久久久久久无码精品亚洲日韩| 热re99久久精品国99热| 久久综合精品国产一区二区三区| 99久久国产热无码精品免费| 久久天天躁狠狠躁夜夜avapp| 日韩人妻无码一区二区三区久久 | 亚洲国产精品无码久久久秋霞2| 久久成人影院精品777| 久久亚洲国产精品一区二区| 7777久久亚洲中文字幕| 91久久精品无码一区二区毛片| 久久久99精品成人片中文字幕| 国产福利电影一区二区三区久久久久成人精品综合 | 伊人久久大香线蕉综合Av| 久久久久久精品久久久久| 久久久精品国产免大香伊| 久久这里只精品国产99热| 亚洲精品乱码久久久久66| 国产精品午夜久久| 久久大香香蕉国产| 久久综合偷偷噜噜噜色| 色婷婷噜噜久久国产精品12p| 亚洲日韩欧美一区久久久久我| 久久精品国产网红主播| 久久亚洲色一区二区三区| 精品久久久无码中文字幕| 国产精品成人99久久久久|