今天主要回顧下listen的第二個參數的意義。 話說現在現在都是用框架寫業務代碼。真的很少在去關注最基本的socket函數的意義了。該忘得都忘得差不多了。~~~ 要慢慢撿起來。 主要是在看redis網絡這塊的時候它的第二個參數設置的是500多。 而且突然想到當初幾年前騰訊電話面試問過我第二個參數是什么意思。當時我一股腦就說成connet的連接數量了。哈哈 2b.
照例 先上圖，再解析
首先這個圖是展示的TCP 三次握手。這里就不吸收三次握手了。我們主要是關注 兩個隊列
1：未完成隊列：每個這樣的SYN分節對應其中一項，已有某個客戶端發出並到達服務器，而服務器正在等待完成相應的TCP三路握手過程。這些套接口處於SYN_RCVD
2：已完成隊列：每個已經完成TCP三路握手過程的客戶對應其中一項。 這些套接口處於ESTABLISHED
這里說下對着兩個隊列的理解
假設未完成隊列設置為100， 有並發1000個請求過來。假如系統處理過慢。那么系統會做以下幾件事
1） 因為未完成隊列只有100個。先放100個請求過來處理三次握手。其他的請求直接拒絕。TCP會忽略該分節，也就是不送RST，這樣客戶端將重發SYN,期望在未完成隊列中找到位置
2）每處理完一個三次握手動作。就放一個SYN請求過來。並站住未完成隊列一個位置。除非三次握手完成（成功或者失敗）、或者超時就把該請求連接移除未完成隊列。如果系統性能好。這個動作會很快。
3）完成TCP三次握手的請求放到已完成隊列里。
這個時候再去看 listen的第二個參數。
其實這里man listen的時候已經解釋的很清楚了
The backlog argument defines the maximum length to which the queue of pending connections for sockfd may grow. If a connection request arrives when the queue is full, the client may receive an error with an indication of ECONNREFUSED or, if the underlying protocol supports retransmission, the request may be ignored so that a later reattempt at connection succeeds.
第二個參數就是未完成隊列的大小
但是繼續man listen函數 看到如下解釋
The behavior of the backlog argument on TCP sockets changed with Linux 2.2. Now it specifies the queue length for completely established sockets waiting to be accepted, instead of the number of incomplete connection requests. The maximum length of the queue for incomplete sockets can be set using /proc/sys/net/ipv4/tcp_max_syn_backlog. When syncookies are enabled there is no logical maximum length and this setting is ignored. See tcp(7) for more information.
在linux 2.2以后 listen的第二個參數。指的是在完成TCP三次握手后的隊列。即在系統accept之前的隊列。已經完成的隊列。如果系統沒有調用accpet把這個隊列的數據拿出來。一旦這個隊列滿了。未連接隊列的請求過不來。導致未連接隊列里的請求會超時或者拒絕。如果系統調用了accpet隊列接受請求數據。那么就會把接受到請求移除已完成隊列。 這時候已完成隊列又可以使用了。
最后 說了如果開啟了syncookies 忽略listen的第二個參數。
syncookie 主要是為了防止syn flood攻擊。這里暫時先不說。以后再補充
總結
1，這里可以感受到 內核用了兩個隊列。 可以針對並發請求的時候。及時拒絕掉一部分處理不過來的請求。防止盲等待。類似有點雪崩處理的感覺。
2，listen的第二個參數。跟系統的鏈接數量沒有任何關系。相當於設置一個瞬間能夠處理的閾值。
3，一般情況下都會去開啟 syncookie。所有其實現在已經可以不太關系listen的第二個值了