分类： 网络与安全
2011-09-20 15:23:47
来源： 作者：
最近我对P2p方面很有兴趣。实际上P2p并不仅仅能用于盗版的传播，在很多合理合法的需求中，P2p也有很广泛的前景，至少包括了信息的冗余存储，内容分发，突破信息监管等等方面。中 就提到，在Google网络内分发一个新版本的应用程序的时候，有巨大数量的客户端需要连接到服务器去下载新版本，造成了数据传输热点严重影响系统的运 行，他们计划利用P2p类的技术来解决这个问题。一段时间以来，网络游戏客户端升级都在采用或者部分采用P2p方案。这些都是在软件分发领域P2p的应 用。
eMule是我用的最多的P2p应用，所以研究也从eMule开始。
最主要的参考文本是eMule协议1.0版，。分析的流程是简要翻译加上我的思考，但我的目标不在于完整的翻译，我的思考和点评会用红色标出。
--------
电骡eMule是基于电驴eDonkey协议的。电骡网络是由数百个电骡服务器和数百万的电骡客户端组成的。客户端必须连接到服务器来获得网络服务，这个连接要一直保持直到客户端关闭。服务器提供集中的索引服务（类同Napster），不同的服务器之间没有通讯。
每个电骡客户端都预先设置好了一个服务器列表和一个本地共享文件列表。客户端通过一个单一的TCP连接到电骡服务器进行网络登陆，得到想要的文件的信息和可用客户端的信息。（这样造成了电骡和电驴都不能完全去中心化，虽然文件存储在客户端上。） 电骡客户端用几百个TCP连接与其他的客户端连接进行文件的上传和下载。每个电骡客户端为它的共享文件维护一个上传队列。正在下载的客户端加入这个队列的 底部，然后逐渐的前进，直到他们达到队列的顶端开始下载文件。一个客户端可能从多个其他的电骡客户端下载同一个文件，从不同的客户端取得不同的部分。客户 端也可以上传一个没有完全下载的文件的部分数据。（文件可以分块传输大大提高了效率，但是也造成了一些问题，比如源提前退出以后，所有的客户端都是不完全数据的情况。）最终，电骡扩展了电驴的能力允许客户端交换关于服务器、其他客户端和文件的信息。（这个能力又开始把中心的意义淡化。）注意，客户端和服务器的通信都是基于TCP的。
服务器使用一个内部数据库来保存客户端和文件的信息。电骡服务器不保存任何文件，它是文件位置信息的中心索引。服务器的另一个功能，正在受到质疑，他将作为通过防火墙连接的客户端之间的桥梁，这样的客户端不能接受引入的连接。桥接功能大大的增加了服务器的负载。（这个功能让服务器承担了过分的负担，大大降低了服务器的能力，在设计中应该摒弃，目前应用中大部分的服务器已经关闭了这个功能，也就是说两个Low id的客户端是不能传输数据的。）电骡使用UDP增强客户端跟服务器和其他客户端的通信能力。但是客户端收发UDP信息的能力不是客户端日常操作强制要求的，即使防火墙阻止客户端收发UDP信息，客户端仍能完美的工作。
客户端一启动就会用TCP连接到一个电骡服务器。服务器给客户端提供一个客户端ID，这个ID仅在客户端服务器连接的生命周期内有效（注意如果客户端是高 ID，那么他在所有的服务器得到的ID都是一样的，直到他的IP地址变化为止）。连接建立后，客户端把它共享的文件列表发送给服务器。服务器把这个列表保 存在它的内部数据库内，这个数据库通常包括了数十万可用文件和活动客户端。电骡客户端也会发送它的下载列表，包含了他想要下载的文件。后面将给出电骡客户 端和服务器间的TCP信息交换格式细节。
连接建立以后，电骡服务器给客户端发送一个列表，这个列表包括了那些有客户端需要的文件的客户端（这些客户端叫做源）。然后，客户端就去跟那些有所需文件的客户端建立连接。
注意客户端服务器的TCP连接在整个客户端会话过程中都会保持。初始化握手之后，事务主要是由用户活动触发的：有时客户端发送一个文件查找请求给服务器， 服务器会返回一个查找结果，一个查找事务之后通常是一个对指定文件的源查询，这个查询的结果是一个可以提供该文件下载的源的列表。
电骡客户端用UDP来跟登录服务器以外的服务器进行通信。UDP信息的用途是增加文件搜索能力，源搜索能力，保持连接。
电骡客户端一般是为了下载某个文件才会连接到其他的客户端（也就是源）的。一个文件会被分为很多块。客户端会从多个客户端（源）那里下载同一个文件，从不同的源下载文件的不同部分（这样不同的部分就可以同时被下载，如果源多，下载的效率就会极高）。
当两个客户端连接后，他们会交换容量信息，然后协商开始下载(或者说是上传,这取决于视角)的时间。每个客户端有一个下载队列，用来保存正在等待下载的客 户端的列表。当电骡客户端的下载对列为空的时候，下载请求会被马上接受（除非这个请求者已经被屏蔽）。如果下载对列不为空，那么新的下载请求就会放在队列 之中。不会努力服务更多的客户端，对每个下载客户端至少保持不少于2.k字节/每秒。一个正在下载的客户端的下载地位可能被一个对列等级（queue ranking）比他高的等待客户端抢占，在下载进程中的前15分钟正在下载的客户端的队列等级会增长用来避免产生颠簸（这里说的颠簸就是说，一个客户端频繁的从下载地位切换到等待状态，然后再切换回去。这种频繁的切换叫做颠簸，这对资源是种浪费，所以要避免。）。
当正在下载的客户端到达了下载队列的顶部，提供上传的客户端初始化一个连接用于把它需要的文件片断传送给它。一个电骡客户端可能会在多个源客户端的等待队 列中，在每个客户端上注册要求同一个文件片断。当这个等待客户端实际上完成了这个文件片断的下载，他不会通知那些源客户端删除它的请求，而仅仅是在它在那 些源客户端的队列中排到顶端的时候拒绝上传请求而已。
电骡使用一个声望系统来鼓励上传，为了防止假冒，电骡用RSA公钥加密技术来保护声望系统。
客户端连接中会使用很多电驴协议（eDonkey protocol）没有定义的消息，这些消息叫做扩展协议。扩展协议用来实现信用系统，用来进行信息交换（例如，服务器列表的更新和源的更新），通过对文 件块进行压缩提升发送和接收的效率。电骡客户端连接中有限地使用UDP去周期其他客户端的状态。
客户端是一个4字节的标识符，在跟服务器连接握手的时候由服务器提供的。客户端ID仅在客户端服务器TCP连接的生命期内可用，虽然如果客户端是高ID （High ID），它在任何服务器分配的客户端ID都一样，除非IP变化了。客户端ID分为低ID（low ID）和高ID。电骡服务器通常会给不能接受连接的客户端分配低ID。拥有低ID会限制客户端在电骡网络中的使用，甚至会造成服务器拒绝连接。高ID是由 客户端的IP地址为基础算出的。这里从电骡协议的观点来看客户端ID的分配和表示。得到高ID的客户端允许其他的客户端自由地连接他的电骡TCP端口（默 认为4662）。得到高ID的客户端在电骡网络内不受任何限制。当服务器不能打开一个连往客户端的电骡端口的连接时，服务器给客户端一个低ID。这主要是 客户端安装了防火墙组织外来连接造成的。以下情况下，客户端会得到低ID：
高ID通过下面的方法计算：假设机器IP地址为X.Y.Z.W，客户端ID应该为 X+28*Y+216*Z+224*W（big endian高位在前）。低ID总是小于15777216(0x1000000)我不知道它是怎么计算的（协议原文如此，看来低ID的算法并不重要，只要满足条件即可。），注意从不同的服务器得到的低ID是不一样的。
低ID的客户端没有公开的IP地址供其他的客户端连接，所以所有的通信必须通过电骡服务器。这会造成服务器的负载提升，所以服务器不愿意接受低ID的客户端。同样，这说明低ID的客户端不能跟其他服务器上面的低ID客户端连接，因为电骡不支持服务器间的桥接。
为了支持低ID客户端电骡协议引入了回调机制。使用这种机制，一个高ID客户段可以要求（通过服务器）低ID客户端连接它来交换文件。
（现在大部分服务器不会拒绝低ID的客户端连接，因为他们基本上都不帮助客户端传输文件了。由此，低ID的客户端之间也无法传输了。）
电骡支持声望系统为了增加用户的文件共享。一个用户上传给其他客户端越多东西，它就得到越多的声望，这样它在他们的等待队列中前进就会越快。用户ID是一 个128位（16字节）GUID，通过连接随机数而产生，第6和第15位不是随机生成的，他们分别是14和111。用户ID仅在客户端和服务器会话中有 效，用户ID是唯一的用来标识客户端。用户ID在声望系统里面起了很大的作用，攻击者冒充其他用户就是为了得到它们声望对应的权利。电骡提供了加密方案用 来用户欺诈。实现方式是用RSA方法来加密方法来加密信息交换。
文件ID用于网络中文件的唯一标识，以及文件损坏的检测和修复。注意电骡对文件进行唯一标识和编目不依赖于文件名，文件由其内容哈希计算出来的全局唯一ID来标识。文件ID有两种，一种用来生成唯一标识，一种用于文件损坏的检测和修复。
文件是用一个128位的GUID来标识的，这个GUID是由客户端用文件内容哈希计算出来的。GUID使用MD4算法计算。计算文件ID的时候文件被分成 9.28MB的大小。一个GUID是分别计算每个文件块的哈希，然后把它们合成为一个唯一文件ID。下载客户端完成文件块的下载后，会计算块的哈希和文件 上传端发送来的文件块哈希做比较，如果不同，就说明文件块损坏了，客户端将逐块的覆盖（一次180kb）知道哈希计算表明文件块已经修复为止。
根哈希是每个文件块用SHA1算法计算出来的，每个计算单元尺寸为180kb。它提供了更高级别的可靠性和错误恢复。
虽然电骡（eMule）完全兼容电驴（eDonkey），但是它还是实现了一些扩展，用于增强它的功能。扩展关注于客户端和客户端之间的通信，特别是安全领域和UDP工具。
服务器设定包括两种对活跃用户数目的限制，软件的和硬件的。硬件限制大于等于软件限制。当活跃用户数目到达了软件限制，服务器停止接受新的低ID客户端连接，当用户数目达到了硬件限制，服务器不会接受任何连接。
每个客户端用TCP连接一个服务器。服务器给客户端分配一个ID，用于在会话中唯一标识这个客户端（高ID总是跟据它的ID地址来分配）。电骡客户端需要一个服务器连接才能操作。客户端不能连接到多个服务器，没有用户干预情况下客户端不能动态改变服务器。
客户端创建连接的时候，可能会同时连接到多个服务器，仅仅使用成功的登陆流程，其他的连接直接放弃。
这里有两种连接建立的情况：
当然不用说，还有服务器死机和无法连接的情况。
上图描述了高ID登录的消息交换流程。在这种情况下，客户端创建一个到服务器的连接，传送他的登录消息给服务器。服务器用另外的TCP连接去 连接客户端，进行一次客户端到客户端的握手，用来确认客户端有能力接受其他的电骡客户端的连接。在完成了客户端到客户端握手之后，服务器关闭第二个连接， 并发给客户端他的ID作为客户端服务器握手的终结。 你可能注意到上图中的eMule info是灰色的。这是因为这个消息属于eMule协议的扩展。
上图描述了登录被拒绝的流程。当客户端是低ID或者服务器已经到达了硬件能力极限，服务器都有可能拒绝登录。服务器消息里面会包含拒绝理由的简单描述。
客户端和服务器成功建立连接之后会交换一些设置消息。这些消息的用途是更新两端的状态信息。客户端首先把它的共享文件列表发送给服务器，然后它要求更新它 的服务器列表。服务器发送它的状态和版本，然后发送它知道的eMule服务器列表，并提供一些自识别的细节。最后客户端询问源（可以用来下载它的下载文件 列表中的文件的客户端），服务器返回一系列消息，知道所有的源列表都被客户端得到为止。
文件搜索是由用户触发的。这个操作是简单的，一个搜索请求发给服务器后，服务器会返回一个搜索结果。当结果有很多的时候，搜索结果消息会被压缩。然后，用 户选择下载其中的一个或多个文件，客户端会请求所选文件的源，服务器返回一个所请求文件的源的列表。一个可选的服务器状态信息可能会在发现源的消息之前发 送给客户端。这个状态信息包含了服务器支持的当前用户和文件数量。注意，这是一个UDP补充消息，用来增强客户端定位源的能力的。确定这些源是新的以后， eMule客户端进行连接，并把他们加到他的源列表内。根据客户端收到源先后顺序连接这些源。没有任何优先级机制来决定先连接哪个源。但是当一个源同时被 下载列表中的多个文件需要的时候，有一个补充机制可以解决问题（注意，eMule只允许两个客户端间建立一个传输连接）。这个选择算法寄予用户指定的文件 优先级，如果没有优先级就根据字母顺序。
回调机制是设计用来克服低ID客户端无法接受连入连接的问题的，这样他们也可以跟其他的客户端共享文件。这个机制很简单：如果客户端A和B都连接到同一个 eMule服务器，A需要的一个文件在B上，而B是一个低ID，A可以给服务器发送一个回调请求，请求服务器要求B反过来连接A。服务器已经跟B有了一个 TCp连接，发送给B回调请求消息，把A的IP和端口提供给B。B就可以连接到A，把文件发送给A，而不需要服务器更多的参与。很明显，只有高ID客户端 可以要求低ID客户端回调（低ID没有能力接受连入的连接）（这就是为什么高ID可以跟任何的源连接，而低ID只能跟高ID连接的原因）。这也是允许两个低ID客户端通过服务器交换文件的方法，服务器作为中转。但是因为这样对服务器负担太重，目前大部分的服务器已经不在支持中转了。
