問題來源：

    在Netty中對於TCP傳輸的預設資料大小為1024位元組，當資料包不超過1024時，會一次接收完畢，當超過1024時，首先會進行拆分，即分成幾次傳輸，等到下次連線時將會改變一次發包的資料大小為2048位元組，然後下次增長為3072位元組，然後下次增長為4096位元組；然而，再往下增長，則增長了2048位元組變為6144位元組，然後變為8192位元組（8KB），當資料再大時，接收到的資料包也不再改變。此後，只要傳送的資料包大小不超過8192位元組，便不再分包。

    當一次連線的資料被分成幾次進行傳輸時就帶來一個問題：channelPipeline會把資料儲存起來，然後每一次收到服務端發回來的資料時，將會觸發一次channelRead方法，然後就會對收到的資料進行解析（因為此刻認為資料已經傳輸完畢，然而實際並沒有），那麼因為是拆分的資料所以就會導致解析失敗！

解決方案：

    在初始化bootstrap（啟動器）時，要進行handler的註冊，handler是以責任鏈的設計模式設計的，即channel讀取時按照頭handler——尾handler的流程，channel寫入時按照尾handler——頭handler的流程。所以我們必須在觸發channelRead方法前先對資料進行處理，所以提出以下解決方案：在處理資料的handler之前註冊一個decode的handler來保證接受到的資料的完整性。

    這裡的decode方法繼承自ByteToMessageDecoder類。因為專案開發基於騰訊的Tars框架，從Tars框架原始碼（https://github.com/Tencent/Tars）中我們可以看到：

public static IoBuffer encodeResponse(TarsServantResponse response, String charsetName) throws ProtocolException {
    ……
    ……
    ByteBuffer buffer = jos.getByteBuffer();
    int datalen = buffer.position();
    buffer.position(0);
    buffer.putInt(datalen);
    buffer.position(datalen);
    return IoBuffer.wrap(jos.toByteArray());
}
 

    在encodeResponse方法中，最後將整個資料長度放入了緩衝區的開頭。那麼我們在decode的時候就可以先讀取資料的長度，然後限制資料的讀入長度，得到完整的資料後再進行處理。處理框圖如下：

    具體程式碼如下：

public class CommunicateDecoder extends ByteToMessageDecoder {

    protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
        int length = in.getInt(0);
//        Logs.access.info(">>>>>>>>> length is : {}", length);
        if(in.readableBytes() >= length) {
//            Logs.access.info(">>>>>>>>> in is : {}", in);
            ByteBuf unPool = Unpooled.buffer(length);
            in.readBytes(unPool, length);
//            Logs.access.info(">>>>>>>>> in after read is : {}", in);
//            Logs.access.info(">>>>>>>>> unPool is : {}", unPool);
            out.add(unPool); // unPool
//            Logs.access.info(">>>>>>>>> ready to send!");
        }

    }

}