QQ视频与webrtc打洞对比分析

转载:http://www.mamicode.com/info-detail-1033776.html

说明:原来的文章没了。好几年看的,地址已经无法访问。

最近研究p2p发现最大的问题,就是移动版的都是  Symmetric NAT对称型NAT ,目前能打洞的概率很小,用webrtc的stun测试过。大概原理很多人没说明白,我描述一下:

A手机私有ip为1 外网ip为a
B手机私有ip为2 外网ip为b
服务器为S 私有ip (172.16.55.55 用不到) 外网ip 为s

访问过程 A-网关->S B-网关->S
ip为 A(本地 1:3333 远程 s:9999 )-网关(本地a:44344 远程 s:9999)->S B(2:3333 远程 s:9999)-网关(b:47777 远程 s:9999)->S
然后 S–>A S–>B S带上B的地址给A S带上A的地址给B

结果:A(本地 1:3333 远程 b:47777)-网关(本地 a:55555 远程 b:47777)->B(丢弃) 丢弃原因: IP
B(本地 2:3333 远程 a:44344)-网关(本地 b:66666 远程 b:44344)->A(丢弃)

下面这个方法挺好,就是变成有点难度

对称型nat打洞

image.png

注:实践才是检验的真理。看了一下 我原来是 44385 端口 ,用新ip udp 端口变成 14638 失败。不过发送的包用ttl来避免防火墙是不错的思路。不过我这个不大会使用

一、NAT

1. 含义

      NAT技术(Network Address Translation,网络地址转换)是一种把内部网络(简称为内网)私有IP地址转换为外部网络(简称为外网)公共IP地址的技术,它使得一定范围内的多台主机只利用一个公共IP地址连接到外网,可以在很大程度上缓解了公网IP地址紧缺的问题。

2. 实现方式

    静态转换、动态转换、端口多路复用。

    静态转换:是指将内部网络的私有IP地址转换为公有IP地址,IP地址对是一对一的,是一成不变的。通过静态配置,把一个固定的私网IP地址和端口关联到一个公网地址和端口,这种方式适用于在NAT网关上把一个知名服务(如HTTP)映射到一个内部主机上。

    动态转换:是指将内部网络的私有IP地址转换为公用IP地址时,IP地址对是不确定的,而是随机的,所有被授权访问Internet的私有IP地址可随机转换为任何指定的合法IP地址。也就是说,只要指定哪些内部地址可以进行转换,以及用哪些合法地址作为外部地址时,就可以进行动态转换。

    端口多路复用:是指改变外出数据包的源端口并进行端口转换,即端口地址转换(Port Address Translation,PAT)。采用端口多路复用方式,内部网络的所有主机均可共享一个合法外部IP地址实现对Internet的访问,从而最大限度地节约IP地址资源。同时,又可隐藏网络内部的所有主机,避免来自Internet的攻击。因此,目前网络中应用最多的就是端口多路复用方式。

3. 分类

     Full Cone NAT全锥形NAT、Restricted Cone NAT限制锥形NAT、Port Restricted Cone NAT端口限制锥形NAT、Symmetric NAT对称型NAT。

      Full Cone NAT全锥形NAT:内网主机建立一个socket(LocalIP:LocalPort) 第一次使用这个socket给外部主机发送数据时NAT会给其分配一个公网(PublicIP:PublicPort),以后用这个socket向外面任何主机发送数据都将使用这对(PublicIP:PublicPort)。此外,任何外部主机只要知道这个(PublicIP:PublicPort)就可以发送数据给(PublicIP:PublicPort),内网的主机就能收到这个数据包。

      Restricted Cone NAT限制锥形NAT:内网主机建立一个socket(LocalIP:LocalPort) 第一次使用这个socket给外部主机发送数据时NAT会给其分配一个公网(PublicIP:PublicPort),以后用这个socket向外面任何主机发送数据都将使用这对(PublicIP:PublicPort)。此外,如果任何外部主机想要发送数据给这个内网主机,只要知道这个(PublicIP:PublicPort)并且内网主机之前用这个socket曾向这个外部主机IP发送过数据。只要满足这两个条件,这个外部主机就可以用自己的(IP,任何端口)发送数据给(PublicIP:PublicPort),内网的主机就能收到这个数据包。

      Port Restricted Cone NAT端口限制锥形NAT:内网主机建立一个socket(LocalIP:LocalPort) 第一次使用这个socket给外部主机发送数据时NAT会给其分配一个公网(PublicIP:PublicPort),以后用这个socket向外面任何主机发送数据都将使用这对(PublicIP:PublicPort)。此外,如果任何外部主机想要发送数据给这个内网主机,只要知道这个(PublicIP:PublicPort)并且内网主机之前用这个socket曾向这个外部主机(IP,Port)发送过数据。只要满足这两个条件,这个外部主机就可以用自己的(IP,Port)发送数据给(PublicIP:PublicPort),内网的主机就能收到这个数据包。

      Symmetric NAT对称型NAT:内网主机建立一个socket(LocalIP,LocalPort),当用这个socket第一次发数据给外部主机1时,NAT为其映射一个(PublicIP-1,Port-1),以后内网主机发送给外部主机1的所有数据都是用这个(PublicIP-1,Port-1),如果内网主机同时用这个socket给外部主机2发送数据,NAT会为其分配一个(PublicIP-2,Port-2), 以后内网主机发送给外部主机2的所有数据都是用这个(PublicIP-2,Port-2).如果NAT有多于一个公网IP,则PublicIP-1和PublicIP-2可能不同,如果NAT只有一个公网IP,则Port-1和Port-2肯定不同,也就是说一定不能是PublicIP-1等于 PublicIP-2且Port-1等于Port-2。此外,如果任何外部主机想要发送数据给这个内网主机,那么它首先应该收到内网主机发给他的数据,然后才能往回发送,否则即使他知道内网主机的一个(PublicIP,Port)也不能发送数据给内网主机。

1. 类型检测

      前提条件:一个提供两个公网地址(通信地址分别设为:Endpoint1与Endpoint2)的服务器S进行UDP端口数据监听并根据客户的要求给出响应;待检测的用户可以正常进行UDP通信。

步骤1.检测主机是否位于NAT后

      为了检测IP地址是不是公网地址,主机A首先发送任意一个UDP数据包给服务器S(Endpoint1),S收到包之后,用Endpoint1将接收到数据包头的IP地址和端口打成一个UDP反馈包发送给用户A。A在收到反馈包之后,比较自身的Endpoint和反馈包中的Endpoint,如果一样则说明A不位于任何NAT之后,否则,就是位于NAT之后,这里并不能判断NAT的具体属于哪一种类型。

步骤2.检测NAT是否是全锥型

      为了检测所处的NAT是否是全锥型的,主机A向服务器S(Endpoint1)发送UDP数据包后,服务器用Endpoint2将接收到数据包头的IP地址和端口打成一个UDP反馈包发送给用户A。另外,A在发送UDP数据包后,立即开始端口侦听,设定一个等待时间上限,防止无限堵塞(因为接收是一个While循环)。这样进行若干次,如果A每次都没有收到数据包,说明A所处的NAT类型不是全锥型的;相反,在这整个过程中只要收到一次服务的包,就说明A所处的NAT类型是全锥型的。

步骤3. 检测NAT是否是对称型

      为了检测所处的NAT是否是对称型的,主机A向服务器S(Endpoint1)发送UDP数据包,服务器S(Endpoint1)在收到数据包后,用Endpoint1将接收到数据包头的IP地址和端口打成一个UDP反馈包发送给用户A。另外,A在发送数据包后,开始侦听端口并接收数据,设定一个等待时间上限,防止无限堵塞(因为接收是一个While循环)。与此同时,主机A用同一个套接字向服务器S (Endpoint2)发送UDP数据,Endpoint2发送与上面类似的UDP回馈包。在A的整个数据接收过程中,如果收到的服务器反馈数据包中标识自身的IP地址和端口存在不相同的情况,就说明NAT是对称型的,否则就不是。

步骤4. 检测NAT是限制锥型的还是端口限制锥型

     最后,为了检测所处的NAT是限制锥型的还是端口限制锥型的,主机A向服务S的Endpoint1发送UDP数据包,服务器用与Endpoint1相同的IP地址和不同的端号将带有A的Public Endpoint的UDP反馈包发送给A。另外,A在发送数据包后,立即侦听端口和并进行数据接收,设定一个等待时间上限,防止无限堵塞(因为接收是一个While循环)。重复若干次。如过在整个过程中,用户A收到S发来的数据包,就说明NAT是限制型的;否则就说明NAT是端口限制型的。

二、打洞

      NAT技术虽然在一定程度上解决了IPv4地址短缺的问题,在构建防火墙、保证网络安全方面都发挥了一定的作用,却破坏了端到端的网络通信。NAT阻碍主机进行P2P通信的主要原因是NAT不允许外网主机主动访问内网主机,因为NAT设备上没有相关转发表项,要在NAT网络环境中进行有效的P2P通信,就必须寻找相应的解决方案——NAT穿越打洞。

      下面分各种NAT场景(如图2)来说明UDP打洞的过程。

     假设现在有A和B通信双方,同时为了便于描述打洞过程,假定图2中的NAT类型均为Full Cone NAT:

   (a)A和B都处于公网下,无需打洞,A和B可直接P2P直连。

   (b)A处于公网,B在内网。若A去连B,由于B没有向A发送过数据,A的数据包会被B的NAT1丢弃,所以即使A知道了B通过NAT1转换后的地址和端口,也是无法连接成功的。但是由于A在公网下,所以反过来B可以连接A,P2P通信成功。
   (c)A和B都处于内网,分属不同的内网,它们彼此的内网地址在外网中是没有路由的,所以发往各自内网地址的UDP数据包会发送到错误的主机或者根本不存在的主机上。由于双方都不知道对方的公网IP和端口,就会无从下手,所以要在A和B之间架设一台服务器S来为它们牵线,而且S是处在公网,以保证A和B都能连接到S。A和B登录时都首先连接S,S就会知道A和B经过NAT后的IP和端口,当A想要连接B时,就向S发出请求,S会把B经过NAT后的IP和端口告诉A,同时S向B发送A经过NAT后的IP和端口,并要求B发送数据给A,B发送数据到达A时会被A的NAT抛弃,但是B的NAT会有B发送数据到A的记录,这时A再向B发送数据时就会被B的NAT放行,因为B曾经向A的外网IP和端口发送过数据。A向B的外网地址发送消息的过程就是“打洞”的过程,一旦A与B都向对方的外网地址发送了数据包,就打开了A与B之间的“洞”,一旦应用程序确认已经可以通过往对方的外网地址发送数据包的方式让数据包到达NAT后面的目的应用程序,程序会自动停止继续发送用于“打洞”的数据包,转而开始真正的P2P数据传输。这个过程可借助于网上的一个形象比喻来理解(见图3)。

   (d)NAT1和NAT2是由ISP(Internet Service Provider)提供的NAT设备,提供将多个用户节点映射到有限的几个公网IP的服务。NAT3作为NAT1的内网节点将把用户的家庭网络或内部网络接入NAT1的内网,然后用户的内部网络就可以经由NAT1访问公网了(NAT4同理)。从这种拓扑结构上来看,只有服务器S与NAT1、NAT2是真正拥有公网可路由IP地址的设备,而NAT3和NAT 4所使用的公网IP地址,实际上是由ISP服务提供商设定的(相对于NAT1和NAT2而言)内网地址(这个由ISP提供的内网地址相对于NAT1和NAT2被称之为“伪”公网地址)。现在假定A和B希望通过UDP“打洞”完成P2P直连。最优化的路由策略是A向B的“伪公网”IP上发送数据包。由于从服务器S的角度只能观察到真正的公网地址,也就是NAT3、NAT4分别通过NAT1、NAT2转换的外网地址,非常不幸的是A与B是无法通过服务器S知道这些“伪”公网的地址,而且即使客户端A和B通过某种手段可以得到NAT3和NAT4的“伪”公网地址,我们仍然不建议采用上述的“最优化”的打洞方式,这是因为这些地址是由ISP服务提供商提供的,或许会存在与客户端本身所在的内网地址重复的可能性,这样就会导致打洞数据包无法发出的问题。因此客户端别无选择,只能使用由服务器S观察到的A,B的公网地址进行“打洞”操作,打洞过程与(c)类似。

   (e)A和B位于同一个NAT设备后面,并且处于同一局域网中,发出的数据包不需要路由,可进行速度较快的常规P2P通信。另外,A和B发往对方公网地址的UDP数据包不一定会被对方收到,这取决于当前的NAT设备是否支持不同端口之间的UDP数据包传输(即Hairpin转换),就算支持,应用程序也应该优先选择上述常规的P2P直连,否则势必会造成数据包无谓地经过NAT设备,这是一种对资源的浪费。

  (f)由于A和B不在一个内网中,所以相对于(e)而言,就不能不经过NAT让A和B直接相连,这样情况下就需要NAT1支持Hairpin转换,虽然目前也有很多NAT设备不支持类似这样的“Hairpin转换”,但是已经有越来越多的NAT设备商开始加入对该转换的支持中来。同理(g)(h)。

二、webrtc打洞框架

      Peer与STUN服务器交互采用的是STUN协议,STUN服务器返回Peer的公网地址,地址形式为[IP:port]。

      L和R都获取到了自己的局域网地址和公网地址后通过信令服务发送给对方,然后彼此都有了对方的地址。

      RFC5245定义这些地址为candidate,按照局域网 > 外网 > TURN地址的优先级顺序为candidates排序后进行打洞测试。

      打洞过程就是双方不停地往彼此的端口发包,既能收到对方发的包,也能收到自己发出去的回包,就说明打洞成功。失败的话,就通过TURN服务器进行转发。

注:以上部分描述和图挑选自网上资料与论文。

二、测试

1. 测试目的

      对比分析QQ和webrtc的打洞情况。

2. 实验环境

      测试之初,我以为NAT在路由器中,试图通过对路由器的布置,可以设计出图2的各种场景,也以为NAT的四种类型可以在路由器中进行设置,这样就能全面地进行测试了。然而结果是,路由器上的NAT设置指的是静态转换、动态转换、端口多路复用的实现方式,查遍各种资料和咨询相关人员也没找到到底在哪里可以设置网络的Full Cone NAT、Restricted Cone NAT、Port Restricted Cone NAT、Symmetric NAT四种类型,最后得出一个结论:NAT功能通常被集成到路由器、防火墙、ISDN路由器或者单独的NAT设备中,或者由运营商决定吧,大概是我们触碰不到修改不了的吧,不确定。

      若欲将所有场景(图2)都测试完,同时又考虑到中国的多运营商情况,暂且只考虑铁通、移动、电信、联通四种,并且每种网络有Full con等四种类型,那么理论上的测试数量则为:组合数C(4*4,2)=120,再乘以8中场景(图2),最后为960种情况。然要齐全所有情况是相当困难的,实际实验室能提供的网络环境为:

    PC4-5:Full cone 铁通

    PC4-6:symmetric 联通

    PC4-7:Port Restricted Cone 电信

    L-014-wifi:Full cone  电信

    这些网分别只经过一个路由器接入,处于不同的内网。

    类型检测工具采用的是从网上下载的STUN_Client_app.exe:

1. 实验方法

      本地内网IP通过利用http://www.ip138.com/检测当前网络的外网IP,采用抓包和相关日志分析方法来判断QQ视频和webrtc的打洞成败(即是否能建立P2P直连)情况。

      webrtc:源码中的STUN服务器Google公司的stun.l.google.com,为了便于在无VPN无FQ的情况下使用,需要将其改成能访问的地址,如荷兰的stun.voipbuster.com。webrtc的peerconnection_server和peerconnection_client工程编译后的peerconnection_server.exe和peerconnection_client.exe在源码\src\talk目录下。将peerconnection_server.exe放到公网下,两个客户端分别输入该公网地址连接上服务器后,其界面上会出现对方的PC名字,双击一方的名字,连接开始,若出现对方的画面表示P2P直连成功,否则失败,没有中转的情况。

     QQ:直接打开两个QQ进行视频通信(P2P失败时会使用中转服务器进行转发)。

2. 实验结果

    理论上各网络类型之间的P2P直连情况如下表:

     QQ和webrtc的打洞测试结果:

1. 结果分析

      除了PC4-5,其余的结果与预期相符。

     其中,PC4-5的铁通网络,明明测出来是Full cone类型,却偏偏出现了与之特性不符的结果,究其原因是该铁通网具有多出口IP,以下面的简化模拟图来说明。

      现有两客户端A和B,通过http://www.ip138.com/检测A和B通过NAT后的外网地址分别为PublicIPA和PublicIPB。真正通信后,在A端抓包看到的对方地址为PublicIPB,则认为是直连,然而在B端抓包显示的对方地址却是一个陌生IP——PublicIPA2,看起来就像是A通过中转服务器似的,故而出现了一端直连一端中转的假象,之所以称之为假象,是因为在A端的抓包中并没有出现与PublicIPA2这个陌生IP进行通信的数据包。

     由于B是电信网,故而在B建立连接时,A从多IP中选择了电信的出口IP(不是说铁通就一定会选择与对方相同的运营商出口,只是说此时正好如此)。这种多ip出口就容易导致本来能够P2P的两端直连却失败。

    不清楚www.ip138.com获取的是不是真实运营商类型。webrtc的STUN服务器获得的客户端的NAT外网地址,我个人觉得是其所处的真实的运营商类型。因为STUN不在国内,故而不存在多运营商问题。在PC4-5 Full cone铁通和PC4-6 Symmetric联通下ping服务器STUN的地址stun.voipbuster.com过程如下:

(某市)铁通——>(省会)铁通——>(省)铁通——>中国铁通——>欧洲联盟——>荷兰

(某市)联通——>(省会)联通——>北京联通——>加拿大——>欧洲联盟——>德国——>欧洲联盟——>荷兰

未经允许不得转载:智慧,启迪人生 » QQ视频与webrtc打洞对比分析

打赏

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏