為什麼每個人都在談論 WebAssembly

瞭解有關在 Web 瀏覽器中執行任何程式碼的最新方法的更多資訊。

如果你還沒有聽說過 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中國 榮譽推出