Apple 的网络服务在国内一直被人诟病,昨晚十一点左右,在 SYSU 加载一首存放在 iCloud Music Library 的无损音乐,加载了半小时没有加载成功。猜测原因很简单,一方面是 SYSU 晚上的网络质量的确令人堪忧,另一方面是 Apple 的 CDN 策略表现也不尽人意。但是昨晚在解决这个问题的时候,还是迂回曲折,发现不少有趣的事实的。
![](https://i.typlog.com/terry-dev/8423170746_428653.png)
调试网络问题,一般都要祭出神器 Charles。我之前一直是在用 Surge Mac,但后来作者更改了激活策略,只能在一台 Mac 上面使用,我就留给 Steven 的 MacBook 用了,这次我用的是 Charles。
![](https://i.typlog.com/terry-dev/8423170735_429914.png)
可以看到 iTunes 播放音乐的时候请求的域名是 audio.itunes.apple.com
。
![](https://i.typlog.com/terry-dev/8423170720_808573.png)
dlmix.ourdvs.com
是网宿 CDN。
![](https://i.typlog.com/terry-dev/8423170707_31421.png)
ccgslb.net
是蓝汛 CDN。
而 SYSUv6 DNS 对这两个 CDN 都是有特殊优化的,CNAME 到网宿的域名会被解析到长城宽带的 CDN 上,CNAME 到蓝汛的域名会被解析到教育网的 CDN 上,这样就可以规避移动出口拥挤的问题。
至此,我开始猜测是长城宽带和教育网的 CDN 没有对我请求的歌曲进行缓存,而且这两条线路的国际出口带宽都是很小的,导致回源引起的缓慢,我对 audio.itunes.apple.com
这个域名做特殊处理,使用移动线路的 CDN,但结果发现访问速度还是不理想,所以我决定深挖一下原因。
![](https://i.typlog.com/terry-dev/8423170690_517944.png)
![](https://i.typlog.com/terry-dev/8423170673_321367.png)
上面两张图都可以从 HTTP Response Header 中看到 Cache 的情况。
根据已有的资料可以猜测到,Apple 的大部分数据存放在 Amazon S3,也有部分是在香港日本新加坡和美国等地自建的数据中心,而在国内则只有 CDN。对于 App 更新下载,CDN 是十分奏效的,因为往往同一时间的请求都比较集中,Cache Hit 当然是好事。但对于 Apple Music,用户点播什么歌就不这么好猜测了,用户可能很少会下载一个几年前的 App,但几年前的音乐还是会经常听,Cache Miss 的时候加载当然就很慢了,特别是 iCloud Music Library 的音乐,几乎是不会被 CDN 缓存的。
另外一个发现是在香港台湾日本新加坡和美国等地区请求该域名,都是解析到 17.0.0.0/8
,也就是 Apple 的 IP 段,没有使用 CDN。
这一类的域名还有下面这些。
se2.itunes.apple.com
radio.itunes.apple.com
radio-activity.itunes.apple.com
radio-services.itunes.apple.com
audio.itunes.apple.com
aod.itunes.apple.com
streamingaudio.itunes.apple.com
search.itunes.apple.com
api.itunes.apple.com
icloud.com
记起前段时间 GitHub 有一个在中国很火的项目叫做 AppleDNS,原理是通过统计 TCP Handshake 的时间,选择 RTT 最低的 CDN,写入 Hosts 中,如果你理解我上面说的话,就应该知道,这样的做法不一定靠谱。
如果你像我一样,Apple Music 听的音乐比较冷门,还有一大部分是自行上传的无损,而且运营商也不是电信联通这些大运营商,那么 DNS 很可能常常解析到一些偏门的 CDN 去,就很可能会遇到 CDN 回源过慢的问题。这个时候,我的建议是放弃 CDN,利用网络加速工具直连香港台湾日本新加坡甚至美国的数据中心,也许会有更好的体验。我在中国电信网络下尝试,一般 CDN cache miss 的加载速度在 800 KB/s,而使用香港阿里云作为代理,访问香港的数据中心,会有 4 MB/s 的速度。