百倍正则加速：让 Yak 中的正则支持统一编译与完整 PCRE2

原创

YAK
YAK

Yak Project

2026年7月10日 17:26
湖南

在小说阅读器读本章

去阅读

两项自研工作重做 Yaklang / Yakit 的正则路径：go-pcre2-lite 将单条正则引擎替换为完整 PCRE2，minirehs/rehs 让成百上千条正则支持\"统一编译、一次扫描\"。

前者降低单条匹配的成本并扩展可编译范围，后者将多正则的复杂度由乘性转为加性——两者在 Yakit MITM 内置规则场景中叠加生效。

除特别标注外，性能数字为本机（darwin/arm64, Apple Silicon）第一手实测；图 3 左半为 go-pcre2-lite 仓库自带基准。

图三

摘要

Yakit MITM 会在每一条经过的报文上执行一批内置规则（指纹识别、组件染色、敏感信息提取）。旧路径存在两个长期问题：

其一是正则语法能力不足——标准库 RE2 不支持 lookaround/backreference，大量从 JS/PHP/.NET 移植的正则直接编译失败，而兜底引擎默认永不超时，单条异常正则即可导致代理无响应；其二是成本随规则数线性增长——数十至上百条正则对每条报文逐条全量匹配，成本为\"规则数 × 报文字节\"的乘积。

本次改造从两层同时入手：单条正则层采用 go-pcre2-lite（完整 PCRE2、JIT 关闭、dlclark/regexp2 的 drop-in 替代，布尔匹配零分配、ReDoS 默认有界、语法更全）；多正则层采用 minirehs 将所有规则统一编译为单一引擎，每条报文仅扫描一次。

在真实 MITM 规则集（87 条）+ 真实流量（~5MB / 1332 报文）上，存在性打标由现状 0.19 MB/s 提升至 6.10 MB/s（约 32×）；在字面量友好的合成集上，加速比随规则数从 50 条的 11.6× 增长至 1000 条的 83.6×。

改造前后速览（数据来源见后文对应章节）：

一、背景与问题：Yakit 旧时代的正则困境

Yakit MITM 长期存在的正则相关问题可归纳为四类：

• 语法能力受限：MITM 默认使用标准库 RE2。RE2 为保证线性时间复杂度，不支持 lookaround、backreference 等构造。从 JS/PHP/.NET 项目移植的正则常因此编译失败，只能改写或弃用。
• 回溯不可控：RE2 无法表达的规则回退到 dlclark/regexp2，该引擎默认 MatchTimeout = 永不超时；对抗性正则遇到构造性输入时会持续回溯直至挂起，表现为 CPU 占满、代理无响应。
• 匹配成本随规则数线性增长：MITM 内置数十条规则，实现为\"对每条报文将每条正则各匹配一次\"。报文体积与规则数增大时吞吐显著下降，这是\"多正则一次匹配随规模劣化\"的根因。
• 内存开销偏高：dlclark 在匹配热路径上每次都将整段输入复制为 []rune，长时间运行时 GC 压力较大。

上述问题在真实规则集上并非均匀分布，而是集中于少数规则。以 rule4yak 87 条内置规则为例，其中含 lookahead 的 URL 识别类规则在 RE2 下直接编译失败，旧路径只能整体回退到 dlclark/regexp2 并对每条报文全量执行；这类 regexp2-only 规则仅约 2–3 条，却在切换前贡献了定位路径约 35% 的 CPU 与约 74% 的分配（getRunes 的整段 []rune 复制）。即少量重规则主导了整体开销。

将上述问题归结为成本模型，MITM 染色/提取的总成本为：

总成本 ≈ N_packets × N_rules × 单条正则匹配成本

由此可得两条正交的优化路径：降低单条正则匹配成本，以及消除× N_rules这一乘性因子。前者属于引擎层面（语法能力、速度、内存、ReDoS 安全），后者属于复杂度层面（避免对每条报文逐条匹配 N 条规则）。二者分别由go-pcre2-lite 与 minirehs 承担，互不替代、可叠加。

本文以实测数据回答四个问题：改造后的实际吞吐、对正则本身的影响、规则数增大时的加速表现、以及对 Yak Project 整体技术体系的影响。

二、方法与实现：完整 PCRE2 与统一编译

整体结构为\"单条正则引擎\"之上叠加一层\"多正则批量调度\"，再接入 MITM 的染色/提取路径：

flowchart TB    MITM[\"Yakit MITM 染色 / 指纹 / 提取\"] --> L2    subgraph L2[\"多正则批量层 · minirehs / rehs\"]        direction TB        C[\"统一编译所有规则 → 一个不可变 Database\"]        P[\"字面量预过滤Aho-Corasick / bit-NFA 一次扫描\"]        V[\"候选验证只对命中候选跑正则\"]        C --> P --> V    end    subgraph L1[\"单条正则引擎层 · go-pcre2-lite\"]        direction TB        RE2[\"RE2 可表达 → 标准库 regexp（线性）\"]        PCRE[\"RE2 不可表达 → 完整 PCRE2 兜底(lookaround/backref, 零分配, ReDoS 有界)\"]    end    V -. \"候选命中后精确判定\" .-> L1    L1 --> R[\"命中规则集合 / 精确偏移\"]

两层分工明确：minirehs 决定\"对哪些规则、在哪些位置执行正则验证\"，go-pcre2-lite 决定\"每一次验证的速度、安全性与可编译性\"。

YAK

2.1 单条正则层：go-pcre2-lite（完整 PCRE2）

它是 github.com/dlclark/regexp2 的 drop-in 替代，绝大多数代码只改一行

import：// beforeimport \"github.com/dlclark/regexp2\"// afterimport regexp2 \"github.com/VillanCh/go-pcre2-lite/regexp2\"

实现要点：

• 完整 PCRE2 8-bit 解释器，C 源码随仓库 vendored、经 cgo 编入，JIT 永久关闭（分发稳定、无运行期代码生成风险）。
• drop-in 兼容：类型、方法、RegexOptions、rune 索引的 Index/Length、Replace/ReplaceFunc、Escape 都对齐 regexp2；在 PCRE2 官方 testoutput1 语料的 1585 条输入上，整段匹配结果与 dlclark100% 一致。
• 语法更全：possessive 量词 a++、原子组 (?>…)、递归 (?R)、\\K、子程序 (?&name)、Unicode 属性——这些 dlclark 直接拒绝的构造均可编译，覆盖背景中\"语法能力受限\"一类此前无法运行的规则。
• ReDoS 默认有界：由 PCRE2 的 match/depth 限额兜底，(a+)+$ 这类指数回溯返回 ErrMatchLimit 而非挂起；收紧 SetMatchLimits 后可将攻击压至亚毫秒，对应背景中\"回溯不可控\"导致的代理无响应。库自带用例覆盖 moment.jsCVE-2022-31129、UAParser.js CVE-2020-7733 等真实 ReDoS，均可终止。

在 Yaklang 里，正则统一走 common/utils/regexp-utils 的 NewYakRegexpUtils(...)：优先标准库 RE2（线性无回溯），RE2 编译失败时回退 PCRE2 兜底。切换后 regexp-utils.go 与 MITM 预过滤模块的 import 已统一指向 go-pcre2-lite/regexp2。

YAK

2.2 多正则层：minirehs（yak 语言里注册为 rehs）

minirehs 是一个零外部依赖、可移植的多正则批量匹配引擎，借鉴 Intel Hyperscan 的\"统一编译、一次扫描\"模型：

// yak 语言里以 rehs 库暴露：一行编译、一次扫描判定哪些正则命中group = rehs.BuildGroup([\"admin\", \"(?i)password\", \"token=\\w+\"])~if group.Match(data) { / 是否有任意命中，命中即停，最快 / }for m in group.Find(data) { println(m.Index, m.Pattern, m.From, m.To, m.Value) }

核心流程是字面量提取 → Aho-Corasick / bit-NFA 预过滤（一次扫描，含位置）→ 候选邻域验证。它按环境自动分档：

CGO 可用时默认下沉自带的纯 C99 位并行内核（最强档，不链接、不 dlopen 任何外部库），不可用时优雅退化为纯 Go，参考执行器，两档结果逐字节一致。

YAK

2.3 接入 MITM：一个\"绝不漏报\"的统一预过滤

接入点是 mitmRulePrefilter（见 common/yakgrpc/yakit/httpflow_replacer_prefilter.go）：把所有可被 RE2 自动机

• 必需字面量安全门控的规则一次性编译进一个常驻 Group，每条报文只扫一次得到\"候选位图\"，其余规则直接跳过昂贵的逐条匹配。作为安全工具，不漏报是底线，因此正确性由构造保证。

• 只有 \"RE2 可精确表达且含必需字面量\" 的规则（disposition=primary）才进入\"可跳过集合\"；regexp2-only（lookaround/backref）或无必需字面量的规则一律标记为 always-candidate（永不跳过）。

• 预过滤引擎强制开 Multiline + DotAll，即预过滤语言是规则语言的超集——只会多报候选，绝不把真正会命中的报文判为不命中。

• 命中与否最终仍由原正则在候选规则上精确判定，染色/提取语义完全不变。

此外提供一键回退开关 YAKIT_MITM_REPLACER_DISABLE_PREFILTER=1，可随时退回逐条匹配的旧行为，用于 A/B 对比或异常时紧急回退。

三、实验设计

正确性不掺进吞吐判断：命中集合/偏移由独立差分测试保证（MVS 命中集与 stdlib oracle 逐字节一致、C 内核与 Go 参考执行器逐位一致）。

四、Benchmark 结果

这批规则的作用是对流量进行自动染色标注：例如报文中出现 rememberMe= 标注 组件-Shiro、出现 swagger-ui.html标注``组件-Swagger指纹、匹配 (?i)Druid 标注 组件-Druid。每一条流量都需经过整批规则匹配，因此该路径的吞吐直接决定 MITM 启用规则后的处理能力。以下从复杂度、真实场景、引擎本身三个维度给出实测结果。

YAK

4.1 复杂度：加速比随规则数增长（N=50 时 11.6× → N=1000 时 83.6×）

固定 ~1MB 语料，仅改变正则条数 N。minirehs 采用\"一次扫描\"，吞吐基本与 N 无关（597→232 MB/s，缓降源于候选管理开销）；逐条匹配的 StdlibLoop 随 N 线性劣化（52→2.8 MB/s）；二者比值即加速比，随 N 单调放大。

图一

适用范围：指纹识别、扫描规则、IOC 匹配等字面量丰富、命中稀疏的场景，规则数越大收益越显著。

YAK

4.2 真实 MITM 场景：0.19 → 6.10 MB/s（约 32×）

本组为最接近 Yakit 实际的场景：87 条真实规则、~5MB 真实流量、同一 Scan API 端到端。以现状 StdlibLoop（0.19 MB/s）为 1× 基线：

图二

口径说明：MVS 各档来自 BenchmarkMVSExistence（87 条），Engine/StdlibLoop 来自 BenchmarkMITMRealTraffic（RE2 可编译子集），两个基准共用同一 0.17~0.19 MB/s 的 StdlibLoop 固定参照。

存在性档不给精确偏移（From/To=-1），契合 MITM 打标\"只要哪些规则命中\"的场景；需要替换/抽取的精确位置时用定位档。

折算为可感知延迟：按同一 per-byte 速率，处理一条 1 MB 的响应体（如 JS bundle、JSON 导出），逐条匹配约需 5.3 s，存在性档降至约 0.16 s——这是\"MITM 开启全部内置规则后是否卡顿\"的直接来源。打标仅判存在性时端到端约 32×，纯 RE2 子集约 38×，需要精确偏移的定位档亦达 14×。

YAK

4.3 引擎层面：单条 1.8×–9.6×，布尔匹配零分配

左图为 go-pcre2-lite（drop-in 层）相对 dlclark/regexp2 的单条加速比（库自带基准，darwin/arm64）：各场景均更快，布尔匹配短串 9.6×、100KB 9.3×，且布尔匹配路径零分配。右图为将 minirehs 候选命中后的兜底引擎由 regexp2 更换为 PCRE2后，对 MVS 存在性吞吐的影响。

图三

右图诚实标注：\"切换前\"为 README 记录的 Phase 4 快照（C 内核存在性档），\"切换后\"为本机第一手实测（当前默认构建，纯 Go MVS + PCRE2 兜底），

两者后端档位不完全一致，不是同一构建上的受控 A/B，表达的是\"当前默认构建相对历史快照的整体提升\"，其中兜底换 PCRE2 是被 profile 标记的主导因素之一，

但不能把全部增益单独归因于它；单条正则层的严格受控收益以左图 PCRE2 vs dlclark 为准。本机快速抽样（benchtime=2x，有噪声）也佐证了方向：短串布尔匹配 low-level ~9.5×、分配 5→1。

五、结果解释

• 合成集可达 80×+ 而真实 MITM 约 32× 的原因：合成集字面量丰富、命中稀疏，预过滤命中率高，× N_rules 因子被有效消除；真实 MITM 为对抗性规则集——含大量形如 (...key|auth|user...).\? 的宽泛正则，字面量短而常见且含无界 .\?，字面量命中后仍需整段验证，该成本占主导，故加速比收敛至约 32×。此为规则形态的固有属性，已通过 profile 与\"全并/LimEx\"等实验定位（见 minirehs/MINI\_VECTOR\_SCAN\_IMPL.md）。
• 存在性档快于定位档的原因：打标仅需判定\"哪些规则命中\"，可走纯位运算快路径、不追踪 leftmost-longest 偏移，分配亦更低。
• 两层分工的本质：minirehs 将\"匹配次数\"从 N_rules × N_packets 降至 ~N_packets；go-pcre2-lite 进一步压低\"每次匹配的常数\"并约束 ReDoS。

二者叠加，构成 MITM 端到端由 0.19 提升至 6~7 MB/s 的来源。

六、能力边界、生态影响与结论

首先明确适用边界，以避免对数字的误读。该方案的强项在于字面量丰富、命中稀疏、规则数大的场景（指纹识别、扫描规则、IOC），加速比随规则数增长，合成集可达数十至上百倍；弱项在于充斥 .* 与常见短字面量的对抗性规则集，此时整段验证成本占主导，MVS 存在性约 32×、纯 Go 引擎约 2.5×。继续逼近 Hyperscan/vectorscan 量级需依靠 Teddy SIMD 默认化 + Rose-lite 链分解（命中点小邻域验证），而非在逐条正则之上叠加\"组合 gate 预筛\"（后者经实测否决，在对抗集上反而更慢）。

此外存在两项工程约束：存在性档不提供精确偏移（需要位置时改用定位档，或以存在性档作快速门）；go-pcre2-lite 兜底强制CGO_ENABLED=1，而 minirehs本身在``CGO_ENABLED=0 下亦可纯 Go 运行，二者对 CGO 的要求不同，需在分发矩阵中分别处理。迁移时应按 MIGRATION.md核对少数文档化的语义差异（混合命名/无名组编号、重复组 capture 历史、RightToLeft；按名访问始终一致）。

在生态影响层面，正则是 Yaklang 的底层原语，因此两项工作的收益不限于 MITM。其一，它提供了统一的正则底座：common/utils/regexp-utils 已成为全生态的正则入口（RE2 优先、PCRE2 兜底），凡使用该入口的子系统——指纹识别 common/fp、Suricata 规则 common/suricata、流量守卫 common/crep/trafficguard、SyntaxFlow 规则匹配——均自动继承\"更快、布尔匹配零分配、ReDoS 有界、语法更全\"的收益，此前因语法受限而无法使用的历史规则相当一部分可直接运行。其二，ReDoS 由潜在隐患转为平台属性：安全工具需处理用户提供或第三方来源的正则，旧引擎\"永不超时\"意味着单条异常正则即可拖垮引擎，PCRE2 的有界匹配将其转为可返回错误的可控事件。其三，rehs 成为 yak 语言的一等能力：插件作者可通过 rehs.BuildGroup / Match / Find / MatchedPatterns实现一次编译、一次扫描海量规则，无需自行编写逐条循环。其四，``minirehs 零外部依赖、不加载任何动态库、CGO 不可用时优雅退化为纯 Go，契合 Yak 引擎跨平台可移植、分发稳定的定位。

结论：真实 MITM 87 条规则 + ~5MB 真实流量下，存在性打标约 32×、纯 RE2 子集约 38×、定位档约 14×；单条正则更快（1.8×–9.6×）、布尔匹配零分配、ReDoS 默认有界、语法更全，代价是正则路径强制 CGO；复杂度由O(N\_rules × N\_bytes) 降至 ~O(N_bytes) 后，数百条正则的匹配确实更快，且加速比随规则数增长（合成集 50 条 11.6× → 1000 条 83.6×）。

综合而言，go-pcre2-lite 降低了每次匹配的成本并扩展了可编译范围，minirehs 将匹配次数由乘性关系转为加性关系；二者叠加，构成 Yakit MITM 内置规则由\"逐条匹配 N 遍\"到\"一次扫描完成\"的性能量变。

七、如何使用

可在MITM规则里配置是否使用更新后的正则规则。

YAK

附录 A：复现信息

合成规模：吞吐随 N 变化（图 1）CGO_ENABLED=1 go test ./common/minirehs/ -run '^$' -bench BenchmarkSyntheticScale -benchmem -benchtime 3x# 真实 MITM 规则 + 真实流量（图 2）CGO_ENABLED=1 go test ./common/minirehs/ -run '^$' \  -bench 'BenchmarkMVSExistence|BenchmarkMITMRealTraffic' -benchmem -benchtime 3x -timeout 1800s# 单条正则层 PCRE2 vs dlclark（图 3 左）CGO_ENABLED=1 go test -bench . -benchmem -run '^$' github.com/VillanCh/go-pcre2-lite/...# 差分正确性（吞吐之外的护栏）go test ./common/minirehs/ -run TestConsistency -short

图一

图二

图三

YAK

附录 B：图表复现

所有图表由 assets/make_figures.py 从 assets/data/*.csv 渲染，复用 precise-content-skills 的共享样式（pc_style.py，warm-paper 米色底、Okabe–Ito 色盲友好配色）：

python3 -m venv venv && ./venv/bin/pip install matplotlib pandas numpy./venv/bin/python assets/make_figures.py   # 输出 fig1..fig3 的 PNG + SVG

YAK

附录 C：关键源码位置

\*说明：真实语料为本地 yaklang 项目库抽取的脱敏 HTTP 流量；rule4yak 规则集来源 SexyBeast233/rule4yak。

数据为特定硬件（darwin/arm64）与特定构建下的实测，绝对数字会随机器与规则集变化，但\"加速比随 N 增长\"与\"两层正交叠加\"的结论具有一般性。\*

END

更新记录

Yakit  v1.4.8-0710

1. WebFuzzer新增API接口测试功能

2. 全局配置增加“关闭二次弹窗”配置开关

3. 优化部分右键菜单快捷执行

4. 修复全局配置AI模型缓存问题

5. 修复history批量染色处理卡顿崩溃问题

6. 修复history点击右键菜单变白的问题

7. 优化引擎连接流程，增加可选工作空间

8. 优化右键执行插件的交互和展示

9. 登录后可使用移动端控制功能，绑定飞书/钉钉远程控制AI Agent功能

10. YakRunner优化AI代码编写的展示和交互

11. 优化WebFuzzer的按钮展示

Memfit  v1.0.3-0710

1. 修改工具调用卡片（icon、工具名称展示，理由位置、生成参数卡片样式）

2. 修改任务执行详情（修改标题、不新开tab）

3. 自由对话新增子agent任务描点定位

4. 优化自由对话待办清单展示，可展示已完成/进行中/未完成

5. 子Agent任务增加跳过和查看任务详情

6. 优化发送问题后前端UI展示逻辑

7. 优化自由对话任务详情展示逻辑，只展示一个，不重复多开

Yaklang 1.4.8-beta2

1. 新增飞书/钉钉远程控制AI Agent功能(需要登录后使用)

2. 新增代码审计子 Agent 与 react\_loop 增强

3. 新增大量 MCP 工具集（chaos maker / fingerprint / http builder 等）

4. 修复大型项目 SyntaxFlow 扫描内存与卡死问题，重构 SSA 编译单元流式编译

5. 修复 HTTPFlow 标签更新、插件取消上下文和 facade TLS 加固

6. 修复 cybertunnel 隧道客户端错误处理与 MITM 热补丁并发问题

7. 新增 Windows ARM64 CI 支持与 slim(轻量版） 门禁测试

YAK官方资源

Yak 语言官方教程：

https://yaklang.com/docs/intro/

Yakit 视频教程：

https://space.bilibili.com/437503777

Github下载地址：

https://github.com/yaklang/yakit

Yakit官网下载地址：

https://yaklang.com/

Yakit安装文档：

https://yaklang.com/products/download\_and\_install

Yakit使用文档：

https://yaklang.com/products/intro/

常见问题速查：

https://yaklang.com/products/FAQ