conntrack

 

conntrack工具
=======================================================================================================
https://blog.csdn.net/Golden_Chen/article/details/116645137

$ sysctl -a | grep conntrack
net.netfilter.nf_conntrack_count = 180      #表示当前连接跟踪数；
net.netfilter.nf_conntrack_max = 1000       #表示最大连接跟踪数；
net.netfilter.nf_conntrack_buckets = 65536  #表示连接跟踪表的大小
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120

# 统计总的连接跟踪数
$ conntrack -L -o extended | wc -l
14289
# 统计TCP协议各个状态的连接跟踪数
$ conntrack -L -o extended | awk '/^.*tcp.*$/ {sum[$6]++} END {for(i in sum) print i, sum[i]}'
SYN_RECV 4
CLOSE_WAIT 9
ESTABLISHED 2877
FIN_WAIT 3
SYN_SENT 2113
TIME_WAIT 9283
# 统计各个源IP的连接跟踪数
$ conntrack -L -o extended | awk '{print $7}' | cut -d "=" -f 2 | sort | uniq -c | sort -nr | head -n 10
  14116 192.168.0.2
    172 192.168.0.96
        
cat /proc/net/stat/nf_conntrack
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

---------------------------------------------------------------------------------------------------------
常见问题
连接太多导致 conntrack table 被打爆

业务层（应用层）现象
    1.存在随机、偶发的新建连接超时（connect timeout）。
        例如，如果业务用的是 Java，那对应的是 jdbc4.CommunicationsException communications link failure 之类的错误。
    2.已有连接正常。
        也就是没有 read timeout 或 write timeout 之类的报错，报错都集中为 connect timeout。

网络层现象
    1.抓包会看到三次握手的第一个 SYN 包被宿主机静默丢弃了。
        需要注意的是，常规的网卡统计（ifconfig）和内核统计（/proc/net/softnet_stat） 无法反映出这些丢包。

    2.1秒+ 之后出发 SYN 重传，或者还没重传连接就关闭了。
        第一个 SYN 的重传是 1s，这个是内核代码里写死的，不可配置。
        再考虑到其他一些耗时，第一次重传的实际间隔要大于 1s。 如果客户端设置的超时时间很小，例如 1.05s，那可能来不及重传连接就被关闭了，然后向上层报 connect timeout 错误。

操作系统层现象
    内核日志中有如下报错：
        $ demsg -T
        [Tue Apr  6 18:12:30 2021] nf_conntrack: nf_conntrack: table full, dropping packet
        [Tue Apr  6 18:12:30 2021] nf_conntrack: nf_conntrack: table full, dropping packet
        [Tue Apr  6 18:12:30 2021] nf_conntrack: nf_conntrack: table full, dropping packet
        ...
    另外，cat /proc/net/stat/nf_conntrack 或 conntrack -S 能看到有 drop 统计。
    
--------------------------------------------------------------------------------------------------------
总结
    连接跟踪是一个非常基础且重要的网络模块，但只有在少数场景下才会引起普通开发者的注意。
    例如，L4LB 短时高并发场景下，LB 节点每秒接受大量并发短连接，可能导致 conntrack table 被打爆。此时的现象是：
        客户端和 L4LB 建连失败，失败可能是随机的，也可能是集中在某些时间点。
        客户端重试可能会成功，也可能会失败。
        在 L4LB 节点抓包看，客户端过来的 TCP SYNC 包 L4LB 收到了，但没有回 ACK。即，包 被静默丢弃了（silently dropped）。
    此时的原因可能是 conntrack table 太小，也可能是 GC 不够及 时，甚至是 GC 有bug。