最近把個人部落格搭建好了，連結在這裡：tobe的囈語，文章會先在部落格和公眾號更新~ 大家多多收藏啊

上一次講了 UDP 協議，從這次開始，就要講 TCP 協議了，因為 TCP 協議涉及到的東西很多，一篇文章概括不完，所以我把 TCP 協議的內容分成好幾個部分，逐個擊破。

TCP 報文段結構

一談到 TCP 協議，大家最先想到的詞就是「面向連線」和「可靠」。沒錯，TCP 協議的設計就是為了能夠在客戶端和伺服器之間建立起一個可靠連線。

在講連線過程之前，我們先來看看 TCP 的報文段結構，通過這個結構，我們可以知道 TCP 能夠提供什麼資訊：

這裡有幾點是需要注意的：

• TCP 協議需要一個四元組（源IP，源埠，目的IP，目的埠）來確定連線，這要和 UDP 協議區分開。多說一句，IP 地址位於 IP 報文段，TCP 報文段是不含 IP 地址資訊的。
• 基本 TCP 頭部的長度是 20 位元組，但是由於「選項」的長度是不確定的，所以需要「首部長度」欄位明確給出頭部長度。這裡要注意的是，首部長度欄位的單位是 32bit，也就是 4 位元組，所以該欄位的最小值是 5。
• 標橙色的欄位（確認序號，接收視窗大小，ECE，ACK）用於「回覆」對方，舉個例子，伺服器收到對方的資料包後，不單獨發一個數據包來回應，而是稍微等一下，把確認資訊附在下一個發往客戶端的資料幀上，也就是捎帶技術。
• 視窗大小是一個 16 位無符號數，也就是說視窗被限制在了 65535 位元組，也就限制了 TCP 的吞吐量效能，這對一些高速以及高延遲的網路不太友好（可以想想為什麼）。所幸 TCP 額外提供了視窗縮放（Window Scale）選項，允許對這個值進行縮放。

下面是 8 個標誌位的含義，有的協議比較舊，可能沒有前兩個標誌位：

標誌位雖然很多，但是如果放到具體場景裡來看的話，就很容易理解他們的作用了。

TCP 三次握手

三次握手就是為了在客戶端和伺服器間建立連線，這個過程並不複雜，但裡面有很多細節需要注意。

這張圖就是握手的過程，可以看到客戶端與伺服器之間一共傳遞了三次訊息，這三次握手其實就是兩臺機器之間互相確認狀態，我們來一點一點看。

第一次握手

首先是客戶端發起連線，第一個資料包將 SYN 置位（也就是 SYN = 1），表明這個資料包是 SYN 報文段（也被稱為段 1）。這一次傳送的目的是告訴伺服器，自己的初始序列號是 client_isn

段 1 裡最需要注意的就是這個client_isn ，也就是初始序列號。「RFC0793¹」指出:

When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32 bit ISN. The generator is bound to a (possibly fictitious) 32 bit clock whose low order bit is incremented roughly every 4 microseconds. Thus, the ISN cycles approximately every 4.55 hours.

翻譯過來就是，初始序列號是一個 32 位的（虛擬）計數器，而且這個計數器每 4 微秒加 1，也就是說，ISN 的值每 4.55 小時迴圈一次。這個舉措是為了防止序列號重疊。

但即使這樣還是會有安全隱患——因為初始 ISN 仍然是可預測的，惡意程式可能會分析 ISN ，然後根據先前使用的 ISN 預測後續 TCP 連線的 ISN，然後進行攻擊，一個著名的例子就是「The Mitnick attack²」 。這裡摘一段原文：

Mitnick sent SYN request to X-Terminal and received SYN/ACK response. Then he sent RESET response to keep the X-Terminal from being filled up. He repeated this for twenty times. He found there is a pattern between two successive TCP sequence numbers. It turned out that the numbers were not random at all. The latter number was greater than the previous one by 128000.

所以為了讓初始序列號更難預測，現代系統常常使用半隨機的方法選擇初始序列號，詳細的方法就不在這裡展開了。

第二次握手

當伺服器接收到客戶端的連線請求後，就會向客戶端傳送 ACK 表示自己收到了連線請求，而且，伺服器還得把自己的初始序列號告訴客戶端，這其實是兩個步驟，但是傳送一個數據包就可以完成，用的就是前面說的捎帶技術。圖裡的 ACK = client_isn + 1 是指確認號欄位的值，要注意和 ACK 標誌位區分開。

ACK 欄位其實也有不少需要注意的點，不過這個跟滑動視窗一塊講比較直觀，這裡就先不提了。

這裡重點強調一下，當一個 SYN 報文段到達的時候，伺服器會檢查處於 SYN_RCVD 狀態的連線數目是否超過了 tcp_max_syn_backlog 這個引數，如果超過了，伺服器就會拒絕連線。當然，這個也會被黑客所利用，「SYN Flood」就是個很好的例子。因為伺服器在回覆 SYN-ACK 後，會等待客戶端的 ACK ，如果一定時間內沒有收到，認為是丟包了，就重發 SYN-ACK，重複幾次後才會斷開這個連線，linux 可能要一分鐘才會斷開，所以攻擊者如果製造一大批 SYN 請求而不回覆，伺服器的 SYN 佇列很快就被耗盡，這一段時間裡，正常的連線也會得不到響應。

伺服器的這種狀態稱為靜默（muted）。為了抵禦 SYN Flood 攻擊，伺服器可以採用「SYN cookies」，這種思想是，當 SYN 到達時，並不直接為其分配記憶體，而是把這條連線的資訊編碼並儲存在 SYN-ACK 報文段的序列號欄位，如果客戶端回覆了，伺服器再從 ACK 欄位裡解算出 SYN 報文的重要資訊（有點黑魔法的感覺了），驗證成功後才為該連線分配記憶體。這樣，伺服器不會響應攻擊者的請求，正常連線則不會受到影響。

但 SYN cookies 本身有一些限制，並不適合作為預設選項，有興趣可以自行 Google。

第三次握手

這是建立 TCP 連線的最後一步，經過前兩次握手，客戶端（伺服器）已經知道對方的滑動視窗大小，初始序列號等資訊了，這不就完了嗎？為什麼還要第三次握手？

這是因為伺服器雖然把資料包發出去了，但他還不知道客戶端是否收到了這個包，所以伺服器需要等待客戶端返回一個 ACK，表明客戶端收到了資料，至此，連線完成。

連線建立後，進入傳輸資料的階段，這裡就涉及到很多很多技術，我會另寫文章。

四次揮手

有了三次握手的基礎，四次揮手就比較容易理解了：

四次揮手的過程其實很簡單，就是伺服器和客戶端互相傳送 FIN 和 ACK 報文段，告知對方要斷開連線。

四次揮手裡值得關注的一點就是 TIME_WAIT 狀態，也就是說主動關閉連線的一方，即使收到了對方的 FIN 報文，也還要等待 2MSL 的時間才會徹底關閉這條連線。（這裡面的 MSL 指的是最大段生成期，指的是報文段在網路中被允許存在的最長時間。）可為什麼不直接關閉連線呢？

一個原因是，第四次揮手的 ACK 報文段不一定到達了伺服器，為了不讓伺服器一直處於 LAST_ACK 狀態（伺服器會重發 FIN，直到收到 ACK），客戶端還得等一會兒，看看是否需要重發。假如真的丟包了，伺服器傳送 FIN ，這個 FIN 報文到達客戶端時不會超過 2MSL（一來一回最多 2MSL），這時候客戶端這邊的 TCP 還沒關掉，還能重發 ACK。

另一個原因是，經過 2MSL 之後，網路中與該連線相關的包都已經消失了，不會干擾新連線。我們來看一個例子：假如客戶端向伺服器建立了新的連線，舊連線中某些延遲的資料堅持到了新連線建立完畢，而且序列號剛好還在滑動視窗內，伺服器就誤把它當成新連線的資料包接收，如下圖所示：

2MSL 機制就避免了這種情況。

關於 TIME_WAIT 還有很多有意思的地方，我覺得可以單獨再寫一篇文章了，這裡就不再多說。

感覺寫的有點亂了，因為 TCP 的知識確實是有點多，希望各位讀者不要介意。