多 Tracker 元数据扩展

2023 年 6 月 16 日

Multitracker Metadata Extension（多 Tracker 元数据扩展）是一种用于 BitTorrent 协议的元数据扩展，旨在提高多个 BitTorrent Tracker 之间协同工作的效率。该扩展允许 Torrent 文件包含来自多个 Tracker 的地址列表，并且客户端可以使用这些地址来连接到任何可用的 Tracker 。这样，如果一个 Tracker 处于离线状态，客户端仍然可以通过其他 Tracker 下载或分享文件。

与标准 BitTorrent 协议不同，Multitracker Metadata Extension 中包含了 Tracker 地址的列表，因此客户端可以更快地找到活动的 Tracker 。这使得 Torrent 文件能够更快速地开始下载，同时还能减轻单个 Tracker 的负载压力。

元数据扩展

BitTorrent 元数据文件中包括两个键（key）：一个是标准的 “announce” 键，另一个是新的 “announce-list” 键。这两个键都用于指定可供客户端使用的 BitTorrent tracker 服务器的 URL 地址列表。

与 “announce” 键不同的是，”announce-list” 键引用的是一个嵌套列表（list of lists），其中每个内部列表都代表了一个 Tracker 服务器的优先级别。这意味着客户端会首先向第一个内部列表中的所有服务器发送请求，如果它们都不可用或无响应，则依次尝试下一个内部列表中的服务器，直到找到可用的 Tracker 服务器为止。

如果客户端支持多 Tracker 规范，且元数据文件中同时存在 “announce” 和 “announce-list” 键，那么客户端将只使用 “announce-list” 中的 URL 地址列表，而忽略 “announce” 键中的地址。这样做可以提高下载效率和可靠性，因为使用多个 Tracker 服务器可以使下载任务更容易地找到其它对等节点并提高下载速度。

执行顺序

“announce-list” 键中的 URL 地址列表会按照优先级别（tiers）逐个处理，客户端会按照优先级别逐个处理列表中的 URL 地址，而不是同时处理所有地址。在每个优先级别中，URL 地址会以随机顺序进行处理，这样可以避免因为某些地址排在前面而导致下载速度过慢或失败的情况。另外，如果客户端与某个 Tracker 服务器的连接成功，那么该服务器所在的优先级别会被移到列表的最前面，这样可以提高与该服务器通信的概率，并加快下载速度。

例：

      d['announce-list'] = [ [tracker1], [backup1], [backup2] ]

当发生 “announce” 事件时，建议首先尝试连接到 “tracker1” 。如果连接失败（可能是因为 tracker 不可用），则应尝试连接到 “backup1”，如果还是失败，则尝试 “backup2” 。下一次发布公告时，应重复相同的尝试顺序 – 首先尝试 “tracker1”，然后是 “backup1”，最后是 “backup2”，如有必要。采用这种方法的原因似乎与不同跟踪器无法彼此共享信息有关。通过每次按照相同的顺序尝试连接到每个跟踪器，系统可以确保始终首选尝试连接到最优先的跟踪器，同时仍然具备备选选项，以防该跟踪器不可用。

      d['announce-list'] = [[ tracker1, tracker2, tracker3 ]]

首先，假设一个 tracker 列表已经被打乱。当客户端需要连接到 tracker 时，会按照以下顺序尝试连接：

首先尝试连接 “tracker1” 。
如果无法连接 “tracker1”，则尝试连接 “tracker2” 。
如果能够连接 “tracker2”，则将追踪器列表重新排列为 “tracker2,tracker1,tracker3”，并以此顺序进行后续连接尝试。
如果无法连接 “tracker2” 或 “tracker1”，但是能够连接 “tracker3”，则将追踪器列表重新排列为 “tracker3,tracker2,tracker1”，并以此顺序进行后续尝试。

Tracker 之间的负载均衡策略。这种方法可以让客户端和 tracker 之间相互交换信息，从而实现负载均衡，避免某个 tracker 过载而导致整个系统性能下降。

      d['announce-list'] = [ [ tracker1, tracker2 ], [backup1] ]

过程中系统分为三个层级：tracker1 、 tracker2 和 backup1 。第一层包括 tracker1 和 tracker2，它们的顺序可能是随机的。当发生 “announce” 事件时，系统会按照某种顺序（每次事件可能的顺序不同）尝试连接到 tracker1 和 tracker2，然后才会尝试使用 backup1 。换句话说，在尝试使用 backup1 之前，系统会先尝试连接 tracker1 和 tracker2 。