為什麽會產生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系統自身參數設置過小：
調整如下參數：

所有用戶一共可以打開的文件數：
[root@zabbix-server13:35:11~]#sysctl -a|grep file-max
fs.file-max = 44348

單用戶可打開的文件數：
[root@zabbix-server13:35:11~]#sysctl -a|grep file-max
fs.file-max = 44348

web服務器自身是否開放進程數過小：
可以調整最大並發訪問值等參數

linux系統端口範圍：
[root@zabbix-server13: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的數量然後在排查問題所在！
 

TCP連接TIME-WAIT解決方案