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主動關閉連線為例：

1. Client向Server傳送FIN包，表示Client主動關閉連線，然後進入FIN_WAIT_1狀態，等待Server返回ACK包。此後Client不能再向Server傳送資料，但能讀取資料。
2. Server收到FIN包後向Client傳送ACK包，然後進入CLOSE_WAIT狀態，此後Server不能再讀取資料，但可以繼續向Client傳送資料。Client收到Server返回的ACK包後進入FIN_WAIT_2狀態，等待Server傳送FIN包。
3. Server完成資料的傳送後，將FIN包傳送給Client，然後進入LAST_ACK狀態，等待Client返回ACK包，此後Server既不能讀取資料，也不能傳送資料。
4. 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狀態的存在主要有兩個原因：

1. 可靠地實現TCP全雙工連線的終止。在關TCP閉連線時，最後的ACK包是由主動關閉方發出的，如果這個ACK包丟失，則被動關閉方將重發FIN包，因此主動方必須維護狀態資訊，以允許它重發這個ACK包。如果不維持這個狀態資訊，那麼主動方將回到CLOSED狀態，並對被動方重發的FIN包響應RST包，而被動關閉方將此包解釋成一個錯誤（在Java中會丟擲connection reset的SocketException)。因而，要實現TCP全雙工連線的正常終止，必須能夠處理四次握手協議中任意一個包丟失的情況，主動關閉方必須維持狀態資訊進入TIME_WAIT狀態。
2. 確保迷路重複資料包在網路中消失，防止上一次連線中的包迷路後重新出現，影響新連線。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會由於達到雜湊表和檔案描述符的限制而無法接受新連線，造成效能的急劇下滑，效能曲線會持續產生嚴重的波動。對於這種情況，有三種應對方式：

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