文章>再聊 TCP backlog>

再聊 TCP backlog

挖坑的张师傅
TCP
IP
性能优化
1周前

这篇文章我们以 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 函数的定义如下:

int listen(int sockfd, int backlog);

当服务端调用 listen 函数时,TCP 的状态被从 CLOSE 状态变为 LISTEN,于此同时内核创建了两个队列:

  • 半连接队列(Incomplete connection queue),又称 SYN 队列
  • 全连接队列(Completed connection queue),又称 Accept 队列

如下图所示。
image.png
接下来开始详细介绍这两个队列相关的内容。

半连接队列(SYN Queue)

当客户端发起 SYN 到服务端,服务端收到以后会回 ACK 和自己的 SYN。这时服务端这边的 TCP 从 listen 状态变为 SYN_RCVD (SYN Received),此时会将这个连接信息放入「半连接队列」,半连接队列也被称为 SYN Queue,存储的是 “inbound SYN packets”。
image.png

服务端回复 SYN+ACK 包以后等待客户端回复 ACK,同时开启一个定时器,如果超时还未收到 ACK 会进行 SYN+ACK 的重传,重传的次数由 tcp_synack_retries 值确定。在 CentOS 上这个值等于 5。
一旦收到客户端的 ACK,服务端就开始尝试把它加入另外一个全连接队列(Accept Queue)。

半连接队列的大小的计算

这里使用 SystemTap 工具插入系统探针,在收到 SYN 包以后打印当前的 SYN 队列的大小和半连接队列的总大小。
TCP listen 状态的 socket 收到 SYN 包的处理流程如下

tcp_v4_rcv
  ->tcp_v4_do_rcv
    -> tcp_v4_conn_request

这里注入 tcp_v4_conn_request 方法,代码如下所示。

probe kernel.function("tcp_v4_conn_request") {
    tcphdr = __get_skb_tcphdr($skb);
    dport = __tcp_skb_dport(tcphdr);
    if (dport == 9090)
    {
        printf("reach here\n");
        // 当前 syn 排队队列的大小
        syn_qlen = @cast($sk, "struct inet_connection_sock")->icsk_accept_queue->listen_opt->qlen;
        // syn 队列总长度 log 值
        max_syn_qlen_log = @cast($sk, "struct inet_connection_sock")->icsk_accept_queue->listen_opt->max_qlen_log;
        // syn 队列总长度,2^n
        max_syn_qlen = (1 << max_syn_qlen_log);
        printf("syn queue: syn_qlen=%d, max_syn_qlen_log=%d, max_syn_qlen=%d\n",
         syn_qlen, max_syn_qlen_log, max_syn_qlen);
        // max_acc_qlen = $sk->sk_max_ack_backlog;
        // printf("accept queue length limit: %d\n", max_acc_qlen)
        print_backtrace();
    }
}

使用 stap 执行上面的脚本

sudo stap -g syn_backlog.c

这样在收到 SYN 包以后可以打印当前syn 队列排队的连接个数和总大小了。

还是以之前的 echo 程序为例,listen 的 backlog 设置为 10,如下所示。

int server_fd = //...

listen(server_fd, 10 /*backlog*/)

启动 echo-server,监听 9090 端口。然后在另外一个机器上使用 nc 命令进行连接。

nc 10.211.55.10 9090

此时在 stap 的输出中,已经可以看到当前的 可以看到syn 队列大小为 0,最大的队列长度是 2^4=16
image.png
因此可以看到实际的 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(listen, int, fd, int, backlog)
{
    // sysctl_somaxconn 是系统变量 net.core.somaxconn 的值
	int somaxconn = sysctl_somaxconn;
	if ((unsigned int)backlog > somaxconn)
		backlog = somaxconn;
	sock->ops->listen(sock, backlog);
}

通过 SYSCALL_DEFINE2 代码可以得知,如果用户传入的 backlog 值大于系统变量 net.core.somaxconn 的值,用户设置的 backlog 不会生效,使用系统变量值,默认为 128。
接下来这个 backlog 值会被依次传递给 inet_listen()->inet_csk_listen_start()->reqsk_queue_alloc() 方法。在 reqsk_queue_alloc 方法中进行了最终的计算。精简后的代码如下。

int reqsk_queue_alloc(struct request_sock_queue *queue,
		      unsigned int nr_table_entries)
{
    nr_table_entries = min_t(u32, nr_table_entries, sysctl_max_syn_backlog);
    nr_table_entries = max_t(u32, nr_table_entries, 8);
    nr_table_entries = roundup_pow_of_two(nr_table_entries + 1);
    	
    for (lopt->max_qlen_log = 3;
         (1 << lopt->max_qlen_log) < nr_table_entries;
         lopt->max_qlen_log++);
}

代码中 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 函数的计算。

nr_table_entries = min_t(u32, nr_table_entries, sysctl_max_syn_backlog);
// max(50, 8) = 50
nr_table_entries = max_t(u32, nr_table_entries, 8);
// roundup_pow_of_two(51) = 64
nr_table_entries = roundup_pow_of_two(nr_table_entries + 1);
  
max_qlen_log 最小值为 2^3 = 8
for (lopt->max_qlen_log = 3;
     (1 << lopt->max_qlen_log) < nr_table_entries;
     lopt->max_qlen_log++);
经过 for 循环 max_qlen_log = 2^6 = 64

下面给了几个 somaxconn、max_syn_backlog、backlog 三者之间不同组合的最终半连接队列大小值。
image.png

可以看到:
在系统参数不修改的情形,盲目调大 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 增加一条规则,如下所示。


image.png
接下来使用你喜欢的语言,开始发起连接就好了,这里选择了 go,代码如下:

	for i := 0; i < 2000; i++ {
		go connect()
	}
	time.Sleep(time.Minute * 10)
}
func connect() {
	_, err := net.Dial("tcp4", "10.211.55.10:9090")
	if err != nil {
		fmt.Println(err)
	}
}

执行这个 go 程序,在服务端使用 netstat 查看当前 9090 端口的连接状态,如下所示。

     64 SYN_RECV
      1 LISTEN

可以观察到 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,那么很快全连接就可以被占满。
image.png
为了贴近最底层的调用,这里用 c 语言来实现,新建一个 main.c 文件

#include <sys/socket.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <arpa/inet.h>

int main() {
    struct sockaddr_in serv_addr;
    int listen_fd = 0;
    if ((listen_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
        exit(1);
    }
    bzero(&serv_addr, sizeof(serv_addr));

    serv_addr.sin_family = AF_INET;
    serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
    serv_addr.sin_port = htons(8080);

    if (bind(listen_fd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) == -1) {
        exit(1);
    }
    
    // 设置 backlog 为 50
    if (listen(listen_fd, 50) == -1) {
        exit(1);
    }
    sleep(100000000);
    return 0;
}

编译运行gcc main.c; ./a.out,使用前面的的 go 程序发起 connect,在服务端用 netstat 查看 tcp 连接状态

     51 ESTABLISHED
     31 SYN_RECV
      1 LISTEN

虽然并发发了很多请求,实际只有 51 个请求处于 ESTABLISHED 状态,还有大量请求处于 SYN_RECV 状态。
另外注意到 backlog 等于 50,但是实际上处于 ESTABLISHED 状态的连接却有 51 个,后面会讲到。
客户端用 netstat 查看 tcp 有几百个连接,状态全是 ESTABLISHED,如下所示。

tcp        0      0 10.211.55.20:37732      10.211.55.10:9090       ESTABLISHED 23618/./connect
tcp        0      0 10.211.55.20:37824      10.211.55.10:9090       ESTABLISHED 23618/./connect
tcp        0      0 10.211.55.20:37740      10.211.55.10:9090       ESTABLISHED 23618/./connect
...

使用 systemstap 可以实时观察当前的全连接队列情况,探针代码如下所示。

    tcphdr = __get_skb_tcphdr($skb);
    dport = __tcp_skb_dport(tcphdr);
    if (dport == 9090)
    {
        printf("reach here\n");
        // 当前 syn 排队队列的大小
        syn_qlen = @cast($sk, "struct inet_connection_sock")->icsk_accept_queue->listen_opt->qlen;
        // syn 队列总长度 log 值
        max_syn_qlen_log = @cast($sk, "struct inet_connection_sock")->icsk_accept_queue->listen_opt->max_qlen_log;
        // syn 队列总长度,2^n
        max_syn_qlen = (1 << max_syn_qlen_log);
        printf("syn queue: syn_qlen=%d, max_syn_qlen_log=%d, max_syn_qlen=%d\n",
         syn_qlen, max_syn_qlen_log, max_syn_qlen);
        ack_backlog = $sk->sk_ack_backlog;
        max_ack_backlog = $sk->sk_max_ack_backlog;
        printf("accept queue length, max: %d, current: %d\n", max_ack_backlog, ack_backlog)
    }
}

使用 stap 执行这个探针,重新运行上面的测试,可以看到内核探针的输出结果。

...
syn queue: syn_qlen=45, max_syn_qlen_log=6, max_syn_qlen=64
accept queue length, max: 50, current: 14
...
syn queue: syn_qlen=2, max_syn_qlen_log=6, max_syn_qlen=64
accept queue length, max: 50, current: 51

这里也可以看出全连接队列的大小变化的情况,印证了我们前面的说法。

跟踪服务器端的一个包的结果如下:
image.png
以下记客户端 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 查看这个文件

cat /proc/sys/net/ipv4/tcp_synack_retries
5

整个过程如下图所示:
image.png
全连接队列的大小
全连接队列的大小是 listen 传入的 backlog 和 somaxconn 中的较小值。

全连接队列大小判断是否满的函数是 /include/net/sock.h 中 的 sk_acceptq_is_full 方法。

static inline bool sk_acceptq_is_full(const struct sock *sk)
{
	return sk->sk_ack_backlog > sk->sk_max_ack_backlog;
}

这里本身没有什么毛病,只是 sk_ack_backlog 是从 0 开始计算的,所以真正全连接队列大小是 backlog + 1。当你指定 backlog 值为 1 时,能容纳的连接个数会是 2。《Unix 网络编程卷一》87 页 4.5 节有详细的对比各个操作系统 backlog 与实际全连接队列最大数量之间的关系。

ss 命令

ss 命令可以查看全连接队列的大小和当前等待 accept 的连接个数,执行 ss -lnt 即可,比如上面的 accept 队列满的例子中,执行 ss 命令的输出结果如下。

State      Recv-Q Send-Q Local Address:Port               Peer Address:Port
LISTEN     51     50           *:9090                     *:*

对于 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 部分的源码如下所示。

static void tcp_diag_get_info(struct sock *sk, struct inet_diag_msg *r,
			      void *_info)
{
	struct tcp_info *info = _info;

	if (inet_sk_state_load(sk) == TCP_LISTEN) {
	   // 对应 Recv-Q
		r->idiag_rqueue = READ_ONCE(sk->sk_ack_backlog); 
		// 对应 Send-Q
		r->idiag_wqueue = READ_ONCE(sk->sk_max_ack_backlog);	} else if (sk->sk_type == SOCK_STREAM) {
		const struct tcp_sock *tp = tcp_sk(sk);
		r->idiag_rqueue = max_t(int, READ_ONCE(tp->rcv_nxt) -
					     READ_ONCE(tp->copied_seq), 0);
		r->idiag_wqueue = READ_ONCE(tp->write_seq) - tp->snd_una;
	}
}

从上面的源码可以得知:

  • 处于 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 等于 50
tcp_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 的较小值

上面所说的结论不应当都是对的,这也是我一直的观点:结论不重要,重要的是研究的过程。我更多的是想授之以渔,教会你一些工具和方法,如果你能举一反三的去研究一些问题,那便是极好的。
不要随意相信网上文章乱下的结论,包括我这篇。实验出真知,自己动手亲自验证一下哦~

1083 阅读
请先登录,再评论

评论列表

暂无回复,快来写下第一个回复吧~