目前幾種常見穿NAT的方法分析 收藏
NAT的出現(xiàn)在一定程度上解決了發(fā)展中國家網(wǎng)絡地址資源不足的情況,然而,這種解決方法也帶來了一些問題,尤其是對網(wǎng)絡要求十分苛刻的流媒體傳輸方面,這些問題變得尤為突出(什么是NAT請參考BOLG的另外一篇文章),在一個帶有NAT結(jié)構(gòu)的網(wǎng)絡環(huán)境中，不能實現(xiàn)P2P(peer to peer也就是點對點)的數(shù)據(jù)傳輸是VOIP的一個硬傷,而如何穿過這些NAT,實現(xiàn)數(shù)據(jù)的點對點傳輸也成了VOIP開發(fā)人員不得不面對的一個頭疼問題.
目前，解決NAT問題的方法大體有四種(按照我的個人觀點，不同意的請拍磚)：修改設備、輔助探測、設備支持和流中轉(zhuǎn)。下面我來分別說明。
（1）修改設備。這種方法也就是通過修改防火墻、router等方法，對在有NAT情況下，實現(xiàn)P2P的數(shù)據(jù)傳輸方式。優(yōu)點很明顯，不用對UA做任何修改，缺點也同樣突出：不可能指望所有的防火墻或者router都支持。這種方法不牽扯到技術(shù)方面的東西，更多的工作交了防火墻或者router開發(fā)人員，我不想多說。
（2）輔助探測。和第一種方法相比較，這種方法不需要對防火墻或者router做任何修改，但UAC需要做一些配合，才能完成NAT的穿越。STUN是這種穿越方式的典型代表。STUN是RFC為了解決NAT而做出的一個標準（你可以在RFC下載到相關(guān)文擋，在我的開發(fā)資源里面有連接），符合這個標準的UAC和服務器，依靠他們之間的一些信息交換，可以確定出UAC在公網(wǎng)的IP地址和端口，從而達到穿越NAT實現(xiàn)P2P的目的。STUN不需要修改網(wǎng)絡的任何部分，也可以在多層NAT下，實現(xiàn)P2P（注：并不是真正意義上的P2P），是一種很可靠的NAT解決方法，因此，STUN在NAT的初期得到了迅速的發(fā)展，你可以找到很多支持STUN的UAC和server資源。STUN的缺點也是顯而易見的：首先，他需要UAC支持。其次用這種方法必須要得到服務器的支持并且要求UAC不停的向一個公網(wǎng)IP發(fā)送數(shù)據(jù)包以維持端口（keep alive）。而這幾個都不是STUN的硬傷，真正置STUN于死地的是一種叫對稱NAT的NAT類型，對于這種NAT類型，STUN 無能為力。在NAT的早期，這種對稱NAT是很少的，然而，隨著對網(wǎng)絡安全要求的提高，目前生產(chǎn)的NAT幾乎全是對稱NAT，這也就等同于宣布STUN的死亡。
（3）設備支持。這種方法和第一種有些類似，但是區(qū)別也是很大的，我用這種方法的典型實例：UPNP來說明。UPNP是微軟和Intel力推的一種標準（顯然這兩個家伙大家都不喜歡，但這并不意味著它們的東西不好），你可以認為這種標準是另一種USB標準，只要你符合這種標準，你生產(chǎn)的USB設備可以被世界上任何一天USB設備使用（我不想討論主從的問題）。而UPNP是網(wǎng)絡設備的USB標準，只要你生產(chǎn)的設備符合UPNP標準，那么它就變成了可以連接到網(wǎng)絡上的，通過網(wǎng)絡控制的USB設備，你用就可以，而不需要關(guān)心如何用，怎么用。
第一次看到UPNP的協(xié)議文擋的時候，我就對自己說：這是個好東西。尤其是當我看到，目前絕大部分（近期生產(chǎn)）網(wǎng)絡設備都支持UPNP的時候，我就更加堅信了我的觀點。
事實上，我們穿越NAT所需要用的只是UPNP協(xié)議族中的一個：WANIPCONNECT SERVICE，也就是互連網(wǎng)接入服務（請允許我這么翻譯，雖然這么有點不恰當，但是更加通俗）。你可以理解為USB設備有N多，而我們用的是U盤一樣。通過這個協(xié)議，你可以控制互連網(wǎng)接入設備（通常是router），來做一些特殊操作，打開一個IP地址影射來實現(xiàn)P2P。這個過程很簡單，只是發(fā)幾個符合要求的數(shù)據(jù)包給UPNP服務設備，但功能卻很強大，的確很迷人。（你可以在開發(fā)資源里面找到UPNP的相關(guān)連接）
UPNP的優(yōu)點如上所說，不需要在累述，但缺點也是有的：1、他需要UAC支持，完成對UPNP設備的控制，令人高興的是，這不是很難。2、這種方法不支持多層NAT嵌套。3、總會碰到不支持UPNP或者號稱支持，實際上卻不支持的UPNP設備。
（4）流中轉(zhuǎn)。流中轉(zhuǎn)是依靠一個公網(wǎng)服務器對兩個UAC的RTP流進行中轉(zhuǎn)的方式解決NAT問題（注意：只是解決，而不是實現(xiàn)P2P），在這種方式下，UAC不需要做任何修改（或者很少修改），并且可以穿越所有的NAT。典型的是outbound。也就是具有公網(wǎng)IP的一臺RTP流轉(zhuǎn)發(fā)服務器。如果outbound server和sip server 沒有合成到一個程序中，那么你必須首先把信令發(fā)送給outbound server，其它的你不需要再關(guān)心。如果是已經(jīng)合成了一個，那你可以象在公網(wǎng)中一樣使用你的UAC，不必再考慮NAT的問題（舒服吧）。
流轉(zhuǎn)發(fā)（outbound）方式簡單，可靠。它使你不再需要考慮NAT的任何東西，可以穿越所有NAT，并且UAC不需要做任何修改，目前網(wǎng)絡上有很多SERVER都是工作在這種方式下。但是它的代價也是昂貴的：它不能實現(xiàn)P2P。這在兩個UAC距離服務器很遠的情況下，會有高的網(wǎng)絡延時和高的丟包率，而這種環(huán)境下的語音或者視頻效果，可能是你不能忍受的。
由于我水平有限，我所知道的NAT解決方案就這四種。如果你問我：xxx方式（比如ICE）怎么沒有的時候，請您先考慮下這種方法是不是上面方法中的一種或幾種的組合（比如汽車是一種交通工具，船也是一種，而我并不認為你把汽車和船弄到了一起就是種新的交通工具），當您知道有別的好的NAT解決方案的時候，麻煩您通知我下，在此謝過
|
QQ好友和群
QQ空間
騰訊微博
騰訊朋友
收藏
淘帖
頂
踩
