1. 實際問題
? ? ? ? 初步查看發現，無法對外新建TCP連接時，線上服務器存在大量處于TIME_WAIT狀態的TCP連接（最多的一次為單機10w+，其中引起報警的那個模塊產生的TIME_WAIT約2w），導致其無法跟下游模塊建立新TCP連接。
? ? ? ? TIME_WAIT涉及到TCP釋放連接過程中的狀態遷移，也涉及到具體的socket api對TCP狀態的影響，下面開始逐步介紹這些概念。

2. TCP狀態遷移
? ? ? ?面向連接的TCP協議要求每次peer間通信前建立一條TCP連接，該連接可抽象為一個4元組（four-tuple，有時也稱socket pair）：（local_ip, local_port, remote_ip,remote_port），這4個元素唯一地代表一條TCP連接。
? ? ? ?1）TCP Connection Establishment
? ? ? ?TCP建立連接的過程，通常又叫“三次握手”（three-way handshake），可用下圖來示意：
? ? ? ?

? ? ??可對上圖做如下解釋：
? ? ? ? a. client向server發送SYN并約定初始包序號（sequence number）為J；
? ? ? ? b. server發送自己的SYN并表明初始包序號為K，同時，針對client的SYNJ返回ACKJ+1（注：J+1表示server期望的來自該client的下一個包序為J+1）；
? ? ? ? c. client收到來自server的SYN+ACK后，發送ACKK+1，至此，TCP建立成功。
? ? ? ? 其實，在TCP建立時的3次握手過程中，還要通過SYN包商定各自的MSS，timestamp等參數，這涉及到協議的細節，本文旨在拋磚引玉，不再展開。

? ? ? ? ? ?2）TCPConnection Termination
? ? ? ?與建立連接的3次握手相對應，釋放一條TCP連接時，需要經過四步交互（又稱“四次揮手”），如下圖所示：
? ? ? ??
? ? ? ? ?可對上圖做如下解釋：
? ? ? ?a. 連接的某一方先調用close()發起主動關閉（active close），該api會促使TCP傳輸層向remotepeer發送FIN包，該包表明發起active close的application不再發送數據（特別注意：這里“不再發送數據”的承諾是從應用層角度來看的，在TCP傳輸層，還是要將該application對應的內核tcp send buffer中當前尚未發出的數據發到鏈路上）。 ? ? ? ? ? ? ? ?
? ? ? ?remote peer收到FIN后，需要完成被動關閉（passive close），具體分為兩步：
? ? ? ?b. 首先，在TCP傳輸層，先針對對方的FIN包發出ACK包（主要ACK的包序是在對方FIN包序基礎上加1）；
? ? ? ?c. 接著，應用層的application收到對方的EOF（end-of-file，對方的FIN包作為EOF傳給應用層的application）后，得知這條連接不會再有來自對方的數據，于是也調用close()關閉連接，該close會促使TCP傳輸層發送FIN。
? ? ? ?d. 發起主動關閉的peer收到remote peer的FIN后，發送ACK包，至此，TCP連接關閉。
? ? ? ?注意1：TCP連接的任一方均可以首先調用close()以發起主動關閉，上圖以client主動發起關閉做說明，而不是說只能client發起主動關閉。
? ? ? ?注意2：上面給出的TCP建立/釋放連接的過程描述中，未考慮由于各種原因引起的重傳、擁塞控制等協議細節，感興趣的同學可以查看各種TCP RFC Documents ，比如TCP RFC793。

? ? ? ??3）TCP StateTransition Diagram
? ? ? ?上面介紹了TCP建立、釋放連接的過程，此處對TCP狀態機的遷移過程做總體說明。將TCP RFC793中描述的TCP狀態機遷移圖摘出如下（下圖引用自這里）：
? ? ?
? ? ? ? ??TCP狀態機共含11個狀態，狀態間在各種socket apis的驅動下進行遷移，雖然此圖看起來錯綜復雜，但對于有一定TCP網絡編程經驗的同學來說，理解起來還是比較容易的。限于篇幅，本文不準備展開詳述，想了解具體遷移過程的新手同學，建議閱讀《Linux Network Programming Volume1》第2.6節。

3. TIME_WAIT狀態
? ? ? ??經過前面的鋪墊，終于要講到與本文主題相關的內容了。 ^_^
? ? ? ? 從TCP狀態遷移圖可知，只有首先調用close()發起主動關閉的一方才會進入TIME_WAIT狀態，而且是必須進入（圖中左下角所示的3條狀態遷移線最終均要進入該狀態才能回到初始的CLOSED狀態）。
? ? ? ? 從圖中還可看到，進入TIME_WAIT狀態的TCP連接需要經過2MSL才能回到初始狀態，其中，MSL是指Max
Segment Lifetime，即數據包在網絡中的最大生存時間。每種TCP協議的實現方法均要指定一個合適的MSL值，如RFC1122給出的建議值為2分鐘，又如Berkeley體系的TCP實現通常選擇30秒作為MSL值。這意味著TIME_WAIT的典型持續時間為1-4分鐘。
? ? ? ?TIME_WAIT狀態存在的原因主要有兩點：
? ???? 1）為實現TCP這種全雙工（full-duplex）連接的可靠釋放
? ? ? ?參考本文前面給出的TCP釋放連接4次揮手示意圖，假設發起active close的一方（圖中為client）發送的ACK（4次交互的最后一個包）在網絡中丟失，那么由于TCP的重傳機制，執行passiveclose的一方（圖中為server）需要重發其FIN，在該FIN到達client（client是active close發起方）之前，client必須維護這條連接的狀態（盡管它已調用過close），具體而言，就是這條TCP連接對應的（local_ip, local_port）資源不能被立即釋放或重新分配。直到romete peer重發的FIN達到，client也重發ACK后，該TCP連接才能恢復初始的CLOSED狀態。如果activeclose方不進入TIME_WAIT以維護其連接狀態，則當passive close方重發的FIN達到時，active close方的TCP傳輸層會以RST包響應對方，這會被對方認為有錯誤發生（而事實上，這是正常的關閉連接過程，并非異常）。
? ? ? ? 2）為使舊的數據包在網絡因過期而消失
? ? ? ?為說明這個問題，我們先假設TCP協議中不存在TIME_WAIT狀態的限制，再假設當前有一條TCP連接：(local_ip, local_port, remote_ip,remote_port)，因某些原因，我們先關閉，接著很快以相同的四元組建立一條新連接。本文前面介紹過，TCP連接由四元組唯一標識，因此，在我們假設的情況中，TCP協議棧是無法區分前后兩條TCP連接的不同的，在它看來，這根本就是同一條連接，中間先釋放再建立的過程對其來說是“感知”不到的。這樣就可能發生這樣的情況：前一條TCP連接由local peer發送的數據到達remote peer后，會被該remot peer的TCP傳輸層當做當前TCP連接的正常數據接收并向上傳遞至應用層（而事實上，在我們假設的場景下，這些舊數據到達remote peer前，舊連接已斷開且一條由相同四元組構成的新TCP連接已建立，因此，這些舊數據是不應該被向上傳遞至應用層的），從而引起數據錯亂進而導致各種無法預知的詭異現象。作為一種可靠的傳輸協議，TCP必須在協議層面考慮并避免這種情況的發生，這正是TIME_WAIT狀態存在的第2個原因。
? ? ? ?具體而言，local peer主動調用close后，此時的TCP連接進入TIME_WAIT狀態，處于該狀態下的TCP連接不能立即以同樣的四元組建立新連接，即發起active close的那方占用的local port在TIME_WAIT期間不能再被重新分配。由于TIME_WAIT狀態持續時間為2MSL，這樣保證了舊TCP連接雙工鏈路中的舊數據包均因過期（超過MSL）而消失，此后，就可以用相同的四元組建立一條新連接而不會發生前后兩次連接數據錯亂的情況。

另一比較深入的說法

TIME_WAIT狀態的存在有兩個理由：（1）讓4次握手關閉流程更加可靠；4次握手的最后一個ACK是是由主動關閉方發送出去的，若這個ACK丟失，被動關閉方會再次發一個FIN過來。若主動關閉方能夠保持一個2MSL的TIME_WAIT狀態，則有更大的機會讓丟失的ACK被再次發送出去。（2）防止lost duplicate對后續新建正常鏈接的傳輸造成破壞。lost duplicate在實際的網絡中非常常見，經常是由于路由器產生故障，路徑無法收斂，導致一個packet在路由器A，B，C之間做類似死循環的跳轉。IP頭部有個TTL，限制了一個包在網絡中的最大跳數，因此這個包有兩種命運，要么最后TTL變為0，在網絡中消失；要么TTL在變為0之前路由器路徑收斂，它憑借剩余的TTL跳數終于到達目的地。但非常可惜的是TCP通過超時重傳機制在早些時候發送了一個跟它一模一樣的包，并先于它達到了目的地，因此它的命運也就注定被TCP協議棧拋棄。另外一個概念叫做incarnation connection，指跟上次的socket pair一摸一樣的新連接，叫做incarnation of previous connection。lost duplicate加上incarnation connection，則會對我們的傳輸造成致命的錯誤。大家都知道TCP是流式的，所有包到達的順序是不一致的，依靠序列號由TCP協議棧做順序的拼接；假設一個incarnation connection這時收到的seq=1000, 來了一個lost duplicate為seq=1000, len=1000, 則tcp認為這個lost duplicate合法，并存放入了receive buffer，導致傳輸出現錯誤。通過一個2MSL TIME_WAIT狀態，確保所有的lost duplicate都會消失掉，避免對新連接造成錯誤。

Q: 編寫 TCP/SOCK_STREAM 服務程序時，SO_REUSEADDR到底什么意思？?

?

A: 這個套接字選項通知內核，如果端口忙，但TCP狀態位于 TIME_WAIT ，可以重用?

端口。如果端口忙，而TCP狀態位于其他狀態，重用端口時依舊得到一個錯誤信息，?

指明"地址已經使用中"。如果你的服務程序停止后想立即重啟，而新套接字依舊?

使用同一端口，此時 SO_REUSEADDR 選項非常有用。必須意識到，此時任何非期?

望數據到達，都可能導致服務程序反應混亂，不過這只是一種可能，事實上很不?

可能。

總結

以上是生活随笔為你收集整理的TCP/IP详解--TIME_WAIT状态存在的原因的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。