nodejs 的誕生
??Node.js 是2009的時候由大神 Ryan Dahl 開發的,Ryan 的本職作業是用 C++ 寫服務器,后來他總結出一個經驗,一個高性能服務器應該是滿足“事件驅動,非阻塞 I/O”模型的,C++ 開發起來比較麻煩,于是 Ryan 就想找一種更高級的語言,以便快速開發,
??Ryan 發現 JS 語言本身的特點就是事件驅動并且是非阻塞 I/O 的,跟他的思路正是絕配,第二點,Chrome 的 JS 引擎,也就是 V8 引擎是開源的,而且性能特別棒,于是 Ryan 就基于 V8 開發了 Node.js,
nodejs與瀏覽器環境
??在 Node.js 出現之前,最常見的 JavaScript 運行時環境是瀏覽器(我們平時寫的代碼跑在瀏覽器環境中),瀏覽器為 JavaScript 提供了 DOM API,2009 年初 Node.js 出現了,它是由 Ryan Dahl 基于 Chrome V8 引擎開發的 JavaScript 運行時環境,所以 Node.js 也是 JavaScript 的一種宿主環境,
Node.js 不是瀏覽器,所以它不具有瀏覽器提供的 DOM API,比如 Window 物件、Location 物件、Document 物件、HTMLElement 物件、Cookie 物件等等,但是,Node.js 提供了自己特有的 API,比如全域的 global 物件,也提供了當前行程資訊的 Process 物件,操作檔案的 fs 模塊,以及創建 Web 服務的 http 模塊等等,這些 API 能夠讓我們使用 JavaScript 操作計算機,也可以開發 web 服務器,
nodejs 是什么
官方定義:Node.js 是一個開源和跨平臺的 JavaScript 運行時環境,
怎么理解這個 JavaScript 運行時環境 ?顧名思義,是一個可以運行 JavaScript 的環境,這里的環境主要包含以下兩個方面:
- 提供了編譯、執行 JavaScript 的底層能力
- 提供了一系列介面,使開發者可以通過 JavaScirpt 呼叫系統底層能力(例如網路,檔案讀寫等)
前者是由 Chrome V8 引擎提供的,而后者則是由一個底層由 C,C++ 撰寫的高性能的事件驅動的異步 I/O 庫 libuv 所提供,
Node.js 內置的模塊很豐富,具體可以查看nodejs 官網
通俗理解:nodejs 能讓js 代碼在瀏覽器之外執行,且能與作業系統進行互動、能操作檔案、操作網路等,
nodejs 擴展了前端的邊界
??在nodejs 這個執行環境中,我們可以與作業系統進行通信、能控制計算機,通過這個平臺做很多的事情,如寫一些web服務,客戶端工具軟體、打包工具等等,有了這樣的一個平臺,我們干的事情相比只能依賴在瀏覽器中完全不是一個級別的,
模塊化
??nodejs 正式發布的時候,JavaScript 還沒有標準的模塊機制,nodejs一開始采用了CommonJS規范,后面JavaScript 標準的模塊機制ES Modules誕生,瀏覽器開始逐步支持ES Modules,Node.js 從v13.2.0之后也引入了規范的ES Modules機制,同時兼容早期的CommonJS,
現在我們寫 Node.js 模塊的時候,可以有 3 種方式:
- 直接采用最新的ES Modules
- 采用ES Modules,通過 Babel 編譯成CommonJS 規范,
- 仍然使用舊的CommonJS規范,預計未來 Node.js 在很長一段時間內依然會同時兼容ES Modules和CommonJS,
什么是npm
??模塊化的目的是使代碼可以更好地復用,同時為了更方便的使用別人寫的模塊或者分享自己的模塊,推出了包管理工具,我們叫他npm,它允許我們以包的形式從共享倉中發布和下載模塊,
??NPM 的全稱是Node Package Manager,是一個將 Node.js 的模塊以包的形式組織和管理的工具,
npm script
NPM Scripts 是指在package.json檔案中配置scripts屬性,在其中指定腳本命令:
// package.json
{
... //其他配置
"scripts": {
"eslint": "eslint ziyue.js"
}
}
NPM Scripts 能夠執行對應的 Node 命令,是因為 NPM 在安裝模塊的時候,不僅將模塊自身安裝到node_modules目錄下,還會在node_modules目錄下創建一個.bin的子目錄,將模塊包中的命令列腳本安裝到.bin目錄下,并在 NPM Script 執行時設定系統的環境變數 PATH 包含node_modules/.bin目錄,這樣就能夠正常執行腳本了,
如執行:
npm run eslint
就相當于執行了:
node ./node_modules/.bin/eslint xx.js
網路部分
??作為前端工程師,少不了要和 Web 打交道,通常情況下,前端工程師主要負責“端”的部分,也就是瀏覽器這一頭的功能實作,后端工程師負責另一頭,也就是服務器上的邏輯實作,當我們打開一個網頁的時候,瀏覽器會向服務器發送 HTTP 請求,服務器根據請求的內容處理資料,將正確的資料回傳,可以說,HTTP 協議將瀏覽器與服務器連接在了一起,
??因為 Web 開發中的許多問題既與客戶端有關也與服務端有關,所以前端工程師很有必要了解 HTTP 協議,比如要優化性能,加快頁面的打開速度,就需要理解 TCP 協議和 HTTP 協議,理解連接是如何建立的,資料是如何傳輸的,有興趣可以參考之前記錄的 http 相關知識點
理解 MIME 型別
瀏覽器可以處理多種格式的媒體檔案,遵循的標準叫做 MIME,
MIME 標準以type/subtype,即主型別/子型別,來表示一個檔案的格式,MIME 型別對大小寫不敏感,通常都寫成小寫形式,
HTTP 請求常見的主型別如下:
|
型別 |
描述 |
典型示例 |
|
text |
表明檔案是普通文本,理論上是人類可讀 |
text/plain, text/html, text/css, text/javascript |
|
image |
表明是某種影像,不包括視頻,但是動態圖(比如動態 gif)也使用image型別 |
image/gif, image/png, image/jpeg, image/bmp, image/webp, image/x-icon |
|
audio |
表明是某種音頻檔案 |
audio/midi, audio/mpeg, audio/webm, audio/ogg, audio/wav |
|
video |
表明是某種視頻檔案 |
video/webm, video/ogg |
|
application |
表明是某種二進制資料 |
application/octet-stream, application/pkcs12, application/vnd.mspowerpoint, application/xhtml+xml, application/xml, application/pdf |
瀏覽器的請求頭中的 Accept 欄位包含該請求期望的 MIME type,可以有多個,以逗號分隔,
所以,Accept: image/webp,image/apng,image/*,*/*;q=0.8表示瀏覽器期望的格式依次是image/webp、image/apng、image/*、*/*, MIME 型別支持通配符*,最后的q=0.8表示相對品質因子,也就是說客戶端“期望”是這個型別的權重,這個值給服務器參考,如果有多個可能回傳的型別帶有品質因子,服務器優先回傳品質因子大的型別,
瀏覽器快取策略
??靜態資源檔案一般不會變化,所以當客戶端請求過某個檔案之后,瀏覽器可以將這個檔案快取下來,這么做可以節省 HTTP 請求,既能夠降低服務器的帶寬消耗,也能夠提升用戶的訪問速度,在 HTTP 協議中,動作 GET 和 OPTIONS 是支持快取的,
瀏覽器支持兩種標準的快取策略:強快取和協商快取,
瀏覽器快取策略根據回應頭的cache-control 來控制,
Cache-Control
Cache-Control 通用訊息頭欄位,被用于在 http 請求和回應中,通過該欄位來實作快取機制,
通俗理解:告訴瀏覽器,當前這個資源要怎么快取,
指令可快取性
- public:表明回應可以被任何物件(包括:發送請求的客戶端,代理服務器,等等)快取,
- private:表明回應只能被單個用戶快取,不能作為共享快取(即代理服務器不能快取它),比如:Cache-Control: private, max-age=360000,意思:中間層(代理)或者說CDN 不快取此資源,
只有瀏覽器可以快取, - no-cache:每次都去進行協商快取,確定資源是否有變更,一般用在index.html, 資源會快取到本地,強制要求快取把請求提交給原始服務器進行驗證 (協商快取驗證),
- no-store:不進行強制快取和協商快取,直接拉取最新的資源,資源不快取到本地,即不使用任何快取,
強快取
服務器回傳資源的時候帶有Cache-Control回應頭,這個策略叫做強快取,
回應頭只要帶有cache-control 就使用強快取策略,當然值不能是no-store(不進行快取)
Cache-Control回應頭的最常用格式為:
Cache-Control: max-age=<seconds>
其中 seconds 是快取的時間,單位是秒,
當瀏覽器請求資源得到的回應帶有Cache-Control回應頭時,瀏覽器會將該資源快取到本地,當瀏覽器下一次訪問該資源時,同時滿足以下 3 個條件,瀏覽器會直接使用本地的資源,不發起 HTTP 請求:
- 兩次請求的 url 完全相同(包括了
host、pathname、query) - 請求的動作是
GET - 請求頭不帶有
Cache-Control: no-cache和Pragma: no-cache這兩個資訊

協商快取
協商快取,以 HTTP 內容協商的方式來實作的快取,協商快取規定,瀏覽器發起 HTTP 請求時,服務器可以回傳Last-Modified回應頭,這個回應頭的值是一個時間戳,如果服務器這么做了,那么瀏覽器會快取這個資源,并且在今后請求該資源的時候,會帶有if-modified-since請求頭,它的值是上一次Last-Modified回應頭中的時間戳,
??服務器收到帶有if-modified-since請求頭的請求,根據請求頭中的時間戳,對檔案進行判斷,如果檔案內容在該時間戳之后到當前時間里沒有被修改,那么服務器回傳一個 304 回應,該回應表示只有 HEAD 沒有 BODY,瀏覽器如果收到 304 回應,就會以快取的內容作為 BODY,
??除來Last-Modified回應頭,還有一個 Etag 回應頭,它的機制和Last-Modified大同小異,只是把Last-Modified的時間戳換成Etag簽名,相應地把If-Modified-Since欄位換成If-None-Match欄位,其中Etag的值可以用資源檔案的 MD5 或 sha 簽名,??
??協商快取為什么要有兩種呢?
??因為,有時候我們的網站是分布式部署在多臺服務器上,一個資源檔案可能在每臺服務器上都有副本,相應地資源檔案被修改時候,新的檔案要同步到各個服務器上,導致各個檔案副本的修改時間不一定相同,那么當用戶一次訪問請求的服務器和另一次訪問請求的服務器不同時,就有可能因為兩個檔案副本的修改時間不同而使得Last-Modified形式的協商快取失效,
??如果這種情況采用Etag形式的協商快取,根據檔案內容而不是修改時間來判斷快取,就不會有這個問題了,
瀏覽器快取注意點
??通過地址欄訪問、以及強制重繪網頁的時候,HTTP 請求頭自動會帶上Cache-Control: no-cache和Pragma: no-cache的資訊,只要有這兩個請求頭之一,瀏覽器就會忽略回應頭中的Cache-Control欄位,即忽略強快取,
強制重繪的區別
??因為強制重繪會帶上Cache-Control: no-cache和Pragma: no-cache請求頭且不會帶上If-Modified-Scene和If-None-Match請求頭,意思是不使用快取,忽略快取,
max-age = 0 和 no-cache 有啥區別
??no-cache 不進行強快取,走協商快取,而max-age=0是進行強快取,但是過期了,需要更新,雖然實際上看起來兩者效果是一樣的,
快取位置
?一般是快取到記憶體以及硬碟
- from memory cache 表示資源是從記憶體當中獲取的,瀏覽器關閉后該資源記憶體會被釋放,
- from disk memory 表示資源是從硬碟中讀取的,關掉瀏覽器資源依然在,
小結
- 瀏覽器能不能快取核心是服務端端回傳的回應頭決定,如強快取的標識頭,協商快取的兩個標識頭,整個程序主要由服務端控制;
-
強快取識別符號:回應頭的cache-control: 不是no-store,強快取的狀態碼是200,帶上from memory cache/from disk memory
協商快取識別符號:
回應頭的帶有
Last-Modified,表示快取起來,下次請求帶上If-Modified-Since,值是上次 Last-Modified的值,回應頭的帶有
ETag,表示快取起來,下次請求帶上If-None-Match,值是上次 ETag的值,(1)如果一致說明檔案內容沒有發生變化,直接回傳304;
(2)如果不一致回傳200 + 最新資源 + 最新的 ETag字串, -
強制重繪會HTTP 請求頭自動會帶上
Cache-Control: no-cache和Pragma: no-cache請求頭且不會帶上If-Modified-Scene和If-None-Match,意思是不使用快取,忽略快取,
nodejs 架構圖

Node.js的結構大致分為三個層次:
Node Standard Library是我們每天都在用的標準庫、api,如 Http、Buffer、fs 等模塊,它們都是由 JavaScript 撰寫的,可以通過require(..)直接能呼叫,Node Bindings是溝通 JS 和 C++ 的橋梁,封裝 V8 和 Libuv 的細節,向上層提供基礎API服務,這一層是支撐 Node.js 運行的關鍵,由 C/C++ 實作,-
第三層是支撐 Node.js 運行的關鍵,由 C/C++ 實作,
V8是 Google 開發的 javascript 引擎,為 javascript 提供了在非瀏覽器端運行的環境,可以說它就是 Node.js 的發動機,它的高效是 Node.js 之所以高效的原因之一,Libuv為Node.js提供了跨平臺,執行緒池,事件池,異步 I/O 等能力,是Node.js如此強大的關鍵,C-ares提供了異步處理 DNS 相關的能力,http_parser、OpenSSL、zlib等,提供包括 http 決議、SSL、資料壓縮等其他的能力,
轉載請註明出處,本文鏈接:https://www.uj5u.com/qiye/552560.html
標籤:其他
上一篇:Node 除錯利器,前端、Node 開發必備 - VSCode JS Debug Terminal
下一篇:返回列表
