Gnutella协议中文版

转载：http://blog.chinaunix.net/uid-11572501-id-2868680.html

工作原理

要了解Gnutella网络是怎样工作的，先设想一个大的由用户（称为“节点”）组成的环，每个节点都有Gnutella客户端软件运行。当初始启动时，客户端软件必须进行 自举（Bootstrapping）并找到至少一个其它节点，有多种不同的方法可以达到这一功能，包括软件内置的一组正在工作的已经存在的地址列表，Web缓存的已知节点更新（称为  GWebCaches）, UDP服务器缓存以及 IRC。一旦连接上，客户端就会请求一张活动地址列表。

当用户想要进行搜索时，客户向每一个活动联接节点发送请求。在历史上（协议0.4版本），一个客户的活动联接节点数十分小（大约是5），所以每一个收到请求的联接节点都会再向其自身的所有联接节点转发该条请求，如此继续下去，直到该请求数据包在网络中被转发的“跳数”超过一个预先设定的数值（最大为7）。

到了0.6版之后，Gnutella网络中的节点被划分为叶节点（leaf nodes）与超节点（ultra nodes 或 ultrapeers）。 每个叶节点仅与少数（一般为3）超节点连接，而每一个超节点与多于32个的其它超节点相连。在这种更高的出度（outdegree）下，先前提到的一条查询在网络中能达到的最大“跳数”被降低到4。

叶节点与超节点利用查询路由协议（Query Routing Protocol）来交换查询路由表（Query Routing Table (QRT)）。叶节点将它的QRT发送到每一个与之连接的超节点，超节点随后将每一个与之相连接的叶节点传来的QRT以及其本身的QRT合并，并且将其与自身的邻居节点交换。

在实际中，这种在Gnutella网络中的搜索模式是十分不可靠的。由于每一个节点都是一台普通的计算机用户，他们经常连接或者断开网络，所以整个Gnutella网络结构永远都不是完全稳定的。Gnutella网络搜索的带宽消耗也是随着连接用户的增加而指数递增的 [1]，经常饱和的连接会导致较慢的节点失去作用。因此，搜索请求在网络中会被经常丢弃，与整个网络相比，大多数的查询只会到达其中的很少一部分节点。

协议功能及扩展

Gnutella曾经是一种纯粹的基于洪泛式请求（query flooding）协议。早期的Gnutella 0.4版使用5种不同的数据包种类，即是：

• ping：用于发现网络中的节点
• pong：用于回覆ping消息
• query：用于寻找某一个文件search for a file
• query hit：用于回覆query消息
• push：用于处于防火墙后的服务器的下载请求

以上不同消息包的定义主要是为了处理Gnutella网络中的搜索功能。文件传输功能是由 HTTP协议实现的。

Gnutella协议的开发目前由 GDF（Gnutella开发者论坛）所领导。许多扩展协议已经或正在由不同的软件商以及GDF的自由开发人员开发。这些扩展包括智能查询路由（intelligent query routing）、 SHA-1校验码、query hit transmission via  UDP、基于UDP的查询（querying via UDP）、基于 TCP的动态查询（dynamic queries via TCP）、基于UDP的文件传输（file transfers via UDP）、 XML元数据、source exchange（也被称为"the download mesh）以及parallel downloading in slices（swarming）。

在Gnutella开发网站上有试图在Gnutella 0.6版中将这些协议扩展规范完成的相关努力。由于所有的协议扩展还只是作为提议而存在于规范中，因此尽管已经过时，Gnutella 0.4版的标准至今仍是最新的完整技术规范。实际上，GDF的开发人员指出在目前的Gnutella网络中使用0.4版的消息握手机制已经十分困难，或者根本不可能，开发人员应该遵循 正在编写中的技术规范来进行开发工作。

Gnutella协议中文版

Gnutella2是一份关于发布检索的协议。虽然Gnutella协议也支持传统的客户端/中心服务器的检索规范，但Gnutella协议更主要是支持点对点的，没有中心的检索。在这个模型中，所有的客户端也是一个服务器，同样反之亦然。这些所谓的 Gnutella客户机正常情况下执行联系服务器和客户端的任务。他们提供客户端的接口使用户可以发出查询请求和看检索结果。同事他们也接收来自其它客户机的请求，检查他们自己的数据中匹配的部分，返回可用的结果。因为具有天然的分布性，一个执行Gnutella协议的网络是具有高度容错的，比如当部分客户机离线，网络服务不会被中断。

协议定义

　　Gnutella协议定义客户机通过网络通讯的方式。其中包括定义了通过客户机进行数据通讯的描述符号集和内部客户机相互交互的一些规则。以下是定义的内容：

描述定义

指令	说明
Ping指令	用于激活发现网络上的客户机。一个客户机收到一个Ping的描述符表示希望回应一个或多个Pong描述符。
Pong指令	用于回应Ping。包括一个被连接的Gnutella客户机的地址和他能提供的数据供共享的信息。
Query指令	首要的分布式网络检索机制。一个客户机收到一个Query描述符后，如果在自己的数据集中发现一个匹配的数据将回应一个QueryHit。
QueryHit指令	用于回应Query。这个描述符提供足够的信息来获取匹配Query请求的数据。
Push指令	一个用于允许防火墙中的客户端向网络提供基于文件的数据文件的机制。

　　一个Gnutella客户机通过与另一个当前在网络中的客户机建立连接来使自己与网络相连。获取另一个客户机的地址不在这个协议的定义中，这里将不作描述（客户机地址缓冲保存是当前用强制方式自动获得Gnutella客户机地址的方式）。

　　一旦网络上的另一个客户机的地址被获取，一个与该客户机的TCP/IP连接将被创建，以下的Gnutella连接请求字符串（ASCII编码）将被发送：

GNUTELLA CONNECT/<protocol version string>\n\n

<protocol version string>在当前版本中定义文ASCII字符串“0.4”（或者，同样可以是” \x30\x2e\x34”）是指当前的协议规范的版本。

注明：

1.这份文件代表事实的标准的Gnutella0.4协议，然而，有些协议的实现方案扩展了组成协议的描述符并在Gnutella网络上传送描述符时附加了额外的规则。已知的协议扩展列在本文件末尾的附录中，但可能有些在实际应用中出现的变量没有在文件中说明。

2.Gnutella的发音是new-tella

一个客户机愿意接受连接的话必须回应

GNUTELLA OK\n\n

任何其它的回应表示客户机不愿意接受连接。一个客户机拒绝连接可能有以下几种原因－一个客户机的连接缓冲池已经满了，或者他不支持同样版本的协议来作为一个响应客户机。仅此举例。

一旦一个客户机成功连接到网络上，他与其它客户机通讯通过发送和接收Gnutella协议描述字。每一个描述符前都有一个以下字节结构的描述头，如下所示：

注意：1.以下所有结构内字符次序都是在低位在后，除非另作说明。

2.所有的地址都是IP4格式

例如：

表示的IP地址为：208.17.50.4

Descriptor Header

DescriptorID网络描述符：16个字节的字符串唯一标示网络的描述符号。

Payload Descriptor负载描述符：

0x00 = Ping
0x01 = Pong
0x40 = Push
0x80 = Query
0x81 = QueryHit

TTL生存期：描述字符在删除前在Gnutella网络中向前传递的次数。每个客户端在将包向前传递前将TTL减一。当TTL等于0，描述符将不再被向前传递。

Hops描述符被向前传递的次数：作为一个描述符向前传递，头部的TTL和Hops字必须满足以下条件：

TTL(0) = TTL(i) + Hops(i)

Payload Length负载长度：表示紧接着头部后面的描述符部分的长度。下一个描述符头后的从头部算起的 Payload Length字节数，也就是没有间隔或保留字在Gnutella的数据流中。

TTL是网络中唯一的描述过期的机制。客户机应该仔细检查收到的描述符的TTL区并必要时减少它的值。滥用TTL区将会导致没有必要的网络阻塞和差劲的网络性能。

Payload Length区是客户机查找输入流中下一个描述符的唯一可靠方式。Gnutella协议不提供一个“监视”字符串或任何其它的描述符同步的方式。因此，客户机应该严格保证每一个收到的描述符的Payload Length区的有效性（至少为固定长度的描述符）。如果一个客户机不能和输入的流同步，它应该断掉与这个输入流有关的来自发送方的客户机，不管是产生这个流还是向前传递这个流的无效的客户机。紧接着描述头的是一个有效装载包含以下之一的描述符：

Ping (0x00)

Ping描述符没有相关的有效装载和数据长度为0。一个Ping只是简单地有一个描述头表述，它的有效装载区是0x00和装载长度区为0x00000000。

一个客户机用Ping描述符
Pong (0x01)

Port

Port：同意接收响应的客户机的端口

IP Address：响应的客户机的地址（此数据区高位字节在后）

Number of Files Shared：本机共享文件的数量

Number of Kilobytes Shared：本机所有共享文件的空间大小，以K为单位

Query (0x80)

字节偏移0 1 2 …

Minimum Speed ：最小响应速度，响应的客户机的速度必须在此速度之上（ 以K/秒为单位）

Search criteria：查询关键字，一个零结尾的字符串。这个字符串的最大长度由描述头的Payload Length负载长度规定。

QueryHit (0x81)

Number of Hits:符合搜索条件的结果数

Port:能接受连接的客户机的端口

IP Address :响应客户机的地址（此数据区高位字节在后）

Speed :响应客户机的连线速度（以K/秒为单位）

Result Set :响应查询的结果集。其中包含一个Number_of_Hits的部分，其中每个都包含以下结构

　　File Index：一个数字，由响应的客户机指定，用来唯一标示响应的文件结果

　　File Size：与File index相符的文件的大小

　　File Name：已双零结尾的与File index相符的文件的名字

Result Set的长度由描述头的Payload Length负载长度规定。

Servent Identifier:一个16位的字符串用来唯一标示网络上的客户机。功能上用来标示客户机的网络地址。用在Push指令上。

QueryHit指令只有在收到一个Query指令后响应才发出。一个客户机只有在它严格符合查询关键字时才对一个Query指令进行响应。

Push (0x40)

Servent Identifier：一个16位的字符串用来唯一标示网络上的客户机，该客户机请求下载带有File_Index的文件。

File Index：下载目标客户机的文件的唯一标识，初始化的客户机应该根据返回的QueryHit指令的File_Index中的标识设置。

IP Address：下载带有File_Index的文件的客户机的地址（此数据区高位字节在后）

Port：下载带有File_Index的文件的客户机的端口

描述符路由

Gnutella网络的点对点本质要求客户机合适地路由网络（包括查询、查询响应、推送文件请求等）。一个好的客户机应该根据以下的规则路由协议的描述符：

1. Pong描述符应该只沿进入的Ping描述符的路径发送。这样可以保证只有路由Ping描述符的客户机将看到的Pong描述符作为响应返回。一个客户机如果收到一个带有描述符ID＝n的Pong描述符，但没有看到一个带有描述符ID=n的Ping描述符的，应该把Pong描述符从网络中删除。
2. QueryHit描述符应该只沿进入的Query描述符的路径发送。这样可以保证只有路由Query描述符的客户机将看到的 Pong描述符作为响应返回。一个客户机如果收到一个带有描述符ID＝n的QueryHit描述符，但没有看到一个带有描述符ID=n的Query描述符的，应该把Pong描述符从网络中删除。
3. Push描述符应该只沿进入的Query描述符的路径发送。这样可以保证只有路由QueryHit描述符的客户机将看到的 Pong描述符作为响应返回。一个客户机如果收到一个带有描述符ID＝n的Push描述符，但没有看到一个带有描述符ID=n的QueryHit描述符的，应该把Push描述符从网络中删除。一个客户机如果收到一个带有客户机ID＝n的Push描述符，但没有看到一个带有客户机ID=n的 QueryHit描述符的，应该把Push描述符从网络中删除。Push描述符通过客户机ID进行路由，而不是通过描述符ID。
4. 一个客户机将通过进来的Ping和Query描述符向前到达所有与它直接相连的客户机，但负责传递进入的Ping和Query的那些客户机除外。
5. 一个客户机将在它向前传递描述符到与它直接相连的客户机前，减少一个描述头的TTL区，并增加Hops区。如果，减少头部的TTL区后，TTL中的值等于0，描述符将不再向前传递到任何连接。
6. 一个客户机收到一个与它之前接收过的描述符具有相同有效描述符和描述符ID的描述符，应该避免再向前传递这个描述符到其它的连接。它已经接收过这样一个描述符，再把它传递出去只会浪费带宽。

文件下载

　　一旦一个客户机收到一个QueryHit描述符，它将初始化直接下载描述符的结果集其中的一个文件。文件将不通过Gnutella的网络进行下载，一个源客户机和目标客户机直接建立连接进行数据的传输。文件数据从来不会通过Gnutella网络进行传送。

文件下载协议是HTTP协议。初始化下载的客户机发送一个请求字符串到目标客户机，格式如下：

GET /get/<File Index>/<File Name>/ HTTP/1.0\r\n
Connection: Keep-Alive\r\n
Range: bytes=0-\r\n
User-Agent: Gnutella\r\n3\r\n

这里的<File Index>和<File Name>是一个QueryHit描述符结果集中的File Index/File Name对中的其中之一。例如，如果QueryHit描述符中包含入口

File Index	2468
File Size	4356789
File Name	Foobar.mp3\x00\x00

那么一个通过这个入口下载这个文件的描述请求应该如下：
GET /get/2468/Foobar.mp3/ HTTP/1.0\r\n
Connection: Keep-Alive\r\n
Range: bytes=0-\r\n
User-Agent: Gnutella\r\n

服务器收到下载请求将回应于HTTP1.0兼容的头，例如：
HTTP 200 OK\r\n
Server: Gnutella\r\n
Content-type: application/binary\r\n
Content-length: 4356789\r\n
\r\n

文件数据随后将被读出，包括HTTP响应中提供的Gontent-length中描述的字节数。

Gnutella协议提供HTTP规范中的参数的支持，所以一个中断的下载可以按照中断的位置重连。

防火墙后的客户机

　　并非总是在初始化一个文件下载后都可以与Gnutella客户机建立直接连接。客户机可能在防火墙后并不允许通过它的Gnutella 端口进入的连接。如果一个直接连接不能建立，客户机若想下载文件可能会请求共享文件的客户机采用“推送”方式来代替。一个客户机可以通过发送一个Push 文件推送请求到发送QueryHit请求的客户机处来实现。作为Push请求目标的客户机（在客户机标志区标示一个Push的描述符）应该接收Push描述符，尝试建立一个新的TCP/IP连接到请求客户机（在Push描述符中标示有IP地址和端口）。如果直接连接不能建立，那么可能发起Push请求的客户机自己也在防火墙后。这种情况，文件传输将不能进行。

　　如果一个直接连接可以从防火墙后的客户机建立到发起Push请求的客户机，防火墙后的客户机应该立刻发送以下的：

GIV <File Index>:<Servent Identifier>/<File Name>\n\n

这里的<File Index>:和<Servent Identifier>是Push请求头中的的文件索引和客户机标示，<File Name>是本地文件表中文件索引为<File Index>的文件。客户机收到GIV请求头（Push请求者）应该从头中取出<File Index>和<File Name>并构造一个如下的HTTP GET请求：
GET /get/<File Index>/<File Name>/ HTTP/1.0\r\n
Connection: Keep-Alive\r\n
Range: bytes=0-\r\n
User-Agent: Gnutella\r\n3
\r\n

余下的下载过程和上面所述的“文件下载”内容一致。

可允许的用户－代理字符串由HTTP标准定义。客户机开发者不能对这里使用的值做自己的假定。其中的值“Gnutella”只是用来演示举例而已。

附录1： Gnutella 协议扩展

扩展的Query Hit( 描述更新03/15/2001) 首先以BearShare v1.3.0 为例，扩展的QueryHit 描述符通过在原先的Gnutella QueryHit 描述符的Servent ID标识符和双null结尾的文件名之间放置额外的数据进行扩展。 一个扩展的QueryHit 描述符将有以下的结构：

QueryHit (0x81)

BearShare的Trailer区的机构如下：

Trailer

Vendor Code

四个大小写敏感的字母代表一个供应商代号。已经确认的代号如下：

Open Data Size

包含Open Data 域的长度（以字节计算）

Open Data

包含2个单字节的标志域,,具有以下的数据分布和次序

flags

flagUploadSpeed=1 当且仅当flags2中的flagUploadSpeed标志有意义时

flagHaveUploaded=1 当且仅当flags2中的flagHaveUploaded标志有意义时

flagBusy=1 当且仅当flags2中的flagBusy标志有意义时

flagPush=1 当且仅当客户机处于防火墙后或者未接受进入的连接时

r=保留字,将来使用

flags2

flagUploadSpeed=1 当且仅当QueryHit描述符中的Speed域包含上10次上传的最高平均速率时

flagHaveUploaded=1 当且仅当客户机成功上传至少一次文件时

flagBusy=1 当且仅当客户机的上传插槽满时

flagPush=1当且仅当flags中的flagPush标志有意义时

r=保留字,将来使用

Private Data

未作正式文档说明的BearShare的数据，这个区域的数据长度可以根据以下决定

Query Hit Descriptor Payload Size-(Open Data Size+4+1)

开发者处理扩展的一种方式为

(1) 意识到一进来的QueryHit 可以或者可能不包含附加数据，在结果下落之后，和在Servent 标识符以前。 没有完整说明适合是可能在场的字节的数量存在，或者他们内容。

使用负载长度领域并且算字节，当他们被从这条溪读确定是否扩展字节在场。

(2) 如果他们是，从排除16 字节Servent 标识符的输入流中读取数据。

(3) 象往常一样处理QueryHit。

Gnotella

　　Gnotella客户端软件的版本至早在0.73(2000年7月30发布)时把额外的数据放置在QueryHit 描述符中。 根据Gnutella 0.4 协议说明，每一个QueryHit 描述符中的结果集要用双nul结尾。 Gnotella 可以把额外的数据安置在两nuls 之间。 虽然它的精确的数据格式未知，但是这些数据代表比特率，采样率，和MP3 文件的播放时间,通过结果集的入口处来描述。 如果结果集入口处所描述的不是一个MP3文件的话，没有数据被放置在nuls 之间。

　　在没有不利的结果的情况下，一些客户机通过简单得抛弃nuls之间的数据来扩展Gnotella的QueryHit描述符。 另外的一些客户机可能，由于发现结果中的数据没有向预期那样结束，不能正确得读取描述符。 一旦读错，引起后来一系列的误处理，并且它的连接可能会断开。