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。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· DeepSeek “源神”启动!「GitHub 热点速览」
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 我与微信审核的“相爱相杀”看个人小程序副业
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
· DeepSeek R1 简明指南:架构、训练、本地部署及硬件要求