4. TCP粘包与分包

做Qt网络开发，粘包和分包是绕不开的坎儿。

我记得刚入行那会儿，写了个简单的聊天程序，客户端发"你好"，服务端收"你好"。一切正常。可当我把消息频率调高、数据量加大后，服务端突然收到一堆乱码——"你好你好你好"拼在一起，或者"你"字被切成两半。当时我一脸懵，心想TCP不是可靠传输吗？怎么还能把数据搞坏？

后来才明白，TCP的可靠性只保证数据不丢、不乱序，但它不保证消息边界。这就是粘包和分包的根源。

4.1 粘包与分包：它们到底怎么产生的？

先看一个场景。你调用QTcpSocket::write()发送了两次数据：

socket->write("Hello");
socket->write("World");

接收方可能一次收到"HelloWorld"（粘包），也可能分两次收到"Hel"和"loWorld"（分包）。

为什么会这样？

TCP是流式协议。它把数据看作一串连续的字节流，没有天然的分隔标记。底层协议栈为了效率，会把多个小数据包合并成一个TCP段发送（Nagle算法），或者把一个大数据包拆成多个段发送（MSS限制）。

我在项目中遇到过最典型的场景：服务端同时处理上千个客户端，每个客户端每秒上报几十条状态数据。如果不处理粘包，服务端解析出来的数据全是错位的，轻则业务异常，重则内存崩溃。

4.2 三种主流解决方案

解决思路其实就一句话：让接收方能准确找到每条消息的起止位置。业界常用的方法有三种，我一个个说。

4.2.1 固定长度法

最简单粗暴。约定每条消息都是固定字节数，比如1024字节。接收方每次读满1024字节，就解析一条。

// 发送方
QByteArray data = "Hello";
data.resize(1024);  // 不足补0
socket->write(data);

// 接收方
const int MSG_LEN = 1024;
while (socket->bytesAvailable() >= MSG_LEN) {
    QByteArray msg = socket->read(MSG_LEN);
    // 解析msg
}

优点：实现简单，解析效率高。
缺点：浪费带宽。如果消息只有10字节，也得凑够1024。而且消息长度不能超过固定值，灵活性差。

我个人习惯在嵌入式设备通信或传感器数据采集这类场景用固定长度。数据格式统一，长度可控，省心。

4.2.2 特殊分隔符法

每条消息末尾加一个特殊标记，比如换行符\n或自定义的0xFF 0xFE。接收方读到分隔符就认为一条消息结束。

// 发送方
socket->write("Hello\n");
socket->write("World\n");

// 接收方
while (socket->canReadLine()) {
    QByteArray line = socket->readLine();
    line.chop(1);  // 去掉换行符
    // 处理line
}

Qt的QTextStream和canReadLine()天然支持这种模式，写起来很顺手。

优点：实现简单，消息长度灵活。
缺点：需要遍历每个字节查找分隔符，性能略低。如果数据体包含分隔符，必须转义。

4.2.3 长度前缀法（最推荐）

每条消息前面加一个固定长度的头部，头部里记录消息体的长度。接收方先读头部，拿到长度，再读对应字节数的消息体。

// 发送方
QByteArray body = "Hello";
QByteArray header;
header.append((body.size() >> 24) & 0xFF);
header.append((body.size() >> 16) & 0xFF);
header.append((body.size() >> 8) & 0xFF);
header.append(body.size() & 0xFF);
socket->write(header + body);

// 接收方
const int HEADER_LEN = 4;
while (socket->bytesAvailable() >= HEADER_LEN) {
    QByteArray header = socket->peek(HEADER_LEN);
    int bodyLen = (unsigned char)header[0] << 24 |
                  (unsigned char)header[1] << 16 |
                  (unsigned char)header[2] << 8  |
                  (unsigned char)header[3];
    if (socket->bytesAvailable() < HEADER_LEN + bodyLen)
        break;  // 数据还没收全，等下一次
    socket->read(HEADER_LEN);  // 丢弃头部
    QByteArray body = socket->read(bodyLen);
    // 处理body
}

注意这里用了peek()而不是read()。先偷看头部，确认数据完整后再真正读取。这是避免分包的关键技巧。

优点：效率高，不浪费带宽，消息长度灵活。工业级协议（如HTTP/2、MQTT）都用这种方式。
缺点：实现稍微复杂一点。

4.3 Qt中的实现技巧

光讲理论不够，我分享几个Qt实战中的小技巧。

4.3.1 用缓冲区管理未处理数据

不要每次收到readyRead()信号就直接解析。因为一次readyRead()可能只收到半个包。正确的做法是：

class MySocket : public QObject {
    Q_OBJECT
public:
    MySocket(QTcpSocket* socket) : m_socket(socket) {
        connect(m_socket, &QTcpSocket::readyRead, this, &MySocket::onReadyRead);
    }

private slots:
    void onReadyRead() {
        m_buffer.append(m_socket->readAll());
        // 从m_buffer中解析完整消息
        parseBuffer();
    }

private:
    void parseBuffer() {
        // 用长度前缀法解析m_buffer
        // 解析完的消息从m_buffer中移除
    }

    QTcpSocket* m_socket;
    QByteArray m_buffer;
};

把m_buffer作为累加缓冲区，每次收到数据先追加进去，再尝试解析。这样无论分包多严重，都能正确处理。

4.3.2 善用QDataStream

Qt的QDataStream内置了长度前缀机制。如果你用它来序列化数据，粘包问题自动解决。

// 发送方
QByteArray data;
QDataStream out(&data, QIODevice::WriteOnly);
out << QString("Hello") << (qint32)42;
socket->write(data);

// 接收方
QDataStream in(socket);
while (!in.atEnd()) {
    QString str;
    qint32 num;
    in >> str >> num;
    // 处理str和num
}

QDataStream会在写入时自动添加长度信息，读取时自动处理分包。不过要注意：它默认使用大端序，且有自己的格式版本。如果你需要和其他语言通信，可能不兼容。

4.3.3 性能优化：一次读取 vs 多次读取

有些同学喜欢在readyRead()里用readAll()一次读完所有数据。这没问题，但如果数据量很大（比如几MB），readAll()会分配大块内存，可能造成卡顿。

我习惯的做法是：先peek()头部，计算消息长度，然后只读取需要的字节数。这样内存分配可控，也避免了不必要的拷贝。

4.4 知识体系总览

下面这张图总结了本章的核心逻辑，帮你快速建立知识框架：

这张图把本章的知识点串起来了。从问题根源出发，到三种解决方案的对比，再到Qt实战技巧，一目了然。

4.5 小结

粘包和分包不是洪水猛兽。理解了TCP的流式本质，选对方案，再配合Qt提供的工具，处理起来其实很顺手。

我个人最常用的是长度前缀法，配合QByteArray缓冲区做累加解析。如果你刚开始接触，建议从固定长度法入手，先跑通流程，再逐步升级方案。

嗯，关于粘包分包就聊这么多。下一章我们聊聊更高级的话题——但那是后话了。