Netty的拆包與粘包簡介

TCP的粘包/拆包問題

不管是服務端仍是客戶端，當咱們讀取或者發送消息的時候，都須要考慮TCP底層的粘包/拆包機制。 TCP是一個「流」協議，所謂流，就是沒有界限的一串數據。TCP底層並不瞭解上層業務數據的具體含義，他會根據TCP緩衝區的實際狀況進行包的劃分，因此在業務上認爲，一個完整的包可能被TCP拆分紅多個包進行發送，也可能把多個小的包封裝成一個大的數據包發送，這就是所謂的粘包和拆包問題

TCP粘包/拆包問題發生的緣由

問題產生的緣由有三個，以下：

• 應用程序write寫入的字節大於套接口發送緩衝區的大小
• 進行MSS大小的TCP分段
• 以太網幀的payload大於MTU進行IP分片

---

粘包問題的解決策略

TCP以流的方式進行數據傳輸，因爲底層TCP沒法理解上層的業務數據，因此在底層是沒法保證數據包不被拆分和重組的，這個問題只能經過上層的應用協議棧設計來解決，上層的應用協議爲了對消息進行區分，業界主流的解決方案能夠概括以下：

• 消息固定長度，累計讀取到長度總和爲定長LEN的報文後，就認爲讀取到了一個完整的消息，若是不夠，空位補空格；將計數器置位，從新開始讀取下一個數據
• 將回車換行符做爲消息結束符，例如FTP協議，這種方式在文本協議中應該比較普遍
• 將特殊的分隔符做爲消息結束標誌，回車換行符就是一種特殊的結束分隔符
• 經過在消息頭中定義長度字段來標識消息的總長度
• 更復雜的應用層協議

---

Netty處理粘包/拆包問題

Netty對上面的前四種應用作了統一的抽象，提供了Decoder來解決對應的問題，使用起來很是方便。有了這些Decoder，用戶不須要對本身讀取的報文進行人工解碼，也不須要考慮TCP的粘包和拆包。Decoder以下：

• LineBasedFrameDecoder
• StringDecoder
• DelimiterBasedFrameDecoder
• FixedLengthFrameDecoder

參考文獻：《Netty權威指南》