磁力链接协议深度解析：从 BEP
磁力链接协议深度解析：从 BEP-9 到 DHT 爬虫
2026-05-15
协议
P2P
· 约 12 分钟
做 磁力古哥 之前，我对磁力链接的认知只停留在"复制粘贴到 BitComet"这个层面。深入做这个项目后才发现，磁力链接背后是一套精巧的 P2P 协议体系。这篇把它从 URI 结构到 DHT 网络全部拆开讲。
如果你需要在线解析一条磁力链接看结构，可以用我做的 磁力链接解析器。
什么是磁力链接
磁力链接（Magnet URI）是一种通过内容哈希来标识资源的 URI 方案，由 RFC 草案定义。它和 HTTP URL 的本质区别：
维度HTTP URLMagnet URI
定位方式位置（哪台服务器）内容（什么数据）
依赖中心化服务器P2P 网络（DHT/tracker）
典型协议HTTP/HTTPSBitTorrent
失效场景服务器宕机即失效只要还有一个 peer 在持有
磁力链接最大的特点是无需中心化协调——你拿到一条磁力链接，理论上不需要联系任何特定服务器就能找到资源。
URI 结构详解
一条标准的磁力链接长这样：
magnet:?xt=urn:btih:E7B7E9D4A8F1B2C5D6E7A8B9C0D1E2F3A4B5C6D7&dn=Ubuntu-22.04-Desktop&tr=udp%3A%2F%2Ftracker.example.com%3A80&xl=3826253824
拆开看每个参数：
参数全称含义
xteXact Topic资源唯一标识（必须）
dnDisplay Name显示名（建议但非必须）
trtrackertracker URL，可重复多个
xleXact Length文件大小（字节）
xseXact SourceHTTP 镜像备用源
asAcceptable Source可选 HTTP 源
ktKeyword Topic关键词搜索（少用）
wsWebSeedBEP-19 网页种子
其中 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）。基本原理：
每个节点有一个 160 位的 ID（随机生成）
节点之间用 XOR 距离衡量"远近"
每个节点维护一个路由表（k-bucket），存储不同距离的节点
查找资源时：从离 info hash "最近"的节点开始，逐步逼近
找到持有该资源的 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？两个原因：
启动加速：DHT 查找一个新节点平均需要数秒，tracker 通常 100ms 内返回结果。冷启动时 tracker 体验明显更好。
DHT 失败的兜底：DHT 网络对 NAT、防火墙环境敏感，部分用户的 DHT 不工作，tracker 是备用。
实际客户端的策略是同时跑 tracker + DHT，谁先返回 peer 就用谁的。
v1 vs v2：未来已来
BEP-52 定义了 BitTorrent v2，2020 年左右开始推广。主要变化：
维度v1v2
哈希算法SHA-1SHA-256
分块校验整个 piece 一个 hashMerkle tree（每个 block 都可校验）
info hash 长度20 字节32 字节
下载效率错块需重传整个 piece错块定位到 16KB block
磁力 URNurn:btih:urn:btmh:1220
实践中现在很多客户端都支持 hybrid 模式：同一个种子既可以 v1 也可以 v2。磁力链接里会出现两个 xt：
magnet:?xt=urn:btih:
客户端选哪个用，看自己的支持情况。
DHT 爬虫：磁力索引站的工作原理
到这里你可能好奇：那些"磁力搜索网站"的索引是怎么来的？答案是 DHT 爬虫。
原理很巧妙：
启动一个 DHT 节点，假装自己是某个 ID
监听网络上其他节点发来的 get_peers 请求
每个 get_peers 请求都带着 info hash
收集这些 info hash 就是"全网正在传播的资源指纹"
对每个 info hash 发起 metadata 请求（BEP-9）拿到文件名、大小
持久化到数据库，对外提供搜索
这是为什么"磁力搜索"网站不需要存任何文件——它们只是在被动观察 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 客户端：把多个磁力索引站聚合到一起，让你输入一次关键词就能在多源中找资源。免费、无广告、本地零账号。如果你常需要找开源软件镜像、纪录片或公开资源，可以试试。
试用磁力古哥
Android 端聚合磁力索引搜索 App，免费无广告。百度/Google 搜「磁力古哥」「magnetgoogo」即可找到。
访问 magnetgoogo.com ↗
在线解析磁力链接
相关文章
磁力古哥 magnetgoogo 是怎么做出来的
磁力链接解析器（在线工具）
用 React Native 实现一个并发搜索引擎