勿信网传，解决CLOSE_WAIT、TIME_WAIT连接状态过多正确姿势

先来看下一台生产环境中的各种tcp状态的连接数：

netstat -n| awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
LAST_ACK 6
SYN_RECV 77
CLOSE_WAIT 5793
ESTABLISHED 8540
FIN_WAIT1 143
FIN_WAIT2 378
CLOSING 29
TIME_WAIT 22960

然后我们来分析下占比比较高的几种状态产生的原因和解决方法，先来回顾下tcp的3次握手和4次挥手的状态图：

• CLOSE_WAIT
  close_wait只会发生在客户端先关闭连接的时候，但已经收到客户端的fin包，但服务器还没有关闭的时候会产生这个状态，如果服务器产生大量的这种连接一般是程序问题导致的，如部分情况下不会执行socket的close方法，解决方法是查程序

• ESTABLISHED
  established是tcp连接完成到连接断开的正常状态，比如一个http下载文件花了100s，那可以99.9s都是这个状态，如何降低这个状态的连接数呢？通过提高业务处理速度，并在处理完成后及时断开。在我们的场景中这台服务器是个restful server，客户端只是间隔性的请求数据，而不是像浏览器那样打开网页时一下请求大量资源，可以通过禁用http的keep_alive或调低keep_alive等待时间可以有效的降低established连接数

• TIME_WAIT
  time_wait是一个需要特别注意的状态，他本身是一个正常的状态，只在主动断开那方出现，每次tcp主动断开都会有这个状态的，维持这个状态的时间是2个msl周期（2分钟），设计这个状态的目的是为了防止我发了ack包对方没有收到可以重发。那如何解决出现大量的time_wait连接呢？千万不要把tcp_tw_recycle改成1，这个我再后面介绍，正确的姿势应该是降低msl周期，也就是tcp_fin_timeout值，同时增加time_wait的队列（tcp_max_tw_buckets），防止满了。

为什么不能把tcp_tw_recycle改成1

这个是通过血的教训换来的，先说改成1的后果是会导致一个路由器后面用户有人能连你服务器有人telnet不通。
原因是tcp_tw_recycle改成1后会启用tcp的tcp_timestamps功能，这个功能简单说就是所有的通信包是时间戳递增的，如果收到了同一个IP下时间戳小的包那就说明是个老数据包，就会丢弃这个功能。
而一个路由器下每台电脑的时候不是完全一致的，有的电脑的时间戳会小，导致这些电脑发出的通信包被直接丢弃了

正确的tcp优化姿势

修改/etc/sysctl.conf 文件，内容如下：

net.nf_conntrack_max = 1000000
#发送keepalive的心跳
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.tcp_tw_reuse = 0
#不能改成1 否则NAT后面的客户端可能连接不上
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_fin_timeout = 30
#timewait队列最大数量
net.ipv4.tcp_max_tw_buckets = 262144
#建立连接握手过程的ack重发次数从5到3
net.ipv4.tcp_synack_retries = 3
#缓存syn请求数量 解决messsage日志中syn溢出日志
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_syncookies = 1
#linux收包缓存
net.core.rmem_default=262144
net.core.wmem_default=262144
net.core.rmem_max=4194304
net.core.wmem_max=4194304
net.core.somaxconn=1024
vm.overcommit_memory = 1
vm.max_map_count=262144

执行sysctl -p生效