TCP 半连接队列和全连接队列满了，怎么破？( 三 ) _TCP

文章插图
说明 TCP 全连接队列最大值从 128 增大到 5000 后，服务端抗住了 3 万连接并发请求，也没有发生全连接队列溢出的现象了。
如果持续不断地有连接因为 TCP 全连接队列溢出被丢弃，就应该调大 backlog 以及 somaxconn 参数。

文章插图
实战 - TCP 半连接队列溢出
1、如何查看 TCP 半连接队列长度？
很遗憾，TCP 半连接队列长度的长度，没有像全连接队列那样可以用 ss 命令查看。
但是我们可以抓住 TCP 半连接的特点，就是服务端处于 SYN_RECV 状态的 TCP 连接，就是在 TCP 半连接队列。
于是，我们可以使用如下命令计算当前 TCP 半连接队列长度：

文章插图
2、如何模拟 TCP 半连接队列溢出场景？
模拟 TCP 半连接溢出场景不难，实际上就是对服务端一直发送 TCP SYN 包，但是不回第三次握手 ACK，这样就会使得服务端有大量的处于 SYN_RECV 状态的 TCP 连接。
这其实也就是所谓的 SYN 洪泛、SYN 攻击、DDoS 攻击。

文章插图
测试环境
实验环境：

客户端和服务端都是 CentOs 6.5 ，Linux 内核版本 2.6.32
服务端 IP 192.168.3.200，客户端 IP 192.168.3.100
服务端是 Nginx 服务，端口为 8088

注意：本次模拟实验是没有开启 tcp_syncookies，关于 tcp_syncookies 的作用，后续会说明。
本次实验使用 hping3 工具模拟 SYN 攻击：

文章插图
当服务端受到 SYN 攻击后，连接服务端 ssh 就会断开了，无法再连上。只能在服务端主机上执行查看当前 TCP 半连接队列大小：

文章插图
同时，还可以通过 netstat -s 观察半连接队列溢出的情况：

文章插图
上面输出的数值是累计值，表示共有多少个 TCP 连接因为半连接队列溢出而被丢弃。隔几秒执行几次，如果有上升的趋势，说明当前存在半连接队列溢出的现象。3、大部分人都说 tcp_max_syn_backlog 是指定半连接队列的大小，是真的吗？
很遗憾，半连接队列的大小并不单单只跟 tcp_max_syn_backlog 有关系。
上面模拟 SYN 攻击场景时，服务端的 tcp_max_syn_backlog 的默认值如下：

文章插图
但是在测试的时候发现，服务端最多只有 256 个半连接队列，而不是 512，所以半连接队列的最大长度不一定由 tcp_max_syn_backlog 值决定的。4、走进 Linux 内核的源码，来分析 TCP 半连接队列的最大值是如何决定的。
TCP 第一次握手（收到 SYN 包）的 Linux 内核代码如下，其中缩减了大量的代码，只需要重点关注 TCP 半连接队列溢出的处理逻辑：

文章插图
从源码中，我可以得出共有三个条件因队列长度的关系而被丢弃的：

文章插图

如果半连接队列满了，并且没有开启 tcp_syncookies，则会丢弃；
若全连接队列满了，且没有重传 SYN+ACK 包的连接请求多于 1 个，则会丢弃；
如果没有开启 tcp_syncookies，并且 max_syn_backlog 减去当前半连接队列长度小于 (max_syn_backlog >> 2)，则会丢弃；

关于 tcp_syncookies 的设置，后面在详细说明，可以先给大家说一下，开启 tcp_syncookies 是缓解 SYN 攻击其中一个手段。
接下来，我们继续跟一下检测半连接队列是否满的函数
inet_csk_reqsk_queue_is_full 和检测全连接队列是否满的函数 sk_acceptq_is_full ：

文章插图
从上面源码，可以得知：

全连接队列的最大值是 sk_max_ack_backlog 变量，sk_max_ack_backlog 实际上是在 listen 源码里指定的，也就是 min(somaxconn, backlog)；
半连接队列的最大值是 max_qlen_log 变量，max_qlen_log 是在哪指定的呢？现在暂时还不知道，我们继续跟进；

我们继续跟进代码，看一下是哪里初始化了半连接队列的最大值 max_qlen_log：