TMT观察网_独特视角观察TMT行业

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

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

STUN是一個C/S架構的協議，支持兩種傳輸類型。一種是請求/響應（requ-est/ respond）類型，由客戶端給服務器發送請求，并等待服務器返回響應；另一種是指示類型（indication trans-action），由服務器或者客戶端 發送指示，另一方不產生響應。兩種類型的傳輸都包含一個96位的隨機數作為事務ID（transactionID），對于請求/響應類型，事務ID允許客戶端將響應和產生響應的請求連接起來； 對于指示類型，事務ID通常作為debugging aid使用。

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

02、STUN報文結構

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

最高的2位必須置零，這可以在當STU N和其他協議復用的時候，用來區分STUN包和其他數據包。STUN Message Type字段定義了消息的類型（請求/成功響應/失敗響應/指示）和消息的主方法。雖然我們有4個消息類別，但在STUN中只有兩種類型的事務，即請求/響應類型和指示類型。 響應類型分為成功和出錯兩種，用來幫助快速處理STUN信息。Message Type字段又可以進一步分解為如下結構：

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

Magic Cookie字段包含固定值0x21 12A442，這是為了前向兼容RFC3489，因為在classic STUN中，這一區域是事務ID的一部分。另外選擇固定數值也是為了服務器判斷客戶端是否能識別特定的屬性。 還有一個作用就是在協議多路復用時候也可以將其作為判斷標志之一。

Transaction ID字段是個96位的標識符，用來區分不同的STUN傳輸事務。對于request/response傳輸，事務ID由客戶端選擇，服務器收到后以同樣的事務ID返回response；對于indication則由發送方自行選擇。 事務ID的主要功能是把request和response聯系起來，同時也在防止攻擊方面有一定作用。服務端也把事務ID當作一個Key來識別不同的STUN客戶端，因此必須格式化且隨機在0~2^(96-1)之間。 重發同樣的request請求時可以重用相同的事務ID，但是客戶端進行新的傳輸時，必須選擇一個新的事務ID。

Message Length字段存儲了信息的長度，以字節為單位，不包括20字節的STUN頭部。由于所有的STU N屬性都是都是4字節對齊（填充）的，因此這個字段最后兩位應該恒等于零，這也是辨別STUN包的一個方法之一。

STUN屬性在STUN報文頭部之后，通常跟著0個或者多個屬性，每個屬性必須是TLV編碼的（Type-Length-Value）。其中Type字段和Length字段都是16位，Value字段為為32位表示，如下：

Length字段必須包含Value部分需要補齊的長度，以字節為單位。由于STUN屬性以32bit邊界對齊，因此屬性內容不足4字節的都會以padding bit進行補齊。padding bit會被忽略，但可以是任何值。

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

03、STUN 通信過程

1. 產生一個Request或Indication

當產生一個Request或者Indica-tion報文時，終端必須根據上文提到的規則來生成頭部，class字段必須是Re-quest或者Indi cation，而method字段為Binding或者其他用戶拓展的方法。屬性部分選擇該方法所需要的對應屬性，比如在一些 情景下我們會需要authenticaton屬性或FINGERP RINT屬性，注意在發送Request報文時候，需要加上SOFTWARE屬性（內含軟件版本描述）。

2. 發送Requst或Indication

目前，STUN報文可以通過UDP，TC P以及TLS-over-TCP的方法發送，其他方法在以后也會添加進來。STUN的使用者必須指定其使用的傳輸協議，以及終端確定接收端IP地址和端口的方式，比如通過基于DNS的方法來確定服務器的IP和端口。

3.通過UDP發送

當使用UDP協議運行STUN時，STUN的報文可能會由于網絡問題而丟失。可靠的STUN請求/響應傳輸是通過客戶端重發request請求來實現的，因此，在UDP運行時，Indication報文是不可靠的。STUN客戶端通過RTO（R-etransmission TimeOut） 來決定是否重傳Requst，并且在每次重傳后將RTO翻倍。具體重傳時間的選取可以參考相關文章，如RFC2988。重傳直到接收到Response才停止，或者重傳次數到達指定次數Rc，Rc應該是可配置的，且默認值為7。

4.通過TCP或者TCP-over-TLS發送

對于這種情景，客戶端打開對服務器的連接。在某些情況下，此TCP鏈接只傳輸STUN報文，而在其他拓展中，在一個TCP鏈接里可能STUN報文和其他協議的報文會進行多路復用（Multiplexed）。數據傳輸的可靠性由TCP協議本身來保證。 值得一提的是，在一次TCP連接中，STUN客戶端可能發起多個傳輸，有可能在前一個Request的Response還沒收到時就再次發送了一個新的Request，因此客戶端應該保持TCP鏈接打開，認所有STUN事務都已完成。

5.接收STUN消息

當STUN終端接收到一個STUN報文時，首先檢查報文的規則是否合法，即前兩位是否為0，magic cookie是否為0x21 12A442，報文長度是否正確以及對應的方法是否支持。如果消息類別為Success/E rror Response，終端會檢測其事務ID 是否與當前正在處理的事務ID相同。如果使用了FINGERPRINT拓展的話還會檢查FIN GERPRINT屬性是否正確。完成身份認證檢查之后，STUN終端會接著檢查其余未知屬性。

6.處理Request

如果請求包含一個或者多個強制理解的未知屬性，接收端會返回error response，錯誤代碼420（ERRORC-ODE屬性），而且包含一個UNKNOW-N-ATTRIBUTES屬性來告知發送方哪些強制理解的屬性是未知的。服務端接著檢查方法和其他指定要求，如果所有檢查都成功， 則會產生一個Success Response給客戶端。

7.處理Indication

如果Indication報文包含未知的強制理解屬性，則此報文會被接收端忽略并丟棄。如果對Indication報文的檢查都沒有錯誤，則服務端會進行相應的處理，但是不會返回Response。對于Binding方法，一般不需要額外的檢查或處理。收到信息的服務端僅需要刷新對應NAT的端口綁定。

由于Indication報文在用UDP協議傳輸時不會進行重傳，因此發送方也不需要處理重傳的情況。

8.處理Success Response

如果Success Response包含了未知的強制理解屬性，則響應會被忽略并且認為此次傳輸失敗。客戶端對報文進行檢查通過之后，就可以開始處理此次報文。

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

9.處理Error Response

如果Error Response包含了未知的強制理解屬性，或者沒有包含ERROR-CODE屬性，則響應會被忽略并且認為此次傳輸失敗。隨后客戶端會對驗證方法進行處理，這有可能會產生新的傳輸。

上面只是介紹了STUN/RFC5389協議的基礎部分，協議本身還包含了許多mech anism，如身份驗證（Auth-entication）DNS Discovery，FIN-GERPRINT Mech anisms，ALTER-NATE-SERVER Mecha nism等， 身份驗證又分為長期驗證和短期驗證，從而保證了傳輸的靈活性并減少服務器的負擔，具體開發時可以參閱白皮書.