（一）現象
伺服器有兩個現象，第一是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 ');do echo -e $i "\c";docker inspect --format '}' $i;done
2．下圖是連線中本地的ip
命令：netstat -tn|grep time_wait|awk ''|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 ''|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不是不**，而是**了，但不斷的生成。
tcp連線中TIME WAIT狀態過多
參考自 作用 1.保證雙方正常種植資料流傳輸 最後乙個 ack丟失了，被動關閉一方會重發它的 fin，主動關閉一方必須維持乙個有效狀態資訊 timewait狀態下維持 以便能夠重發 ack，否則被動一方會認為有錯誤產生 2.保證 在下乙個人使用的ip位址與埠與先前的完全相同的情況下，上乙個殘留的資料...
處理 TIME WAIT 過多
netstat n awk tcp end last ack 14 syn recv 348 established 32 fin wait1 239 fin wait2 30 closing 31 time wait 1643 狀態描述 closed 無連線是活動的或正在進行 listen 伺服器...
TIME WAIT過多的問題
netstat ant awk tcp end last ack 14 syn recv 348 established 70 fin wait1 229 fin wait2 30 closing 33 time wait 18122 命令解釋 closed 無連線是活動的或正在進行 listen ...