1. 程式人生 > >網路穿透與音視訊技術(3)——NAT對映檢測和常見網路穿越方法論(NAT檢測)

網路穿透與音視訊技術(3)——NAT對映檢測和常見網路穿越方法論(NAT檢測)

1、什麼是網路穿透

1.1、伺服器高負載狀態下的通訊問題

想想一下這種情況,多個處於不同內部網路的終端同時進行大檔案傳輸工作。我們最直接的思維模式能夠想到的就是這些終端首先將檔案傳輸到某各都能訪問到的伺服器上,再由伺服器進行中轉傳輸。是的,這個方式最簡單直接,但是有幾個問題:

1、成本問題:一般我們租用或者託管在機房的這種伺服器都是按照頻寬大小或者流量多少進行計費的,只要有資料流流向伺服器,服務商就會收費。但實際上這些大檔案根本就不是我們伺服器需要的,而只是從伺服器進行中轉。

2、 法律問題:這些由客戶終端進行傳輸的檔案,一旦經過了伺服器那麼就涉及到法律風險。使用者會擔心我們的伺服器是否講這些檔案在伺服器端儲存了副本,一旦這些檔案涉密且後續發生了事故,服務程式的提供方很難說清楚自己的責任。

3、效率問題:通過伺服器中轉進行大檔案的傳輸從技術層面說當然沒有問題,但效率相對低下。例如從A終端到伺服器再從伺服器到B終端只有一條通路,在有限的上行頻寬下,無法實現檔案的分片傳輸。另外,伺服器的整體效能和頻寬資源將會限制檔案的中轉規模,很難實現多個大檔案的並行中轉處理(或者就是傳輸速度極低)。

如何解決大檔案的傳輸問題

1.2、什麼是網路穿透

加上這篇文章,這個系列我們聊網路穿透的基本問題已經聊了三篇文章了,可以我們一直還沒有給“網路穿透”一個準確的定義。這裡我們先來給網路穿透這個事情一個比較清晰的概述:

網路穿透問題實際上就是NAT裝置穿透問題,既是如何在兩個相對封閉,並且通過一層或者多層NAT裝置進行連線的內部網路中,建立點對點的網路連線並完成資料傳輸的問題。

1.3、為什麼需要網路穿透

1、在有限的IPV4資源前提下,實現內部網路終端的公平通訊。這個情況很好理解:IPV4資源是有限的,而世界上無數的網路終端(包括PC、移動終端、工控機、各種網路裝置等等)不可能都分配一個全球唯一的IP資源,所以為了穿越不同的內部網路實現終端到終端的平等通訊,就成為一個非常必要的資料通訊手段。

2、使用NAT裝置中繼傳輸,減少伺服器上資料轉發帶來的資源消耗 。NAT裝置廣泛存在於我們熟知的網路世界中,且具有不同的對映實現方式。通過進行網路穿透,是的資料不再經過中轉伺服器,即可規避成本問題、又可規避法律問題,並且使傳輸方案的擴充套件有了更多的可能性。

3、人人為我,我為人人。基於DHT演算法實現的無伺服器網路和混合P2P網路是目前P2P技術發展的重點,而網路穿透技術是P2P技術的一個基本實現要求。關於P2P技術和DHT網路在本專題後續內容中將進行比較詳細的介紹。

2、NAT對映實現方式的檢測

要實現兩個相對封閉網路中終端的點對點穿透,就是要實現這兩個終端下的TCP/IP協議簇的資料傳輸和接收,那麼根據前文介紹的情況,我們就首先要對隔離這兩個終端的多層NAT裝置的對映實現方式進行檢測。

上篇文章中就我們已經提到,NAT對映模式一共有三種,靜態對映(Static NAT)、動態對映(Pooled NAT)和網路地址埠對映(NAPT/PAT)。其中NAPT/PAT對映模式是目前絕大多數現有NAT裝置的工作模式。這種對映模式下,又有四種對映實現方式,它們是:全圓錐NAT(Full Cone NAT)、地址限制圓錐NAT(Address Restricted Cone NAT)、埠限制圓錐NAT(Port Restricted Cone NAT)和對稱NAT(Symmetric NAT)。那麼這個NAT裝置對映實現方式的檢測問題,實際上就是對以上四種實現方式的判定問題。又由於Full Cone NAT、Address Restricted Cone NAT、Port Restricted Cone NAT和Symmetric NAT這四種對映實現方式對於網路穿透的限制是遞增性的,所以最終被檢測出來的兩個終端之間多層NAT裝置的對映實現方式,就是那種對穿透限制最嚴格的對映實現方式

2.1、檢測過程描述

2.1.1、檢測過程前提

要進行 “指定終端到指定伺服器是什麼NAT對映實現方式” 的驗證,首先我們需要有一臺 “指定終端” 還需要有一臺 “指定伺服器”,其中的細節包括:

1、這個指定的伺服器擁有兩個外網IP(分別記為IP1和IP2),指定的終端上的資料可以通過網路達到伺服器(記為Server)。這個問題很好理解,因為至少有一種NAT對映實現方式需要驗證兩個獨立IP的對映結果。

2、每次檢測為了剔除網路延遲問題,都會發送多個重複的UDP資料報(建議為5-10個)。這是為了儘可能避免網路不穩定造成的判定失誤。

3、首先進行預檢測——保證終端和Server之間存在至少一級NAT裝置,這個檢測也非常簡單:
終端以Server的IP1 + PORT1為目標傳送UDP資料報,Server在收到這個資料報之後,將可以得到終端(在NAT裝置轉換後)的IP和埠資訊(記為IPX + PORTX)。接著Server將這個獲得的終端的IPX + PORTX資訊進行打包,並通過IPX + PORTX回傳給終端。終端進行解包,如果發現Server識別到的終端IPX + PORTX和自己傳送UDP使用的IP + PORT是完全一致的,說明終端到Server之間並沒有任何一級NAT裝置

如下圖所示:

在這裡插入圖片描述

(注意:如果檢測到指定的終端和指定的伺服器之間沒有任何NAT裝置,實際上最直觀的判斷是指定的終端和指定的伺服器在同一個內部網路環境中

2.1.2、Symmetric NAT檢測

首先可以檢測網路中的NAT裝置的對映實現方式是否為對稱NAT,因為一旦檢測其為對稱NAT,則後續的檢查都不需要做了。對稱NAT的檢查過程如下:

終端首先分別瞄準Server的兩個IP,向Server的IP1 + PORT1和IP2 + PORT2傳送UDP資料報,這個時候Server的兩個監聽地址肯定都能收到資料報(排除網路本身不通的情況)。我們將在Server上得到這個終端(在NAT裝置轉換後的)的兩個地址 + 埠——IP1 + PORT1得到的客戶端記為Client_IP1 + Client_Port1,IP2 + PORT2得到的客戶端記為Client_IP2 + Client_Port2。

接著Server會將這個地址進行封裝到回覆資料報文中進行回發,IP1 + PORT1回發的資料報中包含的內容為Client_IP1 + Client_Port1(當然還會視情況包含其它內容,例如UDP支援的實際長度);IP2 + PORT2回發的資料報中包含的內容為Client_IP2 + Client_Port2。

客戶端在接受到兩方響應的資料報後,會對這兩個資料報的內容進行檢查,如果Client_IP1 + Client_Port1 和 Client_IP2 + Client_Port2 不相同,那麼說明是對等網路;其它情況說明不是對等網路,但屬於哪一種圓錐NAT還需要繼續進行檢測。

在這裡插入圖片描述

(具體實現程式碼請參見後續文章)

2.1.3、Full Cone NAT檢測

終端首先向IP1 + PORT1傳送UDP資料報到Server,Server將會收到終端發來的資料報,其中包括了終端(在NAT裝置轉換後的)Client_IP + Client_Port。接著Server使用IP2 + PORT2向終端(Client_IP + Client_Port)傳送回覆資訊。如果終端分別收到兩個源傳送過來的響應資料報,則證明終端到Server的NAT裝置對映實現方式為,Full Cone NAT。

在這裡插入圖片描述

注意,這裡為了簡化判斷過程,並不需要IP1向終端回覆響應,因為無論四種實現方式中的哪一種實現方式,IP1 + PORT1傳送的資料報都可以被終端接收到——除非網路非常不穩定甚至不可達。(具體實現程式碼請參見後續文章)

2.1.4、Address Restricted Cone NAT/Port Restricted Cone NAT 檢測

在完成了Full Cone NAT的檢測後,就可以進行Address Restricted Cone NAT/Port Restricted Cone NAT 的檢測了,只需要增加一個接收到終端資料報文的IP1換一個埠,向終端地址進行回發的操作,並判斷終端是否能收到回發的資料報即可。具體過程如下:

終端首先向IP1 + PORT1傳送UDP資料報到Server,Server將會收到終端發來的資料報,其中包括了終端(在NAT裝置轉換後的)Client_IP + Client_Port。接著Server使用IP1 + PORTX(非PORT1)向終端(Client_IP + Client_Port)進行回發。如果終端能夠收到,則證明是Address Restricted Cone NAT;如果不能收到,則證明是Port Restricted Cone NAT。

在這裡插入圖片描述

(具體實現程式碼請參見後續文章)

2.1.5、檢測方式總結

通過閱讀以上檢驗方式,我們至少可以得出以下經驗性的結論:

1、終端傳送資料報後,指定伺服器回發的響應資料報以及資料報中攜帶的終端在NAT裝置上對映的IP + PORT才是整個NAT對映實現方式檢驗的重點。

2、伺服器端只是起到輔助作用——將自己接受到的終端在NAT裝置上形成的對映結果回發給終端,而真正的檢測判斷都是由終端自行做出。

3、為了提高NAT對映方式的檢測效率,其檢測過程是有特定順序的:在準備好以後,先檢查Symmetric NAT,再檢查Full Cone NAT,最後檢查Address Restricted Cone NAT/Port Restricted Cone NAT。

後文我們將編寫程式碼實現這些檢查,並說明在兩個終端進行網路穿透前,如何首先判斷兩個終端存在於同一個區域網中。

相關推薦

網路穿透視訊技術3——NAT對映檢測常見網路穿越方法論NAT檢測

1、什麼是網路穿透 1.1、伺服器高負載狀態下的通訊問題 想想一下這種情況,多個處於不同內部網路的終端同時進行大檔案傳輸工作。我們最直接的思維模式能夠想到的就是這些終端首先將檔案傳輸到某各都能訪問到的伺服器上,再由伺服器進行中轉傳輸。是的,這個方式最簡單直接,

網路穿透視訊技術(1)——NAT的概念及工作模式

(這個專題我們將介紹網路穿透的基本知識,以及建立在此基礎上的實時視訊語音通訊技術。不只是介紹理論知識,還介紹實際案例 ) 1、概念介紹 1.1、NAT基本概念 NAT英文全稱是“Network Address Translation”,中文意思是“網路

網路穿透視訊技術(2)——NAT的概念及工作模式

3、四種NAT對映實現方式 上文中我們已經提到三種NAT對映模式,它們是靜態對映(Static NAT)、動態對映(Pooled NAT)和網路地址埠對映(NAPT/PAT),又由於NAPT/PAT對映模式的靈活性和複用性最好,所以它又是目前應用最廣泛的一種對

網路穿透視訊技術4——NAT對映檢測常見網路穿越方法論NAT檢測實踐1

2.2、檢測過程實戰——伺服器端 要進行NAT對映檢測,按照上文提到的檢測方式,我們就需要一個服務端檢測程式。並將服務端檢測程式部署到具有兩個外網IP的硬體環境下。 2.2.1、檢測要求 服務端程式至少需要做到以下功能: 檢測客戶端和當前伺服器端之間是否至

LiveVideoStack線上交流分享 ( 五 ) —— 線上教育視訊技術探索應用

為了給大家提供一個學習,交流的平臺,暢聊音視訊技術開發新趨勢,新實踐。我們推出了LiveVideoStack線上交流分享活動,在每週四晚19:30,邀請1名業內資深技術專家進行線上分享技術乾貨,解答熱點問題。你可以通過以下方式參與: 關注LiveVideoStack公眾號【

線上教育視訊技術探索應用

隨著實時音視訊通訊技術的發展,1對1,1對多直播等線上教育形式不斷的滿足個人定製化的學習需求。掌門1對1音視訊負責人 曾小偉在LiveVideoStack 線上交流分享中介紹了線上教育中音視訊技術的應用現狀、挑戰以及未來的發展。本文由LiveVideoStack整理而

實時視訊技術WebRTC/voip/Linphone/P2P

  視訊社交與語音社交???    實時視訊(直播)/語音通訊。多媒體技術團隊在音視訊編解碼、前後處理、傳輸等技術;   在語音社交、視訊社交、遊戲語音和互動直播等領域,關於在語音視訊實時傳輸中實現低延遲這個議題,已經有不少的文章提出各種方案。絕大部分方案的思路都是“優化”,

1小時學會:最簡單的iOS直播推流flv 編碼視訊時間戳同步

最簡單的iOS 推流程式碼,視訊捕獲,軟編碼(faac,x264),硬編碼(aac,h264),美顏,flv編碼,rtmp協議,陸續更新程式碼解析,你想學的知識這裡都有,願意懂直播技術的同學快來看!! 前文介紹瞭如何獲取音視訊的aac/h2

快手科技視訊技術亮相ChinaMM 首次公開多媒體傳輸協議KTP

在中國多媒體大會產業前沿論壇,快手科技演算法科學家周超博士發表題為《多媒體傳輸演算法應用和展望》的演講,首次對外公開了其多媒體傳輸協議KTP(Kwai Transport Protocol,快手傳輸協議),該協議解決了重要的內容傳輸問題。以下為周超博士演講的主要內容。 快手的核心理念就是記錄,力

使用ONVIF Device Test Tool獲取網路攝像頭的/視訊

軟/硬體準備 1、一個網路攝像頭(IPC),品牌必須支援ONVIF協議,具體哪些品牌支援不作為本教程介紹的重點,大家可自行度娘,我知道的有品牌大華和海康威視; 2、ONVIF Device Test Tool軟體下載,筆者使用的版本為15.06, 下載地址:https://downl

開源實時視訊技術WebRTC中RTP/RTCP資料傳輸協議的應用

1、前言 RTP/RTCP協議是流媒體通訊的基石。RTP協議定義流媒體資料在網際網路上傳輸的資料包格式,而RTCP協議則負責可靠傳輸、流量控制和擁塞控制等服務質量保證。在WebRTC專案中,RTP/RTCP模組作為傳輸模組的一部分,負責對傳送端採集到的媒體資料進行進行封包,然後交給上層網路模組

LiveVideoStackCon視訊技術大會首次來到上海

音視訊技術生態盛宴——LiveVideoStackCon將在2019年來到上海,並從即日起開啟招募講師與出品人。 文 / 包研 2019年4月12-13日,將迎來LiveVideoStackCon上海大會。這是第三次LiveVideoStackC

視訊技術開發週刊 75期

『音視訊技術開發週刊』由LiveVideoStack團隊出品,專注在音視訊技術領域,縱覽相關技術領域的乾貨和新聞投稿,每週一期。點選『閱讀原文』,瀏覽第75期內容,祝您閱讀愉快。 架構 Netflix媒體資料庫:媒體時間線資料模

視訊技術開發週刊 74期

『音視訊技術開發週刊』由LiveVideoStack團隊出品,專注在音視訊技術領域,縱覽相關技術領域的乾貨和新聞投稿,每週一期。點選『閱讀原文』,瀏覽第74期內容,祝您閱讀愉快。 架構 VMAF:未畢之旅 本文來自N

打造專遞課堂,即構成為希沃專遞課堂實時視訊技術唯一提供方

日前,在南昌舉辦的第75屆中國教育裝備展上,希沃和即構zego打造的互動錄播方案亮相。現場將展廳設定為授課教室,廣州、贛州、南昌三個分會場為聽課教室,以每分鐘一場的高頻次互動演示,模擬了身處不同地區的4個教室的互動教學,現場效果令人震撼。 據瞭解,該方案也稱“專遞課堂”,目前已在江西、雲南

【雲棲TechDay】視訊技術開發實戰專場沙龍,邀您參加

【時間】2018-12-20 下午13:40-18:00【地點】浙江省杭州市蕭山區啟迪路198號杭州灣資訊港A座負一樓國際報告廳【主辦單位】雲棲techday 阿里雲視訊雲團隊 簡介 音視訊技術是當前非常活躍、發展十分迅速的技術領域。近年來,數字化潮流正在迅猛衝擊模擬領域,數字技術促進了音視訊

視訊技術總結

1. 常用的基本知識 基本概念 編解碼   編解碼器(codec)指的是一個能夠對一個訊號或者一個數據流進行變換的裝置或者 程式。這裡指的變換既包括將訊號或者資料流進行編碼(通常是為了傳輸、儲存或者加密)或者提取得到一個編碼流的操作,也包括為了觀察或者處理從這個

視訊技術開發週刊 77期

『音視訊技術開發週刊』由LiveVideoStack團隊出品,專注在音視訊技術領域,縱覽相關技術領域的乾貨和新聞投稿,每週一期。點選『閱讀原文』,瀏覽第77期內容,祝您閱讀愉快。 架構 基於FFmpeg的運動視訊分析 本文

LiveVideoStack視訊技術2018年度評獎揭曉

經過一個月的投票與評審,LiveVideoStack評出了音視訊技術2018年度獲獎者。 一個月前,LiveVideoStack啟動音視訊技術2018年度評獎,總共獲得393份有效問卷。考慮到一些故意的刷票行為,對這部分投票實行了降權處理。儘管如此,我

即構科技金健忠:回顧20年視訊技術演進

多媒體技術是一個傳統行業,從模擬到數字,VCD到藍光,從窄帶到寬頻,標清到高清,技術演進讓人的視聽體驗發生了顛覆式的改變。LiveVideoStack採訪了即構科技CTO金健忠,他回顧了過去20年多媒體技術的發展,並展望了未來的技術趨勢。 文 / 金健忠 策劃 /