背景
作为前端工程师，我想大家肯定对动态文件服务器不会生疏。所谓的动态文件服务器做的工作就是将咱们的前端动态文件(.js/.css/.html)传输给浏览器，而后浏览器再将咱们的页面渲染进去。咱们罕用的webpack-dev-server就是本地开发用的动态文件服务器，而个别线上环境咱们会应用nginx，因为它更加稳固和高效。既然动态文件服务器无处不在，那么它们又是如何实现的呢？本篇文章将带你手把手实现一个高效的动态文件服务器。
性能介绍
咱们的动态服务器包含上面两个性能:
- 当用户申请的内容是
文件夹时，展现以后文件夹的构造信息 - 当用户申请的内容是
文件时，返回文件的内容
咱们来看一下实际效果，服务端的动态文件目录是这样的:
static└── index.html拜访localhost:8080能够获取根目录的信息:
在根目录下只有一个index.html文件。咱们点击index.html文件能够获取这个文件的具体内容:
代码实现
依据下面的需要形容，咱们先用流程图来设计一下咱们的逻辑如何实现:
其实动态文件服务器的实现思路还是很简略的：先判断资源存不存在，不存在就间接报错，资源存在的话依据资源的类型返回对应的后果给客户端就能够了。
根底代码实现
看完下面的流程图，我置信大家的思路根本清晰了，接着咱们看一下具体的代码实现:
const http = require('http')const url = require('url')const fs = require('fs')const path = require('path')const process = require('process')// 获取服务端的工作目录，也就是代码运行的目录const ROOT_DIR = process.cwd()const server = http.createServer(async (req, resp) => { const parsedUrl = url.parse(req.url) // 删除结尾的'/'来获取资源的相对路径，e.g: `/static`变为`static` const parsedPathname = parsedUrl.pathname.slice(1) // 获取资源在服务端的绝对路径 const pathname = path.resolve(ROOT_DIR, parsedPathname) try { // 读取资源的信息, fs.Stats对象 const stat = await fs.promises.stat(pathname) if (stat.isFile()) { // 如果申请的资源是文件就交给sendFile函数解决 sendFile(resp, pathname) } else { // 如果申请的资源是文件夹就交给sendDirectory函数解决 sendDirectory(resp, pathname) } } catch (error) { // 拜访的资源不存在 if (error.code === 'ENOENT') { resp.statusCode = 404 resp.end('file/directory does not exist') } else { resp.statusCode = 500 resp.end('something wrong with the server') } }})server.listen(8080, () => { console.log('server is up and running')})在下面的代码中我应用http模块创立了一个server实例，这个实例外面定义了解决所有HTTP申请的handler函数。handler函数实现比较简单，读者依据下面的代码正文就可以看明确了，这里想要阐明一下我为什么应用fs.promises.stat来获取资源的元信息(fs.Stats类，包含资源的类型和更改工夫等)而不应用能够实现同一个性能的fs.stat和fs.statSync:
fs.promises.stat vs fs.stat:fs.promises.stat是promise-style的，能够应用async和await来实现异步的逻辑，代码很洁净。而fs.stat是callback-style的，这种API写异步逻辑最初可能会变成意大利面条，前期保护艰难。fs.promises.stat vs fs.statSync:fs.promises.stat读取文件的信息是一个异步操作，不会阻塞主线程的执行。而fs.statSync是同步的，这也就意味着当这个API执行的时候，JS主线程会卡死，其它的资源申请是解决不了的。这里我也倡议当大家须要在服务端进行文件系统的读写的时候，肯定要优先应用异步API而防止应用同步式的API。
接着咱们来看一下sendFile和sendDirectory这两个函数的具体实现:
const sendFile = async (resp, pathname) => { // 应用promise-style的readFile API异步读取文件的数据，而后返回给客户端 const data = await fs.promises.readFile(pathname) resp.end(data)}const sendDirectory = async (resp, pathname) => { // 应用promise-style的readdir API异步读取文件夹的目录信息，而后返回给客户端 const fileList = await fs.promises.readdir(pathname, { withFileTypes: true }) // 这里保留一下子资源绝对于根目录的相对路径，用于前面客户端持续拜访子资源 const relativePath = path.relative(ROOT_DIR, pathname) // 结构返回的html构造体 let content = '<ul>' fileList.forEach(file => { content += ` <li> <a href=${ relativePath }/${file.name}>${file.name}${file.isDirectory() ? '/' : ''} </a> </li>` }) content += '</ul>' // 返回以后的目录构造给客户端 resp.end(`<h1>Content of ${relativePath || 'root directory'}:</h1>${content}`)}sendDirectory通过fs.promises.readdir来获取其底下的目录信息，而后以列表的模式返回一个html构造给客户端。这里值得一提的是：因为客户端须要依照返回的子资源信息进一步拜访子资源，所以咱们须要记录子资源绝对于根目录的相对路径。sendFile函数的实现绝对于sendDirectory会简略一点，它只须要读取文件的内容而后返回给客户端就能够了。
下面的代码写完后，咱们其实曾经实现了下面说的需要了，可是这个服务端是生产不可用的，因为它有很多潜在的问题没有解决，接着就让咱们看一下如何解决这些问题来优化咱们的服务端代码。
大文件优化
咱们先来看看在当初的实现下，客户端申请一个大文件会产生什么。首先咱们在static文件夹下筹备一个大文件test.txt，这个文件外面有1000万行Hello World!，文件的大小为124M:
而后咱们启动服务器，查看服务器启动实现后Node的内存占用状况:
能够看到Node服务只占用了8.5M的内存，咱们在浏览器拜访一下test.txt:
浏览器在疯狂输入Hello World!，这个时候再看一眼Node的内存占用状况:
内存应用一下子由8.5M激增到了132.9M，而减少的资源差不多就是文件的大小124M，这到底是为什么呢？咱们再来看一下sendFile文件的实现:
const sendFile = async (resp, pathname) => { // readFile会读取文件的数据而后存在data变量外面 const data = await fs.promises.readFile(pathname) resp.end(data)}下面的代码中，其实咱们会一次性读取文件的内容而后保留在data变量外面，也就是说咱们会将124M的文本信息保留在内存外面！你试想一下，如果有多个用户同时拜访大资源，咱们的程序必定会因为内存爆炸而OOM(Out of Memory)的。那么这个问题如何解决呢？其实node提供的stream模块能够很好地解决咱们的问题。
Stream
咱们先来看一下stream的官网介绍:
A stream is an abstract interface for working withstreaming datain Node.js.
There are many stream objects provided by Node.js. For instance, a request to an HTTP server andprocess.stdoutare both stream instances.Streams can be readable, writable, or both. All streams are instances ofEventEmitter
简略来说，stream就是给咱们流式解决数据用的，那么什么是流式解决呢？用最简略的话来说就是：不是一下子解决完数据而是一点一点地解决它们。应用stream， 咱们要解决的数据就会一点一点地加载到内存的某一个固定大小的区域(buffer)以给其它消费者生产。因为保留数据的buffer大小个别是固定的，当旧的数据处理完才会加载新的数据，因而它能够防止内存的解体。话不多说，咱们马上应用stream来重构一下下面的sendFile函数:
const sendFile = async (resp, pathname) => { // 为须要读取的文件创建一个可读流readableStream const fileStream = fs.createReadStream(pathname) fileStream.pipe(resp)}下面的代码中，咱们为须要读取的文件创建了一个可读流(ReadableStream)，而后将这个流和resp对象连接(pipe)在一起，这样文件的数据就会源源不断发送给客户端了。看到这里你可能会问，为什么resp对象能够和fileStream连贯在一起呢？起因就是这个resp对象底层是一个可写流(WritableStream)，而可读流的pipe函数接管的就是可写流。优化完后咱们再来申请一下test.txt大文件，同样浏览器一顿疯狂输入，不过这个时候Node服务的内存用量是这样的:
Node的内存根本稳固在9.0M，比服务刚启动时只多了0.5M！从这个能够看出咱们通过stream来优化的确达到了很好的成果。因为文章篇幅的限度，这里没有具体介绍stream的API如何应用，须要理解的同学能够自行查看官网文档。
缩小文件传输带宽
应用stream确实能够缩小服务端的内存占用问题，可是它没有缩小服务端和客户端传输的数据大小。换句话来说，如果咱们的文件大小是2M咱们就实打实传输这2M的数据给客户端。如果客户端是手机或者其它挪动设施的话，这么大的带宽耗费必定是不可取的。这个时候咱们须要对被传输的数据进行压缩而后再在客户端进行解压，这样传输的数据量能力大幅度缩小。服务端数据压缩的算法有很多，这里我应用了一个比拟罕用的gzip算法，咱们来看一下如何更改sendFile以反对数据压缩:
// 引入zlib包const zlib = require('zlib')const sendFile = async (resp, pathname) => { // 通过header通知客户端：服务端应用的是gzip压缩算法 resp.setHeader('Content-Encoding', 'gzip') // 创立一个可读流 const fileStream = fs.createReadStream(pathname) // 文件流首先通过zip解决再发送给resp对象 fileStream.pipe(zlib.createGzip()).pipe(resp)}在下面的代码中，我应用Node原生的zlib模块创立了一个转换流(Transform Stream)，这种流是既可读又可写的(Readable and Writable Stream)，所以它像是一个转换器将输出的数据进行加工而后输入到上游的可写流。咱们申请index.html文件来看一下优化后的成果:
上图中，第一行的申请是没有通过gzip压缩的申请大小，大略是2.6kB，而通过gzip压缩后传输数据一下子变成373B，优化成果非常显著！
应用浏览器缓存
数据压缩尽管解决了服务端客户端传输数据的带宽问题，可是没有解决反复数据传输的问题。咱们晓得一般来说服务器的动态文件是很少会扭转的，在服务端资源没有产生扭转的前提下，同一个客户端屡次拜访同一个资源，服务端会传输一样的数据，而这种状况下更无效的形式是：服务器通知客户端资源没有变动，你间接应用缓存就能够了。浏览器缓存的形式有很多种，有协商缓存和强缓存。对于这两种缓存的区别我想网络上曾经有很多文章说得很清晰了，我在这里也不再多说，本篇文章次要想说一下强缓存的Etag机制如何实现。
什么是Etag
其实Etag(Entity-Tag)能够了解为文件内容的指纹，如果文件内容产生了扭转那么这个指纹是大概率是会变的。这里留神的是我用了大概率而不是相对，这是因为HTTP1.1协定外面并没有规定etag具体生成算法是什么，这齐全是由开发者本人决定的。通常对于文件来说，etag是由文件的长度 + 更改工夫生成的，这种做法其实是会存在浏览器读取不到最新文件内容的状况的，不过这不是本文的重点，有趣味的同学能够参考网上的其它材料。
接着让咱们图解一下基于etag的协商缓存过程:
具体的过程如下:
- 浏览器第一次申请服务端的资源时，服务端会在Response外面设置以后资源的
etag信息，例如Etag: 5d-1834e3b6ea2 - 浏览器第二次申请服务端资源时，会在申请头部的
If-None-Match字段带上最新的etag信息5d-1834e3b6ea2。服务端收到申请解析出If-None-Match字段并将其和最新的服务端etag进行比照，如果是一样的就会返回304给浏览器示意资源无更新，如果资源产生了更改则将最新的etag设置到头部并且将最新的资源返回给浏览器。
接着咱们来看一下sendFile函数如何反对etag:
// 这个函数会依据文件的fs.Stats信息计算出etagconst calculateEtag = (stat) => { // 文件的大小 const fileLength = stat.size // 文件的最初更改工夫 const fileLastModifiedTime = stat.mtime.getTime() // 数字都用16进制示意 return `${fileLength.toString(16)}-${fileLastModifiedTime.toString(16)}`}const sendFile = async (req, resp, stat, pathname) => { // 文件的最新etag const latestEtag = calculateEtag(stat) // 客户端的etag const clientEtag = req.headers['if-none-match'] // 客户端能够应用缓存 if (latestEtag == clientEtag) { resp.statusCode = 304 resp.end() return } resp.statusCode = 200 resp.setHeader('etag', latestEtag) resp.setHeader('Content-Encoding', 'gzip') const fileStream = fs.createReadStream(pathname) fileStream.pipe(zlib.createGzip()).pipe(resp) }在下面的代码中我新增了一个计算etag的函数calculateEtag，这个函数会依据文件的大小和最初更改工夫算出文件最新的etag信息。接着我还批改了sendFile的函数签名，接管了req(HTTP申请体)和stat(文件的信息，fs.Stats类)两个新参数。sendFile会先判断客户端的etag和服务端的etag是不是一样的，如果雷同就返回304给客户端否则返回文件的最新内容并且在header设置最新的etag信息。同样咱们再次拜访index.html文件来验证优化成果:
上图能够看到第一次申请资源时浏览器没有缓存，服务端返回了文件的最新内容和200状态码，这个申请的理论带宽是396B，第二次申请时，因为浏览器有缓存并且服务端资源没有更新，所以服务端返回304状态码而没有返回理论的文件内容，这个时候的文件理论带宽是113B！能够看出优化成果是很显著的，咱们略微更改一下index.html的内容来验证一下客户端会不会拉到最新的数据:
从上图能够看出当index.html更新后，旧的etag生效，浏览器能够获取最新的数据。咱们最初再来看一下这三个申请的详细信息，上面是第一次申请时，服务端给浏览器返回etag信息:
接着是第二次申请时，客户端申请服务端资源时带上etag信息:
第三次申请，etag生效，拿到新的数据:
值得一提的是，这里咱们只通过etag实现了浏览器的缓存，这是不齐备的，理论的动态服务器可能会加上基于Expires/Cache-Control的强缓存和基于Last-Modified/Last-Modified-Since的协商缓存来优化。
总结
本篇文章我先实现了一个最简略能用的动态文件服务器，而后通过解决三个理论应用时会遇到的问题优化了咱们的代码，最初实现了一个简略高效的动态文件服务器。
如上文所说，因为篇幅的限度，咱们的实现上还是漏了很多货色的，例如MIME类型的设置，反对更多的压缩算法如deflate以及反对更多的缓存形式如Last-Modified/Last-Modified-Since等。这些内容其实在把握了下面的办法后很容易就能够实现了，所以就留给大家在须要真正用到的时候本人实现了。
集体技术动静
创作不易，如果你从这篇文章中学到货色，请给我点一下赞或者关注，你的反对是我持续创作的最大能源！
同时欢送关注公众号进击的大葱一起学习成长