conntrack连接跟踪分析

nf_conntracktablefull导致的原因nf_conntrack是Linux内核中用于跟踪网络连接的一个组件，它会记录所有经过Linux系统的网络连接信息。

当网络连接数量增多时，nf_conntrack表可能会满，从而导致"nf_conntrack table full"错误。

在深入探讨导致nf_conntrack表满的原因之前，先了解一下nf_conntrack表的用途和工作原理是很重要的。

nf_conntrack表用于存储当前活动的网络连接的状态信息。

每个网络连接都会被赋予唯一的连接标识符，该标识符由源IP地址、目标IP地址、源端口和目标端口组成。

当有数据包进入Linux系统时，nf_conntrack会检查该数据包的连接标识符，然后根据标识符查找比对的连接信息，并根据该连接信息进行处理。

当nf_conntrack表满时，新的连接将无法被跟踪，这可能会导致网络连接的异常和一些网络问题。

接下来，我们将详细讨论造成nf_conntrack表满的原因。

1. 过多的并发连接：过多的并发连接是导致nf_conntrack表满的最常见原因之一、当Linux系统同时处理大量连接时，nf_conntrack表的空间会被快速耗尽。

2. 短时间内的连接增加：在一些情况下，可能会发生一个短时间内出现大量连接的情况，比如在进行网络扫描或者网络攻击时。

这些大量的连接请求会导致nf_conntrack表过载，从而表满错误的发生。

3. 不恰当的nf_conntrack设置：如果nf_conntrack表的大小设置不合适，也有可能导致表满错误的发生。

默认情况下，nf_conntrack表的大小是由系统总内存的一部分决定的。

如果系统总内存较小，而nf_conntrack表的大小设置过高，那么很可能会导致表满问题。

4. 未关闭的连接：在一些情况下，网络连接可能无法正常关闭，比如连接的一方意外断电或崩溃。

ROS连接跟踪解释MikroTikRouterOS操作路径:1 /ip firewall connection tracking连接追踪为nat 地址转换提供每条TCP/UDP 连接的转换状态跟踪，提供了连接超时（timeout）参数，当在指定的超时时间过后，相应的条目将会从连接状态列表中删除。

下面是 tracking 的配置，在RouterOS 6.0 后开始新增 FastPath 功能， Enabled 由原来的双选，变为 auto、 no 和 yes：属性描述count-curent (只读: 整数) –在连接状态列表中记录的当前连接数count-max (只读: 整数) –取决于总内存量的连接状态列表，自动计算出最大连接数enable (yes | no|auto; 默认: auto|yes) –允许或禁止连接追踪，nat 被使用的情况下必须开启；根据硬件平台不同，x86 不具备Fastpath，默认是yes，而RouterBOARD 具备Fastpath 功能，默认是 auto。

generic-timeout (时间; 默认: 10m) –连接列表中追踪既非 TCP 又非 UDP 包的条目的最大时间量将会在看到匹配此条目最后一个包之后存活icmp-timeout (时间; 默认: 10s) –连接追踪条目将在看到 ICMP 请求后存活最的大时间量tcp-close-timeout (时间; 默认: 10s) – TCP 连接追踪条目在看到连接复位请求（ RST）或来自连接释放初始化机连接终端请求确认通知（ ACK）之后存活的最大时间tcp-close-wait-timeout (时间; 默认: 10s) –当来自应答器的终端请求（ FIN）之后连接追踪条目存活的最大时间tcp-established-timeout (时间; 默认: 1d) –当来自连接初始化机的确认通知后连接追踪条目存活的最大时间tcp-fin-wait-timeout (时间; 默认: 10s) –当来自连接释放初始化机的连接终端请求（ FIN）后存后连接追踪条目存活的最大时间tcp-syn-received-timeout (时间; 默认: 1m) –当匹配连接请求（ SYN）之后连接追踪条目存活的最大时间tcp-syn-sent-timeout (时间; 默认: 1m) –当来自连接初始化机的连接请求（ SYN）后连接追踪条目存活的最大时间tcp-time-wait-timeout (时间; 默认: 10s) –当紧随连接请求（ SYN）的连接终端请求（ FIN）之后或在看到来自连接释放初始化机的其他终端请求（FIN）之后连接追踪条目存活的最大时间udp-timeout (时间; 默认: 10s) –当匹配此条目的最后一个包之后连接追踪条目存活的最大时间udp-stream-timeout (时间; 默认: 3m) –在匹配此连接（连接追踪条目是确定的）的最后一个包的响应被看到之后连接追踪条目存活的最大时间。

深入理解NF90参数NF90，全称Netfilter 90，是一种网络过滤框架，它在Linux内核中实现了包过滤、NAT和连接跟踪等功能。

NF90的参数设置直接影响其功能和性能。

本文将详细介绍NF90的主要参数。

1. nf_conntrack_max: 这个参数决定了系统可以同时跟踪的最大连接数。

如果超过这个数量，新的连接请求将会被拒绝。

这个值应该根据系统的实际负载来调整。

2. nf_conntrack_tcp_timeout_established: 这个参数定义了已经建立的TCP 连接的超时时间。

当一个连接在这个时间内没有任何活动，它将被视为过期并被删除。

这个值可以根据业务需求进行调整。

3. nf_conntrack_udp_timeout_stream: 这个参数定义了UDP流连接的超时时间。

与TCP不同，UDP是无连接的，但某些应用（如VoIP）可能会使用UDP来模拟流连接。

这个值可以根据这些应用的需求进行调整。

4. nf_conntrack_generic_timeout: 这个参数定义了非TCP/UDP连接的超时时间。

这包括ICMP、IGMP等协议。

这个值也可以根据实际情况进行调整。

5. nf_conntrack_hashsize: 这个参数决定了连接跟踪表的大小。

这个表用于存储所有正在被跟踪的连接信息。

如果这个值太小，可能会导致连接跟踪表溢出，从而影响系统性能。

如果这个值太大，可能会浪费内存。

因此，这个值需要根据系统的实际负载进行调整。

6. nf_conntrack_buckets: 这个参数决定了连接跟踪表的桶数。

每个桶包含多个连接条目。

如果这个值太小，可能会导致查找效率降低。

如果这个值太大，可能会浪费内存。

因此，这个值需要根据系统的实际负载进行调整。

总的来说，NF90的参数设置是一个复杂的过程，需要根据系统的实际负载和业务需求进行精细调整。

希望本文能帮助你更好地理解和配置NF90。

skbuff解读一、nf_conntrack结构体struct nf_conntrack {atomic_t use;void (*destroy)(struct nf_conntrack *);};二、nf_bridge_info结构体struct nf_bridge_info {atomic_t use;struct net_device *physindev;struct net_device *physoutdev;#if defined(CONFIG_VLAN_8021Q) || efined(CONFIG_VLAN_8021Q_MODULE) struct net_device *netoutdev;#endifunsigned int mask;unsigned long data[32 / sizeof(unsigned long)];};三、sk_buff_head结构体介绍struct sk_buff_head {struct sk_buff * next;struct sk_buff * prev;_ _u32 qlen;spinlock_t lock;};sk_buff构成的链表就是依靠sk_buff_head来进行管理的，其中：next指针指向链表的第一个元素(sk_buf);prev指针指向链表的最后一个元素；qlen存放的是链表的元素个数；lock用来控制链表，以防被并发的访问；链表的初始化由函数skb_queue_head_init(struct sk_buff_head *list)完成，在初始化的时候，next和prev都指向自己，qlen的值为0，具体的如下图一：图一链表头的初始化四、skb_frag_struct结构体typedef struct skb_frag_struct skb_frag_t;struct skb_frag_struct {struct page *page;__u16 page_offset;__u16 size;};五、skb_shared_info结构体struct skb_shared_info {atomic_t dataref;unsigned short nr_frags;unsigned short gso_size;unsigned short gso_segs;unsigned short gso_type;__be32 ip6_frag_id;struct sk_buff *frag_list;skb_frag_t frags[MAX_SKB_FRAGS];};Dataref：引用计数，表示数据块的用户数（包括克隆和复制）；nr_frags：存放数据片段的数量；frag_list：数据片段的链表；frags：每一个数据片段的长度；nr_frags, frag_list, frags用来处理ip分片，确认是否被分片，以及分片重组。

化工类毕业设计论文一、引言化工类毕业设计论文是化学工程与工艺专业学生完成学业的重要环节。

通过毕业设计论文，学生可以综合运用所学的专业知识，提高解决实际问题的能力，并为未来的职业生涯做好准备。

本文将探讨化工类毕业设计论文的写作要点和注意事项。

二、论文结构1、封面：包括论文题目、作者姓名、指导教师姓名、学校名称、专业、日期等基本信息。

2、中英文摘要：摘要是论文的简短概述，应包括论文主题、研究目的、方法、结果和结论。

摘要应简洁明了，方便读者快速了解论文内容。

3、目录：列出论文正文的各章节和各个附录的标题。

4、正文：正文是论文的主体部分，应包括引言、文献综述、研究方法、实验结果分析、讨论、结论等部分。

正文应层次分明，逻辑清晰。

5、一、引言随着全球化的深入推进和信息技术的快速发展，经济类毕业论文的撰写变得越来越重要。

经济类毕业论文不仅是对学生学术能力的综合考察，也是对其独立思考和研究能力的锻炼。

本文将探讨经济类毕业论文的写作方法，以期为相关领域的学生和研究者提供有益的参考。

二、经济类毕业论文的特点1、学术性：经济类毕业论文必须具有高度的学术性，其研究问题和所用方法必须符合学术规范和前沿研究成果。

2、创新性：优秀的经济类毕业论文应具有独特的见解和创新性，能够为相关领域的研究提供新的思路和方法。

3、综合性：经济类毕业论文需要综合运用经济学、统计学、数学等多种学科知识，分析问题和解决问题。

4、应用性：经济类毕业论文的研究成果应具有实际应用价值，能够为政府决策、企业发展等提供参考。

三、经济类毕业论文的写作步骤1、选题：选择一个具有研究价值和实际意义的题目是撰写经济类毕业论文的第一步。

学生应根据自身兴趣和专业方向，结合当前经济发展趋势和社会热点问题，选择具有研究潜力的题目。

2、文献综述：在确定题目后，学生应广泛搜集和阅读相关文献，了解已有研究成果和不足之处，为后续研究提供参考。

同时，学生还需对文献进行归纳和评价，指出研究问题和不足，提出自己的研究思路和方法。

conntrack的状态种类conntrack（连接跟踪）是Linux内核中的一个模块，用于跟踪网络连接的状态。

它可以追踪数据包的流动，并维护有关每个连接的信息。

在Linux操作系统中，conntrack模块提供了一种有效的方法来管理网络连接，以确保网络连接的安全和可靠性。

conntrack模块维护了一个连接跟踪表，其中包含了当前活动的连接的状态信息。

下面将介绍conntrack的几种常见的连接状态。

1. NEW（新建连接）：当一个数据包到达系统，但在连接跟踪表中找不到相应的连接时，就会被认为是一个新连接。

在这种状态下，系统会为这个数据包创建一个新的连接条目，并进入下一个状态。

2. ESTABLISHED（已建立连接）：在连接跟踪表中找到匹配的连接后，数据包会被认为是一个已建立连接的数据包。

这个状态表示连接已经成功建立，并可以正常传输数据。

3. RELATED（相关连接）：在某些情况下，系统会根据已有的连接自动创建一些额外的连接。

这些额外的连接被认为是与已有连接相关的连接，比如FTP数据连接、ICMP错误报文等。

4. INVALID（无效连接）：当一个数据包无法被正确处理时，连接会被标记为无效连接。

这可能是因为数据包格式不正确、数据包没有匹配的连接条目等原因。

5. TIME_WAIT（等待超时）：当一个连接被关闭后，它会进入TIME_WAIT状态。

在这个状态下，连接条目会保持一段时间，以确保所有的数据包都被正确处理。

在等待超时后，连接条目会被删除。

6. CLOSE（关闭连接）：当一个连接被主动关闭时，它会进入CLOSE状态。

在这个状态下，系统会等待对方确认连接关闭请求，并进行必要的清理工作。

7. FIN_WAIT（等待对方关闭连接）：当一个连接被主动关闭后，系统会进入FIN_WAIT状态，等待对方关闭连接。

在这个状态下，系统仍然可以接收对方发送的数据包。

8. SYN_SENT（发送SYN包）：当一个主机尝试发起一个连接时，它会发送一个SYN包给对方。

track链路检测原理
Track链路检测原理是通过在网络中注入特定的数据包，并通
过对接收到的数据包的响应进行分析，从而判断网络链路的连通性和故障位置。

具体原理如下：
1. 链路检测端（通常是网络设备或网络管理系统）发送一个特定的数据包（Ping或TraceRoute等），带有一个序列号或其
他识别标志。

2. 数据包经过网络传输到达目标设备。

3. 目标设备收到数据包后，会解析数据包中的信息，并生成响应报文。

4. 响应报文经过网络传回链路检测端。

5. 链路检测端收到响应报文后，分析报文中的信息。

如果报文中的序列号或识别标志与发送的数据包匹配，则确认链路连通；如果不匹配，则认为链路断开或故障。

通过不断地发送、接收和分析数据包的过程，可以确定网络链路的稳定性和可用性，并且可以进一步定位故障的具体位置。

conntrack 监控指标Conntrack 监控指标Conntrack（连接跟踪）是Linux内核中的一个功能，用于跟踪网络连接的状态。

它可以记录每个连接的相关信息，如源IP地址、目的IP地址、源端口、目的端口、连接状态等。

这些连接信息对于网络安全和性能优化非常重要。

在本文中，我们将深入了解Conntrack监控指标，并逐步回答以下问题。

1. 什么是Conntrack监控指标？Conntrack监控指标是用于监控和评估Conntrack功能的性能和状态的参数和指标。

这些指标可以提供关于连接数量、连接状态、内存使用、丢包等方面的信息。

通过监控这些指标，我们可以及时发现问题并采取相应的措施来维护和优化系统的连接跟踪功能。

2. 有哪些常见的Conntrack监控指标？a. Conntrack连接数量：该指标表示当前系统中活动的Conntrack连接的数量。

可以通过命令`cat/proc/sys/net/netfilter/nf_conntrack_count`来查看。

b. Conntrack连接建立速率：该指标表示每秒建立的新连接的数量。

可以通过命令`cat /proc/sys/net/netfilter/nf_conntrack_count`结合时间间隔来计算。

c. Conntrack最大连接数：该指标表示系统所能支持的最大连接数。

这个值通常设置在`/proc/sys/net/netfilter/nf_conntrack_max`中。

d. Conntrack内存使用情况：该指标表示Conntrack功能所占用的内存大小。

可以通过命令`cat/proc/sys/net/netfilter/nf_conntrack_expect_max`来查看。

e. Conntrack丢包率：该指标表示由于内存不够或其他原因导致无法跟踪连接而被丢弃的连接数量占所有连接数量的比例。

3. 如何监控Conntrack连接数量？监控Conntrack连接数量对于了解系统的负载和性能非常重要。

竭诚为您提供优质文档/双击可除linux,ip协议栈源代码分析,pdf篇一：netfilter源代码分析详解一、概述filter/iptables框架简介netfilter/iptables是继2.0.x的ipfwadm、2.2.x的ipchains之后，新一代的linux防火墙机制。

netfilter采用模块化设计，具有良好的可扩充性。

其重要工具模块iptables连接到netfilter的架构中，并允许使用者对数据报进行过滤、地址转换、处理等操作。

netfilter提供了一个框架，将对网络代码的直接干涉降到最低，并允许用规定的接口将其他包处理代码以模块的形式添加到内核中，具有极强的灵活性。

2.主要源代码文件linux内核版本：2.4.21netfilter主文件：net/core/netfilter.cnetfilter主头文件：include/linux/netfilter.hipv4相关：c文件：net/ipv4/netfilter/*.c头文件：include/linux/netfilter_ipv4.hinclude/linux/netfilter_ipv4/*.hipv4协议栈主体的部分c文件，特别是与数据报传送过程有关的部分：ip_input.c，ip_forward.c，ip_output.c，ip_fragment.c等二、netfilter/iptables-ipv4总体架构netfilter主要通过表、链实现规则，可以这么说，netfilter是表的容器，表是链的容器，链是规则的容器，最终形成对数据报处理规则的实现。

详细地说，netfilter/iptables的体系结构可以分为三个大部分：filter的hook机制netfilter的通用框架不依赖于具体的协议，而是为每种网络协议定义一套hook函数。

这些hook函数在数据报经过协议栈的几个关键点时被调用，在这几个点中，协议栈将数据报及hook函数标号作为参数，传递给netfilter框架。

我们使用Linux作为服务器操作系统时，为了达到高并发处理能力，充分利用机器性能，经常会进行一些内核参数的调整优化，但不合理的调整常常也会引起意想不到的其他问题，本文就一次Linux服务器丢包故障的处理过程，结合Linux 内核参数说明和TCP/IP协议栈相关的理论，介绍一些常见的丢包故障定位方法和解决思路。

问题现象本次故障的反馈现象是：从办公网访问公网服务器不稳定，服务器某些端口访问经常超时，但Ping测试显示客户端与服务器的链路始终是稳定低延迟的。

通过在服务器端抓包，发现还有几个特点：∙从办公网访问服务器有多个客户端，是同一个出口IP，有少部分是始终能够稳定连接的，另一部分间歇访问超时或延迟很高∙同一时刻的访问，无论哪个客户端的数据包先到达，服务端会及时处理部分客户端的SYN请求，对另一部分客户端的SYN包“视而不见”，如tcpdump数据所示，源端口为56909的SYN请求没有得到响应，同一时间源端口为50212的另一客户端SYN请求马上得到响应。

Shell1 2 3 4 5 6 7 8 $ sudo tcpdump -i eth0 port 22 and "tcp[tcpflags] & (tcp-syn) != 0"18:56:37.404603 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198321481 ecr 0,nop,wscale 7], length 018:56:38.404582 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198321731 ecr 0,nop,wscale 7], length 018:56:40.407289 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198322232 ecr 0,nop,wscale 7], length 018:56:44.416108 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198323234 ecr 0,nop,wscale 7], length 018:56:45.100033 IP CLIENT.50212 > SERVER.22: Flags [S], seq 4207350463, win 65535, options91011 [mss 1366,nop,wscale 5,nop,nop,TS val 821068631 ecr 0,sackOK,eol], length 018:56:45.100110 IP SERVER.22 > CLIENT.50212: Flags [S.], seq 1281140899, ack 4207350464, win 27960, options [mss 1410,sackOK,TS val 1709997543 ecr 821068631,nop,wscale 7], length 018:56:52.439086 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198325240 ecr 0,nop,wscale 7], length 018:57:08.472825 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198329248 ecr 0,nop,wscale 7], length 018:57:40.535621 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198337264 ecr 0,nop,wscale 7], length 018:57:40.535698 IP SERVER.22 > CLIENT.56909: Flags [S.], seq 3621462255, ack 1190606851, win 27960, options [mss 1410,sackOK,TS val 1710011402ecr 198337264,nop,wscale 7], length 0排查过程服务器能正常接收到数据包，问题可以限定在两种可能：部分客户端发出的数据包本身异常；服务器处理部分客户端的数据包时触发了某种机制丢弃了数据包。

iptables 相关概念在正式介绍 iptables 的使用之前，我们先来看一下和 iptables 相关的一些基本概念。

我们下面将会频繁使用到它们。

∙匹配（match）：符合指定的条件，比如指定的 IP 地址和端口。

∙丢弃（drop）：当一个包到达时，简单地丢弃，不做其它任何处理。

∙接受（accept）：和丢弃相反，接受这个包，让这个包通过。

∙拒绝（reject）：和丢弃相似，但它还会向发送这个包的源主机发送错误消息。

这个错误消息可以指定，也可以自动产生。

∙目标（target）：指定的动作，说明如何处理一个包，比如：丢弃，接受，或拒绝。

∙跳转（jump）：和目标类似，不过它指定的不是一个具体的动作，而是另一个链，表示要跳转到那个链上。

∙规则（rule）：一个或多个匹配及其对应的目标。

∙链（chain）：每条链都包含有一系列的规则，这些规则会被依次应用到每个遍历该链的数据包上。

每个链都有各自专门的用途，这一点我们下面会详细讨论。

∙表（table）：每个表包含有若干个不同的链，比如 filter 表默认包含有 INPUT，FORWARD，OUTPUT 三个链。

iptables 有四个表，分别是：raw，nat，mangle和filter，每个表都有自己专门的用处，比如最常用filter表就是专门用来做包过滤的，而 nat 表是专门用来做NAT的。

∙策略（police）：我们在这里提到的策略是指，对于 iptables 中某条链，当所有规则都匹配不成功时其默认的处理动作。

∙连接跟踪（connection track）：又称为动态过滤，可以根据指定连接的状态进行一些适当的过滤，是一个很强大的功能，但同时也比较消耗内存资源。

iptables 介绍iptables 的表和链：现在，让我们看看当一个数据包到达时它是怎么依次穿过各个链和表的。

基本步骤如下：∙ 1. 数据包到达网络接口，比如 eth0。

∙ 2. 进入 raw 表的 PREROUTING 链，这个链的作用是赶在连接跟踪之前处理数据包。

netfilternf_conntrack模块实现分析一．连接记录的存储相关函数：static inline struct nf_conn *nf_ct_tuplehash_to_ctrack(const structnf_conntrack_tuple_hash *hash)static inline struct nf_conn *nf_ct_get(const struct sk_buff *skb, enum ip_conntrack_info *ctinfo)nf_conntrack中tuple存储如上图所示。

在struct nf_conntrack_tuple_hash中，成员hnode链接入ct->hash[]->first 中的。

实际的记录在保存在struct nf_conntrack_tuple中。

1.记录的访问：hlist_nulls_for_each_entry_rcu103 #define hlist_nulls_for_each_entry_rcu(tpos, pos, head, member) \104 for (pos = rcu_dereference((head)->first); \105 (!is_a_nulls(pos)) && \106 ({ tpos = hlist_nulls_entry(pos, typeof(*tpos), member);1; }); \ 107 pos = rcu_dereference(pos->next))108参见/net/netfilter/nf_conntrack_core.c __nf_conntrack_find 函数；struct nf_conntrack_tuple_hash *h;struct hlist_nulls_node *n;hlist_nulls_for_each_entry_rcu(h, n, &net->ct.hash[hash], hnnode)2.记录的添加84 static inline void hlist_nulls_add_head_rcu(struct hlist_nulls_node *n,85 struct hlist_nulls_head *h)86 {87 struct hlist_nulls_node *first = h->first;8889 n->next = first;90 n->pprev = &h->first;91 rcu_assign_pointer(h->first, n);92 if (!is_a_nulls(first))93 first->pprev = &n->next;94 }参见/net/netfilter/nf_conntrack_core.c：313 static void __nf_conntrack_hash_insert(struct nf_conn *ct, 314 unsigned int hash,315 unsigned int repl_hash)316 {317 struct net *net = nf_ct_net(ct);318319hlist_nulls_add_head_rcu(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode,320 &net->ct.hash[hash]);321hlist_nulls_add_head_rcu(&ct->tuplehash[IP_CT_DIR_REPLY].hnn ode,322 &net->ct.hash[repl_hash]);323 }3.记录的删除59 static inline void hlist_nulls_del_rcu(struct hlist_nulls_node *n)60 {61 __hlist_nulls_del(n);62 n->pprev = LIST_POISON2;63 }59 static inline void __hlist_nulls_del(struct hlist_nulls_node *n)60 {61 struct hlist_nulls_node *next = n->next;62 struct hlist_nulls_node **pprev = n->pprev;63 *pprev = next;64 if (!is_a_nulls(next))65 next->pprev = pprev;66 }二．nf_conntrack模块的初始化/net/netfilter/nf_conntrack_standalone.c510 static int __init nf_conntrack_standalone_init(void)511 {512 return register_pernet_subsys(&nf_conntrack_net_ops); 513 }473 static int nf_conntrack_net_init(struct net *net)475 int ret;476477 ret = nf_conntrack_init(net);478 if (ret < 0)479 goto out_init;480 ret = nf_conntrack_standalone_init_proc(net);481 if (ret < 0)482 goto out_proc;483 net->ct.sysctl_checksum = 1;484 net->ct.sysctl_log_invalid = 0;485 ret = nf_conntrack_standalone_init_sysctl(net);486 if (ret < 0)487 goto out_sysctl;488 return 0;489447-------：/net/netfilter/nf_conntrack_core.c#nf_conntrack_init1275 int nf_conntrack_init(struct net *net)1276 {1277 int ret;12781279 if (net_eq(net, &init_net)) {1280 ret = nf_conntrack_init_init_net();1281 if (ret < 0)1282 goto out_init_net;1283 }1284 ret = nf_conntrack_init_net(net);1285 if (ret < 0)1286 goto out_net;1288 if (net_eq(net, &init_net)) {1289 /* For use by REJECT target */1290 rcu_assign_pointer(ip_ct_attach, nf_conntrack_attach);1291 rcu_assign_pointer(nf_ct_destroy, destroy_conntrack);1292 }1293 return 0;1294-----------------------/net/netfilter/nf_conntrack_core.c#nf_conntrack_init_net 1223 static int nf_conntrack_init_net(struct net *net)1224 {1225 int ret;12261227 atomic_set(&net->ct.count, 0);1228 INIT_HLIST_NULLS_HEAD(&net->ct.unconfirmed, 0);1229 net->ct.stat = alloc_percpu(struct ip_conntrack_stat);1234 ret = nf_conntrack_ecache_init(net);1237 net->ct.hash = nf_ct_alloc_hashtable(&nf_conntrack_htable_size,1238 &net->ct.hash_vmalloc, 1);1244 ret = nf_conntrack_expect_init(net);1247 ret = nf_conntrack_acct_init(net);1253 #ifdef CONFIG_NET_NS1254 nf_conntrack_untracked.ct_net = &init_net;1255 #endif1256 atomic_set(&nf_conntrack_untracked.ct_e, 1);1257 /* - and look it like as a confirmed connection */1258 set_bit(IPS_CONFIRMED_BIT, &nf_conntrack_untracked.status);1260 return 0;这个函数所做的主要工作就是初始化net中的net->ct中的成员。

conntrack老化逻辑
Conntrack是Linux内核中的一个模块，用于跟踪网络连接的状态。

它可以帮助内核跟踪网络连接的状态，包括连接的源地址、目的地址、端口等信息。

而"老化逻辑"是指连接跟踪表中的连接状态超时后被删除的机制。

在Conntrack中，老化逻辑是指对连接状态进行定期检查，并删除那些超时的连接状态。

这个超时时间可以通过内核参数进行配置。

当连接状态超过了设定的超时时间，Conntrack会将这些连接状态标记为过期，并在一定时间后从连接跟踪表中删除。

这样可以避免连接跟踪表中积累过多的过期连接状态，从而提高系统的性能和资源利用率。

老化逻辑的实现通常是通过定时器来实现的，内核会周期性地检查连接状态的超时情况，并进行相应的处理。

这个处理通常包括标记连接状态为过期并删除过期状态的连接。

这样可以保持连接跟踪表中的状态信息的及时性和准确性。

另外，老化逻辑还可以通过一些策略来优化连接状态的管理，例如对不同类型的连接状态采用不同的超时时间，以及根据连接状
态的使用情况动态调整超时时间等方式，从而更加灵活地管理连接状态的老化。

总之，Conntrack中的老化逻辑是保证连接跟踪表中的状态信息及时、准确地进行管理和清理的重要机制，它通过定期检查连接状态的超时情况，并删除过期状态的连接，从而提高系统的性能和资源利用率。

Netfilter之连接跟踪相关数据结构Netfilter通过连接跟踪来记录和跟踪连接的状态，为状态防⽕墙和NAT提供基础⽀持；钩⼦点与钩⼦函数下图为钩⼦点和钩⼦函数的关系图，其中ipv4_conntrack_defrag、ipv4_conntrack_in、ipv4_helper、ipv4_confirm为连接跟踪相关的钩⼦函数，其作⽤的钩⼦点为PRE_ROUTING、LOCAL_IN、LOCAL_OUT、POST_ROUTING：钩⼦函数的调⽤流程通过上图，可以得到连接跟踪的流程：输⼊本地：ipv4_conntrack_defrag–>ipv4_conntrack_in–>ipv4_helper–>ipv4_confirm【<————-PRE_ROUTING————>】【<—— LOCAL_IN——>】转发：ipv4_conntrack_defrag–>ipv4_conntrack_in–>ipv4_helper–>ipv4_confirm【<————-PRE_ROUTING————>】【<—— LOCAL_IN——>】本地输出：ipv4_conntrack_defrag–>ipv4_conntrack_local–>ipv4_helper–>ipv4_confirm【<————–LOCAL_OUT—————–>】【<—-POST_ROUTING—>】连接跟踪的状态ip_conntrack_info⽤来描述连接跟踪的状态，如下：1enum ip_conntrack_info {2/* Part of an established connection (either direction). */3/* 已建⽴连接的⼀部分(任⼀⽅向) */4 IP_CT_ESTABLISHED,56/* Like NEW, but related to an existing connection, or ICMP error7 (in either direction). */8/* 已建⽴连接的关联连接，或者是ICMP错误(任⼀⽅向) */9 IP_CT_RELATED,1011/* Started a new connection to track (only12 IP_CT_DIR_ORIGINAL); may be a retransmission. */13/* 开始⼀个新连接; 可能是重传 */14 IP_CT_NEW,1516/* >= this indicates reply direction */17/* >=这个值的都是响应⽅向的 */18 IP_CT_IS_REPLY,1920/* 已建⽴连接的响应 */21 IP_CT_ESTABLISHED_REPLY = IP_CT_ESTABLISHED + IP_CT_IS_REPLY,22/* 已建⽴连接的关联连接的响应 */23 IP_CT_RELATED_REPLY = IP_CT_RELATED + IP_CT_IS_REPLY,24/* No NEW in reply direction. */2526/* Number of distinct IP_CT types. */27/* IP_CT类型的数量 */28 IP_CT_NUMBER,2930/* only for userspace compatibility */31 #ifndef __KERNEL__32 IP_CT_NEW_REPLY = IP_CT_NUMBER,33#else34 IP_CT_UNTRACKED = 7,35#endif36 };数据结构图本⽂中涉及的数据结构之间的关系图如下：源码分析nf_conn是对连接跟踪抽象的基础结构，其中tuplehash为连接跟踪nf_conntrack_tuple的hash，分两个⽅向； 1struct nf_conn {2/* Usage count in here is 1 for hash table, 1 per skb,3 * plus 1 for any connection(s) we are `master' for4 *5 * Hint, SKB address this struct and refcnt via skb->_nfct and6 * helpers nf_conntrack_get() and nf_conntrack_put().7 * Helper nf_ct_put() equals nf_conntrack_put() by dec refcnt,8 * beware nf_ct_get() is different and don't inc refcnt.9*/10/* 连接跟踪的引⽤计数 */11struct nf_conntrack ct_general;1213 spinlock_t lock;14 u16 cpu;1516 #ifdef CONFIG_NF_CONNTRACK_ZONES17struct nf_conntrack_zone zone;18#endif19/* XXX should I move this to the tail ? - Y.K */20/* These are my tuples; original and reply */21/* 连接跟踪两个⽅向的tuple节点，即五元组 */22struct nf_conntrack_tuple_hash tuplehash[IP_CT_DIR_MAX];2324/* Have we seen traffic both ways yet? (bitset) */25/* 状态 */26 unsigned long status;2728/* jiffies32 when this ct is considered dead */29/* 连接跟踪的超时时间 */30 u32 timeout;3132/* 命名空间 */33 possible_net_t ct_net;3435#if IS_ENABLED(CONFIG_NF_NAT)36struct rhlist_head nat_bysource;37#endif38/* all members below initialized via memset */39 u8 __nfct_init_offset[0];4041/* If we were expected by an expectation, this will be it */42/* 如果当前连接是某个连接期望的连接，该字段指向主连接 */43struct nf_conn *master;4445#if defined(CONFIG_NF_CONNTRACK_MARK)46 u_int32_t mark;47#endif4849 #ifdef CONFIG_NF_CONNTRACK_SECMARK50 u_int32_t secmark;51#endif5253/* Extensions */54/* 扩展项 */55struct nf_ct_ext *ext;5657/* Storage reserved for other modules, must be the last member */58/* 不同协议实现连接跟踪的额外参数 */59 union nf_conntrack_proto proto;60 };nf_conntrack_tuple_hash的定义如下：1struct nf_conntrack_tuple_hash {2struct hlist_nulls_node hnnode;3struct nf_conntrack_tuple tuple;4 };nf_ct_ext⽤于实现对连接跟踪的扩展；1struct nf_ct_ext {2struct rcu_head rcu;3 u8 offset[NF_CT_EXT_NUM];4 u8 len;5char data[0];6 };nf_conntrack_tuple是⽤来区分⼀条连接的信息，定义如下：1/* 该结构包含源⽬的信息⽤来区分⼀条连接 */2struct nf_conntrack_tuple {3/* 源，可操作? */4struct nf_conntrack_man src;56/* These are the parts of the tuple which are fixed. */7/* ⽬的，不可操作? */8struct {9 union nf_inet_addr u3;10 union {11/* Add other protocols here. */12 __be16 all;1314struct {15 __be16 port;16 } tcp;17struct {18 __be16 port;19 } udp;20struct {21 u_int8_t type, code;22 } icmp;23struct {24 __be16 port;25 } dccp;26struct {27 __be16 port;28 } sctp;29struct {30 __be16 key;31 } gre;32 } u;3334/* The protocol. */35/* 协议 */36 u_int8_t protonum;3738/* The direction (for tuplehash) */39/* ⽅向(tuplehash使⽤) */40 u_int8_t dir;41 } dst;42 };上⾯结构中的源⽅向信息使⽤了nf_conntrack_man结构，其中包括了三层识别信息，四层识别信息，以及三层协议号； 1/* The manipulable part of the tuple. */2/* tuple可操作的部分？ */3struct nf_conntrack_man {4/* 三层识别信息 */5 union nf_inet_addr u3;6/* 四层识别信息 */7 union nf_conntrack_man_proto u;8/* Layer 3 protocol */9/* 三层协议号 */10 u_int16_t l3num;11 };1 union nf_inet_addr {2 __u32 all[4];3 __be32 ip;4 __be32 ip6[4];5struct in_addr in;6struct in6_addr in6;7 };1/* The protocol-specific manipulable parts of the tuple: always in2 * network order3*/4 union nf_conntrack_man_proto {5/* Add other protocols here. */6 __be16 all;78struct {9 __be16 port;10 } tcp;11struct {12 __be16 port;13 } udp;14struct {15 __be16 id;16 } icmp;17struct {18 __be16 port;19 } dccp;20struct {21 __be16 port;22 } sctp;23struct {24 __be16 key; /* GRE key is 32bit, PPtP only uses 16bit */25 } gre;26 };nf_conn中的proto成员⽤来存储协议特有的⽤来表⽰连接跟踪的信息，其联合体nf_conntack_proto定义如下：1/* per conntrack: protocol private data */2 union nf_conntrack_proto {3/* insert conntrack proto private data here */4struct nf_ct_dccp dccp;5struct ip_ct_sctp sctp;6struct ip_ct_tcp tcp;7struct nf_ct_gre gre;8 unsigned int tmpl_padto;9 };下⾯是TCP的⼀些必要信息；1struct ip_ct_tcp {2struct ip_ct_tcp_state seen[2]; /* connection parameters per direction */3 u_int8_t state; /* state of the connection (enum tcp_conntrack) */4/* For detecting stale connections */5 u_int8_t last_dir; /* Direction of the last packet (enum ip_conntrack_dir) */6 u_int8_t retrans; /* Number of retransmitted packets */7 u_int8_t last_index; /* Index of the last packet */8 u_int32_t last_seq; /* Last sequence number seen in dir */9 u_int32_t last_ack; /* Last sequence number seen in opposite dir */10 u_int32_t last_end; /* Last seq + len */11 u_int16_t last_win; /* Last window advertisement seen in dir */12/* For SYN packets while we may be out-of-sync */13 u_int8_t last_wscale; /* Last window scaling factor seen */14 u_int8_t last_flags; /* Last flags set */15 };1struct ip_ct_tcp_state {2 u_int32_t td_end; /* max of seq + len */3 u_int32_t td_maxend; /* max of ack + max(win, 1) */4 u_int32_t td_maxwin; /* max(win) */5 u_int32_t td_maxack; /* max of ack */6 u_int8_t td_scale; /* window scale factor */7 u_int8_t flags; /* per direction options */8 };。

路由跟踪表满，⽇志报错nf_conntrack：tablefull,droppingpacket.“连接跟踪表已满，开始丢包”！相信不少⽤iptables的同学都会见过这个吧，这个问题曾经也困扰过我好长⼀段时间。

此问题的解决办法有四种（nf_conntrack 在CentOS 5 /kernel <= 2.6.19中名为 ip_conntrack ）：⼀、关闭防⽕墙。

简单粗暴，直接有效chkconfig iptables offchkconfig ip6tables offservice iptables stopservice ip6tables stop切记：在防⽕墙关闭状态下，不要通过iptables指令（⽐如 iptables -nL）来查看当前状态！因为这样会导致防⽕墙被启动，⽽且规则为空。

虽然不会有任何拦截效果，但所有连接状态都会被记录，浪费资源且影响性能并可能导致防⽕墙主动丢包！⼆、加⼤防⽕墙跟踪表的⼤⼩，优化对应的系统参数1、状态跟踪表的最⼤⾏数的设定，理论最⼤值 CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (ARCH / 32)以64G的64位操作系统为例，CONNTRACK_MAX = 64*1024*1024*1024/16384/2 = 2097152即时⽣效请执⾏：sysctl –w filter.nf_conntrack_max = 20971522、其哈希表⼤⼩通常为总表的1/8，最⼤为1/2。

CONNTRACK_BUCKETS = CONNTRACK_MAX / 8同样64G的64位操作系统，哈希最佳范围是 262144 ~ 1048576 。

运⾏状态中通过 sysctl filter.nf_conntrack_buckets 进⾏查看，通过⽂件 /sys/module/nf_conntrack/parameters/hashsize 进⾏设置或者新建 /etc/modprobe.d/iptables.conf ，重新加载模块才⽣效：options nf_conntrack hashsize = 2621443、还有些相关的系统参数`sysctl -a | grep nf_conntrack`可以调优（/etc/sysctl.conf ）：filter.nf_conntrack_max = 1048576filter.ip_conntrack_tcp_timeout_established = 3600filter.nf_conntrack_tcp_timeout_close_wait = 60filter.nf_conntrack_tcp_timeout_fin_wait = 120filter.nf_conntrack_tcp_timeout_time_wait = 120三、使⽤祼表，添加“不跟踪”标识。