拆包和沾包

是典型的拆包和沾包問題，俗話說就是兩端通信，一端發(fā)送一端接收，接收的那一端怎么知道是否已經(jīng)完整的接收了數(shù)據(jù)？

假設服務端連續(xù)發(fā)送了兩條消息：hello world! / hello client!

由于客戶端不知道怎么才算一條消息，怎么才算兩條消息，所以讀取會有以下幾種情況：

1.分兩次讀取消息，第一次是hello world!，第二次是hello client!   這是正常情況

2.一次就讀取完成，hello world!hello client!                  這種情況就叫沾包

3.分兩次讀取消息，第一次是hello ，第二次是world!hello client!   這第一次讀取就是拆包，第二次就是沾包

總之就是讀取到的信息不完整就是拆包，讀取到的信息有額外多的信息就是沾包

演示

我們接著上一章的代碼來演示，我們只需要讓客戶端發(fā)送消息的時候循環(huán)發(fā)送100次，服務端不變，看看服務端是不是接收到了100條消息

NettyClientTestHandler

結果如下：

這明顯就不對吧

解決方案

要怎么解決這種問題呢？

1. 消息定長，每條消息都固定長度，不夠則補空格
2. 添加分隔符，等于是為每條消息都增加一個結束標識
3. 將消息分為消息頭和消息體，消息頭固定長度，里面包含整條消息的長度或者消息體的長度
4. 更復雜的協(xié)議約定

下面我們通過Netty中幾種內置的解碼器來解決這種問題：

• LineBasedFrameDecoder：行分隔符解碼器(結尾根據(jù) “\n” 作為結束標識)
• DelimiterBasedFrameDecoder：自定義分割器解碼器，結尾根據(jù)什么作為結束標識可以自定義
• FixedLengthFrameDecoder：固定長度解碼器，發(fā)送的消息需要定長
• LengthFieldBasedFrameDecoder：基于長度的自定義解碼器，比較靈活

注意：所有編解碼在Netty中都是數(shù)據(jù)處理管道當中的一個數(shù)據(jù)處理器而已

LineBasedFrameDecoder

這個是采用行分隔符來解決，所以我們需要改兩個地方

1.發(fā)送消息的時候，消息結尾要加上行分隔符（接著上面的例子來）

2.服務端接收消息，需要在管道內加入解碼器

LineBasedFrameDecoder：傳入的參數(shù)是消息最大長度，發(fā)送消息的大小必須小于設置值

結果如下：

DelimiterBasedFrameDecoder

這個跟上面一樣，只不過分隔符我們可以自定義

1.發(fā)送消息的時候，消息結尾要加上分隔符（這里我們定義分隔符是 “$$”）

2.服務端接收消息，需要在管道內加入解碼器

結果如下：

FixedLengthFrameDecoder

會按照設置的固定字節(jié)大小來切割消息

1.這里我們正常的發(fā)送消息就好了

2.服務端接收消息，需要在管道內加入解碼器

結果如下：

LengthFieldBasedFrameDecoder

這個是需要重點介紹一下的，上面三個解碼器明顯的看到不夠靈活，太過于死板，我們看看這個怎么用

源代碼構造如下

public LengthFieldBasedFrameDecoder(int maxFrameLength, int lengthFieldOffset, int lengthFieldLength, int lengthAdjustment, int initialBytesToStrip) {
    this(maxFrameLength, lengthFieldOffset, lengthFieldLength, lengthAdjustment, initialBytesToStrip, true);
}

參數(shù)含義：

• maxFrameLength：最大幀長度。也就是可以接收的數(shù)據(jù)的最大長度。如果超過，此次數(shù)據(jù)會被丟棄
• lengthFieldOffset：長度域偏移量。存儲數(shù)據(jù)長度的一個偏移量
• lengthFieldLength：長度域字節(jié)數(shù)。存儲數(shù)據(jù)長度的一個大小
• lengthAdjustment：數(shù)據(jù)長度修正。因為長度既可以代表data的長度，也可以是整個消息的長度
• initialBytesToStrip：跳過的字節(jié)數(shù)?？梢赃x擇舍棄一部分數(shù)據(jù)

這參數(shù)前三個可以比較好理解，后兩個是干嘛的？沒關系我們一步一步來，后兩個先不用

假設我們要發(fā)送一個消息，結構為：消息頭+數(shù)據(jù)長度+數(shù)據(jù)（Hello Server）

看看我們要怎么設置：

整體消息長度：20個字節(jié)、數(shù)據(jù)data長度：12字節(jié)
首先我們要找到長度域，所以要往右讀取4個字節(jié)：      lengthFieldOffset設置為4
然后需要讀取數(shù)據(jù)的長度，所以需要再往右讀4個字節(jié)：   lengthFieldLength設置為4
之后會根據(jù)上面讀取到的數(shù)據(jù)長度再往后讀取數(shù)據(jù)：
假設這里數(shù)據(jù)長度是12，則會繼續(xù)往后讀取12個字節(jié)
至此數(shù)據(jù)就全讀取完了（lengthAdjustment和initialBytesToStrip都設置成0的情況下）

下面我們演示一下：

NettyClientTestHandler

客戶端發(fā)送消息，結構為：消息頭+數(shù)據(jù)長度+數(shù)據(jù)

@Override
    public void channelActive(ChannelHandlerContext ctx) throws Exception {
        String data= "Hello Server";
        ByteBuf buffer = Unpooled.buffer();
        // 請求頭 4字節(jié)
        buffer.writeInt(666);
        // 數(shù)據(jù)長度 4字節(jié)
        buffer.writeInt(data.getBytes().length);
        // 然后寫入數(shù)據(jù)
        buffer.writeBytes(Unpooled.copiedBuffer(data, CharsetUtil.UTF_8));
        // 寫入并發(fā)送 完整的數(shù)據(jù)為  666+12+Hello Server
        ctx.writeAndFlush(buffer);
        SocketAddress socketAddress = ctx.channel().remoteAddress();
        log.info(socketAddress + " 已連接");
    }

NettyServerTestHandler

服務端按照結構解析消息

@Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
        // 和NIO一樣有緩沖區(qū) ByteBuf就是對ByteBuffer做了一層封裝
        ByteBuf msg1 = (ByteBuf) msg;
        // 讀取請求頭
        log.info("請求頭：" + msg1.readInt());
        // 讀取長度
        int i = msg1.readInt();
        log.info("數(shù)據(jù)長度：" + i);
        // 讀取數(shù)據(jù)
        log.info("客戶端信息：" + msg1.readBytes(i).toString(CharsetUtil.UTF_8));
    }

服務端編碼設置

結果如下：

initialBytesToStrip參數(shù)的作用

像上面這樣沾包拆包的問題解決了，但是有一個點很麻煩，就是每次讀取消息都需要一步一步的拆解消息，能不能把消息體前面無用的數(shù)據(jù)直接舍棄掉，只保留有用的數(shù)據(jù)部分呢？

可以！initialBytesToStrip參數(shù)就是可以在數(shù)據(jù)讀取完后，可以選擇跳過多少字節(jié)（你可以理解為舍棄，這樣簡單點），就像上面這個例子，我不需要請求頭和數(shù)據(jù)長度的8個字節(jié)，我只需要后面的數(shù)據(jù)體，所以我可以將initialBytesToStrip設置成8

改動兩個地方

服務端就不需要再拆解了，直接讀取

lengthAdjustment參數(shù)的作用

上面我們知道了最后會根據(jù)長度域里面的數(shù)據(jù)來決定再往后讀取多少個字節(jié)，這里我們設置的數(shù)據(jù)長度是12，所以剛剛好往后讀取了12個字節(jié)，讀取完成了，要是我設置的數(shù)據(jù)長度不是12呢？那往后讀取多少個字節(jié)，這個是不是需要修正？

所以lengthAdjustment的作用就是來修正最終往后讀取多少個字節(jié)

假設我設置的數(shù)據(jù)長度是20，代表了整個消息體的長度，但是我數(shù)據(jù)卻只有12個字節(jié)，這往后讀20個字節(jié)無疑是錯的，所以我們需要修正，怎么修正？ 減8唄，對吧

所以最終往后讀取多少個字節(jié)=數(shù)據(jù)長度+lengthAdjustment像上面為例，我們就需要設置成-8

總結

這章主要介紹了解碼器的作用，沾包拆包的問題，但是還是存在一些問題：

每次發(fā)送消息都要寫特定格式，是不是太麻煩了？（自定義編碼器）現(xiàn)在傳輸都是簡單的字符串，實際都是實體類對象，這咋搞？（序列化和反序列化）

之后再介紹怎么自定義協(xié)議解決這些問題

到此這篇關于Netty中解碼器的作用及實現(xiàn)詳解的文章就介紹到這了,更多相關Netty解碼器內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論