从苹果的 Xcode 事件来多了解一点 迅雷下载 的真相

最近的 苹果Xcode 开发工具被感染 XcodeGhost 病毒事件闹得沸沸扬扬，让我等平民百姓也来了兴趣。

事情的经过是这样的：由于一些众所周知的原因，苹果官方站点的 Xcode开发工具 无法正常下载。于是国内某人士就镜像了一份Xcode，并公开了其下载地址，让公众（包括小众和大众）下载。

这看似是一个善举，但是，作者所提供的下载 *不是* 一份干净的、原始的镜像，而是作者修改过的版本（见github上面的说明）。此修改导致的直接后果就是：使用此Xcode编译的苹果app应用都有一段后门程序，该后台程序会直接接收相关的指令并执行（包括但并不限于作者本人所陈述的仅仅是收集app信息（据互联网））。其导致的严重后果可想而知。然而该修改版本的Xcode的使用者竟然覆盖面相当广，包括但不限于腾讯公司（微信）、网易、一些银行机构。并且，使用此Xcode编译出来的app竟被正常地放到苹果的AppStore供大家下载（现已被下架），其受害者不计其数。然而这更让人意想不到的是，此后门程序居然跑了足足有半年之久才被发现。这一度让人们置疑苹果公司的安全审核机制到底出了什么问题。

好了，我不是自媒体，更多相关的信息请搜索。而我今天本来要说的重点是关于迅雷下载的。迅雷下载在带来高速下载的同时其内部的p2p共享机制出了什么问题。

先打开苹果官方的Xcode下载页面(http://adcdownload.apple.com/Developer_Tools/Xcode_6.4/Xcode_6.4.dmg)看看吧：

可以知道的是，这个下载链接已经失效了。我有意把网络请求过程展示了出来，如果你懂这方面（HTTP协议）的话，应该了解该页面的请求是这样的一个过程：

1. 浏览器请求下载文件 http://adcdownload.apple.com/Developer_Tools/Xcode_6.4/Xcode_6.4.dmg，服务器返回 302临时重定向 到页面 http://adcdownload.apple.com/unauthorized/；
2. 浏览器请求上述 302 后的页面，服务器返回 301永久重定向 到 HTTPS 安全页面 https://adcdownload.apple.com/unauthorized/；
3. 浏览器请求上述 301 后的安全页面，服务器返回了 成功（200），并附带了正文内容。

从技术层面来说，虽然中间经过了多次重定向（包括301和302），但最终由于服务器返回的是代表成功的200，并不是标题和正文内容所标识的“未授权”（HTTP代码401）、此文件已不存在（HTTP代码404）、禁止访问（HTTP代码403）。所以这也就意味着：当前所显示的页面正文就是你所请求的文件 http://adcdownload.apple.com/Developer_Tools/Xcode_6.4/Xcode_6.4.dmg 的内容。简单来说就是：/Developer_Tools/Xcode_6.4/Xcode_6.4.dmg 文件的内容就是此页面正文，该 .dmg 文件是一个类型为 text/html 的网页文件。该页面是动态生成的，请求所生成的类型（MIME）由 HTTP头部的 Content-Type 决定，跟所请求的资源的后缀（.dmg）无关。（静态资源多数由后缀确定类型）。

但是，迅雷却未按照HTTP协议的规定正常返回文件（也许是因为其内部的某种共享机制、死链解决机制），下载正常进行，有图有真相：

下载完全正常地进行，没有任何信息显示源（原）文件已经不存在。点击下载项右边的箭头来看看详情页面的任务分块信息：

注意到我加下划线的部分：原始地址来源： 0% 0.00B，这也就说明：当前的下载完全不是来自原始站点（苹果官方），而是来自：镜像加速、P2P加速、离线下载加速。

因此，正如前面所说：如果不是从任务分块信息去仔细发现问题，迅雷不会直接以任何形式的通知告知用户：当前所下载文件的链接已是死链，文件内容完全来自非官方。

迅雷解决死链的机制给大家带来了好处。但是其对用户过度透明却犯了严重错误。下载软件最起码的要求应该有一条是：我请求什么，你就应该给我什么，不论你以何种方式的加速。保证请求的正确是前提，加速是你额外理应提供的。