Torrent 网络的速度是如何决定的?

SoW*_*hat 8 bittorrent

我很好奇下载速度是如何在 Torrent 网络上决定的,因为没有中央集线器。如果有 300 个播种者,为什么客户端不能只连接到所有这 300 个而不实际播种任何内容。它是否内置于客户端(我非常怀疑)。整个共享是如何运作的?

PS:我不确定这是不是该问的地方,但它肯定不属于 Stack Overflow。我也不想知道如何更快地下载 torrent。我想知道它们是如何工作的。

Law*_*ceC 11

Bittorrent 并不是真正完全“无中心”——不是用于数据传输,而是用于对等发现。最初,torrent 只能依赖于一个称为跟踪器的中央集线器——同样,不是交换文件的一部分,而是发现群中还有谁。(我相信您可以在一个协议中指定多个跟踪器以实现冗余。)随着 DHT 的引入,Bittorrent 对等点可以使用 DHT 来寻找其他对等点,除了使用跟踪器之外,或者代替使用跟踪器。DHT 本身取决于对一些著名的 DHT“节点”(不确定确切的术语)的预知,以便“引导”一个从未或有一段时间没有通过 DHT 查询过的对等点。

客户端可以自由地与它知道的每个对等点建立连接,同时也是最常见的做法 - 除了考虑程序支持的任何“连接限制”设置。

来自官方 Bittorrent 规范

连接的两端都包含两个状态位:阻塞与否,感兴趣与否。窒息是一种通知,在解除阻塞之前不会发送任何数据。阻塞背后的推理和常用技术将在本文档的后面部分进行解释。

每当一侧感兴趣而另一侧没有窒息时,就会进行数据传输。兴趣状态必须始终保持最新 - 每当下载者没有他们当前会在 unchoked 中向对等方索要的东西时,他们必须表示缺乏兴趣,尽管被扼杀了。正确实现这一点很棘手,但可以让下载者知道如果没有阻塞,哪些对等点将立即开始下载。

连接开始窒息并且不感兴趣。

在传输数据时,下载者应该将多个请求同时排队,以获得良好的 TCP 性能(这称为“流水线”。)另一方面,不能立即写出到 TCP 缓冲区的请求应该在内存中排队,而不是保存在应用程序级别的网络缓冲区中,这样当发生阻塞时它们都可以被抛出。

因此,根据协议,对于您从对等方获取数据,对等方必须“感兴趣”并且您必须“不窒息”。进一步:

窒息有几个原因。当一次通过多个连接发送时,TCP 拥塞控制的表现非常差。此外,窒息让每个对等方使用针锋相对的算法来确保他们获得一致的下载速率。

下面描述的阻塞算法是当前部署的算法。非常重要的是,所有新算法在完全由它们自己组成的网络和主要由这个算法组成的网络中都能很好地工作。

一个好的阻塞算法应该满足几个标准。它应该限制同时上传的数量以获得良好的 TCP 性能。它应该避免快速窒息和解除窒息,称为“颤动”。它应该回报允许它下载的同行。最后,它应该偶尔尝试一下未使用的连接,以确定它们是否可能比当前使用的连接更好,这称为乐观解锁。

当前部署的窒息算法仅通过每十秒更改一次窒息者来避免颤动。它通过取消四个下载率最高且感兴趣的对等点来实现互惠和上传数量上限。具有更高上传率但不感兴趣的对等点不会被阻塞,如果他们感兴趣,最差的上传者就会被阻塞。如果下载器有一个完整的文件,它会使用它的上传速率而不是它的下载速率来决定取消阻塞的对象。

对于乐观解除阻塞,任何时候都有一个不受阻塞的对等体,无论其上传速率如何(如果感兴趣,它都算作四个允许的下载器之一。)乐观解除阻塞的对等体每 30 秒轮换一次。为了让他们有机会上传完整的作品,新连接开始的可能性是当前乐观解锁的可能性是轮换中其他任何地方的三倍。

因此,大多数 Bittorrent 对等点实施“窒息”算法,以确保事情公平地工作,但给予新连接优惠待遇,让他们有机会成为群体的一部分。一个对等点可能会尝试使用一种更不公平的不同算法,但如果没有所有其他对等点的立即合作,“坏”对等点就会被“扼杀”,直到它没有收到任何人的数据。

更多的同行=更快的速度,更快的同行是首选。对等点的上传容量、您设置的任何下载限制以及您的物理链接上传/下载容量也会影响速度。

我(和其他人)在这个问题上进一步详细说明了 Bittorrent 如何工作。