NAT

IPv4地址只有32位，最多只能提供大致42.9億個唯一IP地址，當設備越來越多時，IP地址變得越來越稀缺，不能為每個設備都分配一個IP地址。于是，作為NAT規(guī)范就出現(xiàn)了。NAT（Network Address Translation，網(wǎng)絡地址轉(zhuǎn)換）是1994年提出的，其當在專用網(wǎng)內(nèi)部的一些主機本來已經(jīng)分配到了本地IP地址（即僅在本專用網(wǎng)內(nèi)使用的專用地址），但現(xiàn)在又想和因特網(wǎng)上的主機通信（并不需要加密）時，可使用NAT方法。每個NAT設備負責維護一個包含本地IP、端口和外網(wǎng)IP、端口的映射表。所有使用本地地址的主機在和外界通信時，都要在NAT路由器上將其本地地址轉(zhuǎn)換成全球IP地址，才能和因特網(wǎng)連接。其大致過程如下：

NAT的實現(xiàn)方式有如下三種，即：

靜態(tài)轉(zhuǎn)換(Static NAT)：將內(nèi)部網(wǎng)絡的私有IP地址轉(zhuǎn)換為公有IP地址，IP地址對是一對一的，是一成不變的，某個私有IP地址只轉(zhuǎn)換為某個公有IP地址；

動態(tài)轉(zhuǎn)換(Dynamic NAT)：將內(nèi)部網(wǎng)絡的私有IP地址轉(zhuǎn)換為公用IP地址時，IP地址是不確定的，是隨機的，所有被授權(quán)訪問上Internet的私有IP地址可隨機轉(zhuǎn)換為任何指定的合法IP地址，當ISP提供的合法IP地址略少于網(wǎng)絡內(nèi)部的計算機數(shù)量時?？梢圆捎脛討B(tài)轉(zhuǎn)換的方式；

端口多路復用(Port NAT)：改變外出數(shù)據(jù)包的源端口并進行端口轉(zhuǎn)換，即端口地址轉(zhuǎn)換。采用端口多路復用方式，內(nèi)部網(wǎng)絡的所有主機均可共享一個合法外部IP地址實現(xiàn)對Internet的訪問，從而可以最大限度地節(jié)約IP地址資源。同時，又可隱藏網(wǎng)絡內(nèi)部的所有主機，有效避免來自internet的攻擊。因此，目前網(wǎng)絡中應用最多的就是端口多路復用方式。

UDP連接狀態(tài)超時

目前，很多網(wǎng)絡都使用了NAT技術(shù)，而NAT需要保存數(shù)據(jù)傳輸?shù)穆酚杀聿拍芡瓿晒ぷ?。每個TCP連接有一個明確的協(xié)議狀態(tài)機，開始三次握手，跟著開始數(shù)據(jù)傳輸，最后關(guān)閉連接，有一個完整的流程?；谶@種流程，NAT可以觀察到每個連接狀態(tài)，并可以根據(jù)需要創(chuàng)建和刪除的路由條目。

然而，UDP是面向無連接的，僅僅只往外發(fā)送一個帶有載荷的數(shù)據(jù)報就不再關(guān)心其他額外的事情了，但路由響應卻需要能從轉(zhuǎn)換表找到本地主機IP和端口，只有如此才能完成數(shù)據(jù)的傳輸。UDP既沒有握手，也沒有連接終止，同時沒有任何狀態(tài)機來監(jiān)控連接狀態(tài)。轉(zhuǎn)換器需要保存每個UDP流的狀態(tài)，進而維護轉(zhuǎn)換表，然而UDP實際上卻是無狀態(tài)的，僅僅只是一個數(shù)據(jù)報而已，沒有提前協(xié)商報文，也沒有結(jié)束狀態(tài)。由于UDP沒有連接終止通告，任何時候，兩端都可以停止發(fā)送數(shù)據(jù)包，不帶任何通知，就對為維護轉(zhuǎn)換表帶來了極大的挑戰(zhàn)，因為轉(zhuǎn)換表大多數(shù)時候都是動態(tài)更新的。為了解決這個問題，UDP路由記錄會設置一個定時器進行定時過期，這個時間的設置取決于設備提供商，版本，配置等。因此，有一個事實上的最佳做是引入雙向 keepalive報文，周期性的重置路由上所有的NAT設備轉(zhuǎn)換記錄計時器。

NAT穿透

不可預知的連接狀態(tài)管理是NAT的一個嚴重問題，但對于許多應用程序的一個更大的問題是根本無法建立UDP連接。這對很多應用譬如P2P，如VoIP、游戲、文件共享等，這些應用往往通信雙方的角色需要轉(zhuǎn)換，以實現(xiàn)雙向通信。

NAT帶來的第一個問題是，內(nèi)部客戶端不知道它的外網(wǎng)IP??，只知道它的內(nèi)部IP，NAT設備負責對UDP數(shù)據(jù)報進行重寫，修改UDP包的源端口和地址，以及IP分組中的源IP地址。如果客戶端使用內(nèi)網(wǎng)IP地址與外網(wǎng)主機進行通信，那么連接將不可避免地失敗。因此，NAT這種“透明”的轉(zhuǎn)換就有問題了，如果它需要與外網(wǎng)中的主機進行通信，應用程序必須先知道自己的外網(wǎng)IP??地址。

然而，僅僅知道的自己的外網(wǎng)IP依然是無法保證UDP傳輸成功的。任何數(shù)據(jù)包到達擁有外網(wǎng)IP的NAT設備后??，還需要??有一個目的端口，才能從NAT轉(zhuǎn)換表中找到對應的內(nèi)網(wǎng)IP和端口，這樣數(shù)據(jù)才能真正達到目的地址。如果不能在轉(zhuǎn)換表中找到對應的映射，那么數(shù)據(jù)報就被直接丟棄。也就是說NAT作為一個簡單的包過濾器，只有在轉(zhuǎn)換表中找到對應的路由，才能完成信息傳遞，否則就會不能成功傳輸數(shù)據(jù)。

如果隔著NAT設備，那種客戶端（內(nèi)網(wǎng)主機作為服務器）處理來自P2P應用（如VoIP，游戲終端，文件共享等）的入站連接時，就需要面對NAT穿透問題。為了解決這種UDP穿透問題，很多穿越技術(shù)（STUN，TURN，ICE）被提出了，用于在UDP主機之間建立端至端的連接。

STUN

STUN(Simple Traversal Utilities forNAT)協(xié)議允許讓位于內(nèi)網(wǎng)的客戶端發(fā)現(xiàn)網(wǎng)絡中的地址轉(zhuǎn)換器，進而找到NAT為自己配置的外網(wǎng)IP和端口。要想實現(xiàn)這種功能，還需要一個已知的第三方STUN服務器支持，示意圖如下：

假設STUN服務器的IP地址是可知的（通過DNS或手動指定），客戶端首先發(fā)送綁定請求到STUN服務器。相應的，STUN服務器回復一個響應，其中包含為客戶端分配的外網(wǎng)IP??和端口。這個簡單的流程解決我們了我們前面討論中遇到的幾個問題：

客戶端可以知道自己的外網(wǎng)IP和端口，使用這些信息就能夠與對端進行通信；

向STUN服務器發(fā)送的請求，也同時在NAT上建立了路由映射記錄，這確保了外部主機的請求可以發(fā)送到內(nèi)部網(wǎng)絡中的客戶端；

STUN協(xié)議定義了一個簡單keep-alive探測機制來保證NAT上的路由不超時。

有了這個機制，兩端需要通過UDP進行通信時，它們會先發(fā)送綁定請求到各自的STUN服務器，收到各自STUN服務器的響應，然后分別使用各自的外網(wǎng)IP和端口進行通信。然而，在實際應用中，STUN是不足以處理所有的NAT的拓撲結(jié)構(gòu)和網(wǎng)絡配置。在某些情況下，UDP可能會被防火墻或其他一些網(wǎng)絡設備完全阻止 ，為了解決這個問題，我們還可以使用TURN協(xié)議作為備用方案，它可以運行在UDP上，在最壞的情況下還可以將UDP轉(zhuǎn)換成TCP。

TURN

TURN(Traversal Using Relays around NAT)通過Relay方式穿越NAT，TURN應用模型通過分配TURNServer的地址和端口作為客戶端對外的接受地址和端口，即私網(wǎng)用戶發(fā)出的報文都要經(jīng)過TURNServer進行Relay轉(zhuǎn)發(fā)，在報文負載中所描述的地址信息直接填寫TURNServer地址的方式進行通信。示意圖如下所示：

當然，這種通信方式的最明顯的缺點就是它不再是P2P的通信。他需要依賴于TURN服務器來保證可靠的傳輸，TURN服務器就成為了一個瓶頸，維護TURN的成本將很高，至少TURN服務器需要足夠的帶寬來保證所有的數(shù)據(jù)流。因此，TURN方案最好作為最后的備用方案，只有在其他方案都失效的情況下才能使用。

在現(xiàn)實場景中，NAT設備很多，相當一部分用戶不能通過STUN直接建立p2p連接，如果想提供可靠的UDP服務，還需要同時支持STUN與TURN。

ICE

建立一個有效的NAT穿越解決方案，不是一件簡單容易的事情。值得慶幸的是，我們可以借助ICE協(xié)議來幫助我們完成這一任務。ICE是一個協(xié)議，和一組方法，用來尋求最有效的端與端之間隧道建立方法：如果可能則直接連接，如果不行則通過STUN進行協(xié)商，如果都失敗了則采取TURN。示意圖如下：

UDP相比于TCP最大的特征正是它忽略了的功能：連接狀態(tài)、握手、重發(fā)、重組、重排、擁塞控制、擁塞預防、流量控制，甚至可選的錯誤檢查。任何事情都是有利有弊的，在忽略了這么多特性之后，這個面向消息的傳輸層能提供了很大的靈活性，當然也為實現(xiàn)者帶來了一些麻煩。客戶端的應用程序可能從頭開始重新實現(xiàn)部分或者大部分缺失的特性，而且每項功能的實現(xiàn)都得保證與網(wǎng)絡中其他主機與協(xié)議和諧共生。
與TCP不同，內(nèi)置了流量和擁塞控制、擁塞避免機制，UDP應用程序必須自己實現(xiàn)這些機制。擁塞不敏感的UDP應用程序可以很容易的擁塞網(wǎng)絡，可能會導致網(wǎng)絡性能降低，在嚴重的情況下，會導致網(wǎng)絡擁塞崩潰。如果想在自己的應用程序中使用UDP，一定要認真研究和學習當下的最佳實踐和建議。RFEC5405對設計單播UDP應用程序給了很多建議，簡述如下：

• 應用必須忍受變化的互聯(lián)網(wǎng)路徑；
• 應用應控制傳輸速率；
• 應用應當實現(xiàn)所有流量擁塞控制；
• 應用應該使用和TCP同等的帶寬；
• 應用當丟包時應該回退重傳計數(shù)器；
• 應用不應該發(fā)送超過MTU的數(shù)據(jù)報；
• 應用應該處理數(shù)據(jù)報的丟失，重復，重新排序；
• 應用應該是確?？梢灾С謨煞昼姷难舆t；
• 應用應該啟用IPv4 UDP校驗，必須啟用IPv6校驗；
• 應用可能在需要的時候使用保活（最小間隔15秒）。

隨著WebRTC規(guī)范的提出，WebRTC為瀏覽器提供了新的能力，相信UDP會變得越來越重要！
編輯：hfy