譯者前序

DHT協議早在2005年就已經成為了官方BitTorrent協議的一部份，但是我竟然一直沒有找到國內的官方翻譯稿，所以將其進行翻譯，若文中錯誤，歡迎各位指正。

其次，若想徹底理解DHT協議的原理，建議各位閱讀Kademlia協議，在本部落格中，有其翻譯稿，參見DHT協議基礎1，2.

DHT協議

BitTorrent使用一種叫做分散式雜湊表(distributedsloppy hashtable)的技術，來實現在無tracker的torrent檔案中peer的聯絡資訊儲存。這個時候，每個peer都是一個tracker。這個協議是基於Kademila協議的，並且在UDP協議基礎上實現。

請注意本文件所使用的術語以免引起混淆。“peer”是一個實現了BT協議，且正在監聽TCP埠的client/server。“node”是實現了DHT協議的，且正在監聽UDP埠的client/server。DHT由nodes組成並儲存peer的位置資訊。BitTorrent客戶端也包括DHTnode，這個DHTnode主要是用來聯絡DHT中的其他nodes，以得peer的位置資訊，從而通過BitTorrent協議下載。

概述

每一個node都有一個全域性的唯一標識“nodeID”。NodeIDS的產生是隨機的，且使用與BitTorrent的infohashes相同的160-bit空間。“distancemetric”

用來比較2個nodeIDs或者nodeID與infohash的接近程度。Nodes必須維護一個路由表，其中儲存了一部分其他nodes的聯絡資訊。越接近自身節點時，路由表的資訊會更加詳細。nodes儲存了很多接近自己的節點，但是離自己很遠的節點的聯絡資訊確知道得很少。

在Kademlia中，“distancemetric”採用XOR異或計算，並轉換為一個無符號整數。distance(A,B)= |A xor B| ，並且距離越小表示2個節點越接近。

當一個node想得到某個torrent檔案的peers，它首先使用distancemetric來比較torrent檔案的info_hash和路由表中節點的

nodeID。接下來向路由表中nodeID與info_hash最接近的那些節點發送請求，得到當前正在下載這個torrent檔案資料的peers的聯絡資訊。如果被請求的節點知道這個torrent檔案的peers，那麼peer的聯絡資訊將包含在回覆中。否則，被請求的節點必須返回他的路由表中更接近info_hash得那些節點。原始的請求node不斷向新獲得的那些node中，更接近目標info_hash的那些node傳送請求，直到不能獲得更近的nodes。當查詢結束時，client將自己的資訊作為一個peer插入到在剛才請求中給出回覆的那些節點中，nodeid與info_hash最接近的哪個節點上，這樣，哪個節點又多儲存了一個peer資訊。

在請求peers的時候，對方給我們的回覆必須還包含一個不透明的令牌，我們稱他為“token”。這樣當我們宣佈我們正在下載某個torrent，想讓對方儲存我們的資訊時，我們必須使用對方向我們傳送的最近的一個token。這樣當我們宣佈我們在下載一個torrent時，被請求的node檢查這個token和IP是否與之前他們向我們回覆的一樣。這樣是為了防止惡意的攻擊。由於token僅僅由請求的節點返回，所以我們不規定他的具體實現。但是token必須有一個可接受的時間範圍，超過這個時間，token將失效。在BitTorrent的實現中，token是在IP地址後面連線一個secret(可以視為一個隨機數)，這個secret每五分鐘改變一次，其中token在十分鐘以內是可接受的。

路由表

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

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

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

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

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

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

BitTorret協議擴充套件

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

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

Torrent檔案擴充套件

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

nodes= [["<host>", <port>], ["<host>",<port>], ...]

nodes= [["127.0.0.1", 6881], ["your.router.node",4804]]

KRPC協議

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

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

相關推薦