摘要：是一個面向字節(jié)流的協(xié)議，它是性質(zhì)是流式的，所以它并沒有分段?？苫诜指舴鉀Q。編解碼的主要目的就是為了可以編碼成字節(jié)流用于在網(wǎng)絡(luò)中傳輸持久化存儲。

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

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

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

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

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

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

這便有了此文。

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

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

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

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

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

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

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

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

但也有以下的情況：

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

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

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

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

將消息分為消息頭、消息體?？梢栽谙㈩^中聲明消息的長度，根據(jù)這個長度來獲取報文（比如 808 協(xié)議）。

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

以上的這些方式我們在 Netty 的 pipline 中里加入對應(yīng)的解碼器都可以手動實現(xiàn)。

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

比如：

LineBasedFrameDecoder 可以基于換行符解決。

DelimiterBasedFrameDecoder 可基于分隔符解決。

FixedLengthFrameDecoder 可指定長度解決。

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

還是在之前的

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

進(jìn)行演示。

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

    /**
     * 向服務(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("客戶端手動發(fā)消息成功={}", msg));

    }

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

    @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