Kademlia 是個 Petar Maymounkov 與 David Mazières 所設計的點對點 (P2P) 重疊網路傳輸協議，以達成非集中式的點對點 (P2P) 電腦網路。它規制了網路的結構及規範了節點間的通訊和交換資訊的方式。Kademlia 節點間使用傳輸通訊協定 UDP （請見OSI模型） 溝通。Kademlia 節點藉以實作分散式雜湊表 (DHT,distributed hash table) 以儲存資料。透過既有的區域網/廣域網( LAN/WAN) （如同因特網），一個新的虛擬網路或是重疊網路被建立起來。每個網路節點都是以一組數字（“節點 ID”）來識別。這組數字不但做為識別之用，Kademlia 演算法還會用來做其他用途。

一個想要加入網路的節點需要先通過

啟動。在這個階段，這個節點需要知道另一個已經在 Kademlia 網路內的節點之 IP 位址 （透過另一個使用者或儲存的清單取得）。如果啟動中的節點還不是網路的一部分，它便會計算一個尚未指定給其他節點的隨機 ID 編號。這個 ID 會一直使用到離開網路為止。

Kademlia 演算法是基於兩節點間的“距離”來計算。這個距離是以兩節點的 ID 進行互斥運算，並將結果四捨五入至整數。

這個“距離”跟實際的地理環境無關，而是標明 ID 範圍內的距離。因此一個德國的節點和一個澳洲的節點就有可能被稱為“鄰居”或“芳鄰”。

Kademlia 內的資訊都儲存在稱為“數值”的東西內，每個數值都連線著一個“金鑰”。

當 搜尋某個金鑰時，演算法會透果幾個步驟探整個網路一圈，每個步驟都會更接近要搜尋的金鑰，直到被連線的節點傳回數值，或找不到更近的節點。網路的大小僅會稍 微影響到進行搜尋時接觸到的節點數目：假如目前網路的使用者突然增為兩倍，那使用者節點大概只需要在搜尋時多查詢一個節點，而不是兩倍的節點量。

非集中式的結構提供了更大的優勢，並很明顯地增加了對拒絕服務阻斷攻擊的抵抗。即使一整系列的節點被壅塞，也不會對網路可用度造成太多影響，最後網路會透過繞過這些“洞”而自我修復。

Kademlia 被用來進行檔案分享。透過進行 Kademlia 關鍵字搜尋，任何人可以在檔案分享網路中尋找資料以下載東西。由於沒有任何中央伺服器儲存檔案列表的索引，因此這項工作是平均的由所有的客戶端擔當：擁有要分享的檔案枝節點，會先處理檔案的內容，並從內容計算出一組數字（

雜湊）， 這組數字將會在檔案分享網路中辨識這個檔案。雜湊與節點 ID 的長度必須相同。接著會搜尋幾個 ID 與雜湊相近、且節點內有儲存著自己 IP 位址的節點。搜尋的客戶端會使用 Kademlia 來搜尋網路上節點ID離自己最近距離的節點來取得檔案雜湊，然後會取得在該節點上的聯絡清單。 當節點聯入和聯出時，這份儲存在網路上的聯絡清單也將保持不變。因為內嵌的冗餘儲存演算法，聯絡清單將複製在多個點上。

檔案雜湊通常都是由其它地方的特製因特網鍵結來取得，或者被包含在來自其它來源中的索引檔中。

對檔案名稱的搜尋是基於關鍵字來實現的。檔案名稱被分成幾個組成檔案名稱的單字。 每個關鍵字都會被雜湊， 並和相對的檔案名稱與檔案雜湊利用和檔案雜湊一樣的方式儲存到網路上。一個搜尋者會選擇其中的一個關鍵字，聯絡上和關鍵字雜湊最相近的節點ID，然後取得 含有關鍵字的檔案名稱列。既然在檔案名稱列中的每個檔案名稱都附有自己的湊雜，那麼被選的檔案就可以由一般的方式取得。

Kad是Kademlia的簡稱，eMule的官方網站在2004年2月27日正式釋出的 eMule v0.42b中，Kad開始正式內嵌成為eMule的一個功
能模組，可以說從這個版本開始eMule便開始支援Kad網路了。

Kad的出現，結束了之前edonkey時代，在ed圈裡只存在著ED2K一種網路的模式，它通過新的協議開創並形成了自己的kad網路，使之
和ED2K網路並駕齊驅，而且它還完全支援兩種網路，可以在兩種網路之間通用。Kad同樣也屬於開源的自由軟體。它的程式和原始碼
可以在官方網站http://www.emule-project.net上下載。

Kad網路拓撲的最大特點在於它完全不需要伺服器，我們都知道傳統的ed2k網路需要伺服器支援作為中轉和儲存hash列表資訊，kad
可以不通過伺服器同樣完成ed2k網路的一切功能，你唯一要做的就是連線上網，然後開啟kad。Kad需要UDP埠的支援，之後Emule
會自動按照客戶端的要求，來判斷它能否自由連線，然後同樣也會分配給你一個id，這個過程和我們ed2k的高id和低id檢查很像，不
過這個id所代表的意義不同於ed2k網路，它代表一個是否“freely”的狀態。

Kad和ed2k網路有著完全不同的觀念但是相同的目的: 都是搜尋和尋找檔案的源。 Kad網路的主要的目標是做到不需要伺服器和改善
可量測性。相對於傳統的ed2k伺服器只能處理一定數量的使用者(我們在伺服器列表也都看到了,每個伺服器都有最大人數限制)，而
且如果伺服器比較大連線人數過多,還會嚴重的的拖垮網路。而Kad能夠自我組織,並且自我調節最佳的使用者數量以及他們的連線
效果。因此, 它更能使網路的損失達到最小。由於具備了以上所敘述的功能，Kad也被稱之為Serverless network（無伺服器
網路）。雖然目前一直處於開發階段(alpha stage) 。但毫無疑問，它無可比擬的優勢,將會使它成為p2p的明天。

可能很多朋友會關注， kad網路沒有高低id的計算原則，是否對於低id來言就暢通無阻了呢？

我們大家知道在ed2k網路裡面，我們的id是通過ip進行如下的演算法計算得出的
設我們的IP = A.B.C.D
那麼我們的ID number= A + 256*B + 256*256*C + 256*256*256*D
low ID的產生是由於我們的ID計算結果小於16777216.
即 ID number= A + 256*B + 256*256*C + 256*256*256*D < 16777216

Kad的 id計算原則並不是象上面那樣，他更關注我們是否open和freely。
但是kad裡面是如何計算我們的id呢？
事實上它的計算方法是這樣
ID number=256*256*256*A+256*256*B+256*C+D
所以kad其實也有高低id的分別。所以內網使用者在使用的時候依舊無法達到內網使用者完全穿透網路的效果，而且目前來看，還存在著kad
模組引入,導致佔用系統資源會變大以及會突然產生Memory Leak的問題，對於記憶體的控制，目前emule做的效果還是不好。

其實kad本身有一個nodes.dat檔案，也叫做節點檔案，這裡面存放了我們在Kad網路中的鄰居節點，我們都是通過這些節點來進入Kad
網路的。其實kad的網路倒更像是overnet和Kazaa網路，有興趣的朋友大家可以對比看看。Kad網路提供了幫助尋找節點以及記錄節點的機制。

下面我們來說說這個機制的原理：
Kad擁有一個160bit的ID，每一個節點送出的訊息都必須包含此ID。每一個節點都必須記錄一個資料來儲存已經存在的節點，資料的格式是
(IP address, UDP port, Node ID)，節點所必須負責的範圍是2的i次方及2的i+1次方，i的範圍是0 < i <160，這個結構叫做
k-bucket，該結構會形成一個tree的形狀，每一次接收到新的資訊時，各個節點都必須更新k-bucket內的資料，透過k-bucket結構我
們可以保證所有的節點狀態都是新的，而且一定會知道這個節點在哪裡。

Kademlia網路提供四種Potocol(RPC)
(1)PING 測試是否節點存在
(2)STORE儲存通知的資料
(3)FIND_NODE 通知其他節點幫助尋找node
(4)FIND_VALUE 通知其他節點幫助尋找Value
而當每一個指令被接受到後，每一個節點都會到k-bucket上搜尋，通過這樣的結構，kad提供一個方便快速且可以被保證在logN次數下找到所需的節點。

通俗的來講就是在kad網路中，我們每個emule使用者端只負責處理一小部分搜尋和查詢源的工作。分配這些工作的時候，通過我們每個使用者端的唯一
的ID和搜尋檔案的hash值之間的匹配來決定。比如像我猜我猜我猜猜.rm這個檔案由使用者小王來負責（通過該檔案的hash值來決定），那麼任何其他用
戶在下載這個檔案的時候都會告訴其他使用者,小王有這個檔案，其他使用者去下載這個檔案的時候也會詢問小王，小王也會告訴他們誰正在共享這個檔案，這
樣kad找源的工作就完成了。搜尋時候的方法也差不多，只不過是每個人負責一個關鍵字。

整個過程有點像在照線索循序問路而找到正確方向，而不是路上隨便到處抓人在問路。而每個地方里的網路相關資訊，則會隨著電腦及檔案的加入而持續
更新。好處在於讓你可以搜尋整個網路，而不只是在某一地區。目前來講，這個機制和演算法是絕對領先而且非常優秀的。

如何找到使用者小王則是通過將使用者id異或的方式，兩個id的二進位異或值決定他們之間的邏輯距離，如1100距離1101要比距離1001近。那麼當一個使用者
加入kad後，首先通過一個已知的使用者找到一批使用者的id和ip地址和埠。當該使用者要尋找一個特定使用者A的時候，該使用者先詢問幾個已知的邏輯距離較A較
近的使用者，如B使用者,C使用者,D使用者，B，C，D會告訴該使用者他們知道的更加近的使用者的id和ip地址和埠，同理類推，這個使用者最終就能找到A。所以尋
找的次數會在logN數量級，這裡N代表詢問的人數。

其實也就是一種分散式雜湊的方法，基本上是對網路上某一特定時刻的檔案進行快照(snapshot)，然後將這些資訊分散到整個網路裡。 為了找到特定
的檔案，搜尋的要求先到達網路上的任何一臺電腦上，然後這臺電腦就會再將它轉到另一臺有更多檔案資訊的電腦。第三臺電腦可能就擁有檔案本
身──或者也可能再繼續轉到其他有正確資訊的電腦。採用這種方法，通常只需要跳轉兩到三次，便可以輕鬆查詢到所需檔案。

以上幾個部分，便是對於kad作用原理以及演算法的分析，可能好多人看了之後頭大，那麼我們普通使用者到底該注意些什麼呢？

很簡單，你要作的就是再使用emule的時候開啟kad，你會發現有兩個明顯的特點
(1)你的下載速度會加快
(2)你的下載檔案的源會增加
以上兩條對於lowid和經常下載源在國外的檔案使用者，效果就更為突出，特別對於在ed2k網路中只有幾個源或者沒有源的檔案，在kad網路中，一般都
能找到源，所以說你使用了emule下載檔案，基本上不會出現沒有源的請況，無論多長時間，差別只是源的多少個數問題，由於kad網路都是自動配置的
，所以你絲毫不用分心，那麼索性我們就開啟它，何樂而不為呢？

另外對於我們搜尋的時候，如果採用kad網路搜尋,多數情況下找到的檔案源會遠遠多於ed2k的全域性搜尋，對於大家都是一個明智的選擇。

1. ID and Key

Node ID：160 bit （每一個Node擁有一個ID，隨機產生）
Key：160 bit （Key也許是某個很大的資料的SHA-1 hash值）

(Key,Value)這一對資料儲存在ID最“接近”Key的Node上。
“接近”的意思是Key和ID之間的“距離”很短。
Kad網路中“距離”的定義是：d(x,y) = x XOR y，也就是x和y的異或值。

* 選擇XOR作為衡量距離的尺度，是因為XOR有xxx,yyy,zzz,...等特性，具體請看Kademlia的paper [1] section 2.1。

2. k-bucket

每一個Node保持160個 list。對於第 i (0 <= i < 160) 個 list，此 list 中儲存著和該 Node 距離為 2*i ~ 2*(i+1)
【2的 i 次方到 2的 i+1 次方】的
一些 Node 的資訊（Node ID，IP地址，UDP埠）。這些 list 叫做 k-bucket 。k是每一個 listk 中儲存的 Node 的最大
個數（比如，20）。

        +------------------------+
list 0: |                        |   距離為[1,2)的node
        +------------------------+
（ID前159 bit相同，第160 bit一定不同的node: 1個）

        +------------------------+
list 1: |                        |   距離為[2,4)的node
        +------------------------+
（ID前158 bit相同，第159 bit一定不同的node: 2個）

        +------------------------+
list 2: |                        |   距離為[4,8)的node
        +------------------------+
（ID前157 bit相同，第158 bit一定不同的node: 4個）

        +------------------------+
list 3: |                        |   距離為[8,16)的node
        +------------------------+
（ID前156 bit相同，第157 bit一定不同的node: 8個）

        +------------------------+
list 4: |                        |   距離為[16,32)的node
        +------------------------+
（ID前155 bit相同，第156 bit一定不同的node: 16個）

。
。
。
          +------------------------+
list 159: |                        |   距離為[2*159,2*160)的node
          +------------------------+
（ID第1 bit不同的node: 2*159個。此list中最多儲存最近訪問的k個）

每一個list （k-bucket）中的node按照訪問的時間順序排列，最先訪問的在list頭部，最近訪問的在list的尾部：

Head                                        Tail
 |                                           |
 V                                           V
+--+   +--+   +--+   +--+   +--+            +--+
|  |-->|  |-->|  |-->|  |-->|  |--> ... --> |  |
+--+   +--+   +--+   +--+   +--+            +--+
Node0  Node1  ...                           Node[N]
 A                                            A
 |                                            |
least-recently                              most-recently

3.k-bucket的重新整理

當一個Node收到另一個Node發來的訊息的時候，它根據以下規則（least-recently seen eviction policy）來重新整理相應的k-bucket:
 1) 如果傳送者已經在某一個k-bucket中，將它在該 k-bucket 中移動到尾部
 2) 如果傳送者不在其對應的k-bucket中，並且該 k-bucket 還不滿 k 個Node，將這個傳送者加入到 k-bucket 的尾部
      如果該 k-bucket 已經滿了（有k個Node），那麼接受訊息的 Node 向該 k-bucket 中最老的（也就是頭部的）
Node傳送一個 ping 訊息
        如果這個最老的 Node 沒有響應，則將它從 k-bucket 中刪除，將新的傳送訊息的 Node 加入到 k-bucket 的尾部
        如果這個最老的 Node 響應了，則將它移動到 k-bucket 的尾部，並拋棄新的 Node 的資訊

* 為什麼要採取這樣的規則，請看Kademlia的paper [1] section 2.2

4. 基本協議(protocol)

四種基本的RPC：PING, STORE, FIND_NODE, FIND_VALUE

1) PING
PING 探測一個Node是否線上

2) STORE
STORE 以(Key,Value)為引數。指示另一個Node（訊息接收者）儲存一個(Key, Value)對，以供以後取用。

3) FIND_NODE
FIND_NODE 以一個160 bit的ID作為引數。接收者返回它所知道的最接近該ID的 k 個 Node 的 Contact 資訊
（ID,UPD Port,IP）。這些 Node 不一定要從同一個 k-bucket 中產生。除非它所有的 k-bucket 中所有的
Node 加在一起都不到 k 個，否則它必需湊足 k 個。

4) FIND_VALUE
FIND_VALUE 以一個160 bit的ID/Key作為引數。如果接收者先前已經收到一個 STORE RPC，而且 STORE 的
引數之一 Key 就是當前 FIND_VALUE 的引數，那麼，接收者將 STORE 的另一個引數 Value 返回給傳送者。
否則，FIND_VALUE 和 FIND_NODE 一樣，返回它所知道的最接近該ID的 k 個 Node 的 Contact 資訊
（ID,UPD Port,IP）。
FIND_VALUE 的意思就是：如果接收者有傳送著所要的 Value，就將該 Value 返回。否則，接收者就幫忙找
更接近該 ID/Key 的 Node。

所有的 RPC 訊息都帶有一個 160 bit的隨機 RPC ID，由傳送者產生，接收者在響應每一個訊息的時候，返回
的訊息裡面都必需拷貝此 RPC ID。目的是防止地址偽造。PING 訊息可以在 RPC 響應裡使用捎帶確認機制來獲
得傳送者網路地址（原文：pings can also be piggy-backed on RPC replies for the RPC recipient to
obtain additional assurance of the sender's network address.）。

* piggyback
  捎帶確認(法)
  A technique used to return acknowledgement information across a full-duplex  (two-way
simultaneous) data link without the use of special (acknowledgement) message. The
acknowledgement information relating to the flow of message in one direction is embedded
(piggybacked) into normal data-carrying message flowing in the reverse direction.
  經全雙工(雙向同時)資料鏈路,不用專門(確認)報文返回確認資訊所用的技術。與一個方向的報文流有關的確
認資訊鉗在反方向正常攜帶資料的報文流中。

5. 節點查詢(node lookup)
node lookup:找到距離給定的 ID 最近的 k 個 node
定義 a:系統範圍內的併發引數，比如3。
步驟：
 1) 從最近的 k-bucket 裡面取出 a 個最近的 node，然後向這 a 個 node 傳送並行的、非同步的 FIND_NODE RPC。
 2) 再次傳送 FIND_NODE RPC 給從前一步返回的 node（這一步可以不必等到前一步中所有 a 個 PRC 都返回之後才開始）：
    從傳送者已知的 k 個最接近目標的 node 當中，取出 a 個還沒有查詢的 node，向這 a 個 node 傳送 FIND_NODE RPC。
    沒有迅速響應的 node 將被排除出考慮之列，直到其響應。
    如果一輪 FIND_NODE RPC 沒有返回一個比已知的所有 node 更接近目標的 node，傳送者將再向 k 個最接近目
標的、還沒有查詢的 node 傳送 FIND_NODE RPC。
 3) 查詢結束的條件：傳送者已經向 k 個最近的 node 傳送了查詢，並且也得到了響應。

6. 儲存<Key, Value>(store a <Key,Value> pair)
步驟：
 1) 使用node lookup演算法，找到距離 Key 最近的 k 個 node
 2) 向這 k 個 node 傳送 STORE RPC
 3) 每一個 node 必要的時候重新發布(re-publish)所有的<Key,Value>
    （對於當前的 Kademlia 應用(檔案共享)，每一個<Key,Value>的原始釋出者被要求每隔24小時重新發布一次，
否則<Key,Value>將在釋出之後的24小時之後過期。對於其他一些應用，比如digital certificates,
cryptographic hash to value mapping，過期時間可以更長一些）

7. 搜尋<Key,Value> （find a <Key,Value> pair)
步驟：
 1) 使用 FIND_VALUE 代替 FIND_NODE 進行"node lookup"過程。一旦任何其他 node 返回了所要的 Value，搜尋的過程就結束。
 2) cache: 如果搜尋成功，搜尋的發起者將這個<Key,Value>對儲存到已知的、最近的、但是在第一步中沒有返回該 Value 的 node 上。
    顯然，有了cache之後，以後對於該 <Key,Value> 的搜尋很可能首先找到 cache，而不是直到找到最接近 Key 的那個 node。
    如果一個 <Key,Value> 被頻繁的搜尋，那麼它很可能被快取到很多 ID 不太接近 Key 的 node 中。
    為了避免過度快取(over-caching)，每一個 <Key,Value> 都有一個過期時間，這個過期時間和 當前node 和“最接近Key
之node”之間的 node 的個數（這個數目可以從當前node的bucket介面推斷出）的指數倒數成正比。（To avoid "over-caching", we make
the expiration time of a <key,value> pair in any node's database exponentially inversely proportional
to the number of nodes between the current node and the node whose ID is closest to the key ID. This number can be inferred from the bucket structure of the current node）
 
8. 重新整理bucket (refresh bucket)
 所有的 bucket 通過node之間的請求來重新整理。
 如果某一個bucket在過去一個小時之內沒有任何的node lookup操作，那麼這個node就隨機搜尋一個在這個bucket覆蓋範圍內的ID。
 
9. node加入網路
步驟：
 1) 一個新加入的node（假設為u）必需首先獲得一個已經在網路中的node（比如為w）的contact資訊。
 2) u 首先將 w 加入到其對應的 k-bucket 中
 3) u 執行一個對自己ID的 node lookup 操作
 4) u 重新整理所有的 k-bucket

與BT的比較
簡單的說,emule與bt 協議兩者各有千秋

       1.傳統連線方式

              bt使用統一的torrent檔案先作一個原下載檔案的資訊記錄,然後客戶下載後通過torrent的資訊與伺服器連線並下載,

              emule僅有一個檔案ID,客戶自行與伺服器連線再下載

       2.底層傳輸協議比較

              bt只使用TCP協議進行下載,協議簡單有效,但是功能比較單一,有的功能不完整

              emule使用TCP和UDP兩種協議進行通訊,更加有效的利用了網路資源,功能完整強大,但這也同時使主機的負荷加大,程式編寫難度提高

       3.檔案組織方式和資料驗證方式

              bt會在開始前對檔案進行一次完全的HASH,就是將檔案首尾相聯然後按固定塊取SHA值,這些值最終被放入torrent檔案編碼中,客戶從網上一次下 載完全,高效簡單,一般情況下bt軟體會在每小塊下載完成後就對其進行HASH測試,檢查其正確性

              emule 在連線字串中只存放了整體檔案的HASH值,通過將這個HASH到伺服器上取出檔案的相關資訊,在實際的操作中,會將檔案分解成9.28M大小的塊並進 行HASH用於對塊的完整性測試.新版的emul會用一種叫AICH的技術,就是說將檔案分成120K大小的塊然後HASH再將HASH值進行二進迭代式 （具體的看emule協議)的HASH最終組成一個HASH二叉樹這種方式的好處是可以在連線時只加入根結節的HASH值而不用加入葉子節點,減小了連線 時的字串大小,如果在最終檔案下載完畢後,測試出的根節點HASH與得到的根節點的HASH值不同,則可以通過協議與網路上的其它主機的樹進行比較快速 得出錯誤的塊.

       4.流量控制方式

              bt採用有名的針鋒相對的方式處理上傳下載平衡的控制,這種方式會記錄短期內與客戶連線的所有節點的上傳下載流量,通過在固定時間內對下載流量的比較,得 出允許上傳的客戶;為防止新客戶長時間得不到其它客戶的認同,bt會在一斷時間停止他的上傳作為對他的警告；對於已經下載完畢的客戶,bt會簡單的使上傳 流量最的客戶得到更多的時間完成上傳;為了防止在檔案的最後階段下載速度下降,bt會在最後時向所有連線的客戶傳送請求迅速完成下載;在整個下載過程 中,bt會對檔案塊在整個網路中的存在複本的多少進行跟蹤,那些存在的比較少的複本總是會得到優先的下載權,以使整個網路的檔案冗餘度提高.簡單的說bt 使用的是針對檔案的流量控制方式.

              Emule採用的是客戶積分的方式,就是對所有使用者的上傳和下載量進行一個運算,從而得出一個客戶的積分值,那些積分比較高的使用者總是可以得到優先的下載 權,甚至可以不進行排隊直接下載,這樣就在一個比較長的時間內對使用者對其它使用者的整體貢獻有了一個評估.簡單的說emule採用的是針對使用者的流量控制方 式.

       5.kad與dht

              kad和dht兩者都是基於kademlia技術的分散式HASH表查詢技術,可惜的是由於協議上的區別,兩者不能互通.簡單介紹下kad,它首先給每個 客戶分配一個唯一的ID值,然後對不同的ID值進行異或來得到兩個客戶之間的"距離",kad會維護一個桶,"距離"越近的使用者桶裡的數量會越多,kad 定其的對桶裡的使用者進行清理,以保持其有效性.對於檔案和使用者emule會有兩個這個東西,所以我們可以通過kad來查詢檔案和檔案相關的使用者資訊;同樣 為了考慮冗餘的問題,kad會將其自身的資訊複製一份給"距離"它最近的一定數量的使用者,這樣就算在它下線後,這些資訊也不會丟失.bt的 dht不太瞭解,呵呵,不過估計差不多.

       6.功能比較

              emule具有查詢功能,而這在bt 只能通過網站來實現

              新版的emule在對防火牆的支援上採用的代理的方式,就是如果一個使用者處在內網,那麼它會找到一個在公網的使用者作為它的朋友.bt在這方面沒有明顯的變化,但是不同的bt客戶端實現方式有些不同的支援.

       7.總體效能比較

              個人感覺bt的方式更注重於簡單高效的快速傳輸,而emule更注重於整個網路狀態的變化及使用者體驗.單從下載效率上說bt佔優,而從網路狀態及完整強大 的協議支援上說,emule作了更多的事情.從效能上考慮,在相同網路狀態下,bt下載單檔案的能力比較強, emule比較適合於長時間的多檔案下載,這源於兩者對網路均衡及p2p模式的不同理解.