如果中国开发者要从 Apple 官方下载 Xcode ,那么整个下载过程的体验快慢主要取决于 Apple 的以下三个 web property 在中国的性能:
Mac App Store 和 iOS App Store 的所有的动态页面。如果有的时候 Mac App Store 显示无法连接,或是 iOS App Store 里出现白屏或者 Nginx 错误(比如 504 Gateway Timeout ),就是因为这个域名的服务不稳定导致的。
除了可以从 Mac App Store 下载,开发者也可以直接从 Apple 的开发者网站 developer.apple.com 下载。如果从 Apple 的开发者网站下载的话,那么这些文件是放在 adcdownload.apple.com 这个域名下。
稳定版本的 Xcode 目前 Apple 推荐的做法是从 Mac App Store 下载,而 Mac App Store 的文件则存放在从 a1-a1999.phobos.apple.com 这 1999 个域名上。
这是我们在 PST 时间 2015.9.22 15:00 到 2015.9.24 9:00 之间对以上 3 个域名在中国的性能做的一些调查。
这个域名下的流量几乎全是动态网页,并且在 CDN 上设置了非常短的 TTL —— 60 秒。这个域名的性能对于用户在访问 App Store 时的体验有着最主要的影响,因为如果页面都没法打开的话,用户就根本没有机会去按下载按钮了。
我们使用了 3 种方式测试 itunes.apple.com 在中国的服务质量:
目前 Catchpoint 在中国有两个 Last Mile 监控点:
分别位于北京联通和上海电信,虽然覆盖十分有限,但是覆盖了中国主要的两个运营商,所以数据具有一定代表意义。
我们在 Catchpoint 设置了针对以下 URL 的在中国的两个 Last Mile 监控点的 single object 测试:
https://itunes.apple.com/cn/app/xcode/id497799835?mt=12
作为对比,同时也选择了两个分别位于美国西部和东部的 Last Mile 节点:
这是从 PST 时间 9-23 9:00 到 9:24 9:00 的 24 小时内的 Catchpoint 测试结果:
http://p.catchpoint.com/ui/Entry/PC/V/AROE-C-D-SIJE7jSw6nsqEAA
中国的结果:
Test Node | Avg Webpage Response | Avg DNS | Avg Connect | Avg Wait | Avg Load |
---|---|---|---|---|---|
LM - Beijing CN - Unicom | 1995 | 13 | 227 | 1284 | 9 |
LM - Shanghai CN - Telecom | 5131 | 7 | 376 | 4466 | 6 |
美国的结果:
Test Node | Avg Webpage Response | Avg DNS | Avg Connect | Avg Wait | Avg Load |
---|---|---|---|---|---|
LM - Los Angeles, CA - VZN FIOS | 505 | 29 | 14 | 341 | 5 |
LM - New York, NY - VZN FIOS | 395 | 18 | 12 | 278 | 7 |
这是完成 Xcode 下载页面的第一个请求所需要的时间。可以看到,上海电信的结果尤其糟糕,不仅比美国慢了十多倍,而且从中国时间的下午开始,服务就变得断断续续不可用(图中的红点)。
在这样的情况下,用户根本就没法打开 Mac App Store 上 Xcode 的下载页面,也就根本没有机会去点击下载按钮了。
我们在中国的一个技术社区 V2EX 发帖(征集帖子地址 https://ex.noerr.eu.org/t/222978 )向大家征集使用家里或者公司的网络访问下面 Xcode 在 iTunes 上的完整页面请求日志( HAR 格式):
https://itunes.apple.com/cn/app/xcode/id497799835?mt=12
截至 PST 时间 2015.9.23 20:00 一共收到 69 个有效样本。这些样本覆盖到了中国所有的主要宽带运营商(电信,联通,移动,教育网),这是我们对这些样本进行的一个初步分析:
Carrier | Samples | Fastest (ms) | Slowest (ms) | Average (ms) |
---|---|---|---|---|
All | 73 | 3 | 17175 | 2413 |
Telecom | 32 | 10 | 17175 | 2651 |
GWB | 1 | 388 | 388 | 388 |
Mobile | 4 | 633 | 4013 | 1506 |
BGP | 2 | 664 | 1448 | 1056 |
CERNET | 6 | 30 | 10099 | 2723 |
Unicom | 26 | 3 | 13816 | 2358 |
DrPeng | 2 | 1531 | 3600 | 2565 |
17ce.com 是一个在中国很流行的测试工具,可以使用超过 60 个位于国内各地的节点对同一个 URL 的下载时间进行实时测试。但是这些节点基本上都是位于数据中心的 Backbone 节点,所以测试结果的数据会比来自真实用户的 Last Mile 数据要更好一些。
测试 URL :
http://itunes.apple.com/cn/app/xcode/id497799835?mt=12
以下是在不同的中国时间进行的测试及结果:
9-24 7:28 - 平均时间 1.15 秒
http://www.17ce.com/site/http/201509_b82f1a360b4710185b0e3eeaa76b4f13.html
9-24 8:55 - 平均时间 4.59 秒
http://www.17ce.com/site/http/201509_a2245c39ffbf89f91cc853040638086c.html
9-24 19:54 - 平均时间 1.669 秒
http://www.17ce.com/site/http/201509_eac6061e0d7dd440318f24d35e86d766.html
9-24 20:41 - 平均时间 2.143 秒
http://www.17ce.com/site/http/201509_76d87600bc8b801fdd7713d7c7b6fa41.html
9-24 21:27 - 平均时间 2.808 秒
http://www.17ce.com/site/http/201509_2bbff8d9db2d654ee2301a5769068896.html
9-24 22:31 - 平均时间 2.818 秒
http://www.17ce.com/site/http/201509_dc82a27462b1134b242e397645853b82.html
由于 adcdownload.apple.com 的下载链接使用了基于 Cookie 的保护机制,所以我们没有对这个 web property 的下载速度进行自动测试。而只是在 Catchpoint 上进行了针对网络的 TCP PING 测试,这里是从 PST 时间 9-23 9:00 到 9:24 9:00 的 24 小时内的测试结果:
http://p.catchpoint.com/ui/Entry/PC/V/AROE-C-D-SIJE9jSw6nsqEAA
我们注意到在大概中国时间 9-24 中午, PST 时间 9-23 晚上 9 点, adcdownload.apple.com 完成了一次 DNS 切换,已经开始使用中国本地 CDN 。而在这个切换完成之前,由于 adcdownload.apple.com 是通过 Akamai 的亚洲甚至美国节点提供服务,性能和可用性都是有问题的。
App Store 的动态页面,是否有必要一定要使用短至 60 秒的 Caching TTL ?因为这个页面实际上有 3 个不同的版本(分别针对不同的设备及浏览器),每个版本对应的是一个单独的 Cache Key 。由于 TTL 过短,并且大部分 CDN 节点并没有使用共享存储,就会造成这个页面实际上 Hit Rate 不高,于是需要频繁回源。当遇到国际链路不好,回源时间过长甚至超时,用户就没法打开 App Store 的页面。
如果将 itunes.apple.com 的 Caching TTL 调到 3600 秒,那么这个域名在中国的体验应该会好很多。当然,同时也需要 CDN 供应商对回源链路进行优化,如果位于中国大陆的边缘服务器直接回源美国的话,失败几率还是会非常高的。
对于像 Xcode 和 OS X El Capitan 这样容量有数 G 的大型软件,如果能够像很多网络游戏那样使用基于 P2P 的下载器,那么用户将可以更快更可靠地完成下载,同时也可以降低 Apple 对于 CDN 的依赖。
很多中国的开发者之前之所以要使用迅雷和网盘来下载 Xcode ,也主要是因为这类基于 P2P 的下载工具可以在复杂的网络情况下更快地完成下载。