Tcp關閉連接問題及注意
最近一段時間一直在學習閱讀mina和nio的源碼，也發現了一些問題無法解決，然后重讀了一下tcp協議，收獲頗多。（這就是帶著問題去讀書的好處）
這次就和大家分享一下我們的netframework服務總會拋出一個“connet reset by peer”的原因吧。通過抓包工具分析，主動關閉方直接發送了一個RST flags,而非FIN。就終止連接了。如下圖所示：
為什么調用sokcet的close時只通過一次握手就終結連接了？
要分析這個原因那就得從關閉連接程的四次握手，有時也會是三次握手，說起。如下圖所示：
大家都知道tcp正常的關閉連接要經過四次握手。如下所示：
在這四次握手狀態中，有一個特別要注意的狀態TIME_WAIT。這個狀態是主動關閉方在收到被關閉方的FIN后會處于并長期（2個MSL時間，根據具體的實現不同，這個值會不同，在RFC 1122建議MSL=2分鐘，但在Berkeley的實現上使用的值為30s,具體可以看www.rfc.net ,要是沒有耐心去看英文的可以看這個網站www.cnpaf.net 里面有協議說明以及相應的源碼，java源碼中我沒有發現這個值，我只能追蹤到PlainSocketImpl.java這個類，再往下就是本地接口調用了，因此它是依賴本地操作系統的實現）處于的一個狀態。也就是大約1-4分鐘，然后由操作系統自動回收并將TCP連接設為CLOSED初始狀態。如下圖所示：
然而在socket的處于TIME_WAIT狀態之后到它結束之前，該socket所占用的本地端口號將一直無法釋放，因此服務在高并發高負載下運行一段時間后，就常常會出現做為客戶端的程序無法向服務端建立新的socket連接的情況，過了1~4分鐘之后，客戶又可以連接上了，沒多久又連接不上，再等1~4分鐘之后又可以連接上，（上一個星期我們在做一個服務切換時遇到了這種情況）
這是因為服務方socket資源已經耗盡。netstat命令查看系統將會發現機器上存在大量處于TIME_WAIT狀態的socket連接,我這邊曾經出現達到了2w多個，并且占用大量的本地端口號。而此時機器上的可用本地端口號被占完，舊的大量處于TIME_WAIT狀態的socket尚未被系統回收時，就會出現無法向服務端創建新的socket連接的情況。只能過2分鐘之后等系統回收這些socket和端口資源之后才能服務，就這樣往復下去。
TCP為什么要這么要讓這種TIME_WAIT狀態存活這么久呢？其原因有兩個（參考stevens的unix網絡編程卷1 第38頁）：
- 可靠地實現TCP全雙工連接的終止。（確保最后的ACK能讓被關閉方接收）
- 允許老的重復分節在網絡中消逝。（TCP中是可靠的服務，當數據包丟失會重傳，當有數據包迷路的情況下，如果不等待2MSL時，當客戶端以同樣地方式重新和服務建立連接后，上一次迷路的數據包這時可能會到達服務，這時會造成舊包被重新讀取）
解決方法：
1、（推薦方法，只能治標不治本）重用本地端口設置SO_REUSEADDR和SO_REUSEPORT(stevens的unix網絡編程卷1 第179~182頁)有詳情的講解，這樣就可以允許同一端口上啟動同一服務器的多個實例。怎樣理解呢？說白了就是即使socket斷了，重新調用前面的socket函數不會再去占用新的一個，而是始終就是一個端口，這樣防止socket始終連接不上，會不斷地換新端口。Java 中通過調用Socket的setReuseAddress,詳細可以查看java.net.Socket源碼。【這個地方會有風險，具體可以看(stevens的unix網絡編程卷1 第181頁)】
2、修改內核TIME_WAIT等待的值，如果客戶端和服務器都在同個路由器下，這個是非常推薦的。（鏈路好，重傳機率低）
3、（不推崇，但目前我們是這樣做的，這個是造成（“connet reset by peer”）的元兇）設置SO_LINGER的值，java中是調用socket的 setSoLinger目前我們是設置為0的。設置為這個值的意思是當主動關閉方設置了setSoLinger（true,0）時，并調用close后，立該發送一個RST標志給對端，該TCP連接將立刻夭折，無論是否有排隊數據未發送或未被確認。這種關閉方式稱為“強行關閉”，而后套接字的虛電路立即被復位，尚未發出的所有數據都會丟失。而被動關閉方卻不知道對端已經徹底斷開。當被動關閉方正阻塞在recv()調用上時，接受到RST時，會立刻得到一個“connet reset by peer”的異常（即對端已經關閉），c中是返回一個EPEERRST錯。
為什么不推崇這種方法在(stevens的unix網絡編程卷1 第173頁)有詳細的講解。因為TIME_WAIT狀態是我們的朋友，它是有助有我們的（也就是說，它會讓舊的重復分節在網絡中超時消失（當我們的鏈路越長，ISP復雜的情況下（從網通到教育網的ping包用了9000ms），重復的分節的比例是非常高的。））。而且我們主動關閉連接方大都是由客戶端發起的（除了HTTP服務和異常），而且客戶方一般都不會有持續的大并發請求。 因此對資源沒有這么苛刻要求。