- Published on
Linux TCP半连接/全连接队列溢出原理与实战调优
- Authors
- Name
- Liant
一、半连接与全连接
在 TCP三次握手的时候, Linux内核会维护两个队列, 分别是: 半连接队列, 也称 SYN 队列; 全连接队列, 也称 accepet 队列;
服务端收到客户端发起的 SYN 请求后, 内核会把该连接存储到半连接队列,并向客户端响应SYN+ACK, 接着客户端会返回 ACK, 服务端收到第三次握手的 ACK 后, 内核会把连接从半连接队列移除, 然后创建新的完全的连接, 并将其添加到 accept 队列, 等待进程调用 accept 函数时把连接取出来:
1.全连接溢出
不管是半连接队列还是全连接队列, 都有最大长度限制, 超过限制时, 内核会直接丢弃, 或返回RST包。
TCP全连接队列溢出如何查看全连接队列大小?在服务端可以使用 ss 命令, 来查看 TCP 全连接队列的情况, ss是Socket Statistics的缩写。顾名思义, ss命令可以用来获socket统计信息, 它可以显示和netstat类似的内容。
但ss的优势在于它能够显示更多更详细的有关TCP和连接状态的信息,而且比netstat更快速更高效。
netstat命令用来打印Linux中网络系统的状态信息, 可让你得知整个Linux系统的网络情况。
但需要注意的是ss命令获取的 Recv-Q/Send-Q在「LISTEN 状态」和「非 LISTEN状态」所表达的含义是不同的。
从下面的内核代码可以看出区别:
利用 ss -lnt 命令可以查看socket信息, 参数含义如下:
-l: --listening 显示监听状态的套接字(sockets)
-n: --numeric 不解析服务名称
-t: --tcp 仅显示tcp协议的socket
在「LISTEN 状态」时, 利用ss -lnt 命令, Recv-Q/Send-Q 表示的含义如下:
Recv-Q: 当前全连接队列的大小, 也就是当前已完成三次握手并等待服务端 accept()的TCP连接
Send-Q: 当前全连接最大队列长度, 上面的输出结果说明监听8088端口的TCP服务, 最大全连接长度为 128
在「非 LISTEN 状态」时, 利用ss -nt 命令Recv-Q/Send-Q 表示的含义如下:
Recv-Q: 已收到但未被应用进程读取的字节数;
Send-Q: 已发送但未收到确认的字节数;
实验环境:
客户端和服务端都是 CentOs 6.5 (Linux 内核版本 2.6.32)
服务端 IP 192.168.127.150
客户端 IP 192.168.127.151
服务端是 Nginx 服务, 端口为 8088,客户端利用wrk工具wrk工具, 它是一款简单的HTTP压测工具, 它能够在单机多核 CPU 的条件下, 使用系统自带的高性能 I/O 机制, 通过多线程和事件模式,对目标机器产生大量的负载。
本次模拟实验就使用wrk工具来压力测试服务端, 发起大量的请求, 一起看看服务端 TCP 全连接队列满了会发生什么, 有什么观察指标。
客户端执行wrk命令对服务端发起压力测试, 并发 3 万个连接:
-t 6: 表示6个线程
-c 30000: 表示3万个连接
-d 60s: 表示持续压测60s在服务端使用 ss 命令, 来查看当前 TCP 全连接队列的情况:
其间共执行了两次 ss 命令, 从上面的输出结果, 可以发现当前TCP全连接队列上升到了129大小, 超过了最大TCP全连接队列的值128。
当超过了TCP最大全连接队列, 服务端则会丢掉后续进来的TCP连接,丢掉的TCP连接的个数会被统计起来, 我们在服务端可以使用 netstat -s 命令来查看:
上面看到的 1750、2287...times , 表示全连接队列溢出的次数, 注意这个是累计值。可以隔几秒钟执行下, 如果这个数字一直在增加的话肯定全连接队列偶尔满了。客户端执行wrk命令最后的结果:
从上面的模拟结果, 可以得知, 当服务端并发处理大量请求时, 如果 TCP 全连接队列过小, 就容易溢出。发生 TCP 全连接队溢出的时候, 后续的请求就会被丢弃。
Linux有个参数可以指定当TCP全连接队列满了会使用什么策略来回应客户端。
tcp_abort_on_overflow 共有两个值分别是 0 和 1, 其分别表示:
0 : 如果全连接队列满了, 那么 server 扔掉 client 发过来的 ack
1 : 如果全连接队列满了, server 发送一个 reset包给client, 表示废掉这个握手过程和这个连接
如果要想知道客户端连接不上服务端, 是不是服务端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_abort_on_overflow 的值设为 1后, 重复上述实验。
在客户端继续执行3W次压测:
可以明显看到Socket errors中 read错误 和 write错误 与 tcp_abort_on_overflow 设为 0之前大幅度增加!
2.如何增大全连接队列呢？
当发现TCP全连接队列发生溢出的时候, 我们就需要增大该队列的大小, 以便可以应对客户端大量的请求。
TCP 全连接队列足最大值取决于 somaxconn 和 backlog 之间的最小值, 也就是 min(somaxconn,backlog)。
从下面的 Linux内核代码可以得知:
somaxconn 是 Linux 内核的参数, 默认值是 128, 可以通过 /proc/sys/net/core/somaxconn 来设置其值
backlog 是 listen(int sockfd, int backlog) 函数中的backlog大小, Nginx 默认值是 511, 可以通过修改配置文件设置其长度
前面模拟测试中, 我的测试环境: somaxconn 是默认值 128, Nginx 的 backlog 是默认值 511现在我们重新压测, 把TCP全连接队列搞大, 把 somaxconn 设置成 5000:
接着把 Nginx 的 backlog 也同样设置成5000:
设置完毕后进入nginx下的sbin目录执行以下命令nginx -s reload,服务端执行 ss 命令, 查看TCP全连接队列大小:
从执行结果, 可以发现TCP全连接最大值为 5000。紧接着在客户端以3万个连接并发发送请求给服务端, 继续压测:
服务端执行 ss 命令, 查看 TCP全连接队列使用情况:
从上面的执行结果, 可以发现全连接队列使用增长的很快, 但是一直都没有超过最大值, 所以就不会溢出, 那么 netstat -s 的值就不会改变:
说明TCP全连接队列最大值从128增大到5000后, 服务端抗住了3万连接并发请求, 也没有发生全连接队列溢出的现象了。
如果持续不断地有连接因为 TCP 全连接队列溢出被丢弃, 就应该调大 backlog 以及 somaxconn 参数。
3.半连接队列溢出
如何查看半连接队列大小? 很遗憾, TCP 半连接队列长度的长度, 没有像全连接队列那样可以用 ss 命令查看。
但是我们可以抓住TCP半连接的特点, 就是服务端处于SYN_RECV 状态的 TCP 连接, 就是在 TCP 半连接队列。
模拟TCP半连接溢出场景不难, 实际上就是对服务端一直发送 TCP SYN 包, 但是不回第三次握手 ACK, 这样就会使得服务端有大量的处于 SYN_RECV 状态的 TCP 连接。
这其实也就是所谓的 SYN 洪泛、SYN 攻击、DDos 攻击
实验环境:
客户端和服务端都是 CentOs 6.5 , Linux 内核版本 2.6.32
服务端 IP 192.168.127.153
客户端 IP 192.168.127.152(由于采用的是DHCP动态分配IP地址, 所以和上一个实验相比, 服务端和客户端的IP地址都改变了, 建议使用静态地址!)
服务端是 Nginx 服务, 端口为 8088客户端利用hping3工具模拟SYN攻击注意: 本次模拟实验是没有开启tcp_syncookies, 关于 tcp_syncookies 的作用, 后续会说明。centos6.5是默认开启tcp_syncookies的,必须主动关闭。
本次实验使用 hping3 工具模拟 SYN攻击:
-S: 表示发生SYN数据包
-p: 表示攻击的端口
--flood: 和洪水一样不停的攻击
--rand-source: 随机构造发送方的IP地址
我们在服务端主机上执行查看当前TCP半连接队列大小:
可以发现最大值到256就不再变化, 说明当前TCP半连接队列的最大值为256。同时, 如果半连接队列满了且tcp_syncookies未开启, 则客户端发送至服务端的正常请求连接数据包将会被丢弃, 利用curl命令证明了这一点:
4.内核参数解释
网上都说tcp_max_syn_backlog是指定半连接队列的大小, 是真的吗?
先说结论, 在centos6.5(linux内核2.6.32)环境下, 半连接队列最大值不是单单由 tcp_max_syn_backlog 决定, 还跟somaxconn 和 backlog 有关系。上面模拟 SYN 攻击场景时, 服务端的 tcp_max_syn_backlog的默认值如下:
但是在测试的时候发现, 服务端最多只有256个半连接队列, 而不是512, 所以半连接队列的最大长度不一定由 tcp_max_syn_backlog 值决定的。
源码分析半连接队列的最大值是如何决定的?
先说结论: 当tcp_max_syn_backlog > min(somaxconn, backlog) 时, 半连接队列最大值 max_qlen_log = min(somaxconn, backlog) * 2;
当tcp_max_syn_backlog < min(somaxconn, backlog) 时, 半连接队列最大值 max_qlen_log = tcp_max_syn_backlog * 2;
TCP 第一次握手(收到 SYN 包)的Linux 内核代码如下, 其中缩减了大量的代码, 只需要重点关注TCP半连接队列溢出的处理逻辑:
从源码中, 我可以得出共有三个条件因队列长度的关系而被丢弃的:
如果半连接队列满了, 并且没有开启 tcp_syncookies, 则会丢弃;
若全连接队列满了, 且没有重传 SYN+ACK 包的连接请求多于1个, 则会丢弃;
如果没有开启 tcp_syncookies, 并且tcp_max_syn_backlog 减去 当前半连接队列长度小于 (tcp_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:
从上面的代码中, 我们可以算出 max_qlen_log 是 8, 于是代入到 检测半连接队列是否满的函数 reqsk_queue_is_full:
也就是 qlen >> 8 什么时候为 1 就代表半连接队列满了。
这计算这不难, 很明显是当 qlen 为 256 时, 256 >> 8 = 1。
至此, 总算知道为什么上面模拟测试 SYN 攻击的时候, 服务端处于 SYN_RECV连接最大只有 256 个。
可见, 半连接队列最大值不是单单由 tcp_max_syn_backlog 决定, 还跟 somaxconn 和 backlog 有关系。
在 Linux 2.6.32 内核版本, 它们之间的关系, 总体可以概况为:
综上所述, 结论如下: 当tcp_max_syn_backlog > min(somaxconn, backlog) 时, 半连接队列最大值 max_qlen_log = min(somaxconn, backlog) * 2;
当tcp_max_syn_backlog < min(somaxconn, backlog) 时, 半连接队列最大值 max_qlen_log = tcp_max_syn_backlog * 2;
5.半连接队列最大值
max_qlen_log 就表示服务端处于 SYN_REVC 状态的最大个数吗？
首先需要明白每个 Linux 内核版本「理论」半连接最大值计算方式会不同。不谈linux内核版本介绍就是扯淡。
本文是基于Centos6.5(linux内核2.6.32)答案是否定的, max_qlen_log 是理论半连接队列最大值, 并不一定代表服务端处于 SYN_REVC 状态的最大个数。
如果「当前半连接队列」没超过「理论半连接队列最大值」, 但是超过tcp_max_syn_backlog - (tcp_max_syn_backlog >> 2), 那么处于 SYN_RECV 状态的最大个数就是 tcp_max_syn_backlog - (tcp_max_syn_backlog >>2)+1;
如果「当前半连接队列」超过「理论半连接队列最大值」, 那么处于 SYN_RECV 状态的最大个数就是「理论半连接队列最大值」;
在前面我们在分析 TCP 第一次握手(收到 SYN 包)时会被丢弃的三种条件:
- 如果半连接队列满了, 并且没有开启 tcp_syncookies, 则会丢弃;
- 若全连接队列满了, 且没有重传 SYN+ACK 包的连接请求多于 1 个, 则会丢弃; 如果没有开启 tcp_syncookies, 并且tcp_max_syn_backlog 减去 当前半连接队列长度小于 (tcp_max_syn_backlog >> 2), 则会丢弃;
- 假设条件 1 当前半连接队列的长度 「没有超过」理论的半连接队列最大值max_qlen_log, 那么如果条件 3 成立, 则依然会丢弃 SYN 包, 也就会使得服务端处于 SYN_REVC 状态的最大个数不会是理论值 max_qlen_log。
接下来我用一个实验来证明这个结论:
服务端的相关变量值如下:
根据上文的结论可以求出在这种情况下, 半连接队列理论最大值为: max_qlen_log = tcp_max_syn_backlog * 2 = 64 * 2 = 128, 客户端执行hping3发起SYN攻击:
服务端执行如下命令, 查看处于 SYN_RECV 状态的最大个数:
可以发现, 服务端处于 SYN_RECV 状态的最大个数(49)并不是半连接队列理论最大值(128).
这就是前面所说的原因: 如果当前半连接队列的长度「没有超过」理论半连接队列最大值 max_qlen_log, 那么如果条件3成立, 则依然会丢弃 SYN 包, 也就会使得服务端处于 SYN_REVC 状态的最大个数不会是理论值 max_qlen_log。
那49是如何计算出来的呢？tcp_max_syn_backlog 减去 当前半连接队列长度小于 (tcp_max_syn_backlog >> 2), 则会丢弃. 64 - 当前半连接队列长度 < 64 / 4 当前半连接队列长度 > 64 - 16 = 48, 因为处于 SYN_RECV 状态的个数还没到「理论半连接队列最大值 128」, 所以如果当前半连接队列长度 > 48,则会丢弃SYN包。
6.如果SYN半连接队列已经满了, 只能丢弃连接吗？
结论: 答案是否定的, 在前面我们源码分析也可以看到这点, 当开启了 syncookies 功能就可以在不使用 SYN半连接队列的情况下成功建立连接
tcp_syncookies 参数主要有以下三个值, 可以在 /proc/sys/net/ipv4/tcp_syncookies 修改该值。
0 值, 表示关闭该功能
1 值, 表示仅当 SYN 半连接队列放不下时, 再启用它
2 值, 表示无条件开启功能
上文也说过了, centos6.5(linun内核2.6.32)默认开启syncookies功能。
7. 如何防御SYN攻击？(当半连接队列已满, 如何调整？)这里给出几种方法: 增大半连接队列; 开启tcp_syncookies 功能减少 SYN+ACK 重传次数(减小tcp_synack_retries的值)
方式一:
增大半连接队列在前面源码和实验中, 得知要想增大半连接队列, 我们得知不能只单纯增大tcp_max_syn_backlog 的值, 还需一同增大 somaxconn 和 backlog, 也就是增大全连接队列。
否则, 只单纯增大tcp_max_syn_backlog 是无效的。
增大 tcp_max_syn_backlog和 somaxconn 的方法是修改 Linux 内核参数。
方式二:
增大backlog的方式, 每个Web服务都不同
比如 Nginx 增大 backlog的方法如下:
方式三:
减少 SYN+ACK 重传次数当服务端受到 SYN 攻击时, 就会有大量处于 SYN_REVC 状态的 TCP 连接, 处于这个状态的 TCP 会重传 SYN+ACK , 当重传超过次数达到上限后, 就会断开连接。
那么针对 SYN攻击的场景, 我们可以减少 SYN+ACK 的重传次数, 也就是修改linux内核参数 tcp_synack_retries 以加快处于 SYN_REVC 状态的 TCP 连接断开。
