靜態(tài)文件服務(wù)器實現(xiàn)

nodejs不僅僅可以用來寫服務(wù)端接口，用來做靜態(tài)文件服務(wù)器替代nginx的功能， 也是分分鐘可以搞定的。 話不多說，先上代碼：

var server=http.createServer(function (req,res){
 fs.createReadStream(Path.resolve(__dirname,"."+req.url)).pipe(res);
})

在項目根目錄建一個hello.html文件測試一下 hello.html內(nèi)容如下：

<h1>hello,world</h1>

node app.js運行，打開瀏覽器訪問一下： http://localhost/hello.html

我們再回頭審視一下代碼，的確就只有這么簡單，這要歸功于node Stream類 pipe方法的強大，fs.createReadStream讀取本地文件創(chuàng)建一個可讀流（ReadStream類的實例），再使用pipe導(dǎo)流到res響應(yīng)流，res是一個http.ServerResponse類的實例，是一個可寫流，繼承自 Stream類

http.ServerResponse類的繼承關(guān)系如下：

安全性考慮

上述代碼實現(xiàn)靜態(tài)文件服務(wù)器后，意味著項目根目錄下所有的文件（遞歸）都可以通過瀏覽器直接訪問和下載了，這樣會帶來一些安全性的問題，想想看，你的服務(wù)器端代碼和配置文件都能通過瀏覽器直接下載了，因此需要在代碼里加一些限制，例如只能訪問特定的目錄下的文件和特定擴(kuò)展名的文件，這樣還不夠，參考OWasp Top 10安全風(fēng)險（第4條-不安全的對象直接引用）,攻擊者仍然可以通過../../目錄回溯的方法訪問到其它目錄，對于訪問路徑中包含..的也要全部過濾掉。

實現(xiàn)mine type

mime type是指http 響應(yīng)頭中的content-type字段，它決定了瀏覽器如何解析文件，是直接當(dāng)做純文件顯示(text/plain)，還是做為html文件渲染(text/html)，或者當(dāng)做二進(jìn)制文件下載，沒有輸出正確的mine type，可能導(dǎo)致圖片文件無法顯示，字體文件無效，視頻文件無法播放的問題。要實現(xiàn)起來也十分簡單，只需要做一個映射表，不同文件擴(kuò)展名，在響應(yīng)頭的content-type字段中輸出對應(yīng)的mine type就行了。

完整代碼如下：

const http=require("http");
const Path=require("path");
const fs=require("fs");

var server=http.createServer(function (req,res){
 const fileName=Path.resolve(__dirname,"."+req.url);
 const extName=Path.extname(fileName).substr(1);

 if (fs.existsSync(fileName)) { //判斷本地文件是否存在
  var mineTypeMap={
   html:'text/html;charset=utf-8',
   htm:'text/html;charset=utf-8',
   xml:"text/xml;charset=utf-8",
   png:"image/png",
   jpg:"image/jpeg",
   jpeg:"image/jpeg",
   gif:"image/gif",
   css:"text/css;charset=utf-8",
   txt:"text/plain;charset=utf-8",
   mp3:"audio/mpeg",
   mp4:"video/mp4",
   ico:"image/x-icon",
   tif:"image/tiff",
   svg:"image/svg+xml",
   zip:"application/zip",
   ttf:"font/ttf",
   woff:"font/woff",
   woff2:"font/woff2",

  }
  if (mineTypeMap[extName]) {
   res.setHeader('Content-Type', mineTypeMap[extName]);
  }
  var stream=fs.createReadStream(fileName);
  stream.pipe(res);
 }

 
})
server.listen(80);

實現(xiàn)gzip

對于文本類型的文件，如html,js,css，采用gzip壓縮可以大幅減少傳輸量，提升服務(wù)器傳輸性能,當(dāng)然這會損耗一點服務(wù)器的cpu性能做為代價，如果客戶端瀏覽器支持gzip壓縮，則會在請求頭的accept-encoding中攜帶gzip關(guān)鍵字，用node自帶的zlib類就可以實現(xiàn)gzip壓縮了，只要在stream.pip實多加一層，先導(dǎo)流到gzip流，再導(dǎo)出到res流，當(dāng)然，還要在響應(yīng)頭中添加Content-Encoding為gzip，這樣瀏覽器才能正確識別到http body是采用gzip算法壓縮的，并進(jìn)行自動解壓縮。

代碼如下：

const zlib = require('zlib');

if (req.headers["accept-encoding"].indexOf("gzip")>=0 && (extName=="js" || extName=="css" || extName=="html"))) {
  res.setHeader('Content-Encoding', "gzip");
  const gzip = zlib.createGzip();
  stream.pipe(gzip).pipe(res);
 }

客戶端緩存

http協(xié)議的緩存協(xié)商流程比較長，最終在響應(yīng)頭中生成expire（絕對時間）和cache-control（相對時間）兩個用于控制緩存過期時間的參數(shù)，瀏覽器下次請求該文件時，分為以下幾種情況：

• 如果沒到過期時間，瀏覽器不會請求文件直接讀緩存
• 如果已到過期時間，則會在請求頭中l(wèi)ast-modified字段攜帶文件的最后修改日期，如果對比時間戳與服務(wù)器文件一致，則HTTP 返回 304: Not Modified
• 如果按下f5刷新，會在請求頭中if-modified-since字段中攜帶緩存的過期時間，如果對比時間戳與服務(wù)器文件一致，則HTTP 返回 304: Not Modified
• ctrl+f5刷新，請求頭中攜帶 cache-control: no-cache，強制禁用緩存。重新下載文件

邏輯分支較多，但都是日期比對，搞清楚緩存協(xié)商過程比較容易寫出來，有興趣的同學(xué)可以自行實現(xiàn)

高性能靜態(tài)文件服務(wù)器優(yōu)化

如果要做一個高性能的靜態(tài)文件服務(wù)器僅實現(xiàn)gzip和緩存協(xié)商是不夠的，涉及到本地文件的頻繁讀取，高并發(fā)下I/O必定成為瓶頸，考慮到服務(wù)器上的文件是很少更新的， 可以用Buffer把文件流緩存到內(nèi)存中，每次請求時先在內(nèi)存中查找匹配項，如果命中了直接從內(nèi)存中返回，避免了讀取磁盤，gzip也不用壓縮了，直接用壓縮好的文件流返回，可以成倍的大幅提升性能。當(dāng)然如果文件太多了，內(nèi)存也會飆升，需要考慮淘汰算法，只緩存訪問次數(shù)高的文件，剔除低訪問量的文件。

采用fs.watch監(jiān)控目錄文件的變化，如果文件有更新，則刪掉緩存。

小結(jié)

Node.js 內(nèi)置的pipe方法可以非常簡便的實現(xiàn)將服務(wù)器本地文件輸出到http 響應(yīng)流中，gzip壓縮也同樣可以通過pipe實現(xiàn)，再配合輸出mine type 實現(xiàn)的靜態(tài)服務(wù)器已經(jīng)可以滿足一般業(yè)務(wù)的使用。如果要實現(xiàn)高性能的靜態(tài)文件服務(wù)器，還需要實現(xiàn)客戶端緩存、服務(wù)端緩存功能（本文提供了思路，按圖索驥也非難事）。

最后，推薦一下個人的開源項目， node.js web開發(fā)框架，已包含本文靜態(tài)文件服務(wù)器的功能 webcontext: https://github.com/windyfancy/webcontext

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評論