实际没那么复杂。大公司开发工具都是 IT 提供放到内网共享里，像 xcode 这种一更新就是 3 个 GB ，很多企业网络禁止大家一起更新，否则带宽直接占满。微软推出 WSUS 也是出于这个考虑。。。。

IT 去哪里找下载？都是 baidu/迅雷走起。。。。。。。。。。。。。

@iF2007 看一篇老文章作为参考：

http://blog.binux.me/2012/03/hash_algorithm_of_xunlei/

> cid 主要用于文件的索引。观察代码可知， cid 并没有 hash 整个文件，而是根据文件的头 /中 /尾部的 0x5000 字节的内容计算 Hash 。这样就可以在不下载完整个文件，就能够查询到其他服务器上可能的相同文件。于是在下载支持 range 的文件的时候，即使该地址没有被索引到，但是通过 cid ，依旧可以被 p2sp 加速。

@aisk 黑盒。目前没确切证据表明迅雷会校验。但是倒是 /t/222018 这个帖子有案例说明下载出来文件对应不上。

再更新一个例子：

http://a.com/1.rar 有 100G ，通过迅雷下载，下载前一瞬间，其实 1.rar 内容已经变了，大小不变。这个时候我记得迅雷依然会通过 p2p 加速下载老版本的。

啊哈哈哈。。。不要说 chrome 了。。。。 android sdk 有几个是从正规途径下载的？

就算翻墙工具，其实就是自己主动使用的“中间人” 而已。

为毛不学习 ruby 的 ||= 。还可以一句话写 cache 。

@wuhx 客户端可以 pin 死证书的。中间人不一定有效。客户端静态连接 SSL ，很难分析出来。

@lawder 对。今天发现了。

@fallwithme 理论可行，实际操作很难。比如 p2p 类。

原来 CNCERT 是腾讯报的。。。

@loading 抓包很容易阻挡的。。。。

@breeswish 是的。

@livepps 电池不可拆。

@breeswish CDN 和 GateKeeper 暂不说，您倒是说说假如您是苹果，如何发现并审核这种“恶意”行为？据我所知所有第三方广告 SDK 都有统计基本信息的行为。

T00ls.net 老大人肉的，多半不会错。

SegmentFault 。。。哈哈哈。

同花顺爱基金

OPlayer 2.1.05 这个够狠！老子还捐钱买了 IAP ！

@tinyproxy 毛的苹果的责任。这恶意 lib 的行为和第三方广告商 SDK 没有本质的区别，都是向第三方服务器发送统计数据。苹果能怎么办？

苹果做多只能事后批量下架这些 app 要求整改。

还有这个 并读新闻·读赚天下- 会赚钱的新闻客户端 bingodu

名片全能王 这个也中了真是意外。

@bitinn That's exactly what I thought. What triggered the sudden change of XCode for this version 6.2.6 inside Tencent?

Also CNCERT knows this issue way earlier than everyone else http://www.cert.org.cn/publish/main/12/2015/20150914152821158428128/20150914152821158428128_.html