一、TCP 粘包和拆包基本介紹
TCP是面向連接配接的，面向流的，提供高可靠性服務。收發兩端（用戶端和伺服器端）都要有一一成對的socket，是以，發送端為了将多個發給接收端的包，更有效的發給對方，使用了優化方法（Nagle算法），将多次間隔較小且資料量小的資料，合并成一個大的資料塊，然後進行封包。這樣做雖然提高了效率，但是接收端就難于分辨出完整的資料包了，因為面向流的通信是無消息保護邊界的。
由于TCP無消息保護邊界, 需要在接收端處理消息邊界問題，也就是我們所說的粘包、拆包問題。
TCP粘包、拆包圖解
假設用戶端分别發送了兩個資料包D1和D2給服務端，由于服務端一次讀取到位元組數是不确定的，故可能存在以下四種情況：
- 1、服務端分兩次讀取到了兩個獨立的資料包，分别是D1和D2，沒有粘包和拆包。
- 2、服務端一次接受到了兩個資料包，D1和D2粘合在一起，稱之為TCP粘包。
- 3、服務端分兩次讀取到了資料包，第一次讀取到了完整的D1包和D2包的部分内容，第二次讀取到了D2包的剩餘内容，這稱之為TCP拆包。
- 4、服務端分兩次讀取到了資料包，第一次讀取到了D1包的部分内容D1_1，第二次讀取到了D1包的剩餘部分内容D1_2和完整的D2包。
特别要注意的是，如果TCP的接受滑窗非常小，而資料包D1和D2比較大，很有可能會發生第五種情況，即服務端分多次才能将D1和D2包完全接受，期間發生多次拆包。
二、 粘包、拆包發生原因
産生原因主要有這3種：滑動視窗、MSS/MTU限制、Nagle算法
1、滑動視窗
TCP流量控制主要使用滑動視窗協定，滑動視窗是接受資料端使用的視窗大小，用來告訴發送端接收端的緩存大小，以此可以控制發送端發送資料的大小，進而達到流量控制的目的。這個視窗大小就是我們一次傳輸幾個資料。對所有資料幀按順序賦予編号，發送方在發送過程中始終保持着一個發送視窗，隻有落在發送視窗内的幀才允許被發送；同時接收方也維持着一個接收視窗，隻有落在接收視窗内的幀才允許接收。這樣通過調整發送方視窗和接收方視窗的大小可以實作流量控制。
現在來看一下滑動視窗是如何造成粘包、拆包的？
- 粘包：假設發送方的每256 bytes表示一個完整的封包，接收方由于資料處理不及時，這256個位元組的資料都會被緩存到SO_RCVBUF(接收緩存區）中。如果接收方的SO_RCVBUF中緩存了多個封包，那麼對于接收方而言，這就是粘包。
- 拆包：考慮另外一種情況，假設接收方的視窗隻剩了128，意味着發送方最多還可以發送128位元組，而由于發送方的資料大小是256位元組，是以隻能發送前128位元組，等到接收方ack後，才能發送剩餘位元組。這就造成了拆包。
2、MSS和MTU分片
MSS：是Maximum Segement Size縮寫，表示TCP封包中data部分的最大長度，是TCP協定在OSI五層網絡模型中傳輸層對一次可以發送的最大資料的限制。
MTU：最大傳輸單元是Maxitum Transmission Unit的簡寫，是OSI五層網絡模型中鍊路層(datalink layer)對一次可以發送的最大資料的限制。
當需要傳輸的資料大于MSS或者MTU時，資料會被拆分成多個包進行傳輸。由于MSS是根據MTU計算出來的，是以當發送的資料滿足MSS時，必然滿足MTU。
為了更好的了解，我們先介紹一下在5層網絡模型中應用通過TCP發送資料的流程：
- 對于應用層來說，隻關心發送的資料DATA，将資料寫入socket在核心中的發送緩沖區SO_SNDBUF即傳回，作業系統會将SO_SNDBUF中的資料取出來進行發送。
- 傳輸層會在DATA前面加上TCP Header，構成一個完整的TCP封包。
- 當資料到達網絡層(network layer)時，網絡層會在TCP封包的基礎上再添加一個IP Header，也就是将自己的網絡位址加入到封包中。
- 到資料鍊路層時，還會加上Datalink Header和CRC。
- 當到達實體層時，會将SMAC(Source Machine，資料發送方的MAC位址)，DMAC(Destination Machine，資料接受方的MAC位址 )和Type域加入。
可以發現資料在發送前，每一層都會在上一層的基礎上增加一些内容，下圖示範了MSS、MTU在這個過程中的作用。
MTU是以太網傳輸資料方面的限制，每個以太網幀都有最小的大小64bytes最大不能超過1518bytes。刨去以太網幀的幀頭 （DMAC目的MAC位址48bit=6Bytes+SMAC源MAC位址48bit=6Bytes+Type域2bytes）14Bytes和幀尾 CRC校驗部分4Bytes（這個部分有時候大家也把它叫做FCS），那麼剩下承載上層協定的地方也就是Data域最大就隻能有1500Bytes這個值 我們就把它稱之為MTU。
由于MTU限制了一次最多可以發送1500個位元組，而TCP協定在發送DATA時，還會加上額外的TCP Header和Ip Header，是以刨去這兩個部分，就是TCP協定一次可以發送的實際應用資料的最大大小，也就是MSS。
MSS長度=MTU長度-IP Header-TCP Header
TCP Header的長度是20位元組，IPv4中IP Header長度是20位元組，IPV6中IP Header長度是40位元組，是以：在IPV4中，以太網MSS可以達到1460byte；在IPV6中，以太網MSS可以達到1440byte。
需要注意的是MSS表示的一次可以發送的DATA的最大長度，而不是DATA的真實長度。發送方發送資料時，當SO_SNDBUF中的資料量大于MSS時，作業系統會将資料進行拆分，使得每一部分都小于MSS，這就是拆包，然後每一部分都加上TCP Header，構成多個完整的TCP封包進行發送，當然經過網絡層和資料鍊路層的時候，還會分别加上相應的内容。
需要注意: 預設情況下，與外部通信的網卡的MTU大小是1500個位元組。而本地回環位址的MTU大小為65535，這是因為本地測試時資料不需要走網卡，是以不受到1500的限制。
3、Nagle算法
TCP/IP協定中，無論發送多少資料，總是要在資料(DATA)前面加上協定頭(TCP Header+IP Header)，同時，對方接收到資料，也需要發送ACK表示确認。
即使從鍵盤輸入的一個字元，占用一個位元組，可能在傳輸上造成41位元組的包，其中包括1位元組的有用資訊和40位元組的首部資料。這種情況轉變成了4000%的消耗，這樣的情況對于重負載的網絡來是無法接受的。
為了盡可能的利用網絡帶寬，TCP總是希望盡可能的發送足夠大的資料。（一個連接配接會設定MSS參數，是以，TCP/IP希望每次都能夠以MSS尺寸的資料塊來發送資料）。
Nagle算法就是為了盡可能發送大塊資料，避免網絡中充斥着許多小資料塊。
Nagle算法的基本定義是任意時刻，最多隻能有一個未被确認的小段。 所謂“小段”，指的是小于MSS尺寸的資料塊，所謂“未被确認”，是指一個資料塊發送出去後，沒有收到對方發送的ACK确認該資料已收到。
Nagle算法的規則：
- 1、如果SO_SNDBUF(發送緩沖區）中的資料長度達到MSS，則允許發送；
- 2、如果該SO_SNDBUF中含有FIN，表示請求關閉連接配接，則先将SO_SNDBUF中的剩餘資料發送，再關閉；
- 3、設定了TCP_NODELAY=true選項，則允許發送。TCP_NODELAY是取消TCP的确認延遲機制，相當于禁用了Nagle 算法。
- 4、未設定TCP_CORK選項時，若所有發出去的小資料包（包長度小于MSS）均被确認，則允許發送;
- 5、上述條件都未滿足，但發生了逾時（一般為200ms），則立即發送。
三、通信協定
在了解了粘包、拆包産生的原因之後，現在來分析接收方如何對此進行區分。道理很簡單，如果存在不完整的資料(拆包)，則需要繼續等待資料，直至可以構成一條完整的請求或者響應。
通過定義通信協定(protocol)，可以解決粘包、拆包問題。協定的作用就定義傳輸資料的格式。這樣在接受到的資料的時候：
- 如果粘包了，就可以根據這個格式來區分不同的包。
- 如果拆包了，就等待資料可以構成一個完整的消息來處理。
3.1、定長協定
定長協定：顧名思義，就是指定一個封包的必須具有固定的長度。例如，我們規定每3個位元組，表示一個有效封包，如果我們分4次總共發送以下9個位元組：
+---+----+------+----+
| A | BC | DEFG | HI |
+---+----+------+----+
那麼根據協定，我們可以判斷出來，這裡包含了3個有效的請求封包，如下：
+-----+-----+-----+
| ABC | DEF | GHI |
+-----+-----+-----+
在定長協定中：
- 發送方，必須保證發送封包長度是固定的。如果封包位元組長度不能滿足條件，如規定長度是1024位元組，但是實際需要發送的内容隻有900個位元組，那麼不足的部分可以補充0。是以定長協定可能會浪費帶寬。
- 接收方，每讀取到固定長度的内容時，則認為讀取到了一個完整的封包。
提示：Netty中提供了FixedLengthFrameDecoder，支援把固定的長度的位元組數當做一個完整的消息進行解碼。
3.2、特殊字元分隔符協定
在包尾部增加回車或者空格符等特殊字元進行分割 。例如，按行解析，遇到字元\n、\r\n的時候，就認為是一個完整的資料包。對于以下二進制位元組流：
+--------------+
| ABC\nDEF\r\n |
+--------------+
那麼根據協定，我們可以判斷出來，這裡包含了2個有效的請求封包
+-----+-----+
| ABC | DEF |
+-----+-----+
在特殊字元分隔符協定中：
- 發送方，需要在發送一個封包時，需要在封包尾部添加特殊分割符号。
- 接收方，在接收到封包時，需要對特殊分隔符進行檢測，直到檢測到一個完整的封包時，才能進行處理。
在使用特殊字元分隔符協定的時候，需要注意的是，我們選擇的特殊字元，一定不能在消息體中出現，否則可能會出現錯誤的拆包。例如，發送方希望把”12\r\n34”，當成一個完整的封包，如果是按行拆分，那麼就會錯誤的拆分為2個封包。一種解決政策是，發送方對需要發送的内容預先進行base64編碼，由于base64編碼隻包含64個字元：0-9、a-z、A-Z、+、/，我們可以選擇這64個字元之外的特殊字元作為分隔符。
提示：netty中提供了DelimiterBasedFrameDecoder根據特殊字元進行解碼。事實上，我們熟悉的的緩存伺服器redis，也是通過換行符來區分一個完整的封包。
3.3、變長協定
将消息區分為消息頭和消息體，在消息頭中，我們使用一個整形數字，例如一個int，來表示消息體的長度。而消息體實際實際要發送的二進制資料位元組。以下是一個基本格式：
header body
+--------+----------+
| Length | Content |
+--------+----------+
在變長協定中：
- 發送方，發送資料之前，需要先擷取需要發送内容的二進制位元組大小，然後在需要發送的内容前面添加一個整數，表示消息體二進制位元組的長度。
- 接收方，在解析時，先讀取内容長度Length，其值為實際消息體内容(Content)占用的位元組數，之後必須讀取到這麼多位元組的内容，才認為是一個完整的資料封包。
提示：Netty中提供了LengthFieldPrepender給實際内容Content進行編碼添加Length字段，接受方使用LengthFieldBasedFrameDecoder解碼。
3.4、序列化
序列化本質上已經不是為了解決粘包和拆包問題，而是為了在網絡開發中可以更加的便捷。在變長協定中，我們看到可以在實際要發送的資料之前加上一個length字段，表示實際要發送的資料的長度。這實際上給我們了一個很好的思路，我們完全可以将一個對象轉換成二進制位元組，來進行通信，例如使用一個Request對象表示請求，使用一個Response對象表示響應。
序列化架構有很多種，我們在選擇時，主要考慮序列化/反序列化的速度，序列化占用的體積，多語言支援等。下面列出了業界流行的序列化架構：
提示：xml、json也屬于序列化架構的範疇，上面的表格中并沒有列出。
一些網絡通信的RPC架構通常會支援多種序列化方式，例如dubbo支援hessian、json、kyro、fst等。在支援多種序列化架構的情況下，在協定中通常需要有一個字段來表示序列化的類型，例如，我們可以将上述變長協定的格式改造為：
+--------+-------------+------------+
| Length | serializer | Content |
+--------+-------------+------------+
這裡使用1個位元組表示Serializer的值，使用不同的值代表不同的架構。
發送方，選擇好序列化架構後編碼後，需要指定Serializer字段的值。
接收方，在解碼時，根據Serializer的值選擇對應的架構進行反序列化。
3.5、壓縮
通常，為了節省網絡開銷，在網絡通信時，可以考慮對資料進行壓縮。常見的壓縮算法有lz4、snappy、gzip等。在選擇壓縮算法時，我們主要考慮壓縮比以及解壓縮的效率。
我們可以在網絡通信協定中，添加一個compress字段，表示采用的壓縮算法：
+--------+-----------+------------+------------+
| Length | serializer| compress | Content |
+--------+-----------+------------+------------+
通常，我們沒有必要使用一個位元組，來表示采用的壓縮算法，1個位元組可以辨別256種可能情況，而常用壓縮算法也就那麼幾種，是以通常隻需要使用2~3個bit來表示采用的壓縮算法即可。
另外，由于資料量比較小的時候，壓縮比并不會太高，沒有必要對所有發送的資料都進行壓縮，隻有再超過一定大小的情況下，才考慮進行壓縮。如rocketmq，producer在發送消息時，預設消息大小超過4k，才會進行壓縮。是以，compress字段，應該有一個值，表示沒有使用任何壓縮算法，例如使用0。
3.6、查錯校驗碼
一些通信協定傳輸的資料中，還包含了查錯校驗碼。典型的算法如CRC32、Adler32等。java對這兩種校驗方式都提供了支援，java.util.zip.Adler32、java.util.zip.CRC32。
+--------+-----------+------------+------------+---------+
| Length | serializer| compress | Content | CRC32 |
+--------+-----------+------------+------------+---------+
這裡并不對CRC32、Adler32進行詳細說明，主要是考慮，為什麼需要進行校驗?
有人說是因為考慮到安全，這個理由似乎并不充分，因為我們已經有了TLS層的加密，CRC32、Adler32的作用不應該是為了考慮安全。
一位同僚的觀點，我非常贊同：二進制資料在傳輸的過程中，可能因為電磁幹擾，導緻一個高電平變成低電平，或者低電平變成高電平。這種情況下，資料相當于受到了污染，此時通過CRC32等校驗值，則可以驗證資料的正确性。
另外，通常校驗機制在通信協定中，是可選的配置的，并不需要強制開啟，其雖然可以保證資料的正确，但是計算校驗值也會帶來一些額外的性能損失。如Mysql主從同步，雖然高版本預設開啟CRC32校驗，但是也可以通過配置禁用。
小結
本節通過一些基本的案例，講解了在TCP程式設計中，如何通過協定來解決粘包、拆包問題。在實際開發中，通常我們的協定會更加複雜。例如，一些RPC架構，會在協定中添加唯一辨別一個請求的ID，一些支援雙向通信的RPC架構，如sofa-bolt，還會添加一個方向資訊等。當然，所謂複雜，無非是在協定中添加了某個字段用于某個用途，隻要弄清楚這些字段的含義，也就不複雜了。
參考：
https://www.cnblogs.com/Leo_wl/p/10297113.html
https://www.cnblogs.com/sidesky/p/6913109.html