Netty 粘包/拆包應用案例及解決方案分析

熟悉TCP變成的能夠知道,不管是客戶端仍是服務端,但咱們讀取或者發送消息的時候,都須要考慮TCP底層粘包/拆包機制,下面咱們先看一下TCP 粘包/拆包和基礎知識,而後模擬一個沒有考慮TCP粘包/拆包致使功能異常的案例,最後,經過正確的例程來談談Netty是如何實現的。網絡

主要內容:框架

  • TCP粘包/拆包的基礎知識設計

  • 沒考慮TCP粘包/拆包的問題案例3d

  • 使用Netty解決讀半包問題netty

 

一、TCP粘包/拆包code

    TCP是個「流「協議,所謂流,就是沒有界限的一串數據。TCP底層並不知道上層業務邏輯,它會根據TCP緩衝區的實際狀況進行包的拆分,因此在業務上認爲,一個完整的包可能會被拆分紅多個包進行發送,也有可能把多個小的包封裝成一個大的數據包發送,這就是所謂的TCP粘包/拆包的問題。server

二、TCP粘包/拆包發生的緣由對象

    問題產生的緣由有三個:以下blog

  • 應用程序write寫入的字節大小大於套接口發送緩衝區大小;索引

  • 進行MSS大小的分段;

  • 以太網幀的payload大於MTU進行IP分片; 

備註:mtu是網絡傳輸最大報文包。mss是網絡傳輸數據最大值。 

https://img3.mukewang.com/5b7ba6030001819a08230455.jpg

三、粘包問題的解決策略

   因爲底層TCP沒法理解上層業務數據,因此在底層是沒法保證數據包不被拆分和重組的,這個問題只能經過上層的應用協議棧設計來解決,根據業界的主流協議的解決方案,能夠概括以下:

  • 消息定長,例如每一個報文的大小長度200字節,若是不夠,不空格;

  • 在包尾增長回車換行符,例如FTP協議;

  • 將消息分爲消息頭和消息體,消息頭包含表示消息總長度的字段,一般設計思路爲消息頭的第一個字段使用int32來表示消息的總長度;

  • 更復雜的設計協議;

介紹完了TCP粘包/拆包的基礎知識後,咱們看一下Netty是如何解決半包問題的,是如何使用Netty的半包解碼器來解決TCP粘包/拆包問題。

四、未考慮TCP粘包/拆包問題出現的功能異常

TimeServer的改造(能夠查看上一篇文章中的netty客戶端-服務端的實現):

https://img1.mukewang.com/5b7badcc0001a03413320886.jpg

每讀到一條消息後,就計數一次,而後發送應答消息給服務端。

TimeClient端的改造:

https://img2.mukewang.com/5b7bb0c20001cdb211660848.jpg

https://img2.mukewang.com/5b7bb0df0001caaf10360573.jpg

運行結果(服務端接收指令):

The time server receive order : QUERY TIME ORDER

此處省略57行。。。。。。。

QUERY TIME ORD ; the counter is :1

The time server receive order : 

此處省略43行。。。。。。。

QUERY TIME ORDER ; the counter is :2

運行結果(客戶端接收響應):

Now is : BAD ORDER

BAD ORDER

 ; the counter is : 1

緣由分析:服務端運行結果代表它只接收到兩條消息,第一條包含57條「QUERY TIME ORDER」指令,次日包含了43條指令,總數100條,咱們指望的也是100條,可是計數只有兩條,全部發生TCP粘包,按照設計初衷,客戶端應該收到100響應,但實際上只收到了1條,不難理解,客戶端也發生了粘包,一條應答消息中包含兩條「BAD ORDER」指令的消息。

五、經過LineBasedFrameDecoder解決TCP粘包問題

   爲了解決TCP粘包/拆包致使的半包讀寫問題,Netty默認提供了多種編解碼器用於處理半包,這是其餘NIO框架和JDK原生的NIO API不能匹敵的。

直接上代碼

TimeServer:

https://img3.mukewang.com/5b7bb71000018a2610730414.jpg

    在原來的TimeServerHandler以前增長了兩個解碼器:LineBasedFrameDecoder、StringDecoder

 

TimeServerHandler:

https://img2.mukewang.com/5b7bbafd0001168013390526.jpg

TimeClient:

https://img3.mukewang.com/5b7bb9b90001e18310300693.jpg

TimeClientHandler:

https://img2.mukewang.com/5b7bbbb500017c0311540389.jpg

支持TCP粘包的運行結果:

服務端:

 

The time server receive order : QUERY TIME ORDER ; the counter is :1

此處省略92條。。。。。。

The time server receive order : QUERY TIME ORDER ; the counter is :100

客戶端:

 

Now is : Tue Aug 21 15:15:21 CST 2018 ; the counter is : 1

此處省略92條。。。。。。

Now is : Tue Aug 21 15:15:21 CST 2018 ; the counter is : 100

 

六、LineBasedFrameDecoder、StringDecoder原來分析

   LineBasedFrameDecoder的工做原理是它依次遍歷ByteBuf中的可讀字節,判斷是否有「\n「或者「\r\n」,若是有,就以此位置爲結束位置,從可讀索引到結束位置區間的字節就組成了一行。它是以換行符爲結束標記的解碼器,

    StringDecoder很是簡單,就是將接收到的對象轉換成字符串,而後繼續調用後面的Handler,

總結:LineBasedFrameDecoder + StringDecoder組合就是按行切換的文本解碼器,它被設計用來支持TCP的粘包、拆包。

疑問:

一、若是發送的消息不是以換行符結束的怎麼辦?

二、靠消息頭中的長度字段來分包的怎麼辦?

這樣的話是否須要本身寫半包解碼器,答案是否認的,Netty 提供了多種支持 TCP粘包、拆包的解碼器,用來知足需求,下面的文章中會詳細介紹《分隔符解碼器》《定長解碼器》,由於它在項目中使用很是普遍,因此單獨去分享這一知識點。

相關文章
相關標籤/搜索