DHT(Distributed Hash Table): 分佈式哈希表

  DHT的全稱是Distributed Hash Table,即分佈式哈希表技術,是一種分佈式存儲方法。這種網絡不需要中心節點服務器,而是每個客戶端負責一個小範圍的路由,並負責存儲一小部分數據,從而實現整個DHT網絡的尋址和存儲。和中心節點服務器不同,DHT網絡中的各節點並不需要維護整個網絡的信息,而是隻在節點中存儲其臨近的後繼節點信息,大幅減少了帶寬的佔用和資源的消耗。DHT網絡還在與關鍵字最接近的節點上覆製備份冗餘信息,避免了單一節點失效問題。
形象地,我們可以把整個DHT網絡想象成一個大城市,那麼每個客戶端,就好比城市裏各個角落的地圖,上面繪製了附近區域的地形情況,把這些地圖一彙總,城市的全貌就出來了。
  而DHT所採用的算法中最出名的是Kademlia,eMule早在一年多前就開始採用,Bitcomet、Azureus和BitTorrent只是步其後塵,同樣使用Kademlia算法的DHT。不過它們各自的實現協議不盡相同,因此不能相互兼容(BitComet與BitTorrent兼容,Azureus更像eMule,但與其它都不兼容)。

  在不需要服務器的情況下,每個客戶端負責一個小範圍的路由,並負責存儲一小部分數據,從而實現整個DHT網絡的尋址和存儲。新版BitComet允許同行連接DHT網絡和Tracker,也就是說在完全不連上[Tracker服務器的情況下,也可以很好的下載,因爲它可以在DHT網絡中尋找下載同一文件的其他用戶。BitComet的DHT網絡協議和BitTorrent今年5月測試版的協議完全兼容,也就是說可以連入一個同DHT網絡分享數據
  Kademlia技術,通常又被稱爲第三代p2p技術,是一種P2P通用協議,適用於所有的分佈式點對點計算機網絡。Kademlia定義了網絡的結構,規劃了節點之間的通訊以及具體的信息交互過程。在Kademlia中,網絡節點之間使用UDP進行通信,通過一種分佈式哈希表來存儲數據,每個節點都會有一個自己的ID,在用來標識節點本身的同時,也用以協助實現Kademlia算法和流程。
  在傳統的BT下載裏,所有的種子文件都必須指定一個或多個種子服務器,即通常所說的Tracker或Announce地址,種子文件和連接信息都存儲在種子服務器上,而引入了DHT網絡之後,這些連接信息則可以保存在根據一定的算法挑選出的DHT網絡參與者(即DHT節點)之間,也就是說,一旦你加入公有DHT網絡,你就會有一個ID(該ID只是程序生成的、虛擬的、完全隨機的ID,與你的實際個人信息沒有任何聯繫,請完全放心)。
  而根據一定的規則,你需要負責維護一部分種子文件的連接信息,相當於你同時也是一個超輕量級種子服務器。這樣,下載者只要接入了DHT網絡,並且找到了一些連接(或者說節點),就能獲得連接信息,而不需要再依賴於tracker服務器。
這樣,加入DHT網絡解決了傳統BT下載中的兩個問題:
  第一: 一旦該種子服務器當機或由於其它原因無法訪問,BT用戶很可能就無法繼續獲得連接信息(當然,已經有比特精靈等一些客戶端通過連接共享等功能一定程度解決了這個問題);
  第二:在傳統BT下載中,如果有兩個完全相同的種子文件,但是由於指定了不同的Tracker,那麼不同Tracker的用戶之間將無法進行下載與上傳,從而不能充分體現BT的下載/上傳效率。
  減少對種子服務器的依賴
  現在,剩下的問題就是,即使加入了DHT網絡,BT下載還是得從種子服務器處獲得種子文件。相信大家都有體會,遇上服務器繁忙的時候,幾分鐘甚至更長時間連不上服務器是很常見的事情。
  比特精靈在支持DHT網絡的同時,對其在應用層面上進行了拓展,支持只需要一個類似鏈接<A href="
http://Kademlia/..(40B">http://Kademlia/..(40B</A>的哈希Hex串)....的鏈接就能添加任務(提示:在比特精靈裏選中一個任務後通過右鍵菜單的"拷貝DHT鏈接"可以提取種子的鏈接),然後比特精靈可以通過特徵串從DHT網絡節點處得到種子文件,而不需要依賴種子服務器,從而在實現了trackerless的同時,也實現了torrentless。
  這樣,BT下載就藉助公有DHT網絡,很大程度上減少了對種子服務器的依賴。可以說,DHT網絡的引入使得BT不再必需種子服務器,可以說是天下從此無服,但從更深層次的角度來說,應該是天下從此無人不服。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章