一、TCP 粘包和拆包基本介紹
TCP是面向連接的，面向流的，提供高可靠性服務(wù)。收發(fā)兩端（客戶端和服務(wù)器端）都要有一一成對的socket，因此，發(fā)送端為了將多個(gè)發(fā)給接收端的包，更有效的發(fā)給對方，使用了優(yōu)化方法（Nagle算法），將多次間隔較小且數(shù)據(jù)量小的數(shù)據(jù)，合并成一個(gè)大的數(shù)據(jù)塊，然后進(jìn)行封包。這樣做雖然提高了效率，但是接收端就難于分辨出完整的數(shù)據(jù)包了，因?yàn)槊嫦蛄鞯耐ㄐ攀菬o消息保護(hù)邊界的。
由于TCP無消息保護(hù)邊界, 需要在接收端處理消息邊界問題，也就是我們所說的粘包、拆包問題。
TCP粘包、拆包圖解
假設(shè)客戶端分別發(fā)送了兩個(gè)數(shù)據(jù)包D1和D2給服務(wù)端，由于服務(wù)端一次讀取到字節(jié)數(shù)是不確定的，故可能存在以下四種情況：
- 1、服務(wù)端分兩次讀取到了兩個(gè)獨(dú)立的數(shù)據(jù)包，分別是D1和D2，沒有粘包和拆包。
- 2、服務(wù)端一次接受到了兩個(gè)數(shù)據(jù)包，D1和D2粘合在一起，稱之為TCP粘包。
- 3、服務(wù)端分兩次讀取到了數(shù)據(jù)包，第一次讀取到了完整的D1包和D2包的部分內(nèi)容，第二次讀取到了D2包的剩余內(nèi)容，這稱之為TCP拆包。
- 4、服務(wù)端分兩次讀取到了數(shù)據(jù)包，第一次讀取到了D1包的部分內(nèi)容D1_1，第二次讀取到了D1包的剩余部分內(nèi)容D1_2和完整的D2包。
特別要注意的是，如果TCP的接受滑窗非常小，而數(shù)據(jù)包D1和D2比較大，很有可能會發(fā)生第五種情況，即服務(wù)端分多次才能將D1和D2包完全接受，期間發(fā)生多次拆包。
二、 粘包、拆包發(fā)生原因
產(chǎn)生原因主要有這3種：滑動窗口、MSS/MTU限制、Nagle算法
1、滑動窗口
TCP流量控制主要使用滑動窗口協(xié)議，滑動窗口是接受數(shù)據(jù)端使用的窗口大小，用來告訴發(fā)送端接收端的緩存大小，以此可以控制發(fā)送端發(fā)送數(shù)據(jù)的大小，從而達(dá)到流量控制的目的。這個(gè)窗口大小就是我們一次傳輸幾個(gè)數(shù)據(jù)。對所有數(shù)據(jù)幀按順序賦予編號，發(fā)送方在發(fā)送過程中始終保持著一個(gè)發(fā)送窗口，只有落在發(fā)送窗口內(nèi)的幀才允許被發(fā)送；同時(shí)接收方也維持著一個(gè)接收窗口，只有落在接收窗口內(nèi)的幀才允許接收。這樣通過調(diào)整發(fā)送方窗口和接收方窗口的大小可以實(shí)現(xiàn)流量控制。
現(xiàn)在來看一下滑動窗口是如何造成粘包、拆包的？
粘包：假設(shè)發(fā)送方的每256 bytes表示一個(gè)完整的報(bào)文，接收方由于數(shù)據(jù)處理不及時(shí)，這256個(gè)字節(jié)的數(shù)據(jù)都會被緩存到SO_RCVBUF(接收緩存區(qū)）中。如果接收方的SO_RCVBUF中緩存了多個(gè)報(bào)文，那么對于接收方而言，這就是粘包。
拆包：考慮另外一種情況，假設(shè)接收方的窗口只剩了128，意味著發(fā)送方最多還可以發(fā)送128字節(jié)，而由于發(fā)送方的數(shù)據(jù)大小是256字節(jié)，因此只能發(fā)送前128字節(jié)，等到接收方ack后，才能發(fā)送剩余字節(jié)。這就造成了拆包。
2、MSS和MTU分片
MSS：是Maximum Segement Size縮寫，表示TCP報(bào)文中data部分的最大長度，是TCP協(xié)議在OSI五層網(wǎng)絡(luò)模型中傳輸層對一次可以發(fā)送的最大數(shù)據(jù)的限制。
MTU：最大傳輸單元是Maxitum Transmission Unit的簡寫，是OSI五層網(wǎng)絡(luò)模型中鏈路層(datalink layer)對一次可以發(fā)送的最大數(shù)據(jù)的限制。
當(dāng)需要傳輸?shù)臄?shù)據(jù)大于MSS或者M(jìn)TU時(shí)，數(shù)據(jù)會被拆分成多個(gè)包進(jìn)行傳輸。由于MSS是根據(jù)MTU計(jì)算出來的，因此當(dāng)發(fā)送的數(shù)據(jù)滿足MSS時(shí)，必然滿足MTU。
為了更好的理解，我們先介紹一下在5層網(wǎng)絡(luò)模型中應(yīng)用通過TCP發(fā)送數(shù)據(jù)的流程：
對于應(yīng)用層來說，只關(guān)心發(fā)送的數(shù)據(jù)DATA，將數(shù)據(jù)寫入socket在內(nèi)核中的發(fā)送緩沖區(qū)SO_SNDBUF即返回，操作系統(tǒng)會將SO_SNDBUF中的數(shù)據(jù)取出來進(jìn)行發(fā)送。
傳輸層會在DATA前面加上TCP Header，構(gòu)成一個(gè)完整的TCP報(bào)文。
當(dāng)數(shù)據(jù)到達(dá)網(wǎng)絡(luò)層(network layer)時(shí)，網(wǎng)絡(luò)層會在TCP報(bào)文的基礎(chǔ)上再添加一個(gè)IP Header，也就是將自己的網(wǎng)絡(luò)地址加入到報(bào)文中。
到數(shù)據(jù)鏈路層時(shí)，還會加上Datalink Header和CRC。
當(dāng)?shù)竭_(dá)物理層時(shí)，會將SMAC(Source Machine，數(shù)據(jù)發(fā)送方的MAC地址)，DMAC(Destination Machine，數(shù)據(jù)接受方的MAC地址 )和Type域加入。
可以發(fā)現(xiàn)數(shù)據(jù)在發(fā)送前，每一層都會在上一層的基礎(chǔ)上增加一些內(nèi)容，下圖演示了MSS、MTU在這個(gè)過程中的作用。
MTU是以太網(wǎng)傳輸數(shù)據(jù)方面的限制，每個(gè)以太網(wǎng)幀都有最小的大小64bytes最大不能超過1518bytes。刨去以太網(wǎng)幀的幀頭 （DMAC目的MAC地址48bit=6Bytes+SMAC源MAC地址48bit=6Bytes+Type域2bytes）14Bytes和幀尾 CRC校驗(yàn)部分4Bytes（這個(gè)部分有時(shí)候大家也把它叫做FCS），那么剩下承載上層協(xié)議的地方也就是Data域最大就只能有1500Bytes這個(gè)值 我們就把它稱之為MTU。
由于MTU限制了一次最多可以發(fā)送1500個(gè)字節(jié)，而TCP協(xié)議在發(fā)送DATA時(shí)，還會加上額外的TCP Header和Ip Header，因此刨去這兩個(gè)部分，就是TCP協(xié)議一次可以發(fā)送的實(shí)際應(yīng)用數(shù)據(jù)的最大大小，也就是MSS。
MSS長度=MTU長度-IP Header-TCP Header
TCP Header的長度是20字節(jié)，IPv4中IP Header長度是20字節(jié)，IPV6中IP Header長度是40字節(jié)，因此：在IPV4中，以太網(wǎng)MSS可以達(dá)到1460byte；在IPV6中，以太網(wǎng)MSS可以達(dá)到1440byte。
需要注意的是MSS表示的一次可以發(fā)送的DATA的最大長度，而不是DATA的真實(shí)長度。發(fā)送方發(fā)送數(shù)據(jù)時(shí)，當(dāng)SO_SNDBUF中的數(shù)據(jù)量大于MSS時(shí)，操作系統(tǒng)會將數(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í)候，還會分別加上相應(yīng)的內(nèi)容。
需要注意: 默認(rèn)情況下，與外部通信的網(wǎng)卡的MTU大小是1500個(gè)字節(jié)。而本地回環(huán)地址的MTU大小為65535，這是因?yàn)楸镜販y試時(shí)數(shù)據(jù)不需要走網(wǎng)卡，所以不受到1500的限制。
3、Nagle算法
TCP/IP協(xié)議中，無論發(fā)送多少數(shù)據(jù)，總是要在數(shù)據(jù)(DATA)前面加上協(xié)議頭(TCP Header+IP Header)，同時(shí)，對方接收到數(shù)據(jù)，也需要發(fā)送ACK表示確認(rèn)。
即使從鍵盤輸入的一個(gè)字符，占用一個(gè)字節(jié)，可能在傳輸上造成41字節(jié)的包，其中包括1字節(jié)的有用信息和40字節(jié)的首部數(shù)據(jù)。這種情況轉(zhuǎn)變成了4000%的消耗，這樣的情況對于重負(fù)載的網(wǎng)絡(luò)來是無法接受的。
為了盡可能的利用網(wǎng)絡(luò)帶寬，TCP總是希望盡可能的發(fā)送足夠大的數(shù)據(jù)。（一個(gè)連接會設(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ā)送出去后，沒有收到對方發(fā)送的ACK確認(rèn)該數(shù)據(jù)已收到。
Nagle算法的規(guī)則：
- 1、如果SO_SNDBUF(發(fā)送緩沖區(qū)）中的數(shù)據(jù)長度達(dá)到MSS，則允許發(fā)送；
- 2、如果該SO_SNDBUF中含有FIN，表示請求關(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)于禁用了Nagle 算法。
- 4、未設(shè)置TCP_CORK選項(xiàng)時(shí)，若所有發(fā)出去的小數(shù)據(jù)包（包長度小于MSS）均被確認(rèn)，則允許發(fā)送;
- 5、上述條件都未滿足，但發(fā)生了超時(shí)（一般為200ms），則立即發(fā)送。
三、通信協(xié)議
在了解了粘包、拆包產(chǎn)生的原因之后，現(xiàn)在來分析接收方如何對此進(jìn)行區(qū)分。道理很簡單，如果存在不完整的數(shù)據(jù)(拆包)，則需要繼續(xù)等待數(shù)據(jù)，直至可以構(gòu)成一條完整的請求或者響應(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è)有效的請求報(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é)議可能會浪費(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ù)包。對于以下二進(jìn)制字節(jié)流：
+--------------+
| ABC\nDEF\r\n |
+--------------+
那么根據(jù)協(xié)議，我們可以判斷出來，這里包含了2個(gè)有效的請求報(bào)文
+-----+-----+
| ABC | DEF |
+-----+-----+
在特殊字符分隔符協(xié)議中：
- 發(fā)送方，需要在發(fā)送一個(gè)報(bào)文時(shí)，需要在報(bào)文尾部添加特殊分割符號。
- 接收方，在接收到報(bào)文時(shí)，需要對特殊分隔符進(jìn)行檢測，直到檢測到一個(gè)完整的報(bào)文時(shí)，才能進(jìn)行處理。
在使用特殊字符分隔符協(xié)議的時(shí)候，需要注意的是，我們選擇的特殊字符，一定不能在消息體中出現(xiàn)，否則可能會出現(xiàn)錯(cuò)誤的拆包。例如，發(fā)送方希望把”12\r\n34”，當(dāng)成一個(gè)完整的報(bào)文，如果是按行拆分，那么就會錯(cuò)誤的拆分為2個(gè)報(bào)文。一種解決策略是，發(fā)送方對需要發(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è)對象轉(zhuǎn)換成二進(jìn)制字節(jié)，來進(jìn)行通信，例如使用一個(gè)Request對象表示請求，使用一個(gè)Response對象表示響應(yīng)。
序列化框架有很多種，我們在選擇時(shí)，主要考慮序列化/反序列化的速度，序列化占用的體積，多語言支持等。下面列出了業(yè)界流行的序列化框架：
提示：xml、json也屬于序列化框架的范疇，上面的表格中并沒有列出。
一些網(wǎng)絡(luò)通信的RPC框架通常會支持多種序列化方式，例如dubbo支持hessian、json、kyro、fst等。在支持多種序列化框架的情況下，在協(xié)議中通常需要有一個(gè)字段來表示序列化的類型，例如，我們可以將上述變長協(xié)議的格式改造為：
+--------+-------------+------------+
| Length | serializer | Content |
+--------+-------------+------------+
這里使用1個(gè)字節(jié)表示Serializer的值，使用不同的值代表不同的框架。
發(fā)送方，選擇好序列化框架后編碼后，需要指定Serializer字段的值。
接收方，在解碼時(shí)，根據(jù)Serializer的值選擇對應(yīng)的框架進(jìn)行反序列化。
3.5、壓縮
通常，為了節(jié)省網(wǎng)絡(luò)開銷，在網(wǎng)絡(luò)通信時(shí)，可以考慮對數(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)識256種可能情況，而常用壓縮算法也就那么幾種，因此通常只需要使用2~3個(gè)bit來表示采用的壓縮算法即可。
另外，由于數(shù)據(jù)量比較小的時(shí)候，壓縮比并不會太高，沒有必要對所有發(fā)送的數(shù)據(jù)都進(jìn)行壓縮，只有再超過一定大小的情況下，才考慮進(jìn)行壓縮。如rocketmq，producer在發(fā)送消息時(shí)，默認(rèn)消息大小超過4k，才會進(jìn)行壓縮。因此，compress字段，應(yīng)該有一個(gè)值，表示沒有使用任何壓縮算法，例如使用0。
3.6、查錯(cuò)校驗(yàn)碼
一些通信協(xié)議傳輸?shù)臄?shù)據(jù)中，還包含了查錯(cuò)校驗(yàn)碼。典型的算法如CRC32、Adler32等。java對這兩種校驗(yàn)方式都提供了支持，java.util.zip.Adler32、java.util.zip.CRC32。
+--------+-----------+------------+------------+---------+
| Length | serializer| compress | Content | CRC32 |
+--------+-----------+------------+------------+---------+
這里并不對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)值也會帶來一些額外的性能損失。如Mysql主從同步，雖然高版本默認(rèn)開啟CRC32校驗(yàn)，但是也可以通過配置禁用。
小結(jié)
本節(jié)通過一些基本的案例，講解了在TCP編程中，如何通過協(xié)議來解決粘包、拆包問題。在實(shí)際開發(fā)中，通常我們的協(xié)議會更加復(fù)雜。例如，一些RPC框架，會在協(xié)議中添加唯一標(biāo)識一個(gè)請求的ID，一些支持雙向通信的RPC框架，如sofa-bolt，還會添加一個(gè)方向信息等。當(dāng)然，所謂復(fù)雜，無非是在協(xié)議中添加了某個(gè)字段用于某個(gè)用途，只要弄清楚這些字段的含義，也就不復(fù)雜了。
參考：
https://www.cnblogs.com/Leo_wl/p/10297113.html
https://www.cnblogs.com/sidesky/p/6913109.html
https://blog.csdn.net/u022812849/article/details/107254239
