TCP SYN_REVD, ESTABELLISHED 狀態對應的隊列
TCP 建立連接時要經過 3 次握手，在客戶端向服務器發起連接時，對於服務器而言，一個完整的連接建立過程，服務器會經歷 2 種 TCP 狀態：SYN_REVD, ESTABELLISHED
對應也會維護兩個隊列：
- 一個存放 SYN 的隊列（半連接隊列）
- 一個存放已經完成連接的隊列（全連接隊列）
當一個連接的狀態是 SYN RECEIVED 時，它會被放在 SYN 隊列中
如果一個服務器要處理大量網絡連接，且並發性比較高，那么這兩個隊列長度就非常重要了。因為，即使服務器的硬件配置非常高，服務器端程序性能很好，但是這兩個隊列非常小，那么經常會出現客戶端連接不上的現象，因為這兩個隊列一旦滿了后，很容易丟包，或者連接被復位。所以，如果服務器並發訪問量非常高，那么這兩個隊列的設置就非常重要了。
Linux backlog 參數意義
對於 Linux 而言，基本上任意語言實現的通信框架或服務器程序在構造 socket server 時，都提供了 backlog 這個參數，因為在監聽端口時，都會調用系統底層 API: int listen(int sockfd, int backlog);
listen 函數中 backlog 參數的定義如下：
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 the tcp_max_syn_backlog sysctl. When syncookies are enabled there is no logical maximum length and this sysctl setting is ignored.If the socket is of type AF_INET, and the backlog argument is greater than the constant SOMAXCONN(128 default), it is silently truncated to SOMAXCONN.
backlog 參數描述的是服務器端 TCP ESTABELLISHED 狀態對應的全連接隊列長度。
ESTABLISHED列長度如何計算？
如果 backlog 大於內核參數 net.core.somaxconn，則以 net.core.somaxconn 為准，
即全連接隊列長度 = min(backlog, 內核參數 net.core.somaxconn)，net.core.somaxconn 默認為 128。
這個很好理解，net.core.somaxconn 定義了系統級別的全連接隊列最大長度，
backlog 只是應用層傳入的參數，不可能超過內核參數，所以 backlog 必須小於等於 net.core.somaxconn。
SYN_RECV隊列長度如何計算？
半連接隊列長度由內核參數 tcp_max_syn_backlog 決定，
當使用 SYN Cookie 時（就是內核參數 net.ipv4.tcp_syncookies = 1），這個參數無效，
半連接隊列的最大長度為 backlog、內核參數 net.core.somaxconn、內核參數 tcp_max_syn_backlog 的最小值。
即半連接隊列長度 = min(backlog, 內核參數 net.core.somaxconn，內核參數 tcp_max_syn_backlog)。
這個公式實際上規定半連接隊列長度不能超過全連接隊列長度，但是tcp_syncooking默認是啟用的，如果按上文的理解，那這個參數設置沒有多大意義
其實，對於 Nginx/Tomcat 等這種 Web 服務器，都提供了 backlog 參數設置入口，當然它們都會有默認值，通常這個默認值都不會太大（包括內核默認的半連接隊列和全連接隊列長度）。如果應用並發訪問非常高，只增大應用層 backlog 是沒有意義的，因為可能內核參數關於連接隊列設置的都很小，一定要綜合應用層 backlog 和內核參數一起看，通過公式很容易調整出正確的設置
以上都是引用文檔，官方文檔如下
tcp_syncookies - BOOLEAN
Only valid when the kernel was compiled with CONFIG_SYN_COOKIES Send out syncookies when the syn backlog queue of a socket overflows. This is to prevent against the common 'SYN flood attack'
Default: 1
Note, that syncookies is fallback facility. It MUST NOT be used to help highly loaded servers to stand against legal connection rate. If you see SYN flood warnings in your logs, but investigation shows that they occur because of overload with legal connections, you should tuneanother parameters until this warning disappear. See: tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow.
大致的意思，這個參數在請求高峰時，無法判斷是不是合法正常的請求，當檢查到SYN flood時首先排查一下原因。建議使用tcp_max_syn_backlog解除告警信息
syncookies seriously violate TCP protocol, do not allow to use TCP extensions, can result in serious degradation of some services (f.e. SMTP relaying), visible not by you, but your clients and relays, contacting you. While you see SYN flood warnings in logs not being really flooded, your server is seriously misconfigured.
If you want to test which effects syncookies have to your network connections you can set this knob to 2 to enable unconditionally generation of syncookies.
參數文獻
https://jaminzhang.github.io/linux/understand-Linux-backlog-and-somaxconn-kernel-arguments/