聊聊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,但底層的原理我們還是要清楚的,而且還要知道有這麼回事,才能更好的結合場景進行使。

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章