[Nginx笔记]关于线上环境CLOSE_WAIT和TIME_WAIT过高

运维的同学和Team里面的一个同学分别遇到过Nginx在线上环境使用中会遇到TIME_WAIT过高或者CLOSE_WAIT过高的状态

先从原因分析一下为什么，问题就迎刃而解了。

首先是TIME_WAIT：

　　理解一下TIME_WAIT状态产生的原因，这个问题已经被很多很多的书说烂了，但是为什么很多人还是不能解决，究其原因还是因为

大多数都是学术派，并没有真正的遇到过这样的问题，因为TIME_WAIT大量产生很多都发生在实际应用环境中。

TIME_WAIT产生的原因还是因为在通讯过程中服务端主动关闭造成的，在服务端发送了最后一个FIN包后，系统会等待 Double时间

的MSL(Max Segment Lifetime)用于等待接受客户端发送过来的FIN_ACK和FIN，这段时间服务端的对应的socket的fd是不能够重新

利用的，这样在大量的短连接服务中，会出现TIME_WAIT过多的现象。

解决方案：

　　调整TIME_WAIT超时时间

　　

vi /etc/sysctl.conf

　　

net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；

net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

net.ipv4.tcp_fin_timeout = 20

其次是CLOSE_WAIT：

　　CLOSE_WAIT产生的原因是客户端主动关闭，收到FIN包，应用层却没有做出关闭操作引起的。

CLOSE_WAIT在Nginx上面的产生原因还是因为Nagle's算法加Nginx本身EPOLL的ET触发模式导致。

ET出发模式在数据就绪的时候会触发一次回调操作，Nagle's算法会累积TCP包，如果最后的数据包和

FIN包被Nagle's算法合并，会导致EPOLL的ET模式只出发一次，然而在应用层的SOCKET是读取返回

0才代表链接关闭，而读取这次合并的数据包时是不返回0的，然后SOCKET以后都不会触发事件，所以

导致应用层没有关闭SOCKET，从而产生大量的CLOSE_WAIT状态链接。

　　关闭TCP_NODELAY，在Nginx配置中加上

　　tcp_nodelay        on;