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/