int listen(int fd, int backlog);


socket系統調用listen只被tcp 服務器使用，他做兩件事：
1. 將未鏈接的套接口轉換為被動套接口，指示內核接受向此套接口的連接請求，調用此系統調用后tcp 狀態機有close轉換到listen.
2.第二個參數制定了內核為此套接口排隊的最大連接個數。
關于第二個參數，對于給定的監聽套接口，內核要維護兩個隊列，未鏈接隊列和已連接隊列，根據tcp 三路握手過程中三個分節來分隔這兩個隊列。
? 服務器處于listen狀態時收到客戶端syn 分節(connect)時在未完成隊列中創建一個新的條目，然后用三路握手的第二個分節即服務器的syn 響應及對客戶端syn的ack,此條目在第三個分節到達前(客戶端對服務器syn的ack)一直保留在未完成連接隊列中，如果三路握手完成，該條目將從未完成連接隊列搬到已完成連接隊列尾部。當進程調用accept時，從已完成隊列中的頭部取出一個條目給進程，當已完成隊列為空時進程將睡眠，直到有條目在已完成連接隊列中才喚醒。
?backlog被規定為兩個隊列總和的最大值，大多數實現默認值為5，但在高并發web服務器中此值顯然不夠，lighttpd中此值達到128*8.需要設置此值更大一些的原因是未完成連接隊列的長度可能因為客戶端SYN的到達及等待三路握手第三個分節的到達延時而增大。
當客戶端發起connect而導致發送syn分節給服務器端握手，如果這時兩個隊列都是滿的，tcp就忽略此分節，并且不發RST,這將導致客戶端TCP重發SYN(超時)，服務器端忽略syn而不發RST響應的原因是如果發RST ，客戶端connect將立即返回錯誤，強制客戶端進程處理這種情況，而不是讓tcp的正常重傳機制來處理。實際上所有源自Berkeley的實現都是忽略新的SYN分節。
還有，backlog為0 時在linux上表明潤許不受限制的連接數，這是一個缺陷，因為它可能會導致SYN Flooding(拒絕服務型攻擊)， 下一篇文章會簡單解釋。

linux 系統tcp /ip協議棧有個選項可以設置未鏈接隊列大小

tcp_max_syn_backlog

cat /proc/sys/net/ipv4/tcp_max_syn_backlog?
1024

參考：

unix network programming

http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/023/2333/2333s2.html

總結

以上是生活随笔為你收集整理的TCP listen() Backlog 参数详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。