一、概述

（一）現象

服務器有兩個現象，第一是tcp連接數不多，不超過10個，但是time_wait狀態的2000。第二個按照以往的性質，在很少用戶訪問的情況下，服務器的資源幾乎沒有使用，比如CPU，不超過5%。現在沒有什么用戶的的情況下，CPU損耗堅持在40%左右，夜間也不停歇。里面運行著好幾個web項目，都用docker啟動的容器分開。

（二）相關知識

tcp連接有3次握手，斷開有四次揮手。

三次握手中第一次，是主動端發出SYN信號給正在listen的被動端，然后自己變成了SYN-SENT狀態；第二次是被動端發送ACK確認收到信號和SYN信號；第三次是主動端發出ACK信號確認已經收到了被動端的SYN。然后雙雙進入了enblished狀態，便是已經連接成功。

四次揮手中的第一次就是主動端斷開，發送FIN信號，變成FIN-WAIT-1狀態；第二次是被動方收到FIN信號，就變成CLOSE-WAIT狀態，然后趕緊發送ACK信號給主動方確認，這是時候主動方變為FIN-WAIT-2狀態；第三次還是被動方等自己的應用斷開連接的時候，發送FIN信號給主動方，被動方的狀態變成LAST-ACK；第四次是主動方收到被動方的FIN信號，然后發送的ACK信號，瞬間自己變成TIME-WAIT狀態，然后等待回收。

就是說，誰有TIME-WAIT，誰就是主動方。這點可以排除用戶頻繁關閉網頁的可能。意思就是說這都是服務器主動請求斷開連接的，而TIME-WAIT狀態的鏈接也沒有回收。

二、問題推測

（一）網絡

網絡上面的就是網絡不好，或者被攻擊。

（二）應用

中間件的參數不對，導致有中間件斷開的連接，或者應用程序錯誤造成的主動斷開連接。或者也是應用方面導致消耗資源太多。

三、排查

這個服務器有三個項目，每個項目的架構都是lanmp。問題復雜在于服務器里面好幾個項目，每個項目用都一個反向代理。好的一點是后端是docker容器，分開的。

（一）TCP連接上的IP

1．下圖是容器的IP

命令：

for i in $(docker ps|awk 'NR!=1 {print $NF}');do echo -e $i "\c";docker inspect --format '{{ .NetworkSettings.IPAddress }}' $i;done

2．下圖是連接中本地的IP

命令：

netstat -tn|grep TIME_WAIT|awk '{print $4}'|sort|uniq -c|sort -nr|head

排名第一這個是我們本地IP，6601是api項目的監聽端口，從這里可以看出在所欲的TIME_WAIT狀態的TCP里面，API項目的后端是被請求最多的那個。估計反向代理服務器也被請求了很多。

3．下圖是連接本地API項目的主動IP

命令：

netstat -ant|grep 10.25.20.251:6601

途中可以看出，請求連接API后端的全部都是nginx的IP，這也很容易理解，nginx反向代理是入口嘛。下面就看看到底是誰對nginx發出請求。

4．下圖是連接中外地的IP

命令：netstat -tn|awk '{print $5}'|sort|uniq -c|sort -nr|head

對API的請求是600，對nginx的請求是300，說明所有的TIME-WAIT，一部分是請求nginx的，一部分是nginx請求API的。

5．下圖是展示到底是對請求了API的web前端nginx

命令：netstat -ant|grep 192.168.42.32:443

原來是192.168.42.1這個IP的請求。其實192.168.42.1這個IP是docker的虛擬網卡的IP，作為全部容器的網關，也就是說反正這就是這些容器發出的請求，但是不能確定是哪一個。

綜上所述，可以排除網絡問題，中間件apache的參數沒有改，但是對web前端nginx的請求那么多，可以說明問題不是出現在apache的請求上面。那就往代碼錯誤方面考慮。

（二）宿主機上的容器

1．應用和網絡的關系

可能TIME-WAIT的問題就是后端程序亂發請求，apache是主項目的后端容器，apache-api就是api的后端程序。webserver占用的CPU上升，剛好就說明容器使用的系統資源就是由這種請求引起的。下面用tail看看api的access日志。

實時監測，發現API一秒鐘被請求12次左右，根據業務性質和docker的狀態顯示，可以斷定是主項目的循環請求造成的系統資源內耗。而每次請求API項目就返回了access_token，API返回數據之后就發出斷開信號，邏輯和現象很符合，也可以斷定TIME_WAIT的狀態也是這請求引起。而TIME_WAIT不是不回收，而是回收了，但不斷的生成。