BitTorrent 性能卓越的原因

概要
BitTorrent 文件发布系统采用针锋相对（tit_for_tat）的方法来达到帕累托有效，与当前已知的协作技术相比，它具有更高的活力。本文将解释BitTorrent 的用途，以及是怎样用经济学的方法来达到这个目标的。

1、BitTorrent 用来做什么？
当通过HTTP协议来下载一个文件的时候，所有的上载开销都在主机上。而使用 BitTorrent，当多个人同时下载同一个文件的时候，他们之间也相互为对方提供文件的部分片断的下载。这样，就把上载的开销分摊到每个下载者那里，也就可以在理论上支持无限多个下载者来下载同一个文件。
研究人员以前也在寻找一种达到这种效果的可实用的技术[3]。这种技术原来并没有在大的范围内运用过，因为逻辑和的问题非常棘手。如果仅仅计算哪些 peers 拥有文件的哪些片断以及这些片断应该被发送给谁，那么很难只产生比较小的系统开销。Peers之间的连接很少会超过几个小时，通常是几分钟而已。最后，有一个普遍的问题，就是公平性。
我们将解释BitTorrent 是如何很好的解决这些问题的。

1.1、BitTorrent接口
BitTorrent 的接口可能是最简单的。用户点击希望下载的文件的超级链接，然后会弹出一个标准的“保存到”对话框。此后，出现一个下载进度的窗口，在这个窗口中，除了显示下载速率外，还显示一个上载速率。BT在使用上非常简单，使得BT能广泛的被运用。

1.2、部署
决定采用BitTorrent的原因是因为有一些文件需要发布。而下载者使用 BitTorrent，是因为这是他们获取所需要的文件的唯一途径。下载者经常一完成下载，就停止为别人上载，虽然说，在BT 客户端完成下载之后，继续为别人提供一段时间的上载是一种礼貌的行为。标准的实现是让客户端一直保持上载，除非窗口被关闭。
在一个典型的部署中，未完成的下载者
一台主机负责提供原始的文件，下载者通过BT来下载这个文件。下载者在下载的同时，为其它人提供上载，最后，离开这个系统。

2、技术框架

2.1发布内容
为了部署 BT，首先将一个扩展名为 .torrent 的文件放在一个普通的web服务器上。.torrent文件包含了要共享的文件的信息，包括文件名、大小、文件的散列信息和一个指向tracker的url。Tracker负责帮助下载者能够获取其它下载者的信息。Tracker和下载者之间使用一种很简单的基于HTTP的协议进行交互，下载者告诉tracker自己要下载的文件、自己使用的端口以及类似的信息，tracker告诉下载者其它下载同样文件的下载者的联系信息。下载者利用这些信息相互之间建立连接。一个被成为“种子”的下载者，必须首先被启动，它知道完整的文件信息。对tracker和web服务器的带宽需求很低，而种子必须至少发送原始文件的一份完整拷贝。

译注：
P2P的核心思想就是没有服务器的概念，任何一个下载者既是client，又是server。
下载者从别人那里取文件的时候，称为下载，而为别人提供文件的时候，称为上载（传）。
为了完成一次部署，至少需要一个 tracker和一个seed。所谓tracker，是一个服务器，负责帮助peers之间相互建立连接。而seed，通常是第一个向tracker注册，然后它就开始进入循环，等待为别人提供文件，也就是说，第一个seed只负责上传文件。一旦有一个peer向tracker注册后，就可以取得seed的信息，从而与seed建立连接。从seed处读取文件。由于原始的文件，只有seed拥有，所有说，seed至少要上传原始文件的一份完整拷贝。如果又有一个peer加入进来，那么它可以同时和seed和前一个peer建立连接，然后从这两者处获取文件。

2.2对等发布
所有和文件下载相关的逻辑问题，通过 peers之间的交互来解决。一些关于下载和上传的速率的信息被发送给tracker，tracker搜集这些信息用于统计。Tracker的职责被严格限定为“帮助peers相互发现对方”。
尽管tracker是peers之间相互发现的唯一途径，也是peers之间相互协作的唯一地点，标准的tracker算法返回一个随机的 peers的列表。随机图具有非常强大的特性，许多的peer选择算法最终产生了一个幂律图，幂律图能以少量的搅拌来获得分片。注意，peers之间的连接都是双向传输的。
为了跟踪每个peers都拥有什么，BT将文件切割为固定大小的片（典型的大小是256k）。每个下载者必须通知其它peers，它拥有哪些片。为了验证文件的完整性，对每个片断都通过SHA1算法计算出它的hash信息，并保存在torrent文件中。Peers只有在检查了片断的完整性之后，才会通知其它peers它拥有这个片断。删除代码是一种被建议使用的帮助文件分布的技术，但是这种更简单的方法（既分片）也是可用的。
Peers不断的从它能连接到的peers那里下载文件片断。当然，它不能从没有跟它建立连接的peers那里下载任何东西。即使是建立了连接的peers，有的也并不包含它想要的片断，或者还不允许它去下载。关于不允许其它peers从它那里下载文件片断的策略，被称为 阻塞choking，后文将进行讨论。其它关于文件分布的方法通常都要用到麻烦的树结构，而且树叶的上载能力并没有被利用起来。简单的让 peers 宣布它拥有什么会导致不到 10 % 的带宽开支，却可以可靠的使用所有的上载能力。

2.3流水作业
构架在TCP之上的应用层协议，例如BT，很重要的一点是应该同时发送多个请求，以避免在两个片断发送之间的延迟，因为那样会严重影响传输速率。为了达到这种目的，BT将每个片断又进一步分为子片断，每个子片断的大小一般是16k，同时，它一直保持几个请求（通常是5个）被流水的同时发送。流水作业所选择的data（应该是指的同时发送的请求数目，也就是5个request）的依据是能使得大多数连接变得饱和。
译注：也就是说，每次发送5个请求，然后过一段时间，又发送5个请求。流水作业在HTTP 协议1.1版本中被广泛运用。

2.4片断选择
选择一个好的顺序来下载片断，对提高性能非常重要。一个差的片断选择算法可能导致所有的片断都处于下载中，或者另一种情况，没有任何片断被上载给其它 peers。

2.4.1严格的优先级
片断选择的第一个策略是：一旦请求了某个片断的子片断，那么该片断剩下的子片断优先被请求。这样，可以尽可能快的获得一个完整的片断

2.4.2最少的优先
对一个下载者来说，在选择下一个被下载的片断时，通常选择的是它的peers们所拥有的最少的那个片断，也就是所谓的“最少优先”。这种技术，确保了每个下载者都拥有它的peers们最希望得到的那些片断，从而一旦有需要，上载就可以开始。这也确保了那些越普通的片断越放在最后下载，从而减少了这样一种可能性，即某个peer当前正提供上载，而随后却没有任何的被别人感兴趣的片断了。

译注：
也就说说，每个peer都优先选择整个系统中最少的那些片断去下载，而那些在系统中相对较多的片断，放在后面下载，这样，整个系统就趋向于一种更优的状态。如果不用这种算法，大家都去下载最多的那些片断，那么这些片断就会在系统中分布的越来越多，而那些在系统中相对较少的片断仍然很少，最后，某些 peer 就不再拥有其它 peer 感兴趣的片断了，那么系统的参与者越来越少，整个系统的性能就下降。
在BT系统中，充分考虑了经济学的概念，处处从整个系统的性能出发，参与者越多，系统越优化。

信息理论显示除非种子上传了文件的所有片断，否则没有任何下载者可以完成所有文件的下载。如果在一个部署中，只有一个种子，而且种子的上载能力比它的大多数下载者都要差，那么，不同的下载者从种子那里下载不同的片断，性能就会变得比较好，因为，重复的下载浪费了种子获取更多信息的机会。“最少优先”使得下载者只从种子处下载新的片断（也就是整个系统中其它peer都没有的片断），因为，下载者能够看到其它peers那里已经有了种子已经上传的片断。

在某些部署中，原始的种子由于某些原因最终关闭，只好由剩下的这些下载者们来负责上传。这样显然会带来一个风险：某些片断任何一个下载者都不拥有。“最少优先”也很好的处理了这种情况。通过尽快的复制最少的片断，减少了这种由于当前的peers停止上载后带来的风险。

2.4.3随机的第一个片断
“最少优先”的一个例外是在下载刚开始的时候。此时，下载者没有任何片断可供上传，所以，需要尽快的获取一个完整的片断。而最少的片断，通常只有某一个peer拥有，所以，它可能比多个peers都拥有的那些片断下载的要慢。因此，第一个片断是随机选择的，直到第一个片断下载完成，才切换到“最少优先”的策略。

2.4.4最后阶段模式
有时候，从一个速率很慢的peer那里请求一个片断。在下载的中间阶段，这不是什么问题，但是却可能潜在的延迟下载的完成。为了防止这种情况，在最后阶段，peer向它的所有的peers们都发送某片断的子片断的请求，一旦某些子片断到了，那么就会向其它peer发送cancel 消息，取消对这些子片断的请求，以避免带宽的浪费。实际上，用这种方法并没有浪费多少带宽，而文件的结束部分也一直下载的非常快。

3 阻塞（choking）算法
BT并不集中分配资源。每个peer自己有责任来尽可能的提高它的下载速率。Peers从它可以连接的peers处下载文件，并根据对方提供的下载速率给予同等的上传回报（你敬我一尺，我敬你一丈）。对于合作者，提供上传服务，对于不合作的，就阻塞对方。所以说，阻塞是一种临时的拒绝上传策略，虽然上传停止了，但是下载仍然继续。在阻塞停止的时候，连接并不需要重新建立。
阻塞算法并不属于BT对等协议（指peers 之间交互的协议）的技术部分，但是对提高性能是必要的。一个好的阻塞算法应该利用所有可用的资源，为所有下载者提供一致可靠的下载速率，并适当惩罚那些只下载而不上传的peers。

3.1帕累托有效
帕累托有效是指资源配置已达到这样一种境地，即任何重新改变资源配置的方式，都不可能使一部分人在没有其他人受损的情况下受益。这一资源配置的状态，被称为“帕累托最优”（Pareto optimum）状态，或称为“帕累托有效”（Pareto efficient）
在计算机领域，寻求帕累托有效是一种本地优化算法
BitTorrent的阻塞算法，用一种针锋相对的方式来试图达到帕累托最优。（原文不太好翻译，我简化了）。Peers对那些向他提供上传服务的peers给予同样的回报，目的是希望在任何时候都有若干个连接正在进行着双向传输。

3.2 BitTorrent的阻塞算法
从技术层面上说，BT的每个peer一直与固定数量的其它 peers 保持疏通（通常是4个），所以问题就变成了哪些peers应该保持疏通？这种方法使得TCP的拥塞控制性能能够可靠的饱和上传容量。（也就是说，尽量让整个系统的上传能力达到最大）。
严格的根据当前的下载速率来决定哪些peers应该保持疏通。令人惊讶的是，计算当前下载速率是个大难题。当前的实现实质上是一个每隔20秒的轮询。而原来的算法是对一个长时间的网络传输进行总计，但这种方法很差劲，因为由于资源可用或者不可用，带宽会变化的很快。
为了避免因为频繁的阻塞和疏通 peers造成的资源浪费，BT每隔10秒计算一次哪个peer需要被阻塞，然后将这种状态保持到下一个10秒。10秒已经足够使得TCP来调整它的传输性能到最大。

3.3、optimistic unchoking
如果只是简单的为提供最好的下载速率的peers们提供上载，那么就没有办法来发现那些空闲的连接是否比当前正使用的连接更好。为了解决这个问题，在任何时候，每个peer都拥有一个称为“optimistic unchoking”的连接，这个连接总是保持疏通状态，而不管它的下载速率是怎样。每隔30秒，重新计算一次哪个连接应该是“optimistic unchoking”。30秒足以让上载能力达到最大，下载能力也相应的达到最大。这种和针锋相对类似的思想非常的伟大。“optimistic unchoking”非常和谐的与“囚徒困境”合作。

3.4、反对歧视
某些情况下，一个peer可能被它所有的peers都阻塞了，这种情况下，它将会保持较低的下载速率直到通过“optimistic unchoking”找到更好peers。为了减轻这种问题，如果一段时间过后，从某个peer那里一个片断也没有得到，那么这个peer认为自己被对方“怠慢”了，于是不再为对方提供上传，除非对方是“optimistic unchoking”。这种情况频繁发生，会导致多于一个的并发的“optimistic unchoking”。

3.5仅仅上传
一旦某个peer完成了下载，它不能再通过下载速率（因为下载速率已经为0了）来决定为哪些 peers 提供上载了。目前采用的解决办法是，优先选择那些从它这里得到更好的上载速率的peers。这样的理由是可以尽可能的利用上载带宽。

4、真实世界的体验
BitTorrent不仅仅早已经实现，而且早已经被广泛的使用，它为许多并发的下载者提供成百兆的文件下载。已知的最大的部署中，同时有超过1000个的下载者。当前的瓶颈（实际还没有达到）看来是tracker的带宽。它（trakcer的带宽）大概占用了带宽总量的千分之一，一些小的协议扩展可能会使它降到万分之一。

参考资料：

[1] E. Adar and B. A. Huberman. Free riding on gnutella. First Monday, 5(10), 2000.
[2] A.-L. Barab´asi. Linked: The New Science of Networks.Perseus Publishing, 2002.
[3] M. Castro, P. Druschel, A.-M. Kermarrec, A. Nandi, A. Rowstron, and A. Singh. Splitstream: High-bandwidth content distribution in cooperative environments. In Proceedings of IPTPS03, Berkeley, USA, Feb. 2003.
[4] P. Maymounkov and D. Mazieres. Kademlia: A peer-to-peer information system based on the xormetric. In Proceedings of IPTPS02, Cambridge, USA, Mar. 2002.

原文见:http://tb.blog.csdn.net/TrackBack.aspx?PostId=376238