napster是一个典型的混合式P2P网络，在整个网络中所有的peer都要与服务器相连，虽然服务器不保存完整的文件，但是服务器却保持网络中各个peer能够提供用于共享的文件一些信息，它的工作原理图如下：
Napster原理图
从上图可以看出，Napster网站是一个服务器集群。每一个服务器保存一部分用户的共享文件索引信息，所有的服务器互连、整合起来对网站外面的Napster用户提供统一的访问接口，在每个用户看来他们访问的都是同一个服务器。
每一个napster用户了解到服务器集群的一台服务器，他愿意与其他用户共享的文件索引信息发
送到服务器，服务器记录这些信息以及该用户的位置，并将它们做成一条索引添加到原有索引表中。当用户想要查询一个文件时，首先将“查询”消息（Q）发到与
其相连的服务器，该服务器收到Q以后，与其他服务器协作处理查询消息Q，处理完成以后将“回复”消息（R）返回给该用户，这条消息包含一个表单，列出所有
查到的匹配的文件索引信息。收到R以后，用户在表单中选择他想要的文件，根据文件索引中对应的位置与其他用户直接建立连接下载文件。
Napster的服务器集群有两个作用：
1.维护所有Napster用户的共享文件索引
2.监控系统中每一个用户的状态
Napster的出现与流行可以说是网络历史上的一个奇迹，但是它只是一颗璀璨的流星，它的光亮
并没有维持很久。Napster被多家唱片公司以侵犯版权为由推上了被告席而在一次成为业界的焦点，最终以Napster的陨落作为谢幕。这里面的教训值
得我们深思，那就是P2P网络所面临的最大困境：版权问题的法律纠纷！！
Gnutella的体系架构
Gnutella与旧式Napster之间有两大相似点：
- 用户将想要共享的文件放到硬盘上，并使其可供任何其他人以对等方式下载。
- 用户使用一个Gnutella软件来连接Gnutella网络。
Gnutella与旧式Napster之间也有两大不同：
- 没有使用中央数据库以存储Gnutella网络中的所有可用文件，使用的是分布式查询法。这样，网络上所有的计算机都能告知彼此可共享的文件。
- 有许多不同客户程序可用于访问Gnutella网络。
由于具有这两个特点，一个简单的法院命令很难关闭Gnutella，法院必须寻找一种方法在ISP和互联网的主干网级别上阻塞所有的Gnutella网络通信，才能阻止人们进行共享。
要了解Gnutella网络是怎样工作的，先设想一个大的由用户（称为“节点”）组成的环，每个节点都有Gnutella客户端软件运行。当初始启动时，客户端软件必须进行（Bootstrapping）并找到至少一个其它节点，有多种不同的方法可以达到这一功能，包括软件内置的一组正在工作的已经存在的地址列表，Web缓存的已知节点更新（称为
GWebCaches）, UDP服务器缓存以及。一旦连接上，客户端就会请求一张活动地址列表。
当用户想要进行搜索时，客户向每一个活动联接节点发送请求。在历史上（协议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网络搜索的带宽消耗也是随着连接用户的增加而指数递增的，经常饱和的连接会导致较慢的节点失去作用。因此，搜索请求在网络中会被经常丢弃，与整个网络相比，大多数的查询只会到达其中的很少一部分节点。
电驴（eMule）建立于多点文件传输协议之上。一个电驴网络由服务器端和客户端两部分组成。服务器端是客户端连接的、为了搜索和查找可以下载用户的桥
梁。服务器列表像电话本一样排列，客户通过浏览它而获取他需要的文件所有者的客户端信息。在下载过程中，没有下载文件通过服务器端。
主要有以下几种功能：搜索、下载。
搜索（Searching）：每一个客户端连接到一个服
务器作为他的主服务器。在连接时，由客户端告诉主服务器他共享了哪些文件，以及IP地址等其他信息。所以每一个服务器会记录所有登录到他服务器上的以上信
息。在本服务器搜索时，它会通过匹配记录的已知以上信息把查找结果反馈给搜索的客户端列表。当您使用扩展搜索(extend
search)时，您的搜索请求和应答结果通过发送限制带宽的UDP包连接到客户端本身的服务器列表(server.met)对应的某一个ip地址的服务
器。
下载（Downloading）：当客户端选择了一个文件下载时，它首先收集一个拥有
该文档的客户端的列表。它会先行查询主服务器所有登录用户他们是否拥有该文件。然后再连接和查选其他服务器的登录用户所拥有该文件的客户端列表。一旦它找
到拥有该文件的其他客户端，它将请求每个客户端发送这个文件的不同片。直至最后文件由这个不同的片组装成一个完整的文件。
在查找到下载源(其他客户端)后，下载就是客户端和客户端通过点对点(P2P)进行直接对话了。期间没有数据流通过服务器。在进行暂停/恢复的时候，我们
选择的下载列表已经获取，它暂停的仅仅是客户端和客户端之间的TCP连接然后恢复TCP连接。这个过程只有再恢复时通过客户端向服务器端发送22个字节后
即可。占用的仅仅是22个字节的网络流量。暂停是不通过你登录的服务器进行，也无须你登录的主服务器进行任何干预和操作。所以说，它并未占用主服务什么资
源，只是在你已经和主服务器连接的通道上发送22个字节而已。
Bittorrent的工作原理其实很简单,他就是将一份数据分隔成256K大小的数据分组,并在Bittorrent
网络中一群用户相互协作完成这些数据的分发,用户参与数据分发的信息已文件的形式存储,一般可以通过web网站获取这些信息｡但是实际数据传输依靠的不是
Http协议,而是由专门的P2P协议来完成,这些对于用户都是透明的｡
根据BitTorrent协议,文件发布者会根据要发布的文件生成提供一个.torrent文件,即种子文件,也简称为“种子"｡
.torrent文件本质上是文本文件,包含Tracker信息和文件信息两部分｡Tracker信息主要是BT下载中需要用到的Tracker服务器的
地址和针对Tracker服务器的设置,文件信息是根据对目标文件的计算生成的计算结果根据BitTorrent协议内的B编码规则进行编码｡它的主要原
理是需要把提供下载的文件虚拟分成大小相等的块,块大小必须为2k的整数次方(由于是虚拟分块,硬盘上并不产生各个块文件),并把每个块的索引信息和
Hash验证码写入.torrent文件中;所以,.torrent文件就是被下载文件的“索引"｡
下载者要下载文件内容,需要先得到相应的.torrent文件,然后使用BT客户端软件进行下载｡
下载时,BT客户端首先解析.torrent文件得到Tracker地址,然后连接Tracker服务器｡Tracker服务器回应下载者的请求,
提供下载者其他下载者(包括发布者)的IP｡下载者再连接其他下载者,根据.torrent文件,两者分别对方告知自己已经有的块,然后交换对方没有的数
据｡此时不需要其他服务器参与,分散了单个线路上的数据流量,因此减轻了服务器负担｡
下载者每得到一个块,需要算出下载块的Hash验证码与.torrent文件中的对比,如果一样则说明块正确,不一样则需要重新下载这个块｡这种规定是为了解决下载内容准确性的问题｡
DHT网络
DHT全称叫分布式哈希表(Distributed Hash
Table)，是一种分布式存储方法。在不需要服务器的情况下，每个客户端负责一个小范围的路由，并负责存储一小部分数据，从而实现整个DHT网络的寻址
和存储。新版BitComet允许同行连接DHT网络和Tracker，也就是说在完全不连上[Tracker服务器的情况下，也可以很好的下载，因为它
可以在DHT网络中寻找下载同一文件的其他用户。BitComet的DHT网络协议和BitTorrent测试版的协议完全兼容，也就是说可以连入一个同
DHT网络分享数据。
另外，这里使用的DHT算法叫Kademlia（在eMule中也有使用，常把它叫做KAD，具体实现协议有所不同）。
Kad 是一种分布式哈希表（DHT）技术，不过和其他DHT 实现技术比较，如Chord、CAN、Pastry 等，Kad 通过独特的以异或算法（XOR）为距离度量基础，建立了一种全新的DHT拓扑结构，相比于其他算法，大大提高了路由查询速度。
阅读(10089) | 评论(0) | 转发(0) |
