我第一次使用磁力链接。好奇它是如何工作的，我查看了规格并没有找到任何答案。wiki 说的xt意思是“确切的主题”，后面是btih带有 SHA1 哈希的格式（在这种情况下）。我看到提到 base32，知道它是每个字符 5 位和 32 个字符，我发现它正好包含 160 位，这正是 SHA1 的大小。
IP地址或任何东西都没有空间，它只是一个SHA1。那么 BitTorrent 客户端是如何找到实际文件的呢？我打开了 URL Snooper 以查看它是否访问页面（使用 TCP）或进行查找等，但没有任何反应。我不知道客户如何找到同行。这是如何运作的？
另外，什么是哈希？它是所有文件散列的数组的散列吗？也许它是所需的实际种子文件的哈希（剥离某些信息）？
在虚拟机中，我尝试了与 uTorrent（新安装的）的磁力链接，它设法找到了对等点。第一个同行是从哪里来的？它很新鲜，没有其他种子。
BitTorrent 磁力链接使用1个 SHA-1 或截断的 SHA-256 哈希值（称为“infohash”）来识别种子。这与对等点（客户端）在与跟踪器或其他对等点通信时用于识别种子的值相同。传统的 .torrent 文件包含具有两个顶级键的数据结构：announce，标识用于下载的跟踪器，以及info，包含 torrent 的文件名和哈希值。“infohash”是编码info数据的哈希值。
一些磁力链接包含跟踪器或网络种子，但它们通常不包含。您的客户可能对洪流一无所知，除了它的 infohash。它需要做的第一件事是找到正在下载种子的其他同行。它使用操作“分布式哈希表”（DHT）的单独的对等网络2来做到这一点。DHT 是一个大型分布式索引，它将种子（由信息哈希标识）映射到参与该种子群（上传/下载数据或元数据）的对等点列表（由 IP 地址和端口标识）。
客户端第一次加入 DHT 网络时，它会从与 infohashes 相同的空间生成一个随机的 160 位 ID。然后，它使用客户端开发人员控制的客户端的硬编码地址或先前在洪流群中遇到的支持 DHT 的客户端引导其与 DHT 网络的连接。当它想要加入一个给定 torrent 的 swarm 时，它会在 DHT 网络中搜索 ID与 infohash 尽可能接近3的其他几个客户端。它通知这些客户端它想加入 swarm，并询问他们已经知道的参与 swarm 的任何对等点的连接信息。
当对等点上传/下载特定的 torrent 时，它们会尝试告诉彼此他们知道的所有其他参与相同 torrent 群的对等点。这可以让对等方快速了解彼此，而无需让跟踪器或 DHT 不断地请求。一旦您从 DHT 中了解了一些对等点，您的客户端将能够向这些对等点询问洪流群中更多对等点的连接信息，直到您拥有所需的所有对等点。
最后，我们可以向这些对等点询问种子的info元数据，包括文件名和哈希列表。一旦我们下载了这些信息并使用 known 验证它是正确的infohash，我们实际上与从常规.torrent文件开始并从包含的跟踪器获取对等点列表的客户端处于相同位置。
可以开始下载。
1 infohash 通常是十六进制编码的，但一些旧客户端使用 base 32 代替。v1 ( urn:btih:) 直接使用 SHA-1 摘要，而 v2 ( urn:bimh:) 添加多哈希前缀来标识哈希算法和摘要长度。
2有两个主要的 DHT 网络：更简单的“主线”DHT 和 Azureus 使用的更复杂的协议。
3距离通过 XOR 测量。
对等发现和资源发现（在您的情况下是文件）是两个不同的东西。
我对 JXTA 比较熟悉，但所有对等网络都遵循相同的基本原则。
需要发生的第一件事是对等发现。
对等发现
大多数 p2p 网络是“种子”网络：当第一次启动对等点时，将连接到一个众所周知的（硬编码）地址以检索正在运行的对等点列表。它可以是直接播种，例如 dht.transmissionbt.com在另一篇文章中提到的连接，也可以是间接播种，通常使用 JXTA 完成，其中对等点连接到仅提供其他对等点网络地址的纯文本列表的地址。
一旦与第一个（少数）对等点建立连接，连接的对等点就会执行其他对等点的发现（通过发送请求）并维护它们的表。由于其他对等点的数量可能很大，因此连接的对等点仅维护对等点的分布式哈希表 (DHT) 的一部分。确定连接对等方应维护表的哪一部分的算法因网络而异。BitTorrent 使用带有 160 位标识符/密钥的 Kademlia。
资源发现
一旦连接的对等点发现了一些对等点，后者就会向它们发送一些请求以发现资源。磁力链接识别这些资源，并以这样一种方式构建它们，即它们是资源的“签名”，并保证它们在所有对等点中唯一标识所请求的内容。然后，连接的对等方将向其周围的对等方发送对磁链/资源的发现请求。DHT 的构建方式有助于确定应首先向哪些对等方询问资源（请阅读 Wikipedia 中的 Kademlia 了解更多信息）。如果请求的对等点不持有请求的资源，它通常会将查询“传递”给从其自己的 DHT 获取的其他对等点。
查询可以传递的“跳数”通常是有限的；4 是 JXTA 类型网络的常用数字。
当对等点持有资源时，它会回复其完整的详细信息。然后连接的对等点可以连接到持有资源的对等点（直接或通过中继 - 我不会在这里详细介绍）并开始获取它。
P2P 网络中的资源/服务不直接附加到网络地址：它们是分布式的，这就是这些高度可扩展网络的优点。
我自己也对同样的问题感到好奇。阅读传输代码，我发现以下内容libtrnasmission/tr-dht.c：
3248: bootstrap_from_name( "dht.transmissionbt.com", 6881,
bootstrap_af(session) );
它尝试了 6 次，尝试之间等待 40（！）秒。我想您可以通过删除配置文件（~/.config/transmission在 unix 上）并阻止与 的所有通信来测试它dht.transmissionbt.com，然后看看会发生什么（至少等待 240 秒）。
所以看起来客户端有一个内置的引导节点开始。当然，一旦它进入网络，它就不再需要那个引导节点了。
当我开始回答你的问题时，我没有意识到你在问磁铁方案是如何工作的。只是想你想知道与 bittorrent 协议相关的部分是如何生成的。
磁铁 uri 中列出的哈希是使用 base32 编码的 torrent 信息哈希。信息散列是种子的编码信息块的 sha1 散列。
此python 代码演示了如何计算它。
我编写了一个（非常幼稚的）C# 实现来测试这一点，因为我手头没有 Bencoder，它符合客户的预期。
static string CalculateInfoHash(string path)
{
// assumes info block is last entry in dictionary
var infokey = "e4:info";
var offset = File.ReadAllText(path).IndexOf(infokey) + infokey.Length;
byte[] fileHash = File.ReadAllBytes(path).Skip(offset).ToArray();
byte[] bytes;
using (SHA1 sha1 = SHA1.Create())
bytes = sha1.ComputeHash(fileHash, 0, fileHash.Length - 1); // need to remove last 'e' to compensate for bencoding
return String.Join("", bytes.Select(b => b.ToString("X2")));
}
据我了解，此哈希不包含有关如何定位跟踪器的任何信息，客户端需要通过其他方式（提供的announce url）找到它。这正是跟踪器上一个洪流与另一个洪流的区别所在。
与 bittorrent 协议相关的一切仍然围绕着跟踪器。它仍然是蜂群之间的主要通信方式。磁铁 uri 方案并非专门为 bittorrent 使用而设计的。它被任何 P2P 协议用作另一种通信形式。Bittorrent 客户端适合接受磁力链接作为另一种识别种子的方式，这样您就不需要再下载 .torrent 文件了。磁铁 uri 仍然需要指定tracker 才能定位它，以便客户端可以参与。它可以包含有关其他协议的信息，但与 bittorrent 协议无关。没有跟踪器，bittorrent 协议最终将无法工作。
我终于找到了规范。谷歌第一次没有帮助。（链接到主要站点 bittorrent.com 的 wiki。我单击了开发人员链接，注意右侧的 bittorrent.org 选项卡，然后从那里很容易。当您不知道它们的标签和许多链接时，很难找到链接点击离开）。
似乎所有的种子都有一个对等网络。您从跟踪器中找到对等点，并在会话之间保留它们。该网络允许您找到对等点和其他东西。我还没有读过它如何与磁力链接一起使用，但似乎未定义新客户如何找到同行。可能有些是内置的，或者他们使用他们的家庭服务器或嵌入客户端的已知跟踪器来获取网络中的第一个对等点。
对等点列表可能是从升级客户端的洪流中填充的（例如，有一个用于升级客户端的 utorrent 的洪流）。只要大家用的是同一个客户端，就应该不错，因为你别无选择，只能共享升级。