Netty_TCP拆包粘包解決方案

1、問題

  熟悉tcp編程的可能都知道，不管是服務器端仍是客戶端，當咱們讀取或者發送數據的時候，都須要考慮TCP底層的粘包/拆包機制。

  TCP是一個「流」協議，所謂流就是沒有界限的遺傳數據，你們能夠想象下若是河裏的水就比如數據，他們是連成一片的，沒有分界線，TCP底層並不瞭解上層的業務數據具體的含義，它會根據TCP緩衝區的實際狀況進行包的劃分，也就是說，在業務上咱們一個完成的包可能會被TCP分紅多個包進行發送，也可能把多個小包封裝成一個大的數據發送出去，這就所謂的TCP粘包、拆包問題。

1）分析TCP粘包、拆包問題的產生緣由：

      一、應用程序write寫入的字節大小大於套接口發送緩衝區的大小

      二、進行MSS大小的TCP分段

      三、以太網幀的payload大於MTU進行IP分片

2）粘包、拆包問題解決方案，三種方案：

     一、消息定長，例如每一個報文的大小固定爲200個字節，若是不夠，空位補空格；

     二、在包尾部增長特殊字符進行分割，例如加回車等

     三、講消息分爲消息頭河消息體，在消息頭中包含表示消息總長度的字段，而後進行業務邏輯處理

2、採用特殊字符進行分割

Server只須要加三行：

 1.根據$_進行截取字符串

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

 3.LineBasedFrameDecoder：依次編譯bytebuf中的可讀字符，判斷看是否有「\n」或者「\r\n」，若是有，就以此位置爲結束位置，從可讀索引到結束位置區間的字節就組成了一行。它是以換行符爲結束標誌的解碼器，支持攜帶結束符或者不攜帶結束符兩種解碼方式，同時支持單行的最大長度。若是連續讀取到最大長度後，仍然沒有發現換行符，就會拋出異常，同時忽略掉以前讀到的異常碼流。（具體例子介紹在《Netty（三）TCP粘包拆包處理》）

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

client只須要加三行：

 

執行結果

反之：客戶端也是同樣寫法。