問題根源：

為什麼會產生time-wait？

當客戶端與伺服器之間進行四次斷開時,當客戶端接收
到伺服器端傳送過來的斷開確認報文後,會發送最後一次
ACK報文,傳送之後客戶端會進入time-wait狀態,這個過
成會持續一分鐘,用來完成接收剩餘所有從伺服器端傳送
過來的資料[由於網路延遲等原因導致資料延遲達到],
同時也可以確自己傳送的最後一個ACK斷開確認報文能被
伺服器端收到！

time-wait狀態的危害：

1 time-wait狀態會佔據一定量的記憶體資源,雖然很少但
是如果這種連線在一個繁忙的伺服器中過於多的話,會額外消耗記憶體資源

2 time-wait狀態會佔據檔案描述符,因為要通過網路和
web程式通訊,需要監聽套接字檔案,這樣不僅會佔用端
口還會佔用檔案描述符,在高併發短連線的場景中,額外
致命,往往一個連線請求一個資源需要幾秒中,但是time
-wait連線卻要等待1分鐘,這往往會迅速消耗埠和描述符資源
當達到設定的閥值時,新的TCP連線的建立將會受到影響

如何檢測這種狀態：

方法1：
netstat -tnl | awk '/^tcp/{print $6}' | uniq -c
可以設定週期性任務計劃將這類資料追加至一個檔案中
進行檢視！

方法2：
使用zabbix自定義key time-wait connection
在agent端使用UserParameter= 來建立一個收集這個值
的命令定期傳遞給伺服器端,在伺服器端設定觸發器來
監控這個值的正常範圍

解決方案思路：

1 linux系統自身引數設定過小：
調整如下引數：

所有使用者一共可以開啟的檔案數：
[
 
[email protected]:35:11~]#sysctl -a|grep file-max
fs.file-max = 44348

單使用者可開啟的檔案數：
[[email protected]:35:11~]#sysctl -a|grep file-max
fs.file-max = 44348

web伺服器自身是否開放程序數過小：
可以調整最大併發訪問值等引數

linux系統埠範圍：
[[email protected]:44:32~]#sysctl -a | grep ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768    60999
可以選擇開放1024埠之上的所有埠！
1024 ~ 65535

2 如果是因為軟體開發原因導致可暫時設定如下引數：

net.ipv4.tcp_tw_recycle = 1 
表示開啟TCP連線中TIME-WAIT sockets的快速回收，預設為0，表示關閉

net.ipv4.tcp_tw_reuse = 1 
表示開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連線，預設為0，表示關閉；

net.ipv4.tcp_fin_timeout = 60
縮短系統設定的time-wait時間

net.ipv4.tcp_syncookies = 1
表示開啟SYN Cookies。當出現SYN等待佇列溢位時，啟用cookies來處理，可防範少量SYN***，預設為0，表示關閉；

先有效控制time-wait的數量然後在排查問題所在！