DHT(Distributed Hash Table) 分布式哈希表

DHT的全称是Distributed Hash Table，即分布式哈希表技术，是一种分布式存储方法。

这种网络不需要中心节点服务器，而是每个客户端负责一个小范围的路由，并负责存储一小部分数据，从而实现整个DHT网络的寻址和存储。

和中心节点服务器不同，DHT网络中的各节点并不需要维护整个网络的信息，而是只在节点中存储其临近的后继节点信息，大幅减少了带宽的占用和资源的消耗。

DHT网络还在与关键字最接近的节点上复制备份冗余信息，避免了单一节点失效问题。

形象地，我们可以把整个DHT网络想象成一个大城市，那么每个客户端，就好比城市里各个角落的地图，上面绘制了附近区域的地形情况，把这些地图一汇总，城市的全貌就出来了。

而DHT所采用的算法中最出名的是Kademlia，eMule早在一年多前就开始采用，Bitcomet、Azureus和BitTorrent只是步其后尘，同样使用Kademlia算法的DHT。

不过它们各自的实现协议不尽相同，因此不能相互兼容（BitComet与BitTorrent兼容，Azureus更像eMule，但与其它都不兼容）。

在不需要服务器的情况下，每个客户端负责一个小范围的路由，并负责存储一小部分数据，从而实现整个DHT网络的寻址和存储。

新版BitComet允许同行连接DHT网络和Tracker，也就是说在完全不连上[Tracker服务器的情况下，也可以很好的下载，因为它可以在DHT网络中寻找下载同一文件的其他用户。

BitComet的DHT网络协议和BitTorrent今年5月测试版的协议完全兼容，也就是说可以连入一个同DHT网络分享数据
Kademlia技术，通常又被称为第三代p2p技术，是一种P2P通用协议，适用于所有的分布式点对点计算机网络。

Kademlia定义了网络的结构，规划了节点之间的通讯以及具体的信息交互过程。

在Kademlia中，网络节点之间使用UDP进行通信，通过一种分布式哈希表来存储数据，每个节点都会有一个自己的ID，在用来标识节点本身的同时，也用以协助实现Kademlia算法和流程。

在传统的BT下载里，所有的种子文件都必须指定一个或多个种子服务器，即通常所说的Tracker或Announce地址，种子文件和连接信息都存储在种子服务器上，而引入了DHT 网络之后，这些连接信息则可以保存在根据一定的算法挑选出的DHT网络参与者（即DHT 节点）之间，也就是说，一旦你加入公有DHT网络，你就会有一个ID（该ID只是程序生成的、虚拟的、完全随机的ID，与你的实际个人信息没有任何联系，请完全放心）。

而根据一定的规则，你需要负责维护一部分种子文件的连接信息，相当于你同时也是一个超轻量级种子服务器。

这样，下载者只要接入了DHT网络，并且找到了一些连接（或者说节点），就能获得连接信息，而不需要再依赖于tracker服务器。

这样，加入DHT网络解决了传统BT下载中的两个问题：
第一：一旦该种子服务器当机或由于其它原因无法访问，BT用户很可能就无法继续获得连接信息（当然，已经有比特精灵等一些客户端通过连接共享等功能一定程度解决了这个问题）；
第二：在传统BT下载中，如果有两个完全相同的种子文件，但是由于指定了不同的Tracker，那么不同Tracker的用户之间将无法进行下载与上传，从而不能充分体现BT的下载/上传效率。

减少对种子服务器的依赖
现在，剩下的问题就是，即使加入了DHT网络，BT下载还是得从种子服务器处获得种子文件。

相信大家都有体会，遇上服务器繁忙的时候，几分钟甚至更长时间连不上服务器是很常见的事情。

比特精灵在支持DHT网络的同时，对其在应用层面上进行了拓展，支持只需要一个类似链接<A href="http://Kademlia/..(40B">http://Kademlia/..(40B</A>的哈希Hex串)....的链接就
能添加任务(提示：在比特精灵里选中一个任务后通过右键菜单的"拷贝DHT链接"可以提取种子的链接)，然后比特精灵可以通过特征串从DHT网络节点处得到种子文件，而不需要依赖种子服务器,从而在实现了trackerless的同时，也实现了torrentless。

这样，BT下载就借助公有DHT网络，很大程度上减少了对种子服务器的依赖。

可以说，DHT网络的引入使得BT不再必需种子服务器，可以说是天下从此无服，但从更深层次的角度来说，应该是天下从此无人不服。