engine.io-parser 基准测试解读：packet/payload 编解码的吞吐表现与 v3 → v4 协议设计差异

本文围绕 packages/engine.io-parser/benchmarks/results.md 中记录的基准测试结果展开，逐项解读 engine.io-parser 在 encode/decode 四个维度、字符串/二进制两种负载下的吞吐数据，并对照 parser v2（协议 v3）与当前 parser（协议 v4）两组结果，结合 协议规范文档 与 源码实现，说明这些数据差异背后是哪些协议设计决策导致的，帮助读者把基准数字与协议演进、源码实现对应起来。

1. engine.io-parser 在 Socket.IO 协议栈中的位置

engine.io-parser 是 Socket.IO 仓库内负责 engine.io 协议编解码的共享包，被 packages/engine.io（服务端）与 packages/engine.io-client（客户端）共同使用，当前仓库中版本为 5.2.3（见 package.json）。它对外暴露四个核心方法：encodePacket、decodePacket、encodePayload、decodePayload，在 lib/index.ts 中定义并导出；lib/index.ts#L199 中的 export const protocol = 4; 声明了它实现的是协议 v4，与 docs/engine.io-protocol/v4-current.md 描述的 Engine.IO 协议 4.x 对应。

理解基准测试的前提是分清两个概念：

• packet（包）：engine.io 协议的最小消息单元，包含 type 与可选 data，类型映射（open=0、close=1、ping=2、pong=3、message=4、upgrade=5、noop=6）定义在 lib/commons.ts#L1-L15；
• payload（有效载荷）：多个 packet 拼接而成的传输单元。由于 HTTP 长轮询基于请求-响应模型，协议规范要求多个 packet 可以拼接在单个 payload 中以提高吞吐（见 docs/engine.io-protocol/v4-current.md 中 "Packet encoding" 一节），encodePayload/decodePayload 正是处理这种拼接与拆分。

2. 基准测试是怎么跑的

测试结果由同目录的 benchmarks/index.js 产生，它基于 benchmark npm 库构建了一个包含 8 个用例的 Suite。在仓库内执行流程为：

cd packages/engine.io-parser
npm ci
node benchmarks/index.js

脚本通过 require('..') 引入解析器主入口，每个用例的测量方式如下：

• 编码类用例（4 个）全部采用 { defer: true } 的 deferred.resolve() 模式——因为 encodePacket/encodePayload 是回调式 API，deferred 模式保证测得的是包含 base64 转换等完整工作量的端到端耗时；
• 解码类用例中，decodePacket 本身是同步函数，直接调用即可；decodePayload 则同样用 deferred 包裹；
• 每次 cycle 事件打印该用例的吞吐（ops/sec），complete 事件汇总最快项。

8 个用例覆盖了编解码矩阵的全部组合：

用例	被测 API	输入特征
encode packet as string	encodePacket({type:'message',data:'test'}, true, cb)	纯文本 data，开启 binary 支持
encode packet as binary	encodePacket({type:'message',data:Buffer.from([1,2,3,4])}, true, cb)	4 字节 Buffer
encode payload as string	encodePayload([{...data:'test1'},{...data:'test2'}], cb)	两个文本 packet 拼接
encode payload as binary	encodePayload([{...data:'test'},{...data:Buffer...}], cb)	文本 + 二进制混合拼接
decode packet from string	decodePacket('4test')	类型字符 4 + 文本
decode packet from binary	decodePacket(Buffer.from([4,1,2,3,4]))	原始字节流（无类型前缀）
decode payload from string	decodePayload('test1\x1etest2')	以 \x1e 分隔符拼接的两个 packet
decode payload from binary	decodePayload('test1\x1ebAQIDBA==','nodebuffer')	文本 + base64 二进制（b 前缀）

注意输入刻意选用了极简数据（4 字节 Buffer、单字符文本），目的是测出编解码的固有单位开销（类型解析、分隔符处理、base64 编解码路径），而不是大块数据拷贝的吞吐。

3. 当前版本（parser 5.x / 协议 v4）的基准结果

benchmarks/results.md 中 "Current" 一节记录了如下原始输出：

encode packet as string x 175,944 ops/sec ±5.64% (25 runs sampled)
encode packet as binary x 176,945 ops/sec ±16.60% (51 runs sampled)
encode payload as string x 47,836 ops/sec ±9.84% (34 runs sampled)
encode payload as binary x 123,987 ops/sec ±22.03% (53 runs sampled)
decode packet from string x 27,680,068 ops/sec ±0.92% (89 runs sampled)
decode packet from binary x 7,747,089 ops/sec ±1.65% (83 runs sampled)
decode payload from string x 198,908 ops/sec ±27.95% (23 runs sampled)
decode payload from binary x 179,574 ops/sec ±41.32% (23 runs sampled)

几个可以直接从数据读出的结论：

1. 解码 packet 是绝对热点路径，且字符串解码最快。decode packet from string 达到约 2768 万 ops/sec，误差仅 ±0.92%；这对应客户端每收到一个文本帧就要执行一次的解析，是最敏感的操作。
2. 字符串解码与二进制解码相差约 3.6 倍（27.68M vs 7.75M ops/sec）。原因是二进制路径必须走 lib/decodePacket.ts#L40-L66 的 mapBinary 类型转换分支（ArrayBuffer 切片或 Buffer.from 拷贝），而字符串路径只做一次 charAt + substring。
3. payload 编解码量级在 5 万～20 万 ops/sec，比单 packet 低一到两个数量级。这是因为 payload 路径涉及数组遍历、逐包回调/拆分以及 base64 编解码（见第 4 节源码分析），而不是简单的字符串切分。
4. 样本量（runs sampled）与误差幅度（±%）由 benchmark 库按运行时长自适应采样得出，如 decode payload from binary 的 ±41.32% 说明该项单次耗时短、采样方差大，解读时应以数量级和相对比较为准。

4. 与 parser v2 / 协议 v3 的对比

同一文件下半部分保留了历史基线（"Results from parser v2 / protocol v3"，即 Socket.IO v1/v2 时代使用的协议 v3，见 docs/engine.io-protocol/v4-current.md "History" 一节）：

encode packet as string x 228,038 ops/sec ±9.28% (40 runs sampled)
encode packet as binary x 163,392 ops/sec ±8.72% (67 runs sampled)
encode payload as string x 73,457 ops/sec ±14.83% (56 runs sampled)
encode payload as binary x 71,400 ops/sec ±3.63% (75 runs sampled)
decode packet from string x 22,712,325 ops/sec ±3.14% (90 runs sampled)
decode packet from binary x 4,849,781 ops/sec ±1.27% (87 runs sampled)
decode payload from string x 82,514 ops/sec ±49.93% (22 runs sampled)
decode payload from binary x 149,206 ops/sec ±25.90% (76 runs sampled)

将两组数据并列对比（v4 相对 v3 的吞吐变化）：

用例	parser v2 / 协议 v3	当前 parser / 协议 v4	变化
encode packet as string	228,038 ops/sec	175,944 ops/sec	下降约 23%
encode packet as binary	163,392 ops/sec	176,945 ops/sec	提升约 8%
encode payload as string	73,457 ops/sec	47,836 ops/sec	下降约 35%
encode payload as binary	71,400 ops/sec	123,987 ops/sec	提升约 74%
decode packet from string	22,712,325 ops/sec	27,680,068 ops/sec	提升约 22%
decode packet from binary	4,849,781 ops/sec	7,747,089 ops/sec	提升约 60%
decode payload from string	82,514 ops/sec	198,908 ops/sec	提升约 141%
decode payload from binary	149,206 ops/sec	179,574 ops/sec	提升约 20%

数据整体呈现"解码侧普遍受益，编码侧互有胜负"的形态：8 项中 5 项解码用例全部提升，其中 decode payload from string（约 1.4 倍）和 decode packet from binary（约 60%）提升最显著；编码侧二进制类用例提升、字符串类用例下降。

需要说明：两组数据来自不同时期的机器与运行环境，且 benchmark 库给出的误差幅度较大（最高 ±49.93%），因此这里的百分比只宜作为方向性参考，用于佐证协议演进带来的结构性差异，不宜当作跨机器的精确性能结论。

5. 数字差异背后的协议设计

5.1 类型字符替换长度前缀：解码快的根源

协议 v3 的 packet 序列化格式是 <length><data>——即先用数字字符写出 data 的长度，再跟数据本身；而 v4 改为首字符直接编码 packet 类型（0~6），data 直接跟随。v3 被取代的原因在 docs/engine.io-protocol/v4-current.md 的 "History" 一节中被明确列出：

• 计数字符的方式在不同语言中行为不一致（字符数 vs 字节数 vs 码点数），导致多语言实现困难；
• 始终用 base64 编码含二进制数据的 payload，从而"以相同方式处理所有 payload（无论是否含二进制），无需再考虑传输层"。

当前源码印证了这一设计：lib/commons.ts#L1-L8 用普通对象（Object.create(null)，注释说明"no Map = no polyfill"）维护 PACKET_TYPES 正向映射；lib/decodePacket.ts#L19-L37 的解码逻辑只需 charAt(0) 取类型、查反向映射表、substring(1) 取数据——没有长度解析、没有 parseInt、没有按长度二次切分。这正是 decode packet from string 能从 2271 万提升到 2768 万 ops/sec 的结构性原因。

编码侧同理：lib/encodePacket.ts#L3-L15 对纯字符串 packet 只做一次查表拼接 PACKET_TYPES[type] + (data || "")，没有任何长度计算。编码字符串用例 v4 相对 v3 下降，从源码结构看更可能与测试用例的输入形状、base64 路径的分支判断成本及跨环境噪声有关，而非解码路径本身的退化——这一点从两组误差幅度（±5.64% / ±9.28%）重叠较大也可以看出。

5.2 二进制 packet 的编码路径与 b 前缀

对于 ArrayBuffer/ArrayBufferView 类型的 data，lib/encodePacket.ts#L8-L12 的行为是：

if (data instanceof ArrayBuffer || ArrayBuffer.isView(data)) {
  return callback(
    supportsBinary ? data : "b" + toBuffer(data, true).toString("base64"),
  );
}

即当传输层支持二进制帧时直接透传原始字节，否则转换为 "b" + base64 文本。解码端在 lib/decodePacket.ts#L19-L26 对称地识别 b 前缀并 Buffer.from(..., "base64") 还原。基准中 decode payload from binary 用例的输入 'test1\x1ebAQIDBA==' 正是这种 base64 packet（AQIDBA== 即 [1,2,3,4] 的 base64）。

mapBinary（lib/decodePacket.ts#L40-L66）还会根据 binaryType（nodebuffer / arraybuffer，见 lib/commons.ts#L43-L46 的 BinaryType 定义）把 Buffer、ArrayBuffer、Uint8Array 之间做相互转换，覆盖 HTTP 长轮询、WebSocket 与 WebTransport 三种来源——这段类型判别与切片/拷贝就是二进制解码比字符串解码慢约 3.6 倍的主要开销。

5.3 payload 拼接：\x1e 分隔符与 base64 强制文本化

encodePayload/decodePayload 的实现见 lib/index.ts#L11-L47：

• 分隔符取 ASCII 30 字符 \x1e（Record Separator），注释引自 ASCII 分隔符惯例；
• 编码时对所有 packet 强制 supportsBinary = false（源码注释 "force base64 encoding for binary packets"），使整个 payload 保持纯字符串形态——这与协议文档 "always use base64 when encoding a payload with binary data" 的表述一致；
• 源码还特意保存初始 packets.length 快照，注释说明"部分 packet 可能在编码过程中被追加到数组"，因此以首次长度为准；
• decodePayload 逐段 decodePacket，且遇到 error 类型包时立即终止（见 lib/index.ts#L39-L45）。

payload 用例中 5 万～20 万 ops/sec 的量级，对应的就是"数组遍历 + 逐包编码 + base64 + 分隔符 join/split"这条完整链路，与单 packet 的纯查表/切分不在同一量级。

5.4 WebTransport 的流式编解码与 WebSocket 式帧头

与基准测试中 packet/payload 的"整包"API 不同，当前版本还面向 WebTransport 提供了基于 Web Streams 的流式编解码器 lib/index.ts#L49-L197（createPacketEncoderStream / createPacketDecoderStream）：

• 帧头格式借鉴 WebSocket 的 payload length 编码：长度 < 126 用 1 字节；< 65536 用 3 字节（首字节 126 + 16 位长度）；更大时用 9 字节（首字节 127 + 64 位长度）；
• 帧头最高位（0x80）标记 payload 是纯文本还是二进制（源码注释明确 "first bit indicates whether the payload is plain text (0) or binary (1)"）；
• 解码器以 READ_HEADER → READ_EXTENDED_LENGTH_16/64 → READ_PAYLOAD 的状态机跨 chunk 累积字节，并用 maxPayload 参数做上限校验；64 位长度还额外校验了是否超过 JS 安全整数（2^53 − 1），超限输出 ERROR_PACKET。

协议文档中 "Transport-specific encoding" 一节对 WebTransport 帧头（x 位 + 分段长度）有对应描述，test/index.ts 与 packages/engine.io/test/webtransport.mjs 提供了该路径的测试覆盖。虽然基准测试未直接测量流式 API，但它体现了 parser 在同一"类型位 + 变长长度头"设计思想下从整包 API 向流式场景的延伸。

6. 如何把这份基准当作参考

• 适用前提：基准在 Node.js 环境运行（package.json 声明 engines.node >= 10.0.0），测试输入是极小的固定 packet，测量的是单位操作开销而非大 payload 吞吐；浏览器侧（*.browser.ts 实现，如 lib/encodePacket.browser.ts、lib/decodePacket.browser.ts）走 ArrayBuffer/Blob 分支，数值不可直接套用；
• 解读方式：优先看数量级与同版本内相对比较（如"字符串解码比二进制解码快 3 倍多""payload 路径比 packet 路径慢 1~2 个数量级"），这些结论由源码结构直接支撑，跨环境稳定；跨版本百分比则受机器与环境噪声影响，仅作协议演进方向的佐证；
• 复现路径：按第 2 节流程运行 benchmarks/index.js 即可在本地机器上得到新数据，与 benchmarks/results.md 的结构（Current + 历史基线两段原始输出）保持一致。

综合来看，这份基准结果的价值不仅在于数字本身，更在于它量化地反映了协议 v4 的两项核心设计——类型字符替代长度前缀与payload 内二进制统一 base64 文本化——在解码热路径上换来的简化收益：解码逻辑退化为"查表 + 切片"，同时以统一格式抹平了不同传输层（HTTP 长轮询、WebSocket、WebTransport）在二进制表示上的差异。