1、P2P
没有(或极少)服务器,利用大量Peer节点相互服务,用户量可以扩展到很多。
举例:文件分发(BitTorrent)、钉钉、流媒体(KanKan)、VoIP(Skype)
2、文件分发时间
N个数据量为F的文件分发;
上载速度upload,记为u;下载速度download,记为d;
为客户端最小的下载速度;
2.1、C/S模式
服务器分发N个文件的时间 t1:;
客户端接收文件的时间 t2:;
传完N个文件至少需要的时间:max{t1,t2(min)};
2.2、P2P模式
3、非结构化P2P管理
3.1、集中式目录
当客户端上线时,告知服务器自己的IP地址、内容列表;
服务器管理所有上线客户端的IP和内容列表;
客户端向服务器查询资源,服务器返回拥有资源的IP,客户端再与之连接传输文件;
3.2、泛洪查询 : Gnutella
- 没有中心服务器;
- 协议最初不开源,后来不成功改成开源的,但效果也并不很好;
利用图,一个对等方通常连接(少于)10个节点;
客户端A查询资源,首先向与自己连接的节点查询;
这些节点再向与自己连接的节点查询,.......
查到之后层层返回到A,A再与之建立连接传输文件;
那么一开始如何连接到节点呢?
在安装软件的时候,有一个死党列表,存着大概率在线的节点;
当A上线后,向列表上的节点发出ping,列表上节点再向与他连接的节点发出ping,每个接收到ping的节点返回pong;
A根据pong的节点,随机选择10个建立连接;
3.3、混合式:KaZaA
每个对等方,要么是组长,要么是组员;
在一个组的内部,采用集中式的管理;
在组长和组长之间,采用分布式的管理;
A查询资源,首先发送给A的组长,如果组内有该资源直接返回给A;
如果组内内有该资源,A的组长向别的组长查询,然后返回;
4、BitTorrent
4.1、一些概念
4.1.1、Torrent(洪流)
参与一个特定文件分发的所有对等方的集合;
4.1.2、Tracker服务器
跟踪洪流中参与的节点,收集下载者信息并提供给其他下载者,使下载者相互连接;
4.1.3、.torrent,种子文件
.torrent文件本质上是文本文件,包含Tracker信息和文件信息两部分,是被下载文件的“索引”。
Tracker信息:BT下载中用到的Tracker服务器的地址和针对Tracker服务器的设置;
文件信息:把提供下载的文件虚拟分成大小相等的块(如256kB),并把每个块的索引信息和Hash验证码写入种子文件(.torrent)中。
4.1.4、bit map
每个Pear都有一个bit map,拥有某个256KB,对应的位标记为1;
定期,所有pear节点泛洪bit map,交换信息之后就知道洪流中资源分布;
4.2、下载过程
4.2.1、下载概述
Alice先得到相应的.torrent文件,然后打开BT客户端软件,BT客户端首先解析.torrent文件得到Tracker地址,然后连接Tracker服务器。
Tracker服务器回应Alice的请求,提供其他下载者(包括发布者)的IP。
Alice再连接其他下载者,根据.torrent文件,两者分别对方告知已经有的块,然后交换没有的块。
校验:Alice每得到一个块,需要算出下载块的Hash验证码与.torrent文件中的对比,如果一样则不需要重新下载这个块。
4.2.2、加入洪流后,如何获取资源?
Alice一开始加入拥有的资源时0,先随机下载4个块,然后请求稀缺块;
得到稀缺块资源,Alice被请求的概率增加,向别人提供的资源越多,本身下载的速度也越快(一报还一报);
稀缺优先策略:稀缺块得以增加,否则稀缺块一旦下线会导致速度减慢或文件缺失;
4.2.3、对于被请求资源方,如何处理请求?
并不是对所有的请求,都会提供资源,上载能力是有限的,如果同时提供,速度很慢;
有限疏通策略:跟4个节点建立连接,疏通这4个,再由自己和这4个提供资源,分散资源请求;
如何选择节点?前两个周期,优先选择向自己提供服务的节点;第三个周期随机选择;
5、结构化P2P
DHT可以看成一个分布式的P2P数据库,这个数据库由许多(key,value)键值对构成。
通过维护树状或环状的结构来查找资源;
(2条消息) 详解P2P技术_训灼说的博客-CSDN博客_p2p协议详解
资料:第二个链接资料很多;
P2P通信原理与实现(C++) - 有价值炮灰 - 博客园 (cnblogs.com)
P2P技术详解(一):NAT详解——详细原理、P2P简介-网络编程/专项技术区 - 即时通讯开发者社区! (52im.net)