iptables性能测试：从开发环境到生产环境的踩坑记录
最近在为公司核心服务器部署防火墙策略时，遇到了一个令人头疼的问题：iptables规则在高并发场景下性能急剧下降。作为系统管理员，我们不能让安全策略成为系统瓶颈。
测试环境搭建
首先，我准备了三台虚拟机：
- 测试机：Ubuntu 20.04，Intel i7-8750H，16GB内存
- 负载生成器：Ubuntu 20.04，Intel i5-7200U，8GB内存
- 目标服务器：CentOS 8，4核CPU，8GB内存
初始配置与问题发现
最初我使用了简单的规则集：
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -j DROP
在轻负载测试中一切正常，但当使用hping3模拟1000并发连接时，服务器CPU使用率飙升至95%，响应时间从2ms增加到200ms。
深入排查过程
通过iptables -L -n -v发现：
- 规则匹配效率低：每条规则都要遍历所有规则
- 连接跟踪消耗大：默认启用conntrack模块导致内存占用激增
- 规则复杂度问题：大量类似规则导致性能下降
解决方案与优化
最终采用以下策略：
- 启用连接跟踪优化：
modprobe nf_conntrack hashsize=4096
- 合并相似规则：
iptables -A INPUT -p tcp --dport 80:443 -j ACCEPT
- 使用hashlimit限制：
iptables -A INPUT -m hashlimit --hashlimit-name http --hashlimit 10/sec -j ACCEPT
- 启用硬件加速：在支持的网卡上开启TCP offload功能
性能对比结果
- 优化前：并发1000时，平均响应时间200ms，CPU占用95%
- 优化后：并发1000时，平均响应时间15ms，CPU占用30%
这个案例提醒我们，在生产环境中部署防火墙策略前，必须进行充分的压力测试，避免安全与性能的两难境地。
讨论