在TCP編程中，我們使用協(xié)議(protocol)來解決粘包和拆包問題。本文將詳解TCP粘包和半包產(chǎn)生的原因，以及如何通過協(xié)議來解決粘包、拆包問題。讓你知其然，知其所以然。

[[279480]]

1 TCP粘包、拆包圖解

由于TCP傳輸協(xié)議面向流的，沒有消息保護邊界。一方發(fā)送的多個報文可能會被合并成一個大的報文進行傳輸，這就是粘包;也可能發(fā)送的一個報文，可能會被拆分成多個小報文，這就是拆包。

下圖演示了粘包、拆包的過程，client分別發(fā)送了兩個數(shù)據(jù)包D1和D2給server，server端一次讀取到字節(jié)數(shù)是不確定的，因此可能可能存在以下幾種情況：

關于這幾種情況說明如下：

server端分兩次讀取到了兩個獨立的數(shù)據(jù)包，分別是D1和D2，沒有粘包和拆包

server一次接受到了兩個數(shù)據(jù)包，D1和D2粘合在一起，稱之為TCP粘包

server分兩次讀取到了數(shù)據(jù)包，第一次讀取到了完整的D1包和D2包的部分內(nèi)容，第二次讀取到了D2包的剩余內(nèi)容，這稱之為TCP拆包

Server分兩次讀取到了數(shù)據(jù)包，第一次讀取到了D1包的部分內(nèi)容D1_1，第二次讀取到了D1包的剩余部分內(nèi)容D1_2和完整的D2包。

由于發(fā)送方發(fā)送的數(shù)據(jù)，可能會發(fā)生粘包、拆包的情況。這樣，對于接收端就難于分辨出來了，因此必須提供科學的機制來解決粘包、拆包問題，這就是協(xié)議的作用。

在介紹協(xié)議之前，我們先了解一下粘包、拆包產(chǎn)生的原因。

2 粘包、拆包產(chǎn)生的原因

粘包、拆包問題的產(chǎn)生原因筆者歸納為以下3種：

• socket緩沖區(qū)與滑動窗口
• MSS/MTU限制
• Nagle算法

2.1 socket緩沖區(qū)與滑動窗口

每個TCP socket在內(nèi)核中都有一個發(fā)送緩沖區(qū)(SO_SNDBUF )和一個接收緩沖區(qū)(SO_RCVBUF)，TCP的全雙工的工作模式以及TCP的滑動窗口便是依賴于這兩個獨立的buffer的填充狀態(tài)。

SO_SNDBUF：

進程發(fā)送的數(shù)據(jù)的時候假設調(diào)用了一個send方法，最簡單情況(也是一般情況)，將數(shù)據(jù)拷貝進入socket的內(nèi)核發(fā)送緩沖區(qū)之中，然后send便會在上層返回。換句話說，send返回之時，數(shù)據(jù)不一定會發(fā)送到對端去(和write寫文件有點類似)，send僅僅是把應用層buffer的數(shù)據(jù)拷貝進socket的內(nèi)核發(fā)送buffer中。

SO_RCVBUF：

把接受到的數(shù)據(jù)緩存入內(nèi)核，應用進程一直沒有調(diào)用read進行讀取的話，此數(shù)據(jù)會一直緩存在相應socket的接收緩沖區(qū)內(nèi)。再啰嗦一點，不管進程是否讀取socket，對端發(fā)來的數(shù)據(jù)都會經(jīng)由內(nèi)核接收并且緩存到socket的內(nèi)核接收緩沖區(qū)之中。read所做的工作，就是把內(nèi)核緩沖區(qū)中的數(shù)據(jù)拷貝到應用層用戶的buffer里面，僅此而已。

滑動窗口：

TCP連接在三次握手的時候，會將自己的窗口大小(window size)發(fā)送給對方，其實就是SO_RCVBUF指定的值。之后在發(fā)送數(shù)據(jù)的時，發(fā)送方必須要先確認接收方的窗口沒有被填充滿，如果沒有填滿，則可以發(fā)送。

每次發(fā)送數(shù)據(jù)后，發(fā)送方將自己維護的對方的window size減小，表示對方的SO_RCVBUF可用空間變小。

當接收方處理開始處理SO_RCVBUF 中的數(shù)據(jù)時，會將數(shù)據(jù)從socket 在內(nèi)核中的接受緩沖區(qū)讀出，此時接收方的SO_RCVBUF可用空間變大，即window size變大，接受方會以ack消息的方式將自己最新的window size返回給發(fā)送方，此時發(fā)送方將自己的維護的接受的方的window size設置為ack消息返回的window size。

此外，發(fā)送方可以連續(xù)的給接受方發(fā)送消息，只要保證對方的SO_RCVBUF空間可以緩存數(shù)據(jù)即可，即window size>0。當接收方的SO_RCVBUF被填充滿時，此時window size=0，發(fā)送方不能再繼續(xù)發(fā)送數(shù)據(jù)，要等待接收方ack消息，以獲得最新可用的window size。

2.2 MSS/MTU分片

MTU (Maxitum Transmission Unit,最大傳輸單元)是鏈路層對一次可以發(fā)送的最大數(shù)據(jù)的限制。MSS(Maxitum Segment Size,最大分段大小)是TCP報文中data部分的最大長度，是傳輸層對一次可以發(fā)送的最大數(shù)據(jù)的限制。

要了解MSS/MTU，首先需要回顧一下TCP/IP五層網(wǎng)絡模型模型。

數(shù)據(jù)在傳輸過程中，每經(jīng)過一層，都會加上一些額外的信息：

• 應用層：只關心發(fā)送的數(shù)據(jù)DATA，將數(shù)據(jù)寫入socket在內(nèi)核中的緩沖區(qū)SO_SNDBUF即返回，操作系統(tǒng)會將SO_SNDBUF中的數(shù)據(jù)取出來進行發(fā)送。
• 傳輸層：會在DATA前面加上TCP Header(20字節(jié))
• 網(wǎng)絡層：會在TCP報文的基礎上再添加一個IP Header，也就是將自己的網(wǎng)絡地址加入到報文中。IPv4中IP Header長度是20字節(jié)，IPV6中IP Header長度是40字節(jié)。
• 鏈路層：加上Datalink Header和CRC。會將SMAC(Source Machine，數(shù)據(jù)發(fā)送方的MAC地址)，DMAC(Destination Machine，數(shù)據(jù)接受方的MAC地址 )和Type域加入。SMAC+DMAC+Type+CRC總長度為18字節(jié)。
• 物理層：進行傳輸

在回顧這個基本內(nèi)容之后，再來看MTU和MSS。MTU是以太網(wǎng)傳輸數(shù)據(jù)方面的限制，每個以太網(wǎng)幀最大不能超過1518bytes。刨去以太網(wǎng)幀的幀頭(DMAC+SMAC+Type域)14Bytes和幀尾(CRC校驗)4Bytes，那么剩下承載上層協(xié)議的地方也就是Data域最大就只能有1500Bytes這個值 我們就把它稱之為MTU。

MSS是在MTU的基礎上減去網(wǎng)絡層的IP Header和傳輸層的TCP Header的部分，這就是TCP協(xié)議一次可以發(fā)送的實際應用數(shù)據(jù)的最大大小。

MSS = MTU(1500) -IP Header(20 or 40)-TCP Header(20) 

由于IPV4和IPV6的長度不同，在IPV4中，以太網(wǎng)MSS可以達到1460byte;在IPV6中，以太網(wǎng)MSS可以達到1440byte。

發(fā)送方發(fā)送數(shù)據(jù)時，當SO_SNDBUF中的數(shù)據(jù)量大于MSS時，操作系統(tǒng)會將數(shù)據(jù)進行拆分，使得每一部分都小于MSS，也形成了拆包，然后每一部分都加上TCP Header，構(gòu)成多個完整的TCP報文進行發(fā)送，當然經(jīng)過網(wǎng)絡層和數(shù)據(jù)鏈路層的時候，還會分別加上相應的內(nèi)容。

另外需要注意的是：對于本地回環(huán)地址(lookback)不需要走以太網(wǎng)，所以不受到以太網(wǎng)MTU=1500的限制。linux服務器上輸入ifconfig命令，可以查看不同網(wǎng)卡的MTU大小，如下：

上圖顯示了2個網(wǎng)卡信息：

• eth0需要走以太網(wǎng)，所以MTU是1500;
• lo是本地回環(huán)，不需要走以太網(wǎng)，所以不受1500的限制。

2.3 Nagle算法

TCP/IP協(xié)議中，無論發(fā)送多少數(shù)據(jù)，總是要在數(shù)據(jù)(DATA)前面加上協(xié)議頭(TCP Header+IP Header)，同時，對方接收到數(shù)據(jù)，也需要發(fā)送ACK表示確認。

即使從鍵盤輸入的一個字符，占用一個字節(jié)，可能在傳輸上造成41字節(jié)的包，其中包括1字節(jié)的有用信息和40字節(jié)的首部數(shù)據(jù)。這種情況轉(zhuǎn)變成了4000%的消耗，這樣的情況對于重負載的網(wǎng)絡來是無法接受的。稱之為"糊涂窗口綜合征"。

為了盡可能的利用網(wǎng)絡帶寬，TCP總是希望盡可能的發(fā)送足夠大的數(shù)據(jù)。(一個連接會設置MSS參數(shù)，因此，TCP/IP希望每次都能夠以MSS尺寸的數(shù)據(jù)塊來發(fā)送數(shù)據(jù))。Nagle算法就是為了盡可能發(fā)送大塊數(shù)據(jù)，避免網(wǎng)絡中充斥著許多小數(shù)據(jù)塊。

Nagle算法的基本定義是任意時刻，最多只能有一個未被確認的小段。 所謂“小段”，指的是小于MSS尺寸的數(shù)據(jù)塊，所謂“未被確認”，是指一個數(shù)據(jù)塊發(fā)送出去后，沒有收到對方發(fā)送的ACK確認該數(shù)據(jù)已收到。

Nagle算法的規(guī)則：

1. 如果SO_SNDBUF中的數(shù)據(jù)長度達到MSS，則允許發(fā)送;
2. 如果該SO_SNDBUF中含有FIN，表示請求關閉連接，則先將SO_SNDBUF中的剩余數(shù)據(jù)發(fā)送，再關閉;
3. 設置了TCP_NODELAY=true選項，則允許發(fā)送。TCP_NODELAY是取消TCP的確認延遲機制，相當于禁用了Negale 算法。正常情況下，當Server端收到數(shù)據(jù)之后，它并不會馬上向client端發(fā)送ACK，而是會將ACK的發(fā)送延遲一段時間(假一般是40ms)，它希望在t時間內(nèi)server端會向client端發(fā)送應答數(shù)據(jù)，這樣ACK就能夠和應答數(shù)據(jù)一起發(fā)送，就像是應答數(shù)據(jù)捎帶著ACK過去。當然，TCP確認延遲40ms并不是一直不變的，TCP連接的延遲確認時間一般初始化為最小值40ms，隨后根據(jù)連接的重傳超時時間(RTO)、上次收到數(shù)據(jù)包與本次接收數(shù)據(jù)包的時間間隔等參數(shù)進行不斷調(diào)整。另外可以通過設置TCP_QUICKACK選項來取消確認延遲。
4. 未設置TCP_CORK選項時，若所有發(fā)出去的小數(shù)據(jù)包(包長度小于MSS)均被確認，則允許發(fā)送;
5. 上述條件都未滿足，但發(fā)生了超時(一般為200ms)，則立即發(fā)送。

3 通信協(xié)議

在了解了粘包、拆包產(chǎn)生的原因之后，現(xiàn)在來分析接收方如何對此進行區(qū)分。道理很簡單，如果存在不完整的數(shù)據(jù)(拆包)，則需要繼續(xù)等待數(shù)據(jù)，直至可以構(gòu)成一條完整的請求或者響應。

通過定義通信協(xié)議(protocol)，可以解決粘包、拆包問題。協(xié)議的作用就定義傳輸數(shù)據(jù)的格式。這樣在接受到的數(shù)據(jù)的時候：

如果粘包了，就可以根據(jù)這個格式來區(qū)分不同的包

如果拆包了，就等待數(shù)據(jù)可以構(gòu)成一個完整的消息來處理。

3.1 定長協(xié)議

定長協(xié)議：顧名思義，就是指定一個報文的必須具有固定的長度。例如，我們規(guī)定每3個字節(jié)，表示一個有效報文，如果我們分4次總共發(fā)送以下9個字節(jié)：

+---+----+------+----+ 
  | A | BC | DEFG | HI | 
  +---+----+------+----+ 

那么根據(jù)協(xié)議，我們可以判斷出來，這里包含了3個有效的請求報文，如下：

+-----+-----+-----+ 
   | ABC | DEF | GHI | 
   +-----+-----+-----+ 

在定長協(xié)議中：

• 發(fā)送方，必須保證發(fā)送報文長度是固定的。如果報文字節(jié)長度不能滿足條件，如規(guī)定長度是1024字節(jié)，但是實際需要發(fā)送的內(nèi)容只有900個字節(jié)，那么不足的部分可以補充0。因此定長協(xié)議可能會浪費帶寬。
• 接收方，每讀取到固定長度的內(nèi)容時，則認為讀取到了一個完整的報文。

提示：Netty中提供了FixedLengthFrameDecoder，支持把固定的長度的字節(jié)數(shù)當做一個完整的消息進行解碼

3.2 特殊字符分隔符協(xié)議

在包尾部增加回車或者空格符等特殊字符進行分割 。例如，按行解析，遇到字符\n、\r\n的時候，就認為是一個完整的數(shù)據(jù)包。對于以下二進制字節(jié)流：

+--------------+ 
   | ABC\nDEF\r\n | 
   +--------------+ 

那么根據(jù)協(xié)議，我們可以判斷出來，這里包含了2個有效的請求報文

+-----+-----+ 
   | ABC | DEF | 
   +-----+-----+ 

在特殊字符分隔符協(xié)議中：

• 發(fā)送方，需要在發(fā)送一個報文時，需要在報文尾部添加特殊分割符號;
• 接收方，在接收到報文時，需要對特殊分隔符進行檢測，直到檢測到一個完整的報文時，才能進行處理。

在使用特殊字符分隔符協(xié)議的時候，需要注意的是，我們選擇的特殊字符，一定不能在消息體中出現(xiàn)，否則可能會出現(xiàn)錯誤的拆包。例如，發(fā)送方希望把”12\r\n34”，當成一個完整的報文，如果是按行拆分，那么就會錯誤的拆分為2個報文。一種解決策略是，發(fā)送方對需要發(fā)送的內(nèi)容預先進行base64編碼，由于base64編碼只包含64個字符：0-9、a-z、A-Z、+、/，我們可以選擇這64個字符之外的特殊字符作為分隔符。

提示：netty中提供了DelimiterBasedFrameDecoder根據(jù)特殊字符進行解碼。事實上，我們熟悉的的緩存服務器redis，也是通過換行符來區(qū)分一個完整的報文。

3.3 變長協(xié)議

將消息區(qū)分為消息頭和消息體，在消息頭中，我們使用一個整形數(shù)字，例如一個int，來表示消息體的長度。而消息體實際實際要發(fā)送的二進制數(shù)據(jù)字節(jié)。以下是一個基本格式：

 header    body 
+--------+----------+ 
| Length |  Content | 
+--------+----------+ 

在變長協(xié)議中：

• 發(fā)送方，發(fā)送數(shù)據(jù)之前，需要先獲取需要發(fā)送內(nèi)容的二進制字節(jié)大小，然后在需要發(fā)送的內(nèi)容前面添加一個整數(shù)，表示消息體二進制字節(jié)的長度。
• 接收方，在解析時，先讀取內(nèi)容長度Length，其值為實際消息體內(nèi)容(Content)占用的字節(jié)數(shù)，之后必須讀取到這么多字節(jié)的內(nèi)容，才認為是一個完整的數(shù)據(jù)報文。

提示：Netty中提供了LengthFieldPrepender給實際內(nèi)容Content進行編碼添加Length字段，接受方使用LengthFieldBasedFrameDecoder解碼。

3.4 序列化

序列化本質(zhì)上已經(jīng)不是為了解決粘包和拆包問題，而是為了在網(wǎng)絡開發(fā)中可以更加的便捷。在變長協(xié)議中，我們看到可以在實際要發(fā)送的數(shù)據(jù)之前加上一個length字段，表示實際要發(fā)送的數(shù)據(jù)的長度。這實際上給我們了一個很好的思路，我們完全可以將一個對象轉(zhuǎn)換成二進制字節(jié)，來進行通信，例如使用一個Request對象表示請求，使用一個Response對象表示響應。

序列化框架有很多種，我們在選擇時，主要考慮序列化/反序列化的速度，序列化占用的體積，多語言支持等。下面列出了業(yè)界流行的序列化框架：

提示：xml、json也屬于序列化框架的范疇，上面的表格中并沒有列出。

一些網(wǎng)絡通信的RPC框架通常會支持多種序列化方式，例如dubbo支持hessian、json、kyro、fst等。在支持多種序列化框架的情況下，在協(xié)議中通常需要有一個字段來表示序列化的類型，例如，我們可以將上述變長協(xié)議的格式改造為：

+--------+-------------+------------+ 
| Length |  serializer |   Content  | 
+--------+-------------+------------+ 

這里使用1個字節(jié)表示Serializer的值，使用不同的值代表不同的框架。

發(fā)送方，選擇好序列化框架后編碼后，需要指定Serializer字段的值。

接收方，在解碼時，根據(jù)Serializer的值選擇對應的框架進行反序列化;

3.5 壓縮

通常，為了節(jié)省網(wǎng)絡開銷，在網(wǎng)絡通信時，可以考慮對數(shù)據(jù)進行壓縮。常見的壓縮算法有l(wèi)z4、snappy、gzip等。在選擇壓縮算法時，我們主要考慮壓縮比以及解壓縮的效率。

我們可以在網(wǎng)絡通信協(xié)議中，添加一個compress字段，表示采用的壓縮算法：

+--------+-----------+------------+------------+ 
| Length | serializer|  compress  |   Content  | 
+--------+-----------+------------+------------+ 

通常，我們沒有必要使用一個字節(jié)，來表示采用的壓縮算法，1個字節(jié)可以標識256種可能情況，而常用壓縮算法也就那么幾種，因此通常只需要使用2~3個bit來表示采用的壓縮算法即可。

另外，由于數(shù)據(jù)量比較小的時候，壓縮比并不會太高，沒有必要對所有發(fā)送的數(shù)據(jù)都進行壓縮，只有再超過一定大小的情況下，才考慮進行壓縮。如rocketmq，producer在發(fā)送消息時，默認消息大小超過4k，才會進行壓縮。因此，compress字段，應該有一個值，表示沒有使用任何壓縮算法，例如使用0。

3.6 查錯校驗碼

一些通信協(xié)議傳輸?shù)臄?shù)據(jù)中，還包含了查錯校驗碼。典型的算法如CRC32、Adler32等。java對這兩種校驗方式都提供了支持，java.util.zip.Adler32、java.util.zip.CRC32。

+--------+-----------+------------+------------+---------+ 
| Length | serializer|  compress  |   Content  |  CRC32  | 
+--------+-----------+------------+------------+---------+ 

這里并不對CRC32、Adler32進行詳細說明，主要是考慮，為什么需要進行校驗?

有人說是因為考慮到安全，這個理由似乎并不充分，因為我們已經(jīng)有了TLS層的加密，CRC32、Adler32的作用不應該是為了考慮安全。

一位同事的觀點，我非常贊同：二進制數(shù)據(jù)在傳輸?shù)倪^程中，可能因為電磁干擾，導致一個高電平變成低電平，或者低電平變成高電平。這種情況下，數(shù)據(jù)相當于受到了污染，此時通過CRC32等校驗值，則可以驗證數(shù)據(jù)的正確性。

另外，通常校驗機制在通信協(xié)議中，是可選的配置的，并不需要強制開啟，其雖然可以保證數(shù)據(jù)的正確，但是計算校驗值也會帶來一些額外的性能損失。如Mysql主從同步，雖然高版本默認開啟CRC32校驗，但是也可以通過配置禁用。

3.7 小結(jié)

本節(jié)通過一些基本的案例，講解了在TCP編程中，如何通過協(xié)議來解決粘包、拆包問題。在實際開發(fā)中，通常我們的協(xié)議會更加復雜。例如，一些RPC框架，會在協(xié)議中添加唯一標識一個請求的ID，一些支持雙向通信的RPC框架，如sofa-bolt，還會添加一個方向信息等。當然，所謂復雜，無非是在協(xié)議中添加了某個字段用于某個用途，只要弄清楚這些字段的含義，也就不復雜了。