本文是Netty系列第8篇
上一篇文章我們深入學習了Netty邏輯架構中的核心組件ChannelHandler和ChannelPipeline，並介紹了它在日常開發使用中的最佳實踐。文中也提到了，ChannelHandler主要用於數據輸入、輸出過程中的加工處理，比如編解碼、異常處理等。
今天，我們就選取日常開發中最常用的一種ChannelHandler用途來學習——編解碼器。
如果說ChannelHandler的學習是Netty的基礎招式，那么編解碼就是“基礎招式”中衍生出的“常用招式“，我們往往會以一個ChannelHandler來實現編解碼邏輯。無論是網絡編程實戰，還是面試八股文，都離不開編解碼的知識。
本文預計閱讀時間約 15分鍾，
將重點圍繞以下幾個問題展開：
- 學習編解碼器，從粘包/拆包開始
- 如何實現自定義編解碼器
- Netty有哪些開箱即用的編解碼器
1.學習編解碼器，從粘包/拆包開始
1.1為什么會有是粘包/拆包
粘包/拆包問題，相信大家都有所耳聞，這個問題的出現主要包括三個原因：
1）MTU 和 MSS 限制
MTU（Maxitum Transmission Unit） 是OSI五層網絡模型中 數據鏈路層 對一次可以發送的最大數據的限制，一般來說大小為 1500 byte。
MSS（Maximum Segement Size） 是指 TCP報文中data部分的最大長度，它是傳輸層一次發送最大數據的大小限制。
MSS和MTU的關系如下所示：
MSS長度=MTU長度 - IP Header - TCP Header
因此，當 MSS長度 + IP Header + TCP Header > MTU長度 時，就需要拆分多個報文進行發送，會導致“拆包”現象。
2）TCP滑動窗口
TCP的流量控制方法就是“滑動窗口”。當A向B發送數據時，B作為接收端會告知發送端A自己可以接受的窗口數值，以此來控制A的發送流量大小，從而達到流量控制的目的。
假設接收方B告知發送方A的窗口大小為256，意味着發送方最多還可以發送256個字節，而由於發送方的數據大小是518字節，因此只能發送前256字節，等到接收方ack后，才能發送剩余字節。會導致“拆包”現象。
3）Nagle算法
TCP/IP協議中，無論發送多少大小的數據，都要在數據(DATA)前面加上協議頭(TCP Header + IP Header)。如果每次需要發送的數據只有 1 字節，加上 20 個字節 IP Header 和 20 個字節 TCP Header，每次發送的數據包大小為 41 字節，但真正有效的信息只有1個字節，這就造成了非常大的浪費。
因此，TCP/IP中使用Nagle 算法來提高效率。
Nagle 算法核心思想在於“化零為整“。它是在數據未得到確認之前先寫入緩沖區，等待數據確認或者緩沖區積攢到一定大小再把數據包發送出去。
多個小數據包合並后一起發送出去，就造成了粘包。
Q: 如果禁用了Nagle算法，還需要對粘包情況進行處理嗎？
A: 需要。除了Nagle算法外，接收端不及時也可能會造成粘包現象。當上一個數據包還在緩沖區未被接收端處理時，下一個數據包已經到達了，然后接收端根據緩沖區大小取到的數據有可能會取到多個數據包。
1.2 怎么處理粘包/拆包
對於TCP，其實我們都知道它的一個特點就是“面向字節流”的傳輸協議，本身並沒有數據包的界限。所以不管什么原因造成了“粘包/拆包”，TCP協議本身的數據傳輸是可靠且正確的。
我們首先要明確一點：“粘包/拆包”導致的問題，本質上是應用層的數據解析問題。
因此，解決拆包/粘包問題的核心方法：定義應用層的通信協議。
核心在於定義正確的數據邊界。
常見協議的解決方案包括三種：
1）固定長度
每個數據報文都約定一個固定的長度。
當接收方累計讀取到固定長度的報文后，就認為已經獲得一個完整的消息。
比如我們要發送一個ABCDEFGHIJKLM的消息，約定固定消息長度為4，那么接收方就可以按照4的長度來解析。如下所示。
|
|
|
|
|
| ABCD |
EFGH |
IJKL |
MN00 |
當發送方的數據小於固定長度時，比如最后一個數據包，只有MN兩個字符，這時候就需要空位補齊。
這種方案非常簡單，但是缺點也非常明顯，非常不靈活。
如果固定長度定義太長，就會浪費數據傳輸空間。如果定義太短，就會影響正確的數據傳輸。
這種方法一般不采用。
2）特定分隔符
除了固定長度外，我們比較容易想到的區分“數據邊界”的方法，就是用“特定分隔符”。當接收方讀到特定的分隔符，就認為拿到了一個完整的消息。
比如我們使用換行符 \n 來區分。
AB\nCDEFG\nHIJK\nLMN\n這種方法就比較靈活了，適應不同長度的消息。但是，必須要注意，“特殊分隔符”不能和消息內容重復，否則就會解析失敗了。
因此，我們在實踐過程中，可以考慮把消息進行編碼（如base64），然后用編碼字符集之外的符號作為“特定分隔符”。
這種方案一般用在協議比較簡單的場景中。
3）消息長度+內容
一般項目開發中，最通用的方式還是采用 消息長度+內容 的方式進行處理。
比如定義一個這樣的消息格式：
| 消息長度（比如4字節長度存儲） |
消息內容 |
| 3 |
ABC |
以這樣一個格式存儲，消息接收方在解析時，先讀取4字節長度的信息作為”消息長度“，這里是3，表示消息長度為3字節。然后就讀取3字節的消息內容作為 完整 的消息。
舉個例子：
2AB5CDEFG4HIJK3LMN消息長度+內容 的方式非常靈活，可以應用於各種場景中。
注意，在消息頭中，除了定義消息長度外，還可以自定義其他擴展字段，比如消息版本、算法類型等。
2.如何在Netty中實現自定義編解碼器
上面我們了解了出現“粘包/拆包”的原因以及常用的解決方法。下面看看如何在Netty中實現自定義編解碼器。
Netty作為一個優秀的網絡通信框架，已經提供了非常豐富的處理編解碼的抽象類，我們只需要自定義編解碼算法擴展即可。
2.1 自定義編碼器
我們先來看看自定義編碼器。因為編碼器比較簡單，不需要關注「粘包/拆包問題」。
常用的編碼抽象類包括MessageToByteEncoder 和 MessageToMessageEncoder，繼承自
ChannelOutboundHandlerAdapter，操作的是Outbound相關數據。
1）MessageToByteEncoder<I>
這個編碼器用於消息對象編碼成字節流。它提供了encode的抽象方法，我們只需要實現encode方法，就能進行自定義編碼了。
編碼器實現非常簡單，不需要關注拆包/粘包問題。
我們舉一個栗子，將String類型消息轉換為字節流：
2）MessageToMessageEncoder
這個編碼器用於將一種消息對象編碼成另一種消息對象。這里的第二個Message可以理解為任意一個對象。如果是使用ByteBuf對象的話，就和上面的MessageToByteEncoder是一樣的了。
我們找一個Netty自帶的栗子看看，StringEncoder：
2.2 自定義解碼器
解碼器比編碼器要復雜一些，因為需要考慮“拆包/粘包”問題。
由於接收方有可能沒有接收到完整的消息，所以解碼框架需要對入站的數據做緩沖操作，直至獲取到完整的消息。
常用的解碼器抽象類包括 ByteToMessageDecoder 和 MessageToMessageDecoder，繼承自
ChannelInboundHandlerAdapter，操作的是Inbbound相關數據。
一般通用的做法是使用 ByteToMessageDecoder 解析 TCP 協議，解決拆包/粘包問題。解析得到有效的 ByteBuf 數據，然后傳遞給后續的 MessageToMessageDecoder 做數據對象的轉換。
1）ByteToMessageDecoder
ByteToMessageDecoder解碼器用於字節流解碼成消息對象。
拿上面的“固定長度法”解決“粘包/拆包”舉一個栗子，Netty自帶的FixedLengthFrameDecoder。
通過固定長度frameLength，來對消息進行解析。
生產實踐中，可能會使用更加復雜的協議來實現自定義編解碼，比如protobuf。
2）MessageToMessageDecoder
MessageToMessageDecoder解碼器用於將一種消息對象解碼成另一種消息對象。如果你需要對解析后的字節數據做對象模型的轉換，這時候便需要用到這個解碼器。
3.Netty有哪些開箱即用的解碼器
作為一個優秀的網絡編程框架，Netty除了支持擴展自定義編解碼器外，還提供了非常豐富的開箱即用的編解碼器。尤其是針對我們上文1.2節中提過的三種解決「粘包/拆包問題」的方式，都有開箱即用的實現。
3.1 固定長度解碼器 FixedLengthFrameDecoder
這個解碼器上文已經提到過，對應1.2節中的「固定長度解碼」，這里再稍微展開一下。
通過構造函數配置固定長度 frameLength，然后在decode時，按照frameLength 進行解碼。
- 當讀取到長度大小為 frameLength 的消息，那么解碼器認為已經獲取到了一個完整的消息。
- 當消息長度小於 frameLength，FixedLengthFrameDecoder 解碼器會一直等后續數據包的到達，直至獲得完整的消息。
3.2 特殊分隔符解碼器 DelimiterBasedFrameDecoder
這個解碼器對應1.2節中的「特殊分隔符解碼」，也是一個繼承自ByteToMessageDecoder的解碼器。
這個解碼器會使用 1個 或 多個 符號delimiter 對傳入的消息（ByteBuf)進行解碼。
我們看一下構造器，了解一下幾個重要參數。
- maxFranmeLength
maxFranmeLength 是待處理消息的最大長度限制。如果超過 maxFranmeLength 還沒有檢測到指定分隔符，將會拋出 TooLongFrameException。
- stripDelimiter
stripDelimiter是一個boolean類型， 用於判斷解碼后得到的消息是否移除分隔符。如果 stripDelimiter=false，那么解碼后的消息內容就會保留分隔符信息。
- failFast
failFast是一個boolean類型。如果為true，那么消息在超出 maxFranmeLength 后，會立即拋出 TooLongFrameException。如果為false，那么會等到解碼出一個完整的消息后才會拋出TooLongFrameException。
- delimiters
delimiters 的類型是 ByteBuf 數組，可以在構造器中同時傳入多個分隔符，但是在解析時，最終會選擇長度最短的分隔符進行消息拆分。
例如收到的數據為：
ABCD\nEFG\r\n 如果指定的分隔符為 \n 和 \r\n，那么會解碼出兩個消息。
ABCD EFG如果指定的特定分隔符只有 \r\n，那么只會解碼出一個消息：
ABCD\nEFG 3.3 長度域解碼器 LengthFieldBasedFrameDecoder
這個解碼器是生產實踐中運用比較廣泛的一種（比如RocketMQ），相對復雜，但是特別靈活，基本能覆蓋各種基於長度進行拆包的方案，比如1.2節中提到的「消息長度+內容」的方案。
使用這個解碼器的時候，重點需要了解4個參數，掌握了參數的設置，就能快速實現不同的基於長度的拆包解碼方案。
| 參數名 |
類型 |
含義 |
| lengthFieldOffset |
int |
長度字段的偏移量。表示「長度域」的起始位置 |
| lengthFieldLength |
int |
長度字段所占用的字節數 |
| lengthAdjustment |
int |
消息長度的修正值。表示一些復雜協議中，會在「長度域」添加一些其他內容，如版本號、消息類型等，這就需要修正值進行修正處理 |
| initialBytesToStrip |
int |
解碼后需要跳過的初始字節數。表示消息內容數據的起始位置 |
1）解碼方案一：基於消息長度 + 消息內容，解碼結果不截斷消息頭
報文只包含消息長度 Length 和消息內容 Content 字段，其中 Length 為 16 進制表示，共占用 2 字節，Length 的值 0x000C 代表 Content 占用 12 字節。
| 參數名 |
取值 |
| lengthFieldOffset |
0 |
| lengthFieldLength |
2 |
| lengthAdjustment |
0 |
| initialBytesToStrip |
0（表示解碼結果不截斷消息頭） |
解碼示例：
2）解碼方案二：基於消息長度 + 消息內容，解碼結果截斷
與方案一不同之處在於，解碼結果會截斷消息頭（跳過2字節）
| 參數名 |
取值 |
| lengthFieldOffset |
0 |
| lengthFieldLength |
2 |
| lengthAdjustment |
0 |
| initialBytesToStrip |
2（表示跳過 Length 字段的字節長度，解碼后 只包含 消息內容） |
解碼示例：
3）解碼方案三：基於消息頭 + 消息長度 + 消息內容
消息起始位置添加特殊消息頭，消息長度 Length字段 后移。
| 參數名 |
取值 |
| lengthFieldOffset |
2 |
| lengthFieldLength |
3 |
| lengthAdjustment |
0 |
| initialBytesToStrip |
0（表示解碼結果不截斷消息頭） |
解碼示例：
4）解碼方案四：基於消息長度 + 消息頭 + 消息內容
消息起始位置為消息長度 Length字段，后面並不直接添加 消息內容，而是先添加 消息頭header，再添加 消息內容。
| 參數名 |
取值 |
| lengthFieldOffset |
0 |
| lengthFieldLength |
3 |
| lengthAdjustment |
2 （Header1的長度） |
| initialBytesToStrip |
0（表示解碼結果不截斷消息頭） |
解碼示例：
由於 Length 后面不是馬上添加content，所以需要加上 lengthAdjustment（2 字節）才能得到 Header + Content 的內容（14 字節）。
4.小結
來簡單回顧下吧。
本文主要介紹了ChannelHandler的一種典型應用場景——編解碼器。
編解碼器核心關注點在於「粘包/拆包」的處理，我們介紹了「粘包/拆包」產生的原因以及常用解決方案。然后說明了如何使用Netty框架實現自定義編解碼器。
最后，介紹了Netty中非常好用的幾個開箱即用的編解碼器。
參考書目：
《Netty in Action》
都看到最后了，原創不易，點個關注，點個贊吧～
文章持續更新，可以微信搜索「阿丸筆記 」第一時間閱讀，回復【筆記】獲取Canal、MySQL、HBase、JAVA實戰筆記，回復【資料】獲取一線大廠面試資料。
知識碎片重新梳理，構建Java知識圖譜： github.com/saigu/JavaK…（歷史文章查閱非常方便）