很多人知道webrtc打洞能力很强，到底有多强但是不知道，比较好的方法就是跟QQ对比，但大多数公司很难模拟各种网络环境进行测试，比如联通，铁通，电信，移动，所以这次请小师妹在实验室下进行了一个比较全面的测试，并整理出测试结果供大家参考，支持原创，文章来自博客园RTC.Blacker（作者:竹叶青），转载必须说明出处，更多详见www.rtc.help。

介绍测试结果前我们先来看看webrtc的p2p架构：

原理介绍：

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

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

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

4，打洞过程就是双方不停地往彼此的端口发包，既能收到对方发的包，也能收到自己发出去的回包，说明打洞成功。否则失败，通过TURN转发。

测试说明：

测试之初，我以为NAT在路由器中，试图通过对路由器的设置，配置NAT的各种类型，这样就能全面地进行测试了。

然而结果是，路由器上的NAT设置指的是静态转换、动态转换、端口多路复用的实现方式，查遍各种资料和咨询相关人员也没找到到底在哪里可以设置网络的Full Cone NAT、Restricted Cone NAT、Port Restricted Cone NAT、Symmetric NAT四种类型？

最后得出结论：NAT功能通常被集成到路由器、防火墙、ISDN路由器或者单独的NAT设备中，或者由运营商决定吧，大概是我们触碰不到修改不了的吧！

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

1，PC4-5：Full cone 铁通

2，PC4-6：symmetric 联通

3，PC4-7：Port Restricted Cone 电信

4，L-014-wifi：Full cone  电信

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

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

测试方法：

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

2，webrtc：利用peerconnection_server和peerconnection_client测试，不过stun服务器地址修改成了stun.voipbuster.com。

3，QQ：直接打开两个QQ进行视频通信（P2P失败时会使用中转服务器进行转发）。

测试结果：

结果分析：

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

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

上图说明：现有两客户端A和B，通过NAT后的外网地址分别为PublicIP_A和PublicIP_B。

真正通信后，在A端抓包看到的对方地址为PublicIP_B，则认为是直连，然而在B端抓包显示的对方地址却是一个陌生IP——PublicIP_A2，

看起来就像是A通过中转服务器似的，故而出现了一端直连一端中转的假象，之所以称之为假象，是因为在A端的抓包中并没有出现与PublicIP_A2这个陌生IP进行通信的数据包。

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

2，不清楚www.ip138.com获取的是不是真实运营商类型。webrtc的STUN服务器获得的客户端的NAT外网地址，我个人觉得是其所处的真实的运营商类型。因为STUN不在国内，故而不存在多运营商问题。

在PC4-5 Full cone铁通和PC4-6 Symmetric联通下ping服务器STUN的地址stun.voipbuster.com过程如下：

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

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

更多待补充！