運維的同學和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;