多圖詳解 TCP 連接管理，太全了！！！
TCP 是一種面向連接的單播協議，在 TCP 中，並不存在多播、廣播的這種行為，因為 TCP 報文段中能明確發送方和接受方的 IP 地址。
在發送數據前，相互通訊的雙方（即發送方和接受方）需要建立一條連接，在發送數據後，通訊雙方需要斷開連接，這就是 TCP 連接的建立和終止。
TCP 連接的建立和終止
如果你看過我之前寫的關於網路層的一篇文章，你應該知道 TCP 的基本元素有四個：即發送方的 IP 地址、發送方的埠號、接收方的 IP 地址、接收方的埠號。而每一方的 IP + 埠號都可以看作是一個套接字，套接字能夠被唯一標示。套接字就相當於是門，出了這個門，就要進行數據傳輸了。
TCP 的連接建立 -> 終止總共分為三個階段
下面我們所討論的重點也是集中在這三個層面。
下圖是一個非常典型的 TCP 連接的建立和關閉過程，其中不包括數據傳輸的部分。
TCP 建立連接 – 三次握手
- 服務端進程準備好接收來自外部的 TCP 連接，一般情況下是調用 bind、listen、socket 三個函數完成。這種打開方式被認為是
被動打開(passive open)。然後服務端進程處於LISTEN狀態，等待客戶端連接請求。 - 客戶端通過
connect發起主動打開(active open)，向伺服器發出連接請求，請求中首部同步位 SYN = 1，同時選擇一個初始序號 sequence ，簡寫 seq = x。SYN 報文段不允許攜帶數據，只消耗一個序號。此時，客戶端進入SYN-SEND狀態。 - 伺服器收到客戶端連接後，，需要確認客戶端的報文段。在確認報文段中，把 SYN 和 ACK 位都置為 1 。確認號是 ack = x + 1，同時也為自己選擇一個初始序號 seq = y。這個報文段也不能攜帶數據，但同樣要消耗掉一個序號。此時，TCP 伺服器進入
SYN-RECEIVED(同步收到)狀態。 - 客戶端在收到伺服器發出的響應後，還需要給出確認連接。確認連接中的 ACK 置為 1 ，序號為 seq = x + 1，確認號為 ack = y + 1。TCP 規定，這個報文段可以攜帶數據也可以不攜帶數據，如果不攜帶數據，那麼下一個數據報文段的序號仍是 seq = x + 1。這時，客戶端進入
ESTABLISHED (已連接)狀態 - 伺服器收到客戶的確認後，也進入
ESTABLISHED狀態。
這是一個典型的三次握手過程，通過上面 3 個報文段就能夠完成一個 TCP 連接的建立。三次握手的的目的不僅僅在於讓通訊雙方知曉正在建立一個連接，也在於利用數據包中的選項欄位來交換一些特殊資訊，交換初始序列號。
一般首個發送 SYN 報文的一方被認為是主動打開一個連接，而這一方通常也被稱為
客戶端。而 SYN 的接收方通常被稱為服務端，它用於接收這個 SYN，並發送下面的 SYN，因此這種打開方式是被動打開。
TCP 建立一個連接需要三個報文段，釋放一個連接卻需要四個報文段。
TCP 斷開連接 – 四次揮手
數據傳輸結束後，通訊的雙方可以釋放連接。數據傳輸結束後的客戶端主機和服務端主機都處於 ESTABLISHED 狀態，然後進入釋放連接的過程。
TCP 斷開連接需要歷經的過程如下
-
客戶端應用程式發出釋放連接的報文段，並停止發送數據，主動關閉 TCP 連接。客戶端主機發送釋放連接的報文段，報文段中首部 FIN 位置為 1 ，不包含數據，序列號位 seq = u，此時客戶端主機進入
FIN-WAIT-1(終止等待 1)階段。 -
伺服器主機接受到客戶端發出的報文段後，即發出確認應答報文，確認應答報文中 ACK = 1，生成自己的序號位 seq = v，ack = u + 1，然後伺服器主機就進入
CLOSE-WAIT(關閉等待)狀態。 -
客戶端主機收到服務端主機的確認應答後，即進入
FIN-WAIT-2(終止等待2)的狀態。等待客戶端發出連接釋放的報文段。 -
這時服務端主機會發出斷開連接的報文段，報文段中 ACK = 1，序列號 seq = v，ack = u + 1，在發送完斷開請求的報文後，服務端主機就進入了
LAST-ACK(最後確認)的階段。 -
客戶端收到服務端的斷開連接請求後，客戶端需要作出響應，客戶端發出斷開連接的報文段，在報文段中，ACK = 1, 序列號 seq = u + 1，因為客戶端從連接開始斷開後就沒有再發送數據，ack = v + 1，然後進入到
TIME-WAIT(時間等待)狀態，請注意，這個時候 TCP 連接還沒有釋放。必須經過時間等待的設置，也就是2MSL後，客戶端才會進入CLOSED狀態，時間 MSL 叫做最長報文段壽命（Maximum Segment Lifetime）。 -
服務端主要收到了客戶端的斷開連接確認後，就會進入 CLOSED 狀態。因為服務端結束 TCP 連接時間要比客戶端早，而整個連接斷開過程需要發送四個報文段，因此釋放連接的過程也被稱為四次揮手。
TCP 連接的任意一方都可以發起關閉操作，只不過通常情況下發起關閉連接操作一般都是客戶端。然而，一些伺服器比如 Web 伺服器在對請求作出相應後也會發起關閉連接的操作。TCP 協議規定通過發送一個 FIN 報文來發起關閉操作。
所以綜上所述，建立一個 TCP 連接需要三個報文段，而關閉一個 TCP 連接需要四個報文段。TCP 協議還支援一種半開啟(half-open) 狀態，雖然這種情況並不多見。
TCP 半開啟
TCP 連接處於半開啟的這種狀態是因為連接的一方關閉或者終止了這個 TCP 連接卻沒有通知另一方，也就是說兩個人正在微信聊天，cxuan 你下線了你不告訴我，我還在跟你侃八卦呢。此時就認為這條連接處於半開啟狀態。這種情況發生在通訊中的一方處於主機崩潰的情況下，你 xxx 的，我電腦死機了我咋告訴你？只要處於半連接狀態的一方不傳輸數據的話，那麼是無法檢測出來對方主機已經下線的。
另外一種處於半開啟狀態的原因是通訊的一方關閉了主機電源 而不是正常關機。這種情況下會導致伺服器上有很多半開啟的 TCP 連接。
TCP 半關閉
既然 TCP 支援半開啟操作，那麼我們可以設想 TCP 也支援半關閉操作。同樣的，TCP 半關閉也並不常見。TCP 的半關閉操作是指僅僅關閉數據流的一個傳輸方向。兩個半關閉操作合在一起就能夠關閉整個連接。在一般情況下，通訊雙方會通過應用程式互相發送 FIN 報文段來結束連接，但是在 TCP 半關閉的情況下，應用程式會表明自己的想法：”我已經完成了數據的發送發送，並發送了一個 FIN 報文段給對方，但是我依然希望接收來自對方的數據直到它發送一個 FIN 報文段給我”。 下面是一個 TCP 半關閉的示意圖。
解釋一下這個過程：
首先客戶端主機和伺服器主機一直在進行數據傳輸，一段時間後，客戶端發起了 FIN 報文，要求主動斷開連接，伺服器收到 FIN 後，回應 ACK ，由於此時發起半關閉的一方也就是客戶端仍然希望伺服器發送數據，所以伺服器會繼續發送數據，一段時間後伺服器發送另外一條 FIN 報文，在客戶端收到 FIN 報文回應 ACK 給伺服器後，斷開連接。
TCP 的半關閉操作中，連接的一個方向被關閉，而另一個方向仍在傳輸數據直到它被關閉為止。只不過很少有應用程式使用這一特性。
同時打開和同時關閉
還有一種比較非常規的操作，這就是兩個應用程式同時主動打開連接。雖然這種情況看起來不太可能，但是在特定的安排下卻是有可能發生的。我們主要講述這個過程。
通訊雙方在接收到來自對方的 SYN 之前會首先發送一個 SYN，這個場景還要求通訊雙方都知道對方的 IP 地址 + 埠號。
比如戀愛中的一對男女，他倆都同時說出了我愛你這個神聖的誓言，然後他倆對彼此的響應進行么么噠，這就是同時打開。
下面是同時打開的例子
如上圖所示，通訊雙方都在收到對方報文前主動發送了 SYN 報文，都在收到彼此的報文後回復了一個 ACK 報文。
一個同時打開過程需要交換四個報文段，比普通的三次握手增加了一個，由於同時打開沒有客戶端和伺服器一說，所以這裡我用了通訊雙方來稱呼。
像同時打開一樣，同時關閉也是通訊雙方同時提出主動關閉請求，發送 FIN 報文，下圖顯示了一個同時關閉的過程。
同時關閉過程中需要交換和正常關閉相同數量的報文段，只不過同時關閉不像四次揮手那樣順序進行，而是交叉進行的。
聊一聊初始序列號
也許是我上面圖示或者文字描述的不專業，初始序列號它是有專業術語表示的，初始序列號的英文名稱是Initial sequence numbers (ISN)，所以我們上面表示的 seq = v，其實就表示的 ISN。
在發送 SYN 之前，通訊雙方會選擇一個初始序列號。初始序列號是隨機生成的，每一個 TCP 連接都會有一個不同的初始序列號。RFC 文檔指出初始序列號是一個 32 位的計數器，每 4 us（微秒） + 1。因為每個 TCP 連接都是一個不同的實例，這麼安排的目的就是為了防止出現序列號重疊的情況。
當一個 TCP 連接建立的過程中，只有正確的 TCP 四元組和正確的序列號才會被對方接收。這也反應了 TCP 報文段容易被偽造 的脆弱性，因為只要我偽造了一個相同的四元組和初始序列號就能夠偽造 TCP 連接，從而打斷 TCP 的正常連接，所以抵禦這種攻擊的一種方式就是使用初始序列號，另外一種方法就是加密序列號。
TCP 狀態轉換
我們上面聊到了三次握手和四次揮手，提到了一些關於 TCP 連接之間的狀態轉換，那麼下面我就從頭開始和你好好梳理一下這些狀態之間的轉換。
首先第一步，剛開始時伺服器和客戶端都處於 CLOSED 狀態，這時需要判斷是主動打開還是被動打開，如果是主動打開，那麼客戶端向伺服器發送 SYN 報文，此時客戶端處於 SYN-SEND 狀態，SYN-SEND 表示發送連接請求後等待匹配的連接請求，伺服器被動打開會處於 LISTEN 狀態，用於監聽 SYN 報文。如果客戶端調用了 close 方法或者經過一段時間沒有操作，就會重新變為 CLOSED 狀態，這一步轉換圖如下
這裡有個疑問，為什麼處於 LISTEN 狀態下的客戶端還會發送 SYN 變為 SYN_SENT 狀態呢？
知乎看到了車小胖大佬的回答，這種情況可能出現在 FTP 中，LISTEN -> SYN_SENT 是因為這個連接可能是由於伺服器端的應用有數據發送給客戶端所觸發的，客戶端被動接受連接，連接建立後，開始傳輸文件。也就是說，處於 LISTEN 狀態的伺服器也是有可能發送 SYN 報文的，只不過這種情況非常少見。
處於 SYN_SEND 狀態的伺服器會接收 SYN 並發送 SYN 和 ACK 轉換成為 SYN_RCVD 狀態，同樣的，處於 LISTEN 狀態的客戶端也會接收 SYN 並發送 SYN 和 ACK 轉換為 SYN_RCVD 狀態。如果處於 SYN_RCVD 狀態的客戶端收到 RST 就會變為 LISTEN 狀態。
這兩張圖一起看會比較好一些。
這裡需要解釋下什麼是 RST
這裡有一種情況是當主機收到 TCP 報文段後，其 IP 和埠號不匹配的情況。假設客戶端主機發送一個請求，而伺服器主機經過 IP 和埠號的判斷後發現不是給這個伺服器的，那麼伺服器就會發出一個 RST 特殊報文段給客戶端。
因此，當服務端發送一個 RST 特殊報文段給客戶端的時候，它就會告訴客戶端沒有匹配的套接字連接，請不要再繼續發送了。
RST：（Reset the connection）用於複位因某種原因引起出現的錯誤連接，也用來拒絕非法數據和請求。如果接收到 RST 位時候，通常發生了某些錯誤。
上面沒有識別正確的 IP 埠是一種導致 RST 出現的情況，除此之外，RST 還可能由於請求超時、取消一個已存在的連接等出現。
位於 SYN_RCVD 的伺服器會接收 ACK 報文，SYN_SEND 的客戶端會接收 SYN 和 ACK 報文，並發送 ACK 報文，由此，客戶端和伺服器之間的連接就建立了。
這裡還要注意一點，同時打開的狀態我在上面沒有刻意表示出來，實際上，在同時打開的情況下，它的狀態變化是這樣的。
為什麼會是這樣呢？因為你想，在同時打開的情況下，兩端主機都發起 SYN 報文，而主動發起 SYN 的主機會處於 SYN-SEND 狀態，發送完成後，會等待接收 SYN 和 ACK ， 在雙方主機都發送了 SYN + ACK 後，雙方都處於 SYN-RECEIVED(SYN-RCVD) 狀態，然後等待 SYN + ACK 的報文到達後，雙方就會處於 ESTABLISHED 狀態，開始傳輸數據。
好了，到現在為止，我給你敘述了一下 TCP 連接建立過程中的狀態轉換，現在你可以泡一壺茶喝點水，等著數據傳輸了。
好了，現在水喝夠了，這時候數據也傳輸完成了，數據傳輸完成後，這條 TCP 連接就可以斷開了。
現在我們把時鐘往前撥一下，調整到服務端處於 SYN_RCVD 狀態的時刻，因為剛收到了 SYN 包並發送了 SYN + ACK 包，此時服務端很開心，但是這時，服務端應用進程關閉了，然後應用進程發了一個 FIN 包，就會讓伺服器從 SYN_RCVD -> FIN_WAIT_1 狀態。
然後把時鐘調到現在，客戶端和伺服器現在已經傳輸完數據了 ，此時客戶端發送了一條 FIN 報文希望斷開連接，此時客戶端也會變為 FIN_WAIT_1 狀態，對於伺服器來說，它接收到了 FIN 報文段並回復了 ACK 報文，就會從 ESTABLISHED -> CLOSE_WAIT 狀態。
位於 CLOSE_WAIT 狀態的服務端會發送 FIN 報文，然後把自己置於 LAST_ACK 狀態。處於 FIN_WAIT_1 的客戶端接收 ACK 消息就會變為 FIN_WAIT_2 狀態。
這裡需要先解釋一下 CLOSING 這個狀態，FIN_WAIT_1 -> CLOSING 的轉換比較特殊
CLOSING 這種狀態比較特殊，實際情況中應該是很少見，屬於一種比較罕見的例外狀態。正常情況下，當你發送FIN 報文後，按理來說是應該先收到（或同時收到）對方的 ACK 報文，再收到對方的 FIN 報文。但是 CLOSING 狀態表示你發送 FIN 報文後，並沒有收到對方的 ACK 報文，反而卻也收到了對方的 FIN 報文。
什麼情況下會出現此種情況呢？其實細想一下，也不難得出結論：那就是如果雙方在同時關閉一個鏈接的話，那麼就出現了同時發送 FIN 報文的情況，也即會出現 CLOSING 狀態，表示雙方都正在關閉連接。
FIN_WAIT_2 狀態的客戶端接收服務端主機發送的 FIN + ACK 消息，並發送 ACK 響應後，會變為 TIME_WAIT 狀態。處於 CLOSE_WAIT 的客戶端發送 FIN 會處於 LAST_ACK 狀態。
這裡不少圖和部落格雖然在圖上畫的是 FIN + ACK 報文後才會處於 LAST_ACK 狀態，但是描述的時候，一般通常只對於 FIN 進行描述。也就是說 CLOSE_WAIT 發送 FIN 才會處於 LAST_ACK 狀態。
所以這裡 FIN_WAIT_1 -> TIME_WAIT 的狀態也就是接收 FIN 和 ACK 並發送 ACK 之後，客戶端處於的狀態。
然後位於 CLOSINIG 狀態的客戶端這時候還有 ACK 接收的話，會繼續處於 TIME_WAIT 狀態，可以看到，TIME_WAIT 狀態相當於是客戶端在關閉前的最後一個狀態，它是一種主動關閉的狀態；而 LAST_ACK 是服務端在關閉前的最後一個狀態，它是一種被動打開的狀態。
上面有幾個狀態比較特殊，這裡我們向西解釋下。
TIME_WAIT 狀態
通訊雙方建立 TCP 連接後，主動關閉連接的一方就會進入 TIME_WAIT 狀態。TIME_WAIT 狀態也稱為 2MSL 的等待狀態。在這個狀態下，TCP 將會等待最大段生存期(Maximum Segment Lifetime, MSL) 時間的兩倍。
這裡需要解釋下 MSL
MSL 是 TCP 段期望的最大生存時間，也就是在網路中存在的最長時間。這個時間是有限制的，因為我們知道 TCP 是依靠 IP 數據段來進行傳輸的，IP 數據報中有 TTL 和跳數的欄位，這兩個欄位決定了 IP 的生存時間，一般情況下，TCP 的最大生存時間是 2 分鐘，不過這個數值是可以修改的，根據不同作業系統可以修改此值。
基於此，我們來探討 TIME_WAIT 的狀態。
當 TCP 執行一個主動關閉並發送最終的 ACK 時，TIME_WAIT 應該以 2 * 最大生存時間存在，這樣就能夠讓 TCP 重新發送最終的 ACK 以避免出現丟失的情況。重新發送最終的 ACK 並不是因為 TCP 重傳了 ACK，而是因為通訊另一方重傳了 FIN，客戶端經常回發送 FIN，因為它需要 ACK 的響應才能夠關閉連接，如果生存時間超過了 2MSL 的話，客戶端就會發送 RST，使服務端出錯。
我自己肝了六本 PDF，全網傳播超過10w+ ，微信搜索「程式設計師cxuan」關注公眾號後，在後台回復 cxuan ，領取全部 PDF，這些 PDF 如下
