最近需要上線的邏輯server由於需要與大量的後台server互動，今天突然發現有大量的close_wait產生，於是仔細研究了一下：
首先我們知道，如果我們的伺服器程式處於close_wait狀態的話，說明套接字是被動關閉的！
因為如果是client端主動斷掉當前連線的話，那麼雙方關閉這個tcp連線共需要四個packet：
client ---> fin ---> server
client <--- ack <--- server
這時候client端處於fin_wait_2狀態；而server 程式處於close_wait狀態。
client <--- fin <--- server
這時server 傳送fin給client，server 就置為last_ack狀態。
client ---> ack ---> server
client回應了ack，那麼server 的套接字才會真正置為closed狀態。
server 程式處於close_wait狀態，而不是last_ack狀態，說明還沒有發fin給client，那麼可能是在關閉連線之前還有許多資料要傳送或者其他事要做，導致沒有發這個fin packet。
通常來說，乙個close_wait會維持至少2個小時的時間（這個時間外網伺服器通常會做調整，要不然太危險了）。如果有個流氓特地寫了個程式，給你造成一堆的close_wait，消耗
你的資源，那麼通常是等不到釋放那一刻，系統就已經解決崩潰了。
但是實際上，還是主要是因為我們的程式**有問題，通常是如下問題：
比如被動關閉的是客戶端。。。
當對方呼叫closesocket的時候，你的程式正在
int nret = recv(s,....);
if (nret == socket_error)
很多人就是忘記了那句closesocket，這種**太常見了。
我的理解，當主動關閉的一方傳送fin到被動關閉這邊後，被動關閉這邊的 tcp馬上回應乙個ack過去，同時向上面應用程式提交乙個error，導 致上面的socket的send或者recv返回socket_error，正常情況下，如果上面在返回socket_error後呼叫了 closesocket,那麼被動關閉的者一方的tcp就會傳送乙個fin過去，自己的狀態就變遷到last_ack.
close wait狀態的產生原因及解決
最近需要上線的邏輯server由於需要與大量的後台server互動，今天突然發現有大量的close wait產生，於是仔細研究了一下 首先我們知道，如果我們的伺服器程式處於close wait狀態的話，說明套接字是被動關閉的！因為如果是client端主動斷掉當前連線的話，那麼雙方關閉這個tcp連線共...
close wait狀態的產生原因及解決
最近測試環境server由於需要與大量的後台server互動，今天突然發現有大量的close wait產生，於是仔細研究了一下 如果我們的伺服器程式處於close wait狀態的話，說明套接字是被動關閉的！因為如果是client端主動斷掉當前連線的話，那麼雙方關閉這個tcp連線共需要四個packet...
CLOSE WAIT狀態的生成原因
關閉socket分為主動關閉 active closure 和被動關閉 passive closure 兩種情況。前者是指有本地主機主動發起的關閉 而後者則是指本地主機檢測到遠端主機發起關閉之後，作出回應，從而關閉整個連線。其狀態圖如下圖所示 起初每個socket都是closed狀態，當客戶端初使化...