干货 | 收藏贴！一文看懂静态资源服务沉浮及其在携程的演进

作者简介

 

蒋小鱼和蒋小猫，携程软件技术专家，主要从事前端基础设施方面的工作。

*温馨提醒：文末有个小福利哦*

上世纪八十年代末，不列颠的伯纳斯-李爵士发明了万维网，距今已有三十年。万维网并非互联网的全部，然而它的出现，为普罗大众开启了新世界的大门。从此之后，互联网的风口轮动不休，静态资源这棵门前的早树却安静如故。许多年过去了，静态资源服务的基础构架没有发生大的改变，改变的只是它所承载的内容和服务的对象。

作为万维网的基石，HTTP 协议的版本号也曾停滞在 1.1 达十八年之久，期间经历了两次迭代。2015年除夕，HTTP/2 终于正式获批。这一协议在继承 HTTP/1.1 绝大部分语义的前提下，改革了传输方式，其效率接近 TCP 协议的能力极限。它将在未来几年内，挑战关于Web 性能优化的许多陈规俗制。然而我们围绕着静态资源基础设施的工作，在那个春天才刚刚起步。几年来所取得的进展很难说尽如人意，谨以此文作一注脚，一起来看“静源深流”。

一、先有“静”，还是先有“动”？

在万维网面世的头几年，网页就是电子化、通过互联网传输的 HTML 页面，除了支持超文本链接，可以天马行空地从一个网页跳转到另一个网页之外，它们和你翻开书本或杂志所见的页面，以及商店橱窗或影院门口张贴的海报，就浏览体验而言，不见得有什么了不起的优势。我的互联网启蒙，居然还是通过一份名为《计算机世界》的纸质报纸完成的——这种报纸价格便宜量又足，一块钱就能买上沉沉的一叠，而且质地良好，很受同学们的欢迎。

那个时代，动态或静态的说法还不怎么流行，大部分以 http:// 为前缀的 URL 是可以作为固定的参考文献地址来引用的。

1996年，李爵士领衔的万维网联盟（W3C）从 IETF 手里赢回了 HTML 标准的主导权。也就是在这一年的12月，微软公司推出一种名为 Active Server Pages 的脚本语言，便是日后大名鼎鼎的ASP 语言。在 PHP 这种“全世界最好的语言”大杀四方之前，ASP 一度是 Web 技术的代名词。

❶打开Notepad，写下一行 <%Response.write "Hello world!" %>，❷把这个文本文件命名为 index.asp，保存在 IIS 的工作目录下，❸然后打开 IE，输入 http://localhost/index.asp，☺「友好的世界」就此呈现。

简单吗？是的，就像把大象放进冰箱一样简单。Notepad、IIS、IE，所有的工具都是现成的，只需要一台安装了 Windows NT 操作系统（即 Windows 操作系统的早期服务器版）的个人电脑，你就可以在一分钟内创建自己的服务端动态网页。与名字晦涩难懂、令人望而生畏的公共网关接口（CGI）相比，不得不说，这太酷了！

脚本语言的介入，使得服务端编程技术迅速走上了平民化的康庄大道。与此同时，浏览器端也在发生着天翻地覆的变化，DOM、JavaScript/JScript、CSS 相继被主流厂商接纳，DHTML 技术初具雏形。之后数年间，动态网页取代静态网页，Browser/Server 架构取代 Client/Server架构，分别成为万维网和网络应用的主流。

动态网页大行其道之后，“静态资源”的概念方才渐渐显露轮廓。所谓动静分离，起初只是 Web 程序员们的一种自发的、朴素的实践。起手建好static 目录，下设 css / imgs / js 子目录，顺带斟酌下 img 和 imgs 哪个更妥，乃是一枚老鸟的自我修养的体现。随着Web 站点或应用的结构日益庞杂，服务端程序和那些仅供浏览器下载、无须在服务端执行或运行的——也就是“静态”的——文件之间显然存在着重大的分歧。即使是泾渭分明的目录，也不足以容纳这种分歧。于是，架构师们开始将这些“静态”文件部署在独立的 Web 容器中，一则可以提升服务性能，二则方便开发和运维，“动静分离”逐渐成为一种被普遍接受的顶层设计模式。

动静分离的模式一直沿用至今，但是它的内涵已经发生了深刻的变化。今天，服务端中间件的性能优劣不再成为瓶颈，客户端（不局限于通用浏览器）的用户体验才是亟需关注的重点。因此，我们也不再纠结于内容在服务端以什么样的形态存在，而是站在客户端的角度，去观察 HTTP 请求和响应的特点，以此作为界定静态资源的依据。

从客户端看 HTTP 请求和响应，静态资源通常拥有这样的侧写：

(1)  其请求指向固定的地址（URL）；
这是“静态”的题中之义，但是，也不尽然。

(2)  其请求经由安全的 HTTP 方法执行；

所谓安全，是指这种请求不会尝试写入或变更服务端所存储的数据，通常仅限于 GET / HEAD / OPTIONS 方法。

(3)  其响应具有特定的内容类型（Content-Type）；
常见的静态内容类型有application/*、image/*、text/*，其中就包括了级联样式表、图片和脚本。

(4)  其响应与上下文无关；

因此静态资源通常部署在 Cookie-Free 的域名下，请求与响应中均不携带任何个性化的 cookie 信息。

然而这些是界定静态资源的必要充分条件吗？并不是！现实往往会超越我们最初的想象，以至于上述看似全面和严谨的描述，也不过是盲人摸象，想当然耳。比如，Polyfill 脚本的内容并不固定，依请求方的浏览器型号而变，显然不合乎“上下文无关”的要求，但在实践中，我们又的的确确是将它作为静态资源来处理的。这并不是仅有的例外。

Polyfill.js 的内容依浏览器型号而定

那么，究竟什么是静态资源？我们认为：凡是固定的内容，如果拥有较长的生命周期、面向较多的用户，即可视为广义的静态资源。这样的内容，必然可以、也应当按照 HTTP 协议的约定，在客户端、代理和反向代理层面将其缓存。

正所谓，一动不如一静。将可以静态化的资源，尽可能实现静态化，对于提升用户访问体验大有裨益。但是，如果没有下节将要讲到的 CDN，这个结论的说服力恐怕就要大打折扣了。

二、不可或缺的 CDN

客户端下载资源所消耗的流量（Traffic）和时间（Time）——我称之为 T2 ——，是衡量静态资源服务优劣的核心指标。几十年来，许许多多的研究人员，孜孜不倦地撰写了许许多多的论文，反反复复地论证以及量化了用户等待时间对于体验质量（QoE）的影响，结论是：越快越好！很好，至少他们的研究成果没有颠覆我们的常识和经验。

1994年，对 IETF 的效率深感失望的李爵士决定另起炉灶。他飞越大西洋，转投有 Georgia Tech of the North 之称的麻省理工学院，并在此创建了 W3C。次年，受到李爵士的启发，应用数学教授Tom Leighton着手研究网络拥塞问题的解决方案。1999年4月，一家名为 Akamai Technologies 的初创公司推出了一种分布式内容传输服务，并自豪地宣布当时如日中天的雅虎为其“特许客户”。Leighton教授正是这家公司的联合创始人。巧合的是，就在一个月后，毕业于佐治亚理工学院的梁建章先生在太平洋彼岸和他的伙伴共同创建了携程，多年之后也成了 Akamai 的客户。对于互联网公司，1999年也许不是一个创业的好时机，能够穿越世纪之交的 .com 泡沫，本身就是其价值的明证。

Leighton 教授领导的团队通过在互联网的“边缘”——也就是靠近终端用户的地方——部署服务器并缓存响应内容，从而减轻内容网站的负荷，同时提升终端用户的访问速度。一举两得！当然了，得花钱。这极有可能是云计算技术成功应用于商业领域的最早的案例。2002年，该公司首席架构师John Dilley 在其撰写的Globally Distributed Content Delivery一文中披露，Akamai 已经在1,000个以上的网络节点中部署了逾12,000台服务器。[1]这在当时是一个非常可观的数字，相比之下，截止到2002年年中，我国联网计算机的总量也不过1,613万台，其中多数还是个人电脑。[2]

由 Akamai 公司首创的这一系统，后来被称为CDN，其全称是内容交付网络（Content Delivery Network）或内容分发网络（Content Distribution Network）。分发是手段，交付是目的，一个宗旨，两种表述。这类系统迅速成为改善网站 QoE 的极为重要的工具，几乎所有不甘于偏安一隅的互联网企业在达到一定用户规模之后，都会认真地思考 CDN 服务哪家强的问题。

虽然 Akamai 系统传输的内容很快就从“Web 对象”——也就是图片和文本——，拓展到了动态内容和流媒体，但是时至今日，静态资源仍然是体现 CDN 优势的最佳标本，而大多数商业化 CDN 也依然因循边缘缓存（Edge Caching）的思路来处理针对静态资源的请求。