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


从客户端看 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 服务哪家强的问题 。


推荐阅读