tcp的粘包和拆包問題往往出現在基於tcp協議的通訊中，比如rpc框架、netty等。如果你的簡歷中寫了類似的技術或者你所面試的公司使用了相關的技術，被問到該面試的機率會非常高。
tcp是面向位元組流的協議，就是沒有界限的一串資料，本沒有「包」的概念，「粘包」和「拆包」一說是為了有助於形象地理解這兩種現象。
粘包拆包問題在資料鏈路層、網路層以及傳輸層都有可能發生。日常的網路應用開發大都在傳輸層進行，由於udp有訊息保護邊界，不會發生粘包拆包問題，因此粘包拆包問題只發生在tcp協議中。
因為tcp是面向流，沒有邊界，而作業系統在傳送tcp資料時，會通過緩衝區來進行優化，例如緩衝區為1024個位元組大小。
如果一次請求傳送的資料量比較小，沒達到緩衝區大小，tcp則會將多個請求合併為同乙個請求進行傳送，這就形成了粘包問題。
如果一次請求傳送的資料量比較大，超過了緩衝區大小，tcp就會將其拆分為多次傳送，這就是拆包。
上圖中演示了以下幾種情況：
對於粘包和拆包問題，常見的解決方案有四種：
netty對解決粘包和拆包的方案做了抽象，提供了一些解碼器（decoder）來解決粘包和拆包的問題。如：
基於netty進行網路讀寫的程式，可以直接使用這些decoder來完成資料報的解碼。對於高併發、大流量的系統來說，每個資料報都不應該傳輸多餘的資料（所以補齊的方式不可取），lenghtfieldbasedframedecode更適合這樣的場景。
tcp協議粘包拆包問題是因為tcp協議資料傳輸是基於位元組流的，它不包含訊息、資料報等概念，需要應用層協議自己設計訊息的邊界，即訊息幀（message framing）。如果應用層協議沒有使用基於長度或者基於終結符息邊界等方式進行處理，則會導致多個訊息的粘包和拆包。
雖然很多框架中都有現成的解決方案，比如netty，但底層的原理我們還是要清楚的，而且還要知道有這麼會事，才能更好的結合場景進行使用。
程式新視界程式新視界」，乙個讓你軟實力、硬技術同步提公升的平台，提供海量資料
面試題 粘包和拆包
什麼是訊息保護邊界？udp協議傳送資料，每乙個包都是被分開的，每乙個包都有它自己的邊界，不會在接收方與其他的包混雜成為乙個包 所以粘包和拆包是針對於tcp包 客戶端給服務端傳送2個tcp資料報有以下幾種情況 1 正常，兩個包分開傳送 2 兩個包一同傳送 3 接收到不完整的或多出一部分的資料報。有3個...
TCP粘包 拆包
tcp粘包 拆包 客戶端發服務端傳送了兩個資料報a和b 粘包 服務端一次性接收到了a和b 拆包 服務端第一次接收了a和b的一部分，第二次接收到了b的剩餘部分 粘包 拆包原因 1 應用程式寫入的位元組大小 socket傳送緩衝區大小 2 tcp分段 tcp data部分的大小 mss max segm...
TCP粘包，拆包
粘包 拆包表現形式 現在假設客戶端向服務端連續傳送了兩個資料報，用packet1和packet2來表示，那麼服務端收到的資料可以分為三種，現列舉如下 第一種情況，接收端正常收到兩個資料報，即沒有發生拆包和粘包的現象，此種情況不在本文的討論範圍內。第二種情況，接收端只收到乙個資料報，由於tcp是不會出...