BitTorrent 協議規範（BT協議集合）

BitTorrent 協議規範（BT協議集合）

翻譯：小馬哥
日期：2004-5-22
BitTorrent 是一種分發文件的協議。它通過URL來識別內容，並且可以無縫的和web進行交互。它基於HTTP協議，它的優勢是：如果有多個下載者併發的下載同一個文件，那麼，每個下載者也同時爲其它下載者上傳文件，這樣，文件源可以支持大量的用戶進行下載，而只帶來適當的負載的增長。（譯註：因爲大量的負載被均衡到整個系統中，所以提供源文件的機器的負載只有少量增長）

一個BT文件分佈系統由下列實體組成：
一個普通的web服務器
一個靜態的“元信息”文件
一個跟蹤（tracker）服務器
終端用戶的web瀏覽器
終端下載者

理想的情況是多個終端用戶在下載同一個文件。
要提供文件共享，那麼一臺主機需要執行以下步驟：
Ø運行一個 tracker服務器（或者，已經有一個tracker服務器在運行了也可以）
Ø運行一個web服務器，例如apache，或者已經有一個web服務器在運行了。
Ø在web服務器上，將文件擴展名.torrent 和MIME類型 application/x-bittorrent關聯起來（或者已經關聯了）
Ø根據 tracker服務器的 URL 和要共享的文件來創建一個“元信息”文件（.torrent）。
Ø將“元信息”文件發佈到web服務器上
Ø在某個web頁面上，添加一個到“元信息”文件的鏈接。
Ø運行一個已經擁有完整文件的下載者（被成爲’origin’，或者’seed’，種子）

要開始下載文件，那麼終端用戶執行以下步驟：
Ø安裝 BT（或者已經安裝）
Ø訪問提供 .torrent 文件的web服務器
Ø點擊到 .torrent 文件的鏈接（譯註：這時候，bt會彈出一個對話框）
Ø選擇要把下載的文件保存到哪裏？或者是一次斷點續傳
Ø等待下載的完成。
Ø結束bt程序的運行（如果不主動結束，那麼bt會一直爲其它人提供文件上傳）

各個部分之間的連通性如下：
網站負責提供一個靜態的文件，而把BT輔助程序（客戶端）放在客戶端機器上。
Trackers從所有下載者處接收信息，並返回給它們一個隨機的peers的列表。這種交互是通過HTTP或HTTPS協議來完成的。
下載者週期性的向tracker登記，使得tracker能瞭解它們的進度；下載者之間通過直接連接進行數據的上傳和下載。這種連接使用的是 BitTorrent 對等協議，它基於TCP。
Origin只負責上傳，從不下載，因爲它已經擁有了完整的文件。Origin是必須的。

元文件和tracker的響應都採用的是一種簡單、有效、可擴展的格式，被稱爲bencoding，它可以包含字符串和整數。由於對不需要的字典關鍵字可以忽略，所以這種格式具有可擴展性，其它選項以後可以方便的加進來。

Bencoding格式如下：
對於字符串，首先是一個字符串的長度，然後是冒號，後面跟着實際的字符串，例如：4:spam，就是“ spam”
整數編碼如下，以 ‘i’ 開始，然後10進制的整數值，最後以’e’結尾。例如，i3e表示3，I-3e表示-3。整數沒有大小限制。I-0e是無效的。除了 i0e外，所以以0起始的整數都無效。I0e當然表示0。
列表編碼如下，以’l’開始，接下來是列表值的編碼（也採用bencoded編碼），最後以’e’結束。例如：l4:spam4:eggse 表示 [‘spam’, ‘eggs’]。
字典編碼如下，以’d’開始，接下來是可選的keys和它對應的值，最戶以’e’結束。例如：d3:cow3:moo4:spam4:eggse，表示{‘cow’:’moo’,’spam’:’eggs’}，而d4:spaml1:al:bee 表示 {‘spam’:[‘a’,’b’]}。鍵值必須是字符串，而且已經排序（並非是按照字母順序排序，而是根據原始的字符串進行排序）。

元文件是採用bencoded編碼的字典，包括以下關鍵字：

announce tracker的服務器

info 它實際上是一個字典，包括以下關鍵字：

Name：
一個字符串，在保存文件的時候，作爲一個建議值。僅僅是個建議而已，你可以用別的名字保存文件。
Piece length：
爲了更好的傳輸，文件被分隔成等長的片斷，除了最後一個片斷以外，這個值就是片斷的大小。片斷大小几乎一直都是2的冪，最常用的是 256k（BT的前一個版本3.2，用的是1M作爲默認大小）
Pieces：
一個長度爲20的整數倍的字符串。它將再被分隔爲20字節長的字符串，每個子串都是相應片斷的hash值。

此外，還有一個length或files的關鍵字，這兩個關鍵字只能出現一個。如果是length，那麼表示要下載的僅僅是單個文件，如果是files那麼要下載的是一個目錄中的多個文件。
如果是單個文件，那麼length是該文件的長度。

爲了能支持其它關鍵字，對於多個文件的情況，也把它當作一個文件來看，也就是按照文件出現的順序，把每個文件的信息連接起來，形成一個字符串。每個文件的信息實際上也是一個字典，包括以下關鍵字：
Length：文件長度
Path：子目錄名稱的列表，列表最後一項是文件的實際名稱。（不允許出現列表爲空的情況）。
Name：在單文件情況下，name是文件的名稱，而在多文件情況下，name是目錄的名稱。

Tracker查詢。Trakcer通過HTTP的GET命令的參數來接收信息，而響應給對方（也就是下載者）的是經過bencoded編碼的消息。注意，儘管當前的tracker的實現需要一個web服務器，它實際上可以運行的更輕便一些，例如，作爲apache的一個模塊。
Tracker GET requests have the following keys:

發送給Tracker的GET請求，包含以下關鍵字：

Info_hash：
元文件中info部分的sha hash，20字節長。這個字符創幾乎肯定需要被轉義（譯註：在URL中，有些字符不能出現，必須通過unicode進行編碼）

Peer_id：
下載者的id，一個20字節長的字符串。每個下載者在開始一次新的下載之前，需要隨機創建這個id。這個字符串通常也需要被轉義。

Ip：
一個可選的參數，給出了peer的ip地址（或者dns名稱？）。通常用在origin身上，如果它和tracker在同一個機器上。

Port：
peer所監聽的端口。下載者通常在在 6881 端口上監聽，如果該端口被佔用，那麼會一直嘗試到 6889，如果都被佔用，那麼就放棄監聽。

Uploaded：
已經上載的數據大小，十進制表示。

Downloaded：
已經下載的數據大小，十進制表示

Left：
該peer還有多少數據沒有下載完，十進制表示。注意，這個值不能根據文件長度和已下載數據大小計算出來，因爲很可能是斷點續傳，如果因爲檢查文件完整性失敗而必須重新下載的時候，這也提供了一個機會。

Event：
一個可選的關鍵字，值是started、compted或者stopped之一（也可以爲空，不做處理）。如果不出現該關鍵字，。在一次下載剛開始的時候，該值被設置爲started，在下載完成之後，設置爲completed。如果下載者停止了下載，那麼該值設置爲stopped。

Tracker的響應是用bencoded編碼的字典。如果tracker的響應中有一個關鍵字failure reason，那麼它對應的是一個字符串，用來解釋查詢失敗的原因，其它關鍵字都不再需要了。否則，它必須有兩個關鍵字：Interval：下載者在兩次發送請求之間的時間間隔。Peers:一個字典的列表，每個字典包括以下關鍵字：Peer id，Ip，Port，分別對應peer所選擇的id、ip地址或者dns名稱、端口號。注意，如果某些事件發生，或者需要更多的peers，那麼下載者可能不定期的發送請求，

（downloader 通過 HTTP 的GET 命令來向 tracker 發送查詢請求，tracker 響應一個peers 的列表）

如果你想對元信息文件或者tracker查詢進行擴展，那麼需要同Bram Cohen協調，以確保所有的擴展都是兼容的。

BT對等協議基於TCP，它很有效率，並不需要設置任何socket選項。（譯註：BT對等協議指的是peer與peer之間交換信息的協議）
對等的兩個連接是對稱的，消息在兩個方向上同樣的傳遞，數據也可以在任何一個方向上流動。
一旦某個peer下載完了一個片斷，並且也檢查了它的完整性，那麼它就向它所有的peers宣佈它擁有了這個片斷。
連接的任何一端都包含兩比特的狀態信息：是否choked，是否感興趣。Choking是通知對方，沒有數據可以發送，除非unchoking發生。Choking的原因以及技術後文解釋。

一旦一端狀態變爲interested，而另一端變爲非choking，那麼數據傳輸就開始了。（也就是說，一個peer，如果想從它的某個peer那裏得到數據，那麼，它首先必須將它兩之間的連接設置爲 interested，其實就是發一個消息過去，而另一個peer，要檢查它是否應該給這個傢伙發送數據，如果它對這個傢伙是 unchoke，那麼就可以給它發數據，否則還是不能給它數據）Interested狀態必須一直被設置――任何時候。要用點技巧才能比較好的實現這個目的，但它使得下載者能夠立刻知道哪些peers將開始下載。

對等協議由一個握手開始，後面是循環的消息流，每個消息的前面，都有一個數字來表示消息的長度。握手的過程首先是先發送19，然後發送“BitTorrent protocol”。19就是“BitTorrent protocol”的長度。
後續的所有的整數，都採用big-endian 來編碼爲4個字節
在協議名稱之後，是8個保留的字節，這些字節當前都設置爲0。
接下來對元文件中的 info 信息，通過 sha1 計算後得到的 hash值，20個字節長。接收消息方，也會對 info 進行一個 hash 運算，如果這兩個結果不一樣，那麼說明對方要的文件，並不是自己所要提供的，所以切斷連接。

接下來是20個字節的 peer id。
這就是握手過程

接下來就是以消息長度開始的消息流，這是可選的。長度爲0 的消息，用於保持連接的活動狀態，被忽略。通常每隔2分鐘發送一個這樣的消息。

其它類型的消息，都有一個字節長的消息類型，可能的值如下：

‘choke’, ‘unchoe’, ‘interested’, not interested’類型的消息不再含有其它數據了。

‘bitfield’永遠也僅僅是第一個被髮送的消息。它的數據實際是一個位圖，如果downloader已經發送了某個片斷，那麼對應的位置1，否則置0。Downloaders如果一個片斷也沒有，可以忽略這個消息。（通過這個消息，能知道什麼了？）

‘have’類型的消息，後面的數據是一個簡單的數字，它是下載者剛剛下載完並檢查過完整性的片斷的索引。（由此，可以看到，peer通過這種消息，很快就相互瞭解了誰都有什麼片斷）

‘request’類型的消息，後面包含索引、開始位置和長度)長度是2的冪。當前的實現都用的是215 ，而關閉連接的時候，請求一個超過2 17的長度。(這種類型的消息，就是當一個peer希望另一個peer給它提供片斷的時候，發出的請求)

‘cancel’類型的消息，它的數據和’request’消息一樣。它們通常只在下載趨向完成的時候發送，也就是在‘結束模式“階段發送。在一次下載接近完成的時候，最後的幾個片斷需要很長時間才能下載完。爲了確保最後幾個片斷儘快下載完，它向所有的peers發送下載請求。爲了保證這不帶來可怕的低效，一旦某個片斷下載完成，它就其它peers發送’cancel’消息。（意思就是說，我不要這個片斷了，你要是準備好了，也不用給我發了，可以想象，如果對方還是把數據發送過來了，那麼這邊必須忽略這些重複的數據）。

‘piece’類型的消息，後面保護索引號、開始位置和實際的數據。注意，這種類型的消息和 ‘request’消息之間有潛在的聯繫（譯註：因爲通常有了request消息之後，纔會響應‘piece’消息）。如果choke和unchoke消息發送的過於迅速，或者，傳輸速度變的很慢，那麼可能會讀到一些並不是所期望的片斷。（ 也就是說，有時候讀到了一些片斷，但這些片斷並不是所想要的）