根据之前的经验观察

电信光纤 ADSL 4mbps 大概在 500 个并发左右，8mbps 大概在 1200 个并发。并发总数量也是专线区别于家宽的重要指标，更大的并发，更多的连接数，也就能分享给更多的 IP 。今天看了看公司的 100mbps 移动专线在 243 个动态 ip 的情况下,跑出了 12083 个并发。

openwrt 下就是 cat /proc/net/nf_conntrack|wc -l,对应的就是每个的发起的连接

ipv4 2 udp 17 33 src=192.168.5.171 dst=112.12.178.38 sport=47818 dport=54976 packets=8 bytes=2816 [UNREPLIED] src=112.12.178.38 dst=xxx.xxx.xxx.xxx sport=54976 dport=47818 packets=0 bytes=0 mark=64 zone=0 use=2
ipv4 2 tcp 6 33 TIME_WAIT src=192.168.5.177 dst=120.233.36.97 sport=51805 dport=80 packets=11 bytes=876 src=120.233.36.97 dst=xxx.xxx.xxx.xxx sport=80 dport=51805 packets=10 bytes=7355 [ASSURED] mark=48 zone=0 use=2

如何理解并发数，应该是在发起第 1201 个并发时，电信局端就开始丢包，让第 1201 个连接无法建立。

所以之前有一迅雷高并发网页都打不开的情况。当然在 QOS 以后有所缓解，但是依然可能因为并发的问题出现各种网络异常。

在一些低并发的宽带，qos 失效的情况，iptables limit 仍然是一种非常好的缓和方式，它能保证指定端口正常使用，又能抑制其它非指定端口的发包数。

#a="`iptables -vnL FORWARD --line-numbers | grep "PMTU" | cut -c1-5` - 1";a=`expr $a`
#iptables -I FORWARD $a -s $i -j DROP
#iptables -I FORWARD $a -s $i -p udp -j REJECT --reject-with icmp-proto-unreachable
#iptables -I FORWARD $a -s $i -p tcp -j REJECT --reject-with icmp-proto-unreachable
#iptables -I FORWARD $a -s $i -p ICMP --icmp-type echo-request -m limit --limit 4/sec -j ACCEPT
#iptables -I FORWARD $a -s $i -m limit --limit 60/s --limit-burst 100 -j ACCEPT
#iptables -I FORWARD $a -s $i -p tcp -m multiport --dport 25,80,443,1863 -m limit --limit 60/s --limit-burst 100 -j ACCEPT;

其它的就是调整 /etc/sysctl.d tcp/udp timeout ，让并发数更快的消亡
net.netfilter.nf_conntrack_max=16384
net.netfilter.nf_conntrack_tcp_timeout_established=600
net.netfilter.nf_conntrack_udp_timeout=65
net.netfilter.nf_conntrack_udp_timeout_stream=120
net.netfilter.nf_conntrack_generic_timeout=600
net.netfilter.nf_conntrack_tcp_timeout_syn_sent=120
net.netfilter.nf_conntrack_tcp_timeout_syn_recv=60
net.netfilter.nf_conntrack_tcp_timeout_fin_wait=120
net.netfilter.nf_conntrack_tcp_timeout_time_wait=120
net.netfilter.nf_conntrack_tcp_timeout_close=10
net.netfilter.nf_conntrack_tcp_timeout_close_wait=60
net.netfilter.nf_conntrack_tcp_timeout_last_ack=30