一文读懂全连接队列

简介

我们在编写服务端程序时，总是需要先 listen 一下。listen 最重要的就是初始化全连接和半连接队列，本文通过 Java 程序来验证全连接队列溢出情况。

全连接队列

上图是三次握手和网络交互的流程图，通过调用 accept 从全连接队列中获取 socket 进行读写。因此，我们在服务端只 listen 不调用 accept 就可以模拟全连接溢出场景。

队列长度

全连接队列长度与两个参数有关，backlog 和 somaxconn。

backlog 可以通过程序指定，在 ServerSocket 构造函数中，第二个参数 backlog 作用就在这儿。

ini

复制代码

// https://github.com/torvalds/linux/blob/448b3fe5a0eab5b625a7e15c67c7972169e47ff8/net/socket.c#L1867-L1886 int __sys_listen(int fd, int backlog) {  struct socket *sock;  int err, fput_needed;  int somaxconn;  sock = sockfd_lookup_light(fd, &err, &fput_needed);  if (sock) {   // 获取 net.core.somaxconn，与 backlog 取较小值。   **somaxconn = READ_ONCE(sock_net(sock->sk)->core.sysctl_somaxconn);   if ((unsigned int)backlog > somaxconn)    backlog = somaxconn;**   err = security_socket_listen(sock, backlog);   if (!err)    err = READ_ONCE(sock->ops)->listen(sock, backlog);   fput_light(sock->file, fput_needed);  }  return err; }

第二个参数在 Linux 中，可以修改 /etc/sysctl.conf 文件。在我的机器上该值为 4096。

动手实践

根据上面的判断，可以推断出下面程序的全连接队列的长度为：min(1, 4096) = 1

csharp

复制代码

/**  * 全连接队列溢出  */ public class Server {     public static void main(String[] args) throws Exception {         ServerSocket ss = new ServerSocket(8888, 1);         System.out.println("Started on 8888!");         Thread.currentThread().join();     } }

csharp

复制代码

/**  * 全连接队列溢出  */ public class Client {     public static void main(String[] args) throws Exception {         System.out.println("Started on: " + System.currentTimeMillis());         try {             for (int i = 0; i < 10; i++) {                 Socket socket = new Socket("127.0.0.1", 8888);                 System.out.println(socket.getPort());             }         } finally {             System.out.println("End on: " + System.currentTimeMillis());         }     } }

Linux 5.10 版本

当我们分别执行 java Server 和 java Client 后，在 client 的控制台会打印两次 8888。

less

复制代码

Started on: 1715755832881 8888 8888 End on: 1715755963822 Exception in thread "main" java.net.ConnectException: Connection timed out (Connection timed out)         at java.net.PlainSocketImpl.socketConnect(Native Method)         at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)         at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)         at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)         at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)         at java.net.Socket.connect(Socket.java:607)         at java.net.Socket.connect(Socket.java:556)         at java.net.Socket.<init>(Socket.java:452)         at java.net.Socket.<init>(Socket.java:229)         at Client.main(Client.java:13)

通过 ss 查看全连接队列情况时，可以看出 Send-Q（全连接队列最大长度） 值为 1，Recv-Q（全连接队列实际长度） 值为 2。

**为什么实际长度要比最大长度大呢？**根据 Linux 作者描述，全连接队列下标是从零开始的，因此连接数要比指定数字多一个。参考：[NET]: Revert incorrect accept queue backlog changes. · torvalds/linux@64a1465 (github.com)

备注：MacOS 上两个长度一致，都为 1。

抓包验证

通过 tcpdump -i lo -w rece.pcap 抓 lo 网卡的包，执行上面的程序。

可以发现在进行过前两次成功的三次握手后，第三次 56128 向 8888 发送 syn 包，但 8888 没有响应，56128 进行了六次重传，最后重传 syn 包失败，程序退出，已经建立成功的连接向 8888 发送 fin 包，销毁连接。

重试次数由 /proc/sys/net/ipv4/tcp_syn_retries 控制，默认为 6 次。重试策略为指数退避，1、2、4、8、16、32 秒进行重试。

不同的 Linux 版本中，全连接队列满后，行为是不一样的。上述是在 5.10 版本的表现。

在 5.10 版本中，只要是全连接队列满了，就会抛掉 syn 包。

scss

复制代码

// net/ipv4/tcp_input.c tcp_conn_request // 需要切换到 5.10 tag // 如果 accept queue 已经满了 if (sk_acceptq_is_full(sk)) {  NET_INC_STATS(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS);  goto drop; }

Linux 3.10 版本

当我们在 3.10 版本测试上面的程序时，现象比较奇怪，抓到的包则更为奇怪。

yaml

复制代码

// 程序输出结果 Started on: 1715928123222 8888 8888 8888 8888 8888 8888 8888 8888 8888 8888 End on: 1715928129242

• 从输出结果看，在全连接队列限制为 1 的前提下建立了 10 个连接
• 抓包显示，建立成功的连接也不止 2 个，并且还有多次 syn 包重传 和 dup ack。

通过 ss -lnt 看出，全连接队列大小确实为 1，连接成功确实为 2，符合我们之前的预计结果。

那么这些「建立成功」的连接是怎么回事儿呢？

答案是 Client 端收到了 syn ack，发送 ack 就认为连接创建成功了。但 Server 端因为全连接队列满了，抛弃掉了部分 ack 包和 syn 包。所以出现了已经建立成功的连接的 Client 重传 ack 包，已经发送 syn-ack 的 Server 重传 syn-ack 包。

那么 Server 端何时丢 syn 包，何时丢 ack 包呢？（这里我们暂时不讨论半连接溢出的情况）

丢弃 syn 包

scss

复制代码

// net/ipv4/tcp_ip_v4.c // 需要切换到 3.10 tag if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1) {  NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS);  goto drop; }

上面的程序和 5.10 版本的类似，只不过后面多了 inet_csk_reqsk_queue_young(sk) > 1 的判断。含义是半连接队列中刚到达的 syn，但是没有被超时重传 syn-ack 的数量，意义在于衡量 Server 的处理能力。因为正常三次握手都会很快，所以该值通常为 0。但如果 > 1，意味着此时 Server 端的处理能力不足，因此就要抛弃掉 syn 包来减轻 Server 的处理压力。

我们可以通过 systemtap 工具打印 qlen_young 的值，观察丢包情况。

ini

复制代码

probe kernel.function("tcp_v4_conn_request") {     tcphdr = __get_skb_tcphdr($skb);     dport = __tcp_skb_dport(tcphdr);     if (dport == 8888)     {         // 获取当前时间的秒数和微秒数         sec = gettimeofday_s();         usec = gettimeofday_us() % 1000000;         // 手动格式化时间         min = (day_sec % 3600) / 60;         sec_only = day_sec % 60;         printf("current: %02d:%02d.%06d \n",                min, sec_only, usec);         // 当前 syn 排队队列的大小         syn_qlen = @cast($sk, "struct inet_connection_sock")->icsk_accept_queue->listen_opt->qlen;         // 当前 syn 排队中 young 的大小         syn_young_qlen = @cast($sk, "struct inet_connection_sock")->icsk_accept_queue->listen_opt->qlen_young;         printf("%02d:%02d.%06d syn queue: syn_qlen=%d, syn_young_qlen=%d\n",                 min, sec_only, usec,                syn_qlen, syn_young_qlen);     } }

将上面的程序保存为 rece_request.c，然后调用 stap -g rece_request.c 观察 syn_yyoung_qlen 的值，当其大于 1 时就会触发丢掉 syn 包操作，再数数抓包文件中 syn 重传，这两个值应该是一致的。

丢弃 ack 包

只要是全连接队列满了，就会丢弃 ack 包。

c

复制代码

/*  * The three way handshake has completed - we got a valid synack -  * now create the new socket.  */  // 三次握手最后一次 ack 处理，完事儿 struct sock *tcp_v4_syn_recv_sock(struct sock *sk, struct sk_buff *skb,       struct request_sock *req,       struct dst_entry *dst) {      // 全连接队是否满了，直接 goto 到溢出，不处理 ack 包。  if (sk_acceptq_is_full(sk))   goto exit_overflow; }      

总结

• 我们在调用 listen 时，主要创建了全连接（accept queue）和半连接（syn queue）队列。
• 全连接队列的大小取决于 min(backlog, somaxconn)
• 不同版本对于全连接队列溢出的策略是不同的，但本质都是通过丢弃 Client 请求来保证 Server 的稳定。
• 全连接队列主要供 accept 调用，因此只要使用先进先出的队列结构即可。全连接队列的数据主要来自于半连接，需要根据不同的 Client 获取，因此被设计成查询高效的哈希表结构。