WASI HTTP 怎样让 WebAssembly 组件访问 HTTP

先给结论：WebAssembly 组件不能因为编译成了 .wasm 就直接访问 HTTP。正确做法是让组件声明自己需要的 WIT world，再由宿主运行时实现并注入 wasi:http 接口。WASI 0.2 里最常见的入口是 wasi:http/proxy：它把 HTTP 类型、入站处理器和出站处理器组合成组件契约。

官方资料入口：https://component-model.bytecodealliance.org/language-support/using-http-in-components/rust.html

本文要点：入站请求由宿主交给组件；组件要访问下游 HTTP 服务，需要调用宿主提供的 outgoing-handler；DNS、TLS、代理、超时和出站地址仍由宿主的网络策略决定。

先看触发信号：组件为什么不能直接访问 HTTP

值班时最容易混淆两个问题。第一类是“组件接口没有接上”：组件的 world 没有导入 wasi:http/outgoing-handler，或者宿主没有把对应接口链接进去。第二类是“接口接上但网络被拒绝”：宿主虽然实现了 HTTP handler，却没有允许目标域名、端口、证书或代理。

因此，看到“找不到 import”“实例化失败”时，先查组件类型与宿主链接；看到 DNS、TLS、连接拒绝或超时，再查 egress policy。WASI HTTP 抽象的是 HTTP 语义和资源接口，不是把宿主的整个网络命名空间搬进沙箱。

快速判断：WASI HTTP world 负责哪些接口

Component Model 用 WIT 描述接口和 world。可以把 world 理解为组件对宿主的能力清单：它既描述组件要导入什么，也描述组件要导出什么。WASI 0.2 的 wasi:http/proxy world 以 HTTP 代理场景为中心，通常会看到以下几块：

下面这段 WIT 只用于表达依赖关系，重点是“声明能力”，不是在组件内直接创建 TCP socket：

package demo:http-proxy;

world gateway {
    // 入站请求由宿主交给组件处理。
    export wasi:http/incoming-handler;
    // 出站请求由宿主提供 HTTP handler 能力。
    import wasi:http/outgoing-handler;
}

实际项目还会由工具链补齐版本、类型包和语言绑定。读者判断一个组件是否能访问 HTTP，先看它的 world 是否声明了所需接口，再看宿主是否实现了同一版本的契约。

处理步骤：让宿主把 HTTP 能力接给组件

落地时可以按四个动作处理：先编译出目标 world 的组件；再让宿主运行时加载组件并链接 wasi:http；组件收到入站请求后构造 outgoing-request；最后调用 outgoing-handler.handle 并按流式资源规则读取或释放响应。

以 Wasmtime 为例，官方文档提供了 serve 子命令来运行 wasi:http/proxy 组件。下面是部署命令的最小示意，参数含义要以当前运行时版本为准：

# 用 Wasmtime 的 HTTP 服务入口承载一个组件。
# 这只是部署示意，不代表本文在本机执行过该命令。
wasmtime serve app.wasm

如果组件还要访问下游服务，宿主必须额外配置允许的网络能力。不要把“outgoing-handler 已链接”理解为“任意公网地址都能访问”。生产环境至少应把目标范围、代理、TLS 校验、连接和整体超时写进宿主配置；组件侧则要处理 handler 返回的错误，以及响应 body 没有读完时的释放路径。

可以用下面的排障顺序快速缩小范围：

1. 实例化失败：对照组件导入项与宿主链接项，先解决 world 或接口版本不匹配。
2. handler 调用失败：查看 HTTP 错误类型、目标 authority、代理和 TLS 配置。
3. 请求卡住：检查连接超时、响应 body 消费、pollable 等待和宿主的并发限制。
4. 偶发资源上涨：确认请求、响应、headers 和 body 子资源的所有权按运行时要求释放。

回滚路径：WASI 0.2 proxy 与 WASI 0.3 怎么选

如果现有宿主和工具链稳定支持 WASI 0.2，继续使用 wasi:http/proxy 是较保守的兼容路线。WASI 0.3 则把异步能力进一步纳入 Component Model，并在 HTTP 方向引入新的 service、middleware 等世界。它适合需要原生异步和组件串联的团队，但不应只因为版本更新就替换线上运行时。

回滚时保留三个东西：组件导出的 world 版本、宿主运行时版本、网络策略版本。若新 world 在某个宿主不可用，先回到已验证的 0.2 组件与宿主组合，再单独迁移接口，不要同时更换组件语言绑定、运行时和出站策略。

告警确认与复盘：HTTP 能力接通后还要看什么

接通之后的确认不应只看“接口能调用”。值班记录应包含：请求目标是否在允许清单、DNS/TLS 错误比例、连接和整体超时、响应 body 的消费与释放、组件实例并发数，以及宿主拒绝出站请求时的错误分类。

复盘时把问题分成三层：WIT 契约层负责“组件需要什么”；运行时链接层负责“宿主提供什么”；网络策略层负责“实际允许访问什么”。三层分开记录，下一次遇到 HTTP 失败时，就不会把接口缺失、权限拒绝和下游故障混成一个“Wasm 不能联网”的结论。

常见问题

WASI HTTP 会让组件绕过宿主的网络限制吗？

不会。它只定义组件与宿主之间的 HTTP 能力接口，是否允许目标地址、如何做 TLS 和代理，仍然由宿主实现与部署策略决定。

为什么组件有 incoming-handler 仍然不能请求下游？

incoming-handler 解决的是宿主把入站请求交给组件；请求下游还需要组件导入并调用 outgoing-handler，且宿主必须提供对应实现和网络权限。