BitTorrent（BT）是一种基于 P2P（Peer-to-Peer，点对点）网络的文件分发协议。
传统的 HTTP 下载通常由服务器向客户端传输文件，而 BitTorrent 允许多个用户之间相互传输文件数据，减少单一服务器的带宽压力。
BT 下载主要涉及以下概念：
| 名称 | 作用 |
|---|---|
| BitTorrent | P2P 文件分发协议 |
| Torrent（.torrent） | 描述共享文件及其校验信息的种子文件 |
| Magnet | 使用资源标识符定位 BT 资源的磁力链接 |
| DHT | 分布式哈希表，用于发现其他节点 |
| Tracker | 帮助下载者发现其他 Peer 的服务器 |
| Peer | 参与文件传输的客户端节点 |
| Seeder（做种者） | 拥有完整资源并向其他节点上传数据的 Peer |
| Leecher（下载者） | 尚未拥有完整资源的 Peer |
| Piece | 文件被划分后的数据块 |
| Info Hash | 对种子元数据中 info 字典计算得到的标识哈希 |
注意：BitTorrent 是文件传输协议，DHT 是节点发现机制，Magnet 是资源标识和链接格式。三者并不是互相替代的下载协议。
BitTorrent 采用分块传输的方式，将一个完整文件分割成多个 Piece。
例如，一个 1GB 的文件可以分成多个 4MiB 的 Piece。
下载者不需要从同一个服务器下载全部数据，而是可以从不同 Peer 下载不同 Piece。
下载完成的 Piece 经过校验后，也可以继续上传给其他节点。
因此，一个用户既是下载者，也可以是上传者。
假设用户 A 制作了一个种子，用户 B 和 C 希望下载资源。
第一步：制作种子
用户 A 使用 BT 客户端选择文件，生成 .torrent 文件。
种子中包含：
种子本身通常不包含被分享文件的实际内容。
第二步：获取种子
用户 B 获得 .torrent 文件，使用 qBittorrent 等客户端下载。
第三步：发现 Peer
客户端通过以下方式寻找拥有资源的其他节点：
第四步：建立连接
客户端通过 TCP 或 uTP 等传输方式连接其他 Peer。
双方通过 BitTorrent 握手确认资源标识及协议兼容性。
第五步：下载 Piece
客户端向不同 Peer 请求数据块。
例如：
客户端下载并验证数据完整性。
第六步：上传与做种
下载过程中，客户端可以把已经验证的数据块上传给其他 Peer。
当所有数据下载完成后，客户端进入做种状态。
greenyang361
发布者
|
创建 .torrent
|
分享种子文件
|
下载者
|
BT 客户端解析种子
|
获取 Info Hash
|
+--------+--------+
| | |
Tracker DHT PEX
| | |
+--------+--------+
|
获取 Peer
|
与多个 Peer 连接
|
请求文件 Piece
|
下载并校验数据
|
文件下载完成
|
继续做种
优点：
缺点：
DHT 的英文全称是 Distributed Hash Table，中文为分布式哈希表。
在 BitTorrent 中，DHT 主要用于在没有 Tracker 服务器的情况下发现 Peer。
BitTorrent Mainline DHT 使用基于 Kademlia 思想的分布式查找机制，相关规范为 BEP 5。
早期 BT 下载比较依赖 Tracker。
例如：
下载者
|
v
Tracker 服务器
|
v
返回 Peer IP 和端口
|
v
连接 Peer 下载文件
如果 Tracker 不可用，客户端可能无法通过它发现 Peer。
DHT 则把节点发现功能分散到大量参与网络的客户端中，降低对单一 Tracker 的依赖。
DHT 网络中的节点拥有自己的 Node ID。
常见的 Mainline DHT 使用 160 位节点标识。
网络使用 XOR 距离衡量两个标识之间的逻辑距离。
计算方式：
Distance(A, B) = A XOR B
这里的距离不是物理距离，也不是网络延迟，而是标识空间中的逻辑距离。
每个节点维护路由表，保存其他 DHT 节点的信息。
通过不断查询距离目标 Info Hash 更近的节点，客户端逐步找到可能知道相关 Peer 的节点。
第一步：加入 DHT 网络
客户端启动后，通过已知的 DHT 节点或 Bootstrap 节点加入网络。
第二步：建立路由表
客户端向其他 DHT 节点发送查询请求，逐渐建立自己的路由表。
第三步：查找资源
用户打开磁力链接后，客户端提取其中的 BTIH（BitTorrent Info Hash）。
第四步：执行迭代查询
客户端向 DHT 节点发送 get_peers 请求。
收到的响应可能包含：
第五步：连接 Peer
客户端得到 Peer 的 IP 和端口后，尝试建立 BT 连接。
第六步：通告自己
客户端可以通过 announce_peer 向 DHT 网络通告自己参与了对应资源的 Swarm。
| 消息 | 作用 |
|---|---|
| ping | 检查节点是否可达 |
| find_node | 查找接近目标 ID 的节点 |
| get_peers | 查找与 Info Hash 对应的 Peer |
| announce_peer | 通告自己正在参与某个资源的分享 |
DHT 常使用 UDP 传输查询消息。
| 对比项 | Tracker | DHT |
|---|---|---|
| 架构 | 集中式服务器 | 分布式节点网络 |
| 发现 Peer | 向 Tracker 查询 | 向 DHT 节点迭代查询 |
| 单点依赖 | 可能存在 | 较低 |
| 网络协议 | HTTP、HTTPS、UDP 等 | 通常 UDP |
| 私有种子 | 通常依赖指定 Tracker | 应遵守私有种子的禁用要求 |
DHT 不是用来存储整个电影、压缩包或软件文件的数据库。
它主要提供资源对应 Peer 的发现能力。
Magnet（磁力链接）是一种 URI 链接格式，用于标识资源。
它不是一个独立的文件传输协议。
磁力链接本身通常不包含完整的种子元数据，也不包含实际文件数据。
BitTorrent 客户端可以通过 Magnet 链接中的 Info Hash 定位资源，再使用 BT 协议进行数据传输。
假设用户获得以下磁力链接：
magnet:?xt=urn:btih:0123456789abcdef0123456789abcdef01234567&dn=example.zip
客户端执行以下操作：
其中，获取元数据通常依赖 BEP 9 所定义的 ut_metadata 扩展。
Magnet 磁力链接
|
提取 Info Hash
|
DHT / Tracker 查询
|
获取 Peer
|
建立 BitTorrent 连接
|
获取 Torrent 元数据
|
获取文件列表和大小
|
下载 Piece
|
哈希校验
|
下载完成
优点：
.torrent 文件缺点：
.torrent 文件是使用 Bencode 编码的数据结构。
Bencode 支持：
例如：
i123e
表示整数 123。
4:spam
表示字符串 spam。
l4:spam4:eggse
表示列表 ["spam", "eggs"]。
d3:cow3:moo4:spam4:eggse
表示字典：
{
"cow": "moo",
"spam": "eggs"
}
以下主要以 BitTorrent v1 为例。
| 字段 | 含义 |
|---|---|
| announce | Tracker 地址 |
| announce-list | Tracker 列表 |
| creation date | 种子创建时间 |
| comment | 种子备注 |
| created by | 创建种子的软件 |
| encoding | 文本编码相关信息 |
| info | 文件及校验元数据 |
| info.name | 文件或根目录名称 |
| info.piece length | 每个 Piece 的长度 |
| info.pieces | 所有 Piece 的 SHA-1 哈希串 |
| info.length | 单文件模式下的文件大小 |
| info.files | 多文件模式下的文件列表 |
| info.private | 私有种子标记 |
部分字段是可选的。
下面是为了方便理解而写的结构化示意，不是可以直接保存使用的 Bencode 文件。
{
"announce": "https://tracker.example.org/announce",
"creation date": 1790000000,
"created by": "qBittorrent",
"comment": "Example torrent",
"info": {
"name": "example.zip",
"piece length": 262144,
"length": 10485760,
"pieces": "<每个 Piece 的 20 字节 SHA-1 摘要依次拼接>"
}
}
其中：
name：资源名称length：文件总大小，单位为字节piece length：每个 Piece 的大小pieces：用于验证数据完整性的哈希值对于多文件种子，通常使用 files 列表记录文件路径及大小。
在 BitTorrent v1 中，Info Hash 是对 info 字典的原始 Bencode 编码计算 SHA-1 得到的哈希。
Torrent 文件
|
v
提取 info 字典的 Bencode 编码
|
v
SHA-1 计算
|
v
20 字节 Info Hash
|
v
通常表示为 40 位十六进制字符串
例如：
0123456789abcdef0123456789abcdef01234567
这个值可以用于标识 BT 资源。
需要注意，BitTorrent v2（BEP 52）使用 SHA-256 和 Merkle Tree 等不同的元数据及校验结构。
因此，不能把 v1 的 SHA-1 规则直接套用到所有种子上。
一个常见的 BitTorrent v1 Magnet 链接：
magnet:?xt=urn:btih:0123456789abcdef0123456789abcdef01234567&dn=example.zip&tr=https%3A%2F%2Ftracker.example.org%2Fannounce
拆解如下：
magnet:?
|
+-- xt=urn:btih:...
|
+-- dn=example.zip
|
+-- tr=https://tracker.example.org/announce
| 参数 | 全称 | 作用 |
|---|---|---|
| xt | Exact Topic | 资源的精确标识 |
| dn | Display Name | 建议显示名称 |
| tr | Tracker | Tracker 地址 |
| xl | Exact Length | 资源大小，单位为字节 |
| ws | Web Seed | Web 下载源 |
| as | Acceptable Source | 可接受的资源来源 |
| xs | Exact Source | 精确资源来源 |
其中最重要的是 xt。
例如：
xt=urn:btih:0123456789abcdef0123456789abcdef01234567
这里的 btih 代表 BitTorrent Info Hash。
BitTorrent v1 的 BTIH 可以采用 40 位十六进制或 32 位 Base32 表示。
BitTorrent v2 则可以使用 urn:btmh: 多哈希标识。
| 对比项 | Torrent | Magnet |
|---|---|---|
| 表现形式 | 文件 | URI 链接 |
| 是否包含完整元数据 | 通常包含 | 通常不包含 |
| 是否包含文件列表 | 通常包含 | 通常需要后续获取 |
| 是否必须包含 Tracker | 否 | 否 |
| 是否可以使用 DHT | 可以 | 可以 |
| 能否直接传输文件内容 | 不能，依赖 BT 客户端 | 不能，依赖 BT 客户端 |
| 初次解析速度 | 通常较快 | 可能需要等待元数据 |
总结：Torrent 更像资源说明书，Magnet 更像指向资源的标识。实际文件传输仍然由 BitTorrent 等机制完成。
以分享自己拥有版权或授权分发的文件为例。
步骤一：准备资源
例如：
/home/user/share/
|
+-- linux-image.iso
+-- README.txt
步骤二：打开 qBittorrent
进入：
工具 → Torrent 创建器
不同版本的菜单名称可能略有区别。
步骤三：选择文件
可以选择单个文件，也可以选择整个文件夹。
步骤四：设置 Tracker
如果使用公开 Tracker，可以填入对应的 Announce URL。
如果使用无 Tracker 的公开种子，可以在允许的情况下依靠 DHT 进行节点发现。
步骤五：设置种子参数
常见选项包括：
步骤六：创建种子
生成：
linux-image.torrent
步骤七：开始做种
确保客户端可以访问原始文件，并保持上传服务运行。
创建 .torrent 文件不等于把实际文件上传到了网络。
至少需要有能够提供文件数据的在线 Peer。
在 Linux 上，可以使用支持创建 Torrent 的命令行工具，例如 mktorrent。
安装示例：
sudo apt install mktorrent
创建带 Tracker 的种子：
mktorrent \
-a "https://tracker.example.org/announce" \
-o linux-image.torrent \
/home/user/share/linux-image.iso
其中：
-a：指定 Tracker-o：指定输出种子文件tracker.example.org 是示例地址，不是真实可用的 Tracker 服务。
创建种子后，需要使用 BT 客户端加载该种子并提供原始文件，才能供其他用户下载。
最简单的方法是使用 qBittorrent。
操作流程：
.torrent 文件。如果已知 BitTorrent v1 的 Info Hash，可以构造：
magnet:?xt=urn:btih:0123456789abcdef0123456789abcdef01234567
也可以加入文件名：
magnet:?xt=urn:btih:0123456789abcdef0123456789abcdef01234567&dn=example.zip
还可以加入 Tracker：
magnet:?xt=urn:btih:0123456789abcdef0123456789abcdef01234567&dn=example.zip&tr=https%3A%2F%2Ftracker.example.org%2Fannounce
注意：Tracker URL 需要进行 URL 编码。
可以使用 Python 和 Bencode 库解析 Torrent。
安装：
python3 -m pip install bencodepy
示例代码：
import hashlib
import bencodepy
torrent_path = "linux-image.torrent"
with open(torrent_path, "rb") as f:
torrent_data = f.read()
torrent = bencodepy.decode(torrent_data)
info = torrent[b"info"]
info_encoded = bencodepy.encode(info)
info_hash = hashlib.sha1(info_encoded).hexdigest()
magnet = f"magnet:?xt=urn:btih:{info_hash}"
print("Info Hash:", info_hash)
print("Magnet:", magnet)
这段代码适用于常见的规范编码 BitTorrent v1 种子。
严格来说，v1 Info Hash 应当根据种子中 info 字典的原始 Bencode 字节计算，而不是任意重新编码后的结果。对于非规范编码种子，重新编码可能改变哈希。
对于纯 v2 种子，需要使用 BEP 52 对应的计算方式。
只要拥有正确的 Info Hash，就可以构造资源标识链接。
但这不意味着资源一定能够下载。
资源是否可以下载，还取决于：
定位：开源 BitTorrent 下载客户端。
主要特点：
适用平台包括 Windows、Linux 和 macOS。
适合人群： 希望使用标准 BT 功能、重视可控性和透明度的用户。
官方网站：
定位：面向 macOS 的下载管理软件。
主要特点：
Folx 更偏向综合下载管理，而不是专门面向高级 BT 用户的工具。
适合人群： 使用 macOS，希望在一个应用中管理普通下载和 BT 下载的用户。
官方网站：
https://www.electronic.us/products/folx/
定位：综合下载工具及相关加速服务平台。
主要特点：
某些商业软件的部分功能与使用体验会因客户端版本、会员状态及服务策略而变化。
适合人群： 更重视便捷性、云端功能及综合下载体验的用户。
官方网站：
定位：基于 P2P 技术的文件同步软件。
Resilio Sync 与传统 BT 下载客户端有所不同。
它主要用于：
例如：
电脑 A
|
| P2P 同步
|
电脑 B
|
| P2P 同步
|
NAS
Resilio Sync 使用与 BitTorrent 相关的 P2P 技术思想，但它不是用来直接下载公共 Magnet 链接的通用 BT 客户端。
它通常通过共享密钥、链接或授权机制建立同步关系。
适合人群： 希望在电脑、NAS 和其他设备之间同步文件的用户。
官方网站：
| 软件 | Torrent | Magnet | 主要用途 | 开源 |
|---|---|---|---|---|
| qBittorrent | 支持 | 支持 | 标准 BT 下载 | 是 |
| Folx | 支持 | 支持 | macOS 综合下载 | 否 |
| 某些商业软件 | 支持 | 支持 | 综合下载与加速服务 | 否 |
| Resilio Sync | 非通用 BT 下载用途 | 非通用 BT 下载用途 | P2P 文件同步 | 否 |
推荐：
日常 BT 下载优先考虑 qBittorrent；macOS 综合下载管理可考虑 Folx；多设备文件同步则更适合 Resilio Sync。
某些商业软件在部分 BT 社区中的争议主要来自以下方面。
BitTorrent 的核心思想之一是用户之间相互分享数据。
理想状态：
Peer A <----> Peer B
^ ^
| |
v v
Peer C <----> Peer D
每个节点既可以下载，也可以上传。
某些商业软件则是商业化下载产品，提供加速、云端服务等功能。
部分用户认为，其商业服务模式与传统 BT 社区强调的互惠分享理念存在冲突。
不过，商业化本身并不违反 BitTorrent 协议。
在 BT 社区中，所谓“吸血客户端”，通常指被认为大量下载却很少向其他 Peer 回传数据的客户端。
某些商业软件历史上曾受到此类批评。
争议包括：
需要强调的是：
不能仅凭某个用户上传量较低，就认定客户端违反 BT 协议。
上传量受到做种时间、网络连接、资源热度、上传限速及 Peer 需求等多种因素影响。
对于某些商业软件具体版本是否存在不公平行为，需要通过可重复的网络抓包和协议测试验证。
qBittorrent 等开源客户端允许开发者检查实现方式。
某些商业软件是闭源商业软件。
因此，外部用户难以直接审计全部下载调度、资源发现、云端交互和数据处理逻辑。
这可能降低部分技术用户对其透明度的信任。
但闭源并不直接意味着软件不安全。
部分用户不满的原因包括：
这些属于产品体验和商业模式方面的争议，并非 BitTorrent 协议本身的问题。
普通 BT：
用户客户端
|
+---- Peer A
|
+---- Peer B
|
+---- Peer C
云端下载或加速可能涉及：
用户客户端
|
v
云端服务
|
+---- 资源缓存
|
+---- 其他下载来源
|
+---- P2P 网络
具体架构取决于服务提供商的实现。
云端服务可能提高某些资源的下载体验，但也引入服务依赖、隐私和收费方面的权衡。
某些商业软件并不是因为商业化就必然违反 BT 协议，也不能笼统认定所有某些商业软件版本都是“吸血客户端”。
更准确的评价是：
某些商业软件在历史上因 P2P 分享公平性、客户端透明度、广告和会员模式等问题受到部分用户批评。
而 qBittorrent 因开源、功能完整和可控性较强，在技术用户中通常更受青睐。
常见原因：
磁力链接中只有资源标识时，客户端需要先获取元数据才能显示完整文件列表。
可能原因：
Peer 数量不等于有效上传者数量。
因为 BitTorrent 依赖其他节点提供数据。
如果所有人下载完成后立即退出，资源可能逐渐失去可用的完整副本。
做种可以：
不是。
在普通公开 BT 网络中，其他 Peer 通常可以看到连接方的公网 IP 地址和端口。
DHT 也不提供匿名性保证。
因此，BT 是一种分布式传输技术，不是匿名网络。
BT 协议具有数据完整性校验机制，但并不能保证下载内容安全。
例如：
哈希验证主要保证下载数据与种子描述一致，不负责判断文件是否可信。
| 规范 | 内容 |
|---|---|
| BEP 3 | BitTorrent v1 协议 |
| BEP 5 | DHT 协议 |
| BEP 9 | 扩展协议元数据交换 |
| BEP 10 | BitTorrent 扩展协议 |
| BEP 19 | WebSeed |
| BEP 23 | Tracker 返回紧凑 Peer 列表 |
| BEP 27 | 私有种子 |
| BEP 29 | uTP 传输 |
| BEP 52 | BitTorrent v2 |
官方技术文档：
https://www.bittorrent.org/beps/bep_0003.html
https://www.bittorrent.org/beps/bep_0005.html
https://www.bittorrent.org/beps/bep_0009.html
https://www.bittorrent.org/beps/bep_0010.html
https://www.bittorrent.org/beps/bep_0052.html
BitTorrent、DHT 和 Magnet 三者之间的关系可以概括为：
BitTorrent
文件传输协议
|
+-------+-------+
| |
Torrent Magnet
种子文件 磁力链接
| |
+-------+-------+
|
Info Hash
|
+-------+-------+
| |
Tracker DHT
| |
+-------+-------+
|
发现 Peer
|
建立 P2P 连接
|
下载元数据
（如需要）
|
下载 Piece
|
校验完整性
|
完成下载
|
继续做种
核心知识点：
一句话理解：
Torrent 告诉客户端资源是什么，Magnet 提供资源标识，Tracker 和 DHT 帮助寻找其他节点，而 BitTorrent 负责实际的数据交换。
iThome鐵人賽
看影片追技術