zz-BitTorrent協議詳解

原文地址：

http://blog.csdn.net/jediluke11/archive/2004/11/16/183892.aspx

這個翻譯版本由孤波獨立完成
原文見 http://bitconjurer.org/BitTorrent/protocol.html
作者Bram Cohen
孤波享有對該翻譯版本解釋權修改權
非商業引用請註明譯者

目前處在Beta測試中，很不完善，請不要轉貼或引用
希望高人提出建議和指出錯誤錯誤不斷完善
尤其請注意後面幾段，我都不知道自己翻譯的什麼

我將在儘量3天內發出正式版本。


BitTorrent協議詳解

BitTrrent(簡稱BT，比特洪流)是一個文件分發協議，它通過URL識別內容並且和網絡無縫結合。它在HTTP平臺上的優勢在於，同時下在一個文件的下載者在下載的同時不斷互相上傳數據，使文件源可以在很有限的負載增加的情況下支持大量下載者同時下載。

一個BT式文件分發需要以下實體：

·一個普通網絡服務器
·一個靜態元信息文件
·一個BT Tracker
·一個“原始”下載者
·網絡終端瀏覽者
·網絡終端下載者

這裏假設理想情況下一個文件有多個下載者。

架設一個BT服務器步驟如下：

1.開始運行Tracker（已運行的跳過這一步）；
2.開始運行普通網絡服務器端程序，如Apache，已運行的跳過這一步；
3.在網絡服務器上將.torrent文件關聯到Mimetype類型application/x-bittorrent（已關聯的跳過這一步）；
4.用要發佈的完整文件和Tracker的URL創建一個元信息文件（.torrent文件）；
5.將元信息文件放置在網絡服務器上；
6.在網頁上發佈元信息文件（.torrent文件）鏈接；
7.原始下載者提供完整的文件（原本）。

通過BT下載步驟如下：

1.安裝BT客戶端程序（已安裝的跳過這一步）；
2.上網；
3.點擊一個鏈到.torrent文件的鏈接；
4.選擇本地存儲路徑，選定需要下載的文件（對有選擇下載功能的BT客戶端用戶）；
5.等待下載完成；
6.用戶退出下載（之前下載者不停止上傳）。

連接狀況如下：

·網站正常提供靜態文件連接，並且啓動客戶端上的BT程序；
·Tracker即時接收所有下載者信息，並且給每個下載者一份隨機的peer列表。通過HTTP或HTTPS協議實現；
·下載者每隔一段時間連一次Tracher，告知自己的進度，並和那些已經直接連接上的peer進行數據的上傳下載。這些連接遵循BitTorrent peer協議，通過TCP協議進行通信。
·原始下載者只上傳不下載，他擁有整個文件，所以很必要向網絡中傳輸完文件的所有部分。在一些人氣很旺的下載中，原始下載者經常可以在較短的時間內退出上傳，由其它已經下載到整個文件的下載者繼續提供上傳。

元信息文件和Tracker的迴應信息都以一種簡單高效可擴展的格式（Bencoding，B編碼）傳送。B編碼過的信息就是以包含字符串和整型數據的字典和列表的嵌套（像在Python中一樣）,可擴展性是指可以通過減少字典忽略的關鍵值來添加新的特性。

B編碼規則如下：

·字符串表示爲十進制數的既定字符串長度加冒號再跟原字符串。
如4:spam就相當於'spam'。
·整型數據表示成前面加'i'後面加'e'中間是十進制數，如i3e就相當於3，i-3e就是-3。整型數據沒有長度限制。i-0e無效，所有以'i0'開頭的除了代表0的i0e，其它都無效。
·列表編碼爲一個'l'開頭後面跟它所包含的項目（已經編碼過）最後加一個'e'，比如l4:spam4:eggse就等於['spam', 'eggs']。
·字典編碼爲一個'd'開頭後面跟一個交替關鍵值（key）及其對應值的列表最後加一個'e'。
如：d3:cow3:moo4:spam4:eggse相當於{'cow': 'moo', 'spam': 'eggs'}
d4:spaml1:a1:bee相當於{'spam': ['a', 'b']}
關鍵值必須是處理過的字符串（用原始字符串編碼的，而且不是數字字母混合編碼的）。

元信息文件就是B編碼的有以下關鍵值的字典：

announce（聲明）

Tracker的URL。

info（信息）

此關鍵值對應一個字典包含以下描述的關鍵值:

關鍵值name對應一個字符串，代表默認的下載文件或存成目錄的名字。它是純粹建議性的。

關鍵值piece length（塊長）對應文件分割成的塊的字節數。出於傳輸需要，文件被分割成大小相等的塊，除了最後一塊通常會小一些。塊長一般來說是2的權值，大部分設塊長爲256K(2的18次冪)。

關鍵值pieces（塊）對應一個字符串，此字符串長度是20的倍數。它可以再分成每20字節一段的多個字符串，分別對應塊在索引中的SHA1校驗碼（hash）。

還有關鍵值length（長度）和files（文件），它們不能同時出現也不能都不出現。當length出現說明這個元信息文件只是單文件下載，否則說明是多文件的目錄結構下載。

單文件情況下，length對應文件長度的字節數。

多文件情況被看作是把許多單文件按文件列表中的順序連成一個大文件下載，而關鍵值files就對應文件列表，是一個字典的列表，其中每個字典又包含以下關鍵值：

length（長度）

文件長度的字節數。

path（路徑）

一個包含字符串的列表，字符串就是子目錄名，最後一項的字符串是文件名。
（一個長度爲零的length表單是錯誤的。）

在單文件情況下，關鍵值name是文件名；多文件情況下，它就成了目錄名。

Tracker質詢是雙向的。Tracker通過HTTP GET參數獲得信息，然後返回一個B編碼後的信息。儘管Tracker需要在服務器端執行，但它運行流暢像Apache的一個模塊。

Tracker的GET請求有如下關鍵值：

info_hash

20字節長的SHA1驗證碼，來自B編碼過的元信息文件中的info值下，是元信息文件的一個支鏈。這個值是自動轉換的。

peer_id

一個20字節長的字符串，是每個用戶開始下載時隨機生成的ID。這個值也是是自動轉換的。

ip

一個可選擇的參數給出peer所在的IP（或DNS主機名），一般是和Tracker同機器的原始下載者得到後以便散發文件。

port

監聽端口，官方默認的是從6881端口開始試，如果端口被佔用則依次向後推一個端口找空閒端口，到6889端口爲止。

uploaded

目前總上傳量，編碼爲十進制ASCII碼。

downloaded

目前總下載量，編碼爲十進制ASCII碼。

left

未下載的字節數，編碼爲十進制ASCII碼。這個數不是通過文件長度和已下載數算出來的，因爲文件可能在被續傳，還有一些已經下載的數據不能通過完整性檢查必須重新下載。

event

這 是個選擇性的關鍵值，選項有started，completed或stopped（或empty，等同於沒有運行）。如果沒有運行，這個聲明會定期間隔一 定時間發出。開始下載時發出started值，完成下載時發出completed。當文件完整後再開始，沒有completed發出，下載者中止下載時發 出stopped。

Tracker的迴應也是B編碼字典。如果Tracker迴應中有關鍵值failure reason（失敗原因），就會對應一個人可以讀懂的字符串信息解釋質詢失敗的原因，不需要其它關鍵值。否則，迴應必須有兩個關鍵 值：interval（間隔）對應下載者定期發出請求的間隔秒數；peers，peer自選ID，IP地址或DNS主機名的字符串和端口號。記住 peers不會完全按照計劃的間隔發送請求，假如他們發生一個事件或者想要更多的peers。

如果你想對元信息文件或者Tracker質詢進行擴展，請與Bram Cohen進行協調，確保所有擴展都兼容。

BitTorrent peer協議通過TCP協議進行操作。它不用調節任何socket選項就可以流暢運行。

peer之間的連接是對稱的。兩個方向送出的信息要協調一致，數據可以流入任一方。

peer協議指一個peer從零開始下載，每得到元信息文件索引中所描述的一個塊且驗證碼一致，就向所有peer聲明已得到此塊。

連接的兩個終端有2個狀態指標，被阻塞與否，被關注與否，被阻塞（choking）是表明在恢復通暢之前數據不再發出的通知。發生阻塞的原因和技術問題稍後會提到。

數 據傳輸發生在一方關注對方且對方沒有阻塞的情況下。關注狀態必須一致保持-如果一個沒阻塞的peer沒有別人需要的數據，別人對他就會失去關注，轉而關注 那些正在阻塞的peer。完全執行這種條件需要非常慎重，但這樣的確可以讓下載者知道哪些peer在阻塞消失後可以馬上開始下載。

連接會逐漸斷開不感興趣和阻塞的peer。

當數據傳輸時，下載者要備好多份請求排成隊列，以獲得較高的TCP傳輸效率（這叫“管運請求”）。另一方面，不能被寫入TCP緩衝區的請求要被立即排入內存，而不是一個應用程序級的網絡緩衝，一旦阻塞出現，這些請求全部丟棄。

peer連線協議包括一次握手跟着不斷的大小一致且確定的信息流。握手的開始是字符十九（十進制），跟着是字符串'BitTorrentprotocol'。開頭的字符是長度固定的，希望其它新協議也能這樣以便區分。

此後所有送入協議的整數都編碼爲4字節大中止端。

在現有的應用中頭部數據之後是8個全部預留爲0的字節，若果你想通過改變這8個預留字節以擴展協議，請與Bram Cohen協調以保證所有擴展兼容。

然 後是來自元信息文件中B編碼的info值中長20字節的SHA1驗證碼（和info_hash向Tracker聲明的值相同，但這裏是原始值那裏是引 用）。如果雙方的值不同，連接斷開。一個例外是下載者想只用一個端口進行多個連接下載，它們會先從接入連接得到一個驗證碼，然後和列表裏面的對照，有相同 的就答覆。

驗證碼之後是20字節的peer id，它包含在Tracker迴應的peer列表中，在向Tracker的請求中被報告。如果接受方peer id不符合發送方希望，連接斷開。

握手完畢。之後是長度固定的交互信息流。零長度信息用來保持連接，被忽略。這種信息一般2分鐘發出一次，但是在等待數據期間很容易超時。

所有非保持連接用信息開頭的字節給出類型，可能值如下：

·0-阻塞
·1-通暢
·2-關注
·3-不關注
·4-有
·5-比特組
·6-請求
·7-塊
·8-取消

“阻塞”、“通暢”、“關注”和“不關注”類信息沒有荷載。

“比特組”類信息僅作爲首信息發出。它負載一個比特組，下載者有索引的設爲1，其它爲0。開始下載時沒有任何數據的下載者跳過“比特組”信息。首字節高位到低位對應索引0-7，依次類推，第二字節對應8-15，等等。尾部的剩餘的比特位設爲0。

“已有”類信息負載一個數，即剛下載並覈對完驗證碼的索引數。

“請求”類信息包括包含一個索引，開始和長度。後兩者是字節偏移。長度一般是2的權值除非被文件尾截斷。現行一般是2的15次冪，並且關閉大於2的17次冪長度的連接。

“ 取消”類信息負載和“請求”類信息有一樣的負載。它通常在下載接近完成即“最後階段”發出。當下載快要完成時，剩下幾個塊有都從同一個線程下載的趨向，這 樣會很慢。爲了確保剩餘塊下載迅速，一旦還沒有決定剩餘塊的下載請求向誰發出，先向所有他正在從對方下載數據的連接者發送要求所有剩餘塊的請求。爲避免低 效，每當一個塊開始下載就向其他peer發出取消信息。

“塊”類信息包含一個索引，開始和塊。記住它和“請求”類信息是相關的。當傳輸速度很慢或“阻塞”“通暢”類信息高頻率交替發出或兩者同時發生，可能會載到一個不需要的塊。

下載者下載塊的順序是隨機的，這樣適當防止下載者與其他Peers僅有相同的塊子集或超集。

阻塞的發生有很多原因。TCP協議的信息擁擠控制在即時向多連接發送信息的過程中表現極差。同時，阻塞的存在使下載者們能夠用以牙還牙式的算法來確保穩定的下載速率。

下面描述的阻塞算法是目前基礎的配置。重要的是所有新算法不光要在包含全部擴展算法的網絡中運行良好，也要在主要包含這個基礎算法的網絡中運行良好。

一 個優秀的阻塞算法有許多標準。它必須封鎖一定同時上傳的數量以獲得良好的TCP表現，還要避免頻繁的堵塞和通暢交替，即所謂“纖維化”。它應該用數據交換 報答給自己數據的peer。最後，它還應該偶爾嘗試一下與未使用過的peer端連接，找出比現有連接好的連接，這叫做嘗試性疏通。

現行的 阻塞算法避免纖維化的手段是每10秒轉換被阻塞的名單。疏通4個自己關注且能從他們身上得到最高下載速率的peer，進行上傳和數據交換。有較高上傳速率 但是不被關注下載者的peer被疏通，一旦這些peer開始被關注，那些上傳率最低的peer的就被阻塞。如果下載者有了完整的文件，他用自己的上傳率而 不是下載率來決定疏通誰的連接。

在嘗試性疏通中，任何一次中都有一個peer被疏通不管他的上傳率如何（如果被關注，他會成爲4個提供下載的peer之一）。被嘗試性疏通的這種peer每30秒輪換一次。爲了給它們一個上傳整一個塊的機會，新連接會以輪換中嘗試性疏通次數的3倍開始連接。