摘要：是一個面向字節流的協議，它是性質是流式的，所以它并沒有分段。可基于分隔符解決。編解碼的主要目的就是為了可以編碼成字節流用于在網絡中傳輸持久化存儲。

記得前段時間我們生產上的一個網關出現了故障。

這個網關邏輯非常簡單，就是接收客戶端的請求然后解析報文最后發送短信。

但這個請求并不是常見的 HTTP ，而是利用 Netty 自定義的協議。

有個前提是：網關是需要讀取一段完整的報文才能進行后面的邏輯。

問題是有天突然發現網關解析報文出錯，查看了客戶端的發送日志也沒發現問題，最后通過日志發現收到了許多不完整的報文，有些還多了。

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

這便有了此文。

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

這就得從 TCP 這個協議說起了。

TCP 是一個面向字節流的協議，它是性質是流式的，所以它并沒有分段。就像水流一樣，你沒法知道什么時候開始，什么時候結束。

所以他會根據當前的套接字緩沖區的情況進行拆包或是粘包。

下圖展示了一個 TCP 協議傳輸的過程：

發送端的字節流都會先傳入緩沖區，再通過網絡傳入到接收端的緩沖區中，最終由接收端獲取。

當我們發送兩個完整包到接收端的時候：

正常情況會接收到兩個完整的報文。

但也有以下的情況：

接收到的是一個報文，它是由發送的兩個報文組成的，這樣對于應用程序來說就很難處理了（這樣稱為粘包）。

還有可能出現上面這樣的雖然收到了兩個包，但是里面的內容卻是互相包含，對于應用來說依然無法解析（拆包）。

對于這樣的問題只能通過上層的應用來解決，常見的方式有：

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

將消息分為消息頭、消息體。可以在消息頭中聲明消息的長度，根據這個長度來獲取報文（比如 808 協議）。

規定好報文長度，不足的空位補齊，取的時候按照長度截取即可。

以上的這些方式我們在 Netty 的 pipline 中里加入對應的解碼器都可以手動實現。

但其實 Netty 已經幫我們做好了，完全可以開箱即用。

比如：

LineBasedFrameDecoder 可以基于換行符解決。

DelimiterBasedFrameDecoder 可基于分隔符解決。

FixedLengthFrameDecoder 可指定長度解決。

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

還是在之前的

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

進行演示。

在 Netty 客戶端中加了一個入口可以循環發送 100 條字符串報文到接收端：

    /**
     * 向服務端發消息 字符串
     * @param stringReqVO
     * @return
     */
    @ApiOperation("客戶端發送消息，字符串")
    @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 ;
    }
    
    
    
    /**
     * 發送消息字符串
     *
     * @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("客戶端手動發消息成功={}", msg));

    }

服務端直接打印即可：

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

    }

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

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