今天我們將 從穩(wěn)定性角度深挖 TCP 協(xié)議的運(yùn)作機(jī)制 。

如今，大半個互聯(lián)網(wǎng)都建立在 TCP 協(xié)議之上，我們使用的 HTTP 協(xié)議、消息隊列、存儲、緩存，都需要用到 TCP 協(xié)議—— 這是因為 TCP 協(xié)議提供了可靠性 。

簡單來說，可靠性就是讓數(shù)據(jù)無損送達(dá)。但若是考慮到成本，就會變得非常復(fù)雜——因為還需要盡可能地提升吞吐量、降低延遲、減少丟包率。

TCP 協(xié)議具有很強(qiáng)的實用性，而可靠性又是 TCP 最核心的能力 。具體來說，從一個終端有序地發(fā)出多個數(shù)據(jù)包，經(jīng)過一個復(fù)雜的網(wǎng)絡(luò)環(huán)境，到達(dá)目的地的時候會變得無序，而可靠性要求數(shù)據(jù)恢復(fù)到原始的順序。這里先提出兩個問題：

• TCP 協(xié)議是如何恢復(fù)數(shù)據(jù)的順序的？
• 拆包和粘包的作用是什么？

那么帶著這兩個問題開始今天的學(xué)習(xí)。

TCP 的拆包和粘包

TCP數(shù)據(jù)發(fā)送

TCP 是一個傳輸層協(xié)議

TCP 發(fā)送數(shù)據(jù)的時候，往往不會將數(shù)據(jù)一次性發(fā)送

而是將數(shù)據(jù)拆分成很多個部分，然后再逐個發(fā)送。像下圖這樣：

同樣的，在目的地，TCP 協(xié)議又需要逐個接收數(shù)據(jù)。

請 思考，TCP 為什么不一次發(fā)送完所有的數(shù)據(jù)？比如我們要傳一個大小為 10M 的文件，對于應(yīng)用層而言，就是一次傳送完成的。而傳輸層的協(xié)議為什么不選擇將這個文件一次發(fā)送完呢？

這里有很多原因，

• 比如為了穩(wěn)定性，一次發(fā)送的數(shù)據(jù)越多，出錯的概率越大。
• 再比如說為了效率，網(wǎng)絡(luò)中有時候存在著并行的路徑，拆分?jǐn)?shù)據(jù)包就能更好地利用這些并行的路徑。
• 再有，比如發(fā)送和接收數(shù)據(jù)的時候，都存在著緩沖區(qū)。如下圖所示：

緩沖區(qū)是在內(nèi)存中開辟的一塊區(qū)域，目的是緩沖。因為大量的應(yīng)用頻繁地通過網(wǎng)卡收發(fā)數(shù)據(jù)，這個時候，網(wǎng)卡只能一個一個處理應(yīng)用的請求。當(dāng)網(wǎng)卡忙不過來的時候，數(shù)據(jù)就需要排隊，也就是將數(shù)據(jù)放入緩沖區(qū) 。如果每個應(yīng)用都隨意發(fā)送很大的數(shù)據(jù)，可能導(dǎo)致其他應(yīng)用實時性遭到破壞。

還有一些原因 比如內(nèi)存的最小分配單位是頁表，如果數(shù)據(jù)的大小超過一個頁表，可能會存在頁面置換問題，造成性能的損失。

總之，方方面面的原因： 在傳輸層封包不能太大 。

這種限制，往往是以緩沖區(qū)大小為單位的。也就是 TCP 協(xié)議，會將數(shù)據(jù)拆分成不超過緩沖區(qū)大小的一個個部分 。每個部分有一個獨(dú)特的名詞，叫作 TCP 段（TCP Segment） 。

在接收數(shù)據(jù)的時候，一個個 TCP 段又被重組成原來的數(shù)據(jù)。

像這樣， 數(shù)據(jù)經(jīng)過拆分，然后傳輸，然后在目的地重組，俗稱拆包 。所以拆包是將數(shù)據(jù)拆分成多個 TCP 段傳輸。

那么粘包是什么呢？有時候， 如果發(fā)往一個目的地的多個數(shù)據(jù)太小了，為了防止多次發(fā)送占用資源，TCP 協(xié)議有可能將它們合并成一個 TCP 段發(fā)送，在目的地再還原成多個數(shù)據(jù)，這個過程俗稱粘包。所以粘包是將多個數(shù)據(jù)合并成一個 TCP 段發(fā)送 。

TCP Segment

那么一個 TCP 段長什么樣子呢？下圖是一個 TCP 段的格式：

我們可以看到，TCP 的很多配置選項和數(shù)據(jù)粘在了一起，作為一個 TCP 段。

顯然， 把每一部分都記住似乎不太現(xiàn)實，先把其中最主要的部分理解。

TCP 協(xié)議就是依靠每一個 TCP 段工作的，所以你每認(rèn)識一個 TCP 的能力，幾乎都會找到在 TCP Segment 中與之對應(yīng)的字段 。接下來 認(rèn)識它們。

• Source Port/Destination Port 描述的是發(fā)送端口號和目標(biāo)端口號，代表發(fā)送數(shù)據(jù)的應(yīng)用程序和接收數(shù)據(jù)的應(yīng)用程序。比如 80 往往代表 HTTP 服務(wù)，22 往往是 SSH 服務(wù)……
• Sequence Number 和 Achnowledgment Number 是保證可靠性的兩個關(guān)鍵
• Data Offset 是一個偏移量。這個量存在的原因是 TCP Header 部分的長度是可變的，因此需要一個數(shù)值來描述數(shù)據(jù)從哪個字節(jié)開始。
• Reserved 是很多協(xié)議設(shè)計會保留的一個區(qū)域，用于日后擴(kuò)展能力。
• URG/ACK/PSH/RST/SYN/FIN 是幾個標(biāo)志位，用于描述 TCP 段的行為。也就是一個 TCP 封包到底是做什么用的

1）URG 代表這是一個緊急數(shù)據(jù)，比如遠(yuǎn)程操作的時候，用戶按下了 Ctrl+C，要求終止程序，這種請求需要緊急處理。

2）ACK 代表響應(yīng)， 所有的消息都必須有 ACK，這是 TCP 協(xié)議確保穩(wěn)定性的一環(huán)。

3）PSH 代表數(shù)據(jù)推送，也就是在傳輸數(shù)據(jù)的意思。

4）SYN 同步請求，也就是申請握手。

5）FIN 終止請求，也就是揮手。

特別說明一下：以上這 5 個標(biāo)志位，每個占了一個比特，可以混合使用。比如 ACK 和 SYN 同時為 1，代表同步請求和響應(yīng)被合并了。這也是 TCP 協(xié)議，為什么是三次握手的原因之一 。

• Window 也是 TCP 保證穩(wěn)定性并進(jìn)行流量控制的工具，后續(xù)會 TCP 的穩(wěn)定性：滑動窗口和流速控制是中詳細(xì)介紹。
• Checksum 是校驗和，用于校驗 TCP 段有沒有損壞。
• Urgent Pointer 指向最后一個緊急數(shù)據(jù)的序號（Sequence Number）。它存在的原因是：有時候緊急數(shù)據(jù)是連續(xù)的很多個段，所以需要提前告訴接收方進(jìn)行準(zhǔn)備。
• Options 中存儲了一些可選字段，比如接下來我們要討論的 MSS（Maximun Segment Size）。
• Padding 存在的意義是因為 Options 的長度不固定，需要 Pading 進(jìn)行對齊。

其實這個問題的本質(zhì)就好像兩個人在說話一樣，我們要確保他們說出去的話，和回答之間的順序。因為 TCP 是一個雙工的協(xié)議，兩邊可能會同時說話。所以聰明的 科學(xué)家想到了確定一句話的順序，需要兩個值去描述——也就是發(fā)送的字節(jié)數(shù)和接收的字節(jié)數(shù) 。

我們重新定義一下 Seq（如上圖所示），對于任何一個接收方，如果知道了發(fā)送者發(fā)送某個 TCP 段時，已經(jīng)發(fā)送了多少字節(jié)的數(shù)據(jù)，那么就可以確定發(fā)送者發(fā)送數(shù)據(jù)的順序。

但是這里有一個問題。如果接收方也向發(fā)送者發(fā)送了數(shù)據(jù)請求（或者說雙方在對話），接收方就不知道發(fā)送者發(fā)送的數(shù)據(jù)到底對應(yīng)哪一條自己發(fā)送的數(shù)據(jù)了。

舉個例子：下面 A 和 B 的對話中，我們可以確定他們彼此之間接收數(shù)據(jù)的順序。但是無法確定數(shù)據(jù)之間的關(guān)聯(lián)關(guān)系，所以只有 Sequence Number 是不夠的。

A：今天天氣好嗎？

A：今天你開心嗎？

B：開心

B：天氣不好

人類很容易理解這幾句話的順序，但是對于機(jī)器來說就需要特別的標(biāo)注。因此我們還需要另一個數(shù)據(jù)，就是每個 TCP 段發(fā)送時，發(fā)送方已經(jīng)接收了多少數(shù)據(jù)。用 Acknowledgement Number 表示，下面簡寫為 ACK。

下圖中，終端發(fā)送了三條數(shù)據(jù)，并且接收到四條數(shù)據(jù)，通過觀察，根據(jù)接收到的數(shù)據(jù)中的 Seq 和 ACK，將發(fā)送和接收的數(shù)據(jù)進(jìn)行排序。

例如上圖中， **發(fā)送方發(fā)送了 100 字節(jié)的數(shù)據(jù)，而接收到的（Seq = 0 和 Seq =100）的兩個封包，都是針對發(fā)送方（Seq = 0）這個封包的。發(fā)送 100 個字節(jié)，所以接收到的 ACK 剛好是 100。說明（Seq= 0 和 Seq= 100）這兩個封包是針對接收到第 100 個字節(jié)數(shù)據(jù)后，發(fā)送回來的。這樣就確定了整體的順序** 。

注意，無論 Seq 還是 ACK，都是針對“對方”而言的。是對方發(fā)送的數(shù)據(jù)和對方接收到的數(shù)據(jù) 。我們在實際的工作當(dāng)中，可以通過 Whireshark 調(diào)試工具觀察兩個 TCP 連接的 Seq和 ACK。

MSS（Maximun Segment Size）

接下來，我們討論下 MSS，它也是面試經(jīng)常會問到的一個 TCP Header 中的可選項（Options）， 這個可選項控制了 TCP 段的大小，它是一個協(xié)商字段（Negotiate） 。協(xié)議是雙方都要遵循的標(biāo)準(zhǔn)，因此配置往往不能由單方?jīng)Q定，需要雙方協(xié)商。

TCP 段的大?。∕SS）涉及發(fā)送、接收緩沖區(qū)的大小設(shè)置，雙方實際發(fā)送接收封包的大小，對拆包和粘包的過程有指導(dǎo)作用，因此需要雙方去協(xié)商 。

如果這個字段設(shè)置得非常大，就會帶來一些影響。

• 首先對方可能會拒絕，作為服務(wù)的提供方，你可能不會愿意接收太大的 TCP 段。因為大的 TCP 段，會降低性能，比如內(nèi)存使用的性能 。還有就是資源的占用。一個用戶占用服務(wù)器太多的資源，意味著其他的用戶就需要等待或者降低他們的服務(wù)質(zhì)量
• 其次，支持 TCP 協(xié)議工作的 IP 協(xié)議，工作效率會下降

TCP 協(xié)議不肯拆包，IP 協(xié)議就需要拆出大量的包。那么 IP 協(xié)議為什么需要拆包呢？這是因為在網(wǎng)絡(luò)中，每次能夠傳輸?shù)臄?shù)據(jù)不可能太大，這受限于具體的網(wǎng)絡(luò)傳輸設(shè)備，也就是物理特性。但是 IP 協(xié)議，拆分太多的封包并沒有意義。因為可能會導(dǎo)致屬于同個 TCP 段的封包被不同的網(wǎng)絡(luò)路線傳輸，這會加大延遲。同時，拆包，還需要消耗硬件和計算資源。

那是不是 MSS 越小越好呢？ MSS 太小的情況下，會浪費(fèi)傳輸資源（降低吞吐量）。因為數(shù)據(jù)被拆分之后，每一份數(shù)據(jù)都要增加一個頭部。如果 MSS 太小，那頭部的數(shù)據(jù)占比會上升，這讓吞吐量成為一個災(zāi)難。所以在使用的過程當(dāng)中，MSS 的配置，往往都是一個折中的方案 。

不要去猜想什么樣的方案是最合理的，而是要嘗試去用實驗證明它，一切都要用實驗依據(jù)說話。

Question : TCP 協(xié)議是如何恢復(fù)數(shù)據(jù)的順序的，TCP 拆包和粘包的作用是什么？

Answer:

TCP 拆包的作用是將任務(wù)拆分處理，降低整體任務(wù)出錯的概率，以及減小底層網(wǎng)絡(luò)處理的壓力。拆包過程需要保證數(shù)據(jù)經(jīng)過網(wǎng)絡(luò)的傳輸，又能恢復(fù)到原始的順序。這中間，需要數(shù)學(xué)提供保證順序的理論依據(jù)。 TCP 利用（發(fā)送字節(jié)數(shù)、接收字節(jié)數(shù)）的唯一性來確定封包之間的順序關(guān)系 。

粘包是為了防止數(shù)據(jù)量過小，導(dǎo)致大量的傳輸，而將多個 TCP 段合并成一個發(fā)送。