为什么 CDN 对移动客户端加速“没有”效果

  • 刘宇

2014 年 7 月 30 日

话题:CDNDevOps

Google web 性能优化工程师和开发大使、《High-Performance Browser Networking》作者Ilya Grigorik近日发布了一篇名为《为什么 CDN 对移动客户端加速“没有”效果》的博客,描述了移动(无线)网络的特殊性,以及如何建设一个适用于移动 CDN 的构想。

Ilya 首先吐槽了目前的 CDN 在移动客户端加速方面的不给力。从他们的移动客户端性能监控数据来看,传统 CDN 的优化效果非常不明显,所以他希望有一个对移动网络支持更好的、特殊的移动 CDN 网络。

对于传统 CDN 在无线网络上的效果,Ilya 认为人们普遍有两种误解:1、传统 CDN 对移动客户端和对宽带网络的绝对优化效果差不多;2、这不是要不要“无线 CDN”的问题,而是运营商网络的问题。

Ilya 首先提供了一个参考数据,用于分析无线网络延迟的主要组成部分:

  • 客户端位于西海岸;服务端位于东海岸。
  • 美国东西海岸之间的网络延迟是 50ms。
  • 服务端的响应延迟是 50ms。
  • 共享客户端 Last-mile 延迟为:光纤约 18ms,电缆约 26ms,DSL 约 44ms。
  • 无线客户端 Last-mile 延迟为:4G 约 50ms,3G 约 200ms。

注: Last-mile 最后一公里,通信行业经常使用“最后一公里”来指代从通信服务提供商的机房交换机到用户计算机等终端设备之间的连接。

下图显示使用 CDN 时用户访问流程和延迟信息

使用一个 CDN 做内容分发加速

CDN 加速需要在世界各地对等点的各种数据中心部署 CDN 高速缓存服务器,并尽可能的将数据部署在离用户最近的地方。换句话说,在最理想的情况下,CDN 服务器会立即定位客户端所在的 ISP/ 运营商网络,客户端发起请求,所引发的 last-mile 延迟时长为:客户端断开 ISP/ 运营商网络和命中时 CDN 服务器立即返回的响应时间。因此:

  1. CDN 减少了 propagation latency;
  2. 在缓存了静态资源的情况下,CDN 还减少了 server response time;

继续前面的例子,假设 CDN 服务器进行了网络优化配置(东海岸到西海岸的延迟时间不是 50ms 而是 5ms)和我们请求 CDN 未命中源站的情况下客户端到 CDN 节点的延迟是 5ms。对于采用光纤的客户端,新的总时间为 last-mile 往返加 CDN 响应时间的总和:18+5+5+5+18,即 51ms。因此,增加 CDN 的好处就是将我们总的请求时间由 186ms 降低到了 51ms:在总延迟上有 365% 的改善。

我们可以来看下不使用 CDN 和使用 CDN 加速时相关的性能数据,如下表所示:

  Last-mile Coast-to-Coast (low) Server Response Total (ms) Improvement
Fiber 18 50 50 186
Cable 26 50 50 202
DSL 44 50 50 238
4G 50 50 50 250
3G 200 50 50 550
CDN + Fiber 18 5 5 51 -135 ms (365%)
CDN + Cable 26 5 5 67 -135 ms (301%)
CDN + DSL 44 5 5 103 -135 ms (231%)
CDN + 4G 50 5 5 115 -135 ms (217%)
CDN + 3G 200 5 5 415 -135 ms (133%)

采用同样的方法重复计算每个连接的基本信息,就可以得到一个不幸的趋势:

  1. last-mile 的延迟最高,CDN 的相对有效性越差
  2. 考虑到 CDN 服务器一般都放置在 ISP 网络之外,这就意味着节点的选择非常有意义
  3. CDN 对于改善 last-mile 的延迟还是有一定效果的

CDN 帮助减少数据传播和服务端响应延迟时间。如果你衡量优化前后的对比,就会发现 CDN 几乎没有做移动客户端的优化:例如,3G 用户普遍获得 33% 的优化效果。

在边缘节点上的运营和业务维护成本

一个很明显的策略是:移动缓存服务器到更靠近客户的位置以提高终端到终端的延迟,而不是将节点部署在运营商网络之外。那么,我们是否可以将节点部署在运营商内部?原则上是可以的,现在许多运营商已经部署了自己的缓存服务器。然而在现实中,存在如下问题:

  1. 对等点的数量相对比较少,CDN 只能部署在世界各地众所周知的几十个位置。然而,移动服务器到运营商网络内部需要与每个运营商单独结算,所以,通常情况下,服务器部署在共享数据中心(对等点)。
  2. 我们假设 CDN 已经和某个 ISP 达成某种协议,理想情况下尽可能将服务器部署靠近他们的客户(在无线电天线塔和其它信号聚合点)的位置。这样做将需要大量硬件设备,这将导致维护和升级成为运维的恶梦,并打开了一个安全问题。例如,你将要部署一个第三方的 TLS 终端节点来操作网络,解决你不能直接访问网络的问题。总之,这是一个成本、安全和物流的恶梦。
  3. 许多互联网运营商长期以来一直在尝试提升“档次”并提供 CDN 服务。然而,运营商也存在不同的问题:很难签订客户,因为大多数网站对于和每个运营商单独签署协议丝毫不感兴趣。

最近的新闻报道说Verizon 收购了 EdgeCast,如果能将其应用于生产环境,这将有利于 Verizon 的客户解决这个问题。

除了业务和运营成本之外,CDN 在移动客户端上没有任何特殊的优化。问题的根源在于:移动运营商的 last-mile 延迟是很糟糕的。这才是我们需要解决的问题,而不是推动将缓存服务器部署在靠近用户的边缘。我们需要公开地进行网络的优化,我们需要更多的运营商参与竞争,从根本上解决 last-mile 性能问题。

在国内,运营商环境更为复杂,大大小小运营商有很多家,其中以北方网通、南方电信、移动为主。但伴随着互联网的发展,小型运营商通过控制入口并以 2、3 级城市为主逐渐扩大了规模,例如:电信通、华数科技、长城宽带等。还包括一些城域网,这些我们通常统称为小运营商。

由于各运营商之间存在着网间费用结算,因此运营商会想尽一切办法将内容存在自己的网内,这就造就了现在市场上比较混乱的"劫持",而劫持技术也是越发越"高科技"。

国内的 CDN 环境竞争也日益加剧,几大 CDN 厂家如网宿科技、蓝讯、快网、帝联也纷纷与运营商进行合作。例如:蓝汛与中国电信宣布共建 CDN 网络,而网宿科技则是发布 MAA 移动应用加速解决方案,正式宣布进军移动互联网市场。再加上大公司自建 CDN 的加入,并有公司将 CDN 与云服务进行整合加入竞争,使得市场愈发激烈。

环境的复杂,导致用户访问的问题更加难以解决。有些观点表示,只有等到互联网关于运营商的改革,这些局面才会得以改善,但我认为只要各大运营商与公司紧密合作,合作更加深入,用户的访问质量肯定会节节攀升。

延伸阅读: 一秒钟法则:来自腾讯无线研发的经验分享

感谢丁雪丰对本文的审校。

CDNDevOps