多队列部分队列没有包_TCP半连接队列和全连接队列满了会发生什么？又该如何应对？...

(给Linux爱好者加星标&＃xff0c;提升Linux技能)

转自&＃xff1a;小林coding(本文来自作者投稿)

前言

网上许多博客针对增大 TCP 半连接队列和全连接队列的方式如下&＃xff1a;

• 增大 TCP 半连接队列方式是增大 tcp_max_syn_backlog&＃xff1b;

• 增大 TCP 全连接队列方式是增大 listen() 函数中的 backlog&＃xff1b;

这里先跟大家说下&＃xff0c;上面的方式都是不准确的。

“你怎么知道不准确&＃xff1f;”

很简单呀&＃xff0c;因为我做了实验和看了 TCP 协议栈的内核源码&＃xff0c;发现要增大这两个队列长度&＃xff0c;不是简简单单增大某一个参数就可以的。

接下来&＃xff0c;就会以实战 &＃43; 源码分析&＃xff0c;带大家解密 TCP 半连接队列和全连接队列。

“源码分析&＃xff0c;那不是劝退吗&＃xff1f;我们搞 Java 的看不懂呀”

放心&＃xff0c;本文的源码分析不会涉及很深的知识&＃xff0c;因为都被我删减了&＃xff0c;你只需要会条件判断语句 if、左移右移操作符、加减法等基本语法&＃xff0c;就可以看懂。

另外&＃xff0c;不仅有源码分析&＃xff0c;还会介绍 Linux 排查半连接队列和全连接队列的命令。

“哦&＃xff1f;似乎很有看头&＃xff0c;那我姑且看一下吧&＃xff01;”

行&＃xff0c;没有被劝退的小伙伴&＃xff0c;值得鼓励&＃xff0c;下面这图是本文的提纲&＃xff1a;

正文

什么是 TCP 半连接队列和全连接队列&＃xff1f;

在 TCP 三次握手的时候&＃xff0c;Linux 内核会维护两个队列&＃xff0c;分别是&＃xff1a;

• 半连接队列&＃xff0c;也称 SYN 队列&＃xff1b;

• 全连接队列&＃xff0c;也称 accepet 队列&＃xff1b;

服务端收到客户端发起的 SYN 请求后&＃xff0c;内核会把该连接存储到半连接队列&＃xff0c;并向客户端响应 SYN&＃43;ACK&＃xff0c;接着客户端会返回 ACK&＃xff0c;服务端收到第三次握手的 ACK 后&＃xff0c;内核会把连接从半连接队列移除&＃xff0c;然后创建新的完全的连接&＃xff0c;并将其添加到 accept 队列&＃xff0c;等待进程调用 accept 函数时把连接取出来。

不管是半连接队列还是全连接队列&＃xff0c;都有最大长度限制&＃xff0c;超过限制时&＃xff0c;内核会直接丢弃&＃xff0c;或返回 RST 包。

实战 - TCP 全连接队列溢出

如何知道应用程序的 TCP 全连接队列大小&＃xff1f;

在服务端可以使用 ss 命令&＃xff0c;来查看 TCP 全连接队列的情况&＃xff1a;

但需要注意的是 ss 命令获取的 Recv-Q/Send-Q 在「LISTEN 状态」和「非 LISTEN 状态」所表达的含义是不同的。从下面的内核代码可以看出区别&＃xff1a;

在「LISTEN 状态」时&＃xff0c;Recv-Q/Send-Q 表示的含义如下&＃xff1a;

• Recv-Q&＃xff1a;当前全连接队列的大小&＃xff0c;也就是当前已完成三次握手并等待服务端 accept() 的 TCP 连接个数&＃xff1b;

• Send-Q&＃xff1a;当前全连接最大队列长度&＃xff0c;上面的输出结果说明监听 8088 端口的 TCP 服务进程&＃xff0c;最大全连接长度为 128&＃xff1b;

在「非 LISTEN 状态」时&＃xff0c;Recv-Q/Send-Q 表示的含义如下&＃xff1a;

• Recv-Q&＃xff1a;已收到但未被应用进程读取的字节数&＃xff1b;

• Send-Q&＃xff1a;已发送但未收到确认的字节数&＃xff1b;

如何模拟 TCP 全连接队列溢出的场景&＃xff1f;

实验环境&＃xff1a;

• 客户端和服务端都是 CentOs 6.5 &＃xff0c;Linux 内核版本 2.6.32

• 服务端 IP 192.168.3.200&＃xff0c;客户端 IP 192.168.3.100

• 服务端是 Nginx 服务&＃xff0c;端口为 8088

这里先介绍下 wrk 工具&＃xff0c;它是一款简单的 HTTP 压测工具&＃xff0c;它能够在单机多核 CPU 的条件下&＃xff0c;使用系统自带的高性能 I/O 机制&＃xff0c;通过多线程和事件模式&＃xff0c;对目标机器产生大量的负载。

本次模拟实验就使用 wrk 工具来压力测试服务端&＃xff0c;发起大量的请求&＃xff0c;一起看看服务端 TCP 全连接队列满了会发生什么&＃xff1f;有什么观察指标&＃xff1f;

客户端执行 wrk 命令对服务端发起压力测试&＃xff0c;并发 3 万个连接&＃xff1a;

在服务端可以使用 ss 命令&＃xff0c;来查看当前 TCP 全连接队列的情况&＃xff1a;

其间共执行了两次 ss 命令&＃xff0c;从上面的输出结果&＃xff0c;可以发现当前 TCP 全连接队列上升到了 129 大小&＃xff0c;超过了最大 TCP 全连接队列。

当超过了 TCP 最大全连接队列&＃xff0c;服务端则会丢掉后续进来的 TCP 连接&＃xff0c;丢掉的 TCP 连接的个数会被统计起来&＃xff0c;我们可以使用 netstat -s 命令来查看&＃xff1a;

上面看到的 41150 times &＃xff0c;表示全连接队列溢出的次数&＃xff0c;注意这个是累计值。可以隔几秒钟执行下&＃xff0c;如果这个数字一直在增加的话肯定全连接队列偶尔满了。

从上面的模拟结果&＃xff0c;可以得知&＃xff0c;当服务端并发处理大量请求时&＃xff0c;如果 TCP 全连接队列过小&＃xff0c;就容易溢出。发生 TCP 全连接队溢出的时候&＃xff0c;后续的请求就会被丢弃&＃xff0c;这样就会出现服务端请求数量上不去的现象。

全连接队列满了&＃xff0c;就只会丢弃连接吗&＃xff1f;

实际上&＃xff0c;丢弃连接只是 Linux 的默认行为&＃xff0c;我们还可以选择向客户端发送 RST 复位报文&＃xff0c;告诉客户端连接已经建立失败。

tcp_abort_on_overflow 共有两个值分别是 0 和 1&＃xff0c;其分别表示&＃xff1a;

• 0 &＃xff1a;表示如果全连接队列满了&＃xff0c;那么 server 扔掉 client  发过来的 ack &＃xff1b;

• 1 &＃xff1a;表示如果全连接队列满了&＃xff0c;那么 server 发送一个 reset 包给 client&＃xff0c;表示废掉这个握手过程和这个连接&＃xff1b;

如果要想知道客户端连接不上服务端&＃xff0c;是不是服务端 TCP 全连接队列满的原因&＃xff0c;那么可以把 tcp_abort_on_overflow 设置为 1&＃xff0c;这时如果在客户端异常中可以看到很多 connection reset by peer 的错误&＃xff0c;那么就可以证明是由于服务端 TCP 全连接队列溢出的问题。

通常情况下&＃xff0c;应当把 tcp_abort_on_overflow 设置为 0&＃xff0c;因为这样更有利于应对突发流量。

举个例子&＃xff0c;当 TCP 全连接队列满导致服务器丢掉了 ACK&＃xff0c;与此同时&＃xff0c;客户端的连接状态却是 ESTABLISHED&＃xff0c;进程就在建立好的连接上发送请求。只要服务器没有为请求回复 ACK&＃xff0c;请求就会被多次重发。如果服务器上的进程只是短暂的繁忙造成 accept 队列满&＃xff0c;那么当 TCP 全连接队列有空位时&＃xff0c;再次接收到的请求报文由于含有 ACK&＃xff0c;仍然会触发服务器端成功建立连接。

所以&＃xff0c;tcp_abort_on_overflow 设为 0 可以提高连接建立的成功率&＃xff0c;只有你非常肯定 TCP 全连接队列会长期溢出时&＃xff0c;才能设置为 1 以尽快通知客户端。

如何增大 TCP 全连接队列呢&＃xff1f;

是的&＃xff0c;当发现 TCP 全连接队列发生溢出的时候&＃xff0c;我们就需要增大该队列的大小&＃xff0c;以便可以应对客户端大量的请求。

TCP 全连接队列足最大值取决于 somaxconn 和 backlog 之间的最小值&＃xff0c;也就是 min(somaxconn, backlog)。从下面的 Linux 内核代码可以得知&＃xff1a;

• somaxconn 是 Linux 内核的参数&＃xff0c;默认值是 128&＃xff0c;可以通过 /proc/sys/net/core/somaxconn 来设置其值&＃xff1b;

• backlog 是 listen(int sockfd, int backlog) 函数中的 backlog 大小&＃xff0c;Nginx 默认值是 511&＃xff0c;可以通过修改配置文件设置其长度&＃xff1b;

前面模拟测试中&＃xff0c;我的测试环境&＃xff1a;

• somaxconn 是默认值 128&＃xff1b;

• Nginx 的 backlog 是默认值 511

所以测试环境的 TCP 全连接队列最大值为 min(128, 511)&＃xff0c;也就是 128&＃xff0c;可以执行 ss 命令查看&＃xff1a;

现在我们重新压测&＃xff0c;把 TCP 全连接队列搞大&＃xff0c;把 somaxconn 设置成 5000&＃xff1a;

接着把 Nginx 的 backlog 也同样设置成 5000&＃xff1a;

最后要重启 Nginx 服务&＃xff0c;因为只有重新调用 listen() 函数&＃xff0c; TCP 全连接队列才会重新初始化。

重启完后 Nginx 服务后&＃xff0c;服务端执行 ss 命令&＃xff0c;查看 TCP 全连接队列大小&＃xff1a;

从执行结果&＃xff0c;可以发现 TCP 全连接最大值为 5000。

增大 TCP 全连接队列后&＃xff0c;继续压测

客户端同样以 3 万个连接并发发送请求给服务端&＃xff1a;

服务端执行 ss 命令&＃xff0c;查看 TCP 全连接队列使用情况&＃xff1a;

从上面的执行结果&＃xff0c;可以发现全连接队列使用增长的很快&＃xff0c;但是一直都没有超过最大值&＃xff0c;所以就不会溢出&＃xff0c;那么 netstat -s 就不会有 TCP 全连接队列溢出个数的显示&＃xff1a;

说明 TCP 全连接队列最大值从 128 增大到 5000 后&＃xff0c;服务端抗住了 3 万连接并发请求&＃xff0c;也没有发生全连接队列溢出的现象了。

如果持续不断地有连接因为 TCP 全连接队列溢出被丢弃&＃xff0c;就应该调大 backlog 以及 somaxconn 参数。

实战 - TCP 半连接队列溢出

如何查看 TCP 半连接队列长度&＃xff1f;

很遗憾&＃xff0c;TCP 半连接队列长度的长度&＃xff0c;没有像全连接队列那样可以用 ss 命令查看。

但是我们可以抓住 TCP 半连接的特点&＃xff0c;就是服务端处于 SYN_RECV 状态的 TCP 连接&＃xff0c;就是在 TCP 半连接队列。

于是&＃xff0c;我们可以使用如下命令计算当前 TCP 半连接队列长度&＃xff1a;

如何模拟 TCP 半连接队列溢出场景&＃xff1f;

模拟 TCP 半连接溢出场景不难&＃xff0c;实际上就是对服务端一直发送 TCP SYN 包&＃xff0c;但是不回第三次握手 ACK&＃xff0c;这样就会使得服务端有大量的处于 SYN_RECV 状态的 TCP 连接。

这其实也就是所谓的 SYN 洪泛、SYN 攻击、DDos 攻击。

实验环境&＃xff1a;

• 客户端和服务端都是 CentOs 6.5 &＃xff0c;Linux 内核版本 2.6.32

• 服务端 IP 192.168.3.200&＃xff0c;客户端 IP 192.168.3.100

• 服务端是 Nginx 服务&＃xff0c;端口为 8088

注意&＃xff1a;本次模拟实验是没有开启 tcp_synCOOKIEs&＃xff0c;关于 tcp_synCOOKIEs 的作用&＃xff0c;后续会说明。

本次实验使用 hping3 工具模拟 SYN 攻击&＃xff1a;

当服务端受到 SYN 攻击后&＃xff0c;连接服务端 ssh 就会断开了&＃xff0c;无法再连上。只能在服务端主机上执行查看当前 TCP 半连接队列大小&＃xff1a;

同时&＃xff0c;还可以通过 netstat -s 观察半连接队列溢出的情况&＃xff1a;

上面输出的数值是累计值&＃xff0c;表示共有多少个 TCP 连接因为半连接队列溢出而被丢弃。隔几秒执行几次&＃xff0c;如果有上升的趋势&＃xff0c;说明当前存在半连接队列溢出的现象。

大部分人都说 tcp_max_syn_backlog 是指定半连接队列的大小&＃xff0c;是真的吗&＃xff1f;

很遗憾&＃xff0c;半连接队列的大小并不单单只跟 tcp_max_syn_backlog 有关系。

上面模拟 SYN 攻击场景时&＃xff0c;服务端的 tcp_max_syn_backlog 的默认值如下&＃xff1a;

但是在测试的时候发现&＃xff0c;服务端最多只有 256 个半连接队列&＃xff0c;而不是 512&＃xff0c;所以半连接队列的最大长度不一定由 tcp_max_syn_backlog 值决定的。

接下来&＃xff0c;走进 Linux 内核的源码&＃xff0c;来分析 TCP 半连接队列的最大值是如何决定的。

TCP 第一次握手(收到 SYN 包)的 Linux 内核代码如下&＃xff0c;其中缩减了大量的代码&＃xff0c;只需要重点关注 TCP 半连接队列溢出的处理逻辑&＃xff1a;

从源码中&＃xff0c;我可以得出共有三个条件因队列长度的关系而被丢弃的&＃xff1a;

1. 如果半连接队列满了&＃xff0c;并且没有开启 tcp_synCOOKIEs&＃xff0c;则会丢弃&＃xff1b;

2. 若全连接队列满了&＃xff0c;且没有重传 SYN&＃43;ACK 包的连接请求多于 1 个&＃xff0c;则会丢弃&＃xff1b;

3. 如果没有开启 tcp_synCOOKIEs&＃xff0c;并且 max_syn_backlog 减去 当前半连接队列长度小于 (max_syn_backlog >> 2)&＃xff0c;则会丢弃&＃xff1b;

关于 tcp_synCOOKIEs 的设置&＃xff0c;后面在详细说明&＃xff0c;可以先给大家说一下&＃xff0c;开启 tcp_synCOOKIEs 是缓解 SYN 攻击其中一个手段。

接下来&＃xff0c;我们继续跟一下检测半连接队列是否满的函数 inet_csk_reqsk_queue_is_full 和 检测全连接队列是否满的函数 sk_acceptq_is_full &＃xff1a;

从上面源码&＃xff0c;可以得知&＃xff1a;

• 全连接队列的最大值是 sk_max_ack_backlog 变量&＃xff0c;sk_max_ack_backlog 实际上是在 listen() 源码里指定的&＃xff0c;也就是 min(somaxconn, backlog)&＃xff1b;

• 半连接队列的最大值是 max_qlen_log 变量&＃xff0c;max_qlen_log 是在哪指定的呢&＃xff1f;现在暂时还不知道&＃xff0c;我们继续跟进&＃xff1b;

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

从上面的代码中&＃xff0c;我们可以算出 max_qlen_log 是 8&＃xff0c;于是代入到 检测半连接队列是否满的函数 reqsk_queue_is_full &＃xff1a;

也就是 qlen >> 8 什么时候为 1 就代表半连接队列满了。这计算这不难&＃xff0c;很明显是当 qlen 为 256 时&＃xff0c;256 >> 8 &＃61; 1。

至此&＃xff0c;总算知道为什么上面模拟测试 SYN 攻击的时候&＃xff0c;服务端处于 SYN_RECV 连接最大只有 256 个。

可见&＃xff0c;半连接队列最大值不是单单由 max_syn_backlog 决定&＃xff0c;还跟 somaxconn 和 backlog 有关系。

在 Linux 2.6.32 内核版本&＃xff0c;它们之间的关系&＃xff0c;总体可以概况为&＃xff1a;

1. 当 max_syn_backlog > min(somaxconn, backlog) 时&＃xff0c; 半连接队列最大值 max_qlen_log &＃61; min(somaxconn, backlog) * 2;

2. 当 max_syn_backlog

半连接队列最大值 max_qlen_log 就表示服务端处于 SYN_REVC 状态的最大个数吗&＃xff1f;

依然很遗憾&＃xff0c;并不是。

max_qlen_log 是理论半连接队列最大值&＃xff0c;并不一定代表服务端处于 SYN_REVC 状态的最大个数。

在前面我们在分析 TCP 第一次握手(收到 SYN 包)时会被丢弃的三种条件&＃xff1a;

1. 如果半连接队列满了&＃xff0c;并且没有开启 tcp_synCOOKIEs&＃xff0c;则会丢弃&＃xff1b;

2. 若全连接队列满了&＃xff0c;且没有重传 SYN&＃43;ACK 包的连接请求多于 1 个&＃xff0c;则会丢弃&＃xff1b;

3. 如果没有开启 tcp_synCOOKIEs&＃xff0c;并且 max_syn_backlog 减去 当前半连接队列长度小于 (max_syn_backlog >> 2)&＃xff0c;则会丢弃&＃xff1b;

假设条件 1 当前半连接队列的长度 「没有超过」理论的半连接队列最大值  max_qlen_log&＃xff0c;那么如果条件 3 成立&＃xff0c;则依然会丢弃 SYN 包&＃xff0c;也就会使得服务端处于 SYN_REVC 状态的最大个数不会是理论值 max_qlen_log。

似乎很难理解&＃xff0c;我们继续接着做实验&＃xff0c;实验见真知。

服务端环境如下&＃xff1a;

配置完后&＃xff0c;服务端要重启 Nginx&＃xff0c;因为全连接队列最大和半连接队列最大值是在 listen() 函数初始化。

根据前面的源码分析&＃xff0c;我们可以计算出半连接队列 max_qlen_log 的最大值为 256&＃xff1a;

客户端执行 hping3 发起 SYN 攻击&＃xff1a;

服务端执行如下命令&＃xff0c;查看处于 SYN_RECV 状态的最大个数&＃xff1a;

可以发现&＃xff0c;服务端处于 SYN_RECV 状态的最大个数并不是 max_qlen_log 变量的值。

这就是前面所说的原因&＃xff1a;如果当前半连接队列的长度 「没有超过」理论半连接队列最大值  max_qlen_log&＃xff0c;那么如果条件 3 成立&＃xff0c;则依然会丢弃 SYN 包&＃xff0c;也就会使得服务端处于 SYN_REVC 状态的最大个数不会是理论值 max_qlen_log。

我们来分析一波条件 3 :

从上面的分析&＃xff0c;可以得知如果触发「当前半连接队列长度 > 192」条件&＃xff0c;TCP 第一次握手的 SYN 包是会被丢弃的。

在前面我们测试的结果&＃xff0c;服务端处于 SYN_RECV 状态的最大个数是 193&＃xff0c;正好是触发了条件 3&＃xff0c;所以处于 SYN_RECV 状态的个数还没到「理论半连接队列最大值 256」&＃xff0c;就已经把 SYN 包丢弃了。

所以&＃xff0c;服务端处于 SYN_RECV 状态的最大个数分为如下两种情况&＃xff1a;

1. 如果「当前半连接队列」没超过「理论半连接队列最大值」&＃xff0c;但是超过 max_syn_backlog - (max_syn_backlog >> 2)&＃xff0c;那么处于 SYN_RECV 状态的最大个数就是 max_syn_backlog - (max_syn_backlog >> 2)&＃xff1b;

2. 如果「当前半连接队列」超过「理论半连接队列最大值」&＃xff0c;那么处于 SYN_RECV 状态的最大个数就是「理论半连接队列最大值」&＃xff1b;

每个 Linux 内核版本「理论」半连接最大值计算方式会不同。

在上面我们是针对 Linux 2.6.32 版本分析的「理论」半连接最大值的算法&＃xff0c;可能每个版本有些不同。

比如在 Linux 5.0.0 的时候&＃xff0c;「理论」半连接最大值就是全连接队列最大值&＃xff0c;但依然还是有队列溢出的三个条件&＃xff1a;

如果 SYN 半连接队列已满&＃xff0c;只能丢弃连接吗&＃xff1f;

并不是这样&＃xff0c;开启 synCOOKIEs 功能就可以在不使用 SYN 半连接队列的情况下成功建立连接&＃xff0c;在前面我们源码分析也可以看到这点&＃xff0c;当开启了  synCOOKIEs 功能就不会丢弃连接。

synCOOKIEs 是这么做的&＃xff1a;服务器根据当前状态计算出一个值&＃xff0c;放在己方发出的 SYN&＃43;ACK 报文中发出&＃xff0c;当客户端返回 ACK 报文时&＃xff0c;取出该值验证&＃xff0c;如果合法&＃xff0c;就认为连接建立成功&＃xff0c;如下图所示。

synCOOKIEs 参数主要有以下三个值&＃xff1a;

• 0 值&＃xff0c;表示关闭该功能&＃xff1b;

• 1 值&＃xff0c;表示仅当 SYN 半连接队列放不下时&＃xff0c;再启用它&＃xff1b;

• 2 值&＃xff0c;表示无条件开启功能&＃xff1b;

那么在应对 SYN 攻击时&＃xff0c;只需要设置为 1 即可&＃xff1a;

如何防御 SYN 攻击&＃xff1f;

这里给出几种防御 SYN 攻击的方法&＃xff1a;

• 增大半连接队列&＃xff1b;

• 开启 tcp_synCOOKIEs 功能

• 减少 SYN&＃43;ACK 重传次数

方式一&＃xff1a;增大半连接队列

在前面源码和实验中&＃xff0c;得知要想增大半连接队列&＃xff0c;我们得知不能只单纯增大 tcp_max_syn_backlog 的值&＃xff0c;还需一同增大 somaxconn 和 backlog&＃xff0c;也就是增大全连接队列。否则&＃xff0c;只单纯增大 tcp_max_syn_backlog 是无效的。

增大 tcp_max_syn_backlog 和 somaxconn 的方法是修改 Linux 内核参数&＃xff1a;

增大 backlog 的方式&＃xff0c;每个 Web 服务都不同&＃xff0c;比如 Nginx 增大 backlog 的方法如下&＃xff1a;

最后&＃xff0c;改变了如上这些参数后&＃xff0c;要重启 Nginx 服务&＃xff0c;因为半连接队列和全连接队列都是在 listen() 初始化的。

方式二&＃xff1a;开启 tcp_synCOOKIEs 功能

开启 tcp_synCOOKIEs 功能的方式也很简单&＃xff0c;修改 Linux 内核参数&＃xff1a;

方式三&＃xff1a;减少 SYN&＃43;ACK 重传次数

当服务端受到 SYN 攻击时&＃xff0c;就会有大量处于 SYN_REVC 状态的 TCP 连接&＃xff0c;处于这个状态的 TCP 会重传 SYN&＃43;ACK &＃xff0c;当重传超过次数达到上限后&＃xff0c;就会断开连接。

那么针对 SYN 攻击的场景&＃xff0c;我们可以减少 SYN&＃43;ACK 的重传次数&＃xff0c;以加快处于 SYN_REVC 状态的 TCP 连接断开。

- EOF -

1、Linux TCP GSO 和 TSO 实现&＃xff1b;

2、下一代 HTTP 底层协议将改用 QUIC 技术&＃xff1b;

3、Edge 浏览器 Linux 版要来了&＃xff1b;

看完本文有收获&＃xff1f;请分享给更多人

关注「Linux 爱好者」加星标&＃xff0c;提升Linux技能

好文章&＃xff0c;我在看❤️