標(biāo)簽：android style log com http 使用 si src la
很多人知道webrtc打洞能力很強(qiáng)，到底有多強(qiáng)但是不知道，比較好的方法就是跟QQ對(duì)比，但大多數(shù)公司很難模擬各種網(wǎng)絡(luò)環(huán)境進(jìn)行測(cè)試，比如聯(lián)通，鐵通，電信，移動(dòng)，所以這次請(qǐng)小師妹在實(shí)驗(yàn)室下進(jìn)行了一個(gè)比較全面的測(cè)試，并整理出測(cè)試結(jié)果供大家參考，支持原創(chuàng)，文章來(lái)自博客園RTC.Blacker（作者:竹葉青），轉(zhuǎn)載必須說(shuō)明出處，更多詳見www.rtc.help。
介紹測(cè)試結(jié)果前我們先來(lái)看看webrtc的p2p架構(gòu)：
原理介紹：
1，Peer與STUN服務(wù)器交互采用的是STUN協(xié)議，STUN服務(wù)器返回Peer的公網(wǎng)地址，地址形式為[IP：port]。
2，L和R都獲取到了自己的局域網(wǎng)地址和公網(wǎng)地址后通過信令服務(wù)發(fā)送給對(duì)方，然后彼此都有了對(duì)方的地址。
3，RFC5245定義這些地址為candidate，按照局域網(wǎng) > 外網(wǎng) > TURN地址的優(yōu)先級(jí)順序?yàn)閏andidates排序后進(jìn)行打洞測(cè)試。
4，打洞過程就是雙方不停地往彼此的端口發(fā)包，既能收到對(duì)方發(fā)的包，也能收到自己發(fā)出去的回包，說(shuō)明打洞成功。否則失敗，通過TURN轉(zhuǎn)發(fā)。
測(cè)試說(shuō)明：
測(cè)試之初，我以為NAT在路由器中，試圖通過對(duì)路由器的設(shè)置，配置NAT的各種類型，這樣就能全面地進(jìn)行測(cè)試了。
然而結(jié)果是，路由器上的NAT設(shè)置指的是靜態(tài)轉(zhuǎn)換、動(dòng)態(tài)轉(zhuǎn)換、端口多路復(fù)用的實(shí)現(xiàn)方式，查遍各種資料和咨詢相關(guān)人員也沒找到到底在哪里可以設(shè)置網(wǎng)絡(luò)的Full Cone NAT、Restricted Cone NAT、Port Restricted Cone NAT、Symmetric NAT四種類型？
最后得出結(jié)論：NAT功能通常被集成到路由器、防火墻、ISDN路由器或者單獨(dú)的NAT設(shè)備中，或者由運(yùn)營(yíng)商決定吧，大概是我們觸碰不到修改不了的吧！
若欲將所有NAT場(chǎng)景都測(cè)試完，同時(shí)又考慮到中國(guó)的多運(yùn)營(yíng)商情況（暫且只考慮鐵通、移動(dòng)、電信、聯(lián)通），并且每種網(wǎng)絡(luò)有Full con等四種類型，那么理論上的測(cè)試數(shù)量則為：組合數(shù)C（4*4，2）=120，再乘以8中場(chǎng)景（圖2），最后為960種情況。然要齊全所有情況是相當(dāng)困難的，實(shí)際實(shí)驗(yàn)室能提供的網(wǎng)絡(luò)環(huán)境為：
1，PC4-5：Full cone 鐵通
2，PC4-6：symmetric 聯(lián)通
3，PC4-7：Port Restricted Cone 電信
4，L-014-wifi：Full cone 電信
這些網(wǎng)分別只經(jīng)過一個(gè)路由器接入，處于不同的內(nèi)網(wǎng)。
類型檢測(cè)工具采用的是從網(wǎng)上下載的STUN_Client_app.exe，如下：
測(cè)試方法：
1，本地外網(wǎng)IP通過http://www.ip138.com/檢測(cè)，采用抓包和相關(guān)日志分析方法來(lái)判斷QQ視頻和webrtc的打洞成?。词欠衲芙2P直連）情況。
2，webrtc：利用peerconnection_server和peerconnection_client測(cè)試，不過stun服務(wù)器地址修改成了stun.voipbuster.com。
3，QQ：直接打開兩個(gè)QQ進(jìn)行視頻通信（P2P失敗時(shí)會(huì)使用中轉(zhuǎn)服務(wù)器進(jìn)行轉(zhuǎn)發(fā)）。
測(cè)試結(jié)果：
1，除了PC4-5，其余的結(jié)果與預(yù)期相符。
其中，PC4-5的鐵通網(wǎng)絡(luò)，明明測(cè)出來(lái)是Full cone類型，卻偏偏出現(xiàn)了與之不符的結(jié)果，究其原因是該鐵通網(wǎng)具有多出口IP，以下面的簡(jiǎn)化模擬圖來(lái)說(shuō)明。
上圖說(shuō)明：現(xiàn)有兩客戶端A和B，通過NAT后的外網(wǎng)地址分別為PublicIPA和PublicIPB。
真正通信后，在A端抓包看到的對(duì)方地址為PublicIPB，則認(rèn)為是直連，然而在B端抓包顯示的對(duì)方地址卻是一個(gè)陌生IP——PublicIPA2，
看起來(lái)就像是A通過中轉(zhuǎn)服務(wù)器似的，故而出現(xiàn)了一端直連一端中轉(zhuǎn)的假象，之所以稱之為假象，是因?yàn)樵贏端的抓包中并沒有出現(xiàn)與PublicIPA2這個(gè)陌生IP進(jìn)行通信的數(shù)據(jù)包。
由于B是電信網(wǎng)，故而在B建立連接時(shí)，A從多IP中選擇了電信的出口IP（不是說(shuō)鐵通就一定會(huì)選擇與對(duì)方相同的運(yùn)營(yíng)商出口，只是說(shuō)此時(shí)正好如此）。這種多ip出口就容易導(dǎo)致本來(lái)能夠P2P的兩端直連卻失敗。
2，不清楚www.ip138.com獲取的是不是真實(shí)運(yùn)營(yíng)商類型。webrtc的STUN服務(wù)器獲得的客戶端的NAT外網(wǎng)地址，我個(gè)人覺得是其所處的真實(shí)的運(yùn)營(yíng)商類型。因?yàn)镾TUN不在國(guó)內(nèi)，故而不存在多運(yùn)營(yíng)商問題。
在PC4-5 Full cone鐵通和PC4-6 Symmetric聯(lián)通下ping服務(wù)器STUN的地址stun.voipbuster.com過程如下：
(某市)鐵通——>(省會(huì))鐵通——>(省)鐵通——>中國(guó)鐵通——>歐洲聯(lián)盟——>荷蘭
(某市)聯(lián)通——>(省會(huì))聯(lián)通——>北京聯(lián)通——>加拿大——>歐洲聯(lián)盟——>德國(guó)——>歐洲聯(lián)盟——>荷蘭
更多待補(bǔ)充！
Android IOS WebRTC 音視頻開發(fā)總結(jié)（四一）-- QQ和webrtc打洞能力pk
標(biāo)簽：android style log com http 使用 si src la
原文：http://www.cnblogs.com/lingyunhu/p/rtc41.html
聯(lián)系客服
