4. 特殊分隔符方案

粘包拆包这个问题，说白了就是TCP这个"搬运工"太实在了。它只管把数据流一股脑儿丢给你，才不管你的消息边界在哪。那怎么办？我们得自己给消息画个"分界线"。

特殊分隔符方案，就是最直观的一种做法。我早期做嵌入式网络通信时，用的就是这招。简单、粗暴、有效。

4.1 核心思想：给消息贴上"结束标签"

想象一下，你收到一长串字符：

HelloWorldHowAreYou

你能分清哪几个单词是一组吗？不能。但如果改成这样：

Hello\nWorld\nHowAreYou\n

是不是一目了然？每个 \n 就是一条消息的结束标记。

这就是特殊分隔符方案的核心——在每条消息的末尾，插入一个约定的特殊字符（或字符序列），接收方只要读到这个字符，就知道一条消息结束了。

关键点：分隔符必须保证不会出现在消息正文中。否则就会发生"误判"——把消息内容当成了边界。

4.2 常见分隔符选择

分隔符 典型场景 优点 缺点
\n（换行符） 文本协议、HTTP头部 简单、人类可读 消息内不能有换行
\r\n（回车换行） FTP、SMTP、HTTP协议 兼容Windows换行标准 多一个字节开销
\0（空字符） C语言字符串传输 与字符串处理天然契合 二进制数据中可能包含\0
自定义序列（如$$$） 私有协议 可避免与正文冲突 需要额外约定

我个人习惯，在文本协议中首选 \n。为什么？因为它够简单。你想想看，调试的时候用telnet直接敲命令，每条命令后面加个回车，服务端就能正确解析。多方便。

4.3 发送端：如何正确添加分隔符

发送端的工作其实很简单：在每条消息的末尾，拼接上约定的分隔符。

来看一段Java代码示例：

public class DelimiterClient {
    private static final String DELIMITER = "\n";

    public void sendMessage(String message) {
        // 关键：在消息末尾追加分隔符
        String framedMessage = message + DELIMITER;
        try {
            socket.getOutputStream().write(framedMessage.getBytes());
            socket.getOutputStream().flush();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

嗯，这里要注意：一定要 flush()。我遇到过好几次，数据没刷出去，客户端和服务端都在干等。你排查半天，最后发现是缓冲区没刷新——这种坑，踩过一次就记住了。

4.4 接收端：如何正确解析并处理粘包

接收端才是重头戏。因为TCP是流式协议，你收到的数据可能是：

  • 一条完整消息：正好包含一个分隔符
  • 多条消息粘在一起：包含多个分隔符
  • 半条消息：分隔符还没到，数据不完整

所以接收端必须有一个缓冲区，把每次收到的数据暂存起来，然后不断扫描分隔符。

核心逻辑如下：

public class DelimiterServer {
    private static final String DELIMITER = "\n";
    private StringBuilder buffer = new StringBuilder();

    public void onDataReceived(byte[] data) {
        // 1. 将新数据追加到缓冲区
        buffer.append(new String(data));

        // 2. 循环扫描分隔符
        while (true) {
            int delimiterIndex = buffer.indexOf(DELIMITER);
            if (delimiterIndex == -1) {
                // 没有找到分隔符，说明消息还不完整，等待下一次数据
                break;
            }

            // 3. 提取出一条完整消息
            String message = buffer.substring(0, delimiterIndex);
            // 4. 从缓冲区中移除已处理的部分（包括分隔符）
            buffer.delete(0, delimiterIndex + DELIMITER.length());

            // 5. 处理这条消息
            processMessage(message);
        }
    }

    private void processMessage(String message) {
        System.out.println("收到完整消息: " + message);
    }
}

这段代码，我建议你多看两遍。它解决粘包的思路其实就三步：

  1. 攒数据：把零散的数据包拼到缓冲区里
  2. 找边界：在缓冲区里找分隔符
  3. 切消息：找到一条就切一条，切完继续找下一条

小技巧：如果消息量很大，用 StringBuilder 的 indexOf 可能效率不高。你可以考虑用 ByteArrayOutputStream 配合字节级别的扫描，性能会好很多。

4.5 避坑指南：我曾经踩过的三个坑

坑一：分隔符出现在消息正文中

我曾经做过一个聊天室，用 \n 做分隔符。结果用户发了一条消息，里面带了个换行。好家伙，服务端直接把它拆成了两条消息。解决方案？要么对正文中的分隔符做转义（比如用 \\n 代替 \n），要么选一个几乎不会出现在正文中的分隔符。

坑二：缓冲区无限增长

如果客户端一直不发分隔符，服务端的缓冲区就会一直膨胀，最后撑爆内存。一定要设置最大缓冲区大小，超过阈值就断开连接或丢弃数据。

坑三：分隔符跨包

假设分隔符是 \r\n，第一次收到 Hello\r，第二次收到 \nWorld。分隔符被拆到了两个包里。你的扫描逻辑必须能处理这种情况——缓冲区里先攒着 Hello\r，等 \n 到了，才能拼出完整的分隔符。

重要提醒：特殊分隔符方案虽然简单，但它不适合传输二进制数据。因为二进制数据里可能包含任意字节值，你很难保证分隔符不会"撞车"。二进制场景，请考虑长度前缀方案。

4.6 适用场景总结

特殊分隔符方案，最适合以下场景：

  • 文本协议：如HTTP、FTP、SMTP等
  • 日志收集：每条日志一行，用换行符分隔
  • 命令行交互：每条命令以回车结束
  • 简单RPC：消息量不大，追求开发效率

说白了，如果你传输的是人类可读的文本，而且你能控制消息内容不包含分隔符，那这方案就是你的首选。简单、直观、好调试。

但如果你的消息里可能包含任意字节，或者你对性能要求极高，那还是看看其他方案吧。

特殊分隔符方案：粘包拆包处理流程 发送端 消息 + 分隔符 TCP传输 可能粘包/拆包 接收端缓冲区 暂存所有收到的数据 扫描分隔符 ✅ 找到分隔符 提取完整消息，从缓冲区移除 ❌ 未找到分隔符 等待下一次数据到达 循环处理，直到缓冲区中没有完整消息 输出完整消息

这张图把整个流程串起来了。你从发送端开始看，消息加上分隔符后进入TCP传输。接收端把数据攒到缓冲区里，然后不断扫描分隔符。找到了就切出一条消息，没找到就继续等。循环往复，直到缓冲区里没有完整消息为止。

嗯，这就是特殊分隔符方案的全部了。简单，但很实用。

← 上一章 📖 返回目录 下一章 →