TCP 包頭格式

老規矩，咱們先來看看 TCP 頭的格式。

從上面這個圖可以看出，它比 UDP 要復雜的多。而復雜的地方，也正是它為了解決 UDP 存在的問題所必需的字段。

首先，源端口號和目標端口號是兩者都有，不可缺少的字段。

接下來是包的序號。給包編號就是為了解決亂序的問題。老大哥做事，穩重為主，一件件來，面臨再復雜的情況，也臨危不亂。

除了發送端需要給包編號外，接收方也會回復確認序號。做事靠譜，答應了就要做到，暫時做不到也要給個回復。

這里要注意的是，TCP 是個老大哥沒錯，但不能說他一定會保證傳輸準確無誤的完成。從 IP 層面來講，如果網絡的確那么差，是沒有任何可靠性保證的，即使 TCP 老大哥再穩，他也管不了 IP 層丟包，他只能盡可能的保證在他的層面上的可靠性。

然后是一些狀態位。有以下常見狀態位：

SYN（Synchronize Sequence Numbers，同步序列編號）：發起一個連接

ACK（Acknowledgement，確認字符）：回復

RST（Connection reset）：重新連接

FIN：結束連接

從這些狀態位就可以看出，TCP 基于“性惡論”，警覺性就很高，不像 UDP 和小朋友似的，隨便一個不認識的小朋友都能玩到一起，他與別人的信任要經過多次交互才能建立。

還有一個窗口大小。這個是 TCP 用來進行流量控制的。通信雙方各聲明一個窗口，標識自己當前的處理能力，讓發送端別發送的太快，要不然撐死接收端。也不能發送的太慢，要不然就餓死接收端了。

根據上述對 TCP 頭的分析，我們知道對于 TCP 協議要重點關注以下幾個問題：

• 順序問題，穩重不亂；
• 丟包問題，承諾靠譜；
• 連接偉豪，有始有終；
• 流量控制，把握分寸；
• 擁塞控制，知進知退。

TCP 的三次握手

了解完 TCP 頭，我們就來看下 TCP 建立連接的過程，這就是著名的“三次握手”。

三次握手，過程是這樣子的：

A：你好，我是 A（SYN）。

B：你好 A，我是 B（SYN，ACK）。

A：你好 B（ACK 的 ACK）。

著重記憶上述過程，后續很多分析都是基于這個過程來的。

記得剛接觸三次握手的時候，就一直很納悶，為啥一定要三次？兩次不行嗎？四次不行嗎？然后很多人就解釋，如果是兩次，就怎樣怎樣，四次，又怎樣怎樣？但這其實都是從結果推原因，沒有說明本質。

我們應該知道，握手是為了建立穩定的連接，這個是最終目的。而要達到這個目的，就要通信雙方的交互形成一個確認的閉環。

拿上述 A、B 通信的例子來看，A 給 B 發信息，B 要告訴 A 他收到信息了。這時候，算是一個確認閉環嗎？明顯不是，因為 B 沒有收到來自 A 的確認信息。

所以，要達到我們上述的目標，還要 A 給 B 一個確認信息，這樣就形成了一個確認閉環。

A 給 B 的確認信息發出后，遇到網絡不好的情況，也會出現丟包的情況。按理來說，還應該有個回應，但是，我們發現，好像這樣下去就沒玩沒了啦。

所以，我們說，只要通信雙方形成一個確認閉環后，就認為連接已建立。一旦連接建立，A 會馬上發送數據，而 A 發送數據，后續的很多問題都得到了解決。

例如 A 發給 B 的確認消息丟了，當 A 后續發送的數據到達的時候，B 可以認為這個連接已經建立。如果 B 直接掛了，A 發送的數據就會報錯，說 B 不可達，這樣，A 也知道 B 出事情了。

三次握手除了通信雙方建立連接外，主要還是為了溝通 TCP 包的序號問題。

A 要告訴 B，我發起的包的序號起始是從哪個號開始的，B 也要告訴 A，B 發起的包的序號的起始號。

TCP 包的序號是會隨時間變化的，可以看成一個 32 位的計數器，每 4ms 加一。計算一下，這樣到出現重復號，需要 4 個多小時。但是，4 個小時后，還沒到達目的地的包早就死翹翹了。這是因為 IP 包頭里的 TTL（生存時間）。

為什么序號不能從 1 開始呢？因為這樣會很容易出現沖突。

例如，A 連上 B 之后，發送了 1、2、3 三個包，但是發送 3 的時候，中間丟了，或者繞路了，于是重新發送，后來 A 掉線了，重新連上 B 后，序號又從 1 開始，然后發送 2，但是壓根沒想發送 3，而如果上次繞路的那個 3 剛好又回來了，發給了 B ，B 自然就認為，這就是下一包，于是發生了錯誤。

就這樣，雙方歷經千辛萬苦，終于建立了連接。前面也說過，為了維護這個連接，雙方都要維護一個狀態機，在連接建立的過程中，雙方的狀態變化時序圖就像下面這樣：

整體過程是：

客戶端和服務端都處于 CLOSED 狀態；

服務端主動監聽某個端口，處于 LISTEN 狀態；

客戶端主動發起連接 SYN，處于 SYN-SENT 狀態。

服務端收到客戶端發起的連接，返回 SYN，并且 ACK 客戶端的 SYN，處于 SYN-RCVD 狀態；

客戶端收到服務端發送的 SYN 和 ACK 之后，發送 ACK 的 ACK，處于 ESTABLISHED 狀態；

服務端收到 ACK 的 ACK 之后，處于 ESTABLISHED 狀態。

TCP 的四次揮手

說完了連接，接下來就來了解下 TCP 的“再見模式”。這也常被稱為四次揮手。

還拿 A 和 B 舉例，揮手過程：

A：B 啊，我不想和你玩了。

B：哦，你不想玩了啊，我知道了。這個時候，還只是 A 不想玩了，就是說 A 不會再發送數據，但是 B 此時還沒做完自己的事情，還是可以發送數據的，所以此時的 B 處于半關閉狀態。

B：A啊，好吧，我也不想和你玩了，拜拜。

A：好的，拜拜。

這樣這個連接就關閉了。看起來過程很順利，是的，這是通信雙方“和平分手”的場面。

A 開始說“不玩了”，B 說“知道了”，這個回合，是沒什么問題的，因為在此之前，雙方還處于合作的狀態。

如果 A 說“不玩了”，沒有收到回復，那么 A 會重新發送“不玩了”。但是這個回合結束之后，就很可能出現異常情況了，因為有一方率先撕破臉。這種撕破臉有兩種情況。

一種情況是，A 說完“不玩了”之后，A 直接跑路，這是會有問題的，因為 B 還沒有發起結束，而如果 A 直接跑路，B 就算發起結束，也得不到回答，B 就就不知道該怎么辦了。

另一種情況是，A 說完“不玩了”，B 直接跑路。這樣也是有問題的，因為 A 不知道 B 是還有事情要處理，還是過一會發送結束。

為了解決這些問題，TCP 專門設計了幾個狀態來處理這些問題。接下來，我們就來看看斷開連接時的狀態時序圖。

整體過程是：

A 說“不玩了”，就進入 FIN_WAIT_1 狀態；

B 收到 “A 不玩”的消息后，回復“知道了”，就進入 CLOSE_WAIT 狀態；

A 收到“B 說知道了”，進入 FIN_WAIT_2 狀態。這時候，如果B 直接跑路，則 A 將永遠在這個狀態。TCP 協議里面并沒有對這個狀態的處理，但是 Linux 有，可以調整 tcp_fin_timeout 這個參數，設置一個超時時間；

B 沒有跑路，發送了“B 也不玩了”的消息，處于 LAST_ACK 狀態；

A 收到“B 說不玩了”的消息，回復“A 知道 B 也不玩了”的消息后，從 FINE_WAIT_2 狀態結束。

最后一個步驟里，如果 A 直接跑路了，也會出現問題。因為 A 的最后一個回復，B 如果沒有收到的話就會重復第 4 步，但是因為 A 已經跑路了，所以 B 會一直重復第 4 步。

因此，TCP 協議要求 A 最后要等待一段時間，這個等待時間是 TIME_WAIT，這個時間要足夠長，長到如果 B 沒收到 A 的回復，B 重發給 A，A 的回復要有足夠時間到達 B。

A 直接跑路還有一個問題是，A 的端口就空出來了，但是 B 不知道，B 原來發過的很多包可能還在路上，如果 A 的端口被新的應用占用了，這個新的應用會受到上個連接中 B 發過來的包，雖然序列號是重新生成的，但是這里會有一個雙保險，防止產生混亂。因此也需要 A 等待足夠長的時間，等到 B 發送的所有未到的包都“死翹翹”，再空出端口。

這個等待的時間設為 2MSL，MSL 是Maximum Segment Lifetime，即報文最大生存時間。它是任何報文再網絡上存在的最長時間，超過這個時間的報文就會被丟棄。

因為 TCP 報文基于 IP 協議，而 IP 頭中有一個 TTL 域，是 IP 數據報可以經過的最大路有數，每經過一個處理他的路由器，此值就減 1，當此值為 0 時，數據報就被丟棄，同時發送 ICMP 報文通知源主機。協議規定 MSL 為 2 分鐘，實際應用中常用的是 30 秒、1分鐘和 2 分鐘等。

還有一種異常情況，B 超過了 2MS 的時間，依然沒有收到它發的 FIN 的 ACK。按照 TCP 的原理，B 當然還會重發 FIN，這個時候 A 再收到這個包之后，就表示，我已經等你這么久，算是仁至義盡了，再來的數據包我就不認了，于是直接發送 RST，這樣 B 就知道 A 跑路了。

TCP 狀態機

將連接建立和連接斷開的兩個時序狀態圖綜合起來，就是著名的TCP 狀態機。我們可以將這個狀態機和時序狀態機對照看，就會更加明了。

圖中加黑加粗部分，是上面說到的主要流程，相關說明：

阿拉伯數字序號：建立連接順序；

大寫中文數字序號：斷開連接順序；

加粗實線：客戶端 A 的狀態變遷；

加粗虛線：服務端 B 的狀態變遷；

總結

TCP 包頭很復雜，主要關注 5 個問題。順序問題、丟包問題、連接維護、流量控制、擁塞控制；

建立連接三次握手，斷開連接四次揮手，狀態圖要牢記。
編輯：hfy