一文看懂静态资源服务沉浮及其在携程的演进( 六 ) _静态资源服务

总之，虽然有佚失的风险，可要是每笔汇款不论多少都固定收取一分钱的手续费，那么一毛一毛地打钱也太不划算了。买东西要凑单，静态资源要合并，都是自然而然的选择。

文章插图

res-concat 示例
2015年， gulp / grunt / webpack 等等前端构建工具已如雨后春笋般崭露头角， JavaScript Bundle 渐渐深入人心。不同于这些大刀阔斧的构建工具，我们的静态资源在线合并功能是一场润物细无声的毛毛雨，强调的是“在线”二字，针对的是存量资源。只需要调整一下 URL 的写法，就可以实现资源合并的目的，不需要投入学习成本，也不涉及任何代码重构。
在线合并看起来就像 1+1=2 那么简单，事实上它就是那么简单。至于加法背后的 Nginx 模块开发（专司 /res/concat 路由）、ProtocolBuffers 协议应用（解决源站应用和提供合并功能的服务集群之间的通讯问题）、原始资源混淆压缩结果的缓存结构设计……等等，不过是细节。
不要过分关注那些细节，因为， HTTP/2 已经来了。相比于 HTTP/1.1 ，前者虽然在语义上一脉相承，但从网络传输的角度看，则是一个全新的协议：基于流 / 消息 / 帧的多路复用设计，彻底解决了队首阻塞问题，同一域名下的并发 TCP 连接已经没有必要；而 HPACK 的引入，不仅借助静态字典大幅压缩了首部尺寸（比如 Access-Control-Allow-Origin这么长的字段名，直接用编号 20 替代了），而且利用先入先出的动态字典节省了多个请求 / 响应之间重复首部所耗费的字节（简而言之，如果下一个请求中不加说明，那就默认其首部“同上”）。这就意味着，合并资源的现实基础不复存在了！
站在2015年的春风里向前眺望， HTTP/2 的大规模落地，也就只剩三、五年的光景。缝缝补补的在线合并功能，并不能满足大家对于静态资源解决方案的预期。在线生意日益繁荣，背后的开发迭代速度越来越快，业务条线的同事于是也越来越多频繁地发出直击灵魂的质问：明明已经发布了，浏览器端的静态资源为什么不更新？
五、对啊，为什么不更新？！遇到疑难杂症，前端写手们有一句口头禅：清一下缓存！似乎，没有什么问题是 F5 解决不了的，如果有，那就Ctrl+F5 。F5 敦促浏览器询问服务器：自从我上次访问这个URL 以来，它的内容有没有变过？请求首部中通常包含 If-None-Match 或If-Modified-Since 字段，对应上次响应中的 ETag 和 Last-Modified 。倘若有变，返回新的内容；否则返回 304 Not Modified 。如果是 Ctrl+F5 ，便不啰嗦，就像一个从未谋面的陌生人那样生硬地说：拿来！于是就拿来了。

文章插图

图片引自 Ilya Grigorik, HTTP 缓存
但是，被 CDN 横插一杠之后，屡试不爽的一指禅和二指禅，好像都不管用了。静态资源内容一旦离开源站，何时过期（Expires: <http-date>），又或者能活多久（Cache-Control: max-age=<seconds>），已是命中注定。虽然按照 HTTP 协议，作为客户端，是允许对着代理或者反向代理作（zuō）的。
• 它可以在请求中委婉地说：
你帮我去问问源站有没有更新？
Cache-Control: no-cache
• 它可以矫情：
快过期的缓存，我可不要！
Cache-Control:min-fresh=<seconds>
• 它可以年龄歧视：
太老的缓存，我也不要！
Cache-Control:max-age=<seconds>
• 它甚至还可以不管不顾：
别拦我，我就是要去源站！
Cache-Control: no-store
没错，协议上是这么说来着。只是我不知道按哪一个键，可以让浏览器说出这样的话？说了， CDN 服务器未必肯听。上一节中也提到过，协议不是数学定理，也不是自然法则，它只是一份契约。就算代理肯听，源站未必答应。因为 CDN 同时还担负着保护源站、抵御 DDoS攻击的责任，不大可能听任请求穿透代理。