15 Netty編解碼框架

1 Netty編解碼框架

在上一節(jié)中，我們提到TCP的粘包、拆包問題，可以通過自定義通信協(xié)議的方式來解決。通信協(xié)議就是通信雙方約定好的數(shù)據(jù)格式，發(fā)送方按照這個(gè)數(shù)據(jù)格式來發(fā)送，接受方按照這個(gè)格式來解析。典型的協(xié)議包括：定長(zhǎng)協(xié)議、特殊字符分隔符協(xié)議、報(bào)文頭指定Length等。在確定了使用什么通信協(xié)議的情況下，發(fā)送方和接收方要完成的工作不同：

編碼：發(fā)送方要將發(fā)送的二進(jìn)制數(shù)據(jù)轉(zhuǎn)換成協(xié)議規(guī)定的格式的二進(jìn)制數(shù)據(jù)流，稱之為編碼(encode)，編碼功能由編碼器(encoder)完成。

解碼：接收方需要根據(jù)協(xié)議的格式，對(duì)二進(jìn)制數(shù)據(jù)進(jìn)行解析，稱之為解碼(decode)，解碼功能由解碼器(decoder)完成。

編解碼：如果有一種組件，既能編碼，又能解碼，則稱之為編碼解碼器(codec)。這種組件在發(fā)送方和接收方都可以使用。

因此對(duì)于開發(fā)人員而言，我們要做的工作主要就是2點(diǎn)：確定協(xié)議、編寫協(xié)議對(duì)應(yīng)的編碼/解碼器。

協(xié)議分為公有協(xié)議和私有協(xié)議。所謂公有協(xié)議，指的是業(yè)界普遍遵循的通信協(xié)議，Netty提供了大量公有協(xié)議數(shù)據(jù)格式的編碼解碼器，從而簡(jiǎn)化開發(fā)者的使用。例如：

  • 你想開發(fā)一個(gè)基于Netty的郵件服務(wù)器，你將會(huì)發(fā)現(xiàn)Netty針對(duì)POP3、IMAP、SMTP協(xié)議的數(shù)據(jù)格式都提供了相應(yīng)的編碼解碼器。

  • 如果你想自己開發(fā)一個(gè)web服務(wù)器，你會(huì)發(fā)現(xiàn)Netty提供好了HTTP協(xié)議、Websocket協(xié)議相應(yīng)的編解碼器。

  • 甚至，對(duì)于一些業(yè)界流行的組件，如redis、memcached這兩個(gè)緩存服務(wù)器，netty都提供了相應(yīng)的解碼器，因此如果你有意愿的話，可以自己編寫訪問redis、memcached服務(wù)器的client，甚至是開源出去給其他人使用。

另外一方面，可能有的時(shí)候，我們希望定義一些私有協(xié)議，例如你們的公司需要編寫一個(gè)RPC框架，這個(gè)框架僅限于公司內(nèi)部使用。這個(gè)時(shí)候，因?yàn)閰f(xié)議本身還沒有，對(duì)應(yīng)的編解碼器也沒有，所以我們就要自己實(shí)現(xiàn)。

Netty提供了一套完善的編解碼框架，不論是公有協(xié)議/私有協(xié)議，我們都可以在這個(gè)框架的基礎(chǔ)上，非常容易的實(shí)現(xiàn)相應(yīng)的編碼/解碼器。輸入的數(shù)據(jù)是在ChannelInboundHandler中處理的，數(shù)據(jù)輸出是在ChannelOutboundHandler中處理的。因此編碼器/解碼器實(shí)際上是這兩個(gè)接口的特殊實(shí)現(xiàn)類，不過它們的作用僅僅是編碼/解碼。

2 解碼器

對(duì)于解碼器，Netty中主要提供了抽象基類ByteToMessageDecoder和MessageToMessageDecoder

1B171BD0-9287-4212-8A4D-112ACC0DEDF6.png

2.1 抽象類ByteToMessageDecoder

用于將接收到的二進(jìn)制數(shù)據(jù)(Byte)解碼，得到完整的請(qǐng)求報(bào)文(Message)。

通常，ByteToMessageDecoder解碼后內(nèi)容會(huì)得到一個(gè)ByteBuf實(shí)例列表，每個(gè)ByteBuf實(shí)例都包含了一個(gè)完整的報(bào)文信息。你可以直接把這些ByteBuf實(shí)例直接交給之后的ChannelInboundHandler處理，或者將這些包含了完整報(bào)文信息的ByteBuf實(shí)例解析封裝到不同的Java對(duì)象實(shí)例后，再交其處理。不管哪一種情況，之后的ChannelInboundHandler在處理時(shí)不需要在考慮粘包、拆包問題。

不過，ByteToMessageDecoder提供的一些常見的實(shí)現(xiàn)類：

  • FixedLengthFrameDecoder：定長(zhǎng)協(xié)議解碼器，我們可以指定固定的字節(jié)數(shù)算一個(gè)完整的報(bào)文

  • LineBasedFrameDecoder：行分隔符解碼器，遇到\n或者\(yùn)r\n，則認(rèn)為是一個(gè)完整的報(bào)文

  • DelimiterBasedFrameDecoder：分隔符解碼器，與LineBasedFrameDecoder類似，只不過分隔符可以自己指定

  • LengthFieldBasedFrameDecoder：長(zhǎng)度編碼解碼器，將報(bào)文劃分為報(bào)文頭/報(bào)文體，根據(jù)報(bào)文頭中的Length字段確定報(bào)文體的長(zhǎng)度，因此報(bào)文提的長(zhǎng)度是可變的

  • JsonObjectDecoder：json格式解碼器，當(dāng)檢測(cè)到匹配數(shù)量的"{" 、”}”或”[””]”時(shí)，則認(rèn)為是一個(gè)完整的json對(duì)象或者json數(shù)組。

這些實(shí)現(xiàn)類，都只是將接收到的二進(jìn)制數(shù)據(jù)，解碼成包含完整報(bào)文信息的ByteBuf實(shí)例后，就直接交給了之后的ChannelInboundHandler處理。之所以不將ByteBuf中的信息封裝到Java對(duì)象中，道理很簡(jiǎn)單，Netty根本不知道開發(fā)者想封裝到什么對(duì)象中，甚至不知道報(bào)文中的具體內(nèi)容是什么，因此不如直接把包含了完整報(bào)文信息的ByteBuf實(shí)例，交給開發(fā)人員來自己解析封裝。

當(dāng)然也有例外，例如Netty提供的XmlDecoder，直接將二進(jìn)制數(shù)據(jù)流解析成Aalto XML parser類庫中定義的xml對(duì)象。

我們也可以自定義ByteToMessageDecoder，此時(shí)需要覆蓋ByteToMessageDecoder的decode方法：

protected abstract void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception;

參數(shù)的作用如下：

  • in：需要解碼的二進(jìn)制數(shù)據(jù)。

  • List<Object> out：解碼后的有效報(bào)文列表，我們需要將解碼后的報(bào)文添加到這個(gè)List中。之所以使用一個(gè)List表示，是因?yàn)榭紤]到粘包問題，因此入?yún)⒌膇n中可能包含多個(gè)有效報(bào)文。當(dāng)然，也有可能發(fā)生了拆包，in中包含的數(shù)據(jù)還不足以構(gòu)成一個(gè)有效報(bào)文，此時(shí)不往List中添加元素即可。

另外特別要注意的是，在解碼時(shí)，不需要直接調(diào)用ByteBuf的readXXX方法來讀取數(shù)據(jù)，而是應(yīng)該首先要判斷能否構(gòu)成一個(gè)有效的報(bào)文。例如對(duì)于以下的案例，假設(shè)協(xié)議規(guī)定傳輸?shù)臄?shù)據(jù)都是int類型的整數(shù)：

WX20180909-193812@2x.png

上圖中顯式輸入的ByteBuf中包含4個(gè)字節(jié)，每個(gè)字節(jié)的值分別為：1，2，3，4。我們自定義一個(gè)ToIntegerDecoder進(jìn)行解碼，盡管這里我看到了4個(gè)字節(jié)剛好可以構(gòu)成一個(gè)int類型整數(shù)，但是在真正解碼之前，我們并不知道ByteBuf包含的字節(jié)數(shù)能否構(gòu)成一個(gè)或者多個(gè)完成的有效報(bào)文，因此需要首先判斷ByteBuf中剩余可讀的字節(jié)，是否大于等于4，如下：

public class ToIntegerDecoder extends ByteToMessageDecoder {
    @Override
   public void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
    if (in.readableBytes() >= 4) {
        out.add(in.readInt());
    } }
}

只有在可讀字節(jié)數(shù)>=4的情況下，我們才進(jìn)行解碼，即讀取一個(gè)int，并添加到List中。

在可讀字節(jié)數(shù)小于4的情況下，我們并沒有做任何處理，假設(shè)剩余可讀字節(jié)數(shù)為3，不足以構(gòu)成1個(gè)int。那么父類ByteToMessageDecoder發(fā)現(xiàn)這次解碼List中的元素沒有變化，則會(huì)對(duì)in中的剩余3個(gè)字節(jié)進(jìn)行緩存，等待下1個(gè)字節(jié)的到來，之后再回到調(diào)用ToIntegerDecoder的decode方法。

另外，細(xì)心的讀者可能注意到了，在ToIntegerDecoder的decode方法中，每次最多只讀取一個(gè)1個(gè)int。如果ByteBuf中的字節(jié)數(shù)很多，例如為16，那么可以構(gòu)成4個(gè)int，而這里只讀取了1個(gè)int，那么剩余12字節(jié)怎么辦？這個(gè)其實(shí)不用擔(dān)心，ByteToMessageDecoder再每次回調(diào)子類的decode方法之后，都會(huì)判斷輸入的ByteBuf中是否還有剩余字節(jié)可讀，如果還有，會(huì)再次回調(diào)子類的decode方法，直到某個(gè)回調(diào)decode方法List中的元素個(gè)數(shù)沒有變化時(shí)才停止，元素個(gè)數(shù)沒有變化，實(shí)際上意味著子類已經(jīng)沒有辦法從剩余的字節(jié)中讀取一個(gè)有效報(bào)文。

由于存在剩余可讀字節(jié)時(shí)，ByteToMessageDecoder會(huì)自動(dòng)再次回調(diào)子類decode方法，因此筆者建議在實(shí)現(xiàn)ByteToMessageDecoder時(shí)，decode方法每次只解析一個(gè)有效報(bào)文即可，沒有必要一次全部解析出來。

2.2 抽象類MessageToMessageDecoder

ByteToMessageDecoder是將二進(jìn)制流進(jìn)行解碼后，得到有效報(bào)文。而MessageToMessageDecoder則是將一個(gè)本身就包含完整報(bào)文信息的對(duì)象轉(zhuǎn)換成另一個(gè)Java對(duì)象。

舉例來說，前面介紹了ByteToMessageDecoder的部分子類解碼后，會(huì)直接將包含了報(bào)文完整信息的ByteBuf實(shí)例交由之后的ChannelInboundHandler處理，此時(shí)，你可以在ChannelPipeline中，再添加一個(gè)MessageToMessageDecoder，將ByteBuf中的信息解析后封裝到Java對(duì)象中，簡(jiǎn)化之后的ChannelInboundHandler的操作。

另外，一些場(chǎng)景下，有可能你的報(bào)文信息已經(jīng)封裝到了Java對(duì)象中，但是還要繼續(xù)轉(zhuǎn)成另外的Java對(duì)象，因此一個(gè)MessageToMessageDecoder后面可能還跟著另一個(gè)MessageToMessageDecoder。一個(gè)比較容易的理解的類比案例是Java Web編程，通?？蛻舳藶g覽器發(fā)送過來的二進(jìn)制數(shù)據(jù)，已經(jīng)被web容器(如tomcat)解析成了一個(gè)HttpServletRequest對(duì)象，但是我們還是需要將HttpServletRequest中的數(shù)據(jù)提取出來，封裝成我們自己的POJO類，也就是從一個(gè)Java對(duì)象(HttpServletRequest)轉(zhuǎn)換成另一個(gè)Java對(duì)象(我們的POJO類)。

除了一些公有協(xié)議的解碼器外，Netty提供的MessageToMessageDecoder實(shí)現(xiàn)類較少，主要是：

StringDecoder：用于將包含完整的報(bào)文信息的ByteBuf轉(zhuǎn)換成字符串。我們可以將其與ByteToMessageDecoder的一些實(shí)現(xiàn)類聯(lián)合使用，以LineBasedFrameDecoder為例，其將二進(jìn)制數(shù)據(jù)流按行分割后封裝到ByteBuf中。我們可以在其之后再添加一個(gè)StringDecoder，將ByteBuf中的數(shù)據(jù)轉(zhuǎn)換成字符串。

Base64Decoder：用于Base64編碼。例如，前面我們提到LineBasedFrameDecoder、DelimiterBasedFrameDecoder等ByteToMessageDecoder實(shí)現(xiàn)類，是使用特殊字符作為分隔符作為解碼的條件。但是如果報(bào)文內(nèi)容中如果本身就包含了分隔符，那么解碼就會(huì)出錯(cuò)。此時(shí)，對(duì)于發(fā)送方，可以先使用Base64Encoder對(duì)報(bào)文內(nèi)容進(jìn)行Base64編碼，然后我們選擇Base64編碼包含的64種字符之外的其他特殊字符作為分隔符。在解碼時(shí)，首先特殊字符進(jìn)行分割，然后通過Base64Decoder解碼得到原始的二進(jìn)制字節(jié)流。

MessageToMessageDecoder的類聲明如下：

public abstract class MessageToMessageDecoder<I> extends ChannelInboundHandlerAdapter

其中泛型參數(shù)I表示我們要解碼的消息類型。例前面，我們?cè)赥oIntegerDecoder中，把二進(jìn)制字節(jié)流轉(zhuǎn)換成了一個(gè)int類型的整數(shù)。

類似的，MessageToMessageDecoder也有一個(gè)decode方法需要覆蓋 ，如下：

/**
* 參數(shù)msg，需要進(jìn)行解碼的參數(shù)。例如ByteToMessageDecoder解碼后的得到的包含完整報(bào)文信息ByteBuf
* List<Object> out參數(shù)：將msg經(jīng)過解析后得到的java對(duì)象，添加到放到List<Object> out中
*/
protected abstract void decode(ChannelHandlerContext ctx, I msg, List<Object> out) throws Exception;

例如，現(xiàn)在我們想編寫一個(gè)IntegerToStringDecoder，把前面編寫的ToIntegerDecoder輸出的int參數(shù)轉(zhuǎn)換成字符串，此時(shí)泛型I就應(yīng)該是Integer類型。

WX20180909-193852@2x.png

IntegerToStringDecoder源碼如下所示：

public class IntegerToStringDecoder extends MessageToMessageDecoder<Integer> {
    @Override
    public void decode(ChannelHandlerContext ctx, Integer msg List<Object> out) throws Exception {
        out.add(String.valueOf(msg));
    }
}

此時(shí)我們應(yīng)該按照如下順序組織ChannelPipieline中ToIntegerDecoder和IntegerToStringDecoder 的關(guān)系：

ChannelPipieline ch=....
ch.addLast(new ToIntegerDecoder());
ch.addLast(new IntegerToStringDecoder());

也就是說，前一個(gè)ChannelInboudHandler輸出的參數(shù)類型，就是后一個(gè)ChannelInboudHandler的輸入類型。

特別需要注意的一點(diǎn)是，如果我們指定MessageToMessageDecoder的泛型參數(shù)為ByteBuf，表示其可以直接針對(duì)ByteBuf進(jìn)行解碼，那么其是否能替代ByteToMessageDecoder呢？

答案是不可以的。因?yàn)锽yteToMessageDecoder除了進(jìn)行解碼，還要會(huì)對(duì)不足以構(gòu)成一個(gè)完整數(shù)據(jù)的報(bào)文拆包數(shù)據(jù)(拆包)進(jìn)行緩存。而MessageToMessageDecoder則沒有這樣的邏輯。

因此通常的使用建議是，使用一個(gè)ByteToMessageDecoder進(jìn)行粘包、拆包處理，得到完整的有效報(bào)文的ByteBuf實(shí)例，然后交由之后的一個(gè)或者多個(gè)MessageToMessageDecoder對(duì)ByteBuf實(shí)例中的數(shù)據(jù)進(jìn)行解析，轉(zhuǎn)換成POJO類。

3 編碼器

與ByteToMessageDecoder和MessageToMessageDecoder相對(duì)應(yīng)，Netty提供了對(duì)應(yīng)的編碼器實(shí)現(xiàn)MessageToByteEncoder和MessageToMessageEncoder，二者都實(shí)現(xiàn)ChannelOutboundHandler接口。

C62F858C-5306-4456-B20B-D07648BE4594.png

相對(duì)來說，編碼器比解碼器的實(shí)現(xiàn)要更加簡(jiǎn)單，原因在于解碼器除了要按照協(xié)議解析數(shù)據(jù)，還要要處理粘包、拆包問題；而編碼器只要將數(shù)據(jù)轉(zhuǎn)換成協(xié)議規(guī)定的二進(jìn)制格式發(fā)送即可。

3.1 抽象類MessageToByteEncoder

MessageToByteEncoder也是一個(gè)泛型類，泛型參數(shù)I表示將需要編碼的對(duì)象的類型，編碼的結(jié)果是將信息轉(zhuǎn)換成二進(jìn)制流放入ByteBuf中。子類通過覆寫其抽象方法encode，來實(shí)現(xiàn)編碼，如下所示：

public abstract class MessageToByteEncoder<I> extends ChannelOutboundHandlerAdapter {
....
     protected abstract void encode(ChannelHandlerContext ctx, I msg, ByteBuf out) throws Exception;
}

可以看到，MessageToByteEncoder的輸出對(duì)象out是一個(gè)ByteBuf實(shí)例，我們應(yīng)該將泛型參數(shù)msg包含的信息寫入到這個(gè)out對(duì)象中。

MessageToByteEncoder使用案例：

public class IntegerToByteEncoder extends MessageToByteEncoder<Integer> {
    @Override
    protected void encode(ChannelHandlerContext ctx, Integer msg, ByteBuf out) throws Exception {
        out.writeInt(msg);//將Integer轉(zhuǎn)成二進(jìn)制字節(jié)流寫入ByteBuf中
    }
}

3.2 抽象類MessageToMessageEncoder

MessageToMessageEncoder同樣是一個(gè)泛型類，泛型參數(shù)I表示將需要編碼的對(duì)象的類型，編碼的結(jié)果是將信息放到一個(gè)List中。子類通過覆寫其抽象方法encode，來實(shí)現(xiàn)編碼，如下所示：

public abstract class MessageToMessageEncoder<I> extends ChannelOutboundHandlerAdapter {
   ...
   protected abstract void encode(ChannelHandlerContext ctx, I msg, List<Object> out) throws Exception;
   ...
}

與MessageToByteEncoder不同的，MessageToMessageEncoder編碼后的結(jié)果放到的out參數(shù)類型是一個(gè)List中。例如，你一次發(fā)送2個(gè)報(bào)文，因此msg參數(shù)中實(shí)際上包含了2個(gè)報(bào)文，因此應(yīng)該解碼出兩個(gè)報(bào)文對(duì)象放到List中。

MessageToMessageEncoder提供的常見子類包括：

  • LineEncoder：按行編碼，給定一個(gè)CharSequence(如String)，在其之后添加換行符\n或者\(yùn)r\n，并封裝到ByteBuf進(jìn)行輸出，與LineBasedFrameDecoder相對(duì)應(yīng)。

  • Base64Encoder：給定一個(gè)ByteBuf，得到對(duì)其包含的二進(jìn)制數(shù)據(jù)進(jìn)行Base64編碼后的新的ByteBuf進(jìn)行輸出，與Base64Decoder相對(duì)應(yīng)。

  • LengthFieldPrepender：給定一個(gè)ByteBuf，為其添加報(bào)文頭Length字段，得到一個(gè)新的ByteBuf進(jìn)行輸出。Length字段表示報(bào)文長(zhǎng)度，與LengthFieldBasedFrameDecoder相對(duì)應(yīng)。

  • StringEncoder：給定一個(gè)CharSequence(如：StringBuilder、StringBuffer、String等)，將其轉(zhuǎn)換成ByteBuf進(jìn)行輸出，與StringDecoder對(duì)應(yīng)。
    細(xì)心的讀者注意到了，這些MessageToMessageEncoder實(shí)現(xiàn)類最終輸出的都是ByteBuf，因?yàn)樽罱K在網(wǎng)絡(luò)上傳輸?shù)亩家嵌M(jìn)制數(shù)據(jù)。

在后面的章節(jié)中，我們將會(huì)對(duì)上述提到的編碼/解碼器如何使用進(jìn)行詳細(xì)的介紹。

4 編碼解碼器Codec

編碼解碼器同時(shí)具有編碼與解碼功能，特點(diǎn)同時(shí)實(shí)現(xiàn)了ChannelInboundHandler和ChannelOutboundHandler接口，因此在數(shù)據(jù)輸入和輸出時(shí)都能進(jìn)行處理。Netty提供提供了一個(gè)ChannelDuplexHandler適配器類，編碼解碼器的抽象基類 ByteToMessageCodec 、MessageToMessageCodec都繼承與此類，如下：

0BF45DAD-EA36-44E1-8946-A844F2BBCC6D.png

ByteToMessageCodec內(nèi)部維護(hù)了一個(gè)ByteToMessageDecoder和一個(gè)MessageToByteEncoder實(shí)例，可以認(rèn)為是二者的功集合，泛型參數(shù)I是接受的編碼類型：

public abstract class ByteToMessageCodec<I> extends ChannelDuplexHandler {
    private final TypeParameterMatcher outboundMsgMatcher;
    private final MessageToByteEncoder<I> encoder;
    private final ByteToMessageDecoder decoder = new ByteToMessageDecoder(){…}
  
    ...
    protected abstract void encode(ChannelHandlerContext ctx, I msg, ByteBuf out) throws Exception;
    protected abstract void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception;
    ...
}

MessageToMessageCodec內(nèi)部維護(hù)了一個(gè)MessageToMessageDecoder和一個(gè)MessageToMessageEncoder實(shí)例，可以認(rèn)為是二者的功集合，泛型參數(shù)INBOUND_IN和OUTBOUND_IN分別表示需要解碼和編碼的數(shù)據(jù)類型。

public abstract class MessageToMessageCodec<INBOUND_IN, OUTBOUND_IN> extends ChannelDuplexHandler {
   private final MessageToMessageEncoder<Object> encoder= ...
   private final MessageToMessageDecoder<Object> decoder =…
   ...
   protected abstract void encode(ChannelHandlerContext ctx, OUTBOUND_IN msg, List<Object> out) throws Exception;
   protected abstract void decode(ChannelHandlerContext ctx, INBOUND_IN msg, List<Object> out) throws Exception;
}

由于前面已經(jīng)分析了編碼器和解碼器，這里對(duì)于編碼解碼器不再進(jìn)行過多說明。在后面章節(jié)中，我們將詳細(xì)介紹不同編碼、解碼器的詳細(xì)使用方法。

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容