Why is my CDN 'slow' for mobile clients?
By Ilya Grigorik on March 26, 2014
We're using a CDN but when we look at the performance numbers it appears to be far less effective for mobile clients. We're considering disabling it entirely as we're not sure that it's worth it. Someone needs to build a special CDN for mobile, we'd definitely use that to improve latency!
我们都在使用CDN（Content Delivery Network，即内容分发网络），但当我们查看移动客户端的性能数据时，看上去优化效果远远没有那么明显。我们正在考虑停用针对移动客户端的CDN加速，因为我们不能确定它是否真的有加速效果。如果有人需要构建一个特殊的移动CDN网络时，我们会毫不犹豫地使用它来改善延迟！
The frequency with which I've been hearing this and similar arguments has been rapidly increasing as more teams are finally focusing on improving performance of their mobile sites. The problem is, while the statement is often based on real data (i.e. the relative performance improvements offered by a CDN are smaller for mobile clients), the conclusion is wrong: the absolute improvements are likely the same for all clients and hence worth every penny. Also, we don't need a "mobile CDN", we need carriers to fix their networks.
无线波段，虽然我已经听说过这个词和类似的争论一直在持续增加，因为，越来越多的团队最终着眼于优化他们无线网站的性能。但问题是，数据报表通常是基于真实的数据（即，由CDN针对移动客户端性能优化效果相对不明显），因此得出如下错误的结论：这个相对的改善有可能是所有的客户端都相同，而且，每分钱都物有所值。另外，我们并不需要一个“移动CDN”，我们需要运营商去改善他们的网络。
The many components of latency
To understand why the relative metrics between desktop and mobile CDN performance are misleading many otherwise well-informed teams, it helps to take a step back and consider the actual topology of the internet, plus what CDNs can and cannot do. In fact, for sake of a concrete example, let's assume the following:
要理解为什么桌面和移动CDN之间的性能优化指标能误导许多其他见多识广的团队，它有助于我们进一步思考和考虑到互联网实际的拓扑结构，加上CDN能做什么和不能做什么。事实上，让我们举一个真实的例子，如下所示：
-
Client is located on the west coast; server is located on the east coast.
-
The propagation latency between west and east US coasts is 50 ms.
-
The server response time is 50 ms.
-
Last-mile latency for "tethered" clients: ~18 ms for fiber, ~26 ms for cable, ~44 ms for DSL.
-
Last-mile latency for "wireless" clients: ~50 ms for 4G, ~200 ms for 3G.
-
客户端位于西海岸；服务端位于东海岸。
-
美国东西海岸之间的网络延迟是50ms。
-
服务端的响应延迟是50ms。
-
共享客户端Last-mile延迟为：光纤约18ms，电缆约26ms，数字用户线路约44ms。
-
无线客户端Last-mile延迟为：4G约50ms，3G约200ms。
Last-mile 最后一公里，通信行业经常使用“最后一公里”来指代从通信服务提供商的机房交换机到用户计算机等终端设备之间的连接。
The total time to service the request is a combination of all of the latencies in both directions: last-mile → coast to coast (50 ms) → server response (50 ms) → coast to coast (50 ms) → last-mile. For example, if the client happens to be on a fiber connection with a 18 ms last-mile path, then the total time is 18+50+50+50+18, or 186 milliseconds.
服务请求总时间由两个方向上的延迟组成：客户端→东海岸到西海岸（50ms）→服务端响应（50ms）→东海岸到西海岸（50ms）→客户端。例如，如果客户端通过光纤连接到服务端所花费的Last-mile延迟是18ms，那么它总的时间为：18+50+50+50+18，即186毫秒。
The last-mile latencies we're using above are specific to the US and are courtesy of the Measuring Broadband America report(FCC, 2013). Sadly, FCC has not yet published any similar reports for US mobile carriers. As a result, the ~50 and ~200ms numbers are based on specified and cited targets of existing US carriers.
上面我们所使用的Last-mile延迟数据由美国 Measuring Broadband America report提供（FCC,2013）。遗憾的是，FCC（联邦通信委员会（Federal Communications Commission））到目前为止都没有公布美国移动运营商的任何延迟相关的数据报告。为此我们采用由specified and cited targets提供的现有美国运营商的延迟数据，即50~200ms。
Accelerating content delivery with a CDN
The whole premise of a CDN is to move the bytes as close to the user as possible and to do so CDNs deploy cache servers within various data centers and peering points around the globe. In other words, in the optimal case the CDN servers are located immediately outside the ISP / carrier network: the client makes a request, incurs the cost of last-mile latency to exit the ISP / carrier network and immediately hits a CDN server that returns a response. As a result, CDN minimizes the propagation latency and if a static resource is served, also reduces the server response time by returning a cached asset.
CDN加速的整个前提就是尽可能的将节点部署在离用户最近的地方，并在世界各地对等点的各种数据中心部署CDN高速缓存服务器。换句话说，在最佳情况下，CDN服务器会立即定位客户端所在的ISP/运营商 网络：客户端发起请求，所引发的last-mile延迟时长为：客户端退出ISP/运营商网络和命中时CDN服务器立即返回的响应时间。因此，如果静态资源被缓存CDN能减少服务延迟时长，并且通过返回一个缓存资源减少了服务端响应时间。
译者注：
peering point 对等点，英文说明：A peering point is a place where many networks interconnect to exchange traffic on a peering basis. It allows a network to peer with many other networks but only incur the expense of a connection to a single point. 即，一个对等点就是一个位置，在一个对等基础上交换许多网络互联的流量。它允许一个网络对等许多其它网络，但只产生一个单一节点的连接费用。可以简单理解为：不同网络之间通过对等点（peering points）进行互联，但互联流量只计一个单一节点。点击查看对等点信息
To continue with our earlier example, let's assume that our CDN server is optimally placed (~5 ms path instead of 50 ms coast-to-coast path) and that we are requesting a publicly cacheable asset that can be served by the CDN (~5ms) without hitting the origin. For our fiber client, the new total time is the sum of the last-mile roundtrip plus the CDN response times: 18+5+5+5+18, or 51 ms in total. As a result, adding a CDN took our request time from ~186ms down to ~51ms: a 365% improvement in total latency!
继续前面的例子，让我们假设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%) |
Repeating the same calculation for each connection profile reveals an unfortunate trend: the relative effectiveness of the CDN "declines" as the last-mile latency increases. If you consider the topology of where the CDN servers are typically placed this makes perfect sense: CDN servers are outside the ISP network. That said, note that the absolute latency improvement is still the same regardless of the last-mile profile. > 采用同样的方法重复计算每个连接的基本信息，就可以得到一个不幸的趋势：相对而言CDN有效地“降低”了客户端到服务端的延迟。如果你考虑到拓扑结构，其中CDN服务器的放置地点就显得非常有意义：CDN服务器都放置在ISP网络之外。这就是说，在last-mile方面CDN对延迟的改善仍然是有效的。
CDNs help minimize propagation and server response times. If your only metric is the relative before and after improvement, then it would appear that a CDN is not doing much for mobile clients - e.g. a mere 33% improvement for 3G clients. In reality, the savings are the same, and the real takeaway is that the last-mile latency of most mobile carriers dominates all other latencies of the resource transfer - yes, a rather sad state of affairs.
CDN帮助减少数据传播和服务端响应延迟时间。如果你仅衡量优化前后的对比，就会发现CDN几乎没有做移动客户端的优化：例如，仅仅只有33%的3G客户端有优化效果。事实上，成本是相同的，大多数移动运营商在资源转换其它所有的延迟才能实实在在地减少last-mile延迟。是的，这是一个很糟糕的情况。
Operational and business costs of living at the edge
One obvious strategy to improve the end-to-end latency is to move the cache servers even closer to the client: instead of positioning them outside the ISPs network, could we move them inside? In principle, the answer is yes, and many ISPs already deploy their own cache servers. However, in practice, this is a tricky problem.
一个很明显的策略是：移动缓存服务器到更靠近客户的位置以提高终端到终端的延迟：而不是将节点部署在它们运营商网络之外，我们可以将节点部署在运营商内部？原则上是可以的，现在许多运营商已经部署了自己的缓存服务器，然而，在实践中，我们发现了一个很棘手的问题。
First, the number of peering points is relatively small, which allows CDNs to deploy in dozens of well known locations around the globe to provide their service. Also, to do so, they don't have to do any special deals with individual ISPs: typically, the servers are deployed in shared data centers (peering points). By contrast, moving servers into the ISP network would require individual deals with each ISP - not impossible, but obviously a much harder operational and business problem.
首先，对等点的数量相对比较少（参考relatively small），它允许CDN部署世界各位从所周知的几十个位置以提供服务。然而，要实现这一点，它们没有针对特殊的运营商做任何优惠的政策：通常情况下，服务器部署在共享数据中心（对等点）。相比之下，移动服务器到运营商网络内部需要与每个运营商单独结算 --- 并非不可能，但这显然是一个很难的运营和业务问题。
For the sake of argument, let's say a CDN does strike a deal with an ISP. Now the CDN needs to deploy many more servers, and ideally as close to their customers as possible (near the radio towers and other aggregation points). Doing so would require a lot of hardware, makes maintenance and upgrades an operations nightmare, and opens a lot of security questions - e.g. would you deploy a TLS termination node within a third-party operated network that you don't have direct access to? In short, it's a cost, security, and a logistics nightmare.
为了便于讨论，我们假设CDN已经和一个ISP达成协议。现在，CDN需要部署更多服务器，理想情况下尽可能靠近他们的客户端（在无线电天线塔和其它信号聚合点）。否则，将需要大量硬件设备，这将导致维护和升级成为运维的恶梦，并打开了一个安全问题。例如，你将要部署一个第三方的TLS终端节点来操作网络，解决你不能直接访问网络的问题。总之，这是一个成本、安全和物流的恶梦。
That's not to say this can't be done. Many ISPs have long been trying to move "upmarket" and provide CDN functionality. However, ISPs have a different problem: it's very hard for them to sign clients because most sites are not interested in signing individual deals with every ISP on the planet. In recent news, Verizon acquired EdgeCast... It remains to be seen what they do with it and if this will actually benefit Verizon clients.
这并不是说不能这么做。许多互联网运营商长期以来一直在尝试提升“档次”并提供CDN服务。然而，运营商也存在不同的问题：他们很难签订客户，因此大多数网站对于这个星球上的每个运营商签署单独的协议不感兴趣。在最近的新闻中，Verizon收购EdgeCastVerizon acquired EdgeCast。这还有待观察Verizon用EdgeCast来做什么，如果是将其应用于生产环境，这将有利于Verizon的客户。
Business and operational costs aside, there is nothing particularly special about optimizing CDNs for mobile clients. The root problem is that the last-mile latency of mobile carriers is atrocious - that's what we need to fix. Instead of pushing cache servers closer to the edge, we need transparency into performance of these networks, and we need more competition between carriers to address the underlying last-mile performance problems.
除了业务和运营成本之外，CDN在移动客户端上没有任何特殊的优化。问题的根源在于：移动运营商的last-mile延迟是很糟糕的 – 这才是我们需要解决的。而不是推动将缓存服务器部署在靠近用户的边缘，我们需要公开地进行网络的优化，我们需要更多的运营商之间竞争，从根本上解决last-mile性能问题。
CDNs are not slow for mobile, use them
In short, there is no reason why CDNs are inherently 'slower' for mobile clients: don't confuse relative gains with absolute savings. That said, the actual performance will obviously vary for each CDN provider based on location of their servers and connectivity with various mobile carriers - measure, gather real data, optimize.
总之，没有任何理由相信，CDN加速本质上能使移动客户端变“快”：不要混淆相对收益和绝对成本。这就是说，通过每个CDN提供的服务器的基本位置和连接到各种移动客运营商的：测量、收集实时数据、优化，实际性能也会有明显的变化。
Ilya Grigorik is a web performance engineer and developer advocate at Google, where his focus is on making the web fast and driving adoption of performance best practices at Google and beyond.
Ilya Grigorik 是Google web性能优化工程师和开发大使（开发员维权者），他的工作重点是采用性能最佳实践驱动Google在将来web上访问更快。High-Performance Browser Networking作者。
