TCP關閉連線（為什麼會能 Time_wait,Close_wait ） ?
TCP關閉連線（為什麼會能 Time_wait,Close_wait ） ?
作者：胡文斌
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這個類，再往下就是本地介面呼叫了，因此它是依賴本地作業系統的實現）處於的一個狀態
然而在socket的處於TIME_WAIT狀態之後到它結束之前，該socket所佔用的本地埠號將一直無法釋放，因此服務在高併發高負載下執行一段時間後，就常常會出現做為客戶端的程式無法向服務端建立新的socket連線的情況，過了1~4分鐘之後，客戶又可以連線上了，沒多久又連線不上，再等1~4分鐘之後又可以連線上，（上一個星期我們在做一個服務切換時遇到了這種情況）
這是因為服務方socket資源已經耗盡。netstat命令檢視系統將會發現機器上存在大量處於TIME_WAIT狀態的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服務和異常），而且客戶方一般都不會有持續的大併發請求。 因此對資源沒有這麼苛刻要求。