TCP連接的狀態與關閉方式及其對Server與Client的影響 - jarvise－IT工程師數位筆記本

文章出處

TCP連接的狀態與關閉方式及其對Server與Client的影響

1. TCP連接的狀態

　　首先介紹一下TCP連接建立與關閉過程中的狀態。TCP連接過程是狀態的轉換，促使狀態發生轉換的因素包括用戶調用、特定數據包以及超時等，具體狀態如下所示：

CLOSED：初始狀態，表示沒有任何連接。
LISTEN：Server端的某個Socket正在監聽來自遠方的TCP端口的連接請求。
SYN_SENT：發送連接請求后等待確認信息。當客戶端Socket進行Connect連接時，會首先發送SYN包，隨即進入SYN_SENT狀態，然后等待Server端發送三次握手中的第2個包。
SYN_RECEIVED：收到一個連接請求后回送確認信息和對等的連接請求，然后等待確認信息。通常是建立TCP連接的三次握手過程中的一個中間狀態，表示Server端的Socket接收到來自Client的SYN包，并作出回應。
ESTABLISHED：表示連接已經建立，可以進行數據傳輸。
FIN_WAIT_1：主動關閉連接的一方等待對方返回ACK包。若Socket在ESTABLISHED狀態下主動關閉連接并向對方發送FIN包（表示己方不再有數據需要發送），則進入FIN_WAIT_1狀態，等待對方返回ACK包，此后還能讀取數據，但不能發送數據。在正常情況下，無論對方處于何種狀態，都應該馬上返回ACK包，所以FIN_WAIT_1狀態一般很難見到。
FIN_WAIT_2：主動關閉連接的一方收到對方返回的ACK包后，等待對方發送FIN包。處于FIN_WAIT_1狀態下的Socket收到了對方返回的ACK包后，便進入FIN_WAIT_2狀態。由于FIN_WAIT_2狀態下的Socket需要等待對方發送的FIN包，所有常常可以看到。若在FIN_WAIT_1狀態下收到對方發送的同時帶有FIN和ACK的包時，則直接進入TIME_WAIT狀態，無須經過FIN_WAIT_2狀態。
TIME_WAIT：主動關閉連接的一方收到對方發送的FIN包后返回ACK包（表示對方也不再有數據需要發送，此后不能再讀取或發送數據），然后等待足夠長的時間（2MSL）以確保對方接收到ACK包（考慮到丟失ACK包的可能和迷路重復數據包的影響），最后回到CLOSED狀態，釋放網絡資源。
CLOSE_WAIT：表示被動關閉連接的一方在等待關閉連接。當收到對方發送的FIN包后（表示對方不再有數據需要發送），相應的返回ACK包，然后進入CLOSE_WAIT狀態。在該狀態下，若己方還有數據未發送，則可以繼續向對方進行發送，但不能再讀取數據，直到數據發送完畢。
LAST_ACK：被動關閉連接的一方在CLOSE_WAIT狀態下完成數據的發送后便可向對方發送FIN包（表示己方不再有數據需要發送），然后等待對方返回ACK包。收到ACK包后便回到CLOSED狀態，釋放網絡資源。
CLOSING：比較罕見的例外狀態。正常情況下，發送FIN包后應該先收到（或同時收到）對方的ACK包，再收到對方的FIN包，而CLOSING狀態表示發送FIN包后并沒有收到對方的ACK包，卻已收到了對方的FIN包。有兩種情況可能導致這種狀態：其一，如果雙方幾乎在同時關閉連接，那么就可能出現雙方同時發送FIN包的情況；其二，如果ACK包丟失而對方的FIN包很快發出，也會出現FIN先于ACK到達。
　　TCP連接的狀態轉換如下圖所示

2. TCP連接的關閉方式

　　建立TCP連接需要三次握手，而關閉連接則需要四次握手，并且分為主動關閉和被動關閉。這是由于TCP連接是全雙工的，我關了你的連接，并不等于你關了我的連接，因此雙方都必須單獨進行關閉。當一方完成它的數據發送任務后可以發送FIN包來終止這個方向的連接，表明自己不再有數據需要發送；收到FIN包的那一方雖然不能再讀取數據，但仍能發送數據。以Client主動關閉連接為例：

Client向Server發送FIN包，表示Client主動關閉連接，然后進入FIN_WAIT_1狀態，等待Server返回ACK包。此后Client不能再向Server發送數據，但能讀取數據。
Server收到FIN包后向Client發送ACK包，然后進入CLOSE_WAIT狀態，此后Server不能再讀取數據，但可以繼續向Client發送數據。Client收到Server返回的ACK包后進入FIN_WAIT_2狀態，等待Server發送FIN包。
Server完成數據的發送后，將FIN包發送給Client，然后進入LAST_ACK狀態，等待Client返回ACK包，此后Server既不能讀取數據，也不能發送數據。
Client收到FIN包后向Server發送ACK包，然后進入TIME_WAIT狀態，接著等待足夠長的時間（2MSL）以確保Server接收到ACK包，最后回到CLOSED狀態，釋放網絡資源。Server收到Client返回的ACK包后便回到CLOSED狀態，釋放網絡資源。
　　TCP連接的建立到關閉，需要經歷以下狀態遷移（假定Client發起連接，并主動關閉連接）：

Client
　　CLOSED -> SYN_SENT -> ESTABLISHED -> FIN_WAIT_1 -> FIN_WAIT_2 -> TIME_WAIT -> CLOSED

Server
　　CLODES -> LISTEN -> SYN_RECEIVED -> ESTABLISHED -> CLOSE_WAIT -> LAST_ACK -> CLOSED

3. 對Server與Client的影響

　　在詳細了解TCP連接的狀態和關閉方式后，我們會發現TIME_WAIT狀態是一個坑爹的存在！主動關閉連接的一方在發送最后一個ACK包后，無論對方是否收到都會進入TIME_WAIT狀態，等待2MSL的時間，然后才能釋放網絡資源。MSL就是Maximum Segment Lifetime（數據包的最大生命周期），是一個數據包能在互聯網上生存的最長時間，若超過這個時間則該數據包將會消失在網絡中。操作系統通常會將2MSL設為4分鐘，最低不少于30秒，因而TIME_WAIT狀態一般維持在30秒至4分鐘。這個是TCP/IP協議必不可少的，是TCP/IP設計者設計的，也就是無法解決的。TIME_WAIT狀態的存在主要有兩個原因：

可靠地實現TCP全雙工連接的終止。在關TCP閉連接時，最后的ACK包是由主動關閉方發出的，如果這個ACK包丟失，則被動關閉方將重發FIN包，因此主動方必須維護狀態信息，以允許它重發這個ACK包。如果不維持這個狀態信息，那么主動方將回到CLOSED狀態，并對被動方重發的FIN包響應RST包，而被動關閉方將此包解釋成一個錯誤（在Java中會拋出connection reset的SocketException)。因而，要實現TCP全雙工連接的正常終止，必須能夠處理四次握手協議中任意一個包丟失的情況，主動關閉方必須維持狀態信息進入TIME_WAIT狀態。
確保迷路重復數據包在網絡中消失，防止上一次連接中的包迷路后重新出現，影響新連接。TCP數據包可能由于路由器異常而迷路，在迷路期間，數據包發送方可能因超時而重發這個包，迷路的數據包在路由器恢復后也會被送到目的地，這個迷路的數據包就稱為Lost Duplicate。在關閉一個TCP連接后，如果馬上使用相同的IP地址和端口建立新的TCP連接，那么有可能出現前一個連接的迷路重復數據包在前一個連接關閉后再次出現，影響新建立的連接。為了避免這一情況，TCP協議不允許使用處于TIME_WAIT狀態的連接的IP和端口啟動一個新連接，只有經過2MSL的時間，確保上一次連接中所有的迷路重復數據包都已消失在網絡中，才能安全地建立新連接。
　　對于Client而言，每個連接都需要占用一個端口，而系統允許的可用端口數不足65000個（這也是在TCP參數優化后才能達到）。因此，如果Client發起過多的連接并主動關閉（假設沒有重用端口或者連接多個Server），就會有大量的連接在關閉后處于TIME_WAIT狀態，等待2MSL的時間后才能釋放網絡資源（包括端口），于是Client會由于缺少可用端口而無法新建連接。

　　對Server而言（特別是處理高并發短連接的Server），Server端與Client建立的連接是使用同一個端口的，即監聽的端口，每個連接通過一個五元組區分，包括源IP地址、源端口、傳輸層協議號（協議類型）、目的IP地址、目的端口，因而在理論上，Server不受系統端口數的限制。但是，Server對每個端口上的連接數是有限制的，它要使用哈希表記錄端口上的每個連接，并受到文件描述符的最大打開數的限制。所以，如果Server主動關閉連接，同樣會有大量的連接在關閉后處于TIME_WAIT狀態，等待2MSL的時間后才能釋放網絡資源（包括哈希表上的連接記錄和文件描述符），于是Server會由于達到哈希表和文件描述符的限制而無法接受新連接，造成性能的急劇下滑，性能曲線會持續產生嚴重的波動。對于這種情況，有三種應對方式：

試圖讓Client主動關閉連接，由于每個Client的并發量都比較低，因而不會產生性能瓶頸。
優化Server的系統TCP參數，使其網絡資源的最大值、消耗速度和恢復速度達到平衡。
改寫TCP協議，重新實現底層代碼，不過該方式難度很大，而且系統的穩定性和安全性可能受到影響。