P2P原理（转）

P2P（Peer to Peer）对等网络

P2P技术属于覆盖层网络(Overlay Network)的范畴，是相对于客户机/服务器(C/S)模式来说的一种网络信息交换方式。在C/S模式中，数据的分发采用专门的服务器，多个客户端都从此服务器获取数据。

优点是：数据的一致性容易控制，系统也容易管理。

缺点是：因为服务器的个数只有一个(即便有多个也非常有限)，系统容易出现单一失效点；单一服务器面对众多的客户端，由于CPU能力、内存大小、网络带宽的限制，可同时服务的客户端非常有限，可扩展性差。

P2P技术正是为了解决这些问题而提出来的一种对等网络结构。在P2P网络中，每个节点既可以从其他节点得到服务，也可以向其他节点提供服务。这样，庞大的终端资源被利用起来，一举解决了C/S模式中的两个弊端。

P2P应用软件主要包括文件分发软件、语音服务软件、流媒体软件。目前P2P应用种类多、形式多样，没有统一的网络协议标准，其体系结构和组织形式也在不断发展。

对等网络的基本结构

（1）集中式对等网络（Napster、QQ）

集中式对等网络基于中央目录服务器，为网络中各节目提供目录查询服务，传输内容无需再经过中央服务器。这种网络，结构比较简单，中央服务器的负担大大降低。但由于仍存在中央节点，容易形成传输瓶颈，扩展性也比较差，不适合大型网络。但由于目录集中管理，对于小型网络的管理和控制上倒是一种可选择方案。

（2）无结构分布式网络（Gnutella）

无结构分布式网络与集中式的最显著区别在于，它没有中央服务器，所有结点通过与相邻节点间的通信，接入整个网络。在无结构的网络中，节点采用一种查询包的机制来搜索需要的资源。具体的方式为，某节点将包含查询内容的查询包发送到与之相邻的节点，该查询包以扩散的方式在网络中蔓延，由于这样的方式如果不加节制，会造成消息泛滥，因此一般会设置一个适当的生存时间（TTL），在查询的过程中递减，当TTL值为0时，将不再继续发送。

这种无结构的方式，组织方式比较松散，节点的加入与离开比较自由，当查询热门内容时，很容易就能找到，但如果需求的内容比较冷门，较小的TTL不容易找到，而较大的TTL值又容易引起较大的查询流量，尤其当网络范围扩展到一定规模时，即使限制的TTL值较小，仍然会引起流量的剧增。但当网络中存在一些拥有丰富资源的所谓的类服务器节点时，可显著提高查询的效率。

（3）结构化分布式网络（第三代P2P Pastry、Tapestry、Chord、CAN）

结构化分布式网络，是近几年基于分布式哈希表（Distributed Hash Table）技术的研究成果。它的基本思想是将网络中所有的资源整理成一张巨大的表，表内包含资源的关键字和所存放结点的地址，然后将这张表分割后分别存储到网络中的每一结点中去。当用户在网络中搜索相应的资源时，它将能发现存储与关键词对应的哈希表内容所存放的结点，在该结点中存储了包含所需资源的结点地址，然后发起搜索的结点根据这些地址信息，与对应结点连接并传输资源。这是一种技术上比较先进的对等网络，它具有高度结构化，高可扩展性，结点的加入与离开比较自由。这种方式适合比较大型的网络。

 

对等网络经典结构

  (1)DHT结构

分布式哈希表(DHT)[1]是一种功能强大的工具，它的提出引起了学术界一股研究DHT的热潮。虽然DHT具有各种各样的实现方式，但是具有共同的特征，即都是一个环行拓扑结构，在这个结构里每个节点具有一个唯一的节点标识(ID)，节点ID是一个128位的哈希值。每个节点都在路由表里保存了其他前驱、后继节点的ID。如图1(a)所示。通过这些路由信息，可以方便地找到其他节点。这种结构多用于文件共享和作为底层结构用于流媒体传输[2]。

    (2)树形结构

    P2P网络树形结构如图1(b)所示。在这种结构中，所有的节点都被组织在一棵树中，树根只有子节点，树叶只有父节点，其他节点既有子节点也有父节点。信息的流向沿着树枝流动。最初的树形结构多用于P2P流媒体直播[3-4]。

    (3)网状结构

网状结构如图1(c)所示，又叫无结构。顾名思义，这种结构中，所有的节点无规则地连在一起，没有稳定的关系，没有父子关系。网状结构[5]为P2P提供了最大的容忍性、动态适应性，在流媒体直播和点播应用中取得了极大的成功。当网络变得很大时，常常会引入超级节点的概念，超级节点可以和任何一种以上结构结合起来组成新的结构，如KaZaA[6]。

 

P2P技术应用

(1)分布式科学计算
P2P技术可以使得众多终端的CPU资源联合起来，服务于一个共同的计算。这种计算一般是计算量巨大、数据极多、耗时很长的科学计算。在每次计算过程中，任务(包括逻辑与数据等)被划分成多个片，被分配到参与科学计算的P2P节点机器上。在不影响原有计算机使用的前提下，人们利用分散的CPU资源完成计算任务，并将结果返回给一个或多个服务器，将众多结果进行整合，以得到最终结果。
(2)文件共享
BitTorrent是一种无结构的网络协议。除了BitTorrent之外，还有不少著名的无结构化的P2P文件共享协议，典型的有Gnutella[8]和KaZaA[6]。
(3)流媒体直播
(4)流媒体点播
(5)IP层语音通信
Skype采取类似KaZaA的拓扑结构，在网络中选取一些超级节点。在通信双方直连效果不好时，一些合适的超级节点则担当起其中转节点的角色，为通信双方创建中转连接，并转发相应的语音通信包。

典型P2P应用的机制分析
      分析典型的P2P应用机制可以深入了解P2P的原理。本节将对文件分发、流媒体应用、语音服务3个领域中具有代表性的软件机制进行详细的分析。对于这些软件的分析有助于理解P2P技术的原理和把握P2P技术未来发展的趋势。

BitTorrent
      BitTorrent软件用户首先从Web服务器上获得下载文件的种子文件，种子文件中包含下载文件名及数据部分的哈希值，还包含一个或者多个的索引(Tracker)服务器地址。它的工作过程如下：客户端向索引服务器发一个超文本传输协议(HTTP)的GET请求，并把它自己的私有信息和下载文件的哈希值放在GET的参数中；索引服务器根据请求的哈希值查找内部的数据字典，随机地返回正在下载该文件的一组节点，客户端连接这些节点，下载需要的文件片段。因此可以将索引服务器的文件下载过程简单地分成两个部分：与索引服务器通信的HTTP，与其他客户端通信并传输数据的协议，我们称为BitTorrent对等协议。BitTorrent软件的工作原理如图4所示。BitTorrent协议也处在不断变化中，可以通过数据报协议(UDP)和DHT的方法获得可用的传输节点信息，而不是仅仅通过原有的HTTP，这种方法使得BitTorrent应用更加灵活，提高BitTorrent用户的下载体验。

eMule
      eMule软件基于eDonkey协议改进后的协议，同时兼容eDonkey协议。每个eMule客户端都预先设置好了一个服务器列表和一个本地共享文件列表，客户端通过TCP连接到eMule服务器进行登录，得到想要的文件的信息以及可用的客户端的信息。一个客户端可以从多个其他的EMule客户端下载同一个文件，并从不同的客户端取得不同的数据片段。eMule同时扩展了eDonkey的能力，允许客户端之间互相交换关于服务器、其他客户端和文件的信息。eMule服务器不保存任何文件，它只是文件位置信息的中心索引。eMule客户端一启动就会自动使用传输控制协议(TCP)连接到eMule服务器上。服务器给客户端提供一个客户端标识(ID)，它仅在客户端服务器连接的生命周期内有效。连接建立后，客户端把其共享的文件列表发送给服务器。服务器将这个列表保存在内部数据库内。eMule客户端也会发送请求下载列表。连接建立以后，eMule服务器给客户端返回一个列表，包括哪些客户端可以提供请求文件的下载。然后，客户端再和它们主动建立连接下载文件。图5所示为eMule的工作原理。

eMule基本原理与BitTorrent类似，客户端通过索引服务器获得文件下载信息。eMule同时允许客户端之间传递服务器信息，BitTorrent只能通过索引服务器或者DHT获得。eMule共享的是整个文件目录，而BitTorrent只共享下载任务，这使得BitTorrent更适合分发热门文件，eMule倾向于一般热门文件的下载。

迅雷
      迅雷是一款新型的基于多资源多线程技术的下载软件，迅雷拥有比目前用户常用的下载软件快7～10倍的下载速度。迅雷的技术主要分成两个部分，一部分是对现有Internet下载资源的搜索和整合，将现有Internet上的下载资源进行校验，将相同校验值的统一资源定位(URL)信息进行聚合。当用户点击某个下载连接时，迅雷服务器按照一定的策略返回该URL信息所在聚合的子集，并将该用户的信息返回给迅雷服务器。另一部分是迅雷客户端通过多资源多线程下载所需要的文件，提高下载速率。迅雷高速稳定下载的根本原因在于同时整合多个稳定服务器的资源实现多资源多线程的数据传输。多资源多线程技术使得迅雷在不降低用户体验的前提下，对服务器资源进行均衡，有效降低了服务器负载。

每个用户在网上下载的文件都会在迅雷的服务器中进行数据记录，如有其他用户再下载同样的文件，迅雷的服务器会在它的数据库中搜索曾经下载过这些文件的用户，服务器再连接这些用户，通过用户已下载文件中的记录进行判断，如用户下载文件中仍存在此文件(文件如改名或改变保存位置则无效)，用户将在不知不觉中扮演下载中间服务角色，上传文件。

PPLive
      PPLive软件的工作机制和BitTorrent十分类似，PPLive将视频文件分成大小相等的片段，第三方提供播放的视频源，用户启矾PPLive以后，从PPLive服务器获得频道的列表，用户点击感兴趣的频道，然后从其他节点获得数据文件，使用流媒体实时传输协议(RTP)和实时传输控制协议(RTCP)进行数据的传输和控制。将数据下载到本地主机后，开放本地端口作为视频服务器，PPLive的客户端播放器连接此端口，任何同一个局域网内的用户都可以通过连接这个地址收看到点播的节目。图6所示为PPLive的工作原理示意图。

Skype
      Skype是网络语音沟通工具。它可以提供免费高清晰的语音对话，也可以用来拨打国内国际长途，还具备即时通讯所需的其他功能，比如文件传输、文字聊天等。Skype是在KaZaA的基础上开发的，就像KaZaA一样，Skype本身也是基于覆盖层的P2P网络，在它里面有两种类型的节点：普通节点和超级节点。普通节点是能传输语音和消息的一个功能实体；超级节点则类似于普通节点的网络网关，所有的普通节点必须与超级节点连接，并向Skype的登陆服务器注册它自己来加入Skype网络。Skype的登陆服务器上存有用户名和密码，并且授权特定的用户加入Skype网络，图7所示为Skype的体系结构^[18]。

Skype的另一个突出特点就是能够穿越地址转换设备和防火墙。Skype能够在最小传输带宽32 kb/s的网络上提供高质量的语音。Skype是使用P2P语音服务的代表。由于其具有超清晰语音质量、极强的穿透防火墙能力、免费多方通话以及高保密性等优点，成为互联网上使用最多的P2P应用之一。

P2P实现的原理

 

首先先介绍一些基本概念：

   NAT(Network Address Translators)，网络地址转换：网络地址转换是在IP地址日益缺乏的情况下产生的，它的主要目的就是为了能够地址重用。NAT从历史发展上分为两大类，基本的NAT和NAPT(Network Address/Port Translator)。

   最先提出的是基本的NAT(peakflys注：刚开始其实只是路由器上的一个功能模块)，它的产生基于如下事实：一个私有网络（域）中的节点中只有很少的节点需要与外网连接（这是在上世纪90年代中期提出的）。那么这个子网中其实只有少数的节点需要全球唯一的IP地址，其他的节点的IP地址应该是可以重用的。

因此，基本的NAT实现的功能很简单，在子网内使用一个保留的IP子网段，这些IP对外是不可见的。子网内只有少数一些IP地址可以对应到真正全球唯一的IP地址。如果这些节点需要访问外部网络，那么基本NAT就负责将这个节点的子网内IP转化为一个全球唯一的IP然后发送出去。(基本的NAT会改变IP包中的原IP地址，但是不会改变IP包中的端口)

关于基本的NAT可以参看RFC 1631

另外一种NAT叫做NAPT，从名称上我们也可以看得出，NAPT不但会改变经过这个NAT设备的IP数据报的IP地址，还会改变IP数据报的TCP/UDP端口。基本NAT的设备可能我们见的不多（基本已经淘汰了），NAPT才是我们真正需要关注的。看下图：

有一个私有网络10.*.*.*，Client A是其中的一台计算机，这个网络的网关（一个NAT设备）的外网IP是155.99.25.11(应该还有一个内网的IP地址，比如10.0.0.10)。如果Client A中的某个进程（这个进程创建了一个UDP Socket,这个Socket绑定1234端口）想访问外网主机18.181.0.31的1235端口，那么当数据包通过NAT时会发生什么事情呢？

首先NAT会改变这个数据包的原IP地址，改为155.99.25.11。接着NAT会为这个传输创建一个Session（Session是一个抽象的概念，如果是TCP，也许Session是由一个SYN包开始，以一个FIN包结束。而UDP呢，以这个IP的这个端口的第一个UDP开始，结束呢，呵呵，也许是几分钟，也许是几小时，这要看具体的实现了）并且给这个Session分配一个端口，比如62000，然后改变这个数据包的源端口为62000。所以本来是

（10.0.0.1:1234->18.181.0.31:1235）的数据包到了互联网上变为了（155.99.25.11:62000->18.181.0.31:1235）。

一旦NAT创建了一个Session后，NAT会记住62000端口对应的是10.0.0.1的1234端口，以后从18.181.0.31发送到62000端口的数据会被NAT自动的转发到10.0.0.1上。（注意：这里是说18.181.0.31发送到62000端口的数据会被转发，其他的IP发送到这个端口的数据将被NAT抛弃）这样Client A就与Server S1建立以了一个连接。

上面的是一些基础知识，下面的才是关键的部分了。

看看下面的情况：

接上面的例子，如果Client A的原来那个Socket(绑定了1234端口的那个UDP Socket)又接着向另外一个Server S2发送了一个UDP包，那么这个UDP包在通过NAT时会怎么样呢？

这时可能会有两种情况发生，一种是NAT再次创建一个Session，并且再次为这个Session分配一个端口号（比如：62001）。另外一种是NAT再次创建一个Session，但是不会新分配一个端口号，而是用原来分配的端口号62000。前一种NAT叫做Symmetric NAT，后一种叫做Cone NAT。如果你的NAT刚好是第一种，那么很可能会有很多P2P软件失灵。（可以庆幸的是，现在绝大多数的NAT属于后者，即Cone NAT）

peakflys注：Cone NAT具体又分为3种：

(1)全圆锥( Full Cone) : NAT把所有来自相同内部IP地址和端口的请求映射到相同的外部IP地址和端口。任何一个外部主机均可通过该映射发送IP包到该内部主机。

(2)限制性圆锥(Restricted Cone) : NAT把所有来自相同内部IP地址和端口的请求映射到相同的外部IP地址和端口。但是,只有当内部主机先给IP地址为X的外部主机发送IP包,该外部主机才能向该内部主机发送IP包。

(3)端口限制性圆锥( Port Restricted Cone) :端口限制性圆锥与限制性圆锥类似,只是多了端口号的限制,即只有内部主机先向IP地址为X,端口号为P的外部主机发送1个IP包,该外部主机才能够把源端口号为P的IP包发送给该内部主机。

好了，我们看到，通过NAT,子网内的计算机向外连结是很容易的（NAT相当于透明的，子网内的和外网的计算机不用知道NAT的情况）。

但是如果外部的计算机想访问子网内的计算机就比较困难了（而这正是P2P所需要的）。

那么我们如果想从外部发送一个数据报给内网的计算机有什么办法呢？首先，我们必须在内网的NAT上打上一个“洞”（也就是前面我们说的在NAT上建立一个Session），这个洞不能由外部来打，只能由内网内的主机来打。而且这个洞是有方向的，比如从内部某台主机（比如：192.168.0.10）向外部的某个IP(比如：219.237.60.1)发送一个UDP包，那么就在这个内网的NAT设备上打了一个方向为219.237.60.1的“洞”，（这就是称为UDP Hole Punching的技术）以后219.237.60.1就可以通过这个洞与内网的192.168.0.10联系了。（但是其他的IP不能利用这个洞）。

 

 

P2P的常用实现

 

一、普通的直连式P2P实现

通过上面的理论，实现两个内网的主机通讯就差最后一步了：那就是鸡生蛋还是蛋生鸡的问题了，两边都无法主动发出连接请求，谁也不知道谁的公网地址，那我们如何来打这个洞呢？我们需要一个中间人来联系这两个内网主机。

现在我们来看看一个P2P软件的流程，以下图为例：

首先，Client A登录服务器，NAT A为这次的Session分配了一个端口60000，那么Server S收到的Client A的地址是202.187.45.3:60000，这就是Client A的外网地址了。同样，Client B登录Server S，NAT B给此次Session分配的端口是40000，那么Server S收到的B的地址是187.34.1.56:40000。

此时，Client A与Client B都可以与Server S通信了。如果Client A此时想直接发送信息给Client B，那么他可以从Server S那儿获得B的公网地址187.34.1.56:40000，是不是Client A向这个地址发送信息Client B就能收到了呢？答案是不行，因为如果这样发送信息，NAT B会将这个信息丢弃（因为这样的信息是不请自来的，为了安全，大多数NAT都会执行丢弃动作）。现在我们需要的是在NAT B上打一个方向为202.187.45.3（即Client A的外网地址）的洞，那么Client A发送到187.34.1.56:40000的信息,Client B就能收到了。这个打洞命令由谁来发呢？自然是Server S。

总结一下这个过程：如果Client A想向Client B发送信息，那么Client A发送命令给Server S，请求Server S命令Client B向Client A方向打洞。然后Client A就可以通过Client B的外网

地址与Client B通信了。

注意：以上过程只适合于Cone NAT的情况，如果是Symmetric NAT，那么当Client B向Client A打洞的端口已经重新分配了，Client B将无法知道这个端口（如果Symmetric NAT的端口是顺序分配的，那么我们或许可以猜测这个端口号，可是由于可能导致失败的因素太多，这种情况下一般放弃P2P  ---peakflys）。

 

二、STUN方式的P2P实现

STUN是RFC3489规定的一种NAT穿透方式，它采用辅助的方法探测NAT的IP和端口。毫无疑问的，它对穿越早期的NAT起了巨大的作用，并且还将继续在NAT穿透中占有一席之地。

STUN的探测过程需要有一个公网IP的STUN server，在NAT后面的UAC必须和此server配合，互相之间发送若干个UDP数据包。UDP包中包含有UAC需要了解的信息，比如NAT外网IP，PORT等等。UAC通过是否得到这个UDP包和包中的数据判断自己的NAT类型。

假设有如下UAC（B），NAT（A），SERVER（C），UAC的IP为IPB，NAT的IP为 IPA ，SERVER的 IP为IPC1 、IPC2。请注意，服务器C有两个IP，后面你会理解为什么需要两个IP。

(1)NAT的探测过程

STEP1：B向C的IPC1的port1端口发送一个UDP包。C收到这个包后，会把它收到包的源IP和port写到UDP包中，然后把此包通过IP1C和port1发还给B。这个IP和port也就是NAT的外网IP和port，也就是说你在STEP1中就得到了NAT的外网IP。

熟悉NAT工作原理的应该都知道，C返回给B的这个UDP包B一定收到。如果在你的应用中，向一个STUN服务器发送数据包后，你没有收到STUN的任何回应包，那只有两种可能：1、STUN服务器不存在，或者你弄错了port。2、你的NAT设备拒绝一切UDP包从外部向内部通过，如果排除防火墙限制规则，那么这样的NAT设备如果存在，那肯定是坏了„„

当B收到此UDP后，把此UDP中的IP和自己的IP做比较，如果是一样的，就说明自己是在公网，下步NAT将去探测防火墙类型，就不多说了(下面有图)。如果不一样，说明有NAT的存在，系统进行STEP2的操作。

STEP2：B向C的IPC1发送一个UDP包，请求C通过另外一个IPC2和PORT（不同与SETP1的IP1）向B返回一个UDP数据包（现在知道为什么C要有两个IP了吧，为了检测cone NAT的类型）。

我们来分析一下，如果B收到了这个数据包，那说明什么？说明NAT来着不拒，不对数据包进行任何过滤，这也就是STUN标准中的full cone NAT。遗憾的是，full cone nat太少了，这也意味着你能收到这个数据包的可能性不大。如果没收到，那么系统进行STEP3的操作。

STEP3：B向C的IPC2的port2发送一个数据包，C收到数据包后，把它收到包的源IP和port写到UDP包中，然后通过自己的IPC2和port2把此包发还给B。

和step1一样，B肯定能收到这个回应UDP包。此包中的port是我们最关心的数据，下面我们来分析：

如果这个port和step1中的port一样，那么可以肯定这个NAT是个CONE NAT，否则是对称NAT。道理很简单：根据对称NAT的规则，当目的地址的IP和port有任何一个改变，那么NAT都会重新分配一个port使用，而在step3中，和step1对应，我们改变了IP和port。因此，如果是对称NAT,那这两个port肯定是不同的。

如果在你的应用中，到此步的时候PORT是不同的，那就只能放弃P2P了，原因同上面实现中的一样。如果不同，那么只剩下了restrict cone 和port restrict cone。系统用step4探测是是那一种。

STEP4：B向C的IP2的一个端口PD发送一个数据请求包，要求C用IP2和不同于PD的port返回一个数据包给B。

我们来分析结果：如果B收到了，那也就意味着只要IP相同，即使port不同，NAT也允许UDP包通过。显然这是restrict cone NAT。如果没收到，没别的好说，port restrict NAT.

协议实现的算法运行图如下：

一旦路经到达红色节点时，UDP的沟通是没有可能性的(peakflys注：准备来说除了包被防火墙blocked之外，其他情况也是有可能建立P2P的，只是代价太大，一般放弃)。一旦通过黄色或是绿色的节点，就有连接的可能。

最终通过STUN服务器得到自己的NAT类型和公网IP、Port，以后建立P2P时就非常容易了。

参考文章：

P2P技术原理：http://www.360doc.com/content/14/0305/17/8285430_357987074.shtml

P2P技术现状及发展未来：http://www.zte.com.cn/cndata/magazine/zte_communications/2007/6/magazine/200712

P2P原理及其常用的实现方式：http://www.cppblog.com/peakflys/archive/2013/01/25/197562.html