eMule協(xié)議

chenshko

來源：http://www.tinydust.net/prog/diary/2005/11/emule.html  作者：Tinyfool

最近我對(duì)P2p方面很有興趣。實(shí)際上P2p并不僅僅能用于盜版的傳播，在很多合理合法的需求中，P2p也有很廣泛的前景，至少包括了信息的冗余存儲(chǔ)，內(nèi)容分發(fā)，突破信息監(jiān)管等等方面。Google文件系統(tǒng)（Google File System）文檔中 就提到，在Google網(wǎng)絡(luò)內(nèi)分發(fā)一個(gè)新版本的應(yīng)用程序的時(shí)候，有巨大數(shù)量的客戶端需要連接到服務(wù)器去下載新版本，造成了數(shù)據(jù)傳輸熱點(diǎn)嚴(yán)重影響系統(tǒng)的運(yùn) 行，他們計(jì)劃利用P2p類的技術(shù)來解決這個(gè)問題。一段時(shí)間以來，網(wǎng)絡(luò)游戲客戶端升級(jí)都在采用或者部分采用P2p方案。這些都是在軟件分發(fā)領(lǐng)域P2p的應(yīng) 用。

eMule是我用的最多的P2p應(yīng)用，所以研究也從eMule開始。

最主要的參考文本是eMule協(xié)議1.0版，原文地址。分析的流程是簡(jiǎn)要翻譯加上我的思考，但我的目標(biāo)不在于完整的翻譯，我的思考和點(diǎn)評(píng)會(huì)用紅色標(biāo)出。

--------
電騾eMule是基于電驢eDonkey協(xié)議的。電騾網(wǎng)絡(luò)是由數(shù)百個(gè)電騾服務(wù)器和數(shù)百萬(wàn)的電騾客戶端組成的�？蛻舳吮仨氝B接到服務(wù)器來獲得網(wǎng)絡(luò)服務(wù)，這個(gè)連接要一直保持直到客戶端關(guān)閉。服務(wù)器提供集中的索引服務(wù)（類同Napster），不同的服務(wù)器之間沒有通訊。

每個(gè)電騾客戶端都預(yù)先設(shè)置好了一個(gè)服務(wù)器列表和一個(gè)本地共享文件列表�？蛻舳送ㄟ^一個(gè)單一的TCP連接到電騾服務(wù)器進(jìn)行網(wǎng)絡(luò)登陸，得到想要的文件的信息和可用客戶端的信息。（這樣造成了電騾和電驢都不能完全去中心化，雖然文件存儲(chǔ)在客戶端上。） 電騾客戶端用幾百個(gè)TCP連接與其他的客戶端連接進(jìn)行文件的上傳和下載。每個(gè)電騾客戶端為它的共享文件維護(hù)一個(gè)上傳隊(duì)列。正在下載的客戶端加入這個(gè)隊(duì)列的 底部，然后逐漸的前進(jìn)，直到他們達(dá)到隊(duì)列的頂端開始下載文件。一個(gè)客戶端可能從多個(gè)其他的電騾客戶端下載同一個(gè)文件，從不同的客戶端取得不同的部分�？蛻� 端也可以上傳一個(gè)沒有完全下載的文件的部分?jǐn)?shù)據(jù)。（文件可以分塊傳輸大大提高了效率，但是也造成了一些問題，比如源提前退出以后，所有的客戶端都是不完全數(shù)據(jù)的情況。）最終，電騾擴(kuò)展了電驢的能力允許客戶端交換關(guān)于服務(wù)器、其他客戶端和文件的信息。（這個(gè)能力又開始把中心的意義淡化。）注意，客戶端和服務(wù)器的通信都是基于TCP的。

服務(wù)器使用一個(gè)內(nèi)部數(shù)據(jù)庫(kù)來保存客戶端和文件的信息。電騾服務(wù)器不保存任何文件，它是文件位置信息的中心索引。服務(wù)器的另一個(gè)功能，正在受到質(zhì)疑，他將作為通過防火墻連接的客戶端之間的橋梁，這樣的客戶端不能接受引入的連接。橋接功能大大的增加了服務(wù)器的負(fù)載。（這個(gè)功能讓服務(wù)器承擔(dān)了過分的負(fù)擔(dān)，大大降低了服務(wù)器的能力，在設(shè)計(jì)中應(yīng)該摒棄，目前應(yīng)用中大部分的服務(wù)器已經(jīng)關(guān)閉了這個(gè)功能，也就是說兩個(gè)Low id的客戶端是不能傳輸數(shù)據(jù)的。）電騾使用UDP增強(qiáng)客戶端跟服務(wù)器和其他客戶端的通信能力。但是客戶端收發(fā)UDP信息的能力不是客戶端日常操作強(qiáng)制要求的，即使防火墻阻止客戶端收發(fā)UDP信息，客戶端仍能完美的工作。

客戶端到服務(wù)器的連接

圖一 電騾網(wǎng)絡(luò)圖

客戶端一啟動(dòng)就會(huì)用TCP連接到一個(gè)電騾服務(wù)器。服務(wù)器給客戶端提供一個(gè)客戶端ID，這個(gè)ID僅在客戶端服務(wù)器連接的生命周期內(nèi)有效（注意如果客戶端是高 ID，那么他在所有的服務(wù)器得到的ID都是一樣的，直到他的IP地址變化為止）。連接建立后，客戶端把它共享的文件列表發(fā)送給服務(wù)器。服務(wù)器把這個(gè)列表保 存在它的內(nèi)部數(shù)據(jù)庫(kù)內(nèi)，這個(gè)數(shù)據(jù)庫(kù)通常包括了數(shù)十萬(wàn)可用文件和活動(dòng)客戶端。電騾客戶端也會(huì)發(fā)送它的下載列表，包含了他想要下載的文件。后面將給出電騾客戶 端和服務(wù)器間的TCP信息交換格式細(xì)節(jié)。

連接建立以后，電騾服務(wù)器給客戶端發(fā)送一個(gè)列表，這個(gè)列表包括了那些有客戶端需要的文件的客戶端（這些客戶端叫做源）。然后，客戶端就去跟那些有所需文件的客戶端建立連接。

注意客戶端服務(wù)器的TCP連接在整個(gè)客戶端會(huì)話過程中都會(huì)保持。初始化握手之后，事務(wù)主要是由用戶活動(dòng)觸發(fā)的：有時(shí)客戶端發(fā)送一個(gè)文件查找請(qǐng)求給服務(wù)器， 服務(wù)器會(huì)返回一個(gè)查找結(jié)果，一個(gè)查找事務(wù)之后通常是一個(gè)對(duì)指定文件的源查詢，這個(gè)查詢的結(jié)果是一個(gè)可以提供該文件下載的源的列表。

電騾客戶端用UDP來跟登錄服務(wù)器以外的服務(wù)器進(jìn)行通信。UDP信息的用途是增加文件搜索能力，源搜索能力，保持連接。

客戶端到客戶端之間的連接

電騾客戶端一般是為了下載某個(gè)文件才會(huì)連接到其他的客戶端（也就是源）的。一個(gè)文件會(huì)被分為很多塊。客戶端會(huì)從多個(gè)客戶端（源）那里下載同一個(gè)文件，從不同的源下載文件的不同部分（這樣不同的部分就可以同時(shí)被下載，如果源多，下載的效率就會(huì)極高）。

當(dāng)兩個(gè)客戶端連接后，他們會(huì)交換容量信息，然后協(xié)商開始下載(或者說是上傳,這取決于視角)的時(shí)間。每個(gè)客戶端有一個(gè)下載隊(duì)列，用來保存正在等待下載的客 戶端的列表。當(dāng)電騾客戶端的下載對(duì)列為空的時(shí)候，下載請(qǐng)求會(huì)被馬上接受（除非這個(gè)請(qǐng)求者已經(jīng)被屏蔽）。如果下載對(duì)列不為空，那么新的下載請(qǐng)求就會(huì)放在隊(duì)列 之中。不會(huì)努力服務(wù)更多的客戶端，對(duì)每個(gè)下載客戶端至少保持不少于2.k字節(jié)/每秒。一個(gè)正在下載的客戶端的下載地位可能被一個(gè)對(duì)列等級(jí)（queue ranking）比他高的等待客戶端搶占，在下載進(jìn)程中的前15分鐘正在下載的客戶端的隊(duì)列等級(jí)會(huì)增長(zhǎng)用來避免產(chǎn)生顛簸（這里說的顛簸就是說，一個(gè)客戶端頻繁的從下載地位切換到等待狀態(tài)，然后再切換回去。這種頻繁的切換叫做顛簸，這對(duì)資源是種浪費(fèi)，所以要避免。）。

當(dāng)正在下載的客戶端到達(dá)了下載隊(duì)列的頂部，提供上傳的客戶端初始化一個(gè)連接用于把它需要的文件片斷傳送給它。一個(gè)電騾客戶端可能會(huì)在多個(gè)源客戶端的等待隊(duì) 列中，在每個(gè)客戶端上注冊(cè)要求同一個(gè)文件片斷。當(dāng)這個(gè)等待客戶端實(shí)際上完成了這個(gè)文件片斷的下載，他不會(huì)通知那些源客戶端刪除它的請(qǐng)求，而僅僅是在它在那 些源客戶端的隊(duì)列中排到頂端的時(shí)候拒絕上傳請(qǐng)求而已。

電騾使用一個(gè)聲望系統(tǒng)來鼓勵(lì)上傳，為了防止假冒，電騾用RSA公鑰加密技術(shù)來保護(hù)聲望系統(tǒng)。

客戶端連接中會(huì)使用很多電驢協(xié)議（eDonkey protocol）沒有定義的消息，這些消息叫做擴(kuò)展協(xié)議。擴(kuò)展協(xié)議用來實(shí)現(xiàn)信用系統(tǒng)，用來進(jìn)行信息交換（例如，服務(wù)器列表的更新和源的更新），通過對(duì)文 件塊進(jìn)行壓縮提升發(fā)送和接收的效率。電騾客戶端連接中有限地使用UDP去周期其他客戶端的狀態(tài)。

客戶端ID

客戶端是一個(gè)4字節(jié)的標(biāo)識(shí)符，在跟服務(wù)器連接握手的時(shí)候由服務(wù)器提供的�？蛻舳薎D僅在客戶端服務(wù)器TCP連接的生命期內(nèi)可用，雖然如果客戶端是高ID （High ID），它在任何服務(wù)器分配的客戶端ID都一樣，除非IP變化了�？蛻舳薎D分為低ID（low ID）和高ID。電騾服務(wù)器通常會(huì)給不能接受連接的客戶端分配低ID。擁有低ID會(huì)限制客戶端在電騾網(wǎng)絡(luò)中的使用，甚至?xí)�造成服�?wù)器拒絕連接。高ID是由 客戶端的IP地址為基礎(chǔ)算出的。這里從電騾協(xié)議的觀點(diǎn)來看客戶端ID的分配和表示。得到高ID的客戶端允許其他的客戶端自由地連接他的電騾TCP端口（默 認(rèn)為4662）。得到高ID的客戶端在電騾網(wǎng)絡(luò)內(nèi)不受任何限制。當(dāng)服務(wù)器不能打開一個(gè)連往客戶端的電騾端口的連接時(shí)，服務(wù)器給客戶端一個(gè)低ID。這主要是 客戶端安裝了防火墻組織外來連接造成的。以下情況下，客戶端會(huì)得到低ID：

• 當(dāng)客戶端通過NAT或者代理服務(wù)器上網(wǎng)。
• 當(dāng)服務(wù)器正在忙（造成服務(wù)器的連接計(jì)數(shù)器超時(shí)，從而認(rèn)為客戶端無法連接）。

高ID通過下面的方法計(jì)算：假設(shè)機(jī)器IP地址為X.Y.Z.W，客戶端ID應(yīng)該為 X+2⁸*Y+2¹⁶*Z+2²⁴*W（big endian高位在前）。低ID總是小于15777216(0x1000000)我不知道它是怎么計(jì)算的（協(xié)議原文如此，看來低ID的算法并不重要，只要滿足條件即可。），注意從不同的服務(wù)器得到的低ID是不一樣的。

低ID的客戶端沒有公開的IP地址供其他的客戶端連接，所以所有的通信必須通過電騾服務(wù)器。這會(huì)造成服務(wù)器的負(fù)載提升，所以服務(wù)器不愿意接受低ID的客戶端。同樣，這說明低ID的客戶端不能跟其他服務(wù)器上面的低ID客戶端連接，因?yàn)殡婒叢恢С址��?wù)器間的橋接。

為了支持低ID客戶端電騾協(xié)議引入了回調(diào)機(jī)制。使用這種機(jī)制，一個(gè)高ID客戶段可以要求（通過服務(wù)器）低ID客戶端連接它來交換文件。

（現(xiàn)在大部分服務(wù)器不會(huì)拒絕低ID的客戶端連接，因?yàn)樗麄兓�本上都不幫助客戶端傳輸文件了。由此，低ID的客戶端之間也無法傳輸了。）

用戶ID

電騾支持聲望系統(tǒng)為了增加用戶的文件共享。一個(gè)用戶上傳給其他客戶端越多東西，它就得到越多的聲望，這樣它在他們的等待隊(duì)列中前進(jìn)就會(huì)越快。用戶ID是一 個(gè)128位（16字節(jié)）GUID，通過連接隨機(jī)數(shù)而產(chǎn)生，第6和第15位不是隨機(jī)生成的，他們分別是14和111。用戶ID僅在客戶端和服務(wù)器會(huì)話中有 效，用戶ID是唯一的用來標(biāo)識(shí)客戶端。用戶ID在聲望系統(tǒng)里面起了很大的作用，攻擊者冒充其他用戶就是為了得到它們聲望對(duì)應(yīng)的權(quán)利。電騾提供了加密方案用 來用戶欺詐。實(shí)現(xiàn)方式是用RSA方法來加密方法來加密信息交換。

文件ID

文件ID用于網(wǎng)絡(luò)中文件的唯一標(biāo)識(shí)，以及文件損壞的檢測(cè)和修復(fù)。注意電騾對(duì)文件進(jìn)行唯一標(biāo)識(shí)和編目不依賴于文件名，文件由其內(nèi)容哈希計(jì)算出來的全局唯一ID來標(biāo)識(shí)。文件ID有兩種，一種用來生成唯一標(biāo)識(shí)，一種用于文件損壞的檢測(cè)和修復(fù)。

文件哈希

文件是用一個(gè)128位的GUID來標(biāo)識(shí)的，這個(gè)GUID是由客戶端用文件內(nèi)容哈希計(jì)算出來的。GUID使用MD4算法計(jì)算。計(jì)算文件ID的時(shí)候文件被分成 9.28MB的大小。一個(gè)GUID是分別計(jì)算每個(gè)文件塊的哈希，然后把它們合成為一個(gè)唯一文件ID。下載客戶端完成文件塊的下載后，會(huì)計(jì)算塊的哈希和文件 上傳端發(fā)送來的文件塊哈希做比較，如果不同，就說明文件塊損壞了，客戶端將逐塊的覆蓋（一次180kb）知道哈希計(jì)算表明文件塊已經(jīng)修復(fù)為止。

根哈希

根哈希是每個(gè)文件塊用SHA1算法計(jì)算出來的，每個(gè)計(jì)算單元尺寸為180kb。它提供了更高級(jí)別的可靠性和錯(cuò)誤恢復(fù)。

電騾協(xié)議拓展

雖然電騾（eMule）完全兼容電驢（eDonkey），但是它還是實(shí)現(xiàn)了一些擴(kuò)展，用于增強(qiáng)它的功能。擴(kuò)展關(guān)注于客戶端和客戶端之間的通信，特別是安全領(lǐng)域和UDP工具。

軟件和硬件限制

服務(wù)器設(shè)定包括兩種對(duì)活躍用戶數(shù)目的限制，軟件的和硬件的。硬件限制大于等于軟件限制。當(dāng)活躍用戶數(shù)目到達(dá)了軟件限制，服務(wù)器停止接受新的低ID客戶端連接，當(dāng)用戶數(shù)目達(dá)到了硬件限制，服務(wù)器不會(huì)接受任何連接。

客戶端服務(wù)器TCP連接

每個(gè)客戶端用TCP連接一個(gè)服務(wù)器。服務(wù)器給客戶端分配一個(gè)ID，用于在會(huì)話中唯一標(biāo)識(shí)這個(gè)客戶端（高ID總是跟據(jù)它的ID地址來分配）。電騾客戶端需要一個(gè)服務(wù)器連接才能操作。客戶端不能連接到多個(gè)服務(wù)器，沒有用戶干預(yù)情況下客戶端不能動(dòng)態(tài)改變服務(wù)器。

連接建立

客戶端創(chuàng)建連接的時(shí)候，可能會(huì)同時(shí)連接到多個(gè)服務(wù)器，僅僅使用成功的登陸流程，其他的連接直接放棄。

這里有兩種連接建立的情況：

1. 高ID??服務(wù)器分配一個(gè)高ID給客戶端。
2. 低ID??服務(wù)器分配一個(gè)低ID給客戶端。
3. 拒絕??服務(wù)器拒絕客戶端的連接。
   

當(dāng)然不用說，還有服務(wù)器死機(jī)和無法連接的情況。

高ID登陸流程

高ID登錄流程

上圖描述了高ID登錄的消息交換流程。在這種情況下，客戶端創(chuàng)建一個(gè)到服務(wù)器的連接，傳送他的登錄消息給服務(wù)器。服務(wù)器用另外的TCP連接去 連接客戶端，進(jìn)行一次客戶端到客戶端的握手，用來確認(rèn)客戶端有能力接受其他的電騾客戶端的連接。在完成了客戶端到客戶端握手之后，服務(wù)器關(guān)閉第二個(gè)連接， 并發(fā)給客戶端他的ID作為客戶端服務(wù)器握手的終結(jié)。 你可能注意到上圖中的eMule info是灰色的。這是因?yàn)檫@個(gè)消息屬于eMule協(xié)議的擴(kuò)展。

低ID登陸流程

低ID登錄流程

上圖描述了產(chǎn)生低ID連接的流程。在這種情況下，服務(wù)器無法連接到客戶端（客戶端到客戶端的握手），所以給客戶端分配了一個(gè)低ID。通常服務(wù)器消息會(huì)包括 這樣的一個(gè)警告“Warning [server details] - You have a lowid. Please review your network config and/or your settings.”。不管高ID還是低ID，握手都是由id change消息結(jié)束的，這個(gè)消息給客戶端在下面的跟服務(wù)器的會(huì)話提供了一個(gè)客戶端ID。

登錄被拒絕流程

登錄被拒絕流程

上圖描述了登錄被拒絕的流程。當(dāng)客戶端是低ID或者服務(wù)器已經(jīng)到達(dá)了硬件能力極限，服務(wù)器都有可能拒絕登錄。服務(wù)器消息里面會(huì)包含拒絕理由的簡(jiǎn)單描述。

連接開始的信息交換

客戶端和服務(wù)器成功建立連接之后會(huì)交換一些設(shè)置消息。這些消息的用途是更新兩端的狀態(tài)信息�？蛻舳耸紫劝阉�的共享文件列表發(fā)送給服務(wù)器，然后它要求更新它 的服務(wù)器列表。服務(wù)器發(fā)送它的狀態(tài)和版本，然后發(fā)送它知道的eMule服務(wù)器列表，并提供一些自識(shí)別的細(xì)節(jié)。最后客戶端詢問源（可以用來下載它的下載文件 列表中的文件的客戶端），服務(wù)器返回一系列消息，知道所有的源列表都被客戶端得到為止。

文件搜索

文件搜索是由用戶觸發(fā)的。這個(gè)操作是簡(jiǎn)單的，一個(gè)搜索請(qǐng)求發(fā)給服務(wù)器后，服務(wù)器會(huì)返回一個(gè)搜索結(jié)果。當(dāng)結(jié)果有很多的時(shí)候，搜索結(jié)果消息會(huì)被壓縮。然后，用 戶選擇下載其中的一個(gè)或多個(gè)文件，客戶端會(huì)請(qǐng)求所選文件的源，服務(wù)器返回一個(gè)所請(qǐng)求文件的源的列表。一個(gè)可選的服務(wù)器狀態(tài)信息可能會(huì)在發(fā)現(xiàn)源的消息之前發(fā) 送給客戶端。這個(gè)狀態(tài)信息包含了服務(wù)器支持的當(dāng)前用戶和文件數(shù)量。注意，這是一個(gè)UDP補(bǔ)充消息，用來增強(qiáng)客戶端定位源的能力的。確定這些源是新的以后， eMule客戶端進(jìn)行連接，并把他們加到他的源列表內(nèi)。根據(jù)客戶端收到源先后順序連接這些源。沒有任何優(yōu)先級(jí)機(jī)制來決定先連接哪個(gè)源。但是當(dāng)一個(gè)源同時(shí)被 下載列表中的多個(gè)文件需要的時(shí)候，有一個(gè)補(bǔ)充機(jī)制可以解決問題（注意，eMule只允許兩個(gè)客戶端間建立一個(gè)傳輸連接）。這個(gè)選擇算法寄予用戶指定的文件 優(yōu)先級(jí)，如果沒有優(yōu)先級(jí)就根據(jù)字母順序。

回調(diào)機(jī)制

回調(diào)機(jī)制是設(shè)計(jì)用來克服低ID客戶端無法接受連入連接的問題的，這樣他們也可以跟其他的客戶端共享文件。這個(gè)機(jī)制很簡(jiǎn)單：如果客戶端A和B都連接到同一個(gè) eMule服務(wù)器，A需要的一個(gè)文件在B上，而B是一個(gè)低ID，A可以給服務(wù)器發(fā)送一個(gè)回調(diào)請(qǐng)求，請(qǐng)求服務(wù)器要求B反過來連接A。服務(wù)器已經(jīng)跟B有了一個(gè) TCp連接，發(fā)送給B回調(diào)請(qǐng)求消息，把A的IP和端口提供給B。B就可以連接到A，把文件發(fā)送給A，而不需要服務(wù)器更多的參與。很明顯，只有高ID客戶端 可以要求低ID客戶端回調(diào)（低ID沒有能力接受連入的連接）（這就是為什么高ID可以跟任何的源連接，而低ID只能跟高ID連接的原因）。這也是允許兩個(gè)低ID客戶端通過服務(wù)器交換文件的方法，服務(wù)器作為中轉(zhuǎn)。但是因?yàn)檫@樣對(duì)服務(wù)器負(fù)擔(dān)太重，目前大部分的服務(wù)器已經(jīng)不在支持中轉(zhuǎn)了。