主题：【求助】关于网站大量 Error 001 应对 -- 铁手
由于Http的特点，会导致大量的连接建立后马上关闭。而默认情况下tcp连接的关闭是有段时间的，这会造成连接过多。
看看这几个参数：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
是否都设为1了。这会减少系统中time_wait状态的连接。
在下载电影时再进西西河频发Error 001.但进其他网站没多大问题.
把下载关掉就少很多Error 001。
以前用“树展”时也会出现。但没现在那样频繁.
老铁新年快乐！
送花成功。有效送花赞扬。感谢：作者获得通宝一枚。
参数变化，作者，声望:1；铢钱:16。你，乐善:1；铢钱:-1。本帖花:1
老铁按照这个做法做一下吧，看看是不是被攻击了，从最近河里的情况看，被攻击的可能性比较大。用一些聪明办法去过滤攻击者，不要单纯靠增加资源来硬撑。
运行了一下，只给出一个数字，而且数字不是很大。
如果用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 里面的每个客户端的链接数并排序，你那个命令该怎么改一下?
我在主题中说的有意无意，恶意非恶意，就是指的这种情况。网站也有很多搜索引擎在抓内容，应该说，这些都是正常的网站访问，无非是增加流量而已，系统应该是能够应付的。
我说的那种情况，从网上搜来的结果来看，可能和 syn flood 攻击有关，先敲一下门，但是就不回答“你是谁”。
西西河在安卓系统里运行不正常，比如用UC浏览器的时候。
1 很多按钮失效：比如，关联网址。
2 树展状态下，页面无法滑动，左右都无法滑动。
不知道这些是不是影响系统的运行。
用下面的工具对APACHE实时的IN/OUT的流量监控下
http://www.ex-parrot.com/~pdw/iftop/
发现某些异常部分按照季候所列举的方法进行系统优化，用IPTABLES 将不正常网段的流量过滤掉。
要找一个平衡点。
我的理解，ip_conntrack_tcp_timeout_established 值太大的话，会造成很多的TIME_WAIT而占用资源,即会话已结束但TCP连接还没有释放（因为还没有time out)。
用netstat -an |grep ESTABLISHED |wc -l 和netstat -an |grep WAIT |wc -l 以及其他状态SYN_SENT等比一下结果，看看到底是哪一种状态居多，如果主要是FIN_WAIT1或2和TIME_WAIT，那么看起来像是连接没有及时释放的问题。
另外，你有没有过去的网管数据? 看看是否是连接数突然增大的，如果是突然增大的那就很可能是被攻击了。
抱歉，手头没有机器，不然可以帮你写几个awk来分析netstat和/proc/net/ip_conntrack的内容。
分析ipcontrack的脚本如下：
下面是我测试结果。
tcp 6 115 TIME_WAIT src=10.242.230.109 dst=10.242.148.102 sport=59592 dport=10080 packets=17 bytes=1324 src=10.242.148.102 dst=10.242.230.109 sport=10080 dport=59592 packets=11 bytes=18112 [ASSURED] mark=0 secmark=0 use=1
tcp 6 83 TIME_WAIT src=10.242.230.109 dst=10.242.148.102 sport=49749 dport=10080 packets=6 bytes=775 src=10.242.148.102 dst=10.242.230.109 sport=10080 dport=49749 packets=5 bytes=512 [ASSURED] mark=0 secmark=0 use=1
tcp 6 105 TIME_WAIT src=10.242.230.111 dst=10.242.148.102 sport=48174 dport=10080 packets=5 bytes=762 src=10.242.148.102 dst=10.242.230.111 sport=10080 dport=48174 packets=4 bytes=1657 [ASSURED] mark=0 secmark=0 use=1
tcp 6 27 TIME_WAIT src=10.242.148.102 dst=10.242.148.140 sport=42357 dport=64148 packets=7 bytes=1156 src=10.242.148.140 dst=10.242.148.102 sport=64148 dport=42357 packets=7 bytes=5180 [ASSURED] mark=0 secmark=0 use=1
tcp 6 90 TIME_WAIT src=10.242.230.109 dst=10.242.148.102 sport=52014 dport=10080 packets=6 bytes=820 src=10.242.148.102 dst=10.242.230.109 sport=10080 dport=52014 packets=5 bytes=512 [ASSURED] mark=0 secmark=0 use=1
tcp 6 77 TIME_WAIT src=10.242.230.112 dst=10.242.148.102 sport=53700 dport=10080 packets=18 bytes=1407 src=10.242.148.102 dst=10.242.230.112 sport=10080 dport=53700 packets=11 bytes=19839 [ASSURED] mark=0 secmark=0 use=1
tcp 6 25 TIME_WAIT src=10.242.230.107 dst=10.242.148.102 sport=47959 dport=10080 packets=10 bytes=960 src=10.242.148.102 dst=10.242.230.107 sport=10080 dport=47959 packets=7 bytes=8566 [ASSURED] mark=0 secmark=0 use=1
tcp 6 20 TIME_WAIT src=10.242.230.112 dst=10.242.148.102 sport=36645 dport=10080 packets=18 bytes=1311 src=10.242.148.102 dst=10.242.230.112 sport=10080 dport=36645 packets=11 bytes=19508 [ASSURED] mark=0 secmark=0 use=1
tcp 6 113 TIME_WAIT src=10.242.230.108 dst=10.242.148.102 sport=60306 dport=10080 packets=12 bytes=1241 src=10.242.148.102 dst=10.242.230.108 sport=10080 dport=60306 packets=8 bytes=11344 [ASSURED] mark=0 secmark=0 use=1
tcp 6 96 TIME_WAIT src=10.242.148.102 dst=10.242.148.140 sport=42710 dport=64148 packets=7 bytes=1108 src=10.242.148.140 dst=10.242.148.102 sport=64148 dport=42710 packets=7 bytes=4676 [ASSURED] mark=0 secmark=0 use=1
[root@ud60216 ~]# head ipcontrack | awk '{print substr($5, index($5,"=")+1) }' | awk '{a[$1]+=1};END {for( i in a){print i,a[ i ] }}' | sort -n -k 2
10.242.230.107 1
10.242.230.108 1
10.242.230.111 1
10.242.148.102 2
10.242.230.112 2
10.242.230.109 3
另外，目前我们生产环境中net.ipv4.netfilter.ip_conntrack_tcp_timeout_established设置为43200.不过我们前端有防dds攻击的策略。
另外加一个链接状况分类统计的脚本。
netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"\t",state[key]}'
就是一群肉鸡站在门口，然后每只都能等5天才会被踢开。怪不得我们这些真正的用户进不来。
稍微改一下脚本就可以了。
我观察了一下自己的浏览器，有可能是因为网络传输速度慢导致的问题。在打开网站的时候如果我当时正在下BT，有可能就会有一两个连接始终没完成。浏览器的表现就是基本页面出来了，但是不断转圈。或者内容全部出来了，但是浏览器始终处于下载页面状态。这时我估计你那边就有一个长时间的连接(Established状态）。用户多了这种连接就可以挤爆你的连接数量。
我建议你查看一下这种空连接的数量占的百分比，并看看和PV、在线用户数量等关系，如果是正相关，那可能就是我说的情况。那看看有没有缩短空闲连接的方法（Linux我也不熟悉）
吐嘈一下家用的NAT路由器，由于这些小路由器通常有连接限制。开BT的时候经常就莫名其妙地随机地断开一些TCP连接，粗暴断开，连个RST都不发。我就吃过这些东西的亏。
这个配置决定是否让客户端在一个连接里发多个HTTP请求。默认应该是Keekalive（允许），可以改成Close（不允许）。
另外，默认timeout时间太长了，timeout_established可以设置为30秒-5分钟。其他的timeout你也看一下，大致在这个数值范围。重传次数也可以适当减少10次估计就差不多了。
不过这些调整最好一次只调整一个，观察一段时间后再做判断。