A .torrent file and a 磁铁 link are two ways of giving a BitTorrent client the same thing: the identity of a torrent.
- .torrent 文件是一个“元信息”文件。 它的信息字典包含片段长度、文件名和长度（或文件列表），以及在 v1 版本中，一个由 20 字节 SHA-1 哈希值组成的连接列表，每个片段对应一个哈希值。信息哈希值是对 ben 编码后的信息值进行 20 字节 SHA-1 哈希处理的结果，计算时完全按照 .torrent 文件中的编码形式进行。Tracker URL 位于该字典之外，因此可以更改它们而不会改变种子文件的身份。BitTorrent v2 (BEP 52) 更改了哈希算法：它使用 SHA-256，并为每个文件设置 Merkle 树和分层文件树。每个文件的“片段层”位于信息字典之外，并且实现方式如下： 必须 检查它们是否与其中的根域对应。bep 0003 +2
- 磁力链接不包含任何元数据，只包含该身份信息。 其格式为 magnet:?xt=urn:btih:（v1）或 xt=urn:btmh:（v2），可选参数包括显示名称 (dn)、tracker (tr) 和 peer-address (x.pe)。混合种子文件可以在一个链接中同时包含 btih 和 btmh 主题。首先，客户端使用 BEP 9 扩展从其他 peer 获取元数据。此扩展仅传输 .torrent 文件中的信息字典部分，每个数据块大小为 16 KiB。然后，客户端将其与链接中的哈希值进行比对。如果链接中未指定 tracker，客户端应使用 DHT 算法查找 peer。bep 0009 +2
因此，这两种格式指向同一个集群，下载一旦开始就会进行相同的下载。它们的区别在于元数据的来源：
.torrent 文件是一个静态产物：文件列表立即可知，元数据在集群死亡后仍然存在，并且该文件必须托管在某个地方。
磁力链接是一小段可以粘贴到任何地方的字符串，但它只有在至少有一个可访问的对等节点仍然拥有元数据时才能生效。这两种格式都无法验证发布者的身份，也无法确认内容是否与其标签匹配。哈希值只能证明数据与哈希值匹配。
提示： 应广大用户要求，本文旨在为我们所有关于工程领域种子下载和 P2P 下载的文章提供支持。
历史背景
.torrent 格式源自最初的 BitTorrent 设计。Bram Cohen 于 2001 年 4 月设计了该协议，并于 2001 年 7 月 2 日发布了第一个版本。他和 Ashwin Navin 于 2004 年创立了 BitTorrent 公司（后更名为 Rainberry 公司）。Cohen 也是 BEP 3 的署名作者，BEP 3 是定义元信息文件和信息哈希的核心规范。后续开发工作通过 BitTorrent 增强提案流程进行协调，该流程借鉴了 Python 的 PEP（程序增强提案）模式。Cohen 希望主线客户端保持开源。
BEP 3规范是最接近正式权威的资料。 文件格式v2 格式出现得晚得多：BitTorrent 公司于 2017 年 5 月 15 日发布了 v2 规范。磁力链接的起源则有所不同。magnet: 方案并非为 BitTorrent 而发明。它的设计初衷是作为一种与项目无关的方式，用于在多个 P2P 网络中通过内容哈希值识别文件。IANA 仅将其列为临时方案，并于 2012 年由 Magnet-URI 项目注册。一些二手资料将其引入时间追溯到 2002 年，但我没有找到任何支持该日期的原始资料。BitTorrent 对磁力链接的使用基于 BEP 9，该规范由 Greg Hazel 和 Arvid Norberg 编写（Norberg 也是 libtorrent 的原作者）。 BEP 9 目前仍只是“已接受”，而非最终版本，并且它在 2016 年获得了 x.pe 对等地址参数。该 BEP 定义了元数据交换协议和 BitTorrent 磁力链接格式，但一位实现者的笔记将磁力链接 URI 描述为事实上的约定，而不是一个编号的 BEP。
实际上，这两种模式都取决于BEP流程以及主要客户的实施情况，而不是取决于正式的协议。 标准 身体。
1. 基本原理
| 方面 | .torrent 文件 | 磁力链接 |
|---|---|---|
| 它是什么 | 一个小型二进制文件（bencoded字典） | 文本 URI（magnet:?xt=urn:btih:…） |
| 包含内容吗？ | 不，只有元数据 | 不，只是一个标识符 |
| 核心内容 | 追踪器 URL、文件名和大小、片段长度、每个片段的哈希值、可选注释、创建者和日期 | 信息哈希 (xt)、可选显示名称 (dn)、跟踪器 (tr)、对等地址 (x.pe)；Web 种子 (ws) 仅作为客户端相关的扩展，未在 BEP 9 中定义。 |
| 典型尺寸 | 几KB到几MB（随内容大小增长） | 大约 100-500 字节 |
| 使用的标识符 | SHA-1 信息哈希（v1）、SHA-256（v2）或两者兼有（混合） | 相同的信息哈希： 瓮:btih (v1) 或 urn:btmh (v2) |
| 规格 | BEP 3 (v1)、BEP 52 (v2) | BEP 9（元数据交换和磁性 URI 格式） |
| 协议处理程序 | 通过文件关联（.torrent）打开 | 由操作系统或浏览器磁力链接打开：URI 处理程序 |
2. 元数据和文件信息
| 方面 | .torrent 文件 | 磁力链接 |
|---|---|---|
| 下载开始前可以看到文件列表 | 是的，立即 | 不，只有在从对等节点获取元数据之后。 |
| 元数据源 | 嵌入在文件中 | 通过 ut_metadata 从对等节点（DHT、PEX、trackers）下载 |
| 元数据完整性 | 经哈希验证 | 已根据链接中的信息哈希值进行验证，因此篡改的元数据会被拒绝。 |
| 启动延迟 | 没有任何 | 几秒到几分钟（或者永远不会，如果没有任何对等方拥有元数据） |
| 显示名称 | 存储在文件（名称）中 | dn 是可选的且未经验证；它只是一个标签。 |
| 碎片哈希 | 包括 | 稍后通过元数据获得 |
| 可编辑 | 无需更改哈希值即可编辑 Tracker。编辑信息字典会更改信息哈希值，从而创建不同的种子文件。 | 以文本形式编辑非常简单（添加或删除跟踪器）。信息哈希值无法更改，除非指向不同的内容。 |
3. 作者、来源和真实性
| 方面 | .torrent 文件 | 磁力链接 |
|---|---|---|
| 作者信息 | 可选字段：创建者（客户端和版本）、创建日期、评论 | 无；没有标准作者字段 |
| 关于创建者的元数据泄露 | 可能包含（客户端版本、时间戳，有时还包括注释或 URL） | 内容极简；链接仅包含分享者提供的内容。 |
| 数字签名 | 虽然存在签署延期条款（BEP 35），但很少使用。 | 没有任何 |
| 标签上的内容就是最好的证明。 | 没有，而且名字可以伪造。 | 没有，而且 dn 可以伪造。 |
| 证明内容与哈希值匹配 | 是的，每一件商品都经过哈希验证。 | 是的，每条元数据之后都会进行哈希验证。 确认 |
| 信任模型 | 您信任提供文件的人，然后根据哈希值验证数据。 | 你信任提供链接的人，然后用同样的方法进行验证。 |
| 欺骗风险 | 标题相同的虚假种子文件很常见。 | 同样，而且链接中的上下文信息更少（没有文件列表可供先查看）。 |
4. 托管、分发和可用性
| 方面 | .torrent 文件 | 磁力链接 |
|---|---|---|
| 需要托管 | 是的，可以是网络服务器、索引站点或文件共享。 | 不，它只是文本，可以粘贴到任何地方。 |
| 分享方法 | 下载、电子邮件附件、文件传输（附件有时会被阻止） | 聊天记录、电子邮件正文、二维码、论坛帖子、笔记应用 |
| 曝光 | 托管文件可以被删除或屏蔽 | 纯文本内容更难删除，但发布这些内容的网站仍然可以被屏蔽。 |
| 链接失效 | 文件与主机同存。 | 文本仍然存在，但如果没有对等节点仍然拥有元数据，那么它就毫无用处了。 |
| 存档价值 | 优点：即使集群死亡，也能保留完整的元数据。 | 低：它依赖于活的集群来检索元数据 |
| 索引和搜索网站 | 每个种子文件必须存储一个文件（需要更多存储空间） | 只存放一小段绳子（更便宜，也更容易镜像）。 |
| 跨设备便利性 | 需要文件传输 | 很简单：复制粘贴，或者扫描二维码 |
| 浏览器行为 | 下载文件，然后在客户端中打开它。 | 触发协议处理程序提示（需要已注册的客户端） |
5. 网络行为和性能
| 方面 | .torrent 文件 | 磁力链接 |
|---|---|---|
| 同伴发现 | 文件中所列的追踪器，以及 DHT、PEX 和 LSD（除非是私有的） | DHT、PEX 和 LSD，以及链接中的任何 tr 追踪器 |
| 无需任何追踪器即可工作 | 只有当DHT被允许时才行。 | 是的，使用DHT（这是它的常用模式） |
| 对二氢睾酮的依赖 | 选修的 | 通常对元数据和对等节点至关重要 |
| Web种子（HTTP源） | url-list / httpseeds 字段（BEP 19） | ws= 参数，一个客户端相关的扩展，未在 BEP 9 中定义。 |
| 下载速度（运行时） | 完全相同的 | |
| 对已失效或稀有种子文件的行为 | 启动并等待同伴 | 可能在“检索元数据”处停滞 |
| 私人追踪器 | 完全支持（私有标志，通行密钥在公告 URL 中） | 通常无法使用。私有种子会禁用 DHT/PEX，而且 tracker 密码不会在共享链接中公开。 |
6. 安全性
| 方面 | .torrent 文件 | 磁力链接 |
|---|---|---|
| 恶意软件风险来源 | 下载的内容，而非格式。 | 下载的内容，而非格式。 |
| 解析器或处理程序风险 | 格式错误的 bencode 可能会在编写不佳的客户端中引发错误（这种情况很少见）。 | 恶意 DN 或 URI 参数可能会导致编写不佳的客户端或处理程序出现注入或显示错误（这种情况很少见）。 |
| 下载前可进行检查 | 高级：您可以首先看到文件列表、扩展名和大小。 | 元数据到达之前，文件大小会比较低；大多数客户端会在下载前允许您查看文件列表。 |
| 伪装的可执行文件 | 可在文件列表中检测到（.exe、.scr、.lnk 等） | 同样，但仅在获取元数据之后才适用。 |
| 网络钓鱼和广告风险 | 种子网站通常广告很多。 | 同样，还会误触外观相似的磁性按钮。 |
| 哈希强度 | v1 版本使用 SHA-1 算法（理论上碰撞风险较低，难以被 BT 下载利用）；v2 版本使用 SHA-256 算法。 | 与它指向的种子文件相同的哈希值 |
| 运输途中篡改 | 通过片段哈希值检测 | 虽然通过信息哈希检测到了问题，但交换后的链接指向了完全不同的内容。 |
7. 隐私和匿名
| 方面 | .torrent 文件 | 磁力链接 |
|---|---|---|
| 您的 IP 地址对其他用户可见。 | 是的 | |
| 您的 IP 地址对追踪器可见 | 是的（嵌入式追踪器） | 是的，如果包含 tr 跟踪器的话。 |
| 二氢睾酮暴露 | 可能的 | 几乎可以肯定；你的查询会流向公共的DHT数据库。 |
| 匿名差异 | 无意义 | |
| 元数据揭示了分享者 | 创建者、评论和创建日期可以揭示详细信息 | 链接文本之外没有任何其他内容 |
| 缓解措施 | VPN 或 代理人客户端 加密私人追踪器 | |
8. 风险和局限性
| 风险 | .torrent 文件 | 磁力链接 |
|---|---|---|
| 无与伦比的摊位 | 等待同伴 | 可能永远无法获得元数据 |
| 虚假或错误标记的内容 | 可能的 | |
| 法律风险 | 取决于内容和司法管辖区。托管文件可能会为网站运营者带来更多曝光机会。 | 这取决于内容和司法管辖区。分享链接有时与托管文件的处理方式不同，但这因情况而异，而且并非绝对安全。 |
| 隐私泄露 | 跟踪器和同行可见性 | DHT 和同伴可见性 |
| 追踪者死亡 | 降低了发现率，但DHT可能仍然有效。 | 如果该链接依赖于DHT，那就没问题。 |
| 长期耐用性 | 更好的 | 更糟 |
| 拼写错误和截断 | 检测到损坏的文件 | 哈希值中的拼写错误会导致链接失效，而截断的链接则会悄无声息地失效。 |
9. 兼容性和易用性
| 方面 | .torrent 文件 | 磁力链接 |
|---|---|---|
| 客户支持 | 普遍的 | 现代客户端通用（需要 BEP 9） |
| 种子盒和网络服务 | 普遍支持 | 大部分服务都支持，但一些较旧的服务仅接受文件。 |
| 移动友好性 | 中等（处理下载的文件比较笨拙） | 高的 |
| 自动化（RSS（脚本、API） | 直截了当 | 此外，操作简便，也更易于存放。 |
| 人类可读性 | 不用工具无法读取 | 哈希值是不透明的，但其结构是可读的。 |
10. 如何创建 .torrent 文件和磁力链接
标有匕首的物品是我个人的推断或常识，未经任何来源证实。
| 方面 | .torrent 文件 | 磁力链接 |
|---|---|---|
| 起始输入 | 您的实际文件或文件夹，以及一个创建工具（例如 mktorrent，或客户端的“创建种子”功能） | 已存在的 info-hash。在 v1 版本中，它是 bencoded info 字典的 SHA-1 值，因此磁力链接不能在 .torrent 元数据存在之前存在。 |
| 步骤顺序 | 1) 选择片段长度。2) 对每个片段进行哈希处理。3) 构建信息字典。4) 添加外部字段，例如跟踪器。5) 进行 Bencode 编码并保存。 | 1) 获取种子文件。2) 获取其信息哈希值。3) 使用 xt 写入 URI。4) （可选）添加 dn、tr 和 x.pe。 |
| 件长 | 由您自行选择。它几乎总是 2 的幂，最常见的是 256 KiB。mktorrent 默认设置为 2^18 字节，您可以使用 -l 参数进行设置。 | 没有；它是从种子流继承而来的。 |
| 哈希工作 | 每个字节都会被哈希处理：v1 版本使用 SHA-1 哈希算法，v2 版本使用 SHA-256 哈希算法生成每个文件的 Merkle 树。处理时间随数据大小（dagger）增加，mktorrent 可以使用多个线程。 | 可忽略不计：除了现有的哈希值之外，没有其他变化 |
| 追踪器 | 公告，或公告列表。该列表位于信息部分之外；如果存在，兼容的客户端将忽略公告，并按顺序尝试各个层级，同一层级内的 URL 顺序会打乱。 | URI 中的 tr 参数。如果未提供任何参数，客户端应使用 DHT。 |
| 私人旗帜 | 通过在信息字典中设置 private=1 来启用此功能。符合规范的客户端将仅向私有 Tracker 广播信息，并仅连接到它返回的对等节点。由于此设置位于内部信息中，因此会影响信息哈希（Dagger）。 | 链接中没有对应的字段。该标志位存在于元数据中，客户端只有在获取元数据后才能看到（使用 Dagger）。 |
| 网络种子 | 根据 BEP 19，URL 列表由 mktorrent 以 -w 参数公开。HTTP/FTP 服务器充当永久开放的种子。 | ws= 不是 BEP 9 参数列表的一部分。请将其视为客户端相关的扩展。 |
| 可选的描述性字段 | 注释和创建日期是可选的。mktorrent 提供 -c 参数用于添加注释，-d 参数用于省略日期。 | 仅显示名称 (dn)。这是一个标签，未经验证。 |
| 源标签 | mktorrent-s 参数会在信息哈希中嵌入源字符串，因此，即使同一个文件带有不同的标签，也会获得不同的哈希值和不同的种子群。 | 不适用 |
| 什么会改变身份 | 内部信息：名称、片段长度、私有标志、源标签、文件列表（dagger） | 更改 xt 指向不同的种子。更改 dn、tr 或 x.pe 则不会。 |
| 哈希版本选择 | 创建时选择 v1 (SHA-1)、v2 (SHA-256) 或混合算法。 | 对于混合种子，链接必须包含 btih、btmh 或两者（BEP 9 允许在一个磁力链接中同时包含这两个主题，如果它们描述的是同一个混合种子）。 |
| 签名 | BEP 35 允许在文件中嵌入 RSA 签名，可以选择使用 X.509 证书，并且每个种子文件可以有多个签名。它很少被使用（dagger）。 | BEP 9 没有定义签名域，因此无需签名。 |
| 输出 | 一个大小在 KB 到 MB 之间的二进制文件，您必须托管或发送该文件。 | 一行几百字节的文本 |
| 使其可用 | 上传文件，并使用原始数据运行客户端，以便进行数据填充。 | 发布该链路，并继续做种。如果没有对等节点拥有数据和元数据，则该链接无效。 |
| 典型错误 | 内容大小与文件大小不匹配（dagger）；发布前忘记设置私有标志，因为之后更改会导致生成新的哈希值（dagger）；添加了错误的 Tracker。 | 哈希值中存在拼写错误或截断，导致链接指向无效位置（†）；前缀错误（btih 而非 btmh）；dn 中包含未转义的特殊字符（†）。 |
11. 使用每一个
标有匕首的物品是我个人的推断或常识，未经任何来源证实。
| 方面 | .torrent 文件 | 磁力链接 |
|---|---|---|
| 如何打开它 | 双击文件关联，将其拖入客户端，或使用“添加种子文件” | 点击磁力链接（需要注册处理程序），将其粘贴到客户端，或扫描二维码（dagger） |
| 客户首先要做什么 | 解析 ben 编码的元信息 | 解析 URI 并提取信息哈希 |
| 元数据来源 | 文件里已有内容 | 对等节点通过 BEP 9 扩展以 16 KiB 的数据块形式发送信息字典（仅包含 .torrent 文件中的这部分内容），客户端将其与哈希值进行比对。 |
| 寻找同伴 | 文件中包含 Tracker 信息，除非种子文件是私有的，否则不会使用 DHT/PEX/LSD。对于私有种子文件，不应使用 DHT 和 PEX。 | 链接中的追踪器；如果没有，则为 DHT |
| 启动延迟 | 没有任何 | 等待拥有元数据的对等节点响应，因此可能会无限期地停滞不前。 |
| 下载前请选择文件 | 立即地 | 元数据到达后。有些客户端可以仅获取元数据，以便在下载前预览文件列表。 |
| 行动前先检查 | 使用任何解析工具进行离线全面检查 | 在获取元数据之前无法实现。 |
| 它们之间的转换 | 计算信息哈希并写入磁力链接（dagger）。 | 获取到的元数据可以导出并缓存为种子文件，因此同一个磁力链接无需再次下载元数据。 |
| 私有追踪器使用 | 之所以有效，是因为该文件包含跟踪器 URL，客户端必须限制自己使用该 URL（BEP 27）。 | 可能不切实际：该链接没有标记，而且追踪器 URL 可能包含个人凭证（dagger）。BEP 27 没有讨论磁力链接。 |
| 编辑 | 添加或移除追踪器无需更改哈希值，因为它们位于信息部分之外。编辑信息会创建一个新的种子文件。 | 您可以随意编辑文本；更改 xt 会改变它是哪个种子文件。 |
| 检查真伪 | 使用您信任的证书验证 BEP 35 签名。某个库指出，其检查并不验证证书本身。否则，请检查文件列表。 | 请将此信息哈希值与来自可信来源的哈希值进行比较；没有其他可用信息。 |
| 自动更新 | BEP 39 允许创建者在信息字典中放置更新 URL，客户端只有在种子文件由创建者签名后才会自动下载更新的种子文件。 | 没有任何 |
| 分享继续 | 发送或托管文件 | 复制并粘贴该行 |
| 当它失败时 | Tracker 已失效或无对等节点：客户端等待。损坏的文件将被拒绝。 | 哈希值拼写错误或没有可达对等节点：卡在“正在检索元数据”处 |
| 网络种子救援 | 即使没有对等节点，带有网络种子的 .torrent 文件仍然可以正常工作。磁力链接没有类似的功能，因为 BEP 9 和 HTTP 种子 BEP 都没有提供从 HTTP 种子中获取元数据的方法。 | |
| 下载后 | 继续从相同的文件进行种子上传 | |
概括
Torrent 文件（.torrent）最适合用于存档、私有 Tracker、先查看文件列表、离线元数据，而磁力链接则擅长快速共享、二维码、独立于 Tracker 的分发、最小托管。
两种格式本身并无绝对的安全性可言。它们都通过加密技术验证数据完整性，但都无法验证内容的发布者身份或内容的真实内容。真正的安全和法律风险来自内容本身及其来源，因此请检查文件列表是否存在可疑的扩展名，并谨慎对待链接来源。
常问问题
BitTorrent 是 IETF 还是 ISO 标准？.torrent 文件和磁力链接的正式程度如何？
不。该协议通过 BitTorrent 增强提案 (BEP) 进行规范，这一过程仿照 Python 的 PEP。BEP 3 定义了元信息格式，BEP 52 定义了 v2 版本。BEP 9 涵盖元数据交换和 BitTorrent 磁力链接格式，其状态为“已接受”，而非“最终”。magnet: 方案本身只是 IANA 的临时注册，由 Magnet-URI 项目创建。实际上，互操作性由主流客户端库定义，因此需要针对多个实现进行测试。
信息哈希是否以加密方式将种子文件与其内容绑定？
从传递意义上讲，是的。v1 的信息哈希值是 ben 编码信息字典的 SHA-1 哈希值，而该字典包含每个数据块的 SHA-1 哈希值，因此该哈希值与数据本身是一致的。需要注意的是 SHA-1 的抗碰撞性较弱：实际中确实存在碰撞，因此，如果发布者同时制作了种子文件的两个变体，则可以使用同一个哈希值构造两个有效载荷。针对现有种子文件的第二原像攻击仍然不可行。v2 版本改用 SHA-256，消除了这一隐患。
哪些编辑会改变种子文件的身份，哪些不会？
信息字典中的任何内容都会更改信息哈希值：名称、文件列表、片段长度、私有标志以及源标签（例如 mktorrent 的 -s 选项）。信息字典之外的字段，例如 announce 和 announce-list（BEP 12），可以自由编辑，而无需创建新的种子。在磁力链接中，dn、tr 和 x.pe 不会影响种子标识；只有 xt 会影响。更改信息字典会静默地 fork 种子群，因此请将其视为发布新种子。
客户端如何验证通过磁力链接接收的元数据？
对等节点通过 BEP 9 ut_metadata 扩展以 16 KiB 数据块的形式发送信息字典，客户端对组装后的结果进行哈希处理，并将其与链路中的信息哈希值进行比较。除非攻击者能够破解哈希值，否则伪造的元数据将被拒绝。这证明的是相对于链路的完整性，而非真实性。dn 值是一个未经验证的标签，哈希值也无法说明内容的发布者或内容的真实性。
v1、v2 和混合种子之间有哪些实际区别？
v1 在信息字典中使用 SHA-1 片段哈希值的扁平列表。v2（BEP 52）使用 SHA-256，并为每个文件构建 Merkle 树和分层文件树。片段层位于信息字典之外，实现必须将其与信息字典内部的片段根字段进行比对。混合种子同时包含这两种结构，因此有两个信息哈希值，磁力链接也可能同时包含 btih 和 btmh 主题。在发布仅支持 v2 的种子之前，请确保您的客户端和工具支持 v2。
当没有其他用户连接但存在HTTP Web种子时，磁力链接能否引导下载？
不。BEP 9 仅从对等节点获取元数据，BEP 9 和 HTTP 种子 BEP（17、19）均未定义从 HTTP 种子获取元数据的方法。即使没有对等节点，带有 Web 种子的 .torrent 文件仍然可以工作，因为元数据已包含在文件中。如果您依赖 Web 种子来保证可用性，请分发 .torrent 文件，而不仅仅是磁力链接。
每种格式会泄露我的隐私和网络身份的哪些信息？
两者都会将您的 IP 地址暴露给其他用户以及您发布的任何 Tracker 服务器。磁力链接通常依赖于公共 DHT，这会增加一条额外的查找路径，您的 IP 地址和信息哈希值都会出现在这条路径上。协议加密可以混淆流量，但并不能匿名化您的身份。私有种子（BEP 27）要求客户端只能使用私有 Tracker 服务器，因此不使用 DHT 和 PEX。对于匿名性要求，应使用具有适当网络级缓解措施的威胁模型，而不是选择特定的格式。
如何验证通过种子下载获得的数据的真实性，而不仅仅是完整性？
片段验证仅能证明数据与种子文件匹配。为了确保真实性，需要通过独立的、可信的渠道获取校验和或签名（例如已签名的 SHA-256 清单），并以此验证最终文件。BEP 35 定义了嵌入在 .torrent 文件中的 RSA 签名，支持可选的 X.509 证书和多个签名者，但很少被部署，而且实现该规范的库也指出，其验证机制并不能验证证书本身。磁力链接则完全没有签名机制。
创建种子文件时，我应该如何选择文件长度？
这是元数据大小和传输粒度之间的一种权衡。BEP 3 规定，数据块长度几乎总是 2 的幂，通常为 256 KiB，这也是 mktorrent 的默认值。在 v1 版本中，一个 100 GiB 的有效载荷，如果数据块大小为 256 KiB，则包含 409,600 个数据块，因此仅数据块字符串就大约有 8 MB。磁力链接客户端必须在启动前拉取整个字典（大约 500 个数据块），因此过大的元数据会减慢磁力链接的启动速度。较大的数据块会缩小元数据，但会使失败数据块后的修复更加粗糙。
为什么两股相同的数据洪流最终会形成不同的集群，我该如何避免这种情况？
因为信息哈希涵盖了整个信息字典。不同的文件名、文件顺序、片段长度、私有标志或源标签，即使是字节相同的有效载荷，也会产生不同的哈希值。为了保持群体的一致性，请在发布过程中标准化片段长度、文件名、文件顺序和标志，并将信息哈希与工件一起发布。源标签是一种有意区分群体的方法，而 mktorrent 的 -s 选项会故意更改哈希值。
为这些格式编写客户端或解析器时，主要存在哪些安全隐患？
将所有输入视为不可信。严格验证 bencode，限制元数据大小（一个开源客户端强制执行 32 MB 的限制），并对元数据中的文件路径进行清理，以防止目录遍历。过滤 Tracker 和 DHT 返回的私有地址和环回地址，以限制 SSRF 式滥用，并在连接前检查 Tracker URL 是否可接受。将 DN 视为不可信文本，并在将其写入最终存储之前验证每个部分的哈希值。
如何从 .torrent 文件中正确计算信息哈希值？
找到文件中信息值对应的确切字节范围，并对这些字节进行哈希运算：v1 使用 SHA-1，v2 使用 SHA-256。BEP 3 强调哈希值必须基于文件中的编码。只有当解码器完全验证了输入时，解码和重新编码字典才是安全的；而宽松的解码器可能会悄悄地规范化数据，从而产生不同的哈希值。对于混合种子文件，应从同一字节范围计算两个哈希值。
我可以使用磁力链接下载私有种子吗？
通常情况下，这样做并不实际。BEP 27 要求客户端只能向私有 Tracker 发出通告，并且只能连接到它返回的对等节点。裸磁力链接不包含私有标志，因为该标志存在于元数据中，而且磁力链接可能不包含可用的 Tracker URL。如果链接中嵌入了带有凭据的 Tracker URL，则应将其视为密钥。这是我从规范中推断出来的，因为 BEP 27 没有直接涉及磁力链接，所以请使用您的 Tracker 规则进行测试。
对于在流程中分发软件、数据集或归档文件，我应该发布 .torrent 文件还是磁力链接？
同时发布两者，并将 .torrent 文件作为权威文件。这样可以保留完整的元数据，允许用户离线查看文件列表，并支持网络种子（BEP 19），确保资源可用性。为了方便起见，磁力链接可以从同一个信息哈希值派生而来，并将信息哈希值和签名校验和发布到可信渠道。这既保证了归档的持久性，又方便了共享，而无需依赖对等节点来检索元数据。
决定种子文件可检索时间长短的因素是什么？如何才能提高其可检索性？
可检索性至少需要一个可访问的节点持有数据，对于磁力链接而言，还需要一个节点持有元数据。可以通过保持种子服务器运行、添加多个分层 Tracker（BEP 12）作为备份、添加 HTTP Web 种子以及将 .torrent 文件存档或使其可从缓存已获取元数据的客户端导出来提高可检索性。磁力链接本身无法保存任何内容，因此一个失效的种子群会使它失效。
相关阅读及主题扩展列表
- 编码： .torrent 文件使用的序列化格式，带有排序的字典键
- 信息哈希： bencoded 信息字典的 SHA-1 (v1) 或 SHA-256 (v2) 摘要，即种子文件的身份标识
- 内容寻址存储： 通过哈希值而非位置来识别数据。
- 默克尔树： BitTorrent v2 (BEP 52) 中用于分段验证的单文件哈希树
- 混合种子： 单个种子文件同时包含v1和v2结构以及两个信息哈希值
- 片长和片层数： 元数据大小与验证粒度之间的权衡
- SHA-1 抗碰撞性： 为什么 v1 哈希算法理论上被削弱，而 v2 则转向 SHA-256 哈希算法？
- 扩展协议（BEP 10）： 实现 ut_metadata、PEX 和其他扩展的握手机制
- 元数据交换（BEP 9，ut_metadata）： 从对等节点获取信息字典，数据块大小为 16 KiB。
- Magnet URI 方案： 一个与项目无关的、基于哈希的标识符方案，并已获得 IANA 临时注册。
- MAGMA（磁力清单）： 磁力方案多网络起源中的显式主题概念
- 磁文件选择（BEP 53）： 从链接本身选择种子文件中的特定文件
- 多轨器元数据（BEP 12）： 带有洗牌和故障转移功能的公告列表层级
- UDP 跟踪协议（BEP 15）： 轻量级追踪器通过UDP协议发布消息
- 精简对等列表（BEP 23）： 跟踪器响应中对等节点的紧凑二进制编码
- IPv6跟踪器扩展（BEP 7）： peers6宣布支持IPv6
- Tracker 外部 IP 报告（BEP 24）： 追踪器会告知客户他们观察到的地址
- 主线 DHT（BEP 5）： 基于 Kademlia 的分布式哈希表，用于无跟踪器对等节点发现
- DHT 安全扩展（BEP 42）： 限制节点 ID 以抵御女巫攻击和路由表攻击
- DHT put/get 和 infohash 索引（BEP 44、BEP 51）： 将数据存储在DHT中，并对信息哈希进行采样。
- 点对点交换，PEX（BEP 11）： 集群成员直接共享对等列表
- 本地服务发现（BEP 14）： 在同一网络段上查找对等节点
- 快速扩展（BEP 6）： 协议快捷方式，例如 have-all、have-none 和 reject
- uTP（BEP 29）： 一种基于UDP的传输协议，具有基于延迟的拥塞控制机制
- 打孔器延长件（BEP 55）： 通过中继对等体协调NAT穿越
- 消息流加密（MSE/PE）： 协议混淆，而非匿名
- 私有种子（BEP 27）： 私有标志限制了跟踪器内的对等节点发现。
- Web 种子数据（BEP 17、BEP 19）： HTTP 或 FTP 服务器充当永久种子
- 填充文件（BEP 47）： 将文件对齐到片段边界以进行去重和混合支持
- 本地数据提示（BEP 38）： 重用相关种子文件中的数据，避免重新下载
- Torrent 签名（BEP 35）： 嵌入式RSA签名，可选X.509证书
- Torrent 更新源（BEP 39）： 已签名自动后续种子文件的更新 URL
- 零件验证流程： 提交前进行哈希检查，并从失败片段中恢复
- 解析器和客户端加固： 严格的本科德 验证大小限制、路径清理、SSRF过滤
- WebTorrent 和 WebRTC： 使用 ws/wss 跟踪器和 ICE 或 TURN 的基于浏览器的对等节点
- 种子箱和长期播种： 用于可用性和归档持久性的基础设施
- BEP流程和治理： 如何提出规范、编制规范索引以及从“已接受”到“最终”的整个流程
- 替代内容寻址系统： IPFS 风格的内容标识符可作为比较模型
- 出处与诚信： 为什么哈希值可以验证数据，但永远无法验证发布者的身份？
