NAT

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

NAT的實現方式有如下三種，即：

靜態轉換(Static NAT)：將內部網絡的私有IP地址轉換為公有IP地址，IP地址對是一對一的，是一成不變的，某個私有IP地址只轉換為某個公有IP地址；

動態轉換(Dynamic NAT)：將內部網絡的私有IP地址轉換為公用IP地址時，IP地址是不確定的，是隨機的，所有被授權訪問上Internet的私有IP地址可隨機轉換為任何指定的合法IP地址，當ISP提供的合法IP地址略少于網絡內部的計算機數量時。可以采用動態轉換的方式；

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

UDP連接狀態超時

目前，很多網絡都使用了NAT技術，而NAT需要保存數據傳輸的路由表才能完成工作。每個TCP連接有一個明確的協議狀態機，開始三次握手，跟著開始數據傳輸，最后關閉連接，有一個完整的流程?；谶@種流程，NAT可以觀察到每個連接狀態，并可以根據需要創建和刪除的路由條目。

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

NAT穿透

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

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

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

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

STUN

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

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

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

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

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

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

TURN

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

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

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

ICE

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

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

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

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