关于FULL CONE NAT对路由性能带来的影响研究

xy***

已废弃，最终版见：https://www.right.com.cn/forum/thread-4031767-1-1.html


最近打开了FULL CONE NAT，发现对路由的性能影响还是挺大的，同时也发现了SFE在这种场景下能大幅降低CPU占用率。

路由：K2P
固件：无灯老毛子20180402-0237
其他耗费CPU的功能：SQM-QOS

1W连接数，打开FULL CONE NAT，不开SFE，CPU每分钟占用飙到4，无法跑满带宽，同时日志疯狂的报kernel: [<860a3390>] 0x860a3390
1W连接数，打开FULL CONE NAT，打开SFE，CPU每分钟占用不超过1，同时能跑满140Mbps带宽
2W连接数，打开FULL CONE NAT，打开SFE，CPU每分钟占用1.5~2，能跑满140Mbps带宽，路由界面响应缓慢
2.5W连接数，Classical Linux Hybrid NAT，打开SFE，CPU每分钟占用1.5~2，能跑满140Mbps带宽，路由界面响应缓慢

发现之前有位恩山的朋友已经发过帖子问过[K2P刷哪个固件能顶住2万五个连接数]

实测下来，2.5W连接数能抗住，但是网络体验比较糟糕，尤其是WIFI影响很大，内网看个不到20Mbps码率的电影都看不了。

对于FULL CONE NAT，如果是BT下载，不一定会提速，受限于路由器的性能，反而可能变慢。

================以下内容20200215更新=================

找到解决办法了，系统启动前更改以下内核参数

1. echo 32768     > /proc/sys/net/core/somaxconn
   
2. echo 16384     > /proc/sys/net/core/netdev_max_backlog
   
3. echo 16384     > /proc/sys/net/ipv4/tcp_max_syn_backlog
   
4. echo 15       > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_close_wait
   
5. echo 30       > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_fin_wait
   
6. echo 30       > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_time_wait
   
7. echo 300      > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established
   
8. echo 30       > /proc/sys/net/netfilter/nf_conntrack_udp_timeout
   
9. echo 120      > /proc/sys/net/netfilter/nf_conntrack_udp_timeout_stream

复制代码

连接数过多会达到K2P CPU的瓶颈，但是其实很多连接都是在等待释放的状态（TIME_WAIT），所以这个办法主要是让路由器快速释放这些连接。

注意，这个办法并不能起到让K2P超过2W连接数不卡的作用，只是能有效抑制连接数的增长。


同样的测试环境下（P2P），改之前netfilter表跟踪了10000的连接数，改之后3000-5000左右；前面三个可能是没用的，不过无害就是了。

li***

过来学习的了。

2371***

k2p开hwnat测的full cone

xy***

237176253 发表于 2020-2-14 17:31
k2p开hwnat测的full cone

你这个数据和我的差不多呀，1W5以下的连接数+SFE，也是这个水平。

跟HW_NAT没关系，是netfilter的跟踪连接数太多CPU就高了。

这两天已经研究出改善的方法了，见主贴

米***

hashsize是个重要的参数，大型集群和他有关的参数一并调整。国内网站介绍的基本不全，看kernel的文档，有全面的介绍，大型公共集群常用，一般，跑到楼主说的 连接数x2 连接不会卡顿。

米***

这里还涉及到网络设备自身的缓存和转发能力。

xy***

米达 发表于 2020-2-15 05:05
hashsize是个重要的参数，大型集群和他有关的参数一并调整。国内网站介绍的基本不全，看kernel的文档，有全 ...

影响hashsize的是net.netfilter.nf_conntrack_buckets和net.netfilter.nf_conntrack_max吧，不是这个原因。

这个路由器的CPU性能不够，netfilter只能拉住2W5左右的连接数，但是各固件本身的参数问题，可能释放time-wait的时间很长，所以P2P连接数会猛涨到超出CPU性能的数值

我的解决办法是缩短时间，尽快释放掉time-wait的连接。

米***

xykz 发表于 2020-2-15 18:59
影响hashsize的是net.netfilter.nf_conntrack_buckets和net.netfilter.nf_conntrack_max吧，不是这个原因 ...

和CPU关系大吗？最好看看文档。

xy***

米达 发表于 2020-2-15 22:06
和CPU关系大吗？最好看看文档。

1. [K2P /home/root]# sysctl net.netfilter.nf_conntrack_buckets
   
2. net.netfilter.nf_conntrack_buckets = 16384
   
3. [K2P /home/root]# sysctl net.netfilter.nf_conntrack_max
   
4. net.netfilter.nf_conntrack_max = 65536
   
5. [K2P /home/root]#
   

复制代码

这是我的配置，而且到了2W5左右，CPU的负载已经到了2以上，难道不是这个原因？

米***

xykz 发表于 2020-2-15 22:14
这是我的配置，而且到了2W5左右，CPU的负载已经到了2以上，难道不是这个原因？

这几个linux核心参数太少。还需要你的网络设备的转发能力、背板的参数。
为什么mtk硬件网络加速和netfilter不兼容，就是因为linux默认netfilter不能处理限制以上的转发；
而公网硬件转发能力，往往十几万以上甚至更高。

xy***

米达 发表于 2020-2-16 07:53
这几个linux核心参数太少。还需要你的网络设备的转发能力、背板的参数。
为什么mtk硬件网络加速和netfil ...

是啊，所以我的意思就是硬件的性能跟不上了嘛。

米***

xykz 发表于 2020-2-17 11:42
是啊，所以我的意思就是硬件的性能跟不上了嘛。

握手。其实还能提升，参见文档。因驱动不同、核心不同有所区别。多试几个不同的驱动固件，就能发现，高速率和高连接驱动和核心设置上有很多不同。

ByB***

米达 发表于 2020-2-17 13:18
握手。其实还能提升，参见文档。因驱动不同、核心不同有所区别。多试几个不同的驱动固件，就能发现，高速 ...

说了半天文档倒是发下看看呢

米***

ByByMe 发表于 2020-2-17 13:22
说了半天文档倒是发下看看呢

https://www.netfilter.org/
https://www.kernel.org/

慢慢品

xy***

米达 发表于 2020-2-17 13:18
握手。其实还能提升，参见文档。因驱动不同、核心不同有所区别。多试几个不同的驱动固件，就能发现，高速 ...

哈哈，这一块我不专业，linux内核参数也是对应用类的比较熟，跟路由侧重的参数不一样。