粘包和拆包是TCP網絡編程中不可避免的，無論是服務端還是客戶端，當我們讀取或者發(fā)送消息的時候，都需要考慮TCP底層的粘包/拆包機制。TCP是個“流”協(xié)議，所謂流，就是沒有界限的一串數據。TCP底層并不了解上層業(yè)務數據的具體含義，它會根據TCP緩沖區(qū)的實際情況進行包的劃分，所以在業(yè)務上認為，一個完整的包可能會被TCP拆分成多個包進行發(fā)送，也有可能把多個小的包封裝成一個大的數據包發(fā)送，這就是所謂的TCP粘包和拆包問題。
如果一次請求發(fā)送的數據量比較小，沒達到緩沖區(qū)大小，TCP則會將多個請求合并為同一個請求進行發(fā)送，這就形成了粘包問題。
如果一次請求發(fā)送的數據量比較大，超過了緩沖區(qū)大小，TCP就會將其拆分為多次發(fā)送，這就形成了拆包問題。
如圖所示，假設客戶端分別發(fā)送了兩個數據包msg1和msg2給服務端，由于服務端一次讀取到的字節(jié)數是不確定的，故可能存在以下4種情況。
2、 代碼復現粘包/拆包問題
客戶端
服務端
問題:服務端一次讀取了客戶端發(fā)送過來的消息,應該讀取10次. 因此發(fā)生粘包。
3、粘包拆包解決方案
3.1業(yè)內解決方案
由于底層的TCP無法理解上層的業(yè)務數據，所以在底層是無法保證數據包不被拆分和重組的，這個問題只能通過上層的應用協(xié)議棧設計來解決，根據業(yè)界的主流協(xié)議的解決方案，可以歸納如下：
1.消息長度固定，累計讀取到長度和為定長LEN的報文后，就認為讀取到了一個完整的信息。
2.將換行符作為消息結束符。
3.將特殊的分隔符作為消息的結束標志，回車換行符就是一種特殊的結束分隔符。
4.通過在消息頭中定義長度字段來標識消息的總長度。
3.2 Netty解決粘包拆包方案
1.固定長度的拆包器 FixedLengthFrameDecoder，每個應用層數據包的都拆分成都是固定長度的大小。
2.行拆包器 LineBasedFrameDecoder，每個應用層數據包，都以換行符作為分隔符，進行分割拆分。
3.分隔符拆包器 DelimiterBasedFrameDecoder，每個應用層數據包，都通過自定義的分隔符，進行分割拆分。
4.基于數據包長度的拆包器 LengthFieldBasedFrameDecoder，將應用層數據包的長度，作為接收端應用層數據包的拆分依據。按照應用層數據包的大小，拆包。這個拆包器，有一個要求，就是應用層協(xié)議中包含數據包的長度。
3.3 代碼實現
1.使用LineBasedFrameDecoder解決粘包問題，其會根據"\n"或"\r\n"對二進制數據進行拆分
客戶端:添加換行符
服務端:添加LineBasedFrameDecoder解碼器
運行結果:發(fā)送了10次，也讀取了10次，解決了粘包的問題
2.使用DelimiterBasedFrameDecoder解碼器，以特殊的符號作為分隔來進行數據包的解碼
服務端:
3. 使用FixedLengthFrameDecoder解碼器，使用固定長度處理消息
服務端:
4.使用LenghtFieldBasedFrameDecode解碼器
服務端:
1024 是最大幀長度，0 是長度字段的偏移量，2 是長度字段的長度，0 是長度調整值，2 是初始需要去掉的字節(jié)數。這樣就可以正確地解碼出數據幀了。
4、總結
造成TCP協(xié)議粘包/拆包問題的原因是TCP協(xié)議數據傳輸是基于字節(jié)流的，它不包含消息、數據包等概念，是無界的，需要應用層協(xié)議自己設計消息的邊界，即消息幀（Message Framing）。如果應用層協(xié)議沒有使用基于長度或者基于分隔符（終結符）劃分邊界等方式進行處理，則會導致多個消息的粘包和拆包。
