摘要：里面有一句描述，可以看到的目標(biāo)是兼容瀏覽器。那么這里的兼容瀏覽器到底如何是什么意思呢我簡(jiǎn)單談?wù)勎业睦斫獍伞：芏嗳诉€有誤解以為兼容瀏覽器指的是會(huì)提供類(lèi)似里的寫(xiě)法。

Deno 里面有一句描述："Aims to be browser compatible"，可以看到 Deno 的目標(biāo)是兼容瀏覽器。那么這里的兼容瀏覽器到底如何是什么意思呢？

我簡(jiǎn)單談?wù)勎业睦斫獍伞?/p>

首先這里的兼容性肯定不是 Deno 直接在瀏覽器端運(yùn)行。因?yàn)?Deno 是一個(gè)和瀏覽器平級(jí)的 Runtime。

很多人還有誤解以為兼容瀏覽器指的是 Deno 會(huì)提供“類(lèi)似 Node.js 里的 UMD 寫(xiě)法”。首先我們明確一點(diǎn)，這里的兼容不是單指語(yǔ)法層面的兼容，并不是說(shuō)要兼容 ES3 ES5。所以不要產(chǎn)生這種誤解，以為可以通過(guò) babel 兼容 Node.js 和 Deno。

在 Deno 的 Roadmap 里面作者就已經(jīng)寫(xiě)到了：

Deno does not aim to be API compatible with Node in any respect. Deno will export a single flat namespace "deno" under which all core functions are defined. We leave it up to users to wrap Deno"s namespace to provide some compatibility with Node.

這里的兼容，我的理解是兼容瀏覽器的 API 和生態(tài)。（坐等被打臉）

之前有個(gè) issue discussion: struct the browser-compatible APIs #82 討論這個(gè)問(wèn)題，在 issue 中列舉了一些想要兼容的瀏覽器 API：

High level

Console ?

URL ?

File/FileList/FileReader/Blob

XMLHttpRequest/Fetch

WebSocket

URLSearchParams

Middle level

AudioContext/AudioBuffer

Canvas

討論中還包括 WebGL 設(shè)置 GPU 的支持。我們可以隱約猜到 Deno 的一個(gè)目標(biāo)就是讓瀏覽器中的代碼可以直接運(yùn)行在 Deno 上面。

我的觀點(diǎn)依然是：Deno 不是下一代 Node.js。（再次坐等被打臉）

Deno 是一個(gè)“A secure TypeScript runtime on V8”。一個(gè)安全的基于 V8 的 TypeScript 運(yùn)行時(shí)，這個(gè)怎么理解呢。

瀏覽器可以認(rèn)為是安全的 JavaScript 運(yùn)行時(shí)，所有的 JavaScript 代碼都是在沙盒（Sandbox）里面運(yùn)行。瀏覽器雖然安裝在你的電腦上，但是瀏覽器里面運(yùn)行的 JavaScript 代碼可以來(lái)自世界各地，換言之瀏覽器里面運(yùn)行的都是不受信代碼，如何保證瀏覽器的 JavaScript 代碼不破壞你的電腦系統(tǒng)，這是瀏覽器安全機(jī)制需要解決的一個(gè)問(wèn)題。而 Node.js 則不是，和任何的 Web 服務(wù)器一樣，Node.js 運(yùn)行的是受信代碼。

之前 V8 出現(xiàn)了關(guān)于逃逸分析（Escape Analysis）的安全漏洞，Chrome 采取了緊急措施，在下一個(gè)版本中刪掉了逃逸分析相關(guān)的功能，相比之下，Node.js 則沒(méi)有受到影響，因?yàn)?Node.js 運(yùn)行的代碼本來(lái)就是受信的。

從這個(gè)角度講，Deno 和瀏覽器的定位很像。

V8 團(tuán)隊(duì)的一個(gè)錯(cuò)誤，使得整個(gè)互聯(lián)網(wǎng)變慢

因?yàn)槲覀兛梢钥吹剑嫒莘?wù)器端生態(tài)和兼容瀏覽器端生態(tài)的一個(gè)區(qū)別：

瀏覽器里面運(yùn)行的都是不受信代碼

服務(wù)器運(yùn)行的是受信代碼

我們?cè)贀Q一個(gè)角度聊聊服務(wù)器生態(tài)。

很多人還有一個(gè)誤解，就是覺(jué)得上面提到的那些 API，對(duì)于 Node.js 也完全可以兼容，比如 Console、URL、XMLHttpRequest/Fetch 等，很多 API 都已經(jīng)被 Node.js 實(shí)現(xiàn)了。

當(dāng) Node.js 被開(kāi)發(fā)出來(lái)的時(shí)候，類(lèi)似 File、URL、Buffer 這類(lèi)的 API 瀏覽器端都還沒(méi)有，但由于 Node.js 定位為服務(wù)器端運(yùn)行平臺(tái)，因此 Node.js 參考的是其他 Web 服務(wù)器或者服務(wù)器編程語(yǔ)言。例如文件系統(tǒng)（File System），實(shí)現(xiàn)了一系列 POSIX（Portable Operating System Interface，可移植操作系統(tǒng)接口） 兼容的函數(shù)和功能。

還有一點(diǎn)需要注意的是 Node.js 和瀏覽器的趨同化，例如 Node.js 7 加入的 URL API，而當(dāng)今的主流瀏覽器也都提供了這個(gè) API，這是因?yàn)?Node.js 也使用了 WHATWG URL 標(biāo)準(zhǔn)。

WHATWG 的全稱(chēng)是 Web Hypertext Application Technology Working Group，網(wǎng)頁(yè)超文本應(yīng)用技術(shù)工作小組。這是一個(gè)相當(dāng)“有重量”的組織，當(dāng) W3C 決定放棄 HTML 打算將未來(lái)的重點(diǎn)放在 XHTML 2.0 上時(shí)，WHATWG 堅(jiān)決擁護(hù) HTML，并制定了下一代 HTML 計(jì)劃。最終 WHATWG 說(shuō)服了 W3C 并與其一起發(fā)布了 HTML5。

如今 Web 的飛速發(fā)展我們要感謝這些組織的努力。

那么現(xiàn)在就有一個(gè)疑問(wèn)了：如果 Node.js、瀏覽器、Deno 都使用這些標(biāo)準(zhǔn)后，那么他們是不是就會(huì)變得一樣，Deno 會(huì)不會(huì)取代 Node.js，成為下一代 Node.js？或者 Deno 變成一個(gè)和 Node.js 一樣但是比 Node.js 還難用的平臺(tái)，最終被邊緣化或者被拋棄？

不會(huì)。因?yàn)樾阅芎桶踩遣豢杉娴玫模热?File/FileReader/Blob 這種 API 天生就是為瀏覽器端沙盒環(huán)境設(shè)計(jì)的（WHATWG 好多標(biāo)準(zhǔn)都是為瀏覽器設(shè)計(jì)的）。Node.js 還沒(méi)有提供相應(yīng)的 API，而且也不打算提供，畢竟在服務(wù)器端環(huán)境我們更需要的是文件系統(tǒng)，所以 Node.js 不去擁抱 WHATWG，而選擇了 POSIX。

既然談到了這個(gè)，那我就再講的深入一點(diǎn)吧，深入到底層看看為什么 Node.js 不是用 Blob 和 FileReader 來(lái)讀取文件。

在瀏覽器端文件通常來(lái)自于網(wǎng)絡(luò)，由 url 提供，或者來(lái)自于表單的用戶(hù)主動(dòng)選擇。無(wú)論何種方式都是由瀏覽器來(lái)完成文件的讀取，并把文件內(nèi)容加載到內(nèi)存緩沖區(qū)中，這時(shí) JavaScript 可以通過(guò) Blob 來(lái)操作此文件。但是 Node.js 卻沒(méi)有實(shí)現(xiàn)這些 API，而是在文件系統(tǒng)之上構(gòu)建了 Stream 模塊來(lái)實(shí)現(xiàn)。再看看其服務(wù)器端編程語(yǔ)言例如 Java、PHP 也都提供了 Stream。

如果我們把 Node.js 作為一個(gè) Web 服務(wù)器，那么我們橫向和 Nginx 對(duì)比一下。如果使用 js 開(kāi)發(fā)一個(gè)靜態(tài)文件服務(wù)器，那么 Nginx 可以輕輕松松以十倍百倍的性能輾壓 Node.js。

我們可以從底層分析一下兩者為何相差懸殊。這里有幾個(gè)知識(shí)點(diǎn)：

用戶(hù)空間

內(nèi)核空間

進(jìn)程上下文

中斷上下文

DMA

Zero Copy

為了安全考慮操作系統(tǒng)不允許用戶(hù)代碼直接操作硬件，為了保證操作系統(tǒng)內(nèi)核的安全，將空間劃分為兩部分，一部分為內(nèi)核空間，一部分為用戶(hù)空間。用戶(hù)編寫(xiě)的代碼運(yùn)行在用戶(hù)空間，當(dāng)需要使用底層功能時(shí)，可以通過(guò)系統(tǒng)調(diào)用進(jìn)入內(nèi)核，例如文件讀取。

當(dāng)用戶(hù)進(jìn)程通過(guò)系統(tǒng)調(diào)用從用戶(hù)空間進(jìn)入到內(nèi)核空間時(shí)，系統(tǒng)需要將用戶(hù)進(jìn)程的上下文保存起來(lái)，當(dāng)再次從內(nèi)核空間回到用戶(hù)空間時(shí)，系統(tǒng)恢復(fù)此上下文。

對(duì)于靜態(tài)服務(wù)器，則這個(gè)步驟大概是：

調(diào)用 read，文件被 copy 到內(nèi)核緩沖區(qū)

read 函數(shù)返回，文件從內(nèi)核緩沖區(qū) copy 到用戶(hù)緩沖區(qū)

write 函數(shù)調(diào)用，將文件從用戶(hù)緩沖區(qū) copy 到內(nèi)核與 socket 相關(guān)的緩沖區(qū)

數(shù)據(jù)從 socket 緩沖區(qū) copy 到相關(guān)協(xié)議引擎

可以看到文件在整個(gè)過(guò)程中被 copy 了 4 次。

而 Nginx 底層使用 sendfile，可以實(shí)現(xiàn) Zero Copy (零拷貝)。

整個(gè)流程變成了：

sendfile 系統(tǒng)調(diào)用，文件被 copy 至內(nèi)核緩沖區(qū)

從內(nèi)核緩沖區(qū) copy 至內(nèi)核中 socket 相關(guān)的緩沖區(qū)

從 socket 相關(guān)的緩沖區(qū) copy 到協(xié)議引擎

可以看到在這個(gè)過(guò)程中，只有 3 次 copy。而且沒(méi)有了用戶(hù)空間和內(nèi)核空間的切換，也不需要保存和恢復(fù)進(jìn)程的上下文。其實(shí)上面還有優(yōu)化的余地，因?yàn)樵趦?nèi)核中發(fā)生了一次緩沖區(qū)到緩沖區(qū)的 copy。在 Linux 內(nèi)核版本 2.4 之后，DMA 模塊將數(shù)據(jù)直接從內(nèi)核緩沖區(qū)傳遞給協(xié)議引擎。

雖然稱(chēng)為 Zero Copy，但是數(shù)據(jù)依然是從磁盤(pán)復(fù)制到了內(nèi)存，從操作系統(tǒng)的角度來(lái)看這個(gè)是必須的，所謂的零拷貝是指內(nèi)核中沒(méi)有冗余數(shù)據(jù)，數(shù)據(jù)不需要在內(nèi)核拷貝。借助 DMA 模塊此過(guò)程完全不需要 CPU 參與。

在 Nginx 中只需要數(shù)據(jù)副本的 2 個(gè) copy，而 Node.js 則需要 4 次。如果 Node.js 要想使用 Zero Copy 也有方法，比如使用 os 模塊的功能，或者直接使用 C++ 擴(kuò)展。

從另一個(gè)角度講，Node.js 的性能損耗不僅僅是 4 次 copy 以及進(jìn)程上下文的保存和恢復(fù)，還包括數(shù)據(jù)和代碼從 C++ 到 JavaScript 的反復(fù)跨越邊界。

我們回過(guò)頭來(lái)討論瀏覽器，對(duì)于瀏覽器來(lái)講，根本就不需要這個(gè)特性。因?yàn)闉g覽器中的 JavaScript 代碼不僅僅是在內(nèi)核空間運(yùn)行，而且還是在沙盒空間運(yùn)行。

所以與其在此猜測(cè)兼容瀏覽器指的什么，不如對(duì)比瀏覽器和服務(wù)器的差別：

瀏覽器運(yùn)行不受信代碼，服務(wù)器運(yùn)行受信代碼

瀏覽器遵循 W3/WHATWG，服務(wù)器遵循 POSIX

瀏覽器關(guān)心 API 層的性能，服務(wù)器更關(guān)心操作系統(tǒng)層的性能

瀏覽器能力受限，服務(wù)器能力不受限

掃碼二維碼關(guān)注我的公眾號(hào)，每周推送原創(chuàng)前端內(nèi)容