Tcp是一個流的協議，一個完整的包可能會被Tcp拆成多個包進行發送，也可能把一個小的包封裝成一個大的數據包發送，這就是所謂的粘包和拆包問題

在流傳輸中出現，UDP不會出現粘包，因為它有消息邊界

1、要發送的數據大於TCP發送緩沖區剩余空間，需要被拆包

2、待發送的數據大於MSS（最大報文長度），TCP在傳輸前將進行拆包

3、要發送的數據小於TCP發送的緩沖區大小，TCP將多次寫入的緩沖區一次發送出去，就會出現粘包

4、接受數據端的應用層沒有及時讀取TCP接受緩沖區的數據，將發生粘包

1、消息定長，例如每個報文的大小固定長度200個字節，如果不夠 ，空位補空格；

2、在包尾增加特殊符號分隔符

3、將消息分為消息頭和消息體，消息頭中包含表示消息總長度的字段，通常設計思路是消息頭的第一個字段用int來表示消息的總長度

4、更復雜的應用層協議

netty對以上4種應用做了抽象，提供了4種解碼器：

LineBasedFrameDecoder：依次編譯bytebuf中的可讀字符，判斷看是否有"\n"或者"\r\n",如果有，就以此位置為結束位置，從可讀索引到結束位置區間的字節就組成了一行，它是以換行符為結束標誌的解碼器，支持攜帶結束符或者不攜帶結束符兩種解碼方式，同時支持單行的最大長度，如果連續讀取到最大長度後，仍然沒有發現換行符，就會拋出異常，同時忽略掉之前讀到的異常碼流

FixedLengthFrameDecoder：固定長度解碼器，它能按照指定的長度對消息進行自動解碼，開發者不需要考慮TCP的粘包等問題，利用FixedLengthFrameDecoder解碼，無論一次性接受到多少數據，他都會按照構造函數中設置的長度進行解碼，如果是半包消息，FixedLengthFrameDecoder會緩存半包消息並等待下一個包，到達後進行拼包，直到讀取完整的包

DelimiterBasedFrameDecoder：自定義的分隔符解碼，構造函數的第一個參數表示單個消息的最大長度，當達到該長度後仍然沒有查到分隔符，就拋出TooLongFrameException異常，防止由於異常碼流缺失分隔符號導致的內存溢出

LengthFieldBasedFrameDecoder：通過固定長度來區分整包消息，消息定長，報文大小固定長度，不夠空格補全，發送和接受方遵循相同的約定，這樣即使粘包了通過接收方編程實現獲取定長報文也能區分。

　　·

netty的解碼器和粘包拆包