Apple 的网络服务在国内一直被人诟病，昨晚十一点左右，在 SYSU 加载一首存放在 iCloud Music Library 的无损音乐，加载了半小时没有加载成功。猜测原因很简单，一方面是 SYSU 晚上的网络质量的确令人堪忧，另一方面是 Apple 的 CDN 策略表现也不尽人意。但是昨晚在解决这个问题的时候，还是迂回曲折，发现不少有趣的事实的。
调试网络问题，一般都要祭出神器 Charles。我之前一直是在用 Surge Mac，但后来作者更改了激活策略，只能在一台 Mac 上面使用，我就留给 Steven 的 MacBook 用了，这次我用的是 Charles。
可以看到 iTunes 播放音乐的时候请求的域名是 audio.itunes.apple.com。
dlmix.ourdvs.com 是网宿 CDN。
ccgslb.net 是蓝汛 CDN。
而 SYSUv6 DNS 对这两个 CDN 都是有特殊优化的，CNAME 到网宿的域名会被解析到长城宽带的 CDN 上，CNAME 到蓝汛的域名会被解析到教育网的 CDN 上，这样就可以规避移动出口拥挤的问题。
至此，我开始猜测是长城宽带和教育网的 CDN 没有对我请求的歌曲进行缓存，而且这两条线路的国际出口带宽都是很小的，导致回源引起的缓慢，我对 audio.itunes.apple.com 这个域名做特殊处理，使用移动线路的 CDN，但结果发现访问速度还是不理想，所以我决定深挖一下原因。
上面两张图都可以从 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 的速度。
