為了項(xiàng)目的后期IM應(yīng)用，最近在研究libjingle，中間看了也收集了很多資料，感慨網(wǎng)上很多資料要么太過(guò)于糾結(jié)協(xié)議（如STUN、ICE等）實(shí)現(xiàn)細(xì)節(jié)，要么中間有很多紕漏。最后去偽存真，歸納總結(jié)了一下，希望對(duì)以后的同行有些許幫助。
如果有什么需要討論或者指正的，歡迎留言或者郵件peakflys@gmail.com
P2P實(shí)現(xiàn)的原理
首先先介紹一些基本概念：
NAT(Network Address Translators)，網(wǎng)絡(luò)地址轉(zhuǎn)換：網(wǎng)絡(luò)地址轉(zhuǎn)換是在IP地址日益缺乏的情況下產(chǎn)生的，它的主要目的就是為了能夠地址重用。NAT從歷史發(fā)展上分為兩大類(lèi)，基本的NAT和NAPT(Network Address/Port Translator)。
最先提出的是基本的NAT(peakflys注：剛開(kāi)始其實(shí)只是路由器上的一個(gè)功能模塊)，它的產(chǎn)生基于如下事實(shí)：一個(gè)私有網(wǎng)絡(luò)（域）中的節(jié)點(diǎn)中只有很少的節(jié)點(diǎn)需要與外網(wǎng)連接（這是在上世紀(jì)90年代中期提出的）。那么這個(gè)子網(wǎng)中其實(shí)只有少數(shù)的節(jié)點(diǎn)需要全球唯一的IP地址，其他的節(jié)點(diǎn)的IP地址應(yīng)該是可以重用的。
因此，基本的NAT實(shí)現(xiàn)的功能很簡(jiǎn)單，在子網(wǎng)內(nèi)使用一個(gè)保留的IP子網(wǎng)段，這些IP對(duì)外是不可見(jiàn)的。子網(wǎng)內(nèi)只有少數(shù)一些IP地址可以對(duì)應(yīng)到真正全球唯一的IP地址。如果這些節(jié)點(diǎn)需要訪(fǎng)問(wèn)外部網(wǎng)絡(luò)，那么基本NAT就負(fù)責(zé)將這個(gè)節(jié)點(diǎn)的子網(wǎng)內(nèi)IP轉(zhuǎn)化為一個(gè)全球唯一的IP然后發(fā)送出去。(基本的NAT會(huì)改變IP包中的原IP地址，但是不會(huì)改變IP包中的端口)
關(guān)于基本的NAT可以參看RFC 1631
另外一種NAT叫做NAPT，從名稱(chēng)上我們也可以看得出，NAPT不但會(huì)改變經(jīng)過(guò)這個(gè)NAT設(shè)備的IP數(shù)據(jù)報(bào)的IP地址，還會(huì)改變IP數(shù)據(jù)報(bào)的TCP/UDP端口。基本NAT的設(shè)備可能我們見(jiàn)的不多（基本已經(jīng)淘汰了），NAPT才是我們真正需要關(guān)注的。看下圖：
有一個(gè)私有網(wǎng)絡(luò)10.*.*.*，Client A是其中的一臺(tái)計(jì)算機(jī)，這個(gè)網(wǎng)絡(luò)的網(wǎng)關(guān)（一個(gè)NAT設(shè)備）的外網(wǎng)IP是155.99.25.11(應(yīng)該還有一個(gè)內(nèi)網(wǎng)的IP地址，比如10.0.0.10)。如果Client A中的某個(gè)進(jìn)程（這個(gè)進(jìn)程創(chuàng)建了一個(gè)UDP Socket,這個(gè)Socket綁定1234端口）想訪(fǎng)問(wèn)外網(wǎng)主機(jī)18.181.0.31的1235端口，那么當(dāng)數(shù)據(jù)包通過(guò)NAT時(shí)會(huì)發(fā)生什么事情呢？
首先NAT會(huì)改變這個(gè)數(shù)據(jù)包的原IP地址，改為155.99.25.11。接著NAT會(huì)為這個(gè)傳輸創(chuàng)建一個(gè)Session（Session是一個(gè)抽象的概念，如果是TCP，也許Session是由一個(gè)SYN包開(kāi)始，以一個(gè)FIN包結(jié)束。而UDP呢，以這個(gè)IP的這個(gè)端口的第一個(gè)UDP開(kāi)始，結(jié)束呢，呵呵，也許是幾分鐘，也許是幾小時(shí)，這要看具體的實(shí)現(xiàn)了）并且給這個(gè)Session分配一個(gè)端口，比如62000，然后改變這個(gè)數(shù)據(jù)包的源端口為62000。所以本來(lái)是
（10.0.0.1:1234->18.181.0.31:1235）的數(shù)據(jù)包到了互聯(lián)網(wǎng)上變?yōu)榱耍?55.99.25.11:62000->18.181.0.31:1235）。
一旦NAT創(chuàng)建了一個(gè)Session后，NAT會(huì)記住62000端口對(duì)應(yīng)的是10.0.0.1的1234端口，以后從18.181.0.31發(fā)送到62000端口的數(shù)據(jù)會(huì)被NAT自動(dòng)的轉(zhuǎn)發(fā)到10.0.0.1上。（注意：這里是說(shuō)18.181.0.31發(fā)送到62000端口的數(shù)據(jù)會(huì)被轉(zhuǎn)發(fā)，其他的IP發(fā)送到這個(gè)端口的數(shù)據(jù)將被NAT拋棄）這樣Client A就與Server S1建立以了一個(gè)連接。
上面的是一些基礎(chǔ)知識(shí)，下面的才是關(guān)鍵的部分了。
看看下面的情況：
接上面的例子，如果Client A的原來(lái)那個(gè)Socket(綁定了1234端口的那個(gè)UDP Socket)又接著向另外一個(gè)Server S2發(fā)送了一個(gè)UDP包，那么這個(gè)UDP包在通過(guò)NAT時(shí)會(huì)怎么樣呢？
這時(shí)可能會(huì)有兩種情況發(fā)生，一種是NAT再次創(chuàng)建一個(gè)Session，并且再次為這個(gè)Session分配一個(gè)端口號(hào)（比如：62001）。另外一種是NAT再次創(chuàng)建一個(gè)Session，但是不會(huì)新分配一個(gè)端口號(hào)，而是用原來(lái)分配的端口號(hào)62000。前一種NAT叫做Symmetric NAT，后一種叫做Cone NAT。如果你的NAT剛好是第一種，那么很可能會(huì)有很多P2P軟件失靈。（可以慶幸的是，現(xiàn)在絕大多數(shù)的NAT屬于后者，即Cone NAT）
peakflys注：Cone NAT具體又分為3種：
(1)全圓錐( Full Cone) : NAT把所有來(lái)自相同內(nèi)部IP地址和端口的請(qǐng)求映射到相同的外部IP地址和端口。任何一個(gè)外部主機(jī)均可通過(guò)該映射發(fā)送IP包到該內(nèi)部主機(jī)。
(2)限制性圓錐(Restricted Cone) : NAT把所有來(lái)自相同內(nèi)部IP地址和端口的請(qǐng)求映射到相同的外部IP地址和端口。但是,只有當(dāng)內(nèi)部主機(jī)先給IP地址為X的外部主機(jī)發(fā)送IP包,該外部主機(jī)才能向該內(nèi)部主機(jī)發(fā)送IP包。
(3)端口限制性圓錐( Port Restricted Cone) :端口限制性圓錐與限制性圓錐類(lèi)似,只是多了端口號(hào)的限制,即只有內(nèi)部主機(jī)先向IP地址為X,端口號(hào)為P的外部主機(jī)發(fā)送1個(gè)IP包,該外部主機(jī)才能夠把源端口號(hào)為P的IP包發(fā)送給該內(nèi)部主機(jī)。
好了，我們看到，通過(guò)NAT,子網(wǎng)內(nèi)的計(jì)算機(jī)向外連結(jié)是很容易的（NAT相當(dāng)于透明的，子網(wǎng)內(nèi)的和外網(wǎng)的計(jì)算機(jī)不用知道NAT的情況）。
但是如果外部的計(jì)算機(jī)想訪(fǎng)問(wèn)子網(wǎng)內(nèi)的計(jì)算機(jī)就比較困難了（而這正是P2P所需要的）。
那么我們?nèi)绻霃耐獠堪l(fā)送一個(gè)數(shù)據(jù)報(bào)給內(nèi)網(wǎng)的計(jì)算機(jī)有什么辦法呢？首先，我們必須在內(nèi)網(wǎng)的NAT上打上一個(gè)“洞”（也就是前面我們說(shuō)的在NAT上建立一個(gè)Session），這個(gè)洞不能由外部來(lái)打，只能由內(nèi)網(wǎng)內(nèi)的主機(jī)來(lái)打。而且這個(gè)洞是有方向的，比如從內(nèi)部某臺(tái)主機(jī)（比如：192.168.0.10）向外部的某個(gè)IP(比如：219.237.60.1)發(fā)送一個(gè)UDP包，那么就在這個(gè)內(nèi)網(wǎng)的NAT設(shè)備上打了一個(gè)方向?yàn)?19.237.60.1的“洞”，（這就是稱(chēng)為UDP Hole Punching的技術(shù)）以后219.237.60.1就可以通過(guò)這個(gè)洞與內(nèi)網(wǎng)的192.168.0.10聯(lián)系了。（但是其他的IP不能利用這個(gè)洞）。
P2P的常用實(shí)現(xiàn)
一、普通的直連式P2P實(shí)現(xiàn)
通過(guò)上面的理論，實(shí)現(xiàn)兩個(gè)內(nèi)網(wǎng)的主機(jī)通訊就差最后一步了：那就是雞生蛋還是蛋生雞的問(wèn)題了，兩邊都無(wú)法主動(dòng)發(fā)出連接請(qǐng)求，誰(shuí)也不知道誰(shuí)的公網(wǎng)地址，那我們?nèi)绾蝸?lái)打這個(gè)洞呢？我們需要一個(gè)中間人來(lái)聯(lián)系這兩個(gè)內(nèi)網(wǎng)主機(jī)。
現(xiàn)在我們來(lái)看看一個(gè)P2P軟件的流程，以下圖為例：
首先，Client A登錄服務(wù)器，NAT A為這次的Session分配了一個(gè)端口60000，那么Server S收到的Client A的地址是202.187.45.3:60000，這就是Client A的外網(wǎng)地址了。同樣，Client B登錄Server S，NAT B給此次Session分配的端口是40000，那么Server S收到的B的地址是187.34.1.56:40000。
此時(shí)，Client A與Client B都可以與Server S通信了。如果Client A此時(shí)想直接發(fā)送信息給Client B，那么他可以從Server S那兒獲得B的公網(wǎng)地址187.34.1.56:40000，是不是Client A向這個(gè)地址發(fā)送信息Client B就能收到了呢？答案是不行，因?yàn)槿绻@樣發(fā)送信息，NAT B會(huì)將這個(gè)信息丟棄（因?yàn)檫@樣的信息是不請(qǐng)自來(lái)的，為了安全，大多數(shù)NAT都會(huì)執(zhí)行丟棄動(dòng)作）。現(xiàn)在我們需要的是在NAT B上打一個(gè)方向?yàn)?02.187.45.3（即Client A的外網(wǎng)地址）的洞，那么Client A發(fā)送到187.34.1.56:40000的信息,Client B就能收到了。這個(gè)打洞命令由誰(shuí)來(lái)發(fā)呢？自然是Server S。
總結(jié)一下這個(gè)過(guò)程：如果Client A想向Client B發(fā)送信息，那么Client A發(fā)送命令給Server S，請(qǐng)求Server S命令Client B向Client A方向打洞。然后Client A就可以通過(guò)Client B的外網(wǎng)
地址與Client B通信了。
注意：以上過(guò)程只適合于Cone NAT的情況，如果是Symmetric NAT，那么當(dāng)Client B向Client A打洞的端口已經(jīng)重新分配了，Client B將無(wú)法知道這個(gè)端口（如果Symmetric NAT的端口是順序分配的，那么我們或許可以猜測(cè)這個(gè)端口號(hào)，可是由于可能導(dǎo)致失敗的因素太多，這種情況下一般放棄P2P ---peakflys）。
二、STUN方式的P2P實(shí)現(xiàn)
STUN是RFC3489規(guī)定的一種NAT穿透方式，它采用輔助的方法探測(cè)NAT的IP和端口。毫無(wú)疑問(wèn)的，它對(duì)穿越早期的NAT起了巨大的作用，并且還將繼續(xù)在NAT穿透中占有一席之地。
STUN的探測(cè)過(guò)程需要有一個(gè)公網(wǎng)IP的STUN server，在NAT后面的UAC必須和此server配合，互相之間發(fā)送若干個(gè)UDP數(shù)據(jù)包。UDP包中包含有UAC需要了解的信息，比如NAT外網(wǎng)IP，PORT等等。UAC通過(guò)是否得到這個(gè)UDP包和包中的數(shù)據(jù)判斷自己的NAT類(lèi)型。
假設(shè)有如下UAC（B），NAT（A），SERVER（C），UAC的IP為IPB，NAT的IP為 IPA ，SERVER的 IP為IPC1 、IPC2。請(qǐng)注意，服務(wù)器C有兩個(gè)IP，后面你會(huì)理解為什么需要兩個(gè)IP。
(1)NAT的探測(cè)過(guò)程
STEP1：B向C的IPC1的port1端口發(fā)送一個(gè)UDP包。C收到這個(gè)包后，會(huì)把它收到包的源IP和port寫(xiě)到UDP包中，然后把此包通過(guò)IP1C和port1發(fā)還給B。這個(gè)IP和port也就是NAT的外網(wǎng)IP和port，也就是說(shuō)你在STEP1中就得到了NAT的外網(wǎng)IP。
熟悉NAT工作原理的應(yīng)該都知道，C返回給B的這個(gè)UDP包B一定收到。如果在你的應(yīng)用中，向一個(gè)STUN服務(wù)器發(fā)送數(shù)據(jù)包后，你沒(méi)有收到STUN的任何回應(yīng)包，那只有兩種可能：1、STUN服務(wù)器不存在，或者你弄錯(cuò)了port。2、你的NAT設(shè)備拒絕一切UDP包從外部向內(nèi)部通過(guò)，如果排除防火墻限制規(guī)則，那么這樣的NAT設(shè)備如果存在，那肯定是壞了„„
當(dāng)B收到此UDP后，把此UDP中的IP和自己的IP做比較，如果是一樣的，就說(shuō)明自己是在公網(wǎng)，下步NAT將去探測(cè)防火墻類(lèi)型，就不多說(shuō)了(下面有圖)。如果不一樣，說(shuō)明有NAT的存在，系統(tǒng)進(jìn)行STEP2的操作。
STEP2：B向C的IPC1發(fā)送一個(gè)UDP包，請(qǐng)求C通過(guò)另外一個(gè)IPC2和PORT（不同與SETP1的IP1）向B返回一個(gè)UDP數(shù)據(jù)包（現(xiàn)在知道為什么C要有兩個(gè)IP了吧，為了檢測(cè)cone NAT的類(lèi)型）。
我們來(lái)分析一下，如果B收到了這個(gè)數(shù)據(jù)包，那說(shuō)明什么？說(shuō)明NAT來(lái)著不拒，不對(duì)數(shù)據(jù)包進(jìn)行任何過(guò)濾，這也就是STUN標(biāo)準(zhǔn)中的full cone NAT。遺憾的是，full cone nat太少了，這也意味著你能收到這個(gè)數(shù)據(jù)包的可能性不大。如果沒(méi)收到，那么系統(tǒng)進(jìn)行STEP3的操作。
STEP3：B向C的IPC2的port2發(fā)送一個(gè)數(shù)據(jù)包，C收到數(shù)據(jù)包后，把它收到包的源IP和port寫(xiě)到UDP包中，然后通過(guò)自己的IPC2和port2把此包發(fā)還給B。
和step1一樣，B肯定能收到這個(gè)回應(yīng)UDP包。此包中的port是我們最關(guān)心的數(shù)據(jù)，下面我們來(lái)分析：
如果這個(gè)port和step1中的port一樣，那么可以肯定這個(gè)NAT是個(gè)CONE NAT，否則是對(duì)稱(chēng)NAT。道理很簡(jiǎn)單：根據(jù)對(duì)稱(chēng)NAT的規(guī)則，當(dāng)目的地址的IP和port有任何一個(gè)改變，那么NAT都會(huì)重新分配一個(gè)port使用，而在step3中，和step1對(duì)應(yīng)，我們改變了IP和port。因此，如果是對(duì)稱(chēng)NAT,那這兩個(gè)port肯定是不同的。
如果在你的應(yīng)用中，到此步的時(shí)候PORT是不同的，那就只能放棄P2P了，原因同上面實(shí)現(xiàn)中的一樣。如果不同，那么只剩下了restrict cone 和port restrict cone。系統(tǒng)用step4探測(cè)是是那一種。
STEP4：B向C的IP2的一個(gè)端口PD發(fā)送一個(gè)數(shù)據(jù)請(qǐng)求包，要求C用IP2和不同于PD的port返回一個(gè)數(shù)據(jù)包給B。
我們來(lái)分析結(jié)果：如果B收到了，那也就意味著只要IP相同，即使port不同，NAT也允許UDP包通過(guò)。顯然這是restrict cone NAT。如果沒(méi)收到，沒(méi)別的好說(shuō)，port restrict NAT.
協(xié)議實(shí)現(xiàn)的算法運(yùn)行圖如下：
一旦路經(jīng)到達(dá)紅色節(jié)點(diǎn)時(shí)，UDP的溝通是沒(méi)有可能性的(peakflys注：準(zhǔn)備來(lái)說(shuō)除了包被防火墻blocked之外，其他情況也是有可能建立P2P的，只是代價(jià)太大，一般放棄)。一旦通過(guò)黃色或是綠色的節(jié)點(diǎn)，就有連接的可能。
最終通過(guò)STUN服務(wù)器得到自己的NAT類(lèi)型和公網(wǎng)IP、Port，以后建立P2P時(shí)就非常容易了
peakflys注：Libjingle正是通過(guò)ICE&STUN方式，建立的P2P連接。關(guān)于libjingle的介紹，待續(xù)……
參考資料：
1、維基百科之STUN
2、http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt（shootingstars）