用.NET开发的磁力搜索引擎——btbook.net

UPDATE:项目已于2018年停止维护。

        去年10月份开始研究相关的协议与资料,中途乱七八糟的事情差点没坚持下来,寒假期间修修补补,上礼拜把Btbook发布了,经过社交网络发布之后,发生了裂变式的分享,上线第三天UV就达到了两万多,也算是对这几个月工作的一点肯定吧。

        界面比较简洁,一共三个页面:首页、列表页、详情页。如果你需要下载对应的文件,电脑里面需要安装一款支持磁力链接的软件,例如迅雷,QQ旋风,BitComet等。

DHT Protocal

        一个种子主要包含元信息(文件标题、文件大小、文件列表等)和Tracker服务器信息,每当一个用户想要下载一个文件,客户端会先询问Tracker服务器,目前有哪些电脑正在下载这个文件,这些电脑被称为“peer”,然后客户端会向这些peer分别请求文件的各个片段,等每个片段都下载完成之后再组合成一个完整的文件,至此整个下载过程完毕。

        由此可见,Tracker服务器相当于提供了一种“路由”服务,在整个下载过程中挥舞着指挥棒。但近年来由于打击盗版等原因,一些Tracker服务器开始陆续关闭,没有Tracker用户还怎么用种子下载文件呢?后来bt协议进行了扩充,添加了DHT(Distributed Hash Table) ,它把Tracker的路由服务分散到了BT网络中的每个节点,那么一个种子由哪个或哪些节点负责路由服务呢?

        首先,每个种子都有一个对应的20字节的hash,这个hash有sha1算法得到,每个节点也有一个20字节的id,通常是随机的20字节。如果这时有两个节点A和B,怎么判断这个种子放在A好还是B好呢?通过Kademlia算法计算种子hash和节点id的异或值(称为距离),异或值最小(距离最近)的那个节点更适合提供这个种子的路由。

       那整个网络之间的节点是如何进行沟通的呢?根据DHT Protocal,主要有四种请求:ping,find_node,get_peers,announce_peer。这四种消息其实都是字典类型,要经过B编码之后才能被对方正确的处理,使用UDP协议进行发送,这四种请求都会影响自己维护的一张路由表。

路由表

        路由表主要用于存储跟自己打过交道的节点信息,节点信息包含IP、Port和节点ID信息。而路由表由一个个的吊桶(Bucket)组成,在这里我简称它为“桶”。每个桶只能存储一定节点ID在一定范围的节点信息,并且桶的容量有限,一般规定一个桶只能存储8个节点。起初路由表里面只有1个桶,这个桶能存储的节点ID范围在2^0至2^160,也就是任何节点它都能保存,等这个桶满了之后怎么办?——分裂。例如桶(min, max)分裂为两个桶后,两个桶能保存的范围分别为(min, max/2), (max/2, max),原先的那个桶里面的8个节点也要重新分配到分裂后的两个桶中。

        伟大的毛主席说过,只要有一拨人,就分左中右。节点也是这样,分为good、questionable和bad,“good”指过去15分钟内该节点跟我有过联系,如果15分钟内该节点没有跟我联系过,它会变成“questionable”状态,客户端就会向它发出几个ping,如果没有收到回应,它就变为“bad”,可以把它从路由表中删除。

KPRC Protocal

1. ping

        注意这里的ping,不是你用cmd黑框框里面的ping。这个请求主要用户询问对方是否在线,比较简单,主要用于维护自己路由表里面的节点。

2. find_node

        顾名思义,find_node就是为了查询节点,它根据对方节点的id询问DHT网络,收到这个请求的节点,会把自己路由表中与该节点距离最接近的8个节点返回。

3. get_peers

        get_peers用于查找一个资源hash对应的peer,它询问路由表中与该hash最接近的8节点,收到该请求的节点如果发现自己知道对应的peer,返回这些peer的信息,否则返回它自己路由表中跟该hash最近的8个节点信息。发起get_peers的节点在收到peer信息了,则跟peer建立连接,正式开始下载文件片段。如果收到的是节点信息,则选出这些节点中跟hash最近的几个节点,递归的get_peers,直到发现peer。有两种情况要控制这种递归的返回:1. 超时,在一定时间内如果没有发现peer,则放弃。2. 已经发现了跟该hash最近的节点,但它没有peer信息。

4. announce_peer

        announce_peer用于在自己get_peers发现peers之后发送,发送的对象是先前回复过自己get_peers的节点,告诉对方自己发现了peer,你们也可以“备份”一下,减小整个网络查询该hash的次数。

磁力链接

        以前一个种子对应一个文件,现在一个hash对应一个文件,通过hash构造的磁力链接就可以下载一个文件。磁力链接的构造方式如下:

magnet:?xt=urn:btih:{hash}

        磁力链接中的hash就是一个40个字符组成的字符串,由20字节的hash计算得来:

public static string ToHexString(byte[] hash)
{
    var sb = new StringBuilder();
    foreach (var b in bytes)
    {
        sb.Append(b.ToString("X2"));
    }
    return sb.ToString();
}

        例如构造了一个磁力链接:magnet:?xt=urn:btih:EAE833FFE5A06B42B9B8C3F239660B537579C8A3 ,用迅雷打开后,迅雷就会下载对应的种子,然后下载该资源。

Btbook是什么

        Btbook主要由DHT网络爬虫,种子下载分析器,一个搜索网站组成。

        DHT网络爬虫用一些“交友策略”,例如我可以递归的find_node,尽可能多的认识DHT网络中的节点,让自己加入到对方的路由表中。剩下的事情就是等待对方的请求,所有的请求都正常的给予回复,对于announce_peer请求,则记录下资源的hash,交给种子下载分析器处理。

        当然随机在网络发起请求,不会有太多节点把你加入它的路由表,因为你们“距离”不够近。所以我想出了一种动态构造爬虫节点ID算法,使得它和网络任意节点的距离都较近,从而让对方路由表加入自己,后续能够收到更多的资源请求信息,实际测下来资源收集速度有上百倍的提升。

        种子下载分析器通过hash下载对应的种子文件,从种子文件中获取文件标题、文件列表、文件大小等元信息,保存到索引文件中。

        搜索网站用ASP.NET MVC搭建,用于处理用户的搜索,内部使用Elasticsearch做索引,对用户的搜索内容进行分词,对一些敏感词汇进行过滤,从索引文件中获取标题与搜索内容最匹配的结果,默认按资源的创建时间进行排序,突出“新”。

        因为整个DHT网络是被我实时监听的,一旦网络中有人分享了内容,我就有概率捕获这个资源,所以一些最新的资源往往都能被索引,是“追剧者”的神器。

使用Btbook

        如果你用电脑访问btbook,你的电脑安装了支持磁力链接的软件即可。如果你使用的是移动设备,你可以安装迅雷手机版之类的软件(“手雷”),把btbook添加进收藏,在手雷中打开btbook,就可以直接在手机中下载文件了。Btbook的网址是:http://btbook.net/ ,考虑了移动版浏览器兼容性,have fun!

                

posted @ 2014-03-03 17:24  Create Chen  阅读(34053)  评论(78编辑  收藏