NAT

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

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

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

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

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

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

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

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

NAT穿透

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

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

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

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

STUN

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

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

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

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

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

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

TURN

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

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

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

ICE

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

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

• 應(yīng)用必須忍受變化的互聯(lián)網(wǎng)路徑；
• 應(yīng)用應(yīng)控制傳輸速率；
• 應(yīng)用應(yīng)當(dāng)實現(xiàn)所有流量擁塞控制；
• 應(yīng)用應(yīng)該使用和TCP同等的帶寬；
• 應(yīng)用當(dāng)丟包時應(yīng)該回退重傳計數(shù)器；
• 應(yīng)用不應(yīng)該發(fā)送超過MTU的數(shù)據(jù)報；
• 應(yīng)用應(yīng)該處理數(shù)據(jù)報的丟失，重復(fù)，重新排序；
• 應(yīng)用應(yīng)該是確保可以支持兩分鐘的延遲；
• 應(yīng)用應(yīng)該啟用IPv4 UDP校驗，必須啟用IPv6校驗；
• 應(yīng)用可能在需要的時候使用?；睿ㄗ钚￠g隔15秒）。

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