KADEMLIA算法

時間 2019-11-06

標籤 kademlia 算法简体版

原文原文鏈接

1、概述

　　基於異或距離算法的分佈式散列表（DHT), 實現了去中心化的信息存儲於查詢系統；node

　　Kademlia將網絡設計爲具備160層的二叉樹，樹最末端的每一個葉子看做爲節點，節點在樹中的位置由一樣是160bit的節點ID決定。每一個bit的兩種可能值（0或1），決定了節點在書中屬於左邊仍是右邊的子樹，160下來，每一個節點ID便都有一個肯定的位置；算法

2、節點之間距離

　　Kad網絡中每一個節點都有一個160bit的ID值做爲標誌符，Key也是一個160bit的標誌符，每個加入Kad網絡的節點都會被分配一個160bit的節點ID（node ID），這個ID值是隨機產生的。同時<key, value>對的數據就存放在ID值距離key值最近的若干個節點上。緩存

　　Kademlia使用異或距離算法來計算節點間的距離：網絡

x ^ x = 0 //本身於本身的距離爲0併發
x ^ y > 0 // 不一樣節點間必有距離異步
x ^ y = y ^ x // x到y的距離等於y到x的距離分佈式
x ^ y + y ^ z >= x ^ z //從a經b繞到c, 要比直接從a到c距離長工具
x + y >= x ^ y //暫不理解性能
(x ^ y) ^ (y ^ z) = x ^ z //暫不理解spa

　　所說的距離是邏輯上的距離，與地理位置無關，因此有可能兩個節點之間計算獲得的邏輯距離很近，但實際上地理上的距離卻很遠。

　　例如：節點A的ID（011）和節點B的ID（101）距離：011 ⊕ 101 = 110 = 4+2 = 6。

3、路由表

　　一、映射規則

- 先把key（如節點ID）以二進制形式表示，而後從高位到地位依次按Step2~Step3處理。
- 二進制的第n位對應二叉樹的第n層
- 若是當前位是1，進入右子樹，若是是0則進入左子樹（認爲設定，能夠反過來）
- 按照高位到地位處理完後，這個Key值就對應於二叉樹上的某個葉子節點。

　　當咱們把全部節點ID都按照上述步驟操做後，會發現，這些節點造成一顆二叉樹。

　　（實例僅演示三層）

　　二、二叉樹拆分規則

　　　　每個節點均可以從本身的視角出發來對二叉樹進行拆分。

　　　　拆分規則是從根節點開始，把不包含本身的子樹拆分出來，而後在剩下的子樹再拆分不包含本身的下一層子樹，以此類推，直到最後只剩下本身。如上圖所示，以節點ID爲6（110）爲視角進行拆分，能夠獲得3個子樹（灰色圓圈）。而以節點101爲視角拆分，則能夠獲得以下二叉樹。

節點101的角度

　　Kad默認的散列值空間是m=160（散列值有160bit），因此拆分之後的子樹最多有160個。而考慮到實際網絡中節點個數遠遠沒有2^160個，因此子樹的個數明顯小於160個。

　　對於每一個節點，當按照本身的視角對二叉樹進行拆分之後，會獲得n個子樹。對於每一個子樹，若是都分別知道里面1個節點，那麼就能夠利用這n個節點進行遞歸路由，從而能夠達到整個二叉樹的任何一個節點。

三、K-bucket 機制

　　假設每一個節點ID是N bits。每一個節點按照本身視角拆分完子樹後，一共能夠獲得N個子樹。

warning：上面說了，只要知道每一個子樹裏的一個節點就能夠實現全部節點的遍歷。可是，在實際使用過程當中，考慮到健壯性（每一個節點可能推出或者宕機），只知道一個節點是不夠的，須要之多多幾個節點才比較保險。

　　因此，在Kad論文中舊有一個K-桶（K-bucket）的概念。也就是說，每一個節點在完成拆分子樹之後，要記錄每一個子樹裏面K個節點。這裏K是一個系統級常量，由軟件系統本身設定（BT下載使用的Kad算法中，K設定爲8）。

　　K桶在這裏實際上就是路由表。每一個節點按照本身視角拆分完子樹後，能夠獲得N個子樹，那麼就須要維護N個路由表（對應N個K-桶）。

　　Kad算法中就使用了K-桶的概念來存儲其餘鄰近節點的狀態信息（節點ID、IP和端口），以下圖，對於160bit的節點ID，就有160個K-桶。

　　對於每個K-桶i,它會存儲與本身距離在區間[2^i, 2^(i+1)) 範圍內的K個節點的信息，以下圖所示。每一個K-桶i中存儲有K個其餘節點信息，在BitTorrent中K取8。固然每個K-桶i不可能把全部相關的節點都存儲，這樣表根本存儲不下。它是距離本身越近的節點存儲的越多，離本身越遠存儲的越少（只取距離本身最近的K個節點），以下圖所示。

　　同時每一個K-桶中存放的位置是根據上次看到的時間順序排列，最先訪問的放在頭部，最新訪問的放在尾部。

　四、K-桶更新機制【主要有3種】

- 主動收集節點

　　　　　　任何節點均可以發起FIND_NODE（查詢節點）的請求，從而刷新K-桶中的節點信息

- 被動收集節點

　　　　　　當收到其餘節點發送過來的請求（如：FIND_NODE、FIND_VALUE），會把對方的節點ID加入到某個K-桶中

- 檢測失效節點

　　　　　　經過發起PING請求，判斷K-桶中某個節點是否在線，而後清理K-桶中哪些下線的節點

　　當一個節點ID要被用來更新對應的K-桶，其具體步驟以下：

- 計算本身和目標節點ID的距離d
- 經過距離d選擇路由表中對應的K-桶，若是目標節點ID已經在K-桶中，則把對應項移到該K-桶的尾部
- 若是目標節點ID不在K-桶中，則有兩種狀況：
  - 若是該K-桶存儲的節點小於K個，則直接把目標節點插入到K-桶尾部；
  - 若是該K-桶存儲節點大於等於K個，則選擇K-桶中的頭部節點進行PING操做，檢測節點是否存活。若是頭部節點沒有響應，則移除該頭部節點，並將目標節點插入到隊列尾部；若是頭部節點有響應，則把頭部節點移到隊列尾部，同時忽略目標節點。

　咱們能夠看到K-桶的更新機制實現了一種把最近看到的節點更新的策略，也就是說在線時間長的節點有較高的可能性可以繼續保留在K-桶列表中。

　這種機制提升了Kad網絡的穩定性並降少了網絡維護成本（減小構建路由表），同時這種機制能在必定程度上防護DDOS攻擊，由於只有老節點失效後，Kad纔會更新K-桶，這就避免了經過新節點加入來泛洪路由信息。

五、協議消息

　Kad算法一共有4中消息類型：

PING 檢查節點是否在線
STORE 通知一個節點存儲<key, value>鍵值對，以便之後查詢使用
FIND_NODE 返回對方節點桶中離請求鍵值最近的 K 個節點
FIND_VALUE 與 FIND_NODE 同樣，不過當請求的接收者存有請求者所請求的key值的時候，它將返回相應value

　備註：每一個發起請求的RPC消息都會包含一個發送者加入的隨機值，這個能夠確保在接收到消息響應的時候能夠根前面發送過的消息匹配。

六、定位節點

　　節點查詢能夠同步進行也能夠異步進行，同時查詢的併發數量通常爲3。

首先由發起者肯定目標ID對應路由表中的K-桶位置，而後從本身的K-桶中篩選出K個距離目標ID最近的節點，並同時向這些節點發起FIND_NODE的查詢請求。
被查詢節點收到FIND_NODE請求後，從對應的K-桶中找出本身所知道的最近的K個節點，並返回給發起者。
發起者在收到這些節點後，更新本身的結果列表，並再次從其中K個距離目標節點ID最近的節點，挑選未發送請求的節點重複Step1步驟。
上述步驟不斷重複，直到沒法獲取比發起者當前已知的K個節點更接近目標節點ID的活動節點爲止。
在查詢過程當中，沒有及時響應的節點應該當即排除，同時查詢者必須保證最終得到的K個節點都是在線的。

七、定位資源

　　當節點要查詢<key, value>數據對時，和定位節點的過程相似。

首先發起者會查找本身是否存儲了<key, value>數據對，若是存在則直接返回，不然就返回K個距離key值最近的節點，並向這K個節點ID發起FIND_VALUE請求
收到FIND_VALUE請求的節點，首先也是檢查本身是否存儲了<key, value>數據對，若是有直接返回value，若是沒有，則在本身的對應的K-桶中返回K-個距離key值最近的節點
發起者若是收到value則結束查詢過程，不然發起者在收到這些節點後，更新本身的結果列表，並再次從其中K個距離key值最近的節點，挑選未發送請求的節點再次發起FIND_VALUE請求。
上述步驟不斷重複，直到獲取到value或者沒法獲取比發起者當前已知的K個節點更接近key值的活動節點爲止，這時就表示未找到value值。

　　若是上述FIND_VALUE最終找到value值，則<key, value>數據對會緩存在沒有返回value值的最近節點上，這樣下次再查詢相同的key值時就能夠加快查詢速度。

　　因此，越熱門的資源，其緩存的<key, value>數據對範圍就越廣。這也是爲何咱們之前用P2P下載工具，下載的某個資源的人越多時，下載速度越快的緣由。