磁力链接协议深度解析：从 BEP-9 到 DHT 爬虫

做 磁力古哥 之前，我对磁力链接的认知只停留在"复制粘贴到 BitComet"这个层面。深入做这个项目后才发现，磁力链接背后是一套精巧的 P2P 协议体系。这篇把它从 URI 结构到 DHT 网络全部拆开讲。

如果你需要在线解析一条磁力链接看结构，可以用我做的 磁力链接解析器。

什么是磁力链接

磁力链接（Magnet URI）是一种通过内容哈希来标识资源的 URI 方案，由 RFC 草案定义。它和 HTTP URL 的本质区别：

磁力链接最大的特点是无需中心化协调——你拿到一条磁力链接，理论上不需要联系任何特定服务器就能找到资源。

URI 结构详解

一条标准的磁力链接长这样：

magnet:?xt=urn:btih:E7B7E9D4A8F1B2C5D6E7A8B9C0D1E2F3A4B5C6D7&dn=Ubuntu-22.04-Desktop&tr=udp%3A%2F%2Ftracker.example.com%3A80&xl=3826253824

拆开看每个参数：

其中 xt 是核心。它的值采用 URN 格式，最常见的是 urn:btih:（BitTorrent Info Hash）。

Info Hash：磁力链接的"身份证"

info hash 是 .torrent 文件中 info 字段的 SHA-1 摘要（v1）或 SHA-256 摘要（v2）。它的核心作用是：标识唯一一组文件 + 一组分块校验。

简单说，从 .torrent 文件的内部结构（用 bencode 编码）中提取出 info 字典，对它做哈希，得到 20 字节（v1）或 32 字节（v2）的二进制串。十六进制表示就是磁力链接里看到的 40 / 64 字符串。

为什么这个 hash 这么重要？因为：

• 相同内容的资源 → 相同 info hash → 不同来源也能匹配（去重）
• BitTorrent 协议握手时双方校验 info hash → 错配直接断开
• DHT 网络以 info hash 作为 lookup key → 找拥有该资源的 peer

info hash 的两种编码：

# 十六进制（40 字符，常见于 magnet URI）
xt=urn:btih:E7B7E9D4A8F1B2C5D6E7A8B9C0D1E2F3A4B5C6D7

# Base32（32 字符，等价表示）
xt=urn:btih:464362WKR4LCLVTKBC4WBUPC6OSLLRWX

# v2 (BEP-52, SHA-256)
xt=urn:btmh:1220<64位hex>

客户端解析时要兼容三种格式。我做磁力古哥的解析器时这部分逻辑写了不少。

DHT：去中心化的 peer 发现

这是磁力链接最神奇的部分。没有中心服务器告诉你"谁有这个资源"，但你居然能找到 peer——靠的是 DHT（分布式哈希表）。

BitTorrent 用的 DHT 基于 Kademlia 算法（BEP-5）。基本原理：

1. 每个节点有一个 160 位的 ID（随机生成）
2. 节点之间用 XOR 距离衡量"远近"
3. 每个节点维护一个路由表（k-bucket），存储不同距离的节点
4. 查找资源时：从离 info hash "最近"的节点开始，逐步逼近
5. 找到持有该资源的 peer 后，连接它进入 BitTorrent 标准流程

Kademlia 的时间复杂度是 O(log n)——即便整个网络有数百万节点，也能在 ~20 跳内找到目标。

从磁力到下载：完整流程

一条磁力链接从用户复制到开始下载，背后发生的事情：

1. 解析 magnet URI
   └─ 提取 info hash, dn, tr, xl

2. 启动 peer 发现（并行多路）
   ├─ 路径 A: tracker 协议
   │   └─ 向 tr 列表中的 tracker 发 announce 请求
   │   └─ tracker 返回最近 50 个 peer 的 IP:port
   │
   ├─ 路径 B: DHT 网络
   │   └─ 在 Kademlia 网络中查找 info hash
   │   └─ 找到持有该资源的 nodes
   │
   └─ 路径 C: PEX (Peer Exchange)
       └─ 已连接的 peer 互相分享其他 peer 列表

3. 选择 peer 建立 BitTorrent 连接
   └─ TCP/uTP 握手，互验 info hash

4. 元数据交换 (BEP-9)
   └─ 通过 ut_metadata 扩展从 peer 获取完整 .torrent 信息
   └─ 包含文件列表、分块大小、每块的 SHA-1 等

5. 开始分块下载
   └─ 标准 BitTorrent 协议

关键点 4 是 BEP-9 的核心创新：磁力链接最初不包含 .torrent 文件信息，但通过 ut_metadata 扩展，下载端可以从其他 peer 那里"借"完整元数据。这是磁力链接能脱离中心化 .torrent 文件存在的关键。

为什么 tracker 仍然存在

既然有 DHT，为什么磁力链接里还有 tracker URL？两个原因：

1. 启动加速：DHT 查找一个新节点平均需要数秒，tracker 通常 100ms 内返回结果。冷启动时 tracker 体验明显更好。
2. DHT 失败的兜底：DHT 网络对 NAT、防火墙环境敏感，部分用户的 DHT 不工作，tracker 是备用。

实际客户端的策略是同时跑 tracker + DHT，谁先返回 peer 就用谁的。

v1 vs v2：未来已来

BEP-52 定义了 BitTorrent v2，2020 年左右开始推广。主要变化：

实践中现在很多客户端都支持 hybrid 模式：同一个种子既可以 v1 也可以 v2。磁力链接里会出现两个 xt：

magnet:?xt=urn:btih:<v1-hash>&xt=urn:btmh:1220<v2-hash>&dn=...

客户端选哪个用，看自己的支持情况。

DHT 爬虫：磁力索引站的工作原理

到这里你可能好奇：那些"磁力搜索网站"的索引是怎么来的？答案是 DHT 爬虫。

原理很巧妙：

1. 启动一个 DHT 节点，假装自己是某个 ID
2. 监听网络上其他节点发来的 get_peers 请求
3. 每个 get_peers 请求都带着 info hash
4. 收集这些 info hash 就是"全网正在传播的资源指纹"
5. 对每个 info hash 发起 metadata 请求（BEP-9）拿到文件名、大小
6. 持久化到数据库，对外提供搜索

这是为什么"磁力搜索"网站不需要存任何文件——它们只是在被动观察 DHT 网络的流量。每个磁力站的差异在于爬虫策略、metadata 抓取速度、过滤规则等。

合规视角的几个事实

聊聊磁力链接的合规边界（这部分写在博客里很重要，避免误导读者）：

• 磁力链接本身是中性的协议——就像 HTTP URL 本身不违法
• 所传输内容的合法性由用户负责——下载盗版/侵权内容仍违法
• 合法用途：Linux ISO、开源软件、公共数据集（如 archive.org）、学术资料、纪录片、独立游戏 demo 等
• 不合法用途：有版权保护的影视作品、商业软件、付费数据等

我做 磁力古哥 时把这块边界画得很清楚——它是搜索工具，不存储任何内容，搜索结果的使用合法性由用户自行判断。

给开发者的实用资源

• BEP 规范文档：bittorrent.org/beps — 所有协议规范
• libtorrent：C++ 库，被大多数客户端使用
• WebTorrent：浏览器端的 BitTorrent 实现
• parse-torrent（npm）：Node.js 端的 .torrent / magnet 解析库

研究这套协议的过程中，我做了 磁力古哥 — 一个 Android 端的聚合磁力索引搜索 App。它做的是搜索聚合而不是 P2P 客户端：把多个磁力索引站聚合到一起，让你输入一次关键词就能在多源中找资源。免费、无广告、本地零账号。如果你常需要找开源软件镜像、纪录片或公开资源，可以试试。