跳轉到內容

P2P 世界:BitTorrent 協議和軟體

來自華夏公益教科書,開放世界開放書籍

BitTorrent

[編輯 | 編輯原始碼]

BitTorrent 是一種協議(BitTorrent 協議規範 v1.0)由 布拉姆·科恩 建立,源於 Gnutella 概念,但主要設計用於透過網際網路分發大型計算機檔案並允許 WEB 整合,實際上它旨在替代舊的集中式 HTTP 下載,而不是完整的 P2P 網路。因此,它最初避免了在網路上傳輸搜尋請求的限制,最近透過採用類似於 eDonkey 解決方案的 DHT 來實現這一點,該解決方案允許在網路上進行搜尋。使 BitTorrent 成為兩層 P2P。

BitTorrent 用於分發合法內容,但本身不區分共享材料的版權狀態,與任何其他去中心化網路一樣,這允許大規模侵權。布拉姆·科恩和 阿什溫·納文 於 2004 年 9 月 22 日創立了 BitTorrent, Inc.,總部位於 舊金山加利福尼亞州,是一傢俬營的 美國 公司,致力於開發變革性的技術和產品,以繼續推動更高效和開放的網際網路的進步,還透過研發和開放規範促進 BitTorrent 協議的開發。

BitTorrent(http://www.bittorrent.com)也是該協議的原始實現的名稱。它最初是一個 Python原始碼和舊版本)應用程式,現在被稱為 BitTorrent 主線,它導致了一個功能齊全的商業企業。BitTorrent.com 是 BitTorrent Inc. 的一部分,現在已成為使用 BitTorrent 協議下載娛樂內容的目的地。該網站提供對數千部電影、電視劇、音樂和遊戲的包含最全面授權目錄的快速點播訪問,但也為內容創作者提供了一個釋出平臺,讓他們可以在主要電影製片廠、電視網路和唱片公司的最知名作品旁邊列出他們的作品,並保持高品質。

BitTorrent Inc. 還透過更廣泛的標準機構(如網際網路工程任務組 (IETF) 的 LEDBAT 工作組(http://www.ietf.org/html.charters/ledbat-charter.html))做出貢獻。BitTorrent, Inc. 擁有 BitTorrent 主線和 µTorrent 客戶端,以及 BitTorrent DNA(交付網路加速器),這是一種基於 BitTorrent 協議的免費內容交付服務,它將使用者貢獻頻寬的力量帶給傳統內容釋出商,同時讓釋出商完全控制他們的檔案。

BitTorrent 協議本質上是點對點的,它最初的創新之處在於不圍繞建立真正的分散式網路,而是圍繞特定的共享資源,在這種情況下是檔案,最好是大型檔案,因為使用者直接相互連線以從其他對等節點發送和接收大型檔案的部分,這些對等節點也已下載了該檔案或其部分。然後,這些片段被重新組裝成完整的檔案。由於使用者從彼此下載,而不是從一箇中央伺服器下載,因此下載大型檔案的頻寬負載分散到使用者正在下載的多個來源之間。這降低了託管大型檔案的使用者的頻寬成本,並提高了下載大型檔案的使用者的下載速度,因為該協議利用了每個下載者的上行頻寬來提高整個分發的效率,並在下載者方面獲得優勢。但是,有一箇中央伺服器(稱為跟蹤器),它協調所有此類對等節點的操作。跟蹤器只管理連線,它不知道正在分發的檔案的內容,因此,可以使用相對有限的跟蹤器頻寬來支援大量的使用者。

BitTorrent 的核心理念是使用者應該在下載(接收入站)的同時上傳(傳輸出站)。這樣,網路頻寬就可以儘可能高效地利用。BitTorrent 被設計為隨著對某個檔案的興趣人數增加而更好地工作,這與其他檔案傳輸協議形成對比。

BitTorrent 正在重新定義人們分享和搜尋內容的方式,並且由於它非常特定於檔案,並且它在 P2P 內容的“新”因素上獲得優勢,越來越受歡迎,用於下載電影、電視劇、完整音樂專輯和應用程式(它在效能上優於其他替代方案),更多使用者意味著更快速度,但對於稀有檔案或分發未被廣泛搜尋的內容來說,它不是最佳解決方案。

要下載使用 BitTorrent 託管的檔案,使用者必須擁有 BitTorrent 客戶端,並且要釋出檔案,必須執行跟蹤器。

2004 年 11 月,BitTorrent 佔網際網路所有流量的驚人 35%,根據英國網路分析公司 CacheLogic 的資料,到 2006 年,BitTorrent 協議已上升到網際網路所有流量的 60% 以上。由於此,一些 ISP 正在進行流量整形,也稱為頻寬限制,這意味著他們正在降低協議在其網路中的優先順序並降低其整體效能,這導致了兩種回應,一些 ISP 正在投資升級他們的網路併為協議提供本地快取,而協議的實施者開始透過加密和隨機化來對抗拒絕適應的 ISP,這種適應的必要性以及由於偏離其創作者的願景而帶來的日益普及正在將更多協議的演變置於獨立開發人員手中。

BitTorrent 系統高度依賴於對等節點的積極參與,因為它的唯一目標是共享檔案。罕見和“舊”內容在系統中不容易找到,只有高度關注的內容才能從這種 P2P 實現中受益。小檔案也無法完全從中受益,因為複製所需的時間太短,在某些極端情況下甚至會降低體驗。

內容索引器

[編輯 | 編輯原始碼]

有許多不同的 BitTorrent 網站索引內容,每個網站都提供有關透過 BitTorrent 協議分發的檔案的資訊。它們通常包含多個種子檔案和這些檔案的索引。在典型情況下,使用者會進入這樣的網站,並根據其他使用者在網站上釋出的種子檔案描述,瀏覽或搜尋他們想要的內容。如果找到包含所需內容的種子檔案,使用者可以下載該種子檔案。

合法種子檔案(http://www.legaltorrents.com),一個由創意共享許可的合法可下載的、自由分發的創作者認可的檔案集合,從電子/獨立音樂到電影和書籍,這些檔案已透過 BitTorrent 提供。每個使用 BitTorrent 客戶端並下載的人都會幫助貢獻更多頻寬。

還有 OpenBitTorrent(http://openbittorrent.com)、OpenBitTorrent.kg(http://www.openbittorrent.kg)、myTorrentTracker(http://www.mytorrenttracker.com)和 trackhub(http://trackhub.appspot.com),所有 BitTorrent 跟蹤器都免費供任何人使用來共享檔案。您無需在任何地方註冊、上傳或索引種子檔案,您只需在種子檔案中包含跟蹤器 URL 即可。

其他

這些網站都有不同的功能來方便使用者的搜尋。參見維基百科的BitTorrent 網站比較頁面。一些較大的 BitTorrent 跟蹤器網站被關閉,原因是擔心版權持有者(主要是大型商業利益代表)的權益。雖然從短期來看,這確實可以防止大規模的版權侵犯,但也給合法使用帶來了困難,而且還存在虛假通知問題,即聲稱對他們不擁有的作品擁有版權。從長遠來看,這無助於解決問題,反而會迫使協議以避免這種干擾的方式發展。人們適應這種壓力的一個方法是建立私人跟蹤器,這些跟蹤器只能透過邀請才能訪問。

如前所述,BitTorrent 是一種用於分發檔案的協議。它透過 URL 識別內容,並旨在與網路無縫整合。它比普通 HTTP 的優勢在於,當多個下載同一檔案同時發生時,每個下載者都會相互上傳,從而使檔案源能夠以適度的負載增長支援大量下載者。(http://www.bittorrent.com/protocol.html)。BitTorrent 共享了其他 P2P 協議的一些命名法,但也建立了一些新的命名法(參見維基百科的頁面BitTorrent 詞彙表以獲得擴充套件列表)。

種子檔案
種子檔案可以指一個.torrent元資料檔案,也可以指它描述的所有檔案,具體取決於上下文。種子檔案,如 BitTorrent 規範中所定義,包含多個跟蹤器的 URL,這些跟蹤器協調蜂群中對等節點之間的通訊,以及有關所有可下載檔案完整性的元資料,包括它們的名稱和大小以及校驗和種子檔案中的所有片段。它還可以包含 BitTorrent 規範擴充套件中定義的附加元資料,稱為BitTorrent 增強建議。此類建議的示例包括用於說明誰建立了種子檔案以及何時建立的元資料。
索引
索引是 .torrent 檔案列表(通常包括描述和其他資訊),由網站管理,可供搜尋。索引網站有時也被稱為跟蹤器,但它是一個“種子檔案”跟蹤器,而不是 BitTorrent 跟蹤器)。

該協議在一定程度上依賴於集中化,因為需要跟蹤器。

客戶端
支援透過 BitTorrent 協議進行P2P檔案共享的程式。它仍然表明了該協議的半集中化性質,在協議定義中,術語有時被替換為對等節點(例如:peer_id),例如 Gnutella 始終將參與者稱為對等節點或節點,而將實現者稱為供應商。
跟蹤器
一個跟蹤器是一個伺服器,它跟蹤蜂群中哪些種子和對等節點。客戶端會定期向跟蹤器報告資訊,並作為交換,接收有關可以連線的其他客戶端的資訊。跟蹤器不直接參與資料傳輸,也沒有檔案的副本。
抓取
當客戶端向跟蹤伺服器傳送請求以獲取有關種子檔案統計資訊時,就會發生這種情況,例如,與誰共享檔案以及其他使用者共享的程度如何。

隨著 DHT(分散式雜湊表)的採用,BitTorrent 協議開始變得不僅僅是圍繞單個資源的半集中化分發網路,它變得更加去中心化,並移除了靜態控制點(跟蹤器),這是透過依靠 DHT 和使用PEX擴充套件來實現的。使易變的對等節點也可以作為跟蹤器執行,但即使這解決了對靜態跟蹤器伺服器的需求,網路仍然圍繞內容集中化。對等節點沒有預設能力在該上下文之外相互聯絡。

種子
種子是一個客戶端,它擁有種子檔案的完整副本,並且仍然提供上傳。種子越多,獲得更高下載速度的可能性就越大。如果種子播種了下載的整個副本,他們應該獲得更快的下載速度。

播種規則,就像我們將在超級播種的特殊情況下看到的那樣,是客戶端在一般配置中本地實現的變數和演算法,通常以某種形式對使用者控制開放。這些規則控制並可能有助於最佳化對可用種子檔案的選擇,而不是隻是啟動列表中的下一個種子檔案,並根據播種排名對種子檔案進行排序。

播種排名
是一個優先順序評級,它是由基於客戶端的活動播種規則的計算產生的,用於根據種子檔案的需求優先順序對種子檔案進行排序。它會生成一個優先順序佇列,其中可用種子檔案會利用可用的傳輸空閒插槽。一些因素可以影響播種排名
  • 種子比率。比率越低,種子檔案越稀缺,播種排名就應該越高,優先順序應該更高,優先考慮稀有種子檔案。
  • 種子計數。類似於種子比率,但不僅考慮完整的種子,還考慮對種子檔案感興趣的任何客戶端的數量,反向工作,優先考慮更大的蜂群和需求量大的種子檔案。
  • 定時輪換。種子檔案將在播種模式中輪換進出。每個種子檔案都會獲得一個播種時間長度。
  • 預設值。每個種子檔案都會根據新增到種子列表中的順序進行播種。
宣佈
類似於“抓取”,但意味著客戶端還宣佈它希望加入蜂群,並且伺服器應該將它新增到該蜂群的對等節點列表中。
可用性(也稱為分散式副本)。
這是分散式系統中常用的一個詞,在本例中,它指的是客戶端可用的檔案的完整副本數量。每個種子都會為這個數字增加 1.0,因為它們擁有檔案的完整副本。如果其他對等節點沒有檔案的這一部分,則連線的對等節點會將可用的檔案片段新增到可用性中。
示例:一個下載了檔案 65.3% 的對等節點會將可用性增加 0.653。但是,如果兩個對等節點都下載了檔案的相同部分(例如 50%),並且只有一個種子,那麼可用性就是 1.5。
感興趣
描述一個希望獲取客戶端擁有的檔案片段的下載者。例如,如果下載的客戶端不擁有上傳的客戶端擁有的片段,並且希望獲取它,那麼上傳的客戶端會將下載的客戶端標記為“感興趣”。
下載者
下載者是任何沒有完整檔案並且正在下載檔案的對等節點。這個術語,在Bram CohenPython實現中使用,缺乏水蛭所具有的負面含義。Bram 選擇了下載者而不是水蛭這個詞,因為 BitTorrent 的公平交換機制確保了下載者也上傳,因此不公平地被歸類為水蛭
阻塞
描述一個被拒絕檔案片段的客戶端。一個客戶端在以下幾種情況下會阻塞另一個客戶端。
  • 第二個客戶端是一個種子,在這種情況下,它不需要任何片段(即它完全不感興趣)。
  • 客戶端已經以其全速上傳(它已達到max_uploads的值)。
  • 第二個客戶端已被列入黑名單,因為它存在濫用行為或正在使用被列入黑名單的 BitTorrent 客戶端。
冷落
如果下載的客戶端在超過 60 秒的時間內沒有從上傳的客戶端收到任何資料,則上傳的客戶端會被標記為冷落


Clipboard

待辦事項
新的協議來提高 BitTorrent 速度,稱為“快取發現協議”或 CDP,它據稱將充當對等網路的 DHCP。


BitTorrent 的擴充套件協議

[編輯 | 編輯原始碼]

由 Arvid Norberg 和 Ludvig Strigeus 建立,(描述 http://www.rasterbar.com/products/libtorrent/extension_protocol.html),它是該協議的擴充套件,旨在為 BitTorrent 協議的未來擴充套件提供簡單且精簡的傳輸。該協議使新增新擴充套件變得容易,而不會干擾標準的 BitTorrent 協議或不支援此擴充套件的客戶端。

擴充套件訊息 ID 在握手時定義,以避免擁有全域性訊息 ID 登錄檔。相反,擴充套件訊息的名稱需要唯一的名稱,這在沒有全域性登錄檔的情況下更容易實現。

Vuze(http://wiki.vuze.com/w/Azureus_messaging_protocol)似乎也存在一個併發的實現或變體,它被 Vuse 和 Transmission 使用。

對等節點交換

[編輯 | 編輯原始碼]

對等節點交換PEX是一種通訊協議,它擴充套件了BitTorrent檔案共享協議。它允許一群使用者(或對等節點)協同共享給定檔案,從而更快更有效地完成此操作。PEX 使用兩種常見的擴充套件協議之一來實現。

在最初的 BitTorrent 檔案共享協議客戶端設計中,檔案共享組(稱為“群”)中的使用者(對等方)依賴於稱為 跟蹤器 的中央計算機伺服器來相互查詢並維護群。PEX 透過允許每個對等方直接更新群中的其他對等方,告知哪些對等方當前在群中,從而大大減少了對等方對跟蹤器的依賴。透過減少對集中式跟蹤器的依賴,PEX 提高了 BitTorrent 協議的速度、效率和健壯性,使其更加去中心化。

如前所述,想要獲取檔案副本的使用者通常會先下載一個 .torrent 檔案,該檔案描述了要共享的檔案,以及一個或多個稱為 跟蹤器 的中央計算機的 URL,這些中央計算機維護著當前共享 .torrent 檔案中描述的檔案的對等方列表。在最初的 BitTorrent 設計中,對等方依賴於這個中央跟蹤器來相互查詢並維護群。後來 分散式雜湊表 (DHT) 的發展意味著對等方部分列表可以由群中的其他計算機儲存,從而減少了對中央跟蹤器計算機的負載。PEX 允許群中的對等方直接交換有關群的資訊,而無需詢問 (輪詢) 跟蹤器計算機或 DHT。這樣做,PEX 利用使用者連線的對等方的知識,透過詢問他們所連線的對等方的地址來獲取資訊。這比僅僅依賴跟蹤器更快、更有效,並且減輕了跟蹤器的處理負載。它還在跟蹤器關閉時將群保持在一起。事實上,一旦對等方保留了檔案共享的完整副本,就消除了對分發的任何控制。

對等方交換本身不能用來將新對等方引入群。為了與群建立初始連線,每個對等方必須使用 ".torrent" 檔案連線到跟蹤器,或者使用稱為 引導節點 的路由器計算機來查詢描述群的對等方列表的分散式雜湊表 (DHT)。對於大多數 BitTorrent 使用者,DHT 和 PEX 將在使用者啟動 BitTorrent 客戶端並開啟 .torrent 檔案後自動開始工作。一個值得注意的例外是“私人洪流”,這些洪流並非公開可用;這些洪流將停用 DHT。

Azureus 和 µTorrent 開發人員之間達成一致,任何實現上述機制的客戶端在傳送 PEX 訊息時都應遵守以下限制

  • 在任何給定的 PEX 訊息中,新增的對等方不應超過 50 個,刪除的對等方不應超過 50 個。
  • 對等方交換訊息的傳送頻率不應超過每分鐘一次。

某些客戶端可能會選擇強制執行這些限制,並斷開忽略這些限制的客戶端的連線。

永久 DHT 跟蹤

[edit | edit source]

隨著 PEX 的實現和對分散式雜湊表 (DHT) 的依賴,向建立真正的完全無伺服器 P2P 覆蓋網路演變成為下一個合乎邏輯的步驟,就像我們所見到的 eDonkey 網路一樣。DHT 的工作方式大致相同,它不僅從舊的跟蹤器獲取資訊,還從 PEX 實現獲取資訊,從而建立了一個類似於共享洪流的分散式資料庫,在所有其他跟蹤器關閉或無法提供足夠對等方的情況下充當備份跟蹤器,並啟用無跟蹤器洪流。如果客戶端啟用了該選項,DHT 作為偽跟蹤器新增到洪流中,並且 DHT 跟蹤器可以像常規跟蹤器一樣,在每個洪流中啟用和停用。使用這種永久 DHT 跟蹤的客戶端現在是一個完全連線的去中心化 P2P 網路,它們以新節點的形式進入 DHT,當然,這使得私人跟蹤器(或非公開分發)必須將自己排除在參與之外。

引導 DHT

由於 DHT 獨立於任何單個跟蹤器(和故障點),因此必須解決 DHT 路由表在首次使用 DHT 時如何引導的問題。這可以通過幾種方式實現

  1. 手動輸入 DHT 節點的主機名和埠號。
  2. 連線到具有包含 DHT 節點列表的 .torrent 檔案的跟蹤器。
  3. 下載任何具有宣傳支援 DHT 的對等方的洪流。並非所有客戶端都完全支援,因為它要求客戶端在 BitTorrent 握手 DHT 支援中進行宣傳。
磁力連結

傳統上,.torrent 檔案是從洪流網站下載的。但是,幾個客戶端也支援 磁力 URI 方案。磁力連結不僅可以提供在 DHT 中查詢共享檔案的所需節點所需的洪流雜湊,還可以包含該檔案的跟蹤器。

BitTorrent 增強提案 (BEP)

[edit | edit source]

BitTorrent 增強提案流程 (BEP) 是由 John Hoffman 啟動的流程。該流程在公共領域文件(http://www.bittorrent.org/beps/bep_0001.html)中定義。

BitTorrent 增強提案列表可用(http://www.bittorrent.org/beps/bep_0000.html)。

BEP 是一份設計文件,它向 BitTorrent 社群提供資訊,或描述 BitTorrent 協議的新功能。BEP 應提供對該功能的簡潔技術規範和基本原理,旨在成為提出新功能、收集社群對問題的意見以及記錄 BitTorrent 設計決策的主要機制。

BEP 作者負責在社群內達成共識並記錄異議。由於 BEP 作為版本控制的儲存庫中的重新結構化文字檔案進行維護,因此它們的修訂歷史記錄是功能提案的歷史記錄。

超級替換

[edit | edit source]

超級替換 在 BEP 16(http://www.bittorrent.org/beps/bep_0016.html)中指定,是對 BitTorrent 協議(在不更改協議的情況下實現)的擴充套件,旨在用於只有一個 種子 的情況,它允許管理資源的稀缺性。

在種子檢測到自己是檔案唯一來源的情況下,它會嘗試最小化上傳的資料量,以保證外部共享並最佳化對稀缺資源的訪問,直到它檢測到其他完整的種子存在。該功能由 John Hoffman 構思,並於 2003 年首次在 BitTornado 客戶端中實現。

uTPµTP(有時也稱為 微傳輸協議)是一種 開源 跨平臺 協議,建立用於在 UDP 協議之上實現 TCP 類似的 LEDBAT(一種 TCP 擁塞避免演算法)。

µTP 在 BitTorrent, Inc. 中開發,網路或 BitTorrent 社群沒有提供任何輸入,以提供可靠的有序交付,同時保持最小的額外延遲,因為自動降低 對等 檔案共享 洪流 使用者之間資料包傳輸速率,因為它會干擾其他應用程式。例如,該協議應自動允許 BitTorrent 應用程式和 Web 瀏覽器之間共享 ADSL 線路。它首次在 µTorrent 1.8.x 測試版分支中引入,並在 µTorrent 1.9 的 Alpha 版本中公佈,現在是 uTorrent 對等連線的主要傳輸協議。

uTP 作為 BitTorrent 擴充套件在 BEP 29 中記錄(http://bittorrent.org/beps/bep_0029.html)。BitTorrent, Inc. 在 MIT 許可下提供了一個 C++ 實現(http://github.com/bittorrent/libutp),但外部介面嚴格為 C(ANSI C89)。

BitTorrent 協議加密

[edit | edit source]

截至 2005 年 1 月,BitTorrent 流量佔住宅網際網路流量的三分之一以上。正如本書中關於 影子游戲 部分所述,一些 ISP 決定採取不同的措施來控制甚至顛覆 P2P 流量。

這就需要提供 BitTorrent 協議加密。混淆和加密使流量更難檢測和監控,因此更難限制。BitTorrent 協議加密並非旨在提供 匿名性機密性,即使某些解決方案會透過混淆內容來提高機密性。

BitTorrent 協議的發明者布拉姆·科恩反對在 BitTorrent 協議中新增加密功能。科恩表示,他擔心加密會導致客戶端之間出現不相容性,並強調大多數 ISP 並沒有阻止 torrent 協議。科恩寫道:“我懷疑有些開發者被他們的 ISP 限速了,他們更感興趣的是繞過 ISP 的限制,而不是整個網際網路的效能。”。在遭到一些批評後,科恩後來在自己的 主線客戶端 上添加了接收但不能發起加密連線的功能。值得注意的是,當 µTorrent 被 BitTorrent, Inc. 收購,併成為下一個主線版本後,發起加密連線的功能得以保留,但預設情況下是關閉的。

加密並不能阻止流量整形系統,該系統被配置為使用諸如丟包等簡單方法普遍降低所有加密、無法識別或未知協議的速度。加密跟蹤器通訊可以防止監聽對等列表,並且不需要升級對等連線的雙方,但它需要在跟蹤器上增加計算開銷。

協議頭加密 (PHE)
由 RnySmile 建立,首次在 2005 年 9 月 8 日的 BitComet 0.60 版本中實現。該規範既沒有釋出,也沒有與 MSE/PE 相容,並且有人聲稱它已經被反向工程,從而降低了它的實用性。
訊息流加密 (MSE)/協議加密 (PE)
由 Azureus(現在是 Vuze)於 2006 年 1 月底開發,後來經過多次修改,獲得了其他 BitTorrent 客戶端建立者的廣泛認可。
根據規範(http://wiki.vuze.com/w/Message_Stream_Encryption),MSE/PE 使用 金鑰交換 與 torrent 的資訊雜湊相結合,以建立一個 RC4 加密金鑰。金鑰交換有助於最小化被動監聽的風險,資訊雜湊有助於避免 中間人攻擊。選擇 RC4 是因為它的速度快。丟棄 RC4 輸出的第一個千位元組以防止 特定攻擊
該規範允許使用者選擇只加密頭還是加密整個連線。加密整個連線可以提供更多混淆,但會使用更多 CPU 時間。為了確保與不支援此規範的其他客戶端的相容性,使用者還可以選擇是否仍然允許未加密的傳入或傳出連線。支援的客戶端透過 PEXDHT 傳播它們已啟用 MSE/PE 的事實。
對這種方法的分析表明,對 TCP 會話中前 100 個數據包的資料包大小和資料包方向的統計測量可以用來識別混淆後的協議,準確率超過 96%,這使得該解決方案僅對沒有采用最先進的流量分析技術的 ISP(主要是較小的 ISP)有效。

存在各種解決方案來保護 BitTorrent 網路免遭攻擊,包括加密對等-跟蹤器和對等-對等通訊,使用微軟的 Teredo 使 TCP 連線在 UDP 資料包中隧道化,在它們到達最終主機中的 TCP 層之前過濾 TCP 重置,或者完全從基於 TCP 的傳輸切換到基於 UDP 的傳輸。每種解決方案都有其權衡。過濾掉攻擊 TCP 重置通常需要核心訪問,並且需要遠端對等的參與,因為攻擊者必須將重置資料包傳送到本地和遠端對等。並非所有 BitTorrent 客戶端都提供 Teredo。在新的 UDP 協議中重寫 TCP 可靠性、按順序交付和擁塞控制需要大量的工程工作,並且需要升級任何對等連線的雙方。

軟體實現

[edit | edit source]

維基百科在諸如 BitTorrent 軟體比較BitTorrent 客戶端的使用份額 等文章中提供了一些相關資訊。以下列表是為了提供關於與其他 P2P 協議相關的實現細節的總體概念和比較。
(這不能被視為 BitTorrent 客戶端的完整列表,沒有使用任何特殊順序。所有連結都已驗證,軟體的程式語言和許可證得到了特別關注。最後更新時間為 2010 年 9 月 11 日)

  • BitTorrent 佇列管理器http://btqueue.sourceforge.net),一個基於控制檯的 BitTorrent 客戶端,具有用於處理多個會話的內建排程程式。它旨在輕鬆地在佇列中管理會話,而無需重量級的 GUI。外部模組可以搜尋跟蹤器中的新 torrent 並自動提交。開源(Python 軟體基金會許可證)專案,使用 Python。
  • Vuze 以前稱為 Azureus(http://azureus.sourceforge.nethttp://www.vuze.com/),一個用 Java 編寫的開源 BitTorrent 客戶端,可能是網路中更先進的對等方(多個 torrent 下載、排隊/優先順序系統、啟動/停止播種選項、嵌入式跟蹤器、主線 DHT 等等),但它是一個眾所周知的資源佔用大戶,會消耗大量的記憶體和 CPU 功率。
  • µTorrenthttp://utorrent.com),一個用 C++ 編寫的閉源免費軟體 BitTorrent 客戶端,是一個非常完整對等方(包括頻寬優先順序、排程、RSS 自動下載和主線 DHT 等等),系統佔用空間非常小。
  • BitTornadohttp://bittornado.com),一個用 Python 編寫的開源 BitTorrent 客戶端,基於原始的 BitTorrent 客戶端。
  • BitComethttp://www.bitcomet.com)(最初從 0.11 版到 0.37 版被稱為 SimpleBT 客戶端)是一個閉源但免費的 BitTorrent 客戶端,僅適用於 MS Windows 作業系統,它還支援 HTTP/FTP 下載管理。
  • ABC(另一個 BitTorrent 客戶端)http://pingpong-abc.sourceforge.net),一個基於 BitTornado 的開源 BitTorrent 客戶端。
  • Transmissionhttp://transmission.m0k.org/),一個具有簡單圖形使用者介面的輕量級開源 BitTorrent 客戶端,該介面位於跨平臺後端之上。Transmission 在 Mac OS X 上執行,具有 Cocoa 介面,在 Linux/NetBSD/FreeBSD/OpenBSD 上執行,具有 GTK+ 介面,在 BeOS 上執行,具有原生介面。在 MIT/X Consortium 許可證下發布。
  • Warezhttp://www.warezclient.com),來自 Neoteric Ltd. 的一個閉源、僅限 MS Windows 的 BitTorrent 客戶端(以前支援 Ares Network Warez P2P 客戶端)。
  • Bits on Wheelshttp://bitsonwheels.com),一個用 Objective-C 和 Cocoa 為 Macintosh 編寫的免費但閉源的實現。
  • Vidorahttp://www.videora.com/),一個閉源免費軟體實現,它還支援 Really Simple Syndication (RSS) 饋送。
  • sharktorrenthttp://sharktorrent.sourceforge.net/),一個用 C++ 編寫的開源(GNU GPL)。這是一個跨平臺 BitTorrent 客戶端,使用 QT、libtorrent 和 boost 庫。
  • ted [Torrent 劇集下載器]http://www.ted.nu/),一個用 Java 編寫的開源(GNU GPL)BitTorrent 客戶端,它還支援 torrent RSS 饋送。
  • rTorrent|http://libtorrent.rakshasa.no)是一個用 C++ 編寫的基於文字的 ncurses BitTorrent 客戶端,基於用於 Unix 的 libTorrent 庫(不要與 Arvid Norberg/Rasterbar 的 libtorrent 混淆),其作者的目標是“專注於高效能和良好的程式碼。客戶端和庫都可以在 GNU GPL 下使用。”
  • libtorrenthttp://www.rasterbar.com/products/libtorrent/)來自 Rasterbar 軟體,一個開源 C++ 庫,實現了 BitTorrent 協議和應用程式的核心必要條件,使用 zlib 和 Boost 庫,特別是 Boost.Asio 並共享 Boost 許可證。該庫也常用於 嵌入裝置 中。該庫還提供對 UPnP 配置的支援。以下實現使用 libtorrent:
    • Halitehttp://www.binarynotions.com/halite-bittorrent-client),一個開源的 BitTorrent 客戶端,在 Boost 軟體許可證下,使用 libtorrent 庫。用 C++ 編寫的,使用 Boost 庫和 WTL(僅限 Windows)。
    • FireTorrenthttps://addons.mozilla.org/en-US/firefox/addon/10931)由 Pete Collins、Radical Software Ltd、Jan Varga、Matthew Gertner 開發,使用 libtorrent 庫的開源 JavaScript,Mozilla 公共許可證 FireFox 擴充套件/附加元件,用於下載 torrent。
    • Folxhttp://www.mac-downloader.com/),閉源,使用 libtorrent 庫(僅限 Mac)。
    • qBittorrenthttp://www.qbittorrent.org/),開源 GNU GPL,由博士生(Christophe Dumez)開發,一個使用 C++/libtorrent 和 Qt4 圖形使用者介面的 Bittorrent 客戶端。
    • Delugehttp://deluge-torrent.org),一個使用 Python 和 libtorrent 的開源、輕量級、跨平臺 BitTorrent 客戶端,在 GNU GPL 許可證下發布。
    • Limewire,作為一個著名的 Gnutella 實現,它還透過使用 libtorrent 庫支援 BitTorrent 協議。
    • BTGhttp://btg.berlios.de),用 C++ 實現並使用 Rasterbar Libtorrent 庫的 Bittorrent 客戶端,在 GNU GPL 下發布。提供 Ncurses、SDL、Gtkmm 和 WWW GUI,它們與執行實際 BitTorrent 操作的公共後端進行通訊,僅適用於 OSX、BSD 和 Linux。
    • Free Download Manager(FDM)(http://www.freedownloadmanager.org),使用 libtorrent 庫的 C++ 開源軟體,在 GNU GPL 下發布(僅限 Windows)。
    • torrent2exe.com,一個據稱將 .torrent 轉換為可執行檔案(Windows)以進行分發的網路工具,閉源,使用 libtorrent 庫。
    • Flushhttp://sourceforge.net/projects/flush)用於 Linux 的基於 GTK 的 BitTorrent 客戶端,開源 C++/GTK+,使用 libtorrent 庫。
    • Pump ( http://www.vipeers.com ) 是一款封閉原始碼的影片管理軟體,它支援 BitTorrent 協議,並使用 libtorrent 庫。
    • Lince ( http://lincetorrent.sourceforge.net ) 是一款開源 C++/GTK+/libtorrent BitTorrent 客戶端,根據 GNU GPL 許可證釋出(適用於 Linux/BSD/類 Unix 作業系統)。
    • Miro,之前被稱為 Democracy Player 和 DTV(http://getmiro.com),旨在自動下載來自 RSS 基於的“頻道”的影片,管理它們並播放它們。它是一款開源的 Python/GTK/libtorrent 軟體,根據 GNU 通用公共許可證的條款釋出。
    • tvitty ( http://tvitty.com ) 是一個封閉原始碼的 BitTorrent 下載外掛,用於 vista 媒體中心,它使用 libtorrent(僅適用於 Windows)。
    • FatRat ( http://fatrat.dolezel.info ) 是一款開源下載管理器,專為 Linux 而設計,使用 C++ 和 Qt4 以及 libtorrent 庫編寫。
    • LeechCraft ( http://leechcraft.org ) 是一款開源 BitTorrent 客戶端(也支援 HTTP/FTP 下載),使用 C++、Qt 和 libtorrent 編寫。根據 GNU 通用公共許可證釋出。
    • MooPolice ( http://www.moopolice.de ) 是一款適用於 Windows 的 BitTorrent 客戶端,擁有非傳統的 GUI。開源(沒有特定許可證)C++,使用 MFC 和 libtorrent BitTorrent 客戶端庫以及 MiniUPnP。
    • Linkage ( http://code.google.com/p/linkage ) 是一款輕量級的 BitTorrent 客戶端,使用 C++、gtkmm 和 libtorrent 編寫,根據 GNU 通用公共許可證釋出(不再維護)。
    • Arctic Torrent ( http://int64.org/projects/arctic-torrent ) 是一款適用於 Windows 的小型 BitTorrent 客戶端(包括 64 位版本)。開源 C++,根據 MIT 許可證釋出,使用 libtorrent。

特定 BitTorrent 論文

[edit | edit source]
  • 2003 年 5 月 22 日 - 激勵在 BitTorrent 中建立健壯性 (PDF),布拉姆·科恩
    BitTorrent 檔案分發系統使用針鋒相對作為尋求帕累託效率的方法。它實現了比任何已知合作技術更高的健壯性和資源利用率。我們將解釋 BitTorrent 的工作原理,以及如何使用經濟方法來實現該目標。

華夏公益教科書