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

[[279480]]

1 TCP粘包、拆包圖解

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

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

 

關(guān)于這幾種情況說明如下：

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

server一次接受到了兩個(gè)數(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ù)，可能會(huì)發(fā)生粘包、拆包的情況。這樣，對(duì)于接收端就難于分辨出來了，因此必須提供科學(xué)的機(jī)制來解決粘包、拆包問題，這就是協(xié)議的作用。

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

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

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

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

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

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

SO_SNDBUF：

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

SO_RCVBUF：

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

滑動(dòng)窗口：

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

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

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

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

2.2 MSS/MTU分片

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

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

 

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

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

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

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

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

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

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

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

 

上圖顯示了2個(gè)網(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í)，對(duì)方接收到數(shù)據(jù)，也需要發(fā)送ACK表示確認(rèn)。

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

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

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

Nagle算法的規(guī)則：

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

3 通信協(xié)議

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

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

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

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

3.1 定長協(xié)議

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

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

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

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

在定長協(xié)議中：

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

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

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

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

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

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

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

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

• 發(fā)送方，需要在發(fā)送一個(gè)報(bào)文時(shí)，需要在報(bào)文尾部添加特殊分割符號(hào);
• 接收方，在接收到報(bào)文時(shí)，需要對(duì)特殊分隔符進(jìn)行檢測(cè)，直到檢測(cè)到一個(gè)完整的報(bào)文時(shí)，才能進(jìn)行處理。

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

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

3.3 變長協(xié)議

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

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

在變長協(xié)議中：

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

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

3.4 序列化

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

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

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

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

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

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

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

接收方，在解碼時(shí)，根據(jù)Serializer的值選擇對(duì)應(yīng)的框架進(jìn)行反序列化;

3.5 壓縮

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

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

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

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

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

3.6 查錯(cuò)校驗(yàn)碼

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

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

這里并不對(duì)CRC32、Adler32進(jìn)行詳細(xì)說明，主要是考慮，為什么需要進(jìn)行校驗(yàn)?

有人說是因?yàn)榭紤]到安全，這個(gè)理由似乎并不充分，因?yàn)槲覀円呀?jīng)有了TLS層的加密，CRC32、Adler32的作用不應(yīng)該是為了考慮安全。

一位同事的觀點(diǎn)，我非常贊同：二進(jìn)制數(shù)據(jù)在傳輸?shù)倪^程中，可能因?yàn)殡姶鸥蓴_，導(dǎo)致一個(gè)高電平變成低電平，或者低電平變成高電平。這種情況下，數(shù)據(jù)相當(dāng)于受到了污染，此時(shí)通過CRC32等校驗(yàn)值，則可以驗(yàn)證數(shù)據(jù)的正確性。

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

3.7 小結(jié)

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