摘要：是一個(gè)面向字節(jié)流的協(xié)議，它是性質(zhì)是流式的，所以它并沒有分段。可基于分隔符解決。編解碼的主要目的就是為了可以編碼成字節(jié)流用于在網(wǎng)絡(luò)中傳輸持久化存儲(chǔ)。

記得前段時(shí)間我們生產(chǎn)上的一個(gè)網(wǎng)關(guān)出現(xiàn)了故障。

這個(gè)網(wǎng)關(guān)邏輯非常簡單，就是接收客戶端的請(qǐng)求然后解析報(bào)文最后發(fā)送短信。

但這個(gè)請(qǐng)求并不是常見的 HTTP ，而是利用 Netty 自定義的協(xié)議。

有個(gè)前提是：網(wǎng)關(guān)是需要讀取一段完整的報(bào)文才能進(jìn)行后面的邏輯。

問題是有天突然發(fā)現(xiàn)網(wǎng)關(guān)解析報(bào)文出錯(cuò)，查看了客戶端的發(fā)送日志也沒發(fā)現(xiàn)問題，最后通過日志發(fā)現(xiàn)收到了許多不完整的報(bào)文，有些還多了。

于是想會(huì)不會(huì)是 TCP 拆、粘包帶來的問題，最后利用 Netty 自帶的拆包工具解決了該問題。

這便有了此文。

問題雖然解決了，但還是得想想原因，為啥會(huì)這樣？打破砂鍋問到底才是一個(gè)靠譜的程序員。

這就得從 TCP 這個(gè)協(xié)議說起了。

TCP 是一個(gè)面向字節(jié)流的協(xié)議，它是性質(zhì)是流式的，所以它并沒有分段。就像水流一樣，你沒法知道什么時(shí)候開始，什么時(shí)候結(jié)束。

所以他會(huì)根據(jù)當(dāng)前的套接字緩沖區(qū)的情況進(jìn)行拆包或是粘包。

下圖展示了一個(gè) TCP 協(xié)議傳輸?shù)倪^程：

發(fā)送端的字節(jié)流都會(huì)先傳入緩沖區(qū)，再通過網(wǎng)絡(luò)傳入到接收端的緩沖區(qū)中，最終由接收端獲取。

當(dāng)我們發(fā)送兩個(gè)完整包到接收端的時(shí)候：

正常情況會(huì)接收到兩個(gè)完整的報(bào)文。

但也有以下的情況：

接收到的是一個(gè)報(bào)文，它是由發(fā)送的兩個(gè)報(bào)文組成的，這樣對(duì)于應(yīng)用程序來說就很難處理了（這樣稱為粘包）。

還有可能出現(xiàn)上面這樣的雖然收到了兩個(gè)包，但是里面的內(nèi)容卻是互相包含，對(duì)于應(yīng)用來說依然無法解析（拆包）。

對(duì)于這樣的問題只能通過上層的應(yīng)用來解決，常見的方式有：

在報(bào)文末尾增加換行符表明一條完整的消息，這樣在接收端可以根據(jù)這個(gè)換行符來判斷消息是否完整。

將消息分為消息頭、消息體。可以在消息頭中聲明消息的長度，根據(jù)這個(gè)長度來獲取報(bào)文（比如 808 協(xié)議）。

規(guī)定好報(bào)文長度，不足的空位補(bǔ)齊，取的時(shí)候按照長度截取即可。

以上的這些方式我們?cè)?Netty 的 pipline 中里加入對(duì)應(yīng)的解碼器都可以手動(dòng)實(shí)現(xiàn)。

但其實(shí) Netty 已經(jīng)幫我們做好了，完全可以開箱即用。

比如：

LineBasedFrameDecoder 可以基于換行符解決。

DelimiterBasedFrameDecoder 可基于分隔符解決。

FixedLengthFrameDecoder 可指定長度解決。

下面來模擬一下最簡單的字符串傳輸。

還是在之前的

https://github.com/crossoverJie/netty-action

進(jìn)行演示。

在 Netty 客戶端中加了一個(gè)入口可以循環(huán)發(fā)送 100 條字符串報(bào)文到接收端：

    /**
     * 向服務(wù)端發(fā)消息 字符串
     * @param stringReqVO
     * @return
     */
    @ApiOperation("客戶端發(fā)送消息，字符串")
    @RequestMapping(value = "sendStringMsg", method = RequestMethod.POST)
    @ResponseBody
    public BaseResponse sendStringMsg(@RequestBody StringReqVO stringReqVO){
        BaseResponse res = new BaseResponse();

        for (int i = 0; i < 100; i++) {
            heartbeatClient.sendStringMsg(stringReqVO.getMsg()) ;
        }

        // 利用 actuator 來自增
        counterService.increment(Constants.COUNTER_CLIENT_PUSH_COUNT);

        SendMsgResVO sendMsgResVO = new SendMsgResVO() ;
        sendMsgResVO.setMsg("OK") ;
        res.setCode(StatusEnum.SUCCESS.getCode()) ;
        res.setMessage(StatusEnum.SUCCESS.getMessage()) ;
        return res ;
    }
    
    
    
    /**
     * 發(fā)送消息字符串
     *
     * @param msg
     */
    public void sendStringMsg(String msg) {
        ByteBuf message = Unpooled.buffer(msg.getBytes().length) ;
        message.writeBytes(msg.getBytes()) ;
        ChannelFuture future = channel.writeAndFlush(message);
        future.addListener((ChannelFutureListener) channelFuture ->
                LOGGER.info("客戶端手動(dòng)發(fā)消息成功={}", msg));

    }

服務(wù)端直接打印即可：

    @Override
    protected void channelRead0(ChannelHandlerContext ctx, String msg) throws Exception {
        LOGGER.info("收到msg={}", msg);

    }

順便提一下，這里加的有一個(gè)字符串的解碼器：.addLast(new StringDecoder()) 其實(shí)就是把消息解析為字符串。

    @Override
    protected void decode(ChannelHandlerContext ctx, ByteBuf msg, List