Swoole怎样配置TCP底层拆包规则

作者:袖梨 2026-07-03
Swoole默认不拆包,因TCP是字节流协议,无法自动识别消息边界;必须显式配置open_length_check或open_eof_check才能按长度或结束符拆包。

必须显式配置 open_length_checkopen_eof_check,否则 Swoole 不会做任何拆包,onReceive 收到的就是原始 TCP 流数据。

为什么默认不拆包?

TCP 本身是字节流协议,Swoole 不可能猜出你的业务协议格式。它不会自动识别“消息边界”,也不会尝试解析 JSON、XML 或自定义结构。所有拆包逻辑都依赖你明确告诉它:长度在哪、结束符是什么、最大能收多大。

常见错误现象:onReceive 里收到半条消息、两条消息拼在一起、或带乱码的截断数据 —— 这不是 bug,是你没配拆包规则。

  • 没开 open_length_check 且没设 package_eof → 完全无拆包,纯裸流
  • 开了 open_eof_check 但数据里混入了 package_eof → 错误切分,后续全乱
  • 开了 open_length_checkpackage_length_offset 填错 → 读到错误字节当长度,直接截出垃圾数据

open_length_check 配固定包头协议(推荐)

这是生产环境最稳的方式,尤其适合二进制或含任意字节的数据。核心是让 Swoole 知道:长度字段在哪、占几个字节、包体从哪开始。

假设协议是「前 4 字节为包体长度(大端 uint32),后面是真实数据」:

$server->set([    'open_length_check' => true,    'package_length_type' => 'N',           // 4 字节无符号大端整数    'package_length_offset' => 0,           // 长度值从第 0 字节开始    'package_body_offset' => 4,             // 包体从第 4 字节开始    'package_max_length' => 81920,          // 防止恶意超长包吃光内存]);

注意点:

  • package_length_type 必须和 pack() 时用的一致:比如客户端用 pack('n', $len)(2 字节短整型),这里就得填 'n'
  • package_body_offset 不等于包头长度:如果包头共 16 字节,长度字段在第 12~15 字节,则 package_length_offset12package_body_offset16
  • package_max_length 是硬限制,超长包会被直接丢弃,不触发 onReceive

open_eof_check 配文本类简单协议

只适用于纯文本、且能确保业务数据中绝不出现在 package_eof 的场景,比如日志推送、命令行交互。

配置示例(以换行符为界):

$server->set([    'open_eof_check' => true,    'package_eof' => "n",    'open_eof_split' => true,  // 让 Swoole 自动剥离 EOF 并分发完整消息]);

关键约束:

  • 客户端每次 send() 必须带上 n,漏了就卡住不触发 onReceive
  • 如果关掉 open_eof_splitonReceive 收到的数据仍含 n,得自己 explode("n", $data) 处理,还要处理跨包换行(比如 "hellonworld" 被拆成 "hellon""world"
  • HTTP、JSON、XML 等含换行的内容,绝对不要用此方式

UDP 和 WebSocket 不走同一套机制

TCP 的 open_length_check / open_eof_check 对 UDP 无效。UDP 是报文边界天然存在的协议,每个 onPacket 收到的就是一个独立 UDP 包 —— 但你要自己校验完整性(比如加 CRC、重传逻辑)。

WebSocket 更特殊:onMessage 已经是解帧后的完整文本或二进制帧,Swoole 内部已按 WebSocket 协议完成分帧与重组,**不能也不该再配 open_length_check**。强行配了会冲突甚至崩溃。

最容易被忽略的是:不同传输层(TCP/UDP/WebSocket)的事件回调入口、缓冲区行为、错误恢复策略完全不同。别把 TCP 的配置复制粘贴到 UDP Server 上试。

相关文章

精彩推荐