udpnat穿透源碼

❶ 使用docker搭建STUN/TURN伺服器

前言     STUN，首先在RFC3489中定義，作為一個完整的NAT穿透解決方案，英文全稱是Simple Traversal of UDP Through NATs，即簡單的用UDP穿透NAT。     TURN，首先在RFC5766中定義，英文全稱是Traversal Using Relays around NAT:Relay Extensions to Session Traversal Utilities for NAT，即使用中繼穿透NAT:STUN的擴展       簡單的說，TURN與STURN的共同點都是通過修改應用層中的私網地址達到NAT穿透的效果，異同點是TURN是通過兩方通訊的「中間人」方式實現穿透。     ICE的全稱Interactive Connectivity Establ.shment（互動式連接建立），由IETF的MMUSIC工作組開發出來的，它所提供的是一種框架，使各種NAT穿透技術可以實現統一。     STUN和TURN伺服器和ICE可以參考閱讀: P2P技術詳解(三)：P2P技術之STUN、TURN、ICE詳解     本文介紹如何通過DOCKER搭建STUN和TURN伺服器，步驟如下 1：創建Dockerfile，內容如下： FROM      ubuntu:14.04 MAINTAINER Patxi Gortázar <[email protected]> RUN apt-get update && apt-get install -y \   curl \   libevent-core-2.0-5 \   libevent-extra-2.0-5 \   libevent-openssl-2.0-5 \   libevent-pthreads-2.0-5 \   libhiredis0.10 \   libmysqlclient18 \   libpq5 \   telnet \   wget RUN wget http://turnserver.open-sys.org/downloads/v4.4.2.2/turnserver-4.4.2.2-debian-wheezy-ubuntu-mint-x86-64bits.tar.gz \   && tar xzf turnserver-4.4.2.2-debian-wheezy-ubuntu-mint-x86-64bits.tar.gz \   && dpkg -i coturn_4.4.2.2-1_amd64.deb COPY ./turnserver.sh /turnserver.sh ENV TURN_USERNAME test ENV TURN_PASSWORD test ENV REALM kurento.org ENV NAT true EXPOSE 3478 3478/udp ENTRYPOINT ["/turnserver.sh"] 2：創建turnserver.sh，內容如下 #!/bin/bash set-e if[$NAT="true"-a-z"$EXTERNAL_IP"];then #Try to get public IP PUBLIC_IP=$(curl http://169.254.169.254/latest/meta-data/public-ipv4)||echo"No public ip found on http://169.254.169.254/latest/meta-data/public-ipv4" if[-z"$PUBLIC_IP"];then PUBLIC_IP=$(curl http://icanhazip.com)||exit1 fi #Try to get private IP PRIVATE_IP=$(ifconfig|awk'/inet addr/{print substr($2,6)}'|grep -v 127.0.0.1)||exit1 exportEXTERNAL_IP="$PUBLIC_IP/$PRIVATE_IP" echo"Starting turn server with external IP:$EXTERNAL_IP" fi echo'min-port=49152'>/etc/turnserver.conf echo'max-port=65535'>>/etc/turnserver.conf echo'fingerprint'>>/etc/turnserver.conf echo'lt-cred-mech'>>/etc/turnserver.conf echo"realm=$REALM">>/etc/turnserver.conf echo'log-file stdout'>>/etc/turnserver.conf echo"user=$TURN_USERNAME:$TURN_PASSWORD">>/etc/turnserver.conf [$NAT="true"]&&echo"external-ip=$EXTERNAL_IP">>/etc/turnserver.conf exec/usr/bin/turnserver"$@" 3：使用docker build 創建鏡像，執行結果如下 [root@www]# docker build -t teststurn_1 . Sending build context to Docker daemon  4.096kB Step 1/11 : FROM      ubuntu:14.04 ---> 6e4f1fe62ff1 Step 2/11 : MAINTAINER Patxi Gortázar <[email protected]> ---> Using cache ---> 4460f9f84053 Step 3/11 : RUN apt-get update && apt-get install -y  curl  libevent-core-2.0-5  libevent-extra-2.0-5  libevent-openssl-2.0-5  libevent-pthreads-2.0-5  libhiredis0.10  libmysqlclient18  libpq5  telnet  wget ---> Using cache ---> 05ed9ced48a5 Step 4/11 : RUN wget http://turnserver.open-sys.org/downloads/v4.4.2.2/turnserver-4.4.2.2-debian-wheezy-ubuntu-mint-x86-64bits.tar.gz  && tar xzf turnserver-4.4.2.2-debian-wheezy-ubuntu-mint-x86-64bits.tar.gz  && dpkg -i coturn_4.4.2.2-1_amd64.deb ---> Using cache ---> d82ed28fdac9 Step 5/11 : COPY ./turnserver.sh /turnserver.sh ---> Using cache ---> 1d37a488282c Step 6/11 : ENV TURN_USERNAME test ---> Running in bfd88f08db42 Removing intermediate container bfd88f08db42 ---> cf8af0504b95 Step 7/11 : ENV TURN_PASSWORD test ---> Running in b8ef33b7c213 Removing intermediate container b8ef33b7c213 ---> 32a832f23169 Step 8/11 : ENV REALM kurento.org ---> Running in bbe129edf5b3 Removing intermediate container bbe129edf5b3 ---> 21fdfe34689b Step 9/11 : ENV NAT true ---> Running in 5bdfe8555d5e Removing intermediate container 5bdfe8555d5e ---> dc7fc896841c Step 10/11 : EXPOSE 3478 3478/udp ---> Running in 67aaa1966f68 Removing intermediate container 67aaa1966f68 ---> a12646ed45ff Step 11/11 : ENTRYPOINT ["/turnserver.sh"] ---> Running in b8fc2ff09265 Removing intermediate container b8fc2ff09265 ---> f5e5acad0f81 Successfully built f5e5acad0f81 Successfully tagged teststurn_1:latest 執行完後可以看到自己創建的鏡像名稱為teststurn_1  4：啟動docker的鏡像，並開啟埠3478      docker run -d -p 3478:3478 -p 3478:3478/udp teststurn_1    啟動後需要等待一兩分鍾才能測試順暢 5：測試伺服器效果     打開 https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/  並輸入自己的本機IP和埠，分別測試兩種協議服務是否生效

❷ C#UDP穿越NAT，UDP打洞，UDP Hole Punching源代碼，該怎麼處理

首先要有一個沒有nat的公網伺服器,
每個用戶使用一個埠與伺服器通訊 ,伺服器在收到用戶連入請求後把用戶的標識符跟用戶的埠號匹配保存起來
當另一個用戶請求該用戶時把該用戶對應的埠號返回 然後用戶之間互相用指定埠號聯系 就是打洞了
伺服器要維系連接要定時發心跳包

❸ udp協議怎麼穿透Symmetric NAT

把4種類型分別標為1234，有兩台主機A:portA和B:portB（port都為外網埠，是與打洞伺服器通信的埠），以及打洞伺服器S，情景是B拿到了A:portA的信息，要與A通信。
（1）、A為類型1；無論B為哪種類型，都可以直接與A:portA tcp連接；
（2）、A為類型2；無論B為哪種類型，在A知道B之前都無法直接連接，B給S發一個打洞請求，S轉發該請求到A。若B的類型為1，則A:portA可直接tcp連接到B:portB；若B的類型為2或3，則A:portA和B:portB各自向對方發送一個一位元組的udp包，分別在自己的路由器上打洞，從此A:portA和B:portB可進行udp通信；若B為類型4，則portB在與不同的ip:port通信時會不一樣，所以A:portA先向B發送一個一位元組的udp包，在路由器上打洞，然後等待B:portB先發送數據，A:portA接收到B:portB的數據後，即知道portB，也可互通數據了；
（3）、A為類型3；無論B為哪種類型，在A知道B之前都無法直接連接，B給S發一個打洞請求，S轉發該請求到A。若B的類型為1，則A:portA可直接tcp連接到B:portB；若B的類型為2或3，則A:portA和B:portB各自向對方發送一個一位元組的udp包，分別在自己的路由器上打下洞，從此A:portA和B:portB可進行udp通信；若B為類型4，則portB在與不同的ip:port通信時會不一樣，而A又要求知道portB的才可讓B:portB連進來，所以這種情況A只能猜測與A:portA通信的portB，通信概率小；
（4）、A為類型4；無論B為哪種類型，在A知道B之前都無法直接連接，B給S發一個打洞請求，S轉發該請求到A。若B的類型為1，則A:portA可直接tcp連接到B:portB；若B的類型為2，則B:portB先向A發送一個一位元組的udp包，在路由器上打洞，然後等待A:portA先發送數據，B:portB接收到A:portA的數據後，即知道portA，也可互通數據了；若B的類型為3，見（3）中B為類型4的描述；若B為4，雙方無法知道對方的埠，無法通信。
希望可以幫到你

❹ 廣域網實現p2p文件傳輸 如何實現nat穿透 求java或C++源代碼

假設有兩台分別處於各自的私有網路中的主機：A和B；N1和N2是兩個NAT設備；S是一個使用了一個眾所周知的、從全球任何地方都能訪問得到的IP地址的公共伺服器
步驟一：A和B分別和S建立UDP連接；NAT設備N1和N2創建UDP轉換狀態並分配臨時的外部埠號
步驟二：S將這些埠號傳回A和B
步驟三：A和B通過轉換好的埠直接聯繫到對方的NAT設備；NAT設備則利用先前創建的轉換狀態將分組發往A和B

源碼已發送請查收

❺ udp協議怎麼穿透Symmetric NAT

http://blog.csdn.net/jq0123/article/details/840302
NAT大致分為下面四類
1)
Full
Cone
這種NAT內部的機器A連接過外網機器C後,NAT會打開一個埠.然後外網的任何發到這個打開的埠的UDP數據報都可以到達A.不管是不是C發過來的.
例如
A:192.168.8.100
NAT:202.100.100.100
C:292.88.88.88
A(192.168.8.100:5000)
->
NAT(202.100.100.100
:
8000)
->
C(292.88.88.88:2000)
任何發送到
NAT(202.100.100.100:8000)的數據都可以到達A(192.168.8.100:5000)
2)
Restricted
Cone
這種NAT內部的機器A連接過外網的機器C後,NAT打開一個埠.然後C可以用任何埠和A通信.其他的外網機器不行.
例如
A:192.168.8.100
NAT:202.100.100.100
C:292.88.88.88
A(192.168.8.100:5000)
->
NAT(202.100.100.100
:
8000)
->
C(292.88.88.88:2000)
任何從C發送到
NAT(202.100.100.100:8000)的數據都可以到達A(192.168.8.100:5000)
3)
Port
Restricted
Cone
這種NAT內部的機器A連接過外網的機器C後,NAT打開一個埠.然後C可以用原來的埠和A通信.其他的外網機器不行.
例如
A:192.168.8.100
NAT:202.100.100.100
C:292.88.88.88
A(192.168.8.100:5000)
->
NAT(202.100.100.100
:
8000)
->
C(292.88.88.88:2000)
C(202.88.88.88:2000)發送到
NAT(202.100.100.100:8000)的數據都可以到達A(192.168.8.100:5000)
以上三種NAT通稱Cone
NAT.我們只能用這種NAT進行UDP打洞.
4)
Symmetic
對於這種NAT.連接不同的外部目標.原來NAT打開的埠會變化.而Cone
NAT不會.雖然可以用埠猜測.但是成功的概率很小.因此放棄這種NAT的UDP打洞.

❻ 詳解P2P技術中的NAT穿透原理(轉載)

課程地址：零聲學院 WebRTC入門與提高 https://ke.qq.com/course/435382?tuin=137bb271

技術支持QQ群：782508536

最近介入測試P2P的相關邏輯，因此對NAT穿透原理做了一定程度的了解（當然也沒有很深入）。本篇文章也是綜合和參考了些網路上和文獻里的一些資料（文中沒有對引用處進行標記，請見諒）。寫本文的目的就是，用自己的語言描述了這個過程，同時也在描述過程中加入了一些自己的理解，形成一篇文章作為要點的記錄。對於這一塊的知識，自己也有很多盲點，還請各路大神多多指教。

NAT（Network Address Translation，網路地址轉換），也叫做網路掩蔽或者IP掩蔽。NAT是一種網路地址翻譯技術，主要是將內部的私有IP地址（private IP）轉換成可以在公網使用的公網IP（public IP）。

時光回到上個世紀80年代，當時的人們在設計網路地址的時候，覺得再怎麼樣也不會有超過32bits位長即2的32次冪台終端設備連入互聯網，再加上增加ip的長度（即使是從4位元組增到6位元組）對當時設備的計算、存儲、傳輸成本也是相當巨大的。後來逐漸發現IP地址不夠用了，然後就NAT就誕生了！（雖然ipv6也是解決辦法，但始終普及不開來，而且未來到底ipv6夠不夠用仍是未知）。

因此，NAT技術能夠興起的原因還是因為在我們國家公網IP地址太少了，不夠用，所以才會採取這種地址轉換的策略。可見，NAT的本質就是讓一群機器公用同一個IP，這樣就暫時解決了IP短缺的問題。

優勢其實上面已經剛剛討論過了，根據定義，比較容易看出，NAT可以同時讓多個計算機同時聯網，並隱藏其內網IP，因此也增加了內網的網路安全性；此外，NAT對來自外部的數據查看其NAT映射記錄，對沒有相應記錄的數據包進行拒絕，提高了網路安全性。

那麼，NAT與此同時也帶來一些弊端：首先是，NAT設備會對數據包進行編輯修改，這樣就降低了發送數據的效率；此外，各種協議的應用各有不同，有的協議是無法通過NAT的（不能通過NAT的協議還是蠻多的），這就需要通過穿透技術來解決。我們後面會重點討論穿透技術。

簡單的背景了解過後，下面介紹下NAT實現的主要方式，以及NAT都有哪些類型。

1）靜態NAT：也就是靜態地址轉換。是指一個公網IP對應一個私有IP，是一對一的轉換，同時注意，這里只進行了IP轉換，而沒有進行埠的轉換。舉個栗子：

2）NAPT：埠多路復用技術。與靜態NAT的差別是，NAPT不但要轉換IP地址，還要進行傳輸層的埠轉換。具體的表現形式就是，對外只有一個公網IP，通過埠來區別不同私有IP主機的數據。再舉個栗子。

通過上面NAT實現方式的介紹，我們其實不難看出，現實環境中NAPT的應用顯然是更廣泛的。因此下面就重點介紹下NAPT的主要類型有哪些。

對於NAPT我們主要分為兩大類：錐型NAT和對稱型NAT。其中錐型NAT又分：完全錐型，受限錐型和埠受限錐型。概括的說：對稱型NAT是一個請求對應一個埠；錐型NAT（非對稱NAT）是多個請求（外部發向內部）對應一個埠，只要源IP埠不變，無論發往的目的IP是否相同，在NAT上都映射為同一個埠，形象的看起來就像錐子一樣。下面分別介紹這四種類型及其差異。

1）完全錐型NAT（Full Cone NAT，後面簡稱FC）

特點：IP和埠都不受限。

表現形式：將來自內部同一個IP地址同一個埠號（IP_IN_A : PORT_IN_A）的主機監聽/請求，映射到公網IP某個埠（IP_OUT_B : PORT_OUT_B）的監聽。任意外部IP地址與埠對其自己公網的IP這個映射後的埠訪問（IP_OUT_B : PORT_OUT_B），都將重新定位到內部這個主機（IP_IN_A : PORT_IN_A）。該技術中，基於C/S架構的應用可以在任何一端發起連接。是不是很繞啊。再簡單一點的說，就是，只要客戶端，由內到外建立一個映射（NatIP:NatPort -> A:P1）之後，其他IP的主機B或埠A:P2都可以使用這個洞給客戶端發送數據。見下圖（）。

2）受限錐型NAT（Restricted Cone NAT）

特點：IP受限，埠不受限。

表現形式：與完全錐形NAT不同的是，在公網映射埠後，並不允許所有IP進行對於該埠的訪問，要想通信必需內部主機對某個外部IP主機發起過連接，然後這個外部IP主機就可以與該內部主機通信了，但埠不做限制。舉個栗子。當客戶端由內到外建立映射(NatIP:NatPort –> A:P1)，A機器可以使用他的其他埠（P2）主動連接客戶端，但B機器則不被允許。因為IP受限啦，但是埠隨便。見下圖（綠色是允許通信，紅色是禁止通信）。

3）埠受限型NAT（Port Restricted Cone NAT）

特點：IP和埠都受限。

表現形式：該技術與受限錐形NAT相比更為嚴格。除具有受限錐形NAT特性，對於回復主機的埠也有要求。也就是說：只有當內部主機曾經發送過報文給外部主機（假設其IP地址為A且埠為P1）之後，外部主機才能以公網IP:PORT中的信息作為目標地址和目標埠，向內部主機發送UDP報文，同時，其請求報文的IP必須是A，埠必須為P1（使用IP地址為A，埠為P2，或者IP地址為B，埠為P1都將通信失敗）。例子見下圖。這一要求進一步強化了對外部報文請求來源的限制，從而較Restrictd Cone更具安全性。

4）對稱型NAT（Symmetric NAT）

特點：對每個外部主機或埠的會話都會映射為不同的埠（洞）。

表現形式：只有來自同一內部IP:PORT、且針對同一目標IP:PORT的請求才被NAT轉換至同一個公網（外部）IP:PORT，否則的話，NAT將為之分配一個新的外部（公網）IP:PORT。並且，只有曾經收到過內部主機請求的外部主機才能向內部主機發送數據包。內部主機用同一IP與同一埠與外部多IP通信。客戶端想和伺服器A（IP_A:PORT_A）建立連接，是通過NAT映射為NatIP:NatPortA來進行的。而客戶端和伺服器B（IP_B:PORT_B）建立連接，是通過NAT映射為NatIP:NatPortB來進行的。即同一個客戶端和不同的目標IP:PORT通信，經過NAT映射後的公網IP:PORT是不同的。此時，如果B想要和客戶端通信，也只能通過NatIP:NatPortB（也就是紫色的洞洞）來進行，而不能通過NatIP:NatPortA（也就是黃色的洞洞）。

以上，就是NAPT的四種NAT類型。可以看出由類型1）至類型4），NAT的限制是越來越大的。

根據上面的介紹，我們可以了解到，在實際的網路情況中，各個設備所處的網路環境是不同的。那麼，如果這些設備想要進行通信，首先判斷出設備所處的網路類型就是非常重要的一步。舉個例子來說：對於視頻會議和VoIP軟體，對位於不同NAT內部的主機通信需要靠伺服器來轉發完成，這樣就會增加伺服器的負擔。為了解決這種問題，要盡量使位於不同NAT內部的主機建立直接通信，其中，最重要的一點就是要判斷出NAT的類型，然後才能根據NAT的類型，設計出直接通信方案。不然的話，兩個都在NAT的終端怎麼通信呢？我們不知道對方的內網IP，即使把消息發到對方的網關，然後呢？網關怎麼知道這條消息給誰，而且誰允許網關這么做了？

為了解決這個問題，也就是處於內網的主機之間能夠穿越它們之間的NAT建立直接通信，已經提出了許多方法，STUN（Session Traversal Utilities for NAT，NAT會話穿越應用程序）技術就是其中比較重要的一種解決方法，並得到了廣泛的應用。在這個部分，我們將重點介紹下STUN技術的原理。（PS：除此之外，還有UPNP技術，ALG應用層網關識別技術，SBC會話邊界控制，ICE互動式連接建立，TURN中繼NAT穿越技術等等，本文不一一做介紹。）

STUN是一種網路協議，它允許位於NAT（或多重NAT）後的客戶端找出自己的公網地址，查出自己位於哪種類型的NAT之後以及NAT為某一個本地埠所綁定的Internet端埠。這些信息被用來在兩個同時處於NAT路由器之後的主機之間建立UDP通信。該協議由RFC 5389定義。STUN由三部分組成：STUN客戶端、STUN伺服器端、NAT路由器。STUN服務端部署在一台有著兩個公網IP的伺服器上。大概的結構參考下圖。STUN客戶端通過向伺服器端發送不同的消息類型，根據伺服器端不同的響應來做出相應的判斷，一旦客戶端得知了Internet端的UDP埠，通信就可以開始了。

STUN協議定義了三類測試過程來檢測NAT類型。

Test1： STUN Client通過埠{IP-C1:Port-C1}向STUN Server{IP-S1:Port-S1}發送一個Binding Request（沒有設置任何屬性）。STUN Server收到該請求後，通過埠{IP-S1:Port-S1}把它所看到的STUN Client的IP和埠{IP-M1,Port-M1}作為Binding Response的內容回送給STUN Client。 Test1#2：STUN Client通過埠{IP-C1:Port-C1}向STUN Server{IP-S2:Port-S2}發送一個Binding Request（沒有設置任何屬性）。STUN Server收到該請求後，通過埠{IP-S2:Port-S2}把它所看到的STUN Client的IP和埠{IP-M1#2,Port-M1#2}作為Binding Response的內容回送給STUN Client。

Test2： STUN Client通過埠{IP-C1:Port-C1}向STUN Server{IP-S1:Port-S1}發送一個Binding Request（設置了Change IP和Change Port屬性）。STUN Server收到該請求後，通過埠{IP-S2:Port-S2}把它所看到的STUN Client的IP和埠{IP-M2,Port-M2}作為Binding Response的內容回送給STUN Client。

Test3： STUN Client通過埠{IP-C1:Port-C1}向STUN Server{IP-S1:Port-S1}發送一個Binding Request（設置了Change Port屬性）。STUN Server收到該請求後，通過埠{IP-S1:Port-S2}把它所看到的STUN Client的IP和埠{IP-M3,Port-M3}作為Binding Response的內容回送給STUN Client。

STUN協議的輸出是： 1）公網IP和Port 2）防火牆是否設置 3）客戶端是否在NAT之後，及所處的NAT的類型

因此我們進而整理出，通過STUN協議，我們可以檢測的類型一共有以下七種：

A：公開的互聯網IP。主機擁有公網IP，並且沒有防火牆，可自由與外部通信 B：完全錐形NAT。 C：受限制錐形NAT。 D：埠受限制形NAT。 E：對稱型UDP防火牆。主機出口處沒有NAT設備,但有防火牆,且防火牆規則如下：從主機UDP埠A發出的數據包保持源地址，但只有從之前該主機發出包的目的IP/PORT發出到該主機埠A的包才能通過防火牆。 F：對稱型NAT G：防火牆限制UDP通信。

輸入和輸出准備好後，附上一張維基網路的流程圖，就可以描述STUN協議的判斷過程了。

STEP1：檢測客戶端是否有能力進行UDP通信以及客戶端是否位於NAT後 -- Test1 客戶端建立UDP socket，然後用這個socket向伺服器的（IP-1，Port-1）發送數據包要求伺服器返回客戶端的IP和Port，客戶端發送請求後立即開始接受數據包。重復幾次。 a）如果每次都超時收不到伺服器的響應，則說明客戶端無法進行UDP通信，可能是：G防火牆阻止UDP通信 b）如果能收到回應，則把伺服器返回的客戶端的（IP:PORT）同（Local IP: Local Port）比較： 如果完全相同則客戶端不在NAT後，這樣的客戶端是：A具有公網IP可以直接監聽UDP埠接收數據進行通信或者E。 否則客戶端在NAT後要做進一步的NAT類型檢測（繼續）。

STEP2：檢測客戶端防火牆類型 -- Test2 STUN客戶端向STUN伺服器發送請求，要求伺服器從其他IP和PORT向客戶端回復包： a）收不到伺服器從其他IP地址的回復，認為包前被前置防火牆阻斷，網路類型為E b）收到則認為客戶端處在一個開放的網路上，網路類型為A

STEP3：檢測客戶端NAT是否是FULL CONE NAT -- Test2 客戶端建立UDP socket然後用這個socket向伺服器的(IP-1,Port-1)發送數據包要求伺服器用另一對(IP-2,Port-2)響應客戶端的請求往回發一個數據包，客戶端發送請求後立即開始接受數據包。 重復這個過程若干次。 a）如果每次都超時，無法接受到伺服器的回應，則說明客戶端的NAT不是一個Full Cone NAT，具體類型有待下一步檢測（繼續）。 b）如果能夠接受到伺服器從(IP-2,Port-2)返回的應答UDP包，則說明客戶端是一個Full Cone NAT，這樣的客戶端能夠進行UDP-P2P通信。

STEP4：檢測客戶端NAT是否是SYMMETRIC NAT -- Test1#2 客戶端建立UDP socket然後用這個socket向伺服器的(IP-1,Port-1)發送數據包要求伺服器返回客戶端的IP和Port, 客戶端發送請求後立即開始接受數據包。 重復這個過程直到收到回應（一定能夠收到，因為第一步保證了這個客戶端可以進行UDP通信）。 用同樣的方法用一個socket向伺服器的(IP-2,Port-2)發送數據包要求伺服器返回客戶端的IP和Port。 比較上面兩個過程從伺服器返回的客戶端(IP,Port),如果兩個過程返回的(IP,Port)有一對不同則說明客戶端為Symmetric NAT，這樣的客戶端無法進行UDP-P2P通信（檢測停止）因為對稱型NAT，每次連接埠都不一樣，所以無法知道對稱NAT的客戶端，下一次會用什麼埠。否則是Restricted Cone NAT，是否為Port Restricted Cone NAT有待檢測（繼續）。

STEP5：檢測客戶端NAT是Restricted Cone 還是 Port Restricted Cone -- Test3 客戶端建立UDP socket然後用這個socket向伺服器的(IP-1,Port-1)發送數據包要求伺服器用IP-1和一個不同於Port-1的埠發送一個UDP 數據包響應客戶端, 客戶端發送請求後立即開始接受數據包。重復這個過程若干次。如果每次都超時，無法接受到伺服器的回應，則說明客戶端是一個Port Restricted Cone NAT，如果能夠收到伺服器的響應則說明客戶端是一個Restricted Cone NAT。以上兩種NAT都可以進行UDP-P2P通信。

通過以上過程，至此，就可以分析和判斷出客戶端是否處於NAT之後，以及NAT的類型及其公網IP，以及判斷客戶端是否具備P2P通信的能力了。當然這是自己個人筆記的第一篇，後面，再作一篇筆記《NAT穿透原理淺析（二）》分析下不同NAT類型的穿透打洞策略。