4. TCP粘包与拆包：问题产生原因、解决方案

聊到网络编程，有个绕不开的话题——TCP粘包与拆包。我记得刚入行那会儿，第一次写基于TCP的服务端程序，客户端发过来的数据总是对不上号。要么多条消息粘在一起，要么一条消息被拆成好几段。当时我盯着日志看了半天，还以为是网络出了问题。后来才明白，这其实是TCP的流式传输特性导致的“正常现象”。

4.1 问题产生原因

TCP是面向流的协议，它不像UDP那样有明确的消息边界。你调用send()发送了两次数据，底层可能一次就把它们全发过去了。反过来，你发了一个大包，底层可能分好几次才发完。

为什么会这样？说白了，TCP内部有个缓冲区，还有MSS（最大报文段长度）的限制。应用程序写入的数据，先放到发送缓冲区，然后TCP根据MSS大小、网络拥塞情况等因素，决定什么时候发、发多少。接收端也一样，从缓冲区里读数据，读多读少由应用程序自己控制。

我遇到过这样一个场景：客户端连续发送了三条登录请求，服务端一次就读到了整块数据。三条请求粘在一起，解析器直接懵了。这就是典型的粘包问题。

拆包问题也常见。比如你要发送一张大图片，TCP可能把它拆成多个小包发送。接收端需要多次读取才能拼完整。如果你没处理好，读到一半就开始解析，那肯定出错。

4.2 解决方案

解决粘包拆包问题，本质上就是给数据流“画边界”。我常用的方案有三种：定长法、分隔符法、长度域法。每种都有适用场景，我一个个说。

4.2.1 定长法

最简单粗暴的方式。规定每个消息固定长度，比如1024字节。发送端不够就补零，接收端每次读满1024字节再解析。

// 发送端：固定长度
byte[] data = "hello".getBytes();
byte[] fixed = new byte[1024];
System.arraycopy(data, 0, fixed, 0, data.length);
channel.write(Unpooled.wrappedBuffer(fixed));

// 接收端：每次读1024字节
ByteBuf buf = channel.read();
if (buf.readableBytes() >= 1024) {
    byte[] msg = new byte[1024];
    buf.readBytes(msg);
    // 解析消息
}

优点：实现简单，性能高。缺点：浪费带宽，小消息也要填满固定长度。我一般只在消息长度变化不大的场景用，比如心跳包、固定格式的指令。

4.2.2 分隔符法

用特殊字符标记消息结束。比如HTTP用\r\n，自定义协议可以用\n或者$$。接收端读到分隔符就知道一条消息结束了。

// 发送端：追加分隔符
String msg = "hello\n";
channel.write(Unpooled.copiedBuffer(msg, CharsetUtil.UTF_8));

// 接收端：按行读取
ByteBuf buf = channel.read();
String line = buf.toString(CharsetUtil.UTF_8);
// 按\n分割处理

优点：灵活，消息长度可变。缺点：消息内容里不能出现分隔符，否则需要转义。我曾经在一个日志采集系统里用过这个方案，消息里偶尔会包含换行符，搞得我加了一层转义逻辑，代码变得有点啰嗦。

4.2.3 长度域法

这是最通用的方案。在消息头部固定位置写入消息长度，接收端先读长度，再根据长度读取完整消息体。

// 消息格式：4字节长度 + 消息体
ByteBuf buf = Unpooled.buffer();
int bodyLen = body.length;
buf.writeInt(bodyLen);  // 写入长度
buf.writeBytes(body);   // 写入消息体

// 接收端处理
ByteBuf in = channel.read();
if (in.readableBytes() < 4) {
    return; // 长度头还没收全
}
in.markReaderIndex();
int length = in.readInt();
if (in.readableBytes() < length) {
    in.resetReaderIndex();
    return; // 消息体还没收全
}
byte[] msg = new byte[length];
in.readBytes(msg);

优点：精确、高效、支持任意二进制数据。缺点：实现稍微复杂一点。但说实话，这点复杂度完全值得。我参与过的绝大多数生产级项目，用的都是长度域法。

4.3 Netty处理方式

Netty对粘包拆包的处理非常优雅。它内置了多种解码器，你几乎不用自己写解析逻辑。我最早用Netty时，最爽的就是这一点——开箱即用。

4.3.1 定长解码器

// 服务端添加定长解码器，每1024字节为一个消息
ChannelPipeline pipeline = ch.pipeline();
pipeline.addLast(new FixedLengthFrameDecoder(1024));
pipeline.addLast(new MyHandler());

Netty的FixedLengthFrameDecoder会自动处理粘包拆包。你只需要在Handler里接收完整的消息即可。

4.3.2 分隔符解码器

// 使用换行符作为分隔符
ChannelPipeline pipeline = ch.pipeline();
pipeline.addLast(new LineBasedFrameDecoder(8192));
pipeline.addLast(new StringDecoder());
pipeline.addLast(new MyHandler());

LineBasedFrameDecoder按行分割，StringDecoder把字节转成字符串。两个配合使用，处理文本协议非常方便。

如果你需要自定义分隔符，可以用DelimiterBasedFrameDecoder：

ByteBuf delimiter = Unpooled.copiedBuffer("$$".getBytes());
pipeline.addLast(new DelimiterBasedFrameDecoder(8192, delimiter));

4.3.3 长度域解码器

这是Netty最强大的解码器，没有之一。它几乎覆盖了所有长度域场景。

ChannelPipeline pipeline = ch.pipeline();
pipeline.addLast(new LengthFieldBasedFrameDecoder(
    65535,    // 最大帧长度
    0,        // 长度字段偏移量
    4,        // 长度字段字节数
    0,        // 长度调整值
    4         // 跳过的初始字节数
));
pipeline.addLast(new MyHandler());

参数说明：

参数	说明
maxFrameLength	消息最大长度，防止内存溢出
lengthFieldOffset	长度字段在消息中的起始位置
lengthFieldLength	长度字段占用的字节数
lengthAdjustment	长度调整值，用于处理长度字段包含自身的情况
initialBytesToStrip	解析后跳过的字节数，通常跳过长度字段

我有个项目用Netty做RPC框架，消息格式是：4字节魔数 + 4字节长度 + 消息体。配置如下：

pipeline.addLast(new LengthFieldBasedFrameDecoder(
    1024 * 1024,  // 最大1MB
    4,            // 魔数占4字节，长度从第5字节开始
    4,            // 长度字段占4字节
    0,            // 长度字段不包含自身
    8             // 跳过魔数和长度字段
));

这样配置后，Handler里拿到的就是完整的消息体，不用再关心粘包拆包问题。

4.4 知识体系总览

下面这张图是我梳理的TCP粘包拆包知识体系，方便你快速回顾：

嗯，到这里TCP粘包拆包的内容就讲完了。我个人觉得，理解这个问题比记住解决方案更重要。你只要明白TCP是流式协议，没有消息边界，自然就知道为什么要“画边界”了。Netty帮我们封装好了这些细节，但底层原理还是值得掌握的——毕竟，哪天你遇到Netty搞不定的场景，还得自己动手写解码器。

可可精品资料库