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

            lynch

            listen()的backlog參數小結

             

                 listen函數是網絡編程一個基本的函數,而且它的backlog參數卻是和TCP協議息息相關的。我們來看一下一個backlog參數到底有多少秘密。
             

            一、 為了理解backlog參數,我們必須首先認識listen函數。

            #include<sys/socket.h>
            int listen(int sockfd, int backlog);

            listen函數僅由TCP服務器調用,它做兩件事情:

            1、當socket函數創建一個套接口時,它被假設為一個主動套裝口,也就是說,它是一個將調用connet發起連接的客戶套接口。listen函數把一個未連接的套接口轉換成一個被動套接口,指示內核應接受指向該套接口的連接請求。根據TCP狀態轉換圖,調用listen導致套接口從CLOSED狀態轉換到LISTEN狀態。

            2、本函數的第二個參數規定了內核應該為相應套接口排隊的最大連接個數。

            為了更好的理解backlog參數,我們必須認識到內核為任何一個給定的監聽套接口維護兩個隊列:

                  1、未完成連接隊列(incomplete connection queue),每個這樣的SYN分節對應其中一項:已由某個客戶發出并到達服務器,而服務器正在等待完成相應的TCP三路握手過程。這些套接口處于SYN_RCVD狀態。

                 2、已完成連接隊列(completed connection queue),每個已完成TCP三路握手過程的客戶對應其中一項。這些套接口處于ESTABLISHED狀態。

            當來自客戶的SYN到達時,TCP在未完成連接隊列中創建一個新項,然后響應以三路握手的第二個分節:服務器的SYN響應,其中稍帶對客戶SYN的ACK(即SYN+ACK)。這一項一直保留在未完成連接隊列中,直到三路握手的第三個分節(客戶對服務器SYN的ACK)到達或者該項超時為止(曾經源自Berkeley的實現為這些未完成連接的項設置的超時值為75秒)。如果三路握手正常完成,該項就從未完成連接隊列移到已完成連接隊列的隊尾。當進程調用accept時,已完成連接隊列中的隊頭項將返回給進程,或者如果該隊列為空,那么進程將被投入睡眠,直到TCP在該隊列中放入一項才喚醒它。

            二、查看man手冊。看看man listen怎么說

            clip_image002[1]
                  可以看到man手冊是這樣描述backlog參數的:“backlog參數確定了connection隊列可以增長的最大長度”,如果connection隊列已滿(達到backlog確定的長度),那么新的connection請求到來時,客戶端會得到一個ECONNREFUSED error,或者,如果底層協議支持重發,那么這個請求會被服務器忽略而使客戶端重新發送connection請求。

            clip_image004[1]
                   現在backlog用來確定已完成隊列(完成三次握手等待accept)的長度,而不再是已完成隊列和未完成連接隊列之和(linux 2.2之前)。

                  未完成隊列(incomplete connection queue)的長度現在由/proc/sys/net/ipv4/tcp_max_syn_backlog設置,在現在大多數最新linux內核都是默認512,這個設置有效的前提是系統的syncookies功能被禁用,如果系統的syncookies功能被啟用,那么這個設置是無效的。Syncookies是在內核編譯的時候設置的,查看syncookies是否啟動:

                  cat /proc/sys/net/ipv4/tcp_syncookies

                  如果是“1”說明已啟用,為“0”說明未啟用。

                 那么為syncookies是做什么的呢,為什么它會和未完成隊列有關系。簡單的說它是為防范SYN Flood攻擊的設計。具體請參考“syncookies介紹”(http://baike.baidu.com/view/9033755.htm)。

            繼續看backlog,如果我們給listen的backlog參數設值超過了/proc/sys/net/core/somaxconn,那么backlog參數的值為自動被改寫為/proc/sys/net/core/somaxconn的值,它的默認大小為128.

             

             

            更多資料可以查看

            1、 man tcp

            2、 man listen

            3、 《unix網絡編程卷一》

            4、 百度百科syncookies介紹:http://baike.baidu.com/view/9033755.htm

            posted on 2012-12-30 15:52 董三 閱讀(3172) 評論(0)  編輯 收藏 引用

            <2025年6月>
            25262728293031
            1234567
            891011121314
            15161718192021
            22232425262728
            293012345

            導航

            統計

            常用鏈接

            留言簿(1)

            隨筆分類

            隨筆檔案

            文章分類

            文章檔案

            博客友

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            久久av高潮av无码av喷吹| 久久久久久一区国产精品| 国内精品伊人久久久久妇| 日日狠狠久久偷偷色综合96蜜桃 | 国産精品久久久久久久| 国产亚州精品女人久久久久久| 久久久久99精品成人片三人毛片 | 韩国无遮挡三级久久| 久久国产三级无码一区二区| 久久无码一区二区三区少妇| 无码任你躁久久久久久老妇App| a高清免费毛片久久| 国产毛片久久久久久国产毛片| 五月丁香综合激情六月久久| 91久久成人免费| 日韩人妻无码精品久久免费一| 久久久久久毛片免费看| 久久精品国产久精国产思思| 新狼窝色AV性久久久久久| 色综合合久久天天综合绕视看 | 国产精品丝袜久久久久久不卡| 精品久久久久中文字幕日本| 久久久久九九精品影院| www性久久久com| 国产精品久久久久久久久免费| 亚洲国产精品无码久久久不卡| 久久综合鬼色88久久精品综合自在自线噜噜 | 中文字幕精品无码久久久久久3D日动漫| 欧美熟妇另类久久久久久不卡| 久久婷婷五月综合成人D啪| 欧美午夜A∨大片久久| 91精品国产综合久久香蕉| 久久亚洲日韩精品一区二区三区| 久久无码AV一区二区三区| 久久久久久无码国产精品中文字幕| 久久久久成人精品无码| 2021国产成人精品久久| 久久精品国产精品亚洲艾草网美妙| 国产香蕉97碰碰久久人人| 久久一区二区免费播放| 久久99亚洲综合精品首页|