调整你的LINUX NETFILTER 参数－－应对P2P应用
echo 8192 > /proc/sys/net/ipv4/ip_conntrack_max一直没怎么关注 /proc/sys/net/ipv4/netfilter/ 下的东东～凌晨下了游戏，邮件列表有封关于ip_conntrack 的。刚才仔细看了看，又对照了偶的CL，发现确实不错，很适合P2P应用较多的地方。写入你的rc.local吧～:lol 绝对有效果。我记得最初用ROS的时候就注意过，不过那时候还不知道为什么会有一个连接建立要保存几天的原因。上面的命令就不说了～
举个例子：/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established 这个参数LINUX默认是 432000，单位是秒，就是 5 天！下面这些例子中，除了ip_conntrack_max之外，其他的参数单位都是秒，个人考虑，除了ip_conntrack_max需要单独设置外，其他参数如果要调整的更小，一定要注意保持合理，某几个参数最好是对应的2倍关系。大家自己去尝试吧，偶还在看文档～不过这个例子可以直接拿来用的。
比如 /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close 这个参数，最好不要小于 5。
如果其他参数调整合理，ip_conntrack_max 这个参数完全可以 设置为 2048，而不必设置过大，再者过大的连接跟踪表对系统也是个负担。具体的还是看情况吧。
echo 8192 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
echo 600 > /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout
echo 10 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close
echo 120 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
echo 1200 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
echo 120 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
echo 60 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
/proc/sys/net/ipv4/ip_conntrack_max 参数值最好大于 /proc/sys/net/ipv4/netfilter/ip_conntrack_max 值。 顺便说一下，偶自己的CL密码似乎不安全了，居然有人给我改设置～汗死了～。 我上个星期天看到有人用字典攻击我的ssh端口,所以密码还是特殊点好.
相反意见呵呵~~
开始我认为ip_conntrack_max最大只能到65536原因是tcp/ip只有65535个端口，做pat时一个ip最多能65535个连接，但从tcp/ip资料上获得双方主机在建立双向有回应的连接时端口可以复用，也就是比如说80端口pat时可以看见远远>1个established，所以max值缩小可以带来显而易见的设备生存时间。我只对tcp/ip_conntrack_tcp_timeout_established作了调整，时间为600秒。
这就意味一旦两个主机已建立连接而且该连接一直用于发送和接收信息包并且有效时，10分钟后切断该连接然后再走一次new的过程。大大减少连接数。
也许你会问网游这不10分钟一掉？no!this for tcp/ip no udp!!cs-->udp 27015 传奇-->udp 7000
qq&&msn --udp ......
bt等p2p抓包分析首先
b->asyn请求
a->b syn/ack回应同时连接a
b->a ACK 建立一个established
搜索种子时会产生大量这种established,5天的时间对于一个狂热的p2p用户可能产生10w个established呵呵。虽然没下载多少数据但连接却一点不少。
sorry说多了。
总言概括ip_conntrack_max作限制就等于把pix525变成了tplink480!无需调整撒！ 默认的很长的 established 时间就是为了再次连接能够省去再次建立的时间，这个勿庸置疑。关键问题是已经 established 的连接是否还要占用ip_conntrack表空间？
“总言概括ip_conntrack_max作限制就等于把pix525变成了tplink480!无需调整撒！”说的很对～ 好文章，作个记号先，谢谢 学习一下。
回复 #7 add1132 的帖子
下面的内容我是从网上找到的,对ip_conntrack_tcp_timeout_established的设置值我认为完全可以设置得更小??正常的tcp连接比如HTTP什么的，数据传输完成后就会通过fin结束连接，不需要超时老化；真正需要老化掉的连接信息，应该是来自于意外中断的tcp连接，比如连接状态非常不确定的P2P，刚刚syn ack后开始传数据了，可服务端关闭了P2P软件或死机、关机了，咱们的ip_conntrack表里就多了一项，而且要保持很长时间，这是非常不必要的，在NAT负载大的时候甚至是非常有害的。这个值可以参考一些专门的硬防火墙中的aging time设置，我所见过的一般都不超过180秒，个人认为，90～120就足够了
回复a99456820 的帖子
谢谢你的提醒，我这里的测试环境太小了，不好测试。 作个记号
页:
[1]