DHT協議原理以及一些重點分析：

   要做DHT的爬蟲，首先得透徹理解DHT，這樣才能知道在什麼地方究竟該應用什麼演算法去解決問題。關於DHT協議的細節以及重要的參考文章，請參考文末1

   DHT協議作為BT協議的一個輔助，是非常好玩的。它主要是為了在BT正式下載時得到種子或者BT資源。傳統的網路，需要一臺中央伺服器存放種子或者BT資源，不僅浪費伺服器資源，還容易出現單點的各種問題，而DHT網路則是為了去中心化，也就是說任意時刻，這個網路總有節點是亮的，你可以去詢問問這些亮的節點，從而將自己加入DHT網路。

   要實現DHT協議的網路爬蟲，主要分3步，第一步是得到資源資訊(infohash，160bit，20位元組，可以編碼為40位元組的十六進位制字串)，第二步是確認這些infohash是有效的，第三步是通過有效的infohash下載到BT的種子檔案，從而得到對這個資源的完整描述。

   其中第一步是其他節點用DHT協議中的get_peers方法向爬蟲傳送請求得到的，第二步是其他節點用DHT協議中的announce_peer向爬蟲傳送請求得到的，第三步可以有幾種方式得到，比如可以去一些儲存種子的網站根據infohash直接下載到，或者通過announce_peer的節點來下載到，具體如何實現，可以取決於你自己的爬蟲。

   DHT協議中的主要幾個操作：

   主要負責通過UDP與外部節點互動，封裝4種基本操作的請求以及相應。

   ping：檢查一個節點是否“存活”

   在一個爬蟲裡主要有兩個地方用到ping，第一是初始路由表時，第二是驗證節點是否存活時

   find_node：向一個節點發送查詢節點的請求

   在一個爬蟲中主要也是兩個地方用到find_node，第一是初始路由表時，第二是驗證桶是否存活時

   get_peers：向一個節點發送查詢資源的請求

   在爬蟲中有節點向自己請求時不僅像個正常節點一樣做出迴應，還需要以此資源的info_hash為機會盡可能多的去認識更多的節點。如圖，get_peers實際上最後一步是announce_peer，但是因為爬蟲不能announce_peer，所以實際上get_peers退化成了find_node操作。

   announce_peer：向一個節點發送自己已經開始下載某個資源的通知

   爬蟲中不能用announce_peer，因為這就相當於通報虛假資源，對方很容易從上下文中判斷你是否通報了虛假資源從而把你禁掉

   DHT協議中有幾個重點的需要澄清的地方：

   1. node與infohash同樣使用160bit的表示方式，160bit意味著整個節點空間有2^160 = 730750818665451459101842416358141509827966271488，是48位10進位制，也就是說有百億億億億億個節點空間，這麼大的節點空間，是足夠存放你的主機節點以及任意的資源資訊的。

   2. 每個節點有張路由表。每張路由表由一堆K桶組成，所謂K桶，就是桶中最多隻能放K個節點，預設是8個。而桶的儲存則是類似一顆字首樹的方式。相當於一張8桶的路由表中最多有160-4個K桶。

   3. 根據DHT協議的規定，每個infohash都是有位置的，因此，兩個infohash之間就有距離一說，而兩個infohash的距離就可以用異或來表示，即infohash1 xor infohash2，也就是說，高位一樣的話，他們的距離就近，反之則遠，這樣可以快速的計算兩個節點的距離。計算這個距離有什麼用呢，在DHT網路中，如果一個資源的infohash與一個節點的infohash越近則該節點越有可能擁有該資源的資訊，為什麼呢？可以想象，因為人人都用同樣的距離演算法去遞迴的詢問離資源接近的節點，並且只要該節點做出了迴應，那麼就會得到一個announce資訊，也就是說跟資源infohash接近的節點就有更大的概率拿到該資源的infohash

   4. 根據上述演算法，DHT中的查詢是跳躍式查詢，可以迅速的跨越的的節點桶而接近目標節點桶。之所以在遠處能夠大幅度跳躍，而在近處只能小幅度跳躍，原因是每個節點的路由表中離自身越接近的節點儲存得越多，如下圖

   5. 在一個DHT網路中當爬蟲並不容易，不像普通爬蟲一樣，看到資源就可以主動爬下來，相反，因為得到資源的方式(get_peers, announce_peer)都是被動的，所以爬蟲的方式就有些變化了，爬蟲所要做的事就是像個正常節點一樣去響應其他節點的查詢，並且得到其他節點的迴應，把其中的資料收集下來就算是完成工作了。而爬蟲唯一能做的，是儘可能的去多認識其他節點，這樣，才能有更多其他節點來向你詢問。

   6. 有人說，那麼我把DHT爬蟲的K桶中的容量K增大是不是就能增加得到資源的機會，其實不然，之前也分析過了，DHT爬蟲最重要的資訊來源全是被動的，因為你不能增大別人的K，所以距離遠的節點儲存你自身的概率就越小，當然距離遠的節點去請求你的概率相對也比較小。

   一些主要的元件（實際實現更加複雜一些，有其他的模組，這裡僅列舉主要幾個）：

   DHT crawler：

   這個就是DHT爬蟲的主邏輯，為了簡化多執行緒問題，跟server用了生產者消費者模型，負責消費，並且複用server的埠。

   主要任務就是負責初始化，包括路由表的初始化，以及初始的請求。另外負責處理所有進來的訊息事件，由於生產者消費者模型的使用，裡面的操作都基本上是單執行緒的，簡化了不少問題，而且相信也比上鎖要提升速度（當然了，加鎖這步按理是放到了queue這裡了，不過對於這種生產者源源不斷生產的型別，可以用ring-buffer大幅提升效能）。

   DHT server：

   這裡是DHT爬蟲的伺服器端，DHT網路中的節點不單是client，也是server，所以要有server擔當生產者的角色，最初也是每個消費者對應一個生產者，但實際上發現可以利用IO多路複用來達到訊息事件的目的，這樣一來大大簡化了系統中執行緒的數量，如果client可以的話，也應該用同樣的方式來組織，這樣系統的速度應該會快很多。（尚未驗證）

   DHT route table：

   主要負責路由表的操作。

   路由表有如下操作：

   init：剛建立路由表時的操作。分兩種情況：

   1. 如果之前已經初始化過，並且將上次路由表的資料儲存下來，則只需要讀入儲存資料。

   2. 如果之前沒有初始化過，則首先應當初始化。

   首先，應當有一個接入點，也就是說，你要想加進這個網路，必須認識這個網路中某個節點i並將i加入路由表，接下來對i用find_node詢問自己的hash_info，這裡巧妙的地方就在於，理論上通過一定數量的詢問就會找到離自己距離很近的節點(也就是經過一定步驟就會收斂)。find_node目的在於儘可能早的讓自己有資料，並且讓網路上別的節點知道自己，如果別人不認識你，就不會發送訊息過來，意味著你也不能獲取到想要的資訊。

   search：比較重要的方法，主要使用它來定位當前infohash所在的桶的位置。會被其他各種代理方法呼叫到。

   findNodes：找到路由表中與傳入的infohash最近的k個節點

   getPeer：找到待查資源是否有peer（即是否有人在下載，也就是是否有人announce過）

   announcePeer：通知該資源正在被下載

   DHT bucket:

   acitiveNode：邏輯比較多，分如下幾點。

        1. 查詢所要新增的節點對應路由表的桶是否已經滿，如果未滿，新增節點

        2. 如果已經滿，檢查該桶中是否包含爬蟲節點自己，如果不包含，拋棄待新增節點

        3. 如果該桶中包含本節點，則平均分裂該桶

   其他的諸如locateNode, replaceNode, updateNode, removeNode，就不一一說明了

   DHT torrent parser：

   主要從bt種子檔案中解析出以下幾個重要的資訊：name，size，file list(sub file name, sub file size)，比較簡單，用bencode方向解碼就行了

   Utils：

   distance：計算兩個資源之間的距離。在kad中用a xor b表示

   為了增加難度，選用了不太熟悉的語言python，結果步步為營，但是也感慨python的簡潔強大。在實現中，也碰到很多有意思的問題。比如如何儲存一張路由表中的所有桶，之前想出來幾個辦法，甚至為了節省資源，打算用bit陣列+dict直接儲存，但是因為估計最終的幾個操作不是很方便直觀容易出錯而放棄，選用的結構就是哈夫曼樹，操作起來果然是沒有障礙；

   在超時問題上，比如桶超時和節點超時，一直在思考一個高效但是比較優雅的做法，可以用一個同步呼叫然後等待它的超時，但是顯然很低效，尤其我沒有用更多執行緒的情況，一旦阻塞了就等於該埠所有事件都被阻塞了。所以必須用非同步操作，但是非同步操作很難去控制它的精確事件，當然，我可以在每個事件來的時候檢查一遍是否超時，但是顯然也是浪費和低效。那麼，剩下的只有採用跟tomcat類似的方式了，增加一個執行緒來監控，當然，這個監控執行緒最好是全域性的，能監控所有crawler中所有事務的超時。另外，超時如果控制不當，容易導致記憶體沒有回收以至於記憶體洩露，也值得注意。超時執行緒是否會與其他執行緒互相影響也應當仔細檢查。

   最初超時的控制沒處理好，出現了ping storm，執行一定時間後大多數桶已經滿了，如果按照協議中的方式去跑的話會發現大量的事件都是在ping以確認這個節點是否ok以至於大量的cpu用於處理ping和ping響應。深入理解後發現，檢查節點狀態是不需要的，因為節點狀態只是為了提供給詢問的人一些好的節點，既然如此，可以將每次過來的節點替換當前桶中最老的節點，如此一來，我們將總是儲存著最新的節點。

   搜尋演算法也是比較讓我困惑的地方，簡而言之，搜尋的目的並不是真正去找資源，而是去認識那些能夠儲存你的節點。為什麼說是能夠儲存你，因為離你越遠，桶的數量越少，這樣一來，要想進他們的桶中去相對來說就比較困難，所以搜尋的目標按理應該是附近的節點最好，但是不能排除遠方節點也可能儲存你的情況，這種情況會發生在遠方節點初始化時或者遠方節點的桶中節點超時的時候，但總而言之，概率要小些。所以搜尋演算法也不應該不做判斷就胡亂搜尋，但是也不應該將搜尋的距離嚴格限制在附近，所以這是一個權衡問題，暫時沒有想到好的方式，覺得暫時讓距離遠的以一定概率發生，而距離近的必然發生

   還有一點，就是搜尋速度問題，因為DHT網路的這種結構，決定了一個節點所認識的其他節點必然是有限的附近節點，於是每個節點在一定時間段內能拿到的資源數必然是有限的，所以應當分配多個節點同時去抓取，而抓取資源的數量很大程度上就跟分配節點的多少有關了。

   最後一個值得優化的地方是findnodes方法，之前的方式是把一個桶中所有資料拿出來排序，然後取其中前K個返回回去，但是實際上我們做了很多額外的工作，這是經典的topN問題，使用排序明顯是浪費時間的，因為這個操作非常頻繁，所以即便所有儲存的節點加起來很少（(160 - 4) * 8），也會一定程度上增加時間。而採用的演算法是在一篇論文《可擴充套件的DHT網路爬蟲設計和優化》中找到的，基本公式是IDi = IDj xor 2 ^(160 - i)，這樣，已知IDi和i就能知道IDj，若已知IDi和IDj就能知道i，通過這種方式，可以快速的查詢該桶A附近的其他桶（顯然是離桶A層次最近的桶中的節點距離A次近），比起全部遍歷再查詢效率要高不少。