@jeremaihloo 这不是项目上的代码，只是我单纯拿来玩的，所以用哪个都无所谓，但出现了这个现象，然后想知道问题出在哪

@Explorare 你说的是 EC2 的 G2 型号？神壕求大腿~~~~
（刚刚看了一下，按需 G2 实例每月 487.5 刀，日本线 673.5 刀...）

卷积神经网刚刚查到了，不明觉厉

@Explorare AWS G2 是什么鬼， CNN 又是什么鬼， Cable News Network ？
难道不是 EC2 么

@Droog 就是说这个东西已经没有了

@Explorare 不如直接上 AWS ，目前 ss 稳定

@bbx 我没碰过算法，自己挖的坑太多，已经填不完了，不想再多挖一个大坑了

@hitmanx 吐个槽而已啊，要不要这么认真啊-_-||

@cnnblike httpclient 已经被干掉。源码没问题，抓包没问题， debug 看就缺了响应状态码

@KoleHank 那个地址国内国外都试过，百度网易也试过，就是得不到正确结果

@bbx 你说的算法我一个也没听说过。。。。
反正上面那 5 题随便哪题都能把我虐成狗
学的越深入越发现自己什么都不知道
太深入的东西最好是用到时才去学它，平时只需要遇到问题多思考，养成良好的习惯就行，毕竟人经历有限，老板也不会要求你必须掌握工作需要的所有知识技能，要的是你能在限定时间内解决问题

5 道题，每题深挖都能出一套书（是一套不是一本←_←）
题 1 ：涉及 tcp/ip 、前端、后端开发
题 2 ：涉及 tcp/ip
题 3 ：主要涉及 ssl ，进一步又关系到 web 服务器与数据安全领域
题 4 ：粗浅来看是地址空间，深挖下去涉及到 CPU 架构、内存管理
题 5 ：这个主要涉及竞争冒险以及内存安全，往深处挖那就是操作系统原理了，是的你没看错就是操作系统，操作系统绝大部分代码都是为了在内核层解决这两个问题

@acess 你需要在本机下载的同时离线下载那个地址，若这个文件早就被保存在迅雷服务器上，链接和文件的对应关系才会被保存，而你服务器上的文件只是被迅雷当成那个文件的节点，而不是那个链接的节点。
若这个文件没被迅雷收录过，则需要用真实地址完整的离线下载一次这个文件

http://www.microsoft.com/en-us/download/details.aspx?id=30679
64 位注意选 VSU_4\vcredist_x64.exe

那个装的是 update ，不是安装包，当然装不上
而你手动安装的 VC++2012 是 x86 也就是 32 位的

都稳定，延迟的话日本的节点好一点
ip 查出是美国这种事我倒是没碰到过
另外就是，如果你的服务器搭了比较大众的梯子，比较容易被查到然后被干扰

怕变卦那就和对方先签个劳动合同呗

(?<=^key:).*(?=As$)

@onerebos
创业不辞职真的没问题么←_←
公司坐标？
工作内容？
可远程？
好吧其实我只想赚点外快←_←

@choury 其实不必盯着有效链接，死链部分就已经够迅雷喝一壶了
1.如何判断现在这个死链对应的文件是原始文件
2.如何确定这个链接是否恢复

现在的迅雷对问 1 的回答是在这个链接上最近被成功下载的文件，对问 2 的回答是没有死链，只是暂时无法访问
漏洞显而易见，这个主题就很好的打了迅雷的脸
虽然迅雷本身黑点挺多的，不过拿 XCodeGhost 事件来黑迅雷，仔细分析就能发现这只是一个笑话

@choury
你说的伪造前中后 5k 数据欺骗服务器在我看来并不十分实际，首先若你成功伪造了这个安装包，你上传到自身服务器让迅雷下载时迅雷依据这段相同的 hash 判断你的文件已经保存在服务器上，实际上你的带毒安装包并未真正被离线服务器保存
其次有可能的情况是文件刚推出时趁着迅雷服务器未完全保存此文件，抢先一步将数据包下载下来、修改、伪装、伪造地址让迅雷保存你的这个安装包，如此才能让迅雷服务器把李鬼当成李逵，但是做一系列工作期间一旦被任何一个正常用户使用离线功能下载正常文件，那么一切努力就白费了，甚至即便抢先成功，有用户只使用原始地址下载而服务器校验了这个文件的完整 hash 与服务器上保存的做比对，那么一切努力也要白费