Netty常用招式—ChannelHandler與編解碼

作者：阿丸筆記 2021-10-08 09:38:57

本文主要介紹了ChannelHandler的一種典型應(yīng)用場景——編解碼器。編解碼器核心關(guān)注點(diǎn)在于「粘包/拆包」的處理，我們介紹了「粘包/拆包」產(chǎn)生的原因以及常用解決方案。然后說明了如何使用Netty框架實(shí)現(xiàn)自定義編解碼器。

[[427477]]

上一篇文章我們深入學(xué)習(xí)了Netty邏輯架構(gòu)中的核心組件ChannelHandler和ChannelPipeline，并介紹了它在日常開發(fā)使用中的最佳實(shí)踐。文中也提到了，ChannelHandler主要用于數(shù)據(jù)輸入、輸出過程中的加工處理，比如編解碼、異常處理等。

今天，我們就選取日常開發(fā)中最常用的一種ChannelHandler用途來學(xué)習(xí)——編解碼器。

如果說ChannelHandler的學(xué)習(xí)是Netty的基礎(chǔ)招式，那么編解碼就是“基礎(chǔ)招式”中衍生出的“常用招式“，我們往往會(huì)以一個(gè)ChannelHandler來實(shí)現(xiàn)編解碼邏輯。無論是網(wǎng)絡(luò)編程實(shí)戰(zhàn)，還是面試八股文，都離不開編解碼的知識(shí)。

[[427478]]

本文預(yù)計(jì)閱讀時(shí)間約 15分鐘，

將重點(diǎn)圍繞以下幾個(gè)問題展開：

學(xué)習(xí)編解碼器，從粘包/拆包開始
如何實(shí)現(xiàn)自定義編解碼器
Netty有哪些開箱即用的編解碼器

1、學(xué)習(xí)編解碼器，從粘包/拆包開始

1.1 為什么會(huì)有粘包/拆包粘包/拆包

問題，相信大家都有所耳聞，這個(gè)問題的出現(xiàn)主要包括三個(gè)原因：

1)MTU 和 MSS 限制

MTU(Maxitum Transmission Unit) 是OSI五層網(wǎng)絡(luò)模型中數(shù)據(jù)鏈路層對(duì)一次可以發(fā)送的最大數(shù)據(jù)的限制，一般來說大小為 1500 byte。

MSS(Maximum Segement Size) 是指 TCP報(bào)文中data部分的最大長度，它是傳輸層一次發(fā)送最大數(shù)據(jù)的大小限制。

MSS和MTU的關(guān)系如下所示：

MSS長度=MTU長度 - IP Header - TCP Header

因此，當(dāng) MSS長度 + IP Header + TCP Header > MTU長度時(shí)，就需要拆分多個(gè)報(bào)文進(jìn)行發(fā)送，會(huì)導(dǎo)致“拆包”現(xiàn)象。

2)TCP滑動(dòng)窗口

TCP的流量控制方法就是“滑動(dòng)窗口”。當(dāng)A向B發(fā)送數(shù)據(jù)時(shí)，B作為接收端會(huì)告知發(fā)送端A自己可以接受的窗口數(shù)值，以此來控制A的發(fā)送流量大小，從而達(dá)到流量控制的目的。

假設(shè)接收方B告知發(fā)送方A的窗口大小為256，意味著發(fā)送方最多還可以發(fā)送256個(gè)字節(jié)，而由于發(fā)送方的數(shù)據(jù)大小是518字節(jié)，因此只能發(fā)送前256字節(jié)，等到接收方ack后，才能發(fā)送剩余字節(jié)。會(huì)導(dǎo)致“拆包”現(xiàn)象。

3)Nagle算法

TCP/IP協(xié)議中，無論發(fā)送多少大小的數(shù)據(jù)，都要在數(shù)據(jù)(DATA)前面加上協(xié)議頭(TCP Header + IP Header)。如果每次需要發(fā)送的數(shù)據(jù)只有 1 字節(jié)，加上 20 個(gè)字節(jié) IP Header 和 20 個(gè)字節(jié) TCP Header，每次發(fā)送的數(shù)據(jù)包大小為 41 字節(jié)，但真正有效的信息只有1個(gè)字節(jié)，這就造成了非常大的浪費(fèi)。

因此，TCP/IP中使用Nagle 算法來提高效率。

Nagle 算法核心思想在于“化零為整“。它是在數(shù)據(jù)未得到確認(rèn)之前先寫入緩沖區(qū)，等待數(shù)據(jù)確認(rèn)或者緩沖區(qū)積攢到一定大小再把數(shù)據(jù)包發(fā)送出去。

多個(gè)小數(shù)據(jù)包合并后一起發(fā)送出去，就造成了粘包。

1.2 怎么處理粘包/拆包

對(duì)于TCP，其實(shí)我們都知道它的一個(gè)特點(diǎn)就是“面向字節(jié)流”的傳輸協(xié)議，本身并沒有數(shù)據(jù)包的界限。所以不管什么原因造成了“粘包/拆包”，TCP協(xié)議本身的數(shù)據(jù)傳輸是可靠且正確的。

我們首先要明確一點(diǎn)：“粘包/拆包”導(dǎo)致的問題，本質(zhì)上是應(yīng)用層的數(shù)據(jù)解析問題。

因此，解決拆包/粘包問題的核心方法：定義應(yīng)用層的通信協(xié)議。

核心在于定義正確的數(shù)據(jù)邊界。

常見協(xié)議的解決方案包括三種：

1)固定長度

每個(gè)數(shù)據(jù)報(bào)文都約定一個(gè)固定的長度。

當(dāng)接收方累計(jì)讀取到固定長度的報(bào)文后，就認(rèn)為已經(jīng)獲得一個(gè)完整的消息。

比如我們要發(fā)送一個(gè)ABCDEFGHIJKLM的消息，約定固定消息長度為4，那么接收方就可以按照4的長度來解析。如下所示。

當(dāng)發(fā)送方的數(shù)據(jù)小于固定長度時(shí)，比如最后一個(gè)數(shù)據(jù)包，只有MN兩個(gè)字符，這時(shí)候就需要空位補(bǔ)齊。

這種方案非常簡單，但是缺點(diǎn)也非常明顯，非常不靈活。

如果固定長度定義太長，就會(huì)浪費(fèi)數(shù)據(jù)傳輸空間。如果定義太短，就會(huì)影響正確的數(shù)據(jù)傳輸。

這種方法一般不采用。

2)特定分隔符

除了固定長度外，我們比較容易想到的區(qū)分“數(shù)據(jù)邊界”的方法，就是用“特定分隔符”。當(dāng)接收方讀到特定的分隔符，就認(rèn)為拿到了一個(gè)完整的消息。

比如我們使用換行符 \n 來區(qū)分。

AB\nCDEFG\nHIJK\nLMN\n

這種方法就比較靈活了，適應(yīng)不同長度的消息。但是，必須要注意，“特殊分隔符”不能和消息內(nèi)容重復(fù)，否則就會(huì)解析失敗了。

因此，我們在實(shí)踐過程中，可以考慮把消息進(jìn)行編碼(如base64)，然后用編碼字符集之外的符號(hào)作為“特定分隔符”。

這種方案一般用在協(xié)議比較簡單的場景中。

3)消息長度+內(nèi)容

一般項(xiàng)目開發(fā)中，最通用的方式還是采用消息長度+內(nèi)容的方式進(jìn)行處理。

比如定義一個(gè)這樣的消息格式：

以這樣一個(gè)格式存儲(chǔ)，消息接收方在解析時(shí)，先讀取4字節(jié)長度的信息作為”消息長度“，這里是3，表示消息長度為3字節(jié)。然后就讀取3字節(jié)的消息內(nèi)容作為完整的消息。

舉個(gè)例子：

2AB5CDEFG4HIJK3LMN

消息長度+內(nèi)容的方式非常靈活，可以應(yīng)用于各種場景中。

注意，在消息頭中，除了定義消息長度外，還可以自定義其他擴(kuò)展字段，比如消息版本、算法類型等。

2、如何在Netty中實(shí)現(xiàn)自定義編解碼器

上面我們了解了出現(xiàn)“粘包/拆包”的原因以及常用的解決方法。下面看看如何在Netty中實(shí)現(xiàn)自定義編解碼器。

Netty作為一個(gè)優(yōu)秀的網(wǎng)絡(luò)通信框架，已經(jīng)提供了非常豐富的處理編解碼的抽象類，我們只需要自定義編解碼算法擴(kuò)展即可。

2.1 自定義編碼器

我們先來看看自定義編碼器。因?yàn)榫幋a器比較簡單，不需要關(guān)注「粘包/拆包問題」。

常用的編碼抽象類包括MessageToByteEncoder 和 MessageToMessageEncoder，繼承自

ChannelOutboundHandlerAdapter，操作的是Outbound相關(guān)數(shù)據(jù)。

1）MessageToByteEncoder<I>

這個(gè)編碼器用于消息對(duì)象編碼成字節(jié)流。它提供了encode的抽象方法，我們只需要實(shí)現(xiàn)encode方法，就能進(jìn)行自定義編碼了。

編碼器實(shí)現(xiàn)非常簡單，不需要關(guān)注拆包/粘包問題。

我們舉一個(gè)栗子，將String類型消息轉(zhuǎn)換為字節(jié)流：

2)MessageToMessageEncoder

這個(gè)編碼器用于將一種消息對(duì)象編碼成另一種消息對(duì)象。這里的第二個(gè)Message可以理解為任意一個(gè)對(duì)象。如果是使用ByteBuf對(duì)象的話，就和上面的MessageToByteEncoder是一樣的了。

我們找一個(gè)Netty自帶的栗子看看，StringEncoder：

2.2 自定義解碼器

解碼器比編碼器要復(fù)雜一些，因?yàn)樾枰紤]“拆包/粘包”問題。

由于接收方有可能沒有接收到完整的消息，所以解碼框架需要對(duì)入站的數(shù)據(jù)做緩沖操作，直至獲取到完整的消息。

常用的解碼器抽象類包括 ByteToMessageDecoder 和 MessageToMessageDecoder，繼承自

ChannelInboundHandlerAdapter，操作的是Inbbound相關(guān)數(shù)據(jù)。

一般通用的做法是使用 ByteToMessageDecoder 解析 TCP 協(xié)議，解決拆包/粘包問題。解析得到有效的 ByteBuf 數(shù)據(jù)，然后傳遞給后續(xù)的 MessageToMessageDecoder 做數(shù)據(jù)對(duì)象的轉(zhuǎn)換。

1)ByteToMessageDecoder

ByteToMessageDecoder解碼器用于字節(jié)流解碼成消息對(duì)象。

拿上面的“固定長度法”解決“粘包/拆包”舉一個(gè)栗子，Netty自帶的FixedLengthFrameDecoder。

通過固定長度frameLength，來對(duì)消息進(jìn)行解析。

生產(chǎn)實(shí)踐中，可能會(huì)使用更加復(fù)雜的協(xié)議來實(shí)現(xiàn)自定義編解碼，比如protobuf。

2)MessageToMessageDecoder

MessageToMessageDecoder解碼器用于將一種消息對(duì)象解碼成另一種消息對(duì)象。如果你需要對(duì)解析后的字節(jié)數(shù)據(jù)做對(duì)象模型的轉(zhuǎn)換，這時(shí)候便需要用到這個(gè)解碼器。

3、Netty有哪些開箱即用的解碼器

作為一個(gè)優(yōu)秀的網(wǎng)絡(luò)編程框架，Netty除了支持?jǐn)U展自定義編解碼器外，還提供了非常豐富的開箱即用的編解碼器。尤其是針對(duì)我們上文1.2節(jié)中提過的三種解決「粘包/拆包問題」的方式，都有開箱即用的實(shí)現(xiàn)。

3.1 固定長度解碼器 FixedLengthFrameDecoder

這個(gè)解碼器上文已經(jīng)提到過，對(duì)應(yīng)1.2節(jié)中的「固定長度解碼」，這里再稍微展開一下。

通過構(gòu)造函數(shù)配置固定長度 frameLength，然后在decode時(shí)，按照frameLength 進(jìn)行解碼。

當(dāng)讀取到長度大小為 frameLength 的消息，那么解碼器認(rèn)為已經(jīng)獲取到了一個(gè)完整的消息。
當(dāng)消息長度小于 frameLength，F(xiàn)ixedLengthFrameDecoder 解碼器會(huì)一直等后續(xù)數(shù)據(jù)包的到達(dá)，直至獲得完整的消息。

3.2 特殊分隔符解碼器 DelimiterBasedFrameDecoder

這個(gè)解碼器對(duì)應(yīng)1.2節(jié)中的「特殊分隔符解碼」，也是一個(gè)繼承自ByteToMessageDecoder的解碼器。

這個(gè)解碼器會(huì)使用 1個(gè) 或多個(gè) 符號(hào)delimiter 對(duì)傳入的消息(ByteBuf)進(jìn)行解碼。

我們看一下構(gòu)造器，了解一下幾個(gè)重要參數(shù)。

maxFranmeLength

maxFranmeLength 是待處理消息的最大長度限制。如果超過 maxFranmeLength 還沒有檢測到指定分隔符，將會(huì)拋出 TooLongFrameException。

stripDelimiter

stripDelimiter是一個(gè)boolean類型，用于判斷解碼后得到的消息是否移除分隔符。如果 stripDelimiter=false，那么解碼后的消息內(nèi)容就會(huì)保留分隔符信息。

failFast

failFast是一個(gè)boolean類型。如果為true，那么消息在超出 maxFranmeLength 后，會(huì)立即拋出 TooLongFrameException。如果為false，那么會(huì)等到解碼出一個(gè)完整的消息后才會(huì)拋出TooLongFrameException。