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。
conntrack
复制代码

 

posted @   雲淡風輕333  阅读(18)  评论(0编辑  收藏  举报
(评论功能已被禁用)
相关博文:
阅读排行:
· DeepSeek “源神”启动!「GitHub 热点速览」
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 我与微信审核的“相爱相杀”看个人小程序副业
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
· DeepSeek R1 简明指南:架构、训练、本地部署及硬件要求
点击右上角即可分享
微信分享提示