P2P的原理和常见的实现方式(为libjingle开路)

参考原文

为了项目的IM应用，最近在研究libjingle，中间看了也收集了不少资料，感慨网上不少资料要么太过于纠结协议（如 STUN、ICE等）实现细节，要么中间有不少纰漏。最后去伪存真，概括总结了一下，但愿对之后的同行有些许帮助。
                    

P2P实现的原理

基本概念：

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

   最早提出的是基本的NAT(刚开始其实只是路由器上的一个功能模块)，它的产生基于以下事实：一个私有网络（域）中的节点中只有不多的节点须要与外网链接（这是在上世纪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，

后一 种叫作C one NAT。若是你 的NAT恰好是第一种，那么极可能会有不少P2P软件失灵。（能够庆幸的是，如今绝大多数的NAT属于后者，即Cone NAT）

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的经常使用实现

 

1、普通的直连式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）。

 

2、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。

NAT的探测过程

STEP1：

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

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

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

 

STEP2：

    B向C的 IPC1发送一个UDP包，请求C经过另一个 IPC2和 port_2（不一样与SETP1的 IPC1）向B返回一个UDP数据包（如今知道为何C要有两个IP了吧，为了检测cone NAT的类型）。

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

 

STEP3：

    B向C的 IPC2的 port_2发送一个数据包，C收到数据包后，把它收到包的源IP和port写到UDP包中，而后经过本身的 IPC2和 port_2把此包发还给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的沟通是没有可能性的(准备来讲除了包被防火墙blocked以外，其余状况也是有可能创建P2P的，只是代价太大，通常放弃)。一旦经过黄色或是绿色的节点，就有链接的可能。

最终经过STUN服务器获得本身的NAT类型和公网IP、Port，之后创建P2P时就很是容易了

Libjingle正是经过ICE&STUN方式，创建的P2P链接。关于libjingle的介绍，待续……

参考资料：

一、维基百科之STUN 二、http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt（shootingstars）