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

參考：

unix network programming