服務(wù)器中TIME_WAIT狀態(tài)過(guò)多時(shí)怎么排查

這篇文章主要介紹了服務(wù)器中TIME_WAIT狀態(tài)過(guò)多時(shí)怎么排查的相關(guān)知識(shí)，內(nèi)容詳細(xì)易懂，操作簡(jiǎn)單快捷，具有一定借鑒價(jià)值，相信大家閱讀完這篇服務(wù)器中TIME_WAIT狀態(tài)過(guò)多時(shí)怎么排查文章都會(huì)有所收獲，下面我們一起來(lái)看看吧。

一、概述

（一）現(xiàn)象

服務(wù)器有兩個(gè)現(xiàn)象，第一是tcp連接數(shù)不多，不超過(guò)10個(gè)，但是time_wait狀態(tài)的2000。第二個(gè)按照以往的性質(zhì)，在很少用戶訪問(wèn)的情況下，服務(wù)器的資源幾乎沒(méi)有使用，比如CPU，不超過(guò)5%?，F(xiàn)在沒(méi)有什么用戶的的情況下，CPU損耗堅(jiān)持在40%左右，夜間也不停歇。里面運(yùn)行著好幾個(gè)web項(xiàng)目，都用docker啟動(dòng)的容器分開(kāi)。

（二）相關(guān)知識(shí)

tcp連接有3次握手，斷開(kāi)有四次揮手。

三次握手中第一次，是主動(dòng)端發(fā)出SYN信號(hào)給正在listen的被動(dòng)端，然后自己變成了SYN-SENT狀態(tài)；第二次是被動(dòng)端發(fā)送ACK確認(rèn)收到信號(hào)和SYN信號(hào)；第三次是主動(dòng)端發(fā)出ACK信號(hào)確認(rèn)已經(jīng)收到了被動(dòng)端的SYN。然后雙雙進(jìn)入了enblished狀態(tài)，便是已經(jīng)連接成功。

四次揮手中的第一次就是主動(dòng)端斷開(kāi)，發(fā)送FIN信號(hào)，變成FIN-WAIT-1狀態(tài)；第二次是被動(dòng)方收到FIN信號(hào)，就變成CLOSE-WAIT狀態(tài)，然后趕緊發(fā)送ACK信號(hào)給主動(dòng)方確認(rèn)，這是時(shí)候主動(dòng)方變?yōu)镕IN-WAIT-2狀態(tài)；第三次還是被動(dòng)方等自己的應(yīng)用斷開(kāi)連接的時(shí)候，發(fā)送FIN信號(hào)給主動(dòng)方，被動(dòng)方的狀態(tài)變成LAST-ACK；第四次是主動(dòng)方收到被動(dòng)方的FIN信號(hào)，然后發(fā)送的ACK信號(hào)，瞬間自己變成TIME-WAIT狀態(tài)，然后等待回收。

就是說(shuō)，誰(shuí)有TIME-WAIT，誰(shuí)就是主動(dòng)方。這點(diǎn)可以排除用戶頻繁關(guān)閉網(wǎng)頁(yè)的可能。意思就是說(shuō)這都是服務(wù)器主動(dòng)請(qǐng)求斷開(kāi)連接的，而TIME-WAIT狀態(tài)的鏈接也沒(méi)有回收。

二、問(wèn)題推測(cè)

（一）網(wǎng)絡(luò)

網(wǎng)絡(luò)上面的就是網(wǎng)絡(luò)不好，或者被攻擊。

（二）應(yīng)用

中間件的參數(shù)不對(duì)，導(dǎo)致有中間件斷開(kāi)的連接，或者應(yīng)用程序錯(cuò)誤造成的主動(dòng)斷開(kāi)連接?；蛘咭彩菓?yīng)用方面導(dǎo)致消耗資源太多。

三、排查

這個(gè)服務(wù)器有三個(gè)項(xiàng)目，每個(gè)項(xiàng)目的架構(gòu)都是lanmp。問(wèn)題復(fù)雜在于服務(wù)器里面好幾個(gè)項(xiàng)目，每個(gè)項(xiàng)目用都一個(gè)反向代理。好的一點(diǎn)是后端是docker容器，分開(kāi)的。

（一）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

排名第一這個(gè)是我們本地IP，6601是api項(xiàng)目的監(jiān)聽(tīng)端口，從這里可以看出在所欲的TIME_WAIT狀態(tài)的TCP里面，API項(xiàng)目的后端是被請(qǐng)求最多的那個(gè)。估計(jì)反向代理服務(wù)器也被請(qǐng)求了很多。

3．下圖是連接本地API項(xiàng)目的主動(dòng)IP

命令：

netstat -ant|grep 10.25.20.251:6601

途中可以看出，請(qǐng)求連接API后端的全部都是nginx的IP，這也很容易理解，nginx反向代理是入口嘛。下面就看看到底是誰(shuí)對(duì)nginx發(fā)出請(qǐng)求。

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

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

對(duì)API的請(qǐng)求是600，對(duì)nginx的請(qǐng)求是300，說(shuō)明所有的TIME-WAIT，一部分是請(qǐng)求nginx的，一部分是nginx請(qǐng)求API的。

5．下圖是展示到底是對(duì)請(qǐng)求了API的web前端nginx

命令：netstat -ant|grep 192.168.42.32:443

原來(lái)是192.168.42.1這個(gè)IP的請(qǐng)求。其實(shí)192.168.42.1這個(gè)IP是docker的虛擬網(wǎng)卡的IP，作為全部容器的網(wǎng)關(guān)，也就是說(shuō)反正這就是這些容器發(fā)出的請(qǐng)求，但是不能確定是哪一個(gè)。

綜上所述，可以排除網(wǎng)絡(luò)問(wèn)題，中間件apache的參數(shù)沒(méi)有改，但是對(duì)web前端nginx的請(qǐng)求那么多，可以說(shuō)明問(wèn)題不是出現(xiàn)在apache的請(qǐng)求上面。那就往代碼錯(cuò)誤方面考慮。

（二）宿主機(jī)上的容器

1．應(yīng)用和網(wǎng)絡(luò)的關(guān)系

可能TIME-WAIT的問(wèn)題就是后端程序亂發(fā)請(qǐng)求，apache是主項(xiàng)目的后端容器，apache-api就是api的后端程序。webserver占用的CPU上升，剛好就說(shuō)明容器使用的系統(tǒng)資源就是由這種請(qǐng)求引起的。下面用tail看看api的access日志。

實(shí)時(shí)監(jiān)測(cè)，發(fā)現(xiàn)API一秒鐘被請(qǐng)求12次左右，根據(jù)業(yè)務(wù)性質(zhì)和docker的狀態(tài)顯示，可以斷定是主項(xiàng)目的循環(huán)請(qǐng)求造成的系統(tǒng)資源內(nèi)耗。而每次請(qǐng)求API項(xiàng)目就返回了access_token，API返回?cái)?shù)據(jù)之后就發(fā)出斷開(kāi)信號(hào)，邏輯和現(xiàn)象很符合，也可以斷定TIME_WAIT的狀態(tài)也是這請(qǐng)求引起。而TIME_WAIT不是不回收，而是回收了，但不斷的生成。

關(guān)于“服務(wù)器中TIME_WAIT狀態(tài)過(guò)多時(shí)怎么排查”這篇文章的內(nèi)容就介紹到這里，感謝各位的閱讀！相信大家對(duì)“服務(wù)器中TIME_WAIT狀態(tài)過(guò)多時(shí)怎么排查”知識(shí)都有一定的了解，大家如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。