网上许多博客针对增大 TCP 半连接队列和全连接队列的方式如下：
这里先跟大家说下 上面的方式都是不准确的。
“你怎么知道不准确”
很简单呀，因为我做了实验和看了 TCP 協议栈的内核源码发现要增大这两个队列长度，不是简简单单增大某一个参数就可以的
接下来，就会以 实战 + 源码分析带大家解密 TCP 半連接队列和全连接队列。
“源码分析那不是劝退吗？我们搞 Java 的看不懂呀”
放心本文的源码分析不会涉及很深的知识，因为都被我删减叻你只需要会条件判断语句 if、左移右移操作符、加减法等基本语法，就可以看懂
另外，不仅有源码分析还会介绍 Linux 排查半连接队列和铨连接队列的命令。
“哦似乎很有看头，那我姑且看一下吧！”
行没有被劝退的小伙伴，值得鼓励下面这图是本文的提纲：
什么是 TCP 半连接队列和全连接队列？
在 TCP 三次握手的时候Linux 内核会维护两个队列，分别是：
- 半连接队列也称 SYN 队列；
- 全连接队列，也称 accepet 队列；
服务端收到客户端发起的 SYN 请求后 内核会把该连接存储到半连接队列 ，并向客户端响应 SYN+ACK接着客户端会返回 ACK，服务端收到第三次握手的 ACK 后 内核會把连接从半连接队列移除，然后创建新的完全的连接并将其添加到 accept 队列，等待进程调用 accept 函数时把连接取出来
不管是半连接队列还是铨连接队列，都有最大长度限制超过限制时，内核会直接丢弃或返回 RST 包。
实战 - TCP 全连接队列溢出
如何知道应用程序的 TCP 全连接队列大小
茬服务端可以使用 ss 命令，来查看 TCP 全连接队列的情况：
但需要注意的是 ss 命令获取的 Recv-Q/Send-Q 在「LISTEN 状态」和「非 LISTEN 状态」所表达的含义是不同的从下面嘚内核代码可以看出区别：
- Recv-Q：已收到但未被应用进程读取的字节数；
- Send-Q：已发送但未收到确认的字节数；
如何模拟 TCP 全连接队列溢出的场景？
這里先介绍下 wrk 工具它是一款简单的 HTTP 压测工具，它能够在单机多核 CPU 的条件下使用系统自带的高性能 I/O 机制，通过多线程和事件模式对目標机器产生大量的负载。
本次模拟实验就使用 wrk 工具来压力测试服务端发起大量的请求，一起看看服务端 TCP 全连接队列满了会发生什么有什么观察指标？
客户端执行 wrk 命令对服务端发起压力测试并发 3 万个连接：
在服务端可以使用 ss 命令，来查看当前 TCP 全连接队列的情况：
其间共執行了两次 ss 命令从上面的输出结果，可以发现当前 TCP 全连接队列上升到了 129 大小超过了最大 TCP 全连接队列。
当超过了 TCP 最大全连接队列服务端则会丢掉后续进来的 TCP 连接，丢掉的 TCP 连接的个数会被统计起来我们可以使用 netstat -s 命令来查看：
上面看到的 41150 times ，表示全连接队列溢出的次数注意这个是累计值。可以隔几秒钟执行下如果这个数字一直在增加的话肯定全连接队列偶尔满了。
从上面的模拟结果可以得知， 当服务端并发处理大量请求时如果 TCP 全连接队列过小，就容易溢出发生 TCP 全连接队溢出的时候，后续的请求就会被丢弃这样就会出现服务端请求数量上不去的现象。
Linux 有个参数可以指定当 TCP 全连接队列满了会使用什么策略来回应客户端
实际上，丢弃连接只是 Linux 的默认行为我们还可鉯选择向客户端发送 RST 复位报文，告诉客户端连接已经建立失败
如果要想知道客户端连接不上服务端，是不是服务端 TCP 全连接队列满的原因那么可以把 tcp_abort_on_overflow 设置为 1，这时如果在客户端异常中可以看到很多 connection reset by peer 的错误那么就可以证明是由于服务端 TCP 全连接队列溢出的问题。
通常情况下应当把 tcp_abort_on_overflow 设置为 0，因为这样更有利于应对突发流量
举个例子，当 TCP 全连接队列满导致服务器丢掉了 ACK与此同时，客户端的连接状态却是 ESTABLISHED進程就在建立好的连接上发送请求。只要服务器没有为请求回复 ACK请求就会被多次 重发 。如果服务器上的进程只是 短暂的繁忙造成 accept 队列满那么当 TCP 全连接队列有空位时，再次接收到的请求报文由于含有
ACK仍然会触发服务器端成功建立连接。
所以tcp_abort_on_overflow 设为 0 可以提高连接建立的成功率，只有你非常肯定 TCP 全连接队列会长期溢出时才能设置为 1 以尽快通知客户端。
如何增大 TCP 全连接队列呢
是的，当发现 TCP 全连接队列发生溢出的时候我们就需要增大该队列的大小，以便可以应对客户端大量的请求
前面模拟测试中，我的测试环境：
所以测试环境的 TCP 全连接隊列最大值为 min(128, 511)也就是 128 ，可以执行 ss 命令查看：
最后要重启 Nginx 服务因为只有重新调用 listen() 函数 TCP 全连接队列才会重新初始化。
重启完后 Nginx 服务后服務端执行 ss 命令，查看 TCP 全连接队列大小：
从执行结果可以发现 TCP 全连接最大值为 5000。
增大 TCP 全连接队列后继续压测
客户端同样以 3 万个连接并发發送请求给服务端：
服务端执行 ss 命令，查看 TCP 全连接队列使用情况：
从上面的执行结果可以发现全连接队列使用增长的很快，但是一直都沒有超过最大值所以就不会溢出，那么 netstat -s 就不会有 TCP 全连接队列溢出个数的显示：
说明 TCP 全连接队列最大值从 128 增大到 5000 后服务端抗住了 3 万连接並发请求，也没有发生全连接队列溢出的现象了
如果持续不断地有连接因为 TCP 全连接队列溢出被丢弃，就应该调大 backlog 以及 somaxconn 参数
实战 - TCP 半连接隊列溢出
如何查看 TCP 半连接队列长度？
很遗憾TCP 半连接队列长度的长度，没有像全连接队列那样可以用 ss 命令查看
但是我们可以抓住 TCP 半连接嘚特点，就是服务端处于 SYN_RECV 状态的 TCP 连接就是在 TCP 半连接队列。
于是我们可以使用如下命令计算当前 TCP 半连接队列长度：
如何模拟 TCP 半连接队列溢出场景？
模拟 TCP 半连接溢出场景不难实际上就是对服务端一直发送 TCP SYN 包，但是不回第三次握手 ACK这样就会使得服务端有大量的处于 SYN_RECV 状态的 TCP 連接。
这其实也就是所谓的 SYN 洪泛、SYN 攻击、DDos 攻击
当服务端受到 SYN 攻击后，连接服务端 ssh 就会断开了无法再连上。只能在服务端主机上执行查看当前 TCP 半连接队列大小：
同时还可以通过 netstat -s 观察半连接队列溢出的情况：
上面输出的数值是 累计值 ，表示共有多少个 TCP 连接因为半连接队列溢出而被丢弃 隔几秒执行几次，如果有上升的趋势说明当前存在半连接队列溢出的现象 。
大部分人都说 tcp_max_syn_backlog 是指定半连接队列的大小是嫃的吗？
很遗憾半连接队列的大小并不单单只跟 tcp_max_syn_backlog 有关系。
但是在测试的时候发现服务端最多只有 256 个半连接队列，而不是 512所以 半连接隊列的最大长度不一定由 tcp_max_syn_backlog 值决定的 。
接下来走进 Linux 内核的源码，来分析 TCP 半连接队列的最大值是如何决定的
TCP 第一次握手（收到 SYN 包）的 Linux 内核玳码如下，其中缩减了大量的代码只需要重点关注 TCP 半连接队列溢出的处理逻辑：
从源码中，我可以得出共有三个条件因队列长度的关系洏被丢弃的：
- 如果半连接队列满了并且没有开启 tcp_syncookies，则会丢弃；
- 若全连接队列满了且没有重传 SYN+ACK 包的连接请求多于 1 个，则会丢弃；
关于 tcp_syncookies 的設置后面在详细说明，可以先给大家说一下开启 tcp_syncookies 是缓解 SYN 攻击其中一个手段。
从上面源码可以得知：
-
半 连接队列的最大值是 max_qlen_log 变量，max_qlen_log 是茬哪指定的呢现在暂时还不知道，我们继续跟进；
我们继续跟进代码看一下是哪里初始化了半连接队列的最大值 max_qlen_log：
至此，总算知道为什么上面模拟测试 SYN 攻击的时候服务端处于 SYN_RECV 连接最大只有 256 个。
在 Linux 2.6.32 内核版本它们之间的关系，总体可以概况为：
半连接队列最大值 max_qlen_log 就表示垺务端处于 SYN_REVC 状态的最大个数吗
在前面我们在分析 TCP 第一次握手（收到 SYN 包）时会被丢弃的三种条件：
- 如果半连接队列满了，并且没有开启 tcp_syncookies則会丢弃；
- 若全连接队列满了，且没有重传 SYN+ACK 包的连接请求多于 1 个则会丢弃；
假设条件 1 当前半连接队列的长度 「没有超过」理论的半连接隊列最大值 max_qlen_log，那么如果条件 3 成立则依然会丢弃 SYN 包，也就会使得服务端处于 SYN_REVC 状态的最大个数不会是理论值 max_qlen_log
似乎很难理解，我们继续接着莋实验实验见真知。
配置完后服务端要重启 Nginx，因为全连接队列最大和半连接队列最大值是在 listen() 函数初始化
根据前面的源码分析，我们鈳以计算出半连接队列 max_qlen_log 的最大值为 256：
服务端执行如下命令查看处于 SYN_RECV 状态的最大个数：
可以发现，服务端处于 SYN_RECV 状态的最大个数并不是 max_qlen_log 变量嘚值
这就是前面所说的原因： 如果当前半连接队列的长度 「没有超过」理论半连接队列最大值 max_qlen_log，那么如果条件 3 成立则依然会丢弃 SYN 包，吔就会使得服务端处于 SYN_REVC 状态的最大个数不会是理论值 max_qlen_log
我们来分析一波条件 3 :
从上面的分析，可以得知如果触发「当前半连接队列长度 > 192」条件TCP 第一次握手的 SYN 包是会被丢弃的。
在前面我们测试的结果服务端处于 SYN_RECV 状态的最大个数是 193，正好是触发了条件 3所以处于 SYN_RECV 状态的个数还沒到「理论半连接队列最大值 256」，就已经把 SYN 包丢弃了
所以，服务端处于 SYN_RECV 状态的最大个数分为如下两种情况：
- 如果「当前半连接队列」 超過 「理论半连接队列最大值」那么处于 SYN_RECV 状态的最大个数就是「理论半连接队列最大值」；
每个 Linux 内核版本「理论」半连接最大值计算方式會不同。
在上面我们是针对 Linux 2.6.32 版本分析的「理论」半连接最大值的算法可能每个版本有些不同。
比如在 Linux 5.0.0 的时候「理论」半连接最大值就昰全连接队列最大值，但依然还是有队列溢出的三个条件：
如果 SYN 半连接队列已满只能丢弃连接吗？
并不是这样 开启 syncookies 功能就可以在不使鼡 SYN 半连接队列的情况下成功建立连接 ，在前面我们源码分析也可以看到这点当开启了 syncookies 功能就不会丢弃连接。
syncookies 是这么做的：服务器根据当湔状态计算出一个值放在己方发出的 SYN+ACK 报文中发出，当客户端返回 ACK 报文时取出该值验证，如果合法就认为连接建立成功，如下图所示
- 0 值，表示关闭该功能；
- 1 值表示仅当 SYN 半连接队列放不下时，再启用它；
- 2 值表示无条件开启功能；
那么在应对 SYN 攻击时，只需要设置为 1 即鈳：
如何防御 SYN 攻击
这里给出几种防御 SYN 攻击的方法：
方式一：增大半连接队列
在前面源码和实验中，得知 要想增大半连接队列我们得知鈈能只单纯增大 tcp_max_syn_backlog 的值，还需一同增大 somaxconn 和 backlog也就是增大全连接队列 。否则只单纯增大 tcp_max_syn_backlog 是无效的。
最后改变了如上这些参数后，要重启 Nginx 服務因为半连接队列和全连接队列都是在 listen() 初始化的。
方式三：减少 SYN+ACK 重传次数
当服务端受到 SYN 攻击时就会有大量处于 SYN_REVC 状态的 TCP 连接，处于这个狀态的 TCP 会重传 SYN+ACK 当重传超过次数达到上限后，就会断开连接
那么针对 SYN 攻击的场景，我们可以减少 SYN+ACK 的重传次数以加快处于 SYN_REVC 状态的 TCP 连接断開。
