很多人知道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后的外網地址分別為PublicIPA和PublicIPB。
真正通信后，在A端抓包看到的對方地址為PublicIPB，則認為是直連，然而在B端抓包顯示的對方地址卻是一個陌生IP——PublicIPA2，
看起來就像是A通過中轉服務器似的，故而出現了一端直連一端中轉的假象，之所以稱之為假象，是因為在A端的抓包中並沒有出現與PublicIPA2這個陌生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過程如下：
(某市)鐵通——>(省會)鐵通——>(省)鐵通——>中國鐵通——>歐洲聯盟——>荷蘭
(某市)聯通——>(省會)聯通——>北京聯通——>加拿大——>歐洲聯盟——>德國——>歐洲聯盟——>荷蘭
更多待補充！