在 Envoy 中当我们需要对 http_connection_manager 中的请求进行修改时，如添加或删除一个请求header，一般通过 HTTP Filter 过滤器来实现。 而在Envoy 包含的几十个Filter中，通常会选择 Lua Filter (extensions.filters.http.lua.v3.Lua) 或 Wasm Filter (extensions.filters.http.wasm.v3.Wasm)这两类过滤器。 Lua Filter 与 Wasm Filter 下表是 Lua Filter 与 HTTP Filter 的对比 Lua Filter Wasm Filter 编程语言 Lua，解释型脚本语言 WebAssembly，编译型语言 运行环境 Envoy 内置的 Lua 虚拟机 Envoy 内嵌的 WebAssembly 虚拟机 生态系统 丰富的 Lua 库可供使用 逐渐形成的 WebAssembly 生态系统 性能 较低 较高 安全性 较弱 较强 可移植性 受宿主环境和依赖库限制 平台无关的二进制格式，可在不同环境中运行 在不同的环境中Lua 的行为和功能可能略有差异，特别是在与底层操作系统和硬件交互的方面，而 Wasm 则没有这个问题。 但对于选择哪类 Filter 扩展 Envoy 的过滤器逻辑时，需要根据你的需求和对编程语言的熟悉程度。

wasm简介 WebAssembly（Wasm）是一种通用字节码技术，它可以将其他编程语言（如 Go、Rust、C/C++ 等）的程序代码编译为可在浏览器或服务端环境直接执行的字节码程序。 使用场景 主要有两个使用场景，分别为 浏览器 和 服务端。 浏览器 wasm最早的出现是为了解决浏览器端的性能问题，让web应用可以达到与本地原生应用类似的性能。 对于浏览器chrome 采用了v8 javascript引擎，其内置了一个 Wasm Runtime，因此可以实现对 wasm 的支持，这也正是浏览器可以运动wasm的原因。 服务端 2019 年 3 月，Mozilla 推出了 WebAssembly 系统接口（Wasi），以标准化 WebAssembly 应用程序与系统资源之间的交互抽象，例如文件系统访问、内存管理和网络连接，该接口类似于 POSIX 等标准 API。Wasi 规范的出现极大地扩展了 WebAssembly 的应用场景，使得 Wasm 不仅限于在浏览器中运行，而且可以在服务器端得到应用。同时，平台开发者可以针对特定的操作系统和运行环境提供 Wasi 接口的不同实现，允许跨平台的 WebAssembly 应用程序运行在不同的设备和操作系统上。 开发教程: Develop WASM Apps： https://wasmedge.org/docs/develop/overview Embed WasmEdge in Your Apps： https://wasmedge.org/docs/embed/overview 运行原理 下面介绍下为什么需要runtime以及常见的运行时有哪些？ 为什么需要Runtime WebAssembly (WASM) 需要运行时环境来提供执行和管理 WASM 模块的功能。下面是一些 wasm 需要运行时的原因： 跨平台执行：WebAssembly 是一种跨平台的二进制指令集格式，用于在不同的环境中执行。运行时环境负责将 WASM 模块加载到特定的执行环境中，并提供必要的接口和功能，使其能够在不同的操作系统和硬件平台上运行。 安全性限制：WebAssembly 是一种沙箱化的执行环境，它在运行时提供了严格的安全性限制。运行时负责执行这些限制，以确保 WASM 模块只能访问其限定的资源，并且不能执行恶意操作。 内存管理：WASM 运行时负责管理线性内存，这意味着它负责分配、释放和管理 WASM 模块的内存资源。运行时提供了合适的内存管理功能，以确保模块运行期间的内存访问的正确性和安全性。 调用外部功能：WASM 运行时提供了一种机制，使 WASM 模块能够与宿主环境进行交互，并调用外部的功能和服务。运行时环境定义了模块与宿主环境之间的接口和调用约定，使得模块能够访问特定功能，如文件系统、网络连接等。 性能优化和代码优化：WASM 运行时可以对加载的 WASM 模块进行解析、编译和优化，以提高执行效率和性能。运行时环境可以实现一些优化技术，如即时编译（Just-in-Time Compilation）和调用间内联（Function Inlining），从而使模块的执行更高效。 综上所述，WASM 需要运行时环境来提供必要的功能和接口，以便在跨平台的环境中安全地加载、执行和管理模块。运行时环境扮演了连接 WASM 模块和宿主环境之间的桥梁角色，使得在不同的环境中使用 WASM 变得更加便捷和可靠。