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

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

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

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

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

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

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

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

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í)符，用來區(qū)分不同的STUN傳輸事務(wù)。對(duì)于request/response傳輸，事務(wù)ID由客戶端選擇，服務(wù)器收到后以同樣的事務(wù)ID返回response；對(duì)于indication則由發(fā)送方自行選擇。 事務(wù)ID的主要功能是把request和response聯(lián)系起來，同時(shí)也在防止攻擊方面有一定作用。服務(wù)端也把事務(wù)ID當(dāng)作一個(gè)Key來識(shí)別不同的STUN客戶端，因此必須格式化且隨機(jī)在0~2^(96-1)之間。 重發(fā)同樣的request請(qǐng)求時(shí)可以重用相同的事務(wù)ID，但是客戶端進(jìn)行新的傳輸時(shí)，必須選擇一個(gè)新的事務(wù)ID。

Message Length字段存儲(chǔ)了信息的長度，以字節(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ǔ)齊的長度，以字節(jié)為單位。由于STUN屬性以32bit邊界對(duì)齊，因此屬性內(nèi)容不足4字節(jié)的都會(huì)以padding bit進(jìn)行補(bǔ)齊。padding bit會(huì)被忽略，但可以是任何值。

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

03、STUN 通信過程

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

當(dāng)產(chǎn)生一個(gè)Request或者Indica-tion報(bào)文時(shí)，終端必須根據(jù)上文提到的規(guī)則來生成頭部，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)文可以通過UDP，TC P以及TLS-over-TCP的方法發(fā)送，其他方法在以后也會(huì)添加進(jìn)來。STUN的使用者必須指定其使用的傳輸協(xié)議，以及終端確定接收端IP地址和端口的方式，比如通過基于DNS的方法來確定服務(wù)器的IP和端口。

3.通過UDP發(fā)送

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

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

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

5.接收STUN消息

當(dāng)STUN終端接收到一個(gè)STUN報(bào)文時(shí)，首先檢查報(bào)文的規(guī)則是否合法，即前兩位是否為0，magic cookie是否為0x21 12A442，報(bào)文長度是否正確以及對(duì)應(yīng)的方法是否支持。如果消息類別為Success/E rror Response，終端會(huì)檢測其事務(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屬性來告知發(fā)送方哪些強(qiáng)制理解的屬性是未知的。服務(wù)端接著檢查方法和其他指定要求，如果所有檢查都成功， 則會(huì)產(chǎn)生一個(gè)Success Response給客戶端。

7.處理Indication

如果Indication報(bào)文包含未知的強(qiáng)制理解屬性，則此報(bào)文會(huì)被接收端忽略并丟棄。如果對(duì)Indication報(bào)文的檢查都沒有錯(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)行檢查通過之后，就可以開始處理此次報(bào)文。

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

9.處理Error Response

如果Error Response包含了未知的強(qiáng)制理解屬性，或者沒有包含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)證又分為長期驗(yàn)證和短期驗(yàn)證，從而保證了傳輸?shù)撵`活性并減少服務(wù)器的負(fù)擔(dān)，具體開發(fā)時(shí)可以參閱白皮書.