如果您还没有听说过 WebAssembly，那么您很快就会听到。它是业界保守得最好的秘密之一，但它无处不在。所有主流浏览器都支持它，而且它也即将进入服务器端。它速度很快。它被用于游戏。 它是万维网联盟 (W3C) 的开放标准，W3C 是网络的主要国际标准组织。
“哇，”您可能会说，“这听起来像是我应该学习编码的东西！” 您是对的，但您也错了；您不是用 WebAssembly 编码。让我们花一些时间来了解这项经常被亲切地缩写为“Wasm”的技术。
它从何而来？
回顾大约十年前，人们越来越认识到，广泛使用的 JavaScript 对于许多用途来说不够快。JavaScript 无疑是成功且方便的。它可以在任何浏览器中运行，并实现了我们今天认为理所当然的那种动态网页。但它是一种高级语言，在设计时并未考虑到计算密集型工作负载。
然而，尽管负责领先网络浏览器的工程师们普遍认同性能问题，但他们对于如何解决这个问题并没有达成一致。出现了两个阵营。谷歌开始了其 Native Client 项目，以及后来的 Portable Native Client 变体，专注于允许用 C/C++ 编写的游戏和其他软件在 Chrome 内的安全隔间中运行。与此同时，Mozilla 赢得了微软对 asm.js 的支持，这是一种更新浏览器的方法，使其可以非常快速地运行低级 JavaScript 指令子集（另一个项目实现了将 C/C++ 代码转换为这些指令）。
由于两个阵营都没有获得广泛采用，各方同意在 2015 年联合起来，围绕一个名为 WebAssembly 的新标准，该标准建立在 asm.js 采取的基本方法之上。正如 CNET 的 Stephen Shankland 当时写道，“在今天的网络上，浏览器的 JavaScript 将这些指令翻译成机器代码。但是使用 WebAssembly，程序员在过程的早期做了很多工作，生成一个介于两种状态之间的程序。这使浏览器从创建机器代码的许多繁重工作中解放出来，但它也实现了 Web 的承诺——软件将在任何具有浏览器的设备上运行，而与底层硬件细节无关。”
2017 年，Mozilla 宣布它是一个最小可行产品，并将其从预览版中移除。所有主要的浏览器都在当年年底采用了它。2019 年 12 月，WebAssembly 工作组发布了三项 WebAssembly 规范作为 W3C 建议。
WebAssembly 定义了一种用于可执行程序的可移植二进制代码格式、一种相应的文本汇编语言，以及用于促进此类程序与其宿主环境之间交互的接口。WebAssembly 代码在低级虚拟机中运行，该虚拟机模拟了可以运行在其上的许多微处理器的功能。通过即时 (JIT) 编译或解释，WebAssembly 引擎的性能可以接近为原生平台编译的代码的速度。
现在为何引起兴趣？
当然，最近对 WebAssembly 的一些兴趣源于最初希望在浏览器中运行更多计算密集型代码。特别是笔记本电脑用户，他们越来越多地将时间花在浏览器中（或者，对于 Chromebook 来说，几乎所有时间）。这种趋势使得消除在浏览器中运行各种应用程序的障碍变得紧迫。其中一个障碍通常是性能的某些方面，这正是 WebAssembly 及其前辈最初构想要解决的问题。
然而，WebAssembly 不仅仅适用于浏览器。2019 年，Mozilla 宣布了一个名为 WASI (WebAssembly 系统接口) 的项目，以标准化 WebAssembly 代码如何在浏览器上下文之外与操作系统交互。通过浏览器对 WebAssembly 和 WASI 的支持，编译后的二进制文件将能够在浏览器内外、跨不同设备和操作系统以接近原生的速度运行。
WebAssembly 的低开销使其立即适用于浏览器以外的用途，但这可以说是基本要求；显然还有其他运行应用程序的方法，这些方法不会引入性能瓶颈。为什么要专门使用 WebAssembly 呢？
一个重要的原因是它的可移植性。像 C++ 和 Rust 这样广泛使用的编译语言可能是当今与 WebAssembly 联系最紧密的语言。然而，各种其他语言可以编译为 WebAssembly 或在 WebAssembly 中拥有其虚拟机。此外，虽然 WebAssembly 对其执行环境假设了一些先决条件，但它旨在在各种操作系统和指令集架构上高效执行。因此，WebAssembly 代码可以使用各种语言编写，并在各种操作系统和处理器类型上运行。
WebAssembly 的另一个优势源于代码在虚拟机中运行的事实。因此，每个 WebAssembly 模块都在沙盒环境中执行，使用故障隔离技术与宿主运行时隔离。这尤其意味着，应用程序与其宿主环境的其余部分隔离执行，并且在不通过适当 API 的情况下无法逃脱沙箱。
WebAssembly 的实际应用
这一切在实践中意味着什么？
WebAssembly 实际应用的一个例子是 Enarx。
Enarx 是一个为使用可信执行环境 (TEE) 保护应用程序提供硬件独立性的项目。Enarx 让您可以安全地将编译为 WebAssembly 的应用程序一直交付到云提供商，并远程执行它。正如 Red Hat 安全工程师 Nathaniel McCallum 所说，“我们这样做的方式是，我们将您的应用程序作为输入，并对远程硬件执行证明过程。我们使用加密技术验证远程硬件实际上是它声称的硬件。最终结果不仅是对我们正在对话的硬件的信任度提高；它还是一个会话密钥，然后我们可以使用它将加密的代码和数据交付到我们刚刚要求进行加密证明的这个环境中。”
另一个例子是 OPA，即开放策略代理，它在 2019 年 11 月宣布，您可以将他们的策略定义语言 Rego 编译为 WebAssembly。Rego 让您可以编写逻辑来搜索和组合来自不同来源的 JSON/YAML 数据，以提出诸如“是否允许此 API？”之类的问题。
OPA 已被用于策略启用软件，包括但不限于 Kubernetes。使用像 OPA 这样的工具简化策略 被认为是在各种不同环境中正确保护 Kubernetes 部署的重要一步。WebAssembly 的可移植性和内置安全功能与这些工具非常匹配。
我们的最后一个例子是 Unity。还记得吗，我们在文章开头提到 WebAssembly 用于游戏？好吧，跨平台游戏引擎 Unity 是 WebAssembly 的早期采用者，提供了 Wasm 在浏览器中运行的第一个演示，并且自 2018 年 8 月以来，已使用 WebAssembly 作为 Unity WebGL 构建目标的输出目标。
这些只是 WebAssembly 已经开始产生影响的几种方式。在 https://webassembly.net.cn/ 了解更多信息并及时了解所有关于 Wasm 的信息
1 条评论