本專(zhuān)題第一篇中介紹了P2P打洞的基本原理和方法，我們可以根據(jù)其原理為自己的網(wǎng)絡(luò)程序設(shè)計(jì)一套通信規(guī)則廉白， 當(dāng)然如果這套程序只有自己在使用是沒(méi)什么問(wèn)題的」院可是在現(xiàn)實(shí)生活中猴蹂，我們的程序往往還需要和第三方的協(xié)議（如SDP，SIP）進(jìn)行對(duì)接

”

因此使用標(biāo)準(zhǔn)化 的通用規(guī)則來(lái)進(jìn)行P2P鏈接建立是很有必要的楣嘁。本文就來(lái)介紹一下當(dāng)前主要應(yīng)用于P2P通信的幾個(gè)標(biāo)準(zhǔn)協(xié)議磅轻，主要有STUN/RFC3489，STUN /RFC5389逐虚， -TURN/RFC5766以及ICE /RFC5245(TU-RN聋溜、ICE 會(huì)在后面幾篇文章中介紹）

01

STUN簡(jiǎn)介

前面我們看到，RFC3489和RFC53 89的名稱(chēng)都是STUN叭爱，但其全稱(chēng)是不同的撮躁。在RFC3489里，STUN的全稱(chēng)是Sim ple Traversal of User D-atagram Proto col (UDP) Through Network Address Translators (NA-Ts)买雾， 即穿越NAT的簡(jiǎn)單UDP傳輸把曼，是一個(gè)輕量級(jí)的協(xié)議，允許應(yīng)用程序發(fā)現(xiàn)自己和公網(wǎng)之間的中間件類(lèi)型漓穿，同時(shí)也能允許應(yīng)用程序發(fā)現(xiàn)自己被NA T分配的公網(wǎng)IP嗤军。這個(gè)協(xié)議在2003年3月被提出，其介紹頁(yè)面里 說(shuō)到已經(jīng)被STUN/R FC5389所替代晃危，后者才是我們要詳細(xì)介紹的叙赚。

RFC5389中，STUN的全稱(chēng)為Ses-si on Traversal Utilities for NAT，即NAT環(huán)境下的會(huì)話傳輸工具纠俭，是一種處理NAT傳輸?shù)膮f(xié)議沿量，但主要作為一個(gè)工具來(lái)服務(wù)于其他協(xié)議。和STUN/RF-C3489 類(lèi)似冤荆，可以被終端用來(lái)發(fā)現(xiàn)其公網(wǎng)IP和端口，同時(shí)可以檢測(cè)端點(diǎn)間的連接性权纤，也可以作為一種钡黾颍活（keepaliv-e）協(xié)議來(lái)維持NAT的綁定。和RFC34-89最大的不同點(diǎn)在于汹想，STUN本身不再是一個(gè) 完整的NAT傳輸解決方案外邓，而是在NAT傳輸環(huán)境中作為一個(gè)輔助的解決方法，同時(shí)也增加了TCP的支持古掏。RF-C5389廢棄了RFC3489损话，因此后者通常稱(chēng)為classic STUN，但依舊是后向兼容的槽唾。 而完整的NAT傳輸解決方案則使用STUN的工具性質(zhì)丧枪，ICE就是一個(gè)基于offer/answer方法的完整NAT傳輸方案，如SIP庞萍。

STUN是一個(gè)C/S架構(gòu)的協(xié)議拧烦，支持兩種傳輸類(lèi)型。一種是請(qǐng)求/響應(yīng)（requ-est/ respond）類(lèi)型钝计，由客戶端給服務(wù)器發(fā)送請(qǐng)求恋博，并等待服務(wù)器返回響應(yīng)；另一種是指示類(lèi)型（indication trans-action）私恬，由服務(wù)器或者客戶端 發(fā)送指示债沮，另一方不產(chǎn)生響應(yīng)。兩種類(lèi)型的傳輸都包含一個(gè)96位的隨機(jī)數(shù)作為事務(wù)ID（transactionID）本鸣，對(duì)于請(qǐng)求/響應(yīng)類(lèi)型疫衩，事務(wù)ID允許客戶端將響應(yīng)和產(chǎn)生響應(yīng)的請(qǐng)求連接起來(lái)； 對(duì)于指示類(lèi)型永高，事務(wù)ID通常作為debugging aid使用隧土。

所有的STUN報(bào)文信息都含有一個(gè)固定頭部，包含了方法命爬，類(lèi)和事務(wù)ID曹傀。方法表示是具體哪一種傳輸類(lèi)型（兩種傳輸類(lèi)型又分了很多具體類(lèi)型），STUN中只定義了一個(gè)方法饲宛，即binding（綁定）皆愉，其他的方法可以由使用者 自行拓展；Binding方法可以用于請(qǐng)求/響應(yīng)類(lèi)型和指示類(lèi)型，用于前者時(shí)可以用來(lái)確定一個(gè)NAT給客戶端分配的具體綁定幕庐，用于后者時(shí)可以保持綁定的激活狀態(tài)久锥。類(lèi)表示報(bào)文類(lèi)型是請(qǐng)求/成功響應(yīng)/錯(cuò)誤響應(yīng)/指示。 在固定頭部之后是零個(gè)或者多個(gè)屬性（attribute）异剥，長(zhǎng)度也是不固定的瑟由。

01

STUN報(bào)文結(jié)構(gòu)

STUN報(bào)文和大多數(shù)網(wǎng)絡(luò)類(lèi)型的格式一樣，是以大端編碼(big-endian)的冤寿，即最高有效位在左邊歹苦。所有的STUN報(bào)文都以20字節(jié)的頭部開(kāi)始，后面跟著若干個(gè)屬性督怜。下面來(lái)詳細(xì)說(shuō)說(shuō)STUN報(bào)文頭部殴瘦，STUN頭部包含了STUN消息類(lèi)型，magic cookie号杠，事務(wù)ID和消息長(zhǎng)度蚪腋，如下：

最高的2位必須置零，這可以在當(dāng)STU N和其他協(xié)議復(fù)用的時(shí)候姨蟋，用來(lái)區(qū)分STUN包和其他數(shù)據(jù)包屉凯。STUN Message Type字段定義了消息的類(lèi)型（請(qǐng)求/成功響應(yīng)/失敗響應(yīng)/指示）和消息的主方法。雖然我們有4個(gè)消息類(lèi)別芬探，但在STUN中只有兩種類(lèi)型的事務(wù)神得，即請(qǐng)求/響應(yīng)類(lèi)型和指示類(lèi)型。 響應(yīng)類(lèi)型分為成功和出錯(cuò)兩種偷仿，用來(lái)幫助快速處理STUN信息哩簿。Message Type字段又可以進(jìn)一步分解為如下結(jié)構(gòu)：

其中顯示的位為從最高有效位M11到最低有效位M0，M11到M0表示方法的12位編碼酝静。C1和C0兩位表示類(lèi)的編碼节榜。比如對(duì)于binding方法來(lái)說(shuō)，0b00表示reques t别智，0b01表示indication宗苍，0b10表示succ ess response， 0b11表示error respo nse薄榛，每一個(gè)method都有可能對(duì)應(yīng)不同的傳輸類(lèi)別讳窟。拓展定義新方法的時(shí)候注意要指定該方法允許哪些類(lèi)型的消息。

Magic Cookie字段包含固定值0x21 12A442敞恋，這是為了前向兼容RFC3489丽啡，因?yàn)樵赾lassic STUN中，這一區(qū)域是事務(wù)ID的一部分硬猫。另外選擇固定數(shù)值也是為了服務(wù)器判斷客戶端是否能識(shí)別特定的屬性补箍。 還有一個(gè)作用就是在協(xié)議多路復(fù)用時(shí)候也可以將其作為判斷標(biāo)志之一改执。

Transaction ID字段是個(gè)96位的標(biāo)識(shí)符，用來(lái)區(qū)分不同的STUN傳輸事務(wù)坑雅。對(duì)于request/response傳輸辈挂，事務(wù)ID由客戶端選擇，服務(wù)器收到后以同樣的事務(wù)ID返回response裹粤；對(duì)于indication則由發(fā)送方自行選擇终蒂。 事務(wù)ID的主要功能是把request和response聯(lián)系起來(lái)，同時(shí)也在防止攻擊方面有一定作用遥诉。服務(wù)端也把事務(wù)ID當(dāng)作一個(gè)Key來(lái)識(shí)別不同的STUN客戶端后豫，因此必須格式化且隨機(jī)在0~2^(96-1)之間。 重發(fā)同樣的request請(qǐng)求時(shí)可以重用相同的事務(wù)ID突那，但是客戶端進(jìn)行新的傳輸時(shí)，必須選擇一個(gè)新的事務(wù)ID构眯。

Message Length字段存儲(chǔ)了信息的長(zhǎng)度愕难，以字節(jié)為單位，不包括20字節(jié)的STUN頭部惫霸。由于所有的STU N屬性都是都是4字節(jié)對(duì)齊（填充）的猫缭，因此這個(gè)字段最后兩位應(yīng)該恒等于零，這也是辨別STUN包的一個(gè)方法之一壹店。

STUN屬性在STUN報(bào)文頭部之后猜丹，通常跟著0個(gè)或者多個(gè)屬性，每個(gè)屬性必須是TLV編碼的（Type-Length-Value）硅卢。其中Type字段和Length字段都是16位射窒，Value字段為為32位表示，如下：

Length字段必須包含Value部分需要補(bǔ)齊的長(zhǎng)度将塑，以字節(jié)為單位脉顿。由于STUN屬性以32bit邊界對(duì)齊，因此屬性內(nèi)容不足4字節(jié)的都會(huì)以padding bit進(jìn)行補(bǔ)齊点寥。padding bit會(huì)被忽略艾疟，但可以是任何值。

Type字段為屬性的類(lèi)型敢辩。任何屬性類(lèi)型都有可能在一個(gè)STUN報(bào)文中出現(xiàn)超過(guò)一次蔽莱。除非特殊指定，否則其出現(xiàn)的順序是有意義的：即只有第一次出現(xiàn)的屬性會(huì)被接收端解析戚长，而其余的將被忽略盗冷。 為了以后版本的拓展和改進(jìn)，屬性區(qū)域被分為兩個(gè)部分历葛。Type值在0x0000-0x7FFF之間的屬性被指定為強(qiáng)制理解正塌，意思是STUN終端必須要理解此屬性嘀略，否則將返回錯(cuò)誤信息；而0x8000-0xFFFF 之間的屬性為選擇性理解乓诽，即如果STUN終端不識(shí)別此屬性則將其忽略帜羊。目前STUN的屬性類(lèi)型由IANA維護(hù)。此外還有很多屬性鸠天，如USER NAME讼育，NONCE，REALM稠集，SOFTWAR E等奶段，具體可以翻閱RFC3489.

01

STUN 通信過(guò)程

1. 產(chǎn)生一個(gè)Request或Indication

當(dāng)產(chǎn)生一個(gè)Request或者Indica-tion報(bào)文時(shí)，終端必須根據(jù)上文提到的規(guī)則來(lái)生成頭部剥纷，class字段必須是Re-quest或者Indi cation痹籍，而method字段為Binding或者其他用戶拓展的方法。屬性部分選擇該方法所需要的對(duì)應(yīng)屬性晦鞋，比如在一些 情景下我們會(huì)需要authenticaton屬性或FINGERP RINT屬性蹲缠，注意在發(fā)送Request報(bào)文時(shí)候，需要加上SOFTWARE屬性（內(nèi)含軟件版本描述）悠垛。

2. 發(fā)送Requst或Indication

目前线定，STUN報(bào)文可以通過(guò)UDP，TC P以及TLS-over-TCP的方法發(fā)送确买，其他方法在以后也會(huì)添加進(jìn)來(lái)斤讥。STUN的使用者必須指定其使用的傳輸協(xié)議，以及終端確定接收端IP地址和端口的方式湾趾，比如通過(guò)基于DNS的方法來(lái)確定服務(wù)器的IP和端口芭商。

3.通過(guò)UDP發(fā)送

當(dāng)使用UDP協(xié)議運(yùn)行STUN時(shí)，STUN的報(bào)文可能會(huì)由于網(wǎng)絡(luò)問(wèn)題而丟失撑帖∪乜玻可靠的STUN請(qǐng)求/響應(yīng)傳輸是通過(guò)客戶端重發(fā)request請(qǐng)求來(lái)實(shí)現(xiàn)的，因此胡嘿，在UDP運(yùn)行時(shí)蛉艾，Indication報(bào)文是不可靠的。STUN客戶端通過(guò)RTO（R-etransmission TimeOut） 來(lái)決定是否重傳Requst衷敌，并且在每次重傳后將RTO翻倍勿侯。具體重傳時(shí)間的選取可以參考相關(guān)文章，如RFC2988缴罗。重傳直到接收到Response才停止助琐，或者重傳次數(shù)到達(dá)指定次數(shù)Rc，Rc應(yīng)該是可配置的面氓，且默認(rèn)值為7兵钮。

4.通過(guò)TCP或者TCP-over-TLS發(fā)送

對(duì)于這種情景蛆橡，客戶端打開(kāi)對(duì)服務(wù)器的連接。在某些情況下掘譬，此TCP鏈接只傳輸STUN報(bào)文泰演，而在其他拓展中，在一個(gè)TCP鏈接里可能STUN報(bào)文和其他協(xié)議的報(bào)文會(huì)進(jìn)行多路復(fù)用（Multiplexed）葱轩。數(shù)據(jù)傳輸?shù)目煽啃杂蒚CP協(xié)議本身來(lái)保證睦焕。 值得一提的是，在一次TCP連接中靴拱，STUN客戶端可能發(fā)起多個(gè)傳輸垃喊，有可能在前一個(gè)Request的Response還沒(méi)收到時(shí)就再次發(fā)送了一個(gè)新的Request，因此客戶端應(yīng)該保持TCP鏈接打開(kāi)袜炕，認(rèn)所有STUN事務(wù)都已完成本谜。

5.接收STUN消息

當(dāng)STUN終端接收到一個(gè)STUN報(bào)文時(shí)，首先檢查報(bào)文的規(guī)則是否合法偎窘，即前兩位是否為0耕突，magic cookie是否為0x21 12A442，報(bào)文長(zhǎng)度是否正確以及對(duì)應(yīng)的方法是否支持评架。如果消息類(lèi)別為Success/E rror Response，終端會(huì)檢測(cè)其事務(wù)ID 是否與當(dāng)前正在處理的事務(wù)ID相同炕泳。如果使用了FINGERPRINT拓展的話還會(huì)檢查FIN GERPRINT屬性是否正確纵诞。完成身份認(rèn)證檢查之后，STUN終端會(huì)接著檢查其余未知屬性培遵。

6.處理Request

如果請(qǐng)求包含一個(gè)或者多個(gè)強(qiáng)制理解的未知屬性浙芙，接收端會(huì)返回error response，錯(cuò)誤代碼420（ERRORC-ODE屬性）籽腕，而且包含一個(gè)UNKNOW-N-ATTRIBUTES屬性來(lái)告知發(fā)送方哪些強(qiáng)制理解的屬性是未知的嗡呼。服務(wù)端接著檢查方法和其他指定要求，如果所有檢查都成功皇耗， 則會(huì)產(chǎn)生一個(gè)Success Response給客戶端南窗。

7.處理Indication

如果Indication報(bào)文包含未知的強(qiáng)制理解屬性，則此報(bào)文會(huì)被接收端忽略并丟棄郎楼。如果對(duì)Indication報(bào)文的檢查都沒(méi)有錯(cuò)誤万伤，則服務(wù)端會(huì)進(jìn)行相應(yīng)的處理，但是不會(huì)返回Response呜袁。對(duì)于Binding方法敌买，一般不需要額外的檢查或處理。收到信息的服務(wù)端僅需要刷新對(duì)應(yīng)NAT的端口綁定阶界。

由于Indication報(bào)文在用UDP協(xié)議傳輸時(shí)不會(huì)進(jìn)行重傳虹钮，因此發(fā)送方也不需要處理重傳的情況聋庵。

8.處理Success Response

如果Success Response包含了未知的強(qiáng)制理解屬性，則響應(yīng)會(huì)被忽略并且認(rèn)為此次傳輸失敗芙粱〖烙瘢客戶端對(duì)報(bào)文進(jìn)行檢查通過(guò)之后，就可以開(kāi)始處理此次報(bào)文宅倒。

以Binding方法為例攘宙，客戶端會(huì)檢查報(bào)文中是否包含XOR-MAPPED-ADDRESS屬性，然后是地址類(lèi)型拐迁，如果是不支持的地址類(lèi)型蹭劈，則這個(gè)屬性會(huì)被忽略掉。

9.處理Error Response

如果Error Response包含了未知的強(qiáng)制理解屬性线召，或者沒(méi)有包含ERROR-CODE屬性铺韧，則響應(yīng)會(huì)被忽略并且認(rèn)為此次傳輸失敗。隨后客戶端會(huì)對(duì)驗(yàn)證方法進(jìn)行處理缓淹，這有可能會(huì)產(chǎn)生新的傳輸哈打。

上面只是介紹了STUN/RFC5389協(xié)議的基礎(chǔ)部分，協(xié)議本身還包含了許多mech anism讯壶，如身份驗(yàn)證（Auth-entication）DNS Discovery料仗，F(xiàn)IN-GERPRINT Mech anisms，ALTER-NATE-SERVER Mecha nism等伏蚊， 身份驗(yàn)證又分為長(zhǎng)期驗(yàn)證和短期驗(yàn)證立轧，從而保證了傳輸?shù)撵`活性并減少服務(wù)器的負(fù)擔(dān)，具體開(kāi)發(fā)時(shí)可以參閱白皮書(shū).