关于连接跟踪表（Connection Tracking Table）的理解
该数据结构用于追踪系统中所有活动的网络连接，并存储每个连接的状态及相关信息以确保网络防火墙与路由器能够正确处理数据包
- 追踪每个网络链接的状态信息: 系统会持续监控每条链路的工作状态, 包括链路是否处于可用状态, 数据传输速率以及链路是否出现故障.
- 分析处理所有网络链接关系: 系统将动态评估当前所有的链路关系, 并根据评估结果进行相应的资源分配与流量调度.
- 确保整个网络系统的安全: 该系统能够有效识别并拒绝所有非法或恶意的通信端口.
对于系统的运行效率和安全措施而言，在对连接跟踪表的大小进行管理和监控方面至关重要。当连接数量达到上限时，在尝试追加新连接的过程中会出现断层现象；这将可能导致数据包丢失或服务中断。
我们当前有遇到SNMP请求超时的问题：
我们配置了5个SNMP客户端连接到我们的嵌入式设备，并持续不断地向这些客户端发送SNMP请求。然而，在测试过程中发现其中一些客户端存在SNMP请求超时的问题。
查看了跟踪表后发现表已经满了。
表溢出的后果分析
一、连接跟踪表溢出（如 nf_conntrack 溢出）
网络中可能出现丢包及连接丢失的情况
当内核的连接跟踪表达到上限容量时，将无法创建新的网络连接请求。这种情况下会触发特定的错误信息 nf_conntrack: table full 的显示，并最终导致业务请求失败或者部分网络流量的丢失（达到约25%的比例）。
系统运行中的异常日志记录
此段中功能组件出现故障
在NAT转换过程中, 有状态的防火墙规则依赖于连接跟踪表, 当该表溢出时会导致两种结果: 一种是地址转换失败; 另一种则是防火墙策略失效, 引发网络功能异常情况发生时将影响网络功能的稳定性.
跟踪表为什么会溢出：
经过分析发现：
Connection Tracking Table will track UDP requests, yet its tracking mechanism differs from that of TCP. The mechanism does not rely on explicit connection states but instead leverages protocol characteristics to achieve pseudo-connect tracking.
2、UDP 请求的记录原理
元组（Tuple）匹配
UDP 请求通过五元组标识：
源IP地址
目标IP地址
协议类型（IPPROTO_UDP）
源端口
目标端口
此外，在内核中使用哈希表实现定位功能的同时进行连接条目维护的具体过程是：内核利用哈希表快速定位到对应五元组，并同时维护其对应的连接条目。
伪状态管理
- NEW 状态 ：响应首次 UDP 数据包完成而创建新的记录项。
- ESTABLISHED 状态 ：检测到双向数据流后将状态更新为已连接状态。
- 超时机制 ：预设值为三分钟未活动则删除条目（可通过配置调整）
如何解决：
由于默认设置下跟踪表的超时时间为30秒, 但SNMP客户端所使用的端口是随机分配的, 因此会不断有新的请求被添加到该表中, 而该跟踪表将在30秒后删除此记录.
所以可以缩短跟踪表的udp超时时间：
sysctl -w net.netfilter.nf_conntrack_udp_timeout=152. 将表扩大也可以解决问题：
# 临时调整至 50 万条
echo 500000 > /proc/sys/net/netfilter/nf_conntrack_max
# 或通过 sysctl
sysctl -w net.netfilter.nf_conntrack_max=500000