CDN 中间件运行在用户附近的边缘节点上，它要在真正回源之前完成鉴权、请求改写、响应裁剪、A/B 分流等工作。如果这些逻辑运行在 Node.js 或 V8 隔离环境中，冷启动和峰值延迟经常不可控，尤其是流量突增时，垃圾回收会把某一次简单请求拖到几十毫秒。WebAssembly 提供了更紧凑的运行时模型：模块经过编译后可在毫秒级完成实例化，线性内存中没有对象头开销，配合 Rust 的所有权系统可以避免大部分运行时安全检查。本文以 Rust 编译到 wasm32-wasi 为基线，讨论如何在 CDN 中间件场景下设计入口函数、传递请求上下文、调用宿主能力并下发安全策略。

一、为什么边缘中间件适合用 WebAssembly 而不是纯脚本

边缘节点通常部署在运营商机房、基站汇聚点或小型数据中心里，计算资源和内存都受到严格限制。传统脚本方案为了做到租户隔离，往往要为每个租户启动一个独立的 isolate，isolate 初始化时还要加载运行时、解析脚本、建立对象原型链。这个过程在单机上并发创建时开销尤其明显。WebAssembly 模块可以预先编译成机器码并缓存在磁盘或内存中，实例化时只需要把数据段复制到线性内存、建立导入表和函数表。一个几十 KB 的 wasm 模块在普通边缘服务器上做到 0.3 毫秒以内的实例化并不困难，而同样逻辑的 JavaScript isolate 冷启动可能要 1 到 5 毫秒。

中间件场景中很多操作都是短促且无状态的：读一个请求头，判断 token 是否有效，设置一个响应头，然后放行或拦截。这类逻辑极少需要动态创建复杂对象，也不依赖 DOM 或浏览器 API。WebAssembly 的线性内存模型特别适合这种字节层面的读取和比较。Rust 编译出的 wasm 没有垃圾回收，不会在处理请求的中途触发 GC 停顿。宿主平台通过导入函数精确控制模块能够访问哪些能力，比如只允许读取请求头、写日志、设置响应状态码，而无法任意访问文件系统或打开网络连接，这一点在 CDN 安全模型里非常关键。

还有一层原因是分发效率。边缘平台需要把客户的自定义逻辑快速推送到全球节点。如果逻辑以纯文本脚本下发，运行时还要做解析和 JIT 预热；如果以 wasm 字节码下发，节点收到后可以直接进入预编译队列。Rust 生成的 wasm 包体可以裁剪得很小，一个做 token 校验和响应头注入的模块压缩后可以控制在 20 KB 以内，批量下发时对边缘节点带宽的占用也小。

二、Rust 编译到 Wasm 的工程入口与 ABI 约定

在 CDN 平台里，wasm 模块通常不直接使用 wasi 的标准输入输出，而是通过宿主注入的函数完成能力调用。Rust 侧需要约定稳定的导出函数签名，例如 alloc、dealloc 和 handle_request。复杂对象不能跨宿主和模块边界直接传递，标准做法是把请求内容序列化成字节数组，把指针和长度传给模块，模块处理完后再返回结果指针和长度。下面是一个最小骨架，展示如何从线性内存中分配缓冲区并返回给宿主。

use std::slice;
#[no_mangle]
pub extern "C" fn alloc(len: usize) -> *mut u8 {
    let mut buf: Vec<u8> = Vec::with_capacity(len);
    let ptr = buf.as_mut_ptr();
    std::mem::forget(buf);
    ptr
}
#[no_mangle]
pub unsafe extern "C" fn dealloc(ptr: *mut u8, len: usize) {
    let _ = Vec::from_raw_parts(ptr, 0, len);
}
#[no_mangle]
pub unsafe extern "C" fn handle_request(ptr: *const u8, len: usize) -> u64 {
    let data = slice::from_raw_parts(ptr, len);
    let request = String::from_utf8_lossy(data);
    let response = format!("handled: {}", request.len());
    let out_ptr = alloc(response.len());
    std::ptr::copy_nonoverlapping(response.as_ptr(), out_ptr, response.len());
    (out_ptr as u64) << 32 | response.len() as u64
}

这里用 Vec<u8> 申请内存后调用 std::mem::forget 放弃 Rust 侧的所有权，把指针交给宿主使用。dealloc 中用 Vec::from_raw_parts 重新接管指针并释放，这样可以避免宿主反复调用时内存持续增长。返回值的编码方式是把指针放在高 32 位、长度放在低 32 位，宿主拿到后再按约定拆开读取结果。这个编码方式比较原始，但优点是避免在模块内维护全局状态，符合多实例并发执行的要求。

请求上下文里包含请求头、方法、路径和查询参数。宿主可以先把这些信息拼接成一个 JSON 字符串写入模块的线性内存，然后把指针传给 handle_request。模块内部用 serde_json 或手写解析器读取自己关心的字段。对于性能敏感路径，手写字节扫描通常比通用 JSON 解析更快，因为中间件往往只需要取出 Authorization 和 User-Agent 两个头部。Rust 中可以基于 slice::from_raw_parts 和 windows 逐字节匹配，避免构造大量临时字符串。

宿主能力通过 extern "C" 块声明为导入函数。比如平台提供一个获取请求头的接口，模块在 Rust 里这样声明：

extern "C" {
    fn host_get_header(name_ptr: *const u8, name_len: usize, out_ptr: *mut u8, out_len: usize) -> i32;
    fn host_set_response_header(name_ptr: *const u8, name_len: usize, value_ptr: *const u8, value_len: usize);
    fn host_log(ptr: *const u8, len: usize);
}

这些导入函数在 wasm 模块实例化时由宿主注入。编译时要确保这些符号不会被优化掉，通常需要在链接参数里保留导入。不同 CDN 平台会提供不同的 header 名和函数签名，正式接入前一定要把 ABI 版本固定下来，并在 CI 中增加 import 校验，避免平台升级后模块加载失败。

三、CDN 中间件核心逻辑：请求改写、鉴权与响应处理

一个完整的中间件流程可以分为三个阶段：读取并验证请求、决定是否放行、修改响应并记录审计日志。以边缘鉴权为例，模块先从内存中拿到 Authorization 头的值，提取 Bearer token，然后做哈希或签名校验。校验逻辑如果在 wasm 里执行，需要把密钥预先编译进模块或通过宿主安全下发；如果密钥不放在模块里，也可以调用宿主的 host_verify_token 导入函数，让平台侧完成真正的加密验证，模块只负责传递参数和解释结果。

Rust 里处理请求头字符串时要注意字节边界。请求头可能包含非 UTF-8 字节，直接 from_utf8_lossy 会替换非法序列，可能影响签名结果。对于安全校验，应该使用原始字节切片参与计算。下面的示例展示如何找到 Authorization 头并做简单的固定 token 比对，示例仅用于说明流程，生产环境应使用 HMAC 或非对称签名。

use std::slice;
fn find_header_value(request: &str, header_name: &str) -> Option<&str> {
    let lower = request.to_ascii_lowercase();
    let needle = format!("{}:", header_name.to_ascii_lowercase());
    let pos = lower.find(&needle)?;
    let after_colon = lower[pos + needle.len()..].trim_start();
    let end = after_colon.find('\r').unwrap_or(after_colon.len());
    Some(&after_colon[..end].trim())
}
#[no_mangle]
pub unsafe extern "C" fn handle_auth(ptr: *const u8, len: usize) -> u32 {
    let data = slice::from_raw_parts(ptr, len);
    let request = String::from_utf8_lossy(data);
    let valid = match find_header_value(&request, "authorization") {
        Some(value) => value == "Bearer edge-token-2024",
        None => false,
    };
    if valid { 1 } else { 0 }
}

这段代码中的 &str 在 HTML 源码里写作 &str，实际查看代码块时会显示为 &str。函数返回 1 表示放行，0 表示拒绝，宿主根据返回值决定是继续回源还是直接返回 403。把鉴权结果收敛成整数返回值，可以避免在模块和宿主之间传输大段错误信息，减少序列化开销。

响应处理阶段通常需要注入安全头。例如给所有 HTML 响应加 Content-Security-Policy，或给图片响应加 Cache-Control。模块可以先调用 host_set_response_header 写入键值对，再返回处理结果。如果响应体也需要改写，比如替换某些关键词或注入统计脚本，就需要宿主提供响应体缓冲区。改写响应体时要注意不要直接修改宿主传进来的内存，而应该先复制到自己申请的空间，处理完再写回，避免宿主后续复用同一块内存导致数据错乱。

四、性能调优与模块缓存中的坑

上线前最容易被忽略的是模块实例化频率。如果每个请求都重新实例化 wasm，性能优势会被初始化成本吃掉大半。正确做法是由平台维护一个实例池，请求进来时从池中取出空闲实例，处理完重置状态后归还。Rust 编写的模块只要不依赖全局可变状态，实例复用就不会产生串扰。如果确实需要少量共享状态，比如计数器或限流令牌，可以通过宿主的共享内存接口传入，而不是在模块内使用 static mut。

包体大小和内存分配器也影响边缘分发速度。默认情况下 Rust 编译到 wasm 会带上系统分配器，体积可能增加十几 KB。对于只做头部处理和简单鉴权的中间件，可以换成 wee_alloc 这类小型分配器，并开启 LTO 和 opt-level = "s"。经过 wasm-opt 优化后，一个只读取请求头并返回策略结果的模块可以压缩到 10 KB 左右。体积小了，节点冷启动时从磁盘读取并解码的速度也会更快。

最后要关注 ABI 和调试链路。边缘平台升级宿主接口时，导入函数签名可能变化，老模块会直接加载失败。因此每次发布前要在 staging 环境用真实请求验证导入表。日志方面，wasm 模块不能直接打印到 stdout，需要通过 host_log 回传。调试时可以在模块里嵌入结构化的日志片段，宿主统一收集后关联到请求 ID。这样即使线上出现偶发拦截，也能快速定位是模块逻辑错误还是宿主传参问题。

总体来说，Rust 加 WebAssembly 的组合并不是要完全替代边缘脚本，而是适合那些对延迟敏感、逻辑相对固定、需要严格隔离的中间件路径。把鉴权、限流、请求改写和高频响应头注入下沉到 wasm，能让 CDN 节点在突发流量下保持更稳定的尾部延迟。开发成本主要来自手动管理内存和自定义 ABI，但这些工作一旦沉淀为平台能力，后续业务接入会非常轻量。