再聊 TCP backlog
这篇文章我们以 backlog 参数来深入研究一下建连的过程。通过阅读这篇文章,你会了解到下面这些知识:
backlog、半连接队列、全连接队列是什么
linux 内核是如何计算半连接队列、全连接队列的
为什么只修改系统的 somaxconn 和 tcp_max_syn_backlog 对最终的队列大小不起作用
如何使用 systemtap 探针获取当前系统的半连接、全连接队列信息
iprouter 库中的 ss 工具的原理是什么
如何快速模拟半连接队列溢出,全连接队列溢出
注:本文中的代码和测试均在内核版本 3.10.0-514.16.1.el7.x86_64 下进行。半连接队列、全连接队列基本概念为了理解 backlog,我们需要了解 listen 和 accept 函数背后的发生了什么。backlog 参数跟 listen 函数有关,listen 函数的定义如下:
当服务端调用 listen 函数时,TCP 的状态被从 CLOSE 状态变为 LISTEN,于此同时内核创建了两个队列:
半连接队列(Incomplete connection queue),又称 SYN 队列
全连接队列(Completed connection queue),又称 Accept 队列
如下图所示。
接下来开始详细介绍这两个队列相关的内容。
半连接队列(SYN Queue)
当客户端发起 SYN 到服务端,服务端收到以后会回 ACK 和自己的 SYN。这时服务端这边的 TCP 从 listen 状态变为 SYN_RCVD (SYN Received),此时会将这个连接信息放入「半连接队列」,半连接队列也被称为 SYN Queue,存储的是 “inbound SYN packets”。
服务端回复 SYN+ACK 包以后等待客户端回复 ACK,同时开启一个定时器,如果超时还未收到 ACK 会进行 SYN+ACK 的重传,重传的次数由 tcp_synack_retries 值确定。在 CentOS 上这个值等于 5。一旦收到客户端的 ACK,服务端就开始尝试把它加入另外一个全连接队列(Accept Queue)。
半连接队列的大小的计算
这里使用 SystemTap 工具插入系统探针,在收到 SYN 包以后打印当前的 SYN 队列的大小和半连接队列的总大小。TCP listen 状态的 socket 收到 SYN 包的处理流程如下
这里注入 tcp_v4_conn_request 方法,代码如下所示。
使用 stap 执行上面的脚本
这样在收到 SYN 包以后可以打印当前 syn 队列排队的连接个数和总大小了。
还是以之前的 echo 程序为例,listen 的 backlog 设置为 10,如下所示。
启动 echo-server,监听 9090 端口。然后在另外一个机器上使用 nc 命令进行连接。
此时在 stap 的输出中,已经可以看到当前的 可以看到 syn 队列大小为 0,最大的队列长度是 2^4=16
因此可以看到实际的 syn 并不是等于 net.ipv4.tcp_max_syn_backlog 的默认值为 128,而是将用户传入的 10 向上取了最接近的 2 的指数幂值 16。接下来我们来看代码中是如何计算的,半连接队列的大小与三个值有关:
用户层 listen 传入的 backlog
系统变量 net.ipv4.tcp_max_syn_backlog,默认值为 128
系统变量 net.core.somaxconn,默认值为 128
具体的计算见下面的源码,调用 listen 函数首先会进入如下的代码。
通过 SYSCALL_DEFINE2 代码可以得知,如果用户传入的 backlog 值大于系统变量 net.core.somaxconn 的值,用户设置的 backlog 不会生效,使用系统变量值,默认为 128。接下来这个 backlog 值会被依次传递给 inet_listen()->inet_csk_listen_start()->reqsk_queue_alloc() 方法。在 reqsk_queue_alloc 方法中进行了最终的计算。精简后的代码如下。
代码中 nr_table_entries 为前面计算的 backlog 值,sysctl_max_syn_backlog 为 net.ipv4.tcp_max_syn_backlog 的值。计算逻辑如下:
在 nr_table_entries 与 sysctl_max_syn_backlog 两者中的较小值,赋值给 nr_table_entries
在 nr_table_entries 和 8 取较大值,赋值给 nr_table_entries
nr_table_entries + 1 向上取求最接近的最大 2 的指数次幂
通过 for 循环找不大于 nr_table_entries 最接近的 2 的对数值
下面来举几个实际的例子,以 listen(50) 为例,经过 SYSCALL_DEFINE2 中计算 backlog 的值为 min(50, somaxconn),等于 50,接下来进入 reqsk_queue_alloc 函数的计算。
下面给了几个 somaxconn、max_syn_backlog、backlog 三者之间不同组合的最终半连接队列大小值。
可以看到:在系统参数不修改的情形,盲目调大 listen 的 backlog 对最终半连接队列的大小不会有影响。在 listen 的 backlog 不变的情况下,盲目调大 somaxconn 和 max_syn_backlog 对最终半连接队列的大小不会有影响
模拟半连接队列占满
以 somaxconn=128、tcp_max_syn_backlog=128、listen backlog=50 为例,模拟的原理是在三次握手的第二步,客户端在收到服务端回复的 SYN+ACK 以后使用 iptables 丢弃这个包。这里实验的服务端是 10.211.55.10,客户端是 10.211.55.20,在客户端使用 iptables 增加一条规则,如下所示。
接下来使用你喜欢的语言,开始发起连接就好了,这里选择了 go,代码如下:
执行这个 go 程序,在服务端使用 netstat 查看当前 9090 端口的连接状态,如下所示。
可以观察到 SYN_RECV 状态的连接个数的从 0 开始涨到 64,就不再上涨了,这里的 64 就是半连接队列的大小。接下来我们来看全连接队列
全连接队列(Accept Queue)
「全连接队列」包含了服务端所有完成了三次握手,但是还未被应用调用 accept 取走的连接队列。此时的 socket 处于 ESTABLISHED 状态。每次应用调用 accept() 函数会移除队列头的连接。如果队列为空,accept() 通常会阻塞。全连接队列也被称为 Accept 队列。你可以把这个过程想象生产者、消费者模型。内核是一个负责三次握手的生产者,握手完的连接会放入一个队列。我们的应用程序是一个消费者,取走队列中的连接进行下一步的处理。这种生产者消费者的模式,在生产过快、消费过慢的情况下就会出现队列积压。listen 函数的第二个参数 backlog 用来设置全连接队列大小,但不一定就会选用这一个 backlog 值,还受限于 somaxconn,等下会有更详细的内容说明全连接队列大小的计算规则。int listen(int sockfd, int backlog)如果全连接队列满,内核会舍弃掉 client 发过来的 ack(应用层会认为此时连接还未完全建立)我们来模拟一下全连接队列满的情况。因为只有 accept 才会移除全连接的队列,所以如果我们只 listen,不调用 accept,那么很快全连接就可以被占满。
为了贴近最底层的调用,这里用 c 语言来实现,新建一个 main.c 文件
编译运行 gcc main.c; ./a.out,使用前面的的 go 程序发起 connect,在服务端用 netstat 查看 tcp 连接状态
虽然并发发了很多请求,实际只有 51 个请求处于 ESTABLISHED 状态,还有大量请求处于 SYN_RECV 状态。另外注意到 backlog 等于 50,但是实际上处于 ESTABLISHED 状态的连接却有 51 个,后面会讲到。客户端用 netstat 查看 tcp 有几百个连接,状态全是 ESTABLISHED,如下所示。
使用 systemstap 可以实时观察当前的全连接队列情况,探针代码如下所示。
使用 stap 执行这个探针,重新运行上面的测试,可以看到内核探针的输出结果。
这里也可以看出全连接队列的大小变化的情况,印证了我们前面的说法。
跟踪服务器端的一个包的结果如下:
以下记客户端 10.211.55.20 为 A,服务端 10.211.55.10 为 B
1:客户端 A 发起 SYN 到服务端 B 的 9090 端口,开始三次握手的第一步
2:服务器 B 马上回复了 ACK + SYN,此时 服务器 B socket 处于 SYN_RCVD 状态
3:客户端 A 收到服务器 B 的 ACK + SYN,发送三次握手最后一步的 ACK 给服务器 B,自己此时处于 ESTABLISHED 状态,与此同时,由于服务器 B 的全连接队列满,它会丢掉这个 ACK,连接还未建立
4:服务端 B 因为认为没有收到 ACK,以为是自己在 2 中的 SYN + ACK 在传输过程中丢掉了,所以开始重传,期待客户端能重新回复 ACK。
5:客户端 A 收到 B 的 SYN + ACK 以后,确实马上回复了 ACK
6 ~ 13:但是这个 ACK 同样也会被服务器 B 丢弃,服务端 B 还是认为没有收到 ACK,继续重传重传的过程同样也是指数级退避的(1s、2s、4s、8s、16s),总共历时 31s 重传 5 次 SYN + ACK 以后,服务器 B 认为没有希望,一段时间后此条 tcp 连接就被系统回收了。
SYN+ACK 重传的次数是由操作系统的一个文件决定的/proc/sys/net/ipv4/tcp_synack_retries,可以用 cat 查看这个文件
整个过程如下图所示:
全连接队列的大小全连接队列的大小是 listen 传入的 backlog 和 somaxconn 中的较小值。
全连接队列大小判断是否满的函数是 /include/net/sock.h 中 的 sk_acceptq_is_full 方法。
这里本身没有什么毛病,只是 sk_ack_backlog 是从 0 开始计算的,所以真正全连接队列大小是 backlog + 1。当你指定 backlog 值为 1 时,能容纳的连接个数会是 2。《Unix 网络编程卷一》87 页 4.5 节有详细的对比各个操作系统 backlog 与实际全连接队列最大数量之间的关系。
ss 命令
ss 命令可以查看全连接队列的大小和当前等待 accept 的连接个数,执行 ss -lnt 即可,比如上面的 accept 队列满的例子中,执行 ss 命令的输出结果如下。
对于 LISTEN 状态的套接字,Recv-Q 表示 accept 队列排队的连接个数,Send-Q 表示全连接队列(也就是 accept 队列)的总大小。
我们来看看 ss 命令的底层实现。ss 命令的源码在 iproute2 项目里,它巧妙的利用了 netlink 与 TCP 协议栈中 tcp_diag 模块通信获取 socket 的详细信息。tcp_diag 是一个统计分析模块,可以获取内核中很多有用的信息,ss 输出中的 Recv-Q 和 Send-Q 就是从 tcp_diag 模块中获取的,这两个值是等于 inet_diag_msg 结构体的 idiag_rqueue 和 idiag_wqueue。tcp_diag 部分的源码如下所示。
从上面的源码可以得知:
处于 LISTEN 状态的 socket,Recv-Q 对应 sk_ack_backlog,表示当前 socket 的完成三次握手等待用户进程 accept 的连接个数,Send-Q 对应 sk_max_ack_backlog,表示当前 socket 全连接队列能最大容纳的连接数
对于非 LISTEN 状态的 socket,Recv-Q 表示 receive queue 的字节大小,Send-Q 表示 send queue 的字节大小
其他
多大的 backlog 是合适的前面讲了这么多,应用程序设置多大的 backlog 是合理的呢?答案是 It depends,根据不同过的业务场景,需要做对应的调整。
你如果的接口处理连接的速度要求非常高,或者在做压力测试,很有必要调高这个值
如果业务接口本身性能不好,accept 取走已建连的速度较慢,那么把 backlog 调的再大也没有用,只会增加连接失败的可能性
可以举个典型的 backlog 值供大家参考,Nginx 和 Redis 默认的 backlog 值等于 511,Linux 默认的 backlog 为 128,Java 默认的 backlog 等于 50tcp_abort_on_overflow 参数默认情况下,全连接队列满以后,服务端会忽略客户端的 ACK,随后会重传 SYN+ACK,也可以修改这种行为,这个值由/proc/sys/net/ipv4/tcp_abort_on_overflow 决定。
tcp_abort_on_overflow 为 0 表示三次握手最后一步全连接队列满以后 server 会丢掉 client 发过来的 ACK,服务端随后会进行重传 SYN+ACK。
tcp_abort_on_overflow 为 1 表示全连接队列满以后服务端直接发送 RST 给客户端。
但是回给客户端 RST 包会带来另外一个问题,客户端不知道服务端响应的 RST 包到底是因为「该端口没有进程监听」,还是「该端口有进程监听,只是它的队列满了」。
小结
这篇文章我们从 backlog 参数为入口来研究了半连接队列、全连接队列的关系。简单回顾一下。
半连接队列:服务端收到客户端的 SYN 包,回复 SYN+ACK 但是还没有收到客户端 ACK 情况下,会将连接信息放入半连接队列。半连接队列又被称为 SYN 队列。
全连接队列:服务端完成了三次握手,但是还未被 accept 取走的连接队列。全连接队列又被称为 Accept 队列。
半连接队列的大小与用户 listen 传入的 backlog、net.core.somaxconn、net.core.somaxconn 都有关系,准确的计算规则见上面的源码分析
全连接队列的大小是用户 listen 传入的 backlog 与 net.core.somaxconn 的较小值
上面所说的结论不应当都是对的,这也是我一直的观点:结论不重要,重要的是研究的过程。我更多的是想授之以渔,教会你一些工具和方法,如果你能举一反三的去研究一些问题,那便是极好的。不要随意相信网上文章乱下的结论,包括我这篇。实验出真知,自己动手亲自验证一下哦~
看完三件事❤️
如果你觉得这篇内容对你还蛮有帮助,我想邀请你帮我三个小忙:
点赞,转发,有你们的 『点赞和评论』,才是我创造的动力。
关注公众号 『 java 烂猪皮 』,不定期分享原创知识。
同时可以期待后续文章 ing🚀
.关注后回复【666】扫码即可获取学习资料包
文章作者:挖坑的张师傅
出处:https://club.perfma.com/article/2351759
评论