1 起因

線上伺服器nginx日誌執行一段時間後，會報如下錯誤：

1024 worker_connections are not enough

一般做法是修改worker_connections。
但實際上：該服務是用於時間比較短的連線裡，並且一天最多才4000個請求。不可能會耗盡worker_connections。
除非每次連線都沒有釋放對應的連線。
‘

shell>netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’
CLOSE_WAIT 802
ESTABLISHED 106
shell>lsof -n | grep “nginx對應的一個程序id”
MvLogServ 31125 mv 111u IPv4 76653578 0t0 TCP 10.1.138.60:8996->10.1.138.60:51977 (CLOSE_WAIT)
MvLogServ 31125 mv 112u IPv4 76659698 0t0 TCP 10.1.138.60:8996->10.1.138.60:52015 (CLOSE_WAIT)
MvLogServ 31125 mv 113u IPv4 76662836 0t0 TCP 10.1.138.60:8996->10.1.138.60:52042 (CLOSE_WAIT)
MvLogServ 31125 mv 114u IPv4 76663435 0t0 TCP 10.1.138.60:8996->10.1.138.60:52051 (CLOSE_WAIT)
MvLogServ 31125 mv 115u IPv4 76682134 0t0 TCP 10.1.138.60:8996->10.1.138.60:52136 (CLOSE_WAIT)
MvLogServ 31125 mv 116u IPv4 76685095 0t0 TCP 10.1.138.60:8996->10.1.138.60:52159 (CLOSE_WAIT)
……………….

TIME_WAIT：表示主動關閉，通過優化系統核心引數可容易解決。
CLOSE_WAIT：表示被動關閉，需要從程式本身出發。
ESTABLISHED：表示正在通訊
則可知：nginx：CLOSE_WAIT過多的狀態

2 解決

2.1 TIME_WAIT 通過優化系統核心引數可容易解決

TIME_WAIT大量產生很多通常都發生在實際應用環境中。
TIME_WAIT產生的原因：在通訊過程中A主動關閉造成的，
在A傳送了最後一個FIN包後，系統會等待 Double時間
的MSL(Max Segment Lifetime)【注：按不同的作業系統有不同時間】用於等待接受B傳送過來的FIN_ACK和FIN，
這段時間A的對應的socket的fd是不能夠重新利用的，
這樣在大量的短連線服務中，會出現TIME_WAIT過多的現象。

解決方案：
調整TIME_WAIT超時時間
vi /etc/sysctl.conf
#表示開啟SYN Cookies。
#當出現SYN等待佇列溢位時，啟用cookies來處理，可防範少量SYN攻擊，預設為0，表示關閉
net.ipv4.tcp_syncookies = 1
#表示開啟重用。
#允許將TIME-WAIT sockets重新用於新的TCP連線，預設為0，表示關閉
net.ipv4.tcp_tw_reuse = 1
#表示開啟TCP連線中TIME-WAIT sockets的快速回收，預設為0，表示關閉
net.ipv4.tcp_tw_recycle = 1
#表示如果套接字由本端要求關閉。
#這個引數決定了它保持在FIN-WAIT-2狀態的時間
#生效，如下命令
/sbin/sysctl -p

• 注：
  已經主動關閉連線了為啥還要保持資源一段時間呢？
  這個是TCP/IP的設計者規定的，主要出於以下兩個方面的考慮：
  

1. 防止上一次連線中的包，迷路後重新出現，影響新連線（經過2MSL，上一次連線中所有的重複包都會消失）
   即：允許老的重複分節在網路中消逝。
   
2. 可靠的關閉TCP連線。在主動關閉方傳送的最後一個 ack(fin) ，有可能丟失，這時被動方會重新發fin, 如果這時主動方處於 CLOSED 狀態 ，就會響應 rst 而不是 ack。所以主動方要處於 TIME_WAIT 狀態，而不能是 CLOSED 。
   另外這麼設計TIME_WAIT 會定時的回收資源，並不會佔用很大資源的，除非短時間內接受大量請求或者受到攻擊。
   即：可靠地實現TCP全雙工連線的終止。（確保最後的ACK能讓被關閉方接收）

2.2 CLOSE_WAIT 需要從程式本身出發

LOSE_WAIT產生的原因是客戶端B主動關閉，
伺服器A收到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;

3 總結

• TIME_WAIT狀態可以通過優化伺服器引數得到解決。
  因為發生TIME_WAIT的情況是伺服器自身可控的，
  要麼就是對方連線的異常，要麼就是自己沒有迅速回收資源，
  總之不是由於自己程式錯誤導致的。

• CLOSE_WAIT需要通過程式本身。
  如果一直保持在CLOSE_WAIT狀態，那麼只有一種情況，就是在對方關閉連線之後伺服器程式自己沒有進一步發出ack訊號。
  即在對方連線關閉之後，程式裡沒有檢測到，或者程式沒有關閉連線，於是這個資源就一直被程式佔著。
  伺服器對於程式搶佔的資源沒有主動回收的功能。只能修改程式本身。
  程式碼需要判斷socket，一旦讀到0，斷開連線，read返回負，
  檢查一下errno，如果不是AGAIN，就斷開連線。