TCP 粘包：本质分析与解决方案

很多人把「粘包」当成 TCP 的 bug，但实际上 TCP 真的不背这个锅。理解粘包，以及如何正确地在应用层处理消息边界。

首先，粘包并不是 TCP 的问题。搜索引擎中列出的各种关于”TCP 粘包问题”的文章，所讲的其实是采用 TCP 传输数据的应用层协议设计不合理导致的粘包问题，并不是 TCP 的锅。

TCP 是流协议，没有粘包这个概念。

所谓粘包问题，是指发送方的多条消息，在传输到接收方时，由于被拼接在一起而导致无法解析的情况。要解决这一问题，需要合理设计应用层协议，约定好消息边界，以便即使多条消息被拼接在一起，也能够按照协议找到消息边界从而正确解析。

之所以很多人将粘包问题看作是 TCP 造成的，是因为“拼接”这一行为发生在 TCP 层。通过 TCP 发送和接收的数据，均为数据流格式。当应用层协议使用 TCP 协议传输数据时，TCP 协议很可能将应用层发送的消息分成多个包依次发送或将多条消息组合后发送，这就会出现接收方收到的一个数据段可能由多条消息组成，即粘包。

而实际情况是，TCP 本就是基于字节流而不是消息包的协议，它保证的是字节流的次序到达，对于字节流的解析应该是由应用层协议来完成的，所以粘包问题，实际上描述的是”如何设计应用层协议”的问题。

graph LR
    subgraph 发送端
        A["消息 A"] -->|TCP| B[字节流]
        C["消息 B"] -->|TCP| B
        D["消息 C"] -->|TCP| B
    end

    subgraph TCP 层
        B -->|可能合并/拆分| E[传输单元]
    end

    subgraph 接收端
        E -->|字节流| F[应用层缓冲区]
        F -->|无边界标识| G["粘在一起：A+B+C"]
    end

    style G fill:#ffcccc

解决方案

应用层可以通过以下几种方式界定消息边界：

方案	原理	适用场景
固定长度	每个消息都是固定长度	简单，但浪费带宽
长度前缀	先发长度，再发数据	通用方案
分隔符	消息间用特殊字符分隔	文本协议（如 HTTP）
混合	长度+分隔符	复杂协议

// 长度前缀方案示例
// 发送端
const send = (socket, message) => {
  const data = JSON.stringify(message);
  const length = Buffer.byteLength(data);
  const lengthBuffer = Buffer.alloc(4);
  lengthBuffer.writeUInt32BE(length);
  socket.write(lengthBuffer);
  socket.write(data);
};

// 接收端
const buffer = Buffer.alloc(0);
socket.on('data', (chunk) => {
  buffer = Buffer.concat([buffer, chunk]);
  while (buffer.length >= 4) {
    const length = buffer.readUInt32BE(0);
    if (buffer.length >= 4 + length) {
      const message = JSON.parse(buffer.slice(4, 4 + length).toString());
      buffer = buffer.slice(4 + length);
      console.log('收到消息:', message);
    } else {
      break;
    }
  }
});

解决方案

相关阅读