[讨论] 迅雷的真正秘密

迅雷下载其实就是一种“强盗行为”！为什么呢？迅雷不公布源代码，官方提供的说明也是忽略他真正的工作原理，偶系菜菜，我就告诉大家我所知道的迅雷（包括收集的），从工作原理说起，不想弄的太专业哈，尽可能简单点。

1.盗链
你发现没有有些用快车、DUDU等下载不了的资源，迅雷可以下载，最明显的是：在收集下载地址时，网际快车不会收集在下载地址里包涵了用户名和密码的下载地址，快车知道下载地址里有用户名和密码,就是不想让所有人都使用.但迅雷的可不理你,一样收集,然后供其它人使用。说白了,就是"盗链"！
例:包涵用户名的下载地:ftp://Thund:Issue@202.154.123.218/0718/世界大战.rmvb
这个下载地址里的Thund:Issue就是用户名和密码了（这里借用了一个百度知道的链接）
可是这个链接快车下载不了，迅雷为什么能下载呢？因为快车在读到需要帐号、密码时就停止了（很厚道），报错不能下载;而迅雷是只要有一个用户成功的下载了该资源，其所有的下载休息都被记录了（不包括下载的文件），你再去下载不光可以下载，而且发现不只有一个资源，迅雷他还把其他用户下载的资源拿来共享了!
2.p2sp技术，p2p的升级：
“ P2P的下载概念，简单点说，就是下载不再像传统方式那样只能依赖服务器，内容的传递可以在网络上的各个终端机器中进行。P2SP除了包含P2P以外，P2SP的“S”是指服务器。P2SP有效地把原本孤立的服务器和其镜像资源以及P2P资源整合到了一起。也就是说，在下载的稳定性和下载的速度上，都比传统的P2P或P2S有了非常大的提高。P2SP实际就是高效的P2S加上有限的P2P！
发现这个问题很偶然，就是前几天用它下载时正好也开着iris，就看到了一些如E:\电影\xj\01.rmvb之类的信息，然后，再找找，就看到了61.140.38.xx00508D5Exxxx0000，相信很多人一眼就可以看出来这是ip地址及MAC地址（xx是我隐藏的），这样的地址有很多，我想大概就是迅雷提示里的多少多少资源吧。
当然，光看到这些可能问题仍不是很大，毕竟知道一个ip也不是人人都可以入侵的，可是...今天，我在后面又找到了ftp://down09D88BE387DA6DF27D107C ... xx@www.tn51.com/lx/仙剑奇侠传/01.rm....没什么吗？如果是收费的呢？如果我告诉你http的也有呢？
顺便说一下，迅雷启动时会把你电脑上的操作系统版本，ip地址，mac地址，桌面分辨率，国家,,,传到服务器上，具体什么用，我也不知道了。 ”以上为引用，我认为有不对的地方！给大家参考。
我还有一个疑问，如果是下载的加密的.rar压缩文件文件怎么也会有很多资源呢？当然最简单的理解是有很多人下载过，那么我们来举个例子：
我要在A站下载一个2007QQ.RAR的文件（假设是珊瑚虫版的，很好），假设这个文件是A站下载后重新做的优化版（全球独家！），还故弄玄虚加了密，里面必然有他们的广告，其他站不可能照搬，有的话也是盗链。这时，问题就出来了，迅雷下载时引用了很多站的资源（再假设是盗链A站的），那么用户在下载时难道几十个资源又通通回到了A站吗？这样速度还能高吗？
这里就不得不提到一个迅雷的功能“资源发布”，就是在迅雷里所谓级别较高的用户，可以将自己下载的东西发布到“雷区”供大家下载。因此，网上流传的说法中有：迅雷会在后台开两个进程Thunder.exe和Issue.exe，开机连上互联网就“悄悄”上传你下载的文件，使你的网速变慢等，我不这样看，要是这样早就被用户发觉了就没有人用了，这两个进程的真正用途是用于用户资源发布的！好一招瞒天过海！

如果说迅雷有盗链行为，那些发布资源的才是最大的帮凶！

说白了迅雷就是一个资源集合库，凡是你用迅雷下载了资源，迅雷的专门服务器都会记录下载信息，有人用迅雷下载时，迅雷在同时干三个工作：1）按你的意愿去链接文件并进行下载；2）搜索迅雷服务器，看有没有相同的资源，一旦发现就加入到你的下载；3）在1+2无法获得良好的速度时，作为补充，适当从其他客户端进行加速。迅雷不是简单的像快车那样将下载文件分割同时下载，而是从不同的地方下载同一个资源。而且它会一边下载，一边搜索可用的其它同名（效验值相同）下载资源。

所以迅雷他现在暂时还吃不了版权官司，为什么呢？大家可以做一个实验：将你的网速限制在3KB（太快了，你什么也看不到！），在调试程序里打开迅雷，让迅雷在调试程序的监视下工作（偶发现脱壳调试软件最好用，毕竟术业有专攻嘛），再在迅雷里导入一个下载链接，你就会发现迅雷惊人的秘密！！！他的确有盗链的嫌疑，但不是盗链全部！！！也许只是盗链了你1%的数据，这还叫侵权吗？其他的又从其他地方获取了！！！这样就不可避免的有一个弊端，万一有心怀不轨者在热门资源里放毒，然后将他发布出去，后果不堪设想！（不过这样做有相当大的难度一旦改变效验值就完了）

说了这么多，迅雷能下载死链接，而其他的下载软件不行，就很好理解了，原始资源失效了，可总有人下载过吧，假设有1500人下载，总有那么几个人抱着：人人为我、我为人人的思想将其发布出来了吧，这里又可以解释为什么下载死链接很慢了，在下载死链接时都是从用户的电脑里下载的，又不是在服务器上，当然慢了。除非迅雷敢自己存储资源！

下面引用网上比较有价值的说法：注：红色为我添加的地方

举个例子：

1．用户点击1.2.3.4上的QQ_1.exe文件的连接

2．用户客户机上的迅雷得到该文件的唯一的校验值。

3．迅雷自动向自己的资源服务器上搜索，查找到存放同一文件的其他的服务器列表

4．得到文件在该服务器上的目录和文件名

ftp://1.2.3.5/QQ_2.exe，http://1.2.3.6/QQ_3.exe，以及公网用户1.2.3.7

有QQ.exe

5．迅雷自动向1.2.3.5和1.2.3.6上下载该文件的不同文件块，以达到加速下载的目的。

6．用户向公网用户1.2.3.7发送一个UDP资源请求

7．1.2.3.7回应一个资源请求说：偶这儿有你要的文件

8．用户向公网用户1.2.3.7的3077端口发起请求，并传输数据。

9．下载完毕后，如果迅雷资源服务器上，该文件的服务器列表中没有目前用户点击下载的服务器1.2.3.4，则将这个新的服务器地址加入到该文件的服务器列表（蓝色部分）。

注：

1．上述过程中的6、7、8步骤中隐含了一个过程：判断用户是否是公网用户。

如果是公网用户，则该用户的IP地址和提供下载服务的端口也将记录在迅雷的资源服务器中，后续用户可以从该用户处下载；第三节有这个过程的说明。

2．迅雷如何区分不同的文件？很多文件名字不同但是内容相同，很多文件名字相同但是内容不同。搜索迅雷的相关信息只是得到了几句无关痛痒的废话：迅雷还使用了独创的文件校验机制,保证了用户下载文件的正确性和完整。至于什么方法不得而知。以前有人说为了防止迅雷的盗链，将文件下载后随便改改再上传就可以了，偶认为是不对的，迅雷有极其强大的检验功能，只要还是原来的那个文件就可以了，反正他只要一部分！一头一尾还是“原版”。

再举个例子：如果你在1.1.1.1下载一个A文件，迅雷下载时搜到了30个资源，在下载时你选择了10线程，你会发现下面的“任务信息”的“线程1”肯定是你的原始链接，以后的线程就不会是了，但如果原始资源下载很慢怎么办？这时迅雷就体现出“智能”的一面，既然有很多资源我何必去下你这个慢的，停掉！！！························到快下载完时，这个线程1又蹦出来开始下载了，我百思不得其解后来终于明白了是为了掩人耳目，给大家一个我下载的是你制定的版本！这是我看到的，不知道对不对，仅供参考！

3．我们如何查看迅雷搜索到的资源列表？

在迅雷搜索到一系列的资源列表并且任务没有完成时，会在相同下载目录下建立一个临时文件，里面有搜索到的资源信息，其中peer就是搜索到的包含要下载文件的公网用户。

3协议解析

分析第二节原理图中的下载过程，第1、2、5步和正常的下载是一模一样的，我们无法根本无法区分。那好，我们就在3、4、6上做文章。除了上述用户下载一个具体文件的过程的各个报文外，还有交换资源信息报文，用户和用户之间的文件块传输报文、判断用户是否是公网用户的报文等。

1．资源请求报文

每次迅雷都会向219.134.132.47的TCP端口3076发出资源请求，该地址是写死在迅雷软件中的，并非依靠DNS请求得到。如果该地址不可用，则会切换到另外两个可替换的地址219.134.132.42、219.134.132.86。

Web迅雷则使用219.134.132.46。过滤掉这个报文，那么迅雷客户端就无法完成资源请求，无法从多点下载。用TP过滤掉报文后迅雷只能从原始连接下载

2．资源搜索回应报文

过滤掉这个报文，那么迅雷客户端就无法得到资源列表，无法从多点下载。

3．用户之间的文件传输（握手报文）

用户之间是可以传送文件块的，下面的报文就是传送文件块开始之前的握手报文，

3077端口为客户端的监听端口，用来把本地的文件传输给别人。（如果3077不能用,会转到其他端口）.

4．用户之间资源信息交换报文

5．提交新的资源信息报文

6．连接NAT测试服务器报文

迅雷每过几分钟就会向statnat1.sandai.net发送NAT测试报文，也就是告诉迅雷的资源服务器，自己是否是公网IP.该报文由于无返回报文，所以猜想采用的办法是采用STUN的方法：

将本机的IP地址放在UDP的payload里，如果迅雷的服务器收到报文发现IP层的源地址和payload里的IP地址一致，那么就是公网地址，否则就是处于防火墙后面或者需要经NAT才能上公网。

+10
评分记录