【架构】客户端优化

这篇文章总结一下服务器网关及之前部分的优化，如客户端的优化，CDN/DNS等。

这里我们先谈一谈客户端缓存优化的手段。一般我们后端在说到缓存，第一时间想到的往往是redis，其实缓存在架构层次还有很多其他可以实现的地方，如客户端缓存。对不同的场景，我们可以尝试不同的客户端优化手段。

1，资源下载

压缩资源：对资源进行压缩，如某些业务场景，不需要展示全像素的图片，可以图片压缩成缩略图，存储在文件系统中，前端需要时，将缩略图传输给前端进行展示，只有在必要时，才会将全像素的原图传输给前端。或者如我们在下载某些资源时，常常是zip格式，这也是对资源进行压缩的表现。

删除不必要的cookie：浏览器第一次访问服务器时，会生成一个session对象保存在服务器中，浏览器中保存sessionId作为查询用户信息的凭证[1,2]，而浏览器在访问服务器时，将sessionid放在了cookie中。对于开发来说，有时候经常会随手携带上cookie。但其实对于接口不需要的session和cookie的，我们可以不用带上cookie，避免带宽的占用。

js删除无效字符和注释：这个的作用有两个，1是降低体积。2是为了代码安全，防止代码被轻易理解，进而对于服务器的恶意攻击。

css压缩：类似js压缩。1是删除注释，无效的字符、空格、回车。可以借助压缩网站进行压缩[3]。2是样式的语义合并

http请求压缩：head中加参数：Accept-Encoding：gzip，deflate，表示 客户端 可以接受的压缩内容的格式，客户端接收到数据后可以以这种格式进行解压；服务端响应时，在head中加参数: Content-Encoding:gzip，并在服务端手动做一些压缩的操作。

此外由于这种方式浏览器需要等待服务器将数据压缩完再发送给浏览器，等待时间长。因此往往配合transfer-encoding:chunked来使用，服务器将会把数据分块压缩并直接传输给浏览器，浏览器不用等待所有数据都压缩完再解压[4]。

将多个小图标合并为雪碧图（CSS Sprite, CSS精灵）：如官网边缘常常显示多个小图标，这种小图标如果每个都单独请求接口，对于网络的压力会更大。可以使用这种叫做雪碧图[5,6]的技术，将多个小图标合并为雪碧图，可以减轻后端网络的压力。前端通过指定background-position来指定小图标坐标。

前端 < svg >生成矢量图代替后端直接传输矢量图图片：< svg >可以用于生成矢量图[7]，这种生成的矢量图可以无限放大而不失真，同时后端也只用传输矢量图的数据而不是图片本身，减小了网络压力。

js文件合并打包：将多个js文件合并为一个文件，便于下载。

使用base64编码对图片进行转换后再压缩：如果图片不适用前面直接对图片压缩为缩略图的方式，可以使用这种方式，先使用base64将图片转换为字符串，再使用压缩算法对字符串进行压缩。客户端那里反向解压再转换回图片。如一篇文章[8]中举例，使用base64编码后，字符串大小和图片本身差不多大。再使用gzip压缩，压缩率可达50%以上。

转移第三方：将文件系统的压力转移给第三方，如阿里云OSS服务。

2，资源缓存优化

资源缓存是对资源下载的优化之一，但是客户端缓存的优化比较复杂，这里单独拆出来讲。通俗的说，资源缓存有客户端缓存/页面缓存，代理服务器缓存/CDN缓存，这些缓存并不是孤立存在，经常是同时存在的。此时需要前端与后端一起对缓存进行控制，如下所述。

客户端/页面缓存 & CDN/代理缓存[13]：控制 客户端、各级代理（中间的各个节点），对页面资源的缓存。请求头中添加Cache-Control，有些参数是客户端请求时添加的缓存请求指令，有些参数是服务端响应时添加的缓存响应指令，列举参数如下[13]：

缓存策略：

//public和private是服务器做响应时添加的参数才能生效。
pubic（服务器 响应）: 各级都能缓存。

private（服务器 响应）: 只能 客户端 缓存，中间各级不缓存，默认就是private。

no-cache: (请求，响应)：可以缓存，但是不能直接使用缓存，要去服务端验证一下（即缓存协商）。

no-store: (请求，响应)：哪都不要存。

缓存有效期：

max-age=秒（服务器 响应），缓存可以存活的相对时间。

s-maxage=秒（服务器 响应），在各级cache服务器（CDN，代理服务器