為什麼每個人都在談論 WebAssembly

如果你還沒有聽說過 WebAssembly，那麼你很快就會知道。這是業界最保密的秘密之一，但它無處不在。所有主流的瀏覽器都支持它，並且它也將在伺服器端使用。它很快，它能用於遊戲編程。這是主要的國際網路標準組織萬維網聯盟（W3C）的一個開放標準。

你可能會說：「哇，這聽起來像是我應該學習編程的東西！」你可能是對的，但也是錯的。你不需要用 WebAssembly 編程。讓我們花一些時間來學習這種通常被縮寫為「Wasm」的技術。

它從哪裡來？

大約十年前，人們越來越認識到，廣泛使用的 JavaScript 不夠快速，無法滿足許多目的。JavaScript 無疑是成功和方便的。它可以在任何瀏覽器中運行，並啟用了今天我們認為理所當然的動態網頁類型。但這是一種高級語言，在設計時並沒有考慮到計算密集型工作負載。

然而，儘管負責主流 web 瀏覽器的工程師們對性能問題的看法大體一致，但他們對如何解決這個問題卻意見不一。出現了兩個陣營，谷歌開始了它的 原生客戶端 Native Client 項目，後來又推出了 可移植原生客戶端 Portable Native Client 變體，著重於允許用 C/C++ 編寫的遊戲和其它軟體在 Chrome 的一個安全隔間中運行。與此同時，Mozilla 贏得了微軟對 asm.js 的支持。該方法更新了瀏覽器，因此它可以非常快速地運行 JavaScript 指令的低級子集（有另一個項目可以將 C/C++ 代碼轉換為這些指令）。

由於這兩個陣營都沒有得到廣泛採用，各方在 2015 年同意圍繞一種稱為 WebAssembly 的新標準，以 asm.js 所採用的基本方法為基礎，聯合起來。如 CNET 的 Stephen Shankland 當時所寫，「在當今的 Web 上，瀏覽器的 JavaScript 將這些指令轉換為機器代碼。但是，通過 WebAssembly，程序員可以在此過程的早期階段完成很多工作，從而生成介於兩種狀態之間的程序。這使瀏覽器擺脫了創建機器代碼的繁瑣工作，但也實現了 Web 的承諾 —— 該軟體將在具有瀏覽器的任何設備上運行，而無需考慮基礎硬體的細節。」

在 2017 年，Mozilla 宣布了它的最小可行的產品（MVP），並使其脫離預覽版階段。到該年年底，所有主流的瀏覽器都採用了它。2019 年 12 月，WebAssembly 工作組發布了三個 W3C 推薦的 WebAssembly 規範。

WebAssembly 定義了一種可執行程序的可移植二進位代碼格式、相應的文本彙編語言以及用於促進此類程序與其宿主環境之間的交互介面。WebAssembly 代碼在低級虛擬機中運行，這個可運行於許多微處理器之上的虛擬機可模仿這些處理器的功能。通過即時（JIT）編譯或解釋，WebAssembly 引擎可以以近乎原生平台編譯代碼的速度執行。

為什麼現在感興趣？

當然，最近對 WebAssembly 感興趣的部分原因是最初希望在瀏覽器中運行更多計算密集型代碼。尤其是筆記本電腦用戶，越來越多的時間都花在瀏覽器上（或者，對於 Chromebook 用戶來說，基本上是所有時間）。這種趨勢已經迫切需要消除在瀏覽器中運行各種應用程序的障礙。這些障礙之一通常是性能的某些方面，這正是 WebAssembly 及其前身最初旨在解決的問題。

但是，WebAssembly 並不僅僅適用於瀏覽器。在 2019 年，Mozilla 宣布了一個名為 WASI（ WebAssembly 系統介面 WebAssembly System Interface ）的項目，以標準化 WebAssembly 代碼如何與瀏覽器上下文之外的操作系統進行交互。通過將瀏覽器對 WebAssembly 和 WASI 的支持結合在一起，編譯後的二進位文件將能夠以接近原生的速度，跨不同的設備和操作系統在瀏覽器內外運行。

WebAssembly 的低開銷立即使它可以在瀏覽器之外使用，但這無疑是賭注；顯然，還有其它不會引入性能瓶頸的運行應用程序的方法。為什麼要專門使用 WebAssembly？

一個重要的原因是它的可移植性。如今，像 C++ 和 Rust 這樣的廣泛使用的編譯語言可能是與 WebAssembly 關聯最緊密的語言。但是，各種各樣的其他語言可以編譯為 WebAssembly 或擁有它們的 WebAssembly 虛擬機。此外，儘管 WebAssembly 為其執行環境假定了某些先決條件，但它被設計為在各種操作系統和指令集體系結構上有效執行。因此，WebAssembly 代碼可以使用多種語言編寫，並可以在多種操作系統和處理器類型上運行。

另一個 WebAssembly 優勢源於這樣一個事實：代碼在虛擬機中運行。因此，每個 WebAssembly 模塊都在沙盒環境中執行，並使用故障隔離技術將其與宿主機運行時環境分開。這意味著，對於其它部分而言，應用程序獨立於其宿主機環境的其餘部分執行，如果不調用適當的 API，就無法擺脫沙箱。

WebAssembly 現狀

這一切在實踐中意味著什麼？

如今在運作中的 WebAssembly 的一個例子是 Enarx。

Enarx 是一個提供硬體獨立性的項目，可使用 受信任的執行環境 Trusted Execution Environments （TEE）保護應用程序的安全。Enarx 使你可以安全地將編譯為 WebAssembly 的應用程序始終交付到雲服務商，並遠程執行它。正如 Red Hat 安全工程師 Nathaniel McCallum 指出的那樣：「我們這樣做的方式是，我們將你的應用程序作為輸入，並使用遠程硬體執行認證過程。我們使用加密技術驗證了遠程硬體實際上是它聲稱的硬體。最終的結果不僅是我們對硬體的信任度提高了；它也是一個會話密鑰，我們可以使用它將加密的代碼和數據傳遞到我們剛剛要求加密驗證的環境中。」

另一個例子是 OPA， 開放策略代理 Open Policy Agent ，它發布於 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.org/ 上查找更多信息並了解 Wasm 的所有最新信息。

via: https://opensource.com/article/20/1/webassembly

作者：Mike Bursell 選題：lujun9972 譯者：laingke 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive