找回密码
 用户注册

QQ登录

只需一步,快速开始

查看: 3419|回复: 0

很实用的LinuTCP优化大并发短链的优化选项

[复制链接]
 楼主| 发表于 2015-12-31 08:47:04 | 显示全部楼层 |阅读模式

相信有一定 Linux 服务器运维经验的人肯定见过这个问题:dmesg 或者 /var/log/messages 里大片地输出类似这样的日志:

12Dec  8 11:22:29 product08 kernel: nf_conntrack: table full, dropping packet.Dec  8 11:22:29 product08 kernel: nf_conntrack: table full, dropping packet.

同时服务器上的各种网络服务耗时大幅上升,各种 timed out,各种丢包,完全无法正常提供服务。

随着我们流量的提升,最近又开始被这个问题虐了。几个月前第一次遇到此问题的时候,我们使用了提高 nf_conntrack table size 的方法解决的,事实证明这是个治标不治本的方法,流量上来了,改得再大最后还是会爆掉。况且 table 太大,占用的内存也会很多。

今天再次研究了一下这个问题,换了另一种更好的方案,尝试解决掉它。简单地说,方案就是在 iptables raw 表里增加规则,将无需跟踪状态的包标记为 NOTRACK,这样就无需耗费 nf_conntrack table entry 来记录其状态了。

1. nf_conntrack 是干嘛的

nf_conntrack(在老版本的 Linux 内核中叫 ip_conntrack)是一个内核模块,用于跟踪一个连接的状态的。连接状态跟踪可以供其他模块使用,最常见的两个使用场景是 iptables 的 nat 的 state 模块。

iptables 的 nat 通过规则来修改目的/源地址,但光修改地址不行,我们还需要能让回来的包能路由到最初的来源主机。这就需要借助 nf_conntrack 来找到原来那个连接的记录才行。

而 state 模块则是直接使用 nf_conntrack 里记录的连接的状态来匹配用户定义的相关规则。例如下面这条 INPUT 规则用于放行 80 端口上的状态为 NEW 的连接上的包。

1iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT

2. 能否完全禁用 nf_conntrack

能否禁用 nf_conntrack 要看服务器干啥了,如果没有使用 nat 模块和 state 模块是可以禁用掉它的,这样做一劳永逸,再也不用被这个恶心的问题折磨了。

但是我发现 RHEL 默认的 iptables 规则里都是用到了 state 模块的:

12345iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPTiptables -A INPUT -p icmp -j ACCEPTiptables -A INPUT -i lo -j ACCEPTiptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPTiptables -A INPUT -j REJECT --reject-with icmp-host-prohibited

按理说打开端口的规则完全不需要使用 -m state --state NEW,只要匹配了目标端口直接放行就好。我理解这样做是为了优化性能。注意看第一条规则,只要连接状态是 ESTABLISHED 或者 RELATED 直接放行。这样做,只有连接初始化时的包需要经过下面的重重规则去一条条匹配,一旦建立上连接了(代表被放行了),后续的包直接通过第一条规则就放行了,省去了一条条匹配后续规则的麻烦(O(1)复杂度?)。

反之,如果我们不这么写,那连接的每个包都需要经过前面的层层规则过滤之后才能被放行,对性能有影响(O(n)复杂度?)。当然只有 iptables 规则很多的时候,这个问题才能突显,且到底能带来多大的影响,我手头没有测试数据,还不是特别清楚。

保险起见,我们就没有全部禁用掉 nf_conntrack,而是采用了 raw 表来部分地禁用连接跟踪。

3. 哪些连接可以不必跟踪状态

我们先看看怎么通过 raw 表针对部分连接禁用 conntrack。

1234# 针对进入本机的包iptables -t raw -A PREROUTING -p tcp -m tcp --dport 8080 -j NOTRACK# 针对从本机出去的包iptables -t raw -A OUTPUT -p tcp -m tcp --dport 8080 -j NOTRACK

重点就是 -t raw 和 -j NOTRACK,前者指定 table,后者指定 action 为 NOTRACK——不跟踪状态。

那么问题来了,要针对哪些连接应用此规则呢?需要 NAT 的肯定不行,各种 redirect 的连接本质上也是 NAT,也一样不行。除此之外的大部分的普通连接都是可以的。

比如所有 lo 接口上的连接:

12iptables -t raw -A PREROUTING -i lo -j NOTRACKiptables -t raw -A OUTPUT -o lo -j NOTRACK

在应用和 Nginx 都跑在一台服务器上的情况下,这能禁用掉很多连接的状态跟踪,因为在并发高的时候,Nginx 和 Upstream 的连接也不是个小数目。

再比如针对流量很大的特定端口:

12iptables -t raw -A PREROUTING -p tcp -m tcp --dport 8080 -j NOTRACKiptables -t raw -A OUTPUT -p tcp -m tcp --sport 8080 -j NOTRACK

需要特别特别注意的是,被 NOTRACK 的包无法匹配上依赖特定状态的其他规则。比如 INPUT 链上假如有这么一条规则:

1iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 8080 -j ACCEPT

那么在增加了上面的 NOTRACK 规则后,你会发现这个端口的包都被丢掉了。因为没有了连接状态跟踪,那个 --state NEW不可能匹配得上。上午我就因为犯了这个错误导致某关键服务宕机了几分钟……


您需要登录后才可以回帖 登录 | 用户注册

本版积分规则

Archiver|手机版|小黑屋|ACE Developer ( 京ICP备06055248号 )

GMT+8, 2024-3-28 18:04 , Processed in 0.023081 second(s), 6 queries , Redis On.

Powered by Discuz! X3.5

© 2001-2023 Discuz! Team.

快速回复 返回顶部 返回列表