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