主题：【求助】关于网站大量 Error 001 应对 -- 铁手
家园 【求助】关于网站大量 Error 001 应对 先祝大家新年快乐，在新的一年，即将到来的龙年龙腾虎跃。
关于网站近期大量出现 Error 001，经过一段时间的分析调查，并做了一些必要的调整，基本恢复稳定。这里做个简单说明，并请熟悉linux服务器管理的河友帮忙参考一下。必要时，请短信给我。
Error 001 是我自己定义的错误代码。和网络链接是否通畅有关。在系统信息提示中有：ip_conntrack: table full, dropping packet.
以下命令给出以下结果：
wc -l /proc/net/ip_conntrack
96187 /proc/net/ip_conntrack
在网站大量出现 Error 001 时，这个值超过了系统预设上限。在系统资源允许的情况下大幅提高上限，基本上缓解了问题之后，这个数值眼下还在不断的上升。
我的基本判断是：
有人有意无意、恶意非恶意的造成对西西河网站的大量链接，导致系统网络相关资源耗尽。我倾向于是一种恶意行为。因为这种行为已经持续了相当一段时间，并有愈演愈烈的趋势，而以前的系统配置在相当长一段时间内一点问题都没有。
为了有效阻止这种行为对网站造成进一步的影响，请熟悉 linux 服务器管理的河友帮忙。虽然我已经尽自己最大能力分析问题所在，并做了必要的系统调整，但还是请各位在给参考意见的时候，尽可能把我当做什么都不懂，这样我们可以从尽可能多角度，尽可能大的覆盖面去分析症结所在，并作出尽可能优化的配置。
比如，
可以帮我想一下查看什么参数，系统统计，怎么分析和判断问题出在哪里，是表面现象还是问题的根子。
也可以帮我想一下，做什么样的系统配置去最大限度的避免问题出现。
总之，思路越宽越好。
多谢各位。
通宝推：无心之云,行在所,笑熬浆糊未糊,雨的节奏,家园 不知道用没用过这个 https://addons.mozilla.org/zh-CN/firefox/addon/servstats/
ServStats lets you share statistics about web server connectivity and diagnose network failures. When a network failure occurs, ServStats automatically conducts diagnostic tests and infers the most likely cause of failure
家园 ip_conntrack 原理如下，采取何种措施，看具体情况。下面的“【整理】中文网站里面很多内容值得参考。”回帖也说的很详细了。
Adrian Otto
28.07.09 at 10:19
Some readers may be interested to know what ip_conntrack is in the first place, and why it fills up. If you run an iptables firewall, and have rules that act upon the state of a packet, then the kernel uses ip_conntrack to keep track of what state what connections are in so that the firewall rule logic can be applied against them. If you have a system that's getting a lot of network activity (high rates of connections, lots of concurrent connections, etc) then the table will accumulate entries.
The entries remain until an RST packet is sent from the original IP address. If you have a flaky network somewhere between you, and the clients accessing your server, it can cause the RST packets to be dropped due to the packet loss, and leave orphaned entries in your ip_conntrack table. This can also happen if you have a malfunctioning switch or NIC card... not necessarily a routing problem out on the internet somewhere.
Typically when I've seen this trouble crop up is when a server is the target of a DDoS attack. Filling up the ip_conntrack table is a relatively easy way to knock a server off line, and attackers know this.
As Major suggested, you can get short term relief by increasing the size of the table. However, these entries are held in memory by the kernel. The bigger you make the table, the more memory it will consume. That memory could be used by your server to serve requests if you really don't need the stateful firewall capability. Don't waste resources on this feature if you really don't need it.
Another option to consider is turning OFF iptables rules that use ip_conntrack so the state able is not used at all. Anything with "-m state" or "-t nat" can be turned off. If you want to just flush all your iptables rules you can do an "iptables -P" to set a default allow policy and "iptables -F" to flush all the rules. On an RHEL or CentOS system you can just do "service iptables stop".
Once iptables is no longer using ip_conntrack, you can reclaim the memory the table was using by unloading the related kernel modules.
rmmod ipt_MASQUERADE
rmmod iptable_nat
rmmod ipt_state
rmmod ip_conntrack
Then you will have an empty ip_conntrack that will stay empty. I mention this because a lot of sysadmins have hordes of iptables rules installed as a matter of course, and don't recognize the downside of having them present. You can still use iptables, but to avoid the use of ip_conntrack simply don't use rules based on stateful logic.
man iptables 查看 --ctstate 内容，如果防火墙没有依赖这些东西，可以把内核关于 ip_conntrack 的模块黑名单了。
家园 简单 用下面的工具对APACHE实时的IN/OUT的流量监控下
http://www.ex-parrot.com/~pdw/iftop/
发现某些异常部分按照季候所列举的方法进行系统优化，用IPTABLES 将不正常网段的流量过滤掉。
家园 说点题外话 西西河在安卓系统里运行不正常，比如用UC浏览器的时候。
1 很多按钮失效：比如，关联网址。
2 树展状态下，页面无法滑动，左右都无法滑动。
不知道这些是不是影响系统的运行。
家园 老铁新年快乐！ 老铁新年快乐！
家园 给个情况老大参考下 在下载电影时再进西西河频发Error 001.但进其他网站没多大问题.
把下载关掉就少很多Error 001。
以前用“树展”时也会出现。但没现在那样频繁.
家园 近几天还好。 家园 看一下tcp连接的状态 由于Http的特点，会导致大量的连接建立后马上关闭。而默认情况下tcp连接的关闭是有段时间的，这会造成连接过多。
看看这几个参数：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
是否都设为1了。这会减少系统中time_wait状态的连接。
家园 查了一下，第一个是1，其余两个是0 网上查了一下，似乎net.ipv4.tcp_tw_recycle=1这个比较容易导致问题，建议使用net.ipv4.tcp_tw_recycle = 1。我试试这个看看。
不过我估计还是没用，因为问题似乎不在 netstat 里面的内容，而是和 ip_conntract 相关，这两个似乎不一样。我的理解，后者是和防火墙有关系的，前者只是一般意义上的链接状态。
家园 你统计一下tcp连接中time_wait的比例 如果比例比较大，超过30%的话，设这个参数就是有用的。
每个tcp连接都会占用iptable的entry，所以连接数是第一重要的，要先解决连接数问题。然后可能是iptable的entry超时时间的控制。默认的conntrak超时时间比较长。不过这个要看你的iptables具体使用环境而定。
家园 呵呵，看在腊八节红包的分上说几句。 老铁有没有统计过每链接pv数，就是pv／链接数，用现在的和以前没出问题时候的值比较一下。如果差别不大，那么恭喜老铁，你该加服务器了，的确流量上去了。
首先请老铁提供一下其他信息，例如是不是真的有长链接的应用例如聊天室出现链接泄露了，这些链接是不是都在80端口。
其次得判断是不是收到ddos攻击了，分ip统计链接数。
netstat -an | grep ESTABLISHED | awk '{print substr($5,1,index($5,":")-1)}' | awk '{a[$1]+=1};END {for(
i in a){print i,a[ i ] }}' | sort -n -k 2
执行上面这个命令，会统计出每个客户端ip的链接数并排序。
如果发现有的ip和服务器的链接数异常高，这些ip数量不多，但是链接数比平均每个ip的链接数多很多，并且累加起来链接数很高，那最简单，是最简单的攻击手段。攻击方用不多的服务器攻击你，这种情况处理起来最简单。不管的是apache还是nginx，加一个ip过滤模块就行了，限制单个ip的链接数就行了。
如果没出现这种情况，那么需要分析一下apache／nginx的日志，看看是不是有的链接持续时间比较长，但是一直没什么数据。这个分析和日志格式有关，我就没法贴脚本了。
如果出现大量没数据的链接，说明被攻击了，呵呵。另外就算不出现这种情况也有可能是受攻击了，攻击方控制了一大批肉鸡，一起访问西西河。这种访问和正常的访问区别不大，相当于压力测试的压力过大，要解决起来有个绝招，一般人我不告诉他。
先买个关子，如果确认是受到了ddos攻击，我再提供解决方案。
家园 多谢。不过这个好像不是很灵，帮忙再想想。 运行了一下，只给出一个数字，而且数字不是很大。
如果用FIN_WAIT1, TIME_WAIT数字还大很多。
这里面的链接似乎没有问题，是正常的网站访问。
主要的问题，我觉得是出在非正常的访问，主要体现在 /proc/net/ip_conntrack 里面有大量的 ESTABLISHED 记录，是不是有人链接了，但是又不断掉，而系统设置里的
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = XXXX
这个值通常又很大。顺便问一下，你觉得这个值，作为主要是web服务器而言，放多大值比较合适？系统缺省好像是5天，30分钟可以么？
从网上查到的看法，这里的表现有点类似 SYN flood 攻击。
如果要分析 ip_conntrack 里面的每个客户端的链接数并排序，你那个命令该怎么改一下?
家园 既然老哥您基本确认了是ip_conntrack的问题。。 前几天看您的帖子没敢回，因为有几个疑问得不到确认：
首先是您server的配置和网络拓扑，防火墙怎么配置的，是不是有反向代理，多域名又是怎么配置的，由此引发的问题点可能各不相同
既然老哥您基本确认了ip_conntrack是罪魁祸首，小羊经验主义一把，应该是您的防火墙在POSTROUTING 和PREROUTING链当中有NAT的操作，SNAT或者DNAT或者REDIRECT这个就不敢确认了，这些都会在ip_conntrack当中添加记录，DNAT多见于防火墙转发包给DMZ中的server，REDIRECT多见于反向代理，因为不了解您的网络拓扑结构，所以还得您自己检查（拓扑图、防火墙配置啥的您千万别往河里贴，这事儿挺敏感的，最近网络安全这块儿事儿蛮多的）。
不管怎么样，ip_conntrack记录保存5天是个默认值，因为NAT得记着每条链接，这样才能进行解包和构包，如果您的防火墙是单独的网关，和web server是分开的，而且有别的任务要做，那么不建议修改，有可能影响正常网络通讯。如果防火墙只为web服务，那么改小点无伤大雅。不过改小了老实说未必有用，ip_conntrack日志里面的记录有UNREPLIED的，也有ASSURED的，前者是没连上的，后面是链接确认的，如果日志满，前者会被正常删除，而后者宁可丢包都不会动，操蛋的是，这个5天的时间还会自己更新，在记录没满的情况下，UNREPLIED的链接在4.9天连上了，都再从头计数（这个记不太清楚了，好象是，建议老哥再查查文档）
把MAX改大是个路数，不过也有到头的一天，还得考虑内存，这玩意太大了，会很消耗内存。
按照主贴的说法，出问题前后没有过变化，那么外部因素的原因会多一点：
1、恶意或者非恶意的异常，首先您局域网当中有没有机器在把您广播成了网关，病毒或者网卡坏了都有着可能，看看路由表，如果不相干的IP后面跟的MAC地址是西河server的，那就基本确认，最好能要求机房管理人员更改一下VLAN设置，单独把您分出来，这种情况比较罕见，机房管理人员愚蠢的VLAN规划和网络异常包同时出现才行，不过还是建议考虑一下。
2、爬虫，而且是专门下河的爬虫，这玩意儿和人不一样，它每天来转悠转悠，他的那条记录就永远不会被删除，再是个并发的爬虫，直接就把记录撑满了，这个查起来倒是不难，看看日志里面user_agent是不是有非常见浏览器的，撵出去就是，如果查不到，那么有可能是做了伪装，这倒是自定义爬虫常见的伎俩，碰见这一号的，编程查日志啥的都不用，直接就挂上google的分析工具，看看报告里面排名靠前的ip是那几个，然后对照网站的用户登录记录，爬虫的特征很明显，会遍历超链，如果能基本确认不是人的，杀无赦。
3、GFW作祟，这条河现在有了支流，ccthere被墙，根据河里有位高人的的分析，恰恰时政类是国内的哥们关注的内容，虽然一准会被旁路的GFW劫持发过来RST，这样的话虽然tcp/ip不管他了，可是日志里头这条记录算是存下了，或者翻墙，那就更简单，无论怎么翻，都是慢速链接，这也挺操蛋的，半死不活。。。小羊解析了一下，俩域名地址不同，如果不是一台服务器，那么按说不会牵连到cchere，不过如果这俩IP在一台机器上。。。再弄台服务器也不便宜，要不咱干脆扔云上去？就我个人而言，反正死亚马逊不死西西河就行。
家园 试试改Web服务器的Connection配置 这个配置决定是否让客户端在一个连接里发多个HTTP请求。默认应该是Keekalive（允许），可以改成Close（不允许）。
另外，默认timeout时间太长了，timeout_established可以设置为30秒-5分钟。其他的timeout你也看一下，大致在这个数值范围。重传次数也可以适当减少10次估计就差不多了。
不过这些调整最好一次只调整一个，观察一段时间后再做判断。