迅雷(XUNLEI)的工作原理揭密

迅雷(XUNLEI)如何搜索一个资源的多服务器版本？

-------实现一个类似迅雷的系统“福雷（FULEI）”

摘要：

当你用迅雷下载东西时，无论你是从迅雷资源页点下载，还是从其它普通页面点下载，你会发现它并不只用你的原始链接下载，它还搜索了一些其它服务器的相同资源，比起网络蚂蚁/网际快车之类的下载工具（这些都是纯客户端工具，而迅雷则有着服务器支持），大大增加成功下载的可能性和下载的速度，对比起P2P之类的下载软件，又更干净利落一些，那它是如何做到的呢？其实同baidu,google的基本原理是一样的，只不过各自的技术又有侧重而已，本文就个人经验分析其实现渠道及基本原理，暂称这个系统为福雷（FULEI），同本人名字有点谐音，呵呵，写下此文，也不枉昨晚失眠的几十分钟。

搜索,视频, 迅雷,p2p,下载,google,baidu,search,

 

转载请注明出处及作者（http://blog.csdn.net/mudboy    mudboy@csdn）

 

下载电影，音乐之类的大文件（相对于网页）相信是每一个年轻人最爱干的一件事之一了，在这个P2P下载软件横行的时代，为什么像迅雷这样的客户/服务器模式还能有那么大市场呢？我曾试过好几款P2P下载软件（如电骡，天网MAZE等），但没用多久就被我卸载了，我不喜欢被人家不断读硬盘的感觉，因为它们曾毁了我一块硬盘，而且占了我太多的上行带宽，个人认为，如果要用这类软件，别装在你的工作用机/学习用机上，而应专门用一台破机器去运行它。使用迅雷还是一两个月以前的事，因为在此之前，我主要还是用网际快车之类的软件下载东西，这类软件是纯客户端软件，更多的无非是下载管理/断点续传/多线程下载之类的功能，下载速度基本上取决于资源链接服务器和网络的速度，迅雷本身的客户端功能同上述功能差不多，不同的只是它可以从迅雷自已的服务器中获取其它服务器的相同资源信息，使单个资源可以从多个服务器/多线程/断点续传的下载，增加了资源成功下载的机率和速度，从我的使用过程看，很多资源的下载速度决不亚于P2P软件，甚至还更快，但相对于P2P，人家不会从我的机器上下载内容，更不会占用我的上行带宽，可以放心的在工作机上使用。

迅雷的这个点子，的确是个好点子！其实仔细想想，这其实只是个中庸的点子而已，介于P2P和纯客户端下载软件（如NETANTS，FLASHGET之类）之间的一个中庸点子，由此又验证了一句话：中庸在很多时候可能是最好的选择。

我们的福雷要做同迅雷差不多的事，读下文时可以暂将福字替换成迅。

谈了这么多，还没有谈到一点技术性的内容，真唐僧！

福雷做法的关键在哪里？在于当用户要下载一个资源时，如何去找在其它服务器上的完全相同的资源！

回顾一下普通搜索引擎的做法：用Crawler没日没夜的下载网页，然后存储，索引（倒排表是很常用的做法），用户搜索时，它会根据索引找到符合的页面，排序后，在本地服务器截取结果片段返回到客户端。PDF/WORD等文档的搜索也差不多，它们有个共同的特点是文件不太大，而且基本不太涉及版权问题，因而所有内容在自己服务器上都有快照。

但对于视频/音频等较大的文件（动则几十兆上百兆到G级），如果按上述方式处理则会有一些问题，首先要爬完一个资源所消耗的代价太大，其次，即使下来了，也没有太大的用处，你不能直接供用户下载，这可能会遭遇诉讼，看看百度音乐搜索，以前搜出来的结果直接指向资源位置，现在还非得出一个对话框，将位置明示，生怕被人抓住把柄，个人认为完全没有必要，也许是为了应付部分什么也不懂的官员，却让使用者感到不便。

既然是搜索，终归需要先找到资源，这一点大家都一样，基本的做法还是用Crawler，只不过，Crawler需要识别不同类型的资源区别对待，我们以视频文件为例说明。

假如Crawler在工作的过程中标识出了所有视频文件的链接并交于特殊的处理程序处理，接下来的问题如何存储和索引这些信息，刚才已经说了，要下载整个视频文件并不现实，而有一些内容是很容易得到的：资源链接，文件名/文件类型（扩展名），大小，存储这些信息是简单且必要的，

现在的关键问题是如何判断文件的同价性？也就是说，如何知道这几个文件是一样的？存储这个信息对我信至关重要，通过文件名？显然不行，通过修改时间？作者？大小？等，都不太准确，最常用的方法还是计算文件摘要，而计算文件摘要最常用的方法又是MD5（虽说MD5可以破解，但对于大众化应用，这种破解没什么意义，而在非人为状况下，MD5可以认为是可靠的），但这又出现一个新的难题，计算摘要需要所在文件内容，我们有以下选择：

1、  能不能在服务器上计算？（可惜视频不像些开源软件，下载链接中常有MD5摘要文件，这样可以一并下来），而想在服务器上计算，是否有些异想天开？

2、  下载所有内容计算摘要，上面已经说过这个问题

3、  下载部分内容计划摘要，听起来真不错，又是一个中庸的想法，我现在越来越喜欢中庸了，没错，就是它，但下载哪部分内容呢？我们可以根据文件大小利用一些简单的散列算法生成散列值，根据这些值在文件的不同部分读取一定量的数据，总数据量控制在K级别（同网页差不多大小），然后将这些数据拼装成整体存储并生成其摘要。这种方法是可行的。首先，它的下载量不大，其次，根据该方法判文件的等价性同基准方法（根据所有数据算摘要）比准确率几乎相同（证明过程我就不说了，实践才是最好的标谁）

利用摘要判断文件等价性的方法有一个好处是可以忽略一些次要信息，比如文件名，创建时间，修改时间等，但文件类型，长度和摘要则是需要考虑的成份。也就是说，如果这三者一样，则我们认为文件是一样的。

存储完上述信息，至于如何索引，考虑的因素可能会多一些，最简单的就以摘要索引就行，这样等价资源会被聚类到一起，但作为一个资源聚集点，资源的描述信息也是要考虑进去的，等下我们会专门谈到这个问题。

上面已经讲完了主要内容，我们看看当我们利用福雷下载时它做了一些什么事情。

1、  先看看普通的链接（非福雷链接）

a)         用户在任何一个网站想用其下载资源：http://blog.csdn.net/mudboy/movie/wanfang.rmvb

b)        福雷客户端将该连接发到福雷服务器，同时，客户端也不闲着，它会去该链接获取文件的基本信息（大小等），并按上面所述的算法下载部分内容并计算摘要。

c)        服务端根据链接找自己服务器，看是否已被系统Crawler处理过，如果已被处理过，很简单，通过其摘要找到所有含有该资源的服务器链接发到客户端。

d)        客户端为了保险起见，会对比一下服务端的摘要和自己算出的摘要（避免文件在近期发生变动），如果一至，OK，可以从服务端发过来的多服务器下载了。

e)         如果不一样的话，客户端需将该信息发到服务端，告诉它文件有变，服务端会去更新该文件的相关信息（包括等价文件链接），这个过程可以短也可能长，由此同时，客户端会通过原始链接开始下载，服务端更新后，会陆续将确认后的链接发到客户端，客户端从而可又可从新增的链接下载。

f)         接c)，如果服务端未找到原始链接呢？是不是意味着服务端就没有其它链接呢？并不一定，此时，客户端将信息及摘要发到服务端，服务端可根据摘要数据去搜索，如果搜索到结果，则将这些结果链接发到客户端，并将该原始链接加入到服务器索引中，从而同样实现多服务器下载，如果没搜索到，则只能从原始链接下载资源了。

g)        在上一步中，如果服务器没找到原始链接也没找到等价文件，服务端会存储该并索引该链接信息。

h)        在上述过程中，对于福雷服务器没有的原始链接，用户可以在门户去发布该资源，此时，用户就可以填入一些该资源的描述信息（这一步要都由公司人员去做，几乎是不可能的），成千上万的网民这样做，门户内容就丰富了（不仅有视频，还有视频的描述信息等其它一些元数据，前面提到索引方式，如果加上这部分内容的索引，又进一步实现在基于关键字的搜索）这本身又有点WEB2.0的概念，由网友自发来聚集和编辑视频信息。

2、  再看看专用链接，比如，你通过雷区找到的资源，有一些链接类似如下形式：

thunder://QUFmdHA6BDCsdi/ry+L1Byaxfdif=

对于这类链接，其实相当于一个映射而已，比如，在上一节的h)步骤中，用户发布了一些资源，这个资源在福雷服务器中找到了一系列等价资源，这个搜索等价资源的过程是需要消耗服务器资源的（这个资源是指CPU/内存等机器资源），这样，可以专为该资源生成一个URL，该URL就对应上述链接信息的索引以及用户输入的视频元数据信息，这样，用户可以很容易通过关键字搜到该视频，同时使用这类URL下载时，没有一个搜索等价资源的过程，直接就可以返回一系列服务器链接到客户端，直接实现多服务器下载。

 

说了这么多，本来应该画个框架图流程图什么的，但愿说清楚了，有什么好的想法可以多交流。