HTTP前端优化之压缩与缓存

1.压缩

现代的浏览器以及服务器都支持压缩技术，惟一须要协商的是采用的压缩算法。 为了选择采用的压缩算法，浏览器和服务器之间会使用主动协商机制

• 浏览器发送Accept-Encoding首部，（其中包含它所支持的压缩算法，以及各自优先级）
• 服务器则从中选择一种，使用该算法对响应消息主体进行压缩，而且发送Content-Encoding首部来告知浏览器它使用了哪种算法

因为该内容协商过程是基于编码类型来选择资源的展示形式的，在响应中，Vary（渲染引擎）首部中至少要包含Accept-Encoding;这样，缓存服务器就能够对资源的不一样的展示形式进行缓存。

以下图：

也就是：

• 客户端（HTTP请求头） -------> accept-encoding: gzip,deflate,br,sdch
• 服务器（HTTP响应头） -------> content-encoding:gzip

实例

gzip(filePath, req, res, statObj) {
        let encoding = req.headers["accept-encoding"]
        if (encoding) {
            if (encoding.match(/gzip/)) {
                res.setHeader("Content-Encoding","gzip")
                return zlib.createGzip()
            } else if (encoding.match(/deflate/)) {
                res.setHeader("Content-Encoding","deflate")
                return zlib.createDeflate()
            }
            return false
        }
        return false
    }
   let flag = this.gzip(filePath, req, res, statObj)
   let type = mime.getType(filePath) || "text/plain"  
   res.setHeader("Content-Type", type + "; charset=utf8")
   if(!flag){
        fs.createReadStream(filePath).pipe(res)
    }else{
        fs.createReadStream(filePath).pipe(flag).pipe(res)
     }

复制代码

压缩的优缺点

• 优势：减小HTTP响应时间，提高传输效率
• 压缩过程占用服务器额外的CPU周期，客户端也要对压缩文件进行解压缩，这也须要占用部分时间。

总结：

请求头：

• Accept-Encoding: gzip,deflate,br,sdch；告知服务器本身支持的压缩格式
• user-agent: 不一样设备自动带上这个头，能够判断什么样的设备，重定向到相同的项目，实现不一样设备响应不一样项目

响应头：

• COntent-encoding:gzip; 告知浏览器，服务器使用的压缩格式
• Content-Type： 服务器给浏览器响应内容的类型
• Location: 重定向到某个地方

2.缓存

假设浏览器存在一个缓存数据库，用于存储缓存信息。

在客户端第一次请求数据时，此时缓存数据库中没用对应的缓存数据，须要请求服务器，服务器返回后，将数据存储至缓存数据库中。

HTTP缓存有多种规则，根据是否须要从新向服务器发起请求进行分类 将其分为两大类（**强制缓存，对比缓存又叫协商缓存）

1. 已存在缓存数据，仅基于强制缓存，请求数据以下

2. 已存在缓存数据，仅基于对比缓存，请求数据以下

两类缓存规则不一样：

• 强制缓存若是生效，不须要再和服务器发生交互
• 对比缓存（协商缓存）不论是否生效，都须要与服务器端发生交互

**两类缓存规则同时存在时，强制缓存优先级高于对比缓存，也就是说，当执行强制缓存的规则时，若是缓存生效，直接使用缓存，再也不执行对比缓存规则

强制缓存

在没有缓存数据时，浏览器向服务器请求数据时，服务器会将数据和缓存规则一并返回，缓存规则信息包含在响应header中；

对于强制缓存来讲，响应头中会有连个字段表名失效规则（Expires/Cache-Control）

Expires

Expries的值为服务器端返回的到期时间，即下一次请求时，请求的时间小于服务端返回到期时间，直接使用缓存数据。不过Expries是HTTP1.0的东西，如今浏览器默认使用的是HTTP1.1，因此它的做用基本忽略

另外一个问题，到期时间使用服务端生成的，可是客户端时间可能跟服务端时间有偏差，这就致使了缓存命中的偏差，所以，HTTP1.1版本中，使用了Cache-Control替代

Cache-Control

Cache-Control是最重要的规则，其常见取值：

• private：客户端能够缓存
• public：客户端和代理服务器均可缓存
• max-age=xxx：缓存的内容将在xxx秒后失效
• no-cache：须要使用对比缓存来验证缓存数据
• no-store：全部内容都不会缓存，强制缓存，对比缓存都不触发，

实例：

图中Cache-Control仅指定了max-age，全部默认是private，缓存时间是31536000秒（365天） 也就是说，在365天内再次请求这条数据，都会直接获取缓存数据库中的数据，直接使用。

对比缓存（协商缓存）

浏览器第一次请求数据时，服务器会将缓存标识u数据一块儿返回给客户端，客户端将两者备份至缓存数据库中， 再次请求数据时，客户端将备份的数据标识发送给服务器，服务器根据缓存标识进行判断，判断成功后，返回304状态码，通知客户端比较成功，可使用缓存数据

经过两图对比，可发现，在对比缓存生效时，状态码是304，而且报文大小和请求时间大大减小。 缘由是，服务器在进行标识比较后，只返回header部分，经过状态码通知客户端使用缓存，再也不须要将报文主体部分返回给客户端。

缓存标识：

Last-Modified/If-Modified-Since

Last-Modified:

服务器在响应请求时，告诉浏览器资源的最后修改时间。

If-Modified-Since:

再次请求服务器时，经过此字段通知服务器上次请求时，服务器返回的资源最后的修改时间。 服务器收到请求后发现头有 If-Modified-Since 则与请求资源的最后修改时间进行对比。 若资源的最后修改时间大于 If-Modified-since ，说明资源又被改动过，则响应整片资源内容，返回状态码200； 若资源的最后修改时间小于或等于 If-Modified-Since ，说明资源没有新修改过，则响应HTTP304，告诉继续使用缓存中的数据

**Etag/If-None-Match

优先级高于 Last-Modified/If-Modified-Since

Etag:

服务器响应请求时，告诉浏览器当前资源在服务器的惟一标识（摘要）

If-None-Match：

再次请求服务器时，经过此字段通知服务器客户端缓存数据的惟一标识， 服务器收到请求后发现请求头中有 If-None-Match 则与被请求资源的惟一标识进行比对， 不一样，说明资源又被改动过，则响应整片资源内容，返回状态码200； 相同，说明资源没有新修改过，则响应HTTP304，告知浏览器使用缓存数据

总结

对于强制缓存，服务器通知浏览器一个缓存时间，在缓存时间内，下次请求，直接用缓存，不在时间内，执行比较缓存策略：

• Expries/Cache-Control:max-age=xxx > Etag/If-None-Match > Last-Modified/If-Modified-Since

对于比较缓存，将缓存信息中的Etage和Last-Modified经过请求发送给服务器，由服务器校验，返回304状态码时，浏览器直接使用缓存数据。

浏览器第一次请求：

浏览器再次请求时：

实例：

cache(filePath, req, res, statObj){
        let lastModified = statObj.ctime.toGMTString()
        let ifModifiedSince = req.headers['if-modified-since']
        let Etag =             crypto.createHash("md5").update(fs.readFileSync(filePath)).digest("base64")

        res.setHeader("Last-Modified",lastModified)
        // Etag是响应头
        res.setHeader("Etag",Etag)
        // if-none-match 当你修改服务器上的文件时，请求头上面会自动添加这个头
        // console.log(req.headers['if-none-match'],"match")
        // console.log(Etag)
        // if-none-match： NISthsES8P9vzWjdFT/xyg== match

        // console.log(req.headers['if-none-match'])
        // T9hRJPsOY4/I9QhWp+NFlQ==

        // 若是if-none-match存在，说明你改动服务器上的文件中的内容
        // T9hRJPsOY4/I9QhWp+NFlQ==

        // console.log("Etag--->",Etag)
        // console.log("if-none-match--->",req.headers['if-none-match'])
        let ifNoneMatch = req.headers['if-none-match']
        // // 根据内容摘要判断是否须要缓存
        // if(ifNoneMatch){
        // // ifNoneMatch说明修改了内容
        // // return false;

        // if(ifNoneMatch !== Etag){
        // // 修改了内容，而且没恢复，走网络
        // return false; // 不走缓存
        // }else{
        // // 修改了内容，而且修改完后，把内容恢复，至关于没有修改
        // return true; // 仍是从缓存中取数据
        // }
        // }else{
        // // 说明内容没有改变 
        // return true // 
        // }
        // // 根据修改时间来判断是否缓存
        // if(ifModifiedSince){
        // if(ifModifiedSince !== lastModified){
        // // 上一次修改的时间和最新修改的时间不同
        // return false // 不走缓存
        // }
        // }
        // 压缩和缓存是后端程序干的 
        if(ifModifiedSince && ifNoneMatch){
            if(ifNoneMatch !== Etag && ifModifiedSince !== lastModified){
                return false
            }
        }else{
            return false
        }

        return true

    }
 sendFile(filePath, req, res, statObj) {
        res.setHeader("Cache-Control","no-cache");

        let cache = this.cache(filePath, req, res, statObj)
        if(cache){
            res.statusCode = 304;
            return res.end()
        }

        let flag = this.gzip(filePath, req, res, statObj)
        let type = mime.getType(filePath) || "text/plain"  
        res.setHeader("Content-Type", type + "; charset=utf8")
        if(!flag){
            fs.createReadStream(filePath).pipe(res)
        }else{
            fs.createReadStream(filePath).pipe(flag).pipe(res)
        }
    }
复制代码