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

标签: p2p 原理 常见 | 发表时间:2013-01-25 15:43 | 作者:peakflys
出处:http://www.cppblog.com
   为了项目的后期IM应用,最近在研究libjingle,中间看了也收集了很多资料,感慨网上很多资料要么太过于纠结协议(如STUN、ICE等)实现细节,要么中间有很多纰漏。最后去伪存真,归纳总结了一下,希望对以后的同行有些许帮助。
   如果有什么需要讨论或者指正的,欢迎留言或者邮件peakflys@gmail.com                            
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时就非常容易了
peakflys注:Libjingle正是通过ICE&STUN方式,建立的P2P连接。关于libjingle的介绍,待续……

参考资料:
1、维基百科之STUN
2、http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt(shootingstars)


本文链接

相关 [p2p 原理 常见] 推荐:

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

- - C++博客_首页
   为了项目的后期IM应用,最近在研究libjingle,中间看了也收集了很多资料,感慨网上很多资料要么太过于纠结协议(如STUN、ICE等)实现细节,要么中间有很多纰漏. 最后去伪存真,归纳总结了一下,希望对以后的同行有些许帮助.    如果有什么需要讨论或者指正的,欢迎留言或者邮件peakflys@gmail.com                            .

Tutk P2P的原理和常见的实现方式 - 书弋江山的博客 - CSDN博客

- -
最近在做tutk P2p相关公司的IP摄像头项目,然后看了一下实现原理,然后改一了一篇文章来记录一下,天下文章一大抄,天下代码也是一样的,下面就是TUTK 的Demo.   当今互联网到处存在着一些中间件(MIddleBoxes),如NAT和防火墙,导致两个(不在同一内网)中的客户端无法直接通信. 这些问题即便是到了IPV6时代也会存在,因为即使不需要NAT,但还有其他中间件如防火墙阻挡了链接的建立.

udp打洞穿透nat实现p2p GitHub - pannzh/P2P-Over-MiddleBoxes-Demo: A simple demo of P2P communication over middle boxes such as NAT

- -
一个P2P聊天程序,使用UDP打洞创建链接. ./p2pchat/server <服务器端口号> ./p2pchat/client <服务器IP>:<服务器端口号> >>> help. 该UDP打洞示例仅支持锥形地址转换器(Cone NAT),如果两个客户端都在同一个公网结点下,需要确保出口路由器支持.

W3C将开发P2P浏览器标准

- guangtao - cnBeta.COM
万维网联盟W3C今天透露,将制定一项直接让浏览器和浏览器之间对等通信的标准,而不需要中央服务器. 该标准可以减少认为干扰和嗅探,提高互联网络通信的可靠性,让浏览器可以实时运用P2P的特性传送内容,包括视频、音频和用于实时通信的“补充”.

P2P网站应用安全报告

- - WooYun知识库
有关e租宝公司被调查的新闻在微博、朋友圈被引爆刷屏. 许多人看中P2P理财的高收益,却忽视其中的风险. 猎豹移动安全实验室监测发现,P2P网站已成钓鱼欺诈网站的重灾区,大量P2P手机理财软件也存在安全隐患. 网民须小心选择P2P类理财产品. P2P网贷在2007开始传入国内,2015年呈现爆发态势,成交规模已进入万亿元时代.

视频监控P2P解决方案

- -
本文分析了日益增长的民用级别家庭和个人网络视频监控市场的需求特点,并给出了一种经济可行易于大规模部署的P2P解决方案. 由于篇幅有限,本文只给出了方案的思路,未对更深入的技术细节做详细的论述,有兴趣的朋友可以继续深入研究. 网络视频监控市场持续火爆升温,除了公共安全市场持续高速增长之外,民用市场中家庭和个人视频监控的需求近年也在逐渐增多.

P2P 文件分发系统 Dragonfly

- - OSCHINA 社区最新软件
Dragonfly(蜻蜓)是阿里自研的 P2P 文件分发系统,用于解决大规模文件分发场景下分发耗时、成功率低、带宽浪费等难题. 大幅提升发布部署、数据预热、大规模容器镜像分发等业务能力. 开源版的 Dragonfly 可用于 P2P 文件分发、容器镜像分发、局部限速、磁盘容量预检等. 它支持多种容器技术,对容器本身无需做任何改造,镜像分发比 natvie 方式提速可高达 57 倍,Registry 网络出流量降低99.5%以上.

OneSwarm – P2P 私密共享 | 小众软件 > 网络工具

- 本 - 小众软件
OneSwarm 是华盛顿大学的研究试验项目制作的 BT 下载客户端,旨在为朋友之间的 P2P 文件共享增加更多隐私保护和用户控制. OneSwarm 采用网页界面,可以作为普通 BitTorrent 下载客户端使用,此时与普通 BitTorrent 下载软件没有区别. 软件特色在于文件共享过程的私密安全.

T週刊:由宅男角度看 P2P 崛起的10年

- Cary - T客邦
網際網路的發達,促成了許多文化交流. P2P 的出現,讓許多當日播出的電視影集,第一時間就能傳送到世界各地. 除了讓轉播商與影集的代理商顏面無光,利益受損,更引起了一連串的法律爭議,以及無心插柳,意外得利的 ACG 產業. 不管是女僕咖啡廳,或是動漫同人誌,都間接受惠於網路傳來的動漫文化. 網際網路的歷史從1983年開始,經歷了20多年的時光,若把1999年,第一個將P2P技術用來「分享好物」的Napster當作是P2P抓檔的始祖,利用P2P技術分享檔案的歷史算起來就已經突破了11年.

P2P租车服务Getaround模式被证明可行

- kxxoling - 36氪
在今年5月份,P2P租车服务Getaround获得了TC Disrupt冠军大奖并正式上线,由于Airbnb的火热,不管他们喜不喜欢,人们现在已经把它叫做“租车领域的Airbnb”. 刚开始很多人认为没有人愿意把自己的车租给别人使用,我也这样想,但就像Airbnb一样,人们错了. 现在每位车主平均每月可以获得325美元(2000人民币左右)的收入,其中收入排前25%的车主更是平均每月可以获得910美元的收入.