close wait是什么
close wait的意思到底是什么?下面是學(xué)習(xí)啦小編給大家整理的close wait是什么，供大家參閱!
close wait是什么
等待結(jié)束
淺談CLOSE WAIT
TCP 有很多連接狀態(tài)，每一個(gè)都?jí)蛄氖畨K錢兒的，比如我們以前討論過(guò)TIME_WAIT 和FIN_WAIT1，最近時(shí)不時(shí)聽(tīng)人提起 CLOSE_WAIT，感覺(jué)有必要梳理一下。
所謂 CLOSE_WAIT，借用某位大牛的話來(lái)說(shuō)應(yīng)該倒過(guò)來(lái)叫做 WAIT_CLOSE，也就是說(shuō)「等待關(guān)閉」，如果你還不理解其含義，可以看看 TCP 關(guān)閉連接時(shí)的圖例：
TCP Close
不要被圖中的 client 和 server 所迷惑，你只要記住：主動(dòng)關(guān)閉的一方發(fā)出 FIN 包，被動(dòng)關(guān)閉的一方響應(yīng) ACK 包，此時(shí)，被動(dòng)關(guān)閉的一方就進(jìn)入了 CLOSE_WAIT 狀態(tài)。如果一切正常，稍后被動(dòng)關(guān)閉的一方也會(huì)發(fā)出 FIN 包，然后遷移到 LAST_ACK 狀態(tài)。
通常，CLOSE_WAIT 狀態(tài)在服務(wù)器停留時(shí)間很短，如果你發(fā)現(xiàn)大量的 CLOSE_WAIT 狀態(tài)，那么就意味著被動(dòng)關(guān)閉的一方?jīng)]有及時(shí)發(fā)出 FIN 包，一般有如下幾種可能：
程序問(wèn)題：代碼層面遺漏或者死循環(huán)之類的，沒(méi)有 close 相應(yīng)的 socket 連接。
響應(yīng)太慢：對(duì)方已經(jīng) timeout 了，本方還忙于耗時(shí)邏輯，導(dǎo)致 close 被延后。
BACKLOG 太大：隊(duì)列堆積嚴(yán)重，導(dǎo)致多余的請(qǐng)求來(lái)不及消費(fèi)就被關(guān)閉了。
如果遭遇了 CLOSE_WAIT 故障，那么需要立刻通過(guò)「netstat」或者「ss」命令來(lái)判斷 CLOSE_WAIT 連接是哪些進(jìn)程引起的，如果是我們自己寫的一些程序，比如用 HttpClient 自定義的蜘蛛，那么八九不離十是忘記了 close 相應(yīng)的 socket，如果是一些使用廣泛的程序，比如 Tomcat 之類的，那么不太可能是它們自身的 BUG，更可能是響應(yīng)速度太慢或者 BACKLOG 設(shè)置過(guò)大導(dǎo)致的故障。
此外還有一點(diǎn)需要說(shuō)明：按照前面圖例所示，當(dāng)被動(dòng)關(guān)閉的一方處于 CLOSE_WAIT 狀態(tài)時(shí)，主動(dòng)關(guān)閉的一方處于 FIN_WAIT2 狀態(tài)。 那么為什么我們總聽(tīng)說(shuō) CLOSE_WAIT 狀態(tài)過(guò)多的故障，但是卻相對(duì)少聽(tīng)說(shuō) FIN_WAIT2 狀態(tài)過(guò)多的故障呢?這是因?yàn)?Linux 有一個(gè)「tcp_fin_timeout」設(shè)置，控制了 FIN_WAIT2 的最大生命周期。壞消息是 CLOSE_WAIT 沒(méi)有類似的設(shè)置，如果不重啟進(jìn)程，那么 CLOSE_WAIT 狀態(tài)很可能會(huì)永遠(yuǎn)持續(xù)下去;好消息是如果連接開(kāi)啟了 keepalive機(jī)制，那么可以通過(guò)對(duì)應(yīng)的設(shè)置來(lái)清理無(wú)效連接，不過(guò) keepalive 是治標(biāo)不治本的方法，還是應(yīng)該對(duì)照前面的解釋找到問(wèn)題的癥結(jié)才對(duì)。
本來(lái)想多寫點(diǎn)的，但是著急下班回家，就寫到這吧，結(jié)尾推薦兩個(gè)案例：
PHP升級(jí)導(dǎo)致系統(tǒng)負(fù)載過(guò)高問(wèn)題分析
又見(jiàn)CLOSE_WAIT
CLOSE WAIT狀態(tài)的生成原因
首先我們知道，如果我們的Client程序處于CLOSE_WAIT狀態(tài)的話，說(shuō)明套接字是被動(dòng)關(guān)閉的!
因?yàn)槿绻荢erver端主動(dòng)斷掉當(dāng)前連接的話，那么雙方關(guān)閉這個(gè)TCP連接共需要四個(gè)packet：
Server ---> FIN ---> Client
Server <--- ACK <--- Client
這時(shí)候Server端處于FIN_WAIT_2狀態(tài);而我們的程序處于CLOSE_WAIT狀態(tài)。
Server <--- FIN <--- Client
這時(shí)Client發(fā)送FIN給Server，Client就置為L(zhǎng)AST_ACK狀態(tài)。
Server ---> ACK ---> Client
Server回應(yīng)了ACK，那么Client的套接字才會(huì)真正置為CLOSED狀態(tài)。
我們的程序處于CLOSE_WAIT狀態(tài)，而不是LAST_ACK狀態(tài)，說(shuō)明還沒(méi)有發(fā)FIN給Server，那么可能是在關(guān)閉連接之前還有許多數(shù)據(jù)要發(fā)送或者其他事要做，導(dǎo)致沒(méi)有發(fā)這個(gè)FIN packet。
原因知道了，那么為什么不發(fā)FIN包呢，難道會(huì)在關(guān)閉己方連接前有那么多事情要做嗎?
elssann舉例說(shuō)，當(dāng)對(duì)方調(diào)用closesocket的時(shí)候，我的程序正在調(diào)用recv中，這時(shí)候有可能對(duì)方發(fā)送的FIN包我沒(méi)有收到，而是由TCP代回了一個(gè)ACK包，所以我這邊套接字進(jìn)入CLOSE_WAIT狀態(tài)。
所以他建議在這里判斷recv函數(shù)的返回值是否已出錯(cuò)，是的話就主動(dòng)closesocket，這樣防止沒(méi)有接收到FIN包。
因?yàn)榍懊嫖覀円呀?jīng)設(shè)置了recv超時(shí)時(shí)間為30秒，那么如果真的是超時(shí)了，這里收到的錯(cuò)誤應(yīng)該是WSAETIMEDOUT，這種情況下也可以主動(dòng)關(guān)閉連接的。
還有一個(gè)問(wèn)題，為什么有數(shù)千個(gè)連接都處于這個(gè)狀態(tài)呢?難道那段時(shí)間內(nèi)，服務(wù)器端總是主動(dòng)拆除我們的連接嗎?
不管怎么樣，我們必須防止類似情況再度發(fā)生!
首先，我們要保證原來(lái)的端口可以被重用，這可以通過(guò)設(shè)置SO_REUSEADDR套接字選項(xiàng)做到：
重用本地地址和端口
以前我總是一個(gè)端口不行，就換一個(gè)新的使用，所以導(dǎo)致讓數(shù)千個(gè)端口進(jìn)入CLOSE_WAIT狀態(tài)。如果下次還發(fā)生這種尷尬狀況，我希望加一個(gè)限定，只是當(dāng)前這個(gè)端口處于CLOSE_WAIT狀態(tài)!
在調(diào)用
sockConnected = socket(AF_INET, SOCK_STREAM, 0);
之后，我們要設(shè)置該套接字的選項(xiàng)來(lái)重用：
/// 允許重用本地地址和端口:
/// 這樣的好處是，即使socket斷了，調(diào)用前面的socket函數(shù)也不會(huì)占用另一個(gè)，而是始終就是一個(gè)端口
/// 這樣防止socket始終連接不上，那么按照原來(lái)的做法，會(huì)不斷地?fù)Q端口。
int nREUSEADDR = 1;
setsockopt(sockConnected,
SOL_SOCKET,
SO_REUSEADDR,
(const char*)&nREUSEADDR,
sizeof(int));
教科書上是這么說(shuō)的：這樣，假如服務(wù)器關(guān)閉或者退出，造成本地地址和端口都處于TIME_WAIT狀態(tài)，那么SO_REUSEADDR就顯得非常有用。
也許我們無(wú)法避免被凍結(jié)在CLOSE_WAIT狀態(tài)永遠(yuǎn)不出現(xiàn)，但起碼可以保證不會(huì)占用新的端口。
其次，我們要設(shè)置SO_LINGER套接字選項(xiàng)：
從容關(guān)閉還是強(qiáng)行關(guān)閉?
LINGER是“拖延”的意思。
默認(rèn)情況下(Win2k)，SO_DONTLINGER套接字選項(xiàng)的是1;SO_LINGER選項(xiàng)是，linger為{l_onoff：0，l_linger：0}。
如果在發(fā)送數(shù)據(jù)的過(guò)程中(send()沒(méi)有完成，還有數(shù)據(jù)沒(méi)發(fā)送)而調(diào)用了closesocket()，以前我們一般采取的措施是“從容關(guān)閉”：
因?yàn)樵谕顺龇?wù)或者每次重新建立socket之前，我都會(huì)先調(diào)用
/// 先將雙向的通訊關(guān)閉
shutdown(sockConnected, SD_BOTH);
/// 安全起見(jiàn)，每次建立Socket連接前，先把這個(gè)舊連接關(guān)閉
closesocket(sockConnected);
我們這次要這么做：
設(shè)置SO_LINGER為零(亦即linger結(jié)構(gòu)中的l_onoff域設(shè)為非零，但l_linger為0)，便不用擔(dān)心closesocket調(diào)用進(jìn)入“鎖定”狀態(tài)(等待完成)，不論是否有排隊(duì)數(shù)據(jù)未發(fā)送或未被確認(rèn)。這種關(guān)閉方式稱為“強(qiáng)行關(guān)閉”，因?yàn)樘捉幼值奶撾娐妨⒓幢粡?fù)位，尚未發(fā)出的所有數(shù)據(jù)都會(huì)丟失。在遠(yuǎn)端的recv()調(diào)用都會(huì)失敗，并返回WSAECONNRESET錯(cuò)誤。
在connect成功建立連接之后設(shè)置該選項(xiàng)：
linger m_sLinger;
m_sLinger.l_onoff = 1; // (在closesocket()調(diào)用,但是還有數(shù)據(jù)沒(méi)發(fā)送完畢的時(shí)候容許逗留)
m_sLinger.l_linger = 0; // (容許逗留的時(shí)間為0秒)
setsockopt(sockConnected,
SOL_SOCKET,
SO_LINGER,
(const char*)&m_sLinger,
sizeof(linger));
總結(jié)
也許我們避免不了CLOSE_WAIT狀態(tài)凍結(jié)的再次出現(xiàn)，但我們會(huì)使影響降到最小，希望那個(gè)重用套接字選項(xiàng)能夠使得下一次重新建立連接時(shí)可以把CLOSE_WAIT狀態(tài)踢掉。
我的意思是：當(dāng)一方關(guān)閉連接后，另外一方?jīng)]有檢測(cè)到，就導(dǎo)致了CLOSE_WAIT的出現(xiàn)，上次我的一個(gè)朋友也是這樣，他寫了一個(gè)客戶端和 APACHE連接，當(dāng)APACHE把連接斷掉后，他沒(méi)檢測(cè)到，出現(xiàn)了CLOSE_WAIT，后來(lái)我叫他檢測(cè)了這個(gè)地方，他添加了調(diào)用 closesocket的代碼后，這個(gè)問(wèn)題就消除了。
如果你在關(guān)閉連接前還是出現(xiàn)CLOSE_WAIT,建議你取消shutdown的調(diào)用，直接兩邊closesocket試試。
另外一個(gè)問(wèn)題:
比如這樣的一個(gè)例子：
當(dāng)客戶端登錄上服務(wù)器后，發(fā)送身份驗(yàn)證的請(qǐng)求，服務(wù)器收到了數(shù)據(jù)，對(duì)客戶端身份進(jìn)行驗(yàn)證，發(fā)現(xiàn)密碼錯(cuò)誤，這時(shí)候服務(wù)器的一般做法應(yīng)該是先發(fā)送一個(gè)密碼錯(cuò)誤的信息給客戶端，然后把連接斷掉。
如果把
m_sLinger.l_onoff = 1;
m_sLinger.l_linger = 0;
這樣設(shè)置后，很多情況下，客戶端根本就收不到密碼錯(cuò)誤的消息，連接就被斷了。
出現(xiàn)CLOSE_WAIT的原因很簡(jiǎn)單，就是某一方在網(wǎng)絡(luò)連接斷開(kāi)后，沒(méi)有檢測(cè)到這個(gè)錯(cuò)誤，沒(méi)有執(zhí)行closesocket，導(dǎo)致了這個(gè)狀態(tài)的實(shí)現(xiàn)，這在TCP/IP協(xié)議的狀態(tài)變遷圖上可以清楚看到。同時(shí)和這個(gè)相對(duì)應(yīng)的還有一種叫TIME_WAIT的。
另外，把SOCKET的SO_LINGER設(shè)置為0秒拖延(也就是立即關(guān)閉)在很多時(shí)候是有害處的。
還有，把端口設(shè)置為可復(fù)用是一種不安全的網(wǎng)絡(luò)編程方法。
能不能解釋請(qǐng)看這里
http://blog.csdn.net/cqq/archive/2005/01/26/269160.aspx
再看這個(gè)圖：
斷開(kāi)連接的時(shí)候，
當(dāng)發(fā)起主動(dòng)關(guān)閉的左邊這方發(fā)送一個(gè)FIN過(guò)去后，右邊被動(dòng)關(guān)閉的這方要回應(yīng)一個(gè)ACK，這個(gè)ACK是TCP回應(yīng)的，而不是應(yīng)用程序發(fā)送的，此時(shí)，被動(dòng)關(guān)閉的一方就處于CLOSE_WAIT狀態(tài)了。如果此時(shí)被動(dòng)關(guān)閉的這一方不再繼續(xù)調(diào)用closesocket,那么他就不會(huì)發(fā)送接下來(lái)的FIN，導(dǎo)致自己老是處于CLOSE_WAIT。只有被動(dòng)關(guān)閉的這一方調(diào)用了closesocket,才會(huì)發(fā)送一個(gè)FIN給主動(dòng)關(guān)閉的這一方，同時(shí)也使得自己的狀態(tài)變遷為L(zhǎng)AST_ACK。
比如被動(dòng)關(guān)閉的是客戶端。。。
當(dāng)對(duì)方調(diào)用closesocket的時(shí)候，你的程序正在
int nRet = recv(s,....);
if (nRet == SOCKET_ERROR)
{// closesocket(s);return FALSE;}
很多人就是忘記了那句closesocket，這種代碼太常見(jiàn)了。
我的理解，當(dāng)主動(dòng)關(guān)閉的一方發(fā)送FIN到被動(dòng)關(guān)閉這邊后，被動(dòng)關(guān)閉這邊的TCP馬上回應(yīng)一個(gè)ACK過(guò)去，同時(shí)向上面應(yīng)用程序提交一個(gè)ERROR，導(dǎo)致上面的SOCKET的send或者recv返回SOCKET_ERROR，正常情況下，如果上面在返回SOCKET_ERROR后調(diào)用了 closesocket,那么被動(dòng)關(guān)閉的者一方的TCP就會(huì)發(fā)送一個(gè)FIN過(guò)去，自己的狀態(tài)就變遷到LAST_ACK.
看過(guò)close wait是什么的人還看了：