P2P技術詳解(一):NAT詳解——詳細原理、P2P簡介(轉)

giserinchina發表於2018-09-17

這是一篇介紹NAT技術要點的精華文章,來自華3通訊官方資料庫,文中對NAT技術原理的介紹很全面也很權威,對網路應用的應用層開發人員而言有很高的參考價值。

 

《P2P技術詳解》系列文章


➊ 本文是《P2P理論詳解》系列文章中的第2篇,總目錄如下:
 
➋ P2P相關的其它資源:
 
另外,如果你覺得本文對網路通訊的基礎知識講的不夠系統話,可繼續看看下面這些精華文章大餐。

➊ 網路程式設計基礎知識:
 
➋ 如果覺得上面的文章枯燥,則《網路程式設計懶人入門》系列可能是你的菜:
 
➌ 如果感到自已已經很牛逼了,《不為人知的網路程式設計》應該是你菜:
 
➍ 如果看完上面的文章還是躁動不安,那看看《高效能網路程式設計系列》吧:
 

1. IPv4協議和NAT的由來


今天,無數快樂的網際網路使用者在盡情享受Internet帶來的樂趣。他們瀏覽新聞,搜尋資料,下載軟體,廣交新朋,分享資訊,甚至於足不出戶獲取一切日用所需。企業利用網際網路釋出資訊,傳遞資料和訂單,提供技術支援,完成日常辦公。然而,Internet在給億萬使用者帶來便利的同時,自身卻面臨一個致命的問題:構建這個無所不能的Internet的基礎IPv4協議已經不能再提供新的網路地址了。

2011年2月3日中國農曆新年, IANA對外宣佈:IPv4地址空間最後5個地址塊已經被分配給下屬的5個地區委員會。2011年4月15日,亞太區委員會APNIC對外宣佈,除了個別保留地址外,本區域所有的IPv4地址基本耗盡。一時之間,IPv4地址作為一種瀕危資源身價陡增,各大網路公司出巨資收購剩餘的空閒地址。其實,IPv4地址不足問題已不是新問題,早在20年以前,IPv4地址即將耗盡的問題就已經擺在Internet先驅們面前。這不禁讓我們想去了解,是什麼技術使這一危機延緩了盡20年。

要找到問題的答案,讓我們先來簡略回顧一下IPv4協議。

IPv4即網際網協議第4版——Internet Protocol Version 4的縮寫。IPv4定義一個跨越異種網路互連的超級網,它為每個網際網的節點分配全球唯一IP地址。如果我們把Internet比作一個郵政系統,那麼IP地址的作用就等同於包含城市、街區、門牌編號在內的完整地址。IPv4使用32bits整數表達一個地址,地址最大範圍就是232 約為43億。以IP創始時期可被聯網的裝置來看,這樣的一個空間已經很大,很難被短時間用完。然而,事實遠遠超出人們的設想,計算機網路在此後的幾十年裡迅速壯大,網路終端數量呈爆炸性增長。

更為糟糕的是,為了路由和管理方便,43億的地址空間被按照不同字首長度劃分為A,B,C,D類地址網路和保留地址。其中,A類網路地址127段,每段包括主機地址約1678萬個。B類網路地址16384段,每段包括65536個主機地址。

P2P技術詳解(一):NAT詳解——詳細原理、P2P簡介_圖1 IPv4網路地址劃分 
圖1 IPv4網路地址劃分

IANA向超大型企業/組織分配A類網路地址,一次一段。向中型企業或教育機構分配B類網路地址,一次一段。這樣一種分配策略使得IP地址浪費很嚴重,很多被分配出去的地址沒有真實被利用,地址消耗很快。以至於二十世紀90年代初,網路專家們意識到,這樣大手大腳下去,IPv4地址很快就要耗光了。於是,人們開始考慮IPv4的替代方案,同時採取一系列的措施來減緩IPv4地址的消耗。正是在這樣一個背景之下,本期的主角閃亮登場,它就是網路地址轉換——NAT。

NAT是一項神奇的技術,說它神奇在於它的出現幾乎使IPv4起死回生。在IPv4已經被認為行將結束歷史使命之後近20年時間裡,人們幾乎忘了IPv4的地址空間即將耗盡這樣一個事實——在新技術日新月異的時代,20年可算一段漫長的歷史。更不用說,在NAT產生以後,網路終端的數量呈加速上升趨勢,對IP地址的需求劇烈增加。此足見NAT技術之成功,影響之深遠。

說它神奇,更因為NAT給IP網路模型帶來了深遠影響,其身影遍佈網路每個角落。根據一份最近的研究報告,70%的P2P使用者位於NAT閘道器以內。因為P2P主要執行在終端使用者的個人電腦之上,這個數字意味著大多數PC通過NAT閘道器連線到Internet。如果加上2G和3G方式聯網的智慧手機等移動終端,在NAT閘道器之後的使用者遠遠超過這個比例。

然而當我們求本溯源時卻發現一個很奇怪的事實:NAT這一意義重大的技術,竟然沒有公認的發明者。NAT第一個版本的RFC作者,只是整理歸納了已被廣泛採用的技術。

2. NAT的工作模型和特點

 

2.1 NAT的概念模型


NAT名字很準確,網路地址轉換,就是替換IP報文頭部的地址資訊。NAT通常部署在一個組織的網路出口位置,通過將內部網路IP地址替換為出口的IP地址提供公網可達性和上層協議的連線能力。那麼,什麼是內部網路IP地址?

RFC1918規定了三個保留地址段落:10.0.0.0-10.255.255.255;172.16.0.0-172.31.255.255;192.168.0.0-192.168.255.255。這三個範圍分別處於A,B,C類的地址段,不向特定的使用者分配,被IANA作為私有地址保留。這些地址可以在任何組織或企業內部使用,和其他Internet地址的區別就是,僅能在內部使用,不能作為全球路由地址。這就是說,出了組織的管理範圍這些地址就不再有意義,無論是作為源地址,還是目的地址。對於一個封閉的組織,如果其網路不連線到Internet,就可以使用這些地址而不用向IANA提出申請,而在內部的路由管理和報文傳遞方式與其他網路沒有差異。

對於有Internet訪問需求而內部又使用私有地址的網路,就要在組織的出口位置部署NAT閘道器,在報文離開私網進入Internet時,將源IP替換為公網地址,通常是出口裝置的介面地址。一個對外的訪問請求在到達目標以後,表現為由本組織出口裝置發起,因此被請求的服務端可將響應由Internet發回出口閘道器。出口閘道器再將目的地址替換為私網的源主機地址,發回內部。這樣一次由私網主機向公網服務端的請求和響應就在通訊兩端均無感知的情況下完成了。依據這種模型,數量龐大的內網主機就不再需要公有IP地址了。

P2P技術詳解(一):NAT詳解——詳細原理、P2P簡介_圖2 NAT轉換過程示意圖 
圖2 NAT轉換過程示意圖

雖然實際過程遠比這個複雜,但上面的描述概括了NAT處理報文的幾個關鍵特點:

1. 網路被分為私網和公網兩個部分,NAT閘道器設定在私網到公網的路由出口位置,雙向流量必須都要經過NAT閘道器;
2. 網路訪問只能先由私網側發起,公網無法主動訪問私網主機; 
3. NAT閘道器在兩個訪問方向上完成兩次地址的轉換或翻譯,出方向做源資訊替換,入方向做目的資訊替換; 
4. NAT閘道器的存在對通訊雙方是保持透明的; 
5. NAT閘道器為了實現雙向翻譯的功能,需要維護一張關聯表,把會話的資訊儲存下來。


隨著後面對NAT的深入描述,讀者會發現,這些特點是鮮明的,但又不是絕對的。其中第二個特點打破了IP協議架構中所有節點在通訊中的對等地位,這是NAT最大的弊端,為對等通訊帶來了諸多問題,當然相應的克服手段也應運而生。事實上,第四點是NAT致力於達到的目標,但在很多情況下,NAT並沒有做到,因為除了IP首部,上層通訊協議經常在內部攜帶IP地址資訊。這些我們稍後解釋。

2.2 一對一的NAT


如果一個內部主機唯一佔用一個公網IP,這種方式被稱為一對一模型。此種方式下,轉換上層協議就是不必要的,因為一個公網IP就能唯一對應一個內部主機。顯然,這種方式對節約公網IP沒有太大意義,主要是為了實現一些特殊的組網需求。比如使用者希望隱藏內部主機的真實IP,或者實現兩個IP地址重疊網路的通訊。

2.3 一對多的NAT


NAT最典型的應用場景就如同圖2描述的,一個組織網路,在出口位置部署NAT閘道器,所有對公網的訪問表現為一臺主機。這就是所謂的一對多模型。這種方式下,出口裝置只佔用一個由Internet服務提供商分配的公網IP地址。面對私網內部數量龐大的主機,如果NAT只進行IP地址的簡單替換,就會產生一個問題:當有多個內部主機去訪問同一個伺服器時,從返回的資訊不足以區分響應應該轉發到哪個內部主機。此時,需要NAT裝置根據傳輸層資訊或其他上層協議去區分不同的會話,並且可能要對上層協議的標識進行轉換,比如TCP或UDP埠號。這樣NAT閘道器就可以將不同的內部連線訪問對映到同一公網IP的不同傳輸層埠,通過這種方式實現公網IP的複用和解複用。這種方式也被稱為埠轉換PAT、NAPT或IP偽裝,但更多時候直接被稱為NAT,因為它是最典型的一種應用模式。

2.4 按照NAT埠對映方式分類


在一對多模型中,按照埠轉換的工作方式不同,又可以進行更進一步的劃分。為描述方便,以下將IP和埠標記為(nAddr:nPort),其中n代表主機或NAT閘道器的不同角色。

P2P技術詳解(一):NAT詳解——詳細原理、P2P簡介_ 圖3 按照埠轉換對映方式分類 
圖3 按照埠轉換對映方式分類

    全錐形NAT
其特點為:一旦內部主機埠對(iAddr:iPort)被NAT閘道器對映到(eAddr:ePort),所有後續的(iAddr:iPort)報文都會被轉換為(eAddr:ePort);任何一個外部主機傳送到(eAddr:ePort)的報文將會被轉換後發到(iAddr:iPort)。

    限制錐形NAT
其特點為:一旦內部主機埠對(iAddr:iPort)被對映到(eAddr:ePort),所有後續的(iAddr:iPort)報文都會被轉換為(eAddr:ePort);只有 (iAddr:iPort)向特定的外部主機hAddr傳送過資料,主機hAddr從任意埠傳送到(eAddr:ePort)的報文將會被轉發到(iAddr:iPort)。

    埠限制錐形NAT
其特點為:一旦內部主機埠對(iAddr:iPort)被對映到(eAddr:ePort),所有後續的(iAddr:iPort)報文都會被轉換為(eAddr:ePort);只有(iAddr:iPort)向特定的外部主機埠對(hAddr:hPort)傳送過資料,由 (hAddr:hPort)傳送到(eAddr:ePort)的報文將會被轉發到(iAddr:iPort)。

    對稱型NAT
其特點為:NAT閘道器會把內部主機“地址埠對”和外部主機“地址埠對”完全相同的報文看作一個連線,在閘道器上建立一個公網“地址埠對”對映進行轉換,只有收到報文的外部主機從對應的埠對傳送回應的報文,才能被轉換。即使內部主機使用之前用過的地址埠對去連線不同外部主機(或埠)時,NAT閘道器也會建立新的對映關係。

事實上,這些術語的引入是很多混淆的起源。現實中的很多NAT裝置是將這些轉換方式混合在一起工作的,而不單單使用一種,所以這些術語只適合描述一種工作方式,而不是一個裝置。比如,很多NAT裝置對內部發出的連線使用對稱型NAT方式,而同時支援靜態的埠對映,後者可以被看作是全錐型NAT方式。而有些情況下,NAT裝置的一個公網地址和埠可以同時對映到內部幾個伺服器上以實現負載分擔,比如一個對外提供WEB伺服器的站點可能是有成百上千個伺服器在提供HTTP服務,但是對外卻表現為一個或少數幾個IP地址。

3. NAT的限制與解決方案

 

3.1 IP端到端服務模型


IP協議的一個重要貢獻是把世界變得平等。在理論上,具有IP地址的每個站點在協議層面有相當的獲取服務和提供服務的能力,不同的IP地址之間沒有差異。人們熟知的伺服器和客戶機實際是在應用協議層上的角色區分,而在網路層和傳輸層沒有差異。一個具有IP地址的主機既可以是客戶機,也可以是伺服器,大部分情況下,既是客戶機,也是伺服器。端到端對等看起來是很平常的事情,而意義並不尋常。但在以往的技術中,很多協議體系下的網路限定了終端的能力。正是IP的這個開放性,使得TCP/IP協議族可以提供豐富的功能,為應用實現提供了廣闊平臺。因為所有的IP主機都可以伺服器的形式出現,所以通訊設計可以更加靈活。使用UNIX/LINUX的系統充分利用了這個特性,使得任何一個主機都可以建立自己的HTTP、SMTP、POP3、DNS、DHCP等服務。與此同時,很多應用也是把客戶端和伺服器的角色組合起來完成功能。例如在VoIP應用中,使用者端向註冊伺服器登入自己的IP地址和埠資訊過程中,主機是客戶端;而在呼叫到達時,呼叫處理伺服器向使用者端傳送呼叫請求時,使用者端實際工作在伺服器模式下。在語音媒體流通道建立過程後,通訊雙向傳送語音資料,傳送端是客戶模式,接收端是伺服器模式。而在P2P的應用中,一個使用者的主機既為下載的客戶,同時也向其他客戶提供資料,是一種C/S混合的模型。上層應用之所以能這樣設計,是因為IP協議棧定義了這樣的能力。試想一下,如果IP提供的能力不對等,那麼每個通訊會話都只能是單方向發起的,這會極大限制通訊的能力。細心的讀者會發現,前面介紹NAT的一個特性正是這樣一種限制。沒錯,NAT最大的弊端正在於此——破壞了IP端到端通訊的能力。

3.2 NAT的弊端


NAT在解決IPv4地址短缺問題上,並非沒有副作用,其實存在很多問題。

首先,NAT使IP會話的保持時效變短。因為一個會話建立後會在NAT裝置上建立一個關聯表,在會話靜默的這段時間,NAT閘道器會進行老化操作。這是任何一個NAT閘道器必須做的事情,因為IP和埠資源有限,通訊的需求無限,所以必須在會話結束後回收資源。通常TCP會話通過協商的方式主動關閉連線,NAT閘道器可以跟蹤這些報文,但總是存在例外的情況,要依賴自己的定時器去回收資源。而基於UDP的通訊協議很難確定何時通訊結束,所以NAT閘道器主要依賴超時機制回收外部埠。通過定時器老化回收會帶來一個問題,如果應用需要維持連線的時間大於NAT閘道器的設定,通訊就會意外中斷。因為閘道器回收相關轉換表資源以後,新的資料到達時就找不到相關的轉換資訊,必須建立新的連線。當這個新資料是由公網側向私網側傳送時,就會發生無法觸發新連線建立,也不能通知到私網側的主機去重建連線的情況。這時候通訊就會中斷,不能自動恢復。即使新資料是從私網側發向公網側,因為重建的會話表往往使用不同於之前的公網IP和埠地址,公網側主機也無法對應到之前的通訊上,導致使用者可感知的連線中斷。NAT閘道器要把回收空閒連線的時間設定到不發生持續的資源流失,又維持大部分連線不被意外中斷,是一件比較有難度的事情。在NAT已經普及化的時代,很多應用協議的設計者已經考慮到了這種情況,所以一般會設定一個連線保活的機制,即在一段時間沒有資料需要傳送時,主動傳送一個NAT能感知到而又沒有實際資料的保活訊息,這麼做的主要目的就是重置NAT的會話定時器。

其次,NAT在實現上將多個內部主機發出的連線複用到一個IP上,這就使依賴IP進行主機跟蹤的機制都失效了。如網路管理中需要的基於網路流量分析的應用無法跟蹤到終端使用者與流量的具體行為的關係。基於使用者行為的日誌分析也變得困難,因為一個IP被很多使用者共享,如果存在惡意的使用者行為,很難定位到發起連線的那個主機。即便有一些機制提供了在NAT閘道器上進行連線跟蹤的方法,但是把這種變換關係接續起來也困難重重。基於IP的使用者授權不再可靠,因為擁有一個IP的不等於一個使用者或主機。一個伺服器也不能簡單把同一IP的訪問視作同一主機發起的,不能進行關聯。有些伺服器設定有連線限制,同一時刻只接納來自一個IP的有限訪問(有時是僅一個訪問),這會造成不同使用者之間的服務搶佔和排隊。有時伺服器端這樣做是出於DOS攻擊防護的考慮,因為一個使用者正常情況下不應該建立大量的連線請求,過度使用服務資源被理解為攻擊行為。但是這在NAT存在時不能簡單按照連線數判斷。總之,因為NAT隱蔽了通訊的一端,把簡單的事情複雜化了。

我們來深入理解NAT一下對IP端到端模型的破壞力。NAT通過修改IP首部的資訊變換通訊的地址。但是在這個轉換過程中只能基於一個會話單位。當一個應用需要保持多個雙向連線時,麻煩就很大。NAT不能理解多個會話之間的關聯性,無法保證轉換符合應用需要的規則。當NAT閘道器擁有多個公有IP地址時,一組關聯會話可能被分配到不同的公網地址,這通常是伺服器端無法接受的。更為嚴重的是,當公網側的主機要主動向私網側傳送資料時,NAT閘道器沒有轉換這個連線需要的關聯表,這個資料包無法到達私網側的主機。這些反方向傳送資料的連線總有應用協議的約定或在初始建立的會話中進行過協商。但是因為NAT工作在網路層和傳輸層,無法理解應用層協議的行為,對這些資訊是無知的。NAT希望自己對通訊雙方是透明的,但是在這些情況下這是一種奢望。

P2P技術詳解(一):NAT詳解——詳細原理、P2P簡介_圖4 NAT對端到端通訊模型的破壞 
圖4 NAT對端到端通訊模型的破壞

此外,NAT工作機制依賴於修改IP包頭的資訊,這會妨礙一些安全協議的工作。因為NAT篡改了IP地址、傳輸層埠號和校驗和,這會導致認證協議徹底不能工作,因為認證目的就是要保證這些資訊在傳輸過程中沒有變化。對於一些隧道協議,NAT的存在也導致了額外的問題,因為隧道協議通常用外層地址標識隧道實體,穿過NAT的隧道會有IP複用關係,在另一端需要小心處理。ICMP是一種網路控制協議,它的工作原理也是在兩個主機之間傳遞差錯和控制訊息,因為IP的對應關係被重新對映,ICMP也要進行復用和解複用處理,很多情況下因為ICMP報文載荷無法提供足夠的資訊,解複用會失敗。IP分片機制是在資訊源端或網路路徑上,需要傳送的IP報文尺寸大於路徑實際能承載最大尺寸時,IP協議層會將一個報文分成多個片斷髮送,然後在接收端重組這些片斷恢復原始報文。IP這樣的分片機制會導致傳輸層的資訊只包括在第一個分片中,NAT難以識別後續分片與關聯表的對應關係,因此需要特殊處理。

3.3 NAT穿越技術


前面解釋了NAT的弊端,為了解決IP端到端應用在NAT環境下遇到的問題,網路協議的設計者們創造了各種武器來進行應對。但遺憾的是,這裡每一種方法都不完美,還需要在內部主機、應用程式或者NAT閘道器上增加額外的處理。

    應用層閘道器
應用層閘道器(ALG)是解決NAT對應用層協議無感知的一個最常用方法,已經被NAT裝置廠商廣泛採用,成為NAT裝置的一個必需功能。因為NAT不感知應用協議,所以有必要額外為每個應用協議定製協議分析功能,這樣NAT閘道器就能理解並支援特定的協議。ALG與NAT形成互動關係,在一個NAT閘道器檢測到新的連線請求時,需要判斷是否為已知的應用型別,這通常是基於連線的傳輸層埠資訊來識別的。在識別為已知應用時,再呼叫相應功能對報文的深層內容進行檢查,當發現任何形式表達的IP地址和埠時,將會把這些資訊同步轉換,並且為這個新連線建立一個附加的轉換表項。這樣,當報文到達公網側的目的主機時,應用層協議中攜帶的資訊就是NAT閘道器提供的地址和埠。一旦公網側主機開始傳送資料或建立連線到此埠,NAT閘道器就可以根據關聯表資訊進行轉換,再把資料轉發到私網側的主機。很多應用層協議實現不限於一個初始連線(通常為信令或控制通道)加一個資料連線,可能是一個初始連線對應很多後續的新連線。比較特別的協議,在一次協商中會產生一組相關連線,比如RTP/RTCP協議規定,一個RTP通道建立後佔用連續的兩個埠,一個服務於資料,另一個服務於控制訊息。此時,就需要ALG分配連續的埠為應用服務。ALG能成功解決大部分協議的NAT穿越需求,但是這個方法也有很大的限制。因為應用協議的數量非常多而且在不斷髮展變化之中,新增到裝置中的ALG功能都是為特定協議的特定規範版本而開發的,協議的創新和演進要求NAT裝置製造商必須跟蹤這些協議的最近標準,同時相容舊標準。儘管有如Linux這種開放平臺允許動態載入新的ALG特性,但是管理成本仍然很高,網路維護人員也不能隨時瞭解使用者都需要什麼應用。因此為每個應用協議開發ALG程式碼並跟蹤最新標準是不可行的,ALG只能解決使用者最常用的需求。此外,出於安全性需要,有些應用型別報文從源端發出就已經加密,這種報文在網路中間無法進行分析,所以ALG無能為力。

    探針技術STUN和TURN
所謂探針技術,是通過在所有參與通訊的實體上安裝探測外掛,以檢測網路中是否存在NAT閘道器,並對不同NAT模型實施不同穿越方法的一種技術。STUN伺服器被部署在公網上,用於接收來自通訊實體的探測請求,伺服器會記錄收到請求的報文地址和埠,並填寫到回送的響應報文中。客戶端根據接收到的響應訊息中記錄的地址和埠與本地選擇的地址和埠進行比較,就能識別出是否存在NAT閘道器。如果存在NAT閘道器,客戶端會使用之前的地址和埠向伺服器的另外一個IP發起請求,重複前面的探測。然後再比較兩次響應返回的結果判斷出NAT工作的模式。由前述的一對多轉換模型得知,除對稱型NAT以外的模型,NAT閘道器對內部主機地址埠的對映都是相對固定的,所以比較容易實現NAT穿越。而對稱型NAT為每個連線提供一個對映,使得轉換後的公網地址和埠對不可預測。此時TURN可以與STUN繫結提供穿越NAT的服務,即在公網伺服器上提供一個“地址埠對”,所有此“地址埠對”接收到的資料會經由探測建立的連線轉發到內網主機上。TURN分配的這個對映“地址埠對”會通過STUN響應發給內部主機,後者將此資訊放入建立連線的信令中通知通訊的對端。這種探針技術是一種通用方法,不用在NAT裝置上為每種應用協議開發功能,相對於ALG方式有一定普遍性。但是TURN中繼服務會成為通訊瓶頸。而且在客戶端中增加探針功能要求每個應用都要增加程式碼才能支援。

    中介軟體技術
這也是一種通過開發通用方法解決NAT穿越問題的努力。與前者不同之處是,NAT閘道器是這一解決方案的參與者。與ALG的不同在於,客戶端會參與閘道器公網對映資訊的維護,此時NAT閘道器只要理解客戶端的請求並按照要求去分配轉換表,不需要自己去分析客戶端的應用層資料。其中UPnP就是這樣一種方法。UPnP中文全稱為通用即插即用,是一個通用的網路終端與閘道器的通訊協議,具備資訊釋出和管理控制的能力。其中,閘道器對映請求可以為客戶動態新增對映表項。此時,NAT不再需要理解應用層攜帶的資訊,只轉換IP地址和埠資訊。而客戶端通過控制訊息或信令發到公網側的資訊中,直接攜帶公網對映的IP地址和埠,接收端可以按照此資訊建立資料連線。NAT閘道器在收到資料或連線請求時,按照UPnP建立的表項只轉換地址和埠資訊,不關心內容,再將資料轉發到內網。這種方案需要閘道器、內部主機和應用程式都支援UPnP技術,且組網允許內部主機和NAT閘道器之間可以直接交換UPnP信令才能實施。

    中繼代理技術
準確說它不是NAT穿越技術,而是NAT旁路技術。簡單說,就是在NAT閘道器所在的位置旁邊放置一個應用伺服器,這個伺服器在內部網路和外部公網分別有自己的網路連線。客戶端特定的應用產生網路請求時,將定向傳送到應用代理伺服器。應用代理伺服器根據代理協議解析客戶端的請求,再從伺服器的公網側發起一個新的請求,把客戶端請求的內容中繼到外部網路上,返回的相應反方向中繼。這項技術和ALG有很大的相似性,它要求為每個應用型別部署中繼代理業務,中間伺服器要理解這些請求。

    特定協議的自穿越技術
在所有方法中最複雜也最可靠的就是自己解決自己的問題。比如IKE和IPsec技術,在設計時就考慮了到如何穿越NAT的問題。因為這個協議是一個自加密的協議並且具有報文防修改的鑑別能力,其他通用方法愛莫能助。因為實際應用的NAT閘道器基本都是NAPT方式,所有通過傳輸層協議承載的報文可以順利通過NAT。IKE和IPsec採用的方案就是用UDP在報文外面再加一層封裝,而內部的報文就不再受到影響。IKE中還專門增加了NAT閘道器是否存在的檢查能力以及繞開NAT閘道器檢測IKE協議的方法。

4. NAT的應用和實現

 

4.1 NAT的應用


NAT在當代Internet中被廣泛採用,小至家庭閘道器,大到企業廣域網出口甚至運營商業務網路出口。其實NAT在使用者身邊隨處可見,一般家庭寬頻接入的ADSL Modem和SOHO路由器都內建了NAT功能,WindowsXP支援網路連線共享,一個使用者連線到公網可能會經過多層NAT而對此一無所知。很多企業也為節約IP費用採用NAT接入Internet,但是相比家庭使用者有更復雜的需求。

    NAT多例項應用
在VPN網路中,多例項路由意味著一個物理拓撲上承載多個邏輯拓撲,網路終端被分配到相互隔離的邏輯拓撲中,彼此之間沒有路由的通路。但在訪問Internet或者一些關鍵伺服器資源時,被隔離的網路之間又存在共享資源的需求。NAT的多例項實現就是跨越這種邏輯拓撲的方法,把一個空間的網路地址對映到另一個空間。

    NAT的高可靠性組網
提高網路可靠性是一個廣泛的需求,NAT作為私網到公網的關鍵路徑自然也需要高可靠性。當一個裝置提供多個公網介面時,在多介面上部署NAT可以提供更高頻寬和多ISP就近訪問的能力。但是,當部署多個出口時,訪問的流量可能會從不匹配的介面返回,這就要求NAT方案有良好的路由規劃和部署合適的策略保證這種流量能夠正確處理。在多個物理裝置承擔NAT功能時,不同裝置之間的資訊備份和流量分擔也是一個組網難題。

    同時轉換源和目的地址的應用
前面我們介紹的所有NAT應用中,由內網向外網訪問過程中,都是將源地址進行轉換而目的地址保持不變,報文反方向進入時則處理目的地址。但有一些特殊應用需要在由內向外的IP通路上,替換目的IP地址。通常,這種應用會同時替換源地址和目的地址,在經過NAT閘道器以後完成兩次地址轉換。當兩個均規劃使用私屬IP地址範圍的網路進行合併時,終端使用者都不想調整自己的IP地址方案,又希望開放一些網路資源給彼此訪問。這時就可以通過NAT的兩次地址轉換來解決路由和地址規劃無法解決的問題。

P2P技術詳解(一):NAT詳解——詳細原理、P2P簡介_圖5 同時轉換源和目的地址的應用 
圖5 同時轉換源和目的地址的應用

4.2 NAT的裝置實現


NAT作為一個IP層業務特性,在產品實現中與防火牆、會話管理等特性有緊密聯絡,這是因為NAT判斷一個進入裝置的報文是否需要NAT處理,判斷報文是否為一個新的連線,都需要通過匹配訪問控制列表規則和查詢會話關聯表進行判斷。為了滿足不同應用場景的NAT需求, NAT的管理介面可提供使用者多種配置策略。按照NAT的具體工作方式,又可以做如下分類。

    靜態一對一地址對映
這種工作方式下,NAT把一個私網地址和一個公網地址做靜態關聯,在從內而外的方向,將源IP匹配的私網IP替換為公網IP,反方向則將目的IP匹配公網IP的報文替換為私網IP。網路層以上的部分不進行替換處理,只修正校驗和。

    靜態多對多地址對映
這種方式與上一種類似,只是把一段私網地址對映到一段公網地址。工作機制與前述的方式沒有差別,只是簡化配置工作量。

    動態埠對映
這是最基本的工作方式,即前面多次介紹的將一段內網地址動態翻譯為一個或多個公網IP,同時對傳輸層埠或其他上層協議資訊進行轉換,以實現IP複用。對由內而外的報文,替換源地址和埠,反向報文替換目的地址和埠。僅以連線公網的介面IP作為NAT轉換的公網地址時,這種配置最簡化,又被稱為EasyIP。當以一段公網IP地址作為NAT轉換地址時,需要配置一個地址池,NAT會自動在地址池中選擇使用公網IP。

    動態地址對映(no-pat)
這是介於靜態多對多地址對映和動態埠對映方式之間的一種工作機制。當有一個私網向公網側訪問到達NAT閘道器時,NAT閘道器會檢查這個私網IP是否已經有關聯的公網IP對映。如果已經存在,則按照轉換表直接替換IP,不修改上層協議。如果不存在關聯表項,則在空閒的公網IP池中佔用一個IP,並寫入關聯表中,以後按照這個關聯關係進行地址轉換。當這個私網主機發起的所有對外訪問均關閉或超時後,回收公網IP。這種方式可以理解為一組內網主機搶佔式地共享一個公網IP地址池。當公網IP地址池用完以後,新連線將無法建立。

    靜態埠對映
通過靜態配置,把一個固定的私網IP地址和埠關聯到一個公網地址和埠上。這種方式等同於前面介紹過的全錐模式,但是不需要內網主機首先發出報文。這種方式適用於在NAT閘道器上把一個知名服務(如HTTP)對映到一個內部主機上,也稱為port forwarding。

    應用層閘道器(ALG)
在所有NAT產品實現中,ALG是一個必需的功能元件。但在不同實現中,有些產品可以動態載入不同的ALG模組,有些產品可以提供ALG開關控制,有些則不提供任何使用者介面。ALG解析上層應用協議的內容,並且根據需要修改IP和埠相關資訊,建立和維護附加的關聯表項。

    NAT轉換關聯表
無論哪一種NAT工作方式,都要用到地址轉換關聯表,在不同產品的實現中,這個關聯表的儲存結構和在IP轉發中呼叫的方式有很大不同。關聯表中會記錄源IP、目的IP、連線協議型別、傳輸層源埠、目的埠,以及轉換後的源IP、源埠,目的IP、目的埠資訊,這裡的源和目的都是對應於從內網到外網的訪問方向。依據NAT具體工作方式,這些資訊可能全部填充,也可能部分填充。例如只按照IP做靜態對映的方式,就不需要填入任何埠相關資訊;對於靜態埠對映,則只填入源相關的內容,而目的端的資訊為空。

5. 後IPv4時代的NAT


NAT是為延緩IPv4地址耗盡而推出的技術。毫無疑問,它已經出色完成了自己的歷史使命,IPv4比預期走得更遠。作為繼任者的IPv6吸取了IPv4的教訓,被賦予充足地址空間的同時在各個方面做了優化——安全、高效、簡潔。但是IPv6無法平滑地取代IPv4,導致IP升級步伐緩慢。儘管網路協議的分層設計很清晰,大量應用層協議和網際網路軟體中仍內嵌了IPv4地址的處理,要Internet全網升級到IPv6,必須先完成應用的改造。因為NAT和它的穿越技術結合能夠滿足大部分使用者的需求,所以IPv6時代被不斷推遲。

隨著IPv4地址的瀕臨耗盡,再經濟的模式也無以為繼,IPv4必須退出歷史舞臺。人們自然會認為,NAT作為IPv4的超級補丁技術使命已經完結。實際情況是,IPv4向IPv6過渡的階段,NAT仍然是一項必不可少的技術手段。因為Internet無法在一日之內完成全網升級,必然是區域性升級,逐漸替換。在兩套協議並存的時期,使用者和服務資源分佈在不同網路之間,跨網訪問的需求必須得到滿足。這正是NAT所擅長的領域,地址替換,因此NAT-PT應運而生。由於IPv4和IPv6之間的差異,NAT要做的事比以往更復雜,有更多的限制和細節。

此外,IETF也在制定純IPv6網路使用的NAT規範。雖然人們還看不到這種應用的強烈需求,但是NAT仍有其獨特的作用,比如隱藏內部網路的地址,實現重疊地址網路的合併等。

毫不誇張地說,正是有了NAT,以IPv4為基礎的Internet才能容納數十億的使用者終端,成就今日之輝煌。IPv4已至日暮西山,IPv6的黎明尚未來臨,Internet比任何時刻都更依賴NAT這項過渡技術。NAT的歷史再次證明,翻天覆地的劃時代進步不一定有市場,抱殘守缺的修修補補未必不會成功。在世代更替之時讓我們走近NAT,領略IP領域更多細微但不高深的知識,理解NAT就是理解變換萬千的應用世界。

全站即時通訊技術資料分類


[1] 網路程式設計基礎資料:
TCP/IP詳解 - 第11章·UDP:使用者資料包協議
TCP/IP詳解 - 第17章·TCP:傳輸控制協議
TCP/IP詳解 - 第18章·TCP連線的建立與終止
TCP/IP詳解 - 第21章·TCP的超時與重傳
理論經典:TCP協議的3次握手與4次揮手過程詳解
理論聯絡實際:Wireshark抓包分析TCP 3次握手、4次揮手過程
計算機網路通訊協議關係圖(中文珍藏版)
NAT詳解:基本原理、穿越技術(P2P打洞)、埠老化等
UDP中一個包的大小最大能多大?
Java新一代網路程式設計模型AIO原理及Linux系統AIO介紹
NIO框架入門(三):iOS與MINA2、Netty4的跨平臺UDP雙向通訊實戰
NIO框架入門(四):Android與MINA2、Netty4的跨平臺UDP雙向通訊實戰
>> 更多同類文章 ……

[2] 有關IM/推送的通訊格式、協議的選擇:
為什麼QQ用的是UDP協議而不是TCP協議?
移動端即時通訊協議選擇:UDP還是TCP?
如何選擇即時通訊應用的資料傳輸格式
強列建議將Protobuf作為你的即時通訊應用資料傳輸格式
移動端IM開發需要面對的技術問題(含通訊協議選擇)
簡述移動端IM開發的那些坑:架構設計、通訊協議和客戶端
理論聯絡實際:一套典型的IM通訊協議設計詳解
58到家實時訊息系統的協議設計等技術實踐分享
>> 更多同類文章 ……

[3] 有關IM/推送的心跳保活處理:
Android程式保活詳解:一篇文章解決你的所有疑問
Android端訊息推送總結:實現原理、心跳保活、遇到的問題等
為何基於TCP協議的移動端IM仍然需要心跳保活機制?
微信團隊原創分享:Android版微信後臺保活實戰分享(程式保活篇)
微信團隊原創分享:Android版微信後臺保活實戰分享(網路保活篇)
移動端IM實踐:實現Android版微信的智慧心跳機制
移動端IM實踐:WhatsApp、Line、微信的心跳策略分析
>> 更多同類文章 ……

[4] 有關WEB端即時通訊開發:
新手入門貼:史上最全Web端即時通訊技術原理詳解
Web端即時通訊技術盤點:短輪詢、Comet、Websocket、SSE
SSE技術詳解:一種全新的HTML5伺服器推送事件技術
Comet技術詳解:基於HTTP長連線的Web端實時通訊技術
WebSocket詳解(一):初步認識WebSocket技術
socket.io實現訊息推送的一點實踐及思路
>> 更多同類文章 ……

[5] 有關IM架構設計:
淺談IM系統的架構設計
簡述移動端IM開發的那些坑:架構設計、通訊協議和客戶端
一套原創分散式即時通訊(IM)系統理論架構方案
從零到卓越:京東客服即時通訊系統的技術架構演進歷程
蘑菇街即時通訊/IM伺服器開發之架構選擇
騰訊QQ1.4億線上使用者的技術挑戰和架構演進之路PPT
微信技術總監談架構:微信之道——大道至簡(演講全文)
如何解讀《微信技術總監談架構:微信之道——大道至簡》
快速裂變:見證微信強大後臺架構從0到1的演進歷程(一)
17年的實踐:騰訊海量產品的技術方法論
>> 更多同類文章 ……

[6] 有關IM安全的文章:
即時通訊安全篇(一):正確地理解和使用Android端加密演算法
即時通訊安全篇(二):探討組合加密演算法在IM中的應用
即時通訊安全篇(三):常用加解密演算法與通訊安全講解
即時通訊安全篇(四):例項分析Android中金鑰硬編碼的風險
傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示
理論聯絡實際:一套典型的IM通訊協議設計詳解(含安全層設計)
微信新一代通訊安全解決方案:基於TLS1.3的MMTLS詳解
來自阿里OpenIM:打造安全可靠即時通訊服務的技術實踐分享
>> 更多同類文章 ……

[7] 有關實時音視訊開發:
即時通訊音視訊開發(一):視訊編解碼之理論概述
即時通訊音視訊開發(二):視訊編解碼之數字視訊介紹
即時通訊音視訊開發(三):視訊編解碼之編碼基礎
即時通訊音視訊開發(四):視訊編解碼之預測技術介紹
即時通訊音視訊開發(五):認識主流視訊編碼技術H.264
即時通訊音視訊開發(六):如何開始音訊編解碼技術的學習
即時通訊音視訊開發(七):音訊基礎及編碼原理入門
即時通訊音視訊開發(八):常見的實時語音通訊編碼標準
即時通訊音視訊開發(九):實時語音通訊的迴音及迴音消除概述
即時通訊音視訊開發(十):實時語音通訊的迴音消除技術詳解
即時通訊音視訊開發(十一):實時語音通訊丟包補償技術詳解
即時通訊音視訊開發(十二):多人實時音視訊聊天架構探討
即時通訊音視訊開發(十三):實時視訊編碼H.264的特點與優勢
即時通訊音視訊開發(十四):實時音視訊資料傳輸協議介紹
即時通訊音視訊開發(十五):聊聊P2P與實時音視訊的應用情況
即時通訊音視訊開發(十六):移動端實時音視訊開發的幾個建議
即時通訊音視訊開發(十七):視訊編碼H.264、V8的前世今生
簡述開源實時音視訊技術WebRTC的優缺點
良心分享:WebRTC 零基礎開發者教程(中文)
>> 更多同類文章 ……

[8] IM開發綜合文章:
移動端IM開發需要面對的技術問題
開發IM是自己設計協議用位元組流好還是字元流好?
請問有人知道語音留言聊天的主流實現方式嗎?
IM系統中如何保證訊息的可靠投遞(即QoS機制)
談談移動端 IM 開發中登入請求的優化
完全自已開發的IM該如何設計“失敗重試”機制?
微信對網路影響的技術試驗及分析(論文全文)
即時通訊系統的原理、技術和應用(技術論文)
開源IM工程“蘑菇街TeamTalk”的現狀:一場有始無終的開源秀
>> 更多同類文章 …… 

[9] 開源移動端IM技術框架資料:
開源移動端IM技術框架MobileIMSDK:快速入門
開源移動端IM技術框架MobileIMSDK:常見問題解答
開源移動端IM技術框架MobileIMSDK:壓力測試報告
開源移動端IM技術框架MobileIMSDK:Android版Demo使用幫助
開源移動端IM技術框架MobileIMSDK:Java版Demo使用幫助
開源移動端IM技術框架MobileIMSDK:iOS版Demo使用幫助
開源移動端IM技術框架MobileIMSDK:Android客戶端開發指南
開源移動端IM技術框架MobileIMSDK:Java客戶端開發指南
開源移動端IM技術框架MobileIMSDK:iOS客戶端開發指南
開源移動端IM技術框架MobileIMSDK:Server端開發指南
>> 更多同類文章 ……

[10] 有關推送技術的文章:
iOS的推送服務APNs詳解:設計思路、技術原理及缺陷等
Android端訊息推送總結:實現原理、心跳保活、遇到的問題等
掃盲貼:認識MQTT通訊協議
一個基於MQTT通訊協議的完整Android推送Demo
求教android訊息推送:GCM、XMPP、MQTT三種方案的優劣
移動端實時訊息推送技術淺析
掃盲貼:淺談iOS和Android後臺實時訊息推送的原理和區別
絕對乾貨:基於Netty實現海量接入的推送服務技術要點
移動端IM實踐:谷歌訊息推送服務(GCM)研究(來自微信)
為何微信、QQ這樣的IM工具不使用GCM服務推送訊息?
>> 更多同類文章 ……

[11] 更多即時通訊技術好文分類:
http://www.52im.net/forum.php?mod=collection&op=all

 

相關文章