如何正确查看线上半/全连接队列溢出情况？

 关注

“脚本之家

”，与百万开发者在一起

作者 | 张彦飞allen

出品 | 开发内功修炼（ID：kfngxl）

在《深入解析常见三次握手异常》 这一文中，我们讨论到如果发生连接队列溢出而丢包的话，会导致连接耗时会上涨很多。那如何判断一台服务器当前是否有半/全连接队列溢出丢包发生呢？

我在我早期的一篇文章里提到过，可以通过 netstat 来查看。

# netstat -s 
    8 SYNs to LISTEN sockets ignored
    160 times the listen queue of a socket overflowed
    ...

• SYNs to LISTEN ockets ignored 前面的数字是半连接队列的溢出，
• times the listen queue of a socket overflowed 前面的数字是全连接队列的溢出。

如果这两个数字在动态增长，那就说明当前有溢出发生了。

但可惜这个说法存在一些问题。其中对于全连接队列溢出描述 ok，但半连接队列的描述很不正确！所以我今天专门发篇文章纠正一下，来从源码角度来分析一下为啥这样说。

一、全连接队列溢出判断

全连接队列溢出判断比较简单，所以先说这个。

1. 全连接溢出丢包

全连接队列溢出都会记录到 ListenOverflows 这个 MIB（Management Information Base，管理信息库）上的，对应 SNMP 统计信息中的 ListenDrops 这一项。我们来展开看一下相关的源码。

服务器在响应客户端的 SYN 握手包的时候，有可能会在 tcp_v4_conn_request 这里发生全连接队列溢出而丢包。

//file: net/ipv4/tcp_ipv4.c
int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
{
 //看看半连接队列是否满了
 ...

 //看看全连接队列是否满了
 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;
 }
 ...
drop:
 NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENDROPS);
 return 0;
}

从上述代码中可以看到，全连接队列满了以后调用 NET_INC_STATS_BH 增加了 LINUX_MIB_LISTENOVERFLOWS 和 LINUX_MIB_LISTENDROPS 这两个 MIB。

服务器在响应第三次握手的时候，会再次判断全连接队列是否溢出。如果溢出，一样会增加这两个 MIB。源码如下：

//file: net/ipv4/tcp_ipv4.c
struct sock *tcp_v4_syn_recv_sock(...)
{
 if (sk_acceptq_is_full(sk))
  goto exit_overflow;
 ...
exit_overflow:
 NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS); 
exit:
 NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENDROPS);
 return NULL;
} 

在 proc.c 中， LINUX_MIB_LISTENOVERFLOWS 和 LINUX_MIB_LISTENDROPS 都被整合进了 SNMP 统计信息。

//file: net/ipv4/proc.c
static const struct snmp_mib snmp4_net_list[] = {
 SNMP_MIB_ITEM("ListenDrops", LINUX_MIB_LISTENDROPS),
 SNMP_MIB_ITEM("ListenOverflows", LINUX_MIB_LISTENOVERFLOWS),
 ......
}

2.netstat 工具源码

我们在执行 netstat -s 的时候，该工具会读取 SNMP 统计信息并展现出来。netstat 命令属于 net-tool 工具集，所以得找 net-tool 的源码。我用 SYNs to LISTEN sockets dropped 这种关键词去搜到了：

//file: https://github.com/giftnuss/net-tools/blob/master/statistics.c
struct entry Tcpexttab[] =
{
 { "ListenDrops", N_("%u SYNs to LISTEN sockets dropped"), opt_number },
 { "ListenOverflows", N_("%u times the listen queue of a socket overflowed"),
 ......
}

以上这些就是执行 netstat -s 时会执行到的源码。它从 SNMP 统计信息中获取到 ListenDrops 和 ListenOverflows 这两项显示了出来，分别对应 LINUX_MIB_LISTENDROPS 和 LINUX_MIB_LISTENOVERFLOWS 这两个 MIB。

# watch 'netstat -s | grep overflowed'
 198 times the listen queue of a socket overflowed

所以，每当发生全连接队列满导致的丢包的时候，可以通过上述命令的结果里体现出来。而且幸运的是，ListenOverflows 这个 SNMP 统计项只有在全连接队列满的时候才会增加，内核源码其它地方没有用到。

所以，通过 netstat -s 输出中的 xx times the listen queue 中的查看到数字如果有变化，那么一定是你的服务器上发生了全连接队列溢出了！！

二、半连接队列溢出判断

再来看半连接队列，溢出时是更新的是 LINUX_MIB_LISTENDROPS 这个 MIB，对应到 SNMP 就是 ListenDrops 这个统计项。

//file: net/ipv4/tcp_ipv4.c
int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
{
 //看看半连接队列是否满了
 if (inet_csk_reqsk_queue_is_full(sk) && !isn) {
  want_cookie = tcp_syn_flood_action(sk, skb, "TCP");
  if (!want_cookie)
   goto drop;
 }

 //看看全连接队列是否满了
 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;
 }
 ...
drop:
 NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENDROPS);
 return 0; 
}

上述源码中可见，半连接队列满的时候 goto drop，然后增加了 LINUX_MIB_LISTENDROPS 这个 MIB。通过上一节 netstat -s 的源码我们看到也会展示它出来（对应 SNMP 中的 ListenDrops 这个统计项）。

但是问题在于，不仅仅只是在半连接队列发生溢出的时候会增加该值。所以根据 netstat -s 看半连接队列是否溢出是不靠谱的！

上面看到，即使半连接队列没问题，全连接队列满了该值也会增加。另外就是当在 listen 状态握手发生错误的时候，进入 tcp_v4_err 函数时也会增加该值。

对于如何查看半连接队列溢出丢包这个问题，我的建议是不要纠结咋看是否丢包了。直接看服务器上的 tcp_syncookies 是不是 1 就行。

如果该值是 1 ，那么下面代码中 want_cookie 就返回是真，是根本不会发生半连接溢出丢包的。

//file: net/ipv4/tcp_ipv4.c
int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
{
 //看看半连接队列是否满了
 if (inet_csk_reqsk_queue_is_full(sk) && !isn) {
  want_cookie = tcp_syn_flood_action(sk, skb, "TCP");
  if (!want_cookie)
   goto drop;
 }

如果 tcp_syncookies 不是 1，则建议改成 1 就完事了。

如果因为各种原因就是不想打开 tcp_syncookies。就想死磕看下是否有因为半连接队列满而导致的 SYN 丢弃，除了 netstat -s 的结果，我建议同时查看下当前 listen 的端口上的 SYN_RECV 的数量。

# netstat -antp | grep SYN_RECV 
256

在《为什么服务端程序都需要先 listen 一下？》中我们讨论了半连接队列的实际长度怎么计算。如果 SYN_RECV 状态的连接数量达到你算出来的队列长度了，那么可以确定是有半连接队列溢出了。如果想加大半连接队列的长度，方法我们在上面文章里也一并讲过了。

三、总结

最后，总结一下。

对于全连接队列来说，使用 netstat -s （最好再配合 watch 命令动态观察）就可以判断是否有丢包发生。如果看到 “xx times the listen queue of a socket overflowed” 中的数值在增长，那么就确定是全连接队列满了。

# watch 'netstat -s | grep overflowed'
 198 times the listen queue of a socket overflowed

对于半连接队列来说，只要保证 tcp_syncookies 这个内核参数是 1 就能保证不会有因为半连接队列满而发生的丢包。

如果确实较真就像看一看，netstat -s | grep "SYNs" 这个是没有办法说明问题的。还需要你自己计算一下半连接队列的长度，再看下当前 SYN_RECV 状态的连接的数量。

# watch 'netstat -s | grep "SYNs"'
 258209 SYNs to LISTEN sockets dropped 
# netstat -antp | grep SYN_RECV | wc -l
5 

至于如何加大半连接队列长度，参考《为什么服务端程序都需要先 listen 一下？》这篇文章就行了。

结尾再感叹一句，很多问题真的是只有通过源码才能找到最准确的结论啊！！

Github: https://github.com/yanfeizhang/coder-kung-fu

  推荐阅读：

每日打卡赢积分兑换书籍入口