TCP 半链接队列和全链接队列满了会发生什么？又该如何应对？

每日英语，天天进步一点点：

---

前言

网上许多博客针对增大 TCP 半链接队列和全链接队列的方式以下：

• 增大 TCP 半链接队列的方式是增大 /proc/sys/net/ipv4/tcp_max_syn_backlog；
• 增大 TCP 全链接队列的方式是增大 listen() 函数中的 backlog；

这里先跟你们说下，上面的方式都是不许确的。

“你怎么知道不许确？”

很简单呀，由于我作了实验和看了 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 状态」所表达的含义是不一样的。从下面的内核代码能够看出区别：

在「LISTEN 状态」时，Recv-Q/Send-Q 表示的含义以下：

• Recv-Q：当前全链接队列的大小，也就是当前已完成三次握手并等待服务端 accept() 的 TCP 链接；
• Send-Q：当前全链接最大队列长度，上面的输出结果说明监听 8088 端口的 TCP 服务，最大全链接长度为 128；

在「非 LISTEN 状态」时，Recv-Q/Send-Q 表示的含义以下：

• Recv-Q：已收到但未被应用进程读取的字节数；
• Send-Q：已发送但未收到确认的字节数；

如何模拟 TCP 全链接队列溢出的场景？

实验环境：

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

这里先介绍下 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_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 全链接队列呢？

是的，当发现 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 全链接队列最大值为 min(128, 511)，也就是 128，能够执行 ss 命令查看：

如今咱们从新压测，把 TCP 全链接队列搞大，把 somaxconn 设置成 5000：

接着把 Nginx 的 backlog 也一样设置成 5000：

最后要重启 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 攻击。

实验环境：

• 客户端和服务端都是 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 链接由于半链接队列溢出而被丢弃。隔几秒执行几回，若是有上升的趋势，说明当前存在半链接队列溢出的现象。

大部分人都说 tcp_max_syn_backlog 是指定半链接队列的大小，是真的吗？

很遗憾，半链接队列的大小并不仅仅只跟 tcp_max_syn_backlog 有关系。

上面模拟 SYN 攻击场景时，服务端的 tcp_max_syn_backlog 的默认值以下：

可是在测试的时候发现，服务端最多只有 256 个半链接队列，而不是 512，因此半链接队列的最大长度不必定由 tcp_max_syn_backlog 值决定的。

接下来，走进 Linux 内核的源码，来分析 TCP 半链接队列的最大值是如何决定的。

TCP 第一次握手（收到 SYN 包）的 Linux 内核代码以下，其中缩减了大量的代码，只须要重点关注 TCP 半链接队列溢出的处理逻辑：

从源码中，我能够得出共有三个条件因队列长度的关系而被丢弃的：

1. 若是半链接队列满了，而且没有开启 tcp_syncookies，则会丢弃；
2. 若全链接队列满了，且没有重传 SYN+ACK 包的链接请求多于 1 个，则会丢弃；
3. 若是没有开启 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：

从上面的代码中，咱们能够算出 max_qlen_log 是 8，因而代入到 检测半链接队列是否满的函数 reqsk_queue_is_full ：

也就是 qlen >> 8 何时为 1 就表明半链接队列满了。这计算这不难，很明显是当 qlen 为 256 时，256 >> 8 = 1。

至此，总算知道为何上面模拟测试 SYN 攻击的时候，服务端处于 SYN_RECV 链接最大只有 256 个。

可见，半链接队列最大值不是单单由 max_syn_backlog 决定，还跟 somaxconn 和 backlog 有关系。

在 Linux 2.6.32 内核版本，它们之间的关系，整体能够概况为：

• 当 max_syn_backlog > min(somaxconn, backlog) 时， 半链接队列最大值 max_qlen_log = min(somaxconn, backlog) * 2;
• 当 max_syn_backlog < min(somaxconn, backlog) 时， 半链接队列最大值 max_qlen_log = max_syn_backlog * 2;

半链接队列最大值 max_qlen_log 就表示服务端处于 SYN_REVC 状态的最大个数吗？

依然很遗憾，并非。

max_qlen_log 是理论半链接队列最大值，并不必定表明服务端处于 SYN_REVC 状态的最大个数。

在前面咱们在分析 TCP 第一次握手（收到 SYN 包）时会被丢弃的三种条件：

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

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

彷佛很难理解，咱们继续接着作实验，实验见真知。

服务端环境以下：

配置完后，服务端要重启 Nginx，由于全链接队列最大和半链接队列最大值是在 listen() 函数初始化。

根据前面的源码分析，咱们能够计算出半链接队列 max_qlen_log 的最大值为 256：

客户端执行 hping3 发起 SYN 攻击：

服务端执行以下命令，查看处于 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 状态的最大个数分为以下两种状况：

• 若是「当前半链接队列」没超过「理论半链接队列最大值」，可是超过 max_syn_backlog - (max_syn_backlog >> 2)，那么处于 SYN_RECV 状态的最大个数就是 max_syn_backlog - (max_syn_backlog >> 2)；
• 若是「当前半链接队列」超过「理论半链接队列最大值」，那么处于 SYN_RECV 状态的最大个数就是「理论半链接队列最大值」；

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

在上面咱们是针对 Linux 2.6.32 版本分析的「理论」半链接最大值的算法，可能每一个版本有些不一样。

好比在 Linux 5.0.0 的时候，「理论」半链接最大值就是全链接队列最大值，但依然仍是有队列溢出的三个条件：

若是 SYN 半链接队列已满，只能丢弃链接吗？

并非这样，开启 syncookies 功能就能够在不使用 SYN 半链接队列的状况下成功创建链接，在前面咱们源码分析也能够看到这点，当开启了 syncookies 功能就不会丢弃链接。

syncookies 是这么作的：服务器根据当前状态计算出一个值，放在己方发出的 SYN+ACK 报文中发出，当客户端返回 ACK 报文时，取出该值验证，若是合法，就认为链接创建成功，以下图所示。

syncookies 参数主要有如下三个值：

• 0 值，表示关闭该功能；
• 1 值，表示仅当 SYN 半链接队列放不下时，再启用它；
• 2 值，表示无条件开启功能；

那么在应对 SYN 攻击时，只须要设置为 1 便可：

如何防护 SYN 攻击？

这里给出几种防护 SYN 攻击的方法：

• 增大半链接队列；
• 开启 tcp_syncookies 功能
• 减小 SYN+ACK 重传次数

方式一：增大半链接队列

在前面源码和实验中，得知要想增大半链接队列，咱们得知不能只单纯增大 tcp_max_syn_backlog 的值，还需一同增大 somaxconn 和 backlog，也就是增大全链接队列。不然，只单纯增大 tcp_max_syn_backlog 是无效的。

增大 tcp_max_syn_backlog 和 somaxconn 的方法是修改 Linux 内核参数：

增大 backlog 的方式，每一个 Web 服务都不一样，好比 Nginx 增大 backlog 的方法以下：

最后，改变了如上这些参数后，要重启 Nginx 服务，由于半链接队列和全链接队列都是在 listen() 初始化的。

方式二：开启 tcp_syncookies 功能

开启 tcp_syncookies 功能的方式也很简单，修改 Linux 内核参数：

方式三：减小 SYN+ACK 重传次数

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

那么针对 SYN 攻击的场景，咱们能够减小 SYN+ACK 的重传次数，以加快处于 SYN_REVC 状态的 TCP 链接断开。

---

巨人的肩膀

[1] 系统性能调优必知必会.陶辉.极客时间.

[2] https://www.cnblogs.com/zengk...

[3] https://blog.cloudflare.com/s...

---

小林是专为你们图解的工具人，Goodbye，咱们下次见！