大家好，又见面了，我是你们的朋友全栈君。
UPDATE：项目已于2018年停止维护。
去年10月份开始研究相关的协议与资料，中途乱七八糟的事情差点没坚持下来，寒假期间修修补补，上礼拜把发布了，经过社交网络发布之后，发生了裂变式的分享，上线第三天UV就达到了两万多，也算是对这几个月工作的一点肯定吧。
界面比较简洁，一共三个页面：首页、列表页、详情页。如果你需要下载对应的文件，电脑里面需要安装一款支持磁力链接的软件，例如迅雷，QQ旋风，BitComet等。
一个种子主要包含元信息（文件标题、文件大小、文件列表等）和Tracker服务器信息，每当一个用户想要下载一个文件，客户端会先询问Tracker服务器，目前有哪些电脑正在下载这个文件，这些电脑被称为“peer”，然后客户端会向这些peer分别请求文件的各个片段，等每个片段都下载完成之后再组合成一个完整的文件，至此整个下载过程完毕。
由此可见，Tracker服务器相当于提供了一种“路由”服务，在整个下载过程中挥舞着指挥棒。但近年来由于打击盗版等原因，一些Tracker服务器开始陆续关闭，没有Tracker用户还怎么用种子下载文件呢？后来bt协议进行了扩充， ，它把Tracker的路由服务分散到了BT网络中的每个节点，那么一个种子由哪个或哪些节点负责路由服务呢？
首先，每个种子都有一个对应的20字节的hash，这个hash有sha1算法得到，每个节点也有一个20字节的id，通常是随机的20字节。如果这时有两个节点A和B，怎么判断这个种子放在A好还是B好呢？通过计算种子hash和节点id的异或值（称为距离），异或值最小（距离最近）的那个节点更适合提供这个种子的路由。
那整个网络之间的节点是如何进行沟通的呢？根据DHT Protocal，主要有四种请求：ping，find_node，get_peers，announce_peer。这四种消息其实都是字典类型，要经过之后才能被对方正确的处理，使用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”，可以把它从路由表中删除。
注意这里的ping，不是你用cmd黑框框里面的ping。这个请求主要用户询问对方是否在线，比较简单，主要用于维护自己路由表里面的节点。
顾名思义，find_node就是为了查询节点，它根据对方节点的id询问DHT网络，收到这个请求的节点，会把自己路由表中与该节点距离最接近的8个节点返回。
get_peers用于查找一个资源hash对应的peer，它询问路由表中与该hash最接近的8节点，收到该请求的节点如果发现自己知道对应的peer，返回这些peer的信息，否则返回它自己路由表中跟该hash最近的8个节点信息。发起get_peers的节点在收到peer信息了，则跟peer建立连接，正式开始下载文件片段。如果收到的是节点信息，则选出这些节点中跟hash最近的几个节点，递归的get_peers，直到发现peer。有两种情况要控制这种递归的返回：1. 超时，在一定时间内如果没有发现peer，则放弃。2. 已经发现了跟该hash最近的节点，但它没有peer信息。
announce_peer用于在自己get_peers发现peers之后发送，发送的对象是先前回复过自己get_peers的节点，告诉对方自己发现了peer，你们也可以“备份”一下，减小整个网络查询该hash的次数。
以前一个种子对应一个文件，现在一个hash对应一个文件，通过hash构造的磁力链接就可以下载一个文件。磁力链接的构造方式如下：
magnet:?xt=urn:btih:{hash}
磁力链接中的hash就是一个40个字符组成的字符串，由20字节的hash计算得来：
例如构造了一个磁力链接：magnet:?xt=urn:btih:EAE833FFE5A06B42B9B8C3F239660B537579C8A3 ，用迅雷打开后，迅雷就会下载对应的种子，然后下载该资源。
Btbook主要由DHT网络爬虫，种子下载分析器，一个网站组成。
DHT网络爬虫用一些“交友策略”，例如我可以递归的find_node，尽可能多的认识DHT网络中的节点，让自己加入到对方的路由表中。剩下的事情就是等待对方的请求，所有的请求都正常的给予回复，对于announce_peer请求，则记录下资源的hash，交给种子下载分析器处理。
当然随机在网络发起请求，不会有太多节点把你加入它的路由表，因为你们“距离”不够近。所以我想出了一种动态构造爬虫节点ID算法，使得它和网络任意节点的距离都较近，从而让对方路由表加入自己，后续能够收到更多的资源请求信息，实际测下来资源收集速度有上百倍的提升。
种子下载分析器通过hash下载对应的种子文件，从种子文件中获取文件标题、文件列表、文件大小等元信息，保存到索引文件中。
搜索网站用ASP.NET MVC搭建，用于处理用户的搜索，内部使用Elasticsearch做索引，对用户的搜索内容进行分词，对一些敏感词汇进行过滤，从索引文件中获取标题与搜索内容最匹配的结果，默认按资源的创建时间进行排序，突出“新”。
因为整个DHT网络是被我实时监听的，一旦网络中有人分享了内容，我就有概率捕获这个资源，所以一些最新的资源往往都能被索引，是“追剧者”的神器。