怎樣分析TCP的粘包、拆包以及解決方案

今天就跟大家聊聊有關怎樣分析TCP的粘包、拆包以及解決方案，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

TCP的粘包、拆包以及解決方案

TCP的粘包和拆包問題往往出現在基于TCP協議的通訊中，比如RPC框架、Netty等。如果你的簡歷中寫了類似的技術或者你所面試的公司使用了相關的技術，被問到該面試的幾率會非常高。

TCP的粘包和拆包問題往往出現在基于TCP協議的通訊中，比如RPC框架、Netty等。如果你的簡歷中寫了類似的技術或者你所面試的公司使用了相關的技術，被問到該面試的幾率會非常高。

今天這篇文章就帶大家詳細了解一下TCP的粘包和拆包以及解決方案。

什么是粘包?

在學習粘包之前，先糾正一下讀音，很多視頻教程中將“粘”讀作“nián”。經過調研，個人更傾向于讀“zhān bāo”。

如果在百度百科上搜索“粘包”，對應的讀音便是“zhān bāo”，語義解釋為：網絡技術術語。指TCP協議中，發送方發送的若干包數據到接收方接收時粘成一包，從接收緩沖區看，后一包數據的頭緊接著前一包數據的尾。

TCP是面向字節流的協議，就是沒有界限的一串數據，本沒有“包”的概念，“粘包”和“拆包”一說是為了有助于形象地理解這兩種現象。

為什么UDP沒有粘包?

粘包拆包問題在數據鏈路層、網絡層以及傳輸層都有可能發生。日常的網絡應用開發大都在傳輸層進行，由于UDP有消息保護邊界，不會發生粘包拆包問題，因此粘包拆包問題只發生在TCP協議中

粘包拆包發生場景

因為TCP是面向流，沒有邊界，而操作系統在發送TCP數據時，會通過緩沖區來進行優化，例如緩沖區為1024個字節大小。

如果一次請求發送的數據量比較小，沒達到緩沖區大小，TCP則會將多個請求合并為同一個請求進行發送，這就形成了粘包問題。

如果一次請求發送的數據量比較大，超過了緩沖區大小，TCP就會將其拆分為多次發送，這就是拆包。

關于粘包和拆包可以參考下圖的幾種情況：

粘包/拆包

上圖中演示了以下幾種情況：

• 正常的理想情況，兩個包恰好滿足TCP緩沖區的大小或達到TCP等待時長，分別發送兩個包;

• 粘包：兩個包較小，間隔時間短，發生粘包，合并成一個包發送;

• 拆包：一個包過大，超過緩存區大小，拆分成兩個或多個包發送;

• 拆包和粘包：Packet1過大，進行了拆包處理，而拆出去的一部分又與Packet2進行粘包處理。

常見的解決方案

對于粘包和拆包問題，常見的解決方案有四種：

• 發送端將每個包都封裝成固定的長度，比如100字節大小。如果不足100字節可通過補0或空等進行填充到指定長度;

• 發送端在每個包的末尾使用固定的分隔符，例如\r\n。如果發生拆包需等待多個包發送過來之后再找到其中的\r\n進行合并;例如，FTP協議;

• 將消息分為頭部和消息體，頭部中保存整個消息的長度，只有讀取到足夠長度的消息之后才算是讀到了一個完整的消息;

• 通過自定義協議進行粘包和拆包的處理。

Netty對粘包和拆包問題的處理

Netty對解決粘包和拆包的方案做了抽象，提供了一些解碼器(Decoder)來解決粘包和拆包的問題。如：

• LineBasedFrameDecoder：以行為單位進行數據包的解碼;

• DelimiterBasedFrameDecoder：以特殊的符號作為分隔來進行數據包的解碼;

• FixedLengthFrameDecoder：以固定長度進行數據包的解碼;

• LenghtFieldBasedFrameDecode：適用于消息頭包含消息長度的協議(最常用);

基于Netty進行網絡讀寫的程序，可以直接使用這些Decoder來完成數據包的解碼。對于高并發、大流量的系統來說，每個數據包都不應該傳輸多余的數據(所以補齊的方式不可取)，LenghtFieldBasedFrameDecode更適合這樣的場景。

TCP協議粘包拆包問題是因為TCP協議數據傳輸是基于字節流的，它不包含消息、數據包等概念，需要應用層協議自己設計消息的邊界，即消息幀(Message Framing)。如果應用層協議沒有使用基于長度或者基于終結符息邊界等方式進行處理，則會導致多個消息的粘包和拆包。

雖然很多框架中都有現成的解決方案，比如Netty，但底層的原理我們還是要清楚的，而且還要知道有這么回事，才能更好的結合場景進行使。

看完上述內容，你們對怎樣分析TCP的粘包、拆包以及解決方案有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。