共計 2382 個字符，預計需要花費 6 分鐘才能閱讀完成。
這篇文章主要介紹“TCP 關閉連接的方法是什么”，在日常操作中，相信很多人在 TCP 關閉連接的方法是什么問題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”TCP 關閉連接的方法是什么”的疑惑有所幫助！接下來，請跟著丸趣 TV 小編一起來學習吧！
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 服務和異常），而且客戶方一般都不會有持續的大并發請求。因此對資源沒有這么苛刻要求。
到此，關于“TCP 關閉連接的方法是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注丸趣 TV 網站，丸趣 TV 小編會繼續努力為大家帶來更多實用的文章！
