1. 半包和粘包

（1）粘包现象

• 现象，发送 abc def，接收 abcdef
• 原因
  • 应用层：接收方 ByteBuf 设置太大（Netty 默认 1024）
  • 滑动窗口：假设发送方 256 bytes 表示一个完整报文，但由于接收方处理不及时且窗口大小足够大，这 256 bytes 字节就会缓冲在接收方的滑动窗口中，当滑动窗口中缓冲了多个报文就会粘包
  • Nagle 算法：会造成粘包

（2）半包现象

• 现象，发送 abcdef，接收 abc def
• 原因
  • 应用层：接收方 ByteBuf 小于实际发送数据量
  • 滑动窗口：假设接收方的窗口只剩了 128 bytes，发送方的报文大小是 256 bytes，这时放不下了，只能先发送前 128 bytes，等待 ack 后才能发送剩余部分，这就造成了半包
  • MSS 限制：当发送的数据超过 MSS 限制后，会将数据切分发送，就会造成半包

本质是因为 TCP 是流式协议，消息无边界

（3）解决方案

1. 短链接，发一个包建立一次连接，这样连接建立到连接断开之间就是消息的边界，缺点效率太低
2. 每一条消息采用固定长度，缺点浪费空间
3. 每一条消息采用分隔符，例如 \n，缺点需要转义
4. 每一条消息分为 head 和 body，head 中包含 body 的长度

这里给出第4种最优的解决方法：

LengthFieldBasedFrameDecoder的四个参数分别表示：

• 最大长度：处理一些异常情况
• 消息长度偏移：表示长度是从哪里开始的
• 消息长度占用字节：消息长度的占用了多少个字节
• 长度调整：就是说长度后面是否是真正的消息
  • 剥离字节数：剥离字节数，从这个位置，后面都是真正的消息了。把后面的消息交给下一个Handler

public static void main(String[] args) {
        // 最大长度，长度偏移，长度占用字节，长度调整，剥离字节数
        EmbeddedChannel ch = new EmbeddedChannel(
            new LengthFieldBasedFrameDecoder(1024, 0, 4,
                1,5),
            new LoggingHandler(LogLevel.DEBUG)
        );

        ByteBuf buffer = ByteBufAllocator.DEFAULT.buffer();
        send(buffer, "hello world");
        send(buffer, "Hi!");
        ch.writeOneInbound(buffer);
    }

    private static void send(ByteBuf buffer, String content) {
        byte[] bytes = content.getBytes();
        buffer.writeInt(bytes.length);
        buffer.writeByte(1);
        buffer.writeBytes(bytes);
    }