1、背景

使用netfilter实现NAT功能是网络技术中常用的一种方式，但是在未对netfilter的参数做任何优化的情况下，且业务流量比较大的情况下会遇到部分NAT失效的情况。

2、技术分析

在使用netfilter的NAT规则后，会生成对应的Conntrack连接跟踪记录信息，在对应连接跟踪记录表满的情况下，新的请求将会被drop，因此会遇到NAT失效的情况。

Conntrack连接跟踪记录会存储在hashtable里面，涉及到一个查询时间与存储空间的效率问题： 连接跟踪entry hash到对应的hash桶（bucket）中，每个bucket中只有一个link node，每个link node中只存储一个entry（直接把entry放在bucket里），能达到效率最高O（1），但是hashtable表中占用很大的存储空间； 采用hashtable + linknode list的方案能在存储空间和查询效率之间取个平衡，其中连接跟踪entry会hash到对应hash桶（bucket）中，bucket里面是常用的link node list单链表来存放多个entry的信息，其中bucket里面存储的是头指针，其中bucket是直接占用内存，若按照nf_conntrack的struck结构体来分配则占用大约300字节，若桶里放的是该单链表的头指针则一般为8字节，可以大幅度减少内存空间；官方推荐一般bucket中存储4个entry，即nf_conntrack_max = nf_conntrack_buckets *4，四倍的关系，其查询效率为O（1）+O（4），即查询hash表到bucket，再插叙link node list单链表到具体entry的地址；

3、参数优化 

其中在内核中Conntrack重要相关的参数有：

net.netfilter.nf_conntrack_count，表示当前连接跟踪数；

net.netfilter.nf_conntrack_max，表示最大连接跟踪数；

net.netfilter.nf_conntrack_buckets，表示连接跟踪表的大小（bucket桶数量）；

net.netfilter.nf_conntrack_tcp_timeout_established，tcp会话的超时时间，默认是432000 (5天)； net.netfilter.nf_conntrack_tcp_timeout_time_wait，tcp处于 TIME_WAIT 的超时时间，默认 120s； 

conntrack_max和conntrack_buckets参数计算和设置：

CONNTRACK_MAX的最大值取与宿主机内存有关系，对应计算关系为CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (ARCH / 32)，其中 ARCH 为 CPU 架构，值为 32 或 64位，即32 位系统使用内存的 1/16384，64 位系统再减半，如32位的64G系统，conntrack_max  = (64 * 1024^3) / 16384 / (32 / 32) =4,194,304，约为400万的entry，bucket的数量按照官方推荐的为entry的四分之一计算，conntrack_buckets = 4194304/4 = 1048576 约为100万；则这两个参数可设置在系统中；

计算算内存占用，其中nf_conntrack struck本身初始化就得占用300左右字节，bucket中link node指针占用个8个字节，则内存占用 = 4194304 * 300 + 1048576 * 8 = 1266679808字节 = 1208M 

若在已经配置合理conntrack_max和conntrack_buckets情况下，实际的conntrack数量超过max，则需要进行如下优化： nf_conntrack_tcp_timeout_time_wait，time_wait为了让包收收尾，早前网络不稳定，预留2分钟为了让这些释放连接的包能在2分钟内顺利到达，现在网络环境好了，connection track没必要跟踪这么长时间，可以设置成60s或更小，connection track的数量立马下降； nf_conntrack_tcp_timeout_established也会影响conntrack track数量 ，该参数会跟踪一个记录5days（官方推荐），这个值对应的场景是 “双方建立了连接后一直不发包，直到 5 天后才发”，可以把该值改为600s。