tcp通道關閉時，發生了什嗎？

  前段時間，同事發現一個採用Thrift TheadPoolServer作為TCP的服務出現了大量的CLOSE_WAIT狀態的socket。當第一次遇到這種問題的時候，你可能會有如下的問題：

1. 什麼是CLOSE_WAIT? 為什麼會發生?
2. 還有其他類似狀態我不知道的嗎？

其實，你真正想問的是：

1. 當tcp通道關閉時，發生了什麼事情？
2. 我該怎麼辦？

TCP通道是一個串連，串連的兩端都可以向通道裡寫資料或者從通道裡讀資料，串連的兩端都可以發起關閉操作。整個TCP通道的關閉流程如下：

A(socketfd:10) <——–TCP Connction ———->B(socketfd:20)

1. 關閉A，則A向B發送FIN;
2. B接受到FIN後，返回一個ACK，表明收到了關閉通知， 當B返回ACK後，狀態就轉變為CLOSE_WAIT（！）了，它在等待什麼呢？等待程式顯式（手動）的關閉socket B。如果開啟B的程式在發出ACK後，沒有做任何處理，那麼它就一直處於CLOSE_WAIT中了。
3. 如果程式顯式的關閉了B，那麼B會向A發送一個FIN，然後B就處於LAST_ACK狀態了；
4. A在接受到B的FIN後，發出最後一個ACK，此時A就處於知名的TIME_WAIT狀態了。TIME_WAIT時間一般會比較長。

如何避免CLOSE_WAIT? 太多的CLOSE_WAIT通常意味著你程式中存在著嚴重的問題：沒有正確處理socket的關閉事件，去查看代碼吧。

如何避免TIME_WAIT? 通常，這是一個不應該問的問題，應該先問自己，TIME_WAIT真的給你帶來麻煩了麼? TIME_WAIT是可靠性的保證機制，沒有必要去避免它。但或許，你可以嘗試一下使用RFC1323。如果某一端實在是有太多的TIME_WAIT而造成問題，我建議的策略是：

1. 盡量避免TIME_WAIT過多的一端主動關閉socket
2. 使用SocketPool，避免頻繁建立/關閉socket