BitTorrent DHT 協議中文翻譯

發表於2015-02-01

前言

做了一個磁力連結和BT種子的搜尋引擎 {Magnet & Torrent}，因此把 DHT 協議重新看了一遍。

BitTorrent 使用"分散式雜湊表"(DHT)來為無 tracker 的種子(torrents)儲存 peer 之間的聯絡資訊。這樣每個 peer 都成了 tracker。這個協議基於 Kademila[1] 網路並且在 UDP 上實現。

請注意本文件中使用的術語，以免混亂。

"peer" 是在一個 TCP 埠上監聽的客戶端/伺服器，它實現了 BitTorrent 協議。
"節點" 是在一個 UDP 埠上監聽的客戶端/伺服器，它實現了 DHT(分散式雜湊表) 協議。

DHT 由節點組成，它儲存了 peer 的位置。BitTorrent 客戶端包含一個 DHT 節點，這個節點用來聯絡 DHT 中其他節點，從而得到 peer 的位置，進而通過 BitTorrent 協議下載。

概述 Overview

每個節點有一個全域性唯一的識別符號，作為 "node ID"。節點 ID 是一個隨機選擇的 160bit 空間，BitTorrent infohash[2] 也使用這樣的 160bit 空間。
"距離"用來比較兩個節點 ID 之間或者節點 ID 和 infohash 之間的"遠近"。節點必須維護一個路由表，路由表中含有一部分其它節點的聯絡資訊。其它節點距離自己越近時，路由表資訊越詳細。因此每個節點都知道 DHT 中離自己很"近"的節點的聯絡資訊，而離自己非常遠的 ID 的聯絡資訊卻知道的很少。

在 Kademlia 網路中，距離是通過異或(XOR)計算的，結果為無符號整數。distance(A, B) = |A xor B|，值越小表示越近。

當節點要為 torrent 尋找 peer 時，它將自己路由表中的節點 ID 和 torrent 的 infohash 進行"距離對比"。然後向路由表中離 infohash 最近的節點傳送請求，問它們正在下載這個 torrent 的 peer 的聯絡資訊。如果一個被聯絡的節點知道下載這個 torrent 的 peer 資訊，那個 peer 的聯絡資訊將被回覆給當前節點。否則，那個被聯絡的節點則必須回覆在它的路由表中離該 torrent 的 infohash 最近的節點的聯絡資訊。最初的節點重複地請求比目標 infohash 更近的節點，直到不能再找到更近的節點為止。查詢完了之後，客戶端把自己作為一個 peer 插入到所有回覆節點中離種子最近的那個節點中。

請求 peer 的返回值包含一個不透明的值，稱之為"令牌(token)"。如果一個節點宣佈它所控制的 peer 正在下載一個種子，它必須在回覆請求節點的同時，附加上對方向我們傳送的最近的"令牌(token)"。這樣當一個節點試圖"宣佈"正在下載一個種子時，被請求的節點核對令牌和發出請求的節點的 IP 地址。這是為了防止惡意的主機登記其它主機的種子。由於令牌僅僅由請求節點返回給收到令牌的同一個節點，所以沒有規定他的具體實現。但是令牌必須在一個規定的時間內被接受，超時後令牌則失效。在 BitTorrent 的實現中，token 是在 IP 地址後面連線一個 secret(通常是一個隨機數)，這個 secret 每五分鐘改變一次，其中 token 在十分鐘以內是可接受的。

路由表 Routing Table

每個節點維護一個路由表儲存已知的好節點。路由表中的節點是用來作為在 DHT 中請求的起始點。路由表中的節點是在不斷的向其他節點請求過程中，對方節點回復的。

並不是我們在請求過程中收到得節點都是平等的，有的節點是好的，而另一些則不是。許多使用 DHT 協議的節點都可以傳送請求並接收回復，但是不能主動回覆其他節點的請求。節點的路由表只包含已知的好節點，這很重要。好節點是指在過去的 15 分鐘以內，曾經對我們的某一個請求給出過回覆的節點，或者曾經對我們的請求給出過一個回覆(不用在15分鐘以內)，並且在過去的 15 分鐘給我們傳送過請求。上述兩種情況都可將節點視為好節點。在 15 分鐘之後，對方沒有上述 2 種情況發生，這個節點將變為可疑的。當節點不能給我們的一系列請求給出回覆時，這個節點將變為壞的。相比那些未知狀態的節點，已知的好節點會被給於更高的優先順序。

路由表覆蓋從 0 到 2^160 全部的節點 ID 空間。路由表又被劃分為桶(bucket)，每個桶包含一部分的 ID 空間。空的路由表只有一個桶，它的 ID 範圍從 min=0 到 max=2^160。當 ID 為 N 的節點插入到表中時，它將被放到 ID 範圍在 min <= N < max 的桶中。空的路由表只有一個桶，所以所有的節點都將被放到這個桶中。每個桶最多隻能儲存 K 個節點，當前 K=8。當一個桶放滿了好節點之後，將不再允許新的節點加入，除非我們自身的節點 ID 在這個桶的範圍內。在這樣的情況下，這個桶將被分裂為 2 個新的桶，每個新桶的範圍都是原來舊桶的一半。原來舊桶中的節點將被重新分配到這兩個新的桶中。如果一個新表只有一個桶，這個包含整個範圍的桶將總被分裂為 2 個新的桶，每個桶的覆蓋範圍從 0..2^159 和 2^159..2^160。

當桶裝滿了好節點，新的節點會被丟棄。一旦桶中的某個節點變為了壞的節點，那麼我們就用新的節點來替換這個壞的節點。如果桶中有在 15 分鐘內都沒有活躍過的節點，我們將這樣的節點視為可疑的節點，這時我們向最久沒有聯絡的節點傳送 ping。如果被 ping 的節點給出了回覆，那麼我們向下一個可疑的節點傳送 ping，不斷這樣迴圈下去，直到有某一個節點沒有給出 ping 的回覆，或者當前桶中的所有節點都是好的(也就是所有節點都不是可疑節點，他們在過去 15 分鐘內都有活動)。如果桶中的某個節點沒有對我們的 ping 給出回覆，我們最好再試一次(再傳送一次 ping，因為這個節點也許仍然是活躍的，但由於網路擁塞，所以發生了丟包現象，注意 DHT 的包都是 UDP 的)，而不是立即丟棄這個節點或者直接用新節點來替代它。這樣，我們得路由表將充滿穩定的長時間線上的節點。

每個桶都應該維持一個 lastchange 欄位來表明桶中節點的"新鮮"度。當桶中的節點被 ping 並給出了回覆，或者一個節點被加入到了桶，或者一個節點被新的節點所替代，桶的 lastchange 欄位都應當被更新。如果一個桶的 lastchange 在過去的 15 分鐘內都沒有變化，那麼我們將更新它。這個更新桶操作是這樣完成的：從這個桶所覆蓋的範圍中隨機選擇一個 ID，並對這個 ID 執行 find_nodes 查詢操作。常常收到請求的節點通常不需要常常更新自己的桶，反之，不常常收到請求的節點常常需要週期性的執行更新所有桶的操作，這樣才能保證當我們用到 DHT 的時候，裡面有足夠多的好的節點。

在插入第一個節點到路由表並啟動服務後，這個節點應試著查詢 DHT 中離自己更近的節點，這個查詢工作是通過不斷的發出 find_node 訊息給越來越近的節點來完成的，當不能找到更近的節點時，這個擴散工作就結束了。路由表應當被啟動工作和客戶端軟體儲存（也就是啟動的時候從客戶端中讀取路由表資訊，結束的時候客戶端軟體記錄到檔案中）。

BitTorrent 協議擴充套件 BitTorrent Protocol Extension

BitTorrent 協議已經被擴充套件為可以在通過 tracker 得到的 peer 之間互相交換節點的 UDP 埠號(也就是告訴對方我們的 DHT 服務埠號)，在這樣的方式下，客戶端可以通過下載普通的種子檔案來自動擴充套件 DHT 路由表。新安裝的客戶端第一次試著下載一個無 tracker 的種子時，它的路由表中將沒有任何節點，這是它需要在 torrent 檔案中找到聯絡資訊。

peers 如果支援 DHT 協議就將 BitTorrent 協議握手訊息的保留位的第 8 位元組的最後一位置為 1。這時如果 peer 收到一個 handshake 表明對方支援 DHT 協議，就應該傳送 PORT 訊息。它由位元組 0x09 開始，payload 的長度是 2 個位元組，包含了這個 peer 的 DHT 服務使用的網路位元組序的 UDP 埠號。當 peer 收到這樣的訊息是應當向對方的 IP 和訊息中指定的埠號的節點傳送 ping。如果收到了 ping 的回覆，那麼應當使用上述的方法將新節點的聯絡資訊加入到路由表中。

Torrent 檔案擴充套件 Torrent File Extensions

一個無 tracker 的 torrent 檔案字典不包含 announce 關鍵字，而使用 nodes 關鍵字來替代。這個關鍵字對應的內容應該設定為 torrent 建立者的路由表中 K 個最接近的節點。可供選擇的，這個關鍵字也可以設定為一個已知的可用節點，比如這個 torrent 檔案的建立者。請不要自動加入 router.bittorrent.com 到 torrent 檔案中或者自動加入這個節點到客戶端路由表中。

nodes = [["<host>", <port>], ["<host>", <port>], ...]
nodes = [["127.0.0.1", 6881], ["your.router.node", 4804]]

KRPC 協議 KRPC Protocol

KRPC 協議是由 bencode 編碼組成的一個簡單的 RPC 結構，他使用 UDP 報文傳送。一個獨立的請求包被髮出去然後一個獨立的包被回覆。這個協議沒有重發。它包含 3 種訊息：請求，回覆和錯誤。對DHT協議而言，這裡有 4 種請求：ping，find_node，get_peers 和 announce_peer。

一條 KRPC 訊息由一個獨立的字典組成，其中有 2 個關鍵字是所有的訊息都包含的，其餘的附加關鍵字取決於訊息型別。每條訊息都包含 t 關鍵字，它是一個代表了 transaction ID 的字串型別。transaction ID 由請求節點產生，並且回覆中要包含回顯該欄位，所以回覆可能對應一個節點的多個請求。transaction ID 應當被編碼為一個短的二進位制字串，比如 2 個位元組，這樣就可以對應 2^16 個請求。另外每個 KRPC 訊息還應該包含的關鍵字是 y，它由一個位元組組成，表明這個訊息的型別。y 對應的值有三種情況：q 表示請求，r 表示回覆，e 表示錯誤。

聯絡資訊編碼 Contact Encoding

Peers 的聯絡資訊被編碼為 6 位元組的字串。又被稱為 "CompactIP-address/port info"，其中前 4 個位元組是網路位元組序的 IP 地址，後 2 個位元組是網路位元組序的埠。

節點的聯絡資訊被編碼為 26 位元組的字串。又被稱為 "Compactnode info"，其中前 20 位元組是網路位元組序的節點 ID，後面 6 個位元組是 peers 的 "CompactIP-address/port info"。

請求 Queries

請求，對應於 KPRC 訊息字典中的 y 關鍵字的值是 q，它包含 2 個附加的關鍵字 q 和 a。關鍵字 q 是字串型別，包含了請求的方法名字。關鍵字 a 一個字典型別包含了請求所附加的引數。

回覆 Responses

回覆，對應於 KPRC 訊息字典中的 y 關鍵字的值是 r，包含了一個附加的關鍵字 r。關鍵字 r 是字典型別，包含了返回的值。傳送回覆訊息是在正確解析了請求訊息的基礎上完成的。

錯誤 Errors

錯誤，對應於 KPRC 訊息字典中的 y 關鍵字的值是 e，包含一個附加的關鍵字 e。關鍵字 e 是列表型別。第一個元素是數字型別，表明了錯誤碼。第二個元素是字串型別，表明了錯誤資訊。當一個請求不能解析或出錯時，錯誤包將被髮送。下表描述了可能出現的錯誤碼：

201 一般錯誤
202 服務錯誤
203 協議錯誤，比如不規範的包，無效的引數，或者錯誤的 toke
204 未知方法

錯誤包例子 Example Error Packets:

generic error = {"t":"aa", "y":"e", "e":[201, "A Generic Error Ocurred"]}
bencoded = d1:eli201e23:A Generic Error Ocurrede1:t2:aa1:y1:ee

DHT 請求 DHT Queries

所有的請求都包含一個關鍵字 id，它包含了請求節點的節點 ID。所有的回覆也包含關鍵字id，它包含了回覆節點的節點 ID。

ping

最基礎的請求就是 ping。這時 KPRC 協議中的 "q" = "ping"。Ping 請求包含一個引數 id，它是一個 20 位元組的字串包含了傳送者網路位元組序的節點 ID。對應的 ping 回覆也包含一個引數 id，包含了回覆者的節點 ID。

引數: {"id" : "<querying nodes id>"}
回覆: {"id" : "<queried nodes id>"}

報文包例子 Example Packets

ping Query = {"t":"aa", "y":"q", "q":"ping", "a":{"id":"abcdefghij0123456789"}}
bencoded = d1:ad2:id20:abcdefghij0123456789e1:q4:ping1:t2:aa1:y1:qe
Response = {"t":"aa", "y":"r", "r": {"id":"mnopqrstuvwxyz123456"}}
bencoded = d1:rd2:id20:mnopqrstuvwxyz123456e1:t2:aa1:y1:re

find_node

find_node 被用來查詢給定 ID 的節點的聯絡資訊。這時 KPRC 協議中的 "q" == "find_node"。find_node 請求包含 2 個引數，第一個引數是 id，包含了請求節點的ID。第二個引數是 target，包含了請求者正在查詢的節點的 ID。當一個節點接收到了 find_node 的請求，他應該給出對應的回覆，回覆中包含 2 個關鍵字 id 和 nodes，nodes 是字串型別，包含了被請求節點的路由表中最接近目標節點的 K(8) 個最接近的節點的聯絡資訊。

引數: {"id" : "<querying nodes id>", "target" : "<id of target node>"}
回覆: {"id" : "<queried nodes id>", "nodes" : "<compact node info>"}

報文包例子 Example Packets

find_node Query = {"t":"aa", "y":"q", "q":"find_node", "a": {"id":"abcdefghij0123456789", "target":"mnopqrstuvwxyz123456"}}
bencoded = d1:ad2:id20:abcdefghij01234567896:target20:mnopqrstuvwxyz123456e1:q9:find_node1:t2:aa1:y1:qe
Response = {"t":"aa", "y":"r", "r": {"id":"0123456789abcdefghij", "nodes": "def456..."}}
bencoded = d1:rd2:id20:0123456789abcdefghij5:nodes9:def456...e1:t2:aa1:y1:re

get_peers

get_peers 與 torrent 檔案的 infohash 有關。這時 KPRC 協議中的 "q" = "get_peers"。get_peers 請求包含 2 個引數。第一個引數是 id，包含了請求節點的 ID。第二個引數是 info_hash，它代表 torrent 檔案的 infohash。如果被請求的節點有對應 info_hash 的 peers，他將返回一個關鍵字 values，這是一個列表型別的字串。每一個字串包含了 "CompactIP-address/portinfo" 格式的 peers 資訊。如果被請求的節點沒有這個 infohash 的 peers，那麼他將返回關鍵字 nodes，這個關鍵字包含了被請求節點的路由表中離 info_hash 最近的 K 個節點，使用 "Compactnodeinfo" 格式回覆。在這兩種情況下，關鍵字 token 都將被返回。token 關鍵字在今後的 annouce_peer 請求中必須要攜帶。token 是一個短的二進位制字串。

引數: {"id" : "<querying nodes id>", "info_hash" : "<20-byte infohash of target torrent>"}
回覆: {"id" : "<queried nodes id>", "token" :"<opaque write token>", "values" : ["<peer 1 info string>", "<peer 2 info string>"]}
或: {"id" : "<queried nodes id>", "token" :"<opaque write token>", "nodes" : "<compact node info>"}

報文包例子 Example Packets:

get_peers Query = {"t":"aa", "y":"q", "q":"get_peers", "a": {"id":"abcdefghij0123456789", "info_hash":"mnopqrstuvwxyz123456"}}
bencoded = d1:ad2:id20:abcdefghij01234567899:info_hash20:mnopqrstuvwxyz123456e1:q9:get_peers1:t2:aa1:y1:qe
Response with peers = {"t":"aa", "y":"r", "r": {"id":"abcdefghij0123456789", "token":"aoeusnth", "values": ["axje.u", "idhtnm"]}}
bencoded = d1:rd2:id20:abcdefghij01234567895:token8:aoeusnth6:valuesl6:axje.u6:idhtnmee1:t2:aa1:y1:re
Response with closest nodes = {"t":"aa", "y":"r", "r": {"id":"abcdefghij0123456789", "token":"aoeusnth", "nodes": "def456..."}}
bencoded = d1:rd2:id20:abcdefghij01234567895:nodes9:def456...5:token8:aoeusnthe1:t2:aa1:y1:re

announce_peer

這個請求用來表明發出 announce_peer 請求的節點，正在某個埠下載 torrent 檔案。announce_peer 包含 4 個引數。第一個引數是 id，包含了請求節點的 ID；第二個引數是 info_hash，包含了 torrent 檔案的 infohash；第三個引數是 port 包含了整型的埠號，表明 peer 在哪個埠下載；第四個引數數是 token，這是在之前的 get_peers 請求中收到的回覆中包含的。收到 announce_peer 請求的節點必須檢查這個 token 與之前我們回覆給這個節點 get_peers 的 token 是否相同。如果相同，那麼被請求的節點將記錄傳送 announce_peer 節點的 IP 和請求中包含的 port 埠號在 peer 聯絡資訊中對應的 infohash 下。

引數: {"id" : "<querying nodes id>", "implied_port": <0 or 1>, "info_hash" : "<20-byte infohash of target torrent>", "port" : <port number>, "token" : "<opaque token>"}
回覆: {"id" : "<queried nodes id>"}