前一段時間在P2P通訊原理與實現中介紹了P2P打洞的基本原理和方法，我們可以根據其原理為自己的網路程式設計一套通訊規則，
當然如果這套程式只有自己在使用是沒什麼問題的。可是在現實生活中，我們的程式往往還需要和第三方的協議（如SDP，SIP）進行對接，因此使用標準化
的通用規則來進行P2P連結建立是很有必要的。本文就來介紹一下當前主要應用於P2P通訊的幾個標準協議，主要有STUN/RFC3489，STUN/RFC5389，
TURN/RFC5766以及ICE/RFC5245。
STUN簡介
在前言裡我們看到，RFC3489和RFC5389的名稱都是STUN，但其全稱是不同的。在RFC3489裡，
STUN的全稱是Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)，
即穿越NAT的簡單UDP傳輸，是一個輕量級的協議，允許應用程式發現自己和公網之間的中介軟體型別，
同時也能允許應用程式發現自己被NAT分配的公網IP。這個協議在2003年3月被提出，其介紹頁面裡
說到已經被STUN/RFC5389所替代，後者才是我們要詳細介紹的。
RFC5389中，STUN的全稱為Session Traversal Utilities for NAT，即NAT環境下的會話傳輸工具，
是一種處理NAT傳輸的協議，但主要作為一個工具來服務於其他協議。和STUN/RFC3489
類似，可以被終端用來發現其公網IP和埠，同時可以檢測端點間的連線性，也可以作為一種保活（keep-alive）協議來維持NAT的繫結。
和RFC3489最大的不同點在於，STUN本身不再是一個完整的NAT傳輸解決方案，而是在NAT傳輸環境中作為一個輔助的解決方法，
同時也增加了TCP的支援。RFC5389廢棄了RFC3489，因此後者通常稱為classic STUN，但依舊是後向相容的。
而完整的NAT傳輸解決方案則使用STUN的工具性質，ICE就是一個基於offer/answer方法的完整NAT傳輸方案，如SIP。
STUN是一個C/S架構的協議，支援兩種傳輸型別。一種是請求/響應（request/respond）型別，由客戶端給伺服器傳送請求，
並等待伺服器返回響應；另一種是指示型別（indication transaction），由伺服器或者客戶端傳送指示，另一方不產生響應。
兩種型別的傳輸都包含一個96位的隨機數作為事務ID（transaction ID），對於請求/響應型別，事務ID允許客戶端將響應和產生響應的請求連線起來；
對於指示型別，事務ID通常作為debugging aid使用。
所有的STUN報文資訊都含有一個固定頭部，包含了方法，類和事務ID。方法表示是具體哪一種傳輸型別（兩種傳輸型別又分了很多具體型別），
STUN中只定義了一個方法，即binding（繫結），其他的方法可以由使用者自行擴充；Binding方法可以用於請求/響應型別和指示型別，
用於前者時可以用來確定一個NAT給客戶端分配的具體繫結，用於後者時可以保持繫結的啟用狀態。類表示報文型別是請求/成功響應/錯誤響應/指示。
在固定頭部之後是零個或者多個屬性（attribute），長度也是不固定的。
STUN報文結構
STUN報文和大多數網路型別的格式一樣，是以大端編碼(big-endian)的，即最高有效位在左邊。所有的STUN報文都以20位元組的頭部開始，後面跟著若干個屬性。下面來詳細說說。
STUN報文頭部
STUN頭部包含了STUN訊息型別，magic cookie，事務ID和訊息長度，如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0| STUN Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transaction ID (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+最高的2位必須置零，這可以在當STUN和其他協議複用的時候，用來區分STUN包和其他資料包。
STUN Message Type欄位定義了訊息的型別（請求/成功響應/失敗響應/指示）和訊息的主方法。
雖然我們有4個訊息類別，但在STUN中只有兩種型別的事務，即請求/響應型別和指示型別。
響應型別分為成功和出錯兩種，用來幫助快速處理STUN資訊。Message Type欄位又可以進一步分解為如下結構：
0 1
2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
|M |M |M|M|M|C|M|M|M|C|M|M|M|M|
|11|10|9|8|7|1|6|5|4|0|3|2|1|0|
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+其中顯示的位為從最高有效位M11到最低有效位M0，M11到M0表示方法的12位編碼。C1和C0兩位表示類的編碼。比如對於binding方法來說，
0b00表示request，0b01表示indication，0b10表示success response，0b11表示error response，每一個method都有可能對應不同的傳輸類別。
擴充定義新方法的時候注意要指定該方法允許哪些型別的訊息。
Magic Cookie欄位包含固定值0x2112A442，這是為了前向相容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頭部。由於所有的STUN屬性都是都是4位元組對齊（填充）的，
因此這個欄位最後兩位應該恆等於零，這也是辨別STUN包的一個方法之一。
STUN屬性
在STUN報文頭部之後，通常跟著0個或者多個屬性，每個屬性必須是TLV編碼的（Type-Length-Value）。其中Type欄位和Length欄位都是16位，
Value欄位為為32位表示，如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length欄位必須包含Value部分需要補齊的長度，以位元組為單位。由於STUN屬性以32bit邊界對齊，因此屬性內容不足4位元組的都會以padding bit進行補齊。
padding bit會被忽略，但可以是任何值。
Type欄位為屬性的型別。任何屬性型別都有可能在一個STUN報文中出現超過一次。除非特殊指定，否則其出現的順序是有意義的：
即只有第一次出現的屬性會被接收端解析，而其餘的將被忽略。為了以後版本的擴充和改進，屬性區域被分為兩個部分。
Type值在0x0000-0x7FFF之間的屬性被指定為強制理解，意思是STUN終端必須要理解此屬性，否則將返回錯誤資訊；而0x8000-0xFFFF
之間的屬性為選擇性理解，即如果STUN終端不識別此屬性則將其忽略。目前STUN的屬性型別由IANA維護。
這裡簡要介紹幾個常見屬性的Value結構：
- MAPPED-ADDRESS
MAPPED-ADDRESS同時也是classic STUN的一個屬性，之所以還存在也是為了前向相容。其包含了NAT客戶端的反射地址，
Family為IP型別，即IPV4(0x01)或IPV6(0x02)，Port為埠，Address為32位或128位的IP地址。注意高8位必須全部置零，
而且接收端必須要將其忽略掉。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Family | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address (32 bits or 128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- XOR-MAPPED-ADDRESS
XOR-MAPPED-ADDRESS和MAPPED-ADDRESS基本相同，不同點是反射地址部分經過了一次異或（XOR）處理。對於X-Port欄位，
是將NAT的對映埠以小端形式與magic cookie的高16位進行異或，再將結果轉換成大端形式而得到的，X-Address也是類似。
之所以要經過這麼一次轉換，是因為在實踐中發現很多NAT會修改payload中自身公網IP的32位資料，從而導致NAT打洞失敗。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x| Family | X-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X-Address (Variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ERROR-CODE
ERROR-CODE屬性用於error response報文中。其包含了300-699表示的錯誤程式碼，以及一個UTF-8格式的文字出錯資訊（Reason Phrase）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved, should be 0 |Class| Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase (variable) ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+另外，錯誤程式碼在語義上還與SIP和HTTP協議保持一致。比如：
300：嘗試代替(Try Alternate)，客戶端應該使用該請求聯絡一個代替的伺服器。這個錯誤響應僅在請求包括一個USERNAME屬性和一個有效的MESSAGE-INTEGRITY屬性時傳送；否則它不會被髮送，而是傳送錯誤程式碼為400的錯誤響應；
400：錯誤請求(Bad Request)，請求變形了，客戶端在修改先前的嘗試前不應該重試該請求。
401：未授權(Unauthorized)，請求未包括正確的資格來繼續。客戶端應該採用一個合適的資格來重試該請求。
420：未知屬性(Unknown Attribute)，伺服器收到一個STUN包包含一個強制理解的屬性但是它不會理解。
伺服器必須將不認識的屬性放在錯誤響應的UNKNOWN-ATTRIBUTE屬性中。
438：過期Nonce(Stale Nonce)，客戶端使用的Nonce不再有效，應該使用響應中提供的Nonce來重試。
500：伺服器錯誤(Server Error)，伺服器遇到臨時錯誤，客戶端應該再次嘗試。
此外還有很多屬性，如USERNAME，NONCE，REALM，SOFTWARE等，具體可以翻閱RFC3489。
STUN 通訊過程
1. 產生一個Request或Indication
當產生一個Request或者Indication報文時，終端必須根據上文提到的規則來生成頭部，class欄位必須是Request或者Indication，
而method欄位為Binding或者其他使用者擴充的方法。屬性部分選擇該方法所需要的對應屬性，比如在一些
情景下我們會需要authenticaton屬性或FINGERPRINT屬性，注意在傳送Request報文時候，需要加上SOFTWARE屬性（內含軟體版本描述）。
2. 傳送Requst或Indication
目前，STUN報文可以通過UDP，TCP以及TLS-over-TCP的方法傳送，其他方法在以後也會新增進來。STUN的使用者必須指定其使用的傳輸協議，
以及終端確定接收端IP地址和埠的方式，比如通過基於DNS的方法來確定伺服器的IP和埠。
2.1 通過UDP傳送
當使用UDP協議執行STUN時，STUN的報文可能會由於網路問題而丟失。可靠的STUN請求/響應傳輸是通過客戶端重發request請求來實現的，
因此，在UDP執行時，Indication報文是不可靠的。STUN客戶端通過RTO（Retransmission TimeOut）
來決定是否重傳Requst，並且在每次重傳後將RTO翻倍。具體重傳時間的選取可以參考相關文章，如RFC2988。
重傳直到接收到Response才停止，或者重傳次數到達指定次數Rc，Rc應該是可配置的，且預設值為7。
2.2 通過TCP或者TCP-over-TLS傳送
對於這種情景，客戶端開啟對伺服器的連線。在某些情況下，此TCP連結只傳輸STUN報文，而在其他擴充中，
在一個TCP連結裡可能STUN報文和其他協議的報文會進行多路複用（Multiplexed）。資料傳輸的可靠性由TCP協議本身來保證。
值得一提的是，在一次TCP連線中，STUN客戶端可能發起多個傳輸，有可能在前一個Request的Response還沒收到時就再次傳送了一個新的Request，
因此客戶端應該保持TCP連結開啟，認所有STUN事務都已完成。
3. 接收STUN訊息
當STUN終端接收到一個STUN報文時，首先檢查報文的規則是否合法，即前兩位是否為0，magic cookie是否為0x2112A442，報文長度是否正確以及對應的方法是否支援。
如果訊息類別為Success/Error Response，終端會檢測其事務ID是否與當前正在處理的事務ID相同。如果使用了FINGERPRINT擴充的話還會檢查FINGERPRINT屬性是否正確。
完成身份認證檢查之後，STUN終端會接著檢查其餘未知屬性。
3.1 處理Request
如果請求包含一個或者多個強制理解的未知屬性，接收端會返回error response，錯誤程式碼420（ERROR-CODE屬性），
而且包含一個UNKNOWN-ATTRIBUTES屬性來告知傳送方哪些強制理解的屬性是未知的。服務端接著檢查方法和其他指定要求，如果所有檢查都成功，
則會產生一個Success Response給客戶端。
3.1.1 生成Success Response或Error Response
- 如果伺服器通過某種
驗證方法（authentication mechanism）通過了請求方的驗證，那麼在響應報文裡最好也加上對應的驗證屬性。 - 伺服器端也應該加上指定方法所需要的屬性資訊，另外協議建議伺服器返回時也加上SOFTWARE屬性。
- 對於Binding方法，除非特別指明，一般不要求進行額外的檢查。當生成Success Response時，伺服器在響應里加上XOR-MAPPED-ADDRESS屬性。
對於UDP，這是其源IP和埠資訊，對於TCP或TLS-over-TCP，這就是伺服器端所看見的此次TCP連線的源IP和埠。
- 如果伺服器通過某種
3.1.2 傳送Success Response或Error Response
- 傳送響應時候如果是用UDP協議，則發往其源IP和埠，如果是TCP則直接用相同的TCP連結回發即可。
3.2 處理Indication
如果Indication報文包含未知的強制理解屬性，則此報文會被接收端忽略並丟棄。如果對Indication報文的檢查都沒有錯誤，則服務端會進行相應的處理，
但是不會返回Response。對於Binding方法，一般不需要額外的檢查或處理。收到資訊的服務端僅需要重新整理對應NAT的埠繫結。
由於Indication報文在用UDP協議傳輸時不會進行重傳，因此傳送方也不需要處理重傳的情況。
3.3 處理Success Response
如果Success Response包含了未知的強制理解屬性，則響應會被忽略並且認為此次傳輸失敗。客戶端對報文進行檢查通過之後，就可以開始處理此次報文。
以Binding方法為例，客戶端會檢查報文中是否包含XOR-MAPPED-ADDRESS屬性，然後是地址型別，如果是不支援的地址型別，則這個屬性會被忽略掉。
3.4 處理Error Response
如果Error Response包含了未知的強制理解屬性，或者沒有包含ERROR-CODE屬性，則響應會被忽略並且認為此次傳輸失敗。
隨後客戶端會對驗證方法進行處理，這有可能會產生新的傳輸。
到目前為止，對錯誤響應的處理主要基於ERROR-CODE屬性的值，並遵循如下規則：
- 如果error code在300到399之間，客戶端被建議認為此次傳輸失敗，除非用了ALTERNATE-SERVER擴充；
- 如果error code在400到499之間，客戶端認為此次傳輸失敗；
- 如果error code在500到599之間，客戶端可能會需要重傳請求，並且必須限制重傳的次數。
任何其他的error code值都會導致客戶端認為此次傳輸失敗。
後記
上面只是介紹了STUN/RFC5389協議的基礎部分，協議本身還包含了許多mechanism，如身份驗證（Authentication），DNS Discovery，FINGERPRINT Mechanisms，
ALTERNATE-SERVER Mechanism等，身份驗證又分為長期驗證和短期驗證，從而保證了傳輸的靈活性並減少伺服器的負擔。具體可以詳細閱讀白皮書。
我本來打算一篇文章把P2P通訊的所有協議都介紹完不過現在看來似乎篇幅過長了，所以關於TURN和ICE就放在下一篇介紹好了。
另外由於SourceForge的StunServer的原始碼已經長期不更新，因此我從svn的倉庫中整理了一下放到了GitHub上面，
需要的可以自行去取來參考一下STUN互動的實現，當然了雖然實現的是TurnServer，但除了Relay部分基本上都是和STUN類似的。
另外在P2P原理與實現所做的一個P2P聊天應用時, 順便也做了個基於RFC3489的STUN客戶端, 基於Python3,
用於檢測使用者的NAT型別, 可以參見p2p-over-middleboxes.