BitTorrent DHT协议簇 技术文档BitTorrent的分布式哈希表（DHT）是一个去中心化的对等网络，它允许客户端在没有中心Tracker服务器的情况下找到彼此。这个网络并非由单一协议构成，而是一个以核心协议为基础，由多个扩展协议（BEP, BitTorrent Enhancement Proposal）不断增强的协议簇。
核心协议：BEP-0005 - DHT Protocol这是整个DHT网络的基石，几乎所有BT客户端都实现了这个协议。它定义了DHT的Kademlia网络结构、四种基本消息类型和节点发现机制。
1. 网络结构
拓扑: 基于 Kademlia 算法。
ID空间: 160位的节点ID（Node ID）和信息哈希（Info-Hash），与SHA-1哈希长度一致。
距离度量: 两个ID之间的距离通过异或（XOR）运算定义 (distance = id1 XOR id2)。这个结果被视为一个无符号整数。
路由表: 每个节点维护一个路由表，由160个“K桶”（K-Buckets）组成，用于存储其他节点的信息。这种结构保证了对“近”的节点了解更详细，对“远”的节点了解相对稀疏。
2. 消息格式
所有消息都使用 Bencode 编码，并通过 UDP 协议传输。
消息分为三类，由顶层键 y 决定：
"y": "q": Query (查询/请求)
"y": "r": Response (响应)
"y": "e": Error (错误)
3. 四种基本查询 (q)一个节点通过向其他节点发送这四种查询来与网络交互。
查询名 (q)
目的
关键参数 (a 字典)
关键响应 (r 字典)
ping
检查节点是否在线，并将自己加入对方路由表
id: 查询者ID
id: 响应者ID
find_node
请求对方返回其路由表中离target最近的节点列表
id: 查询者ID, target: 目标ID
id: 响应者ID, nodes: 紧凑编码的节点列表
get_peers
请求下载某个info_hash的peer列表
id: 查询者ID, info_hash: 目标资源哈希
① values: peer列表, token: 宣告凭证② nodes: 更近的节点列表
announce_peer
宣告自己正在分享某个info_hash的资源
id, info_hash, port, token (必需)
id: 响应者ID (确认)
主要扩展协议以下是构建在BEP-5之上的、被广泛采用的扩展协议。
BEP-0032: IPv6 extension for DHT
目的: 让DHT网络同时支持IPv4和IPv6，实现混合网络通信。
核心机制:
在 find_node 响应和 get_peers 响应中，引入了一个新的可选字段 **nodes6**。
nodes: 继续用于存储紧凑编码的 IPv4 节点信息 (ID 20字节 + IP 4字节 + Port 2字节 = 26字节/节点)。
nodes6: 用于存储紧凑编码的 IPv6 节点信息 (ID 20字节 + IP 16字节 + Port 2字节 = 38字节/节点)。
客户端可以根据自己的网络能力选择性地请求和处理这些字段。
BEP-0042: DHT Security Extension
目的: 缓解DHT网络中的几种常见攻击，特别是针对节点ID生成的攻击。
核心机制:
强制节点ID与IP地址相关联。一个节点的ID的前几个字节必须与其公网IP地址的加盐哈希值相匹配。
这使得攻击者难以在特定ID空间区域内“伪造”大量节点（Sybil攻击），因为他们无法轻易地获得大量符合ID生成规则的IP地址。
在 find_node 查询中增加一个 want 字段，值为 ["n4", "n6"]，表示客户端期望收到的节点都符合此安全规范。
BEP-0044: Storing arbitrary data in the DHT
目的: 扩展DHT的功能，使其不仅仅能存储peer列表，还能存储少量（小于1000字节）的任意数据。这为实现Mutable Torrents（可变种子）和去中心化应用奠定了基础。
核心机制:
引入两种新的查询：**put** 和 **get**。
put 请求:
token: 必须提供，从之前的 get 请求中获得。
v: 要存储的值 (Bencode编码，<1000字节)。
签名机制: 为了验证数据所有权，put 请求必须包含公钥 (k) 和签名 (sig)。只有拥有与公钥对应的私钥的人才能成功写入。
序列号 (seq): 一个递增的整数，用于版本控制，确保新的数据可以覆盖旧的数据。
get 请求:
id: 查询者ID。
target: 要获取的数据的哈希键 (SHA-1)。
响应中会包含数据值 v、签名 sig、公钥 k、序列号 seq 以及一个用于后续 put 的 token。
BEP-0045: Multiple-address operation for the DHT
目的: 让一个同时拥有IPv4和IPv6地址的节点，能被网络中的其他节点正确地发现和使用。
核心机制:
当一个节点通过IPv4联系你时，你不能假设它也有IPv6地址（反之亦然）。
协议规定，客户端应该独立地在IPv4和IPv6网络栈上运行DHT实例，或者在同一个实例中能明确区分和验证不同协议族的地址。
它澄清了在混合网络环境下，如何正确地响应和更新路由表。
BEP-0051: DHT Info-Hash Indexing
目的: 允许DHT节点之间高效地交换info-hash样本，以加速新节点或爬虫对网络热门资源的发现速度。
核心机制:
引入一种新的查询：**sample_infohashes**。
查询 (q):
id: 查询者ID。
target: 目标ID，用于指定采样的ID空间区域。
响应 (r):
id: 响应者ID。
interval: 建议的下次采样间隔。
nodes: 靠近target的节点列表。
num: 响应者在其完整索引中拥有的总样本数。
samples: 核心字段。一个由多个20字节info-hash拼接而成的紧凑字符串。
这个协议极大地提高了DHT爬虫的效率。
协议关系与总结graph TD
A[BEP-0005: 核心DHT协议] --> B[BEP-0032: IPv6支持];
A --> C[BEP-0042: 安全扩展];
A --> D[BEP-0044: 可变数据存储];
A --> E[BEP-0045: 多地址操作];
A --> F[BEP-0051: Info-Hash索引];
subgraph 基础功能
A
end
subgraph 网络扩展
B
E
end
subgraph 安全增强
C
end
subgraph 功能扩展
D
F
end
style A fill:#f9f,stroke:#333,stroke-width:2px
BEP-5 是所有一切的起点。
BEP-32 和 BEP-45 共同解决了在现代IPv4/IPv6混合网络中的运行问题。
BEP-42 致力于提升网络的安全性，防止被恶意利用。
BEP-44 和 BEP-51 则是在核心功能之上进行的能力扩展，前者开启了DHT作为通用去中心化数据库的大门，后者则极大地优化了资源发现的效率。
一个现代的、功能完备的BT客户端或DHT爬虫，通常会实现BEP-5、BEP-32，并至少作为客户端使用BEP-51的功能。其他扩展则根据其具体需求选择性实现。