【P2P网络】BitTorrent的DHT协议(译自官方版本)

来源虾库网：xiaqo.com

译者前序

DHT协议早在2005年就已经成为了官方BitTorrent协议的一部份，但是我竟然一直没有找到国内的官方翻译稿，所以将其进行翻译，若文中错误，欢迎各位指正。

其次，若想彻底理解DHT协议的原理，建议各位阅读Kademlia协议，在本博客中，有其翻译稿，参见DHT协议基础1，2.

本文英文版官方地址：http://www.bittorrent.org/beps/bep_0005.html

DHT协议

BitTorrent使用一种叫做分布式哈希表(distributedsloppy hashtable)的技术，来实现在无tracker的torrent文件中peer的联系信息存储。这个时候，每个peer都是一个tracker。这个协议是基于Kademila协议的，并且在UDP协议基础上实现。

请注意本文档所使用的术语以免引起混淆。“peer”是一个实现了BT协议，且正在监听TCP端口的client/server。“node”是实现了DHT协议的，且正在监听UDP端口的client/server。DHT由nodes组成并保存peer的位置信息。BitTorrent客户端也包括DHTnode，这个DHTnode主要是用来联系DHT中的其他nodes，以得peer的位置信息，从而通过BitTorrent协议下载。

概述

每一个node都有一个全局的唯一标识“nodeID”。NodeIDS的产生是随机的，且使用与BitTorrent的infohashes相同的160-bit空间。“distancemetric”用来比较2个nodeIDs或者nodeID与infohash的接近程度。Nodes必须维护一个路由表，其中保存了一部分其他nodes的联系信息。越接近自身节点时，路由表的信息会更加详细。nodes保存了很多接近自己的节点，但是离自己很远的节点的联系信息确知道得很少。

在Kademlia中，“distancemetric”采用XOR异或计算，并转换为一个无符号整数。distance(A,B)= |A xor B| ，并且距离越小表示2个节点越接近。

当一个node想得到某个torrent文件的peers，它首先使用distancemetric来比较torrent文件的info_hash和路由表中节点的nodeID。接下来向路由表中nodeID与info_hash最接近的那些节点发送请求，得到当前正在下载这个torrent文件数据的peers的联系信息。如果被请求的节点知道这个torrent文件的peers，那么peer的联系信息将包含在回复中。否则，被请求的节点必须返回他的路由表中更接近info_hash得那些节点。原始的请求node不断向新获得的那些node中，更接近目标info_hash的那些node发送请求，直到不能获得更近的nodes。当查找结束时，client将自己的信息作为一个peer插入到在刚才请求中给出回复的那些节点中，nodeid与info_hash最接近的哪个节点上，这样，哪个节点又多保存了一个peer信息。

在请求peers的时候，对方给我们的回复必须还包含一个不透明的令牌，我们称他为“token”。这样当我们宣布我们正在下载某个torrent，想让对方保存我们的信息时，我们必须使用对方向我们发送的最近的一个token。这样当我们宣布我们在下载一个torrent时，被请求的node检查这个token和IP是否与之前他们向我们回复的一样。这样是为了防止恶意的攻击。由于token仅仅由请求的节点返回，所以我们不规定他的具体实现。但是token必须有一个可接受的时间范围，超过这个时间，token将失效。在BitTorrent的实现中，token是在IP地址后面连接一个secret(可以视为一个随机数)，这个secret每五分钟改变一次，其中token在十分钟以内是可接受的。

路由表

每一个node维护一个路由表保存已知的好节点。这些路由表中的nodes被作为DHT请求的起始节点。路由表中的nodes是在不断的向其他node请求过程中，对方节点回复的。

并不是我们在请求过程中收到得节点都是平等的，有的node是好的，而有的node是死掉的。很多使用DHT协议的nodes都可以发送请求并接收回复，但是不能主动回复其他节点的请求(我认为这是由于防火墙或者NAT的原因)。对每一个node的路由表，只包含好的nodes是很重要的。好的node是指在过去的15分钟以内，曾经对我们的某一个请求给出过