陳恒勛 閆永航 孟丹 夏倫

摘? 要：NAT是一種在IP數(shù)據(jù)包通過路由器或防火墻時(shí)重寫源IP地址或目的IP地址的技術(shù)，作為一種解決IPv4地址短缺的方案而流行起來，但卻阻礙了以P2P網(wǎng)絡(luò)為基礎(chǔ)的應(yīng)用的發(fā)展。為解決這一問題，各種NAT穿越技術(shù)應(yīng)運(yùn)而生，文章基于不同場景視角闡述四種主流的NAT穿越方案，包括UDP打洞技術(shù)、STUN協(xié)議、TURN協(xié)議和ICE框架，并說明了各方案的研究進(jìn)展。

關(guān)鍵詞：NAT穿越;UDP打洞;STUN;TURN;ICE

中圖分類號：TP393? ? ? 文獻(xiàn)標(biāo)識碼：A 文章編號：2096-4706（2020）06-0094-05

Abstract：Network Address Translation （NAT） is a technology that rewrites a source IP address or a destination IP address when an IP data packet passes through a router or firewall. NAT is popular as a solution to the shortage of IPv4 addresses，but it has hindered the development of applications based on P2P networks. In order to solve this problem，various NAT traversal technologies have emerged at the historic moment. This paper describes four mainstream NAT traversal solutions based on different scenarios，including UDP hole punching technology，STUN protocol，TURN protocol and ICE framework，and then describes the research progress of each scheme.

Keywords：NAT traversal;UDP hole punching;STUN;TURN;ICE

0? 引? 言

1994年，網(wǎng)絡(luò)地址轉(zhuǎn)換（Network Address Translation，NAT）[1]作為一種解決IPv4地址短缺的方案流行起來，在許多國家廣泛使用。時(shí)至今日，NAT成為了家庭和中小型辦公室路由器上的一個(gè)標(biāo)準(zhǔn)實(shí)現(xiàn)。雖然NAT提供了許多益處，但仍存在許多缺點(diǎn)，其最大的缺點(diǎn)就是使用了NAT設(shè)備私有網(wǎng)絡(luò)中的主機(jī)連接問題。在傳統(tǒng)的P2P網(wǎng)絡(luò)中，端到端通信的兩臺(tái)主機(jī)之間的地位是平等的，參與通信的兩臺(tái)主機(jī)均可主動(dòng)發(fā)起連接[2]。但NAT設(shè)備卻使得外網(wǎng)的主機(jī)無法主動(dòng)訪問私有網(wǎng)絡(luò)中的主機(jī)，從而破壞了這種通信平等，這一問題嚴(yán)重地阻礙了P2P應(yīng)用的發(fā)展[3]。

為了解決上述問題，NAT穿越技術(shù)應(yīng)運(yùn)而生，其中UDP打洞、TCP打洞及STUN技術(shù)可有效穿越非對稱型的NAT設(shè)備，而TURN技術(shù)通過服務(wù)器中繼轉(zhuǎn)發(fā)可以解決上述方法無法解決的對稱型NAT穿越問題。盡管有許多穿越NAT的技術(shù)，但沒有一種是完美的，所以后來又出現(xiàn)了ICE這類框架，使各種NAT穿越技術(shù)可以實(shí)現(xiàn)統(tǒng)一，最大程度地保障了NAT穿越的可行性。本文以河南大學(xué)計(jì)算機(jī)網(wǎng)絡(luò)課程為基礎(chǔ)，對NAT穿越技術(shù)展開研究，首先闡述NAT的基本概念和類型，之后描述各種實(shí)現(xiàn)NAT穿越的解決方案。

1? NAT類型

根據(jù)NAT設(shè)備內(nèi)部地址映射的表現(xiàn)不同，可將NAT分為四類，即完全錐型（Full Cone）、限制錐型（Restricted Cone）、端口限制型（Port Restricted Cone）和對稱型（Sym- metric）[4]。

（1）完全錐型：將來自相同內(nèi)部IP地址和端口的所有請求都映射到同一個(gè)外部IP地址和端口。任何外部主機(jī)都可以通過向映射后的外部地址發(fā)送數(shù)據(jù)包實(shí)現(xiàn)與內(nèi)部主機(jī)通信。

（2）限制錐型：將來自同一內(nèi)部IP地址和端口的所有的請求都映射到同一個(gè)外部IP地址和端口。但與完全錐型NAT不同，假設(shè)外部主機(jī)擁有IP地址X，只有當(dāng)內(nèi)部主機(jī)先前與IP地址X發(fā)送過數(shù)據(jù)包，內(nèi)部主機(jī)才能接收到外部主機(jī)發(fā)送的數(shù)據(jù)包。

（3）端口限制型：與限制錐型NAT相似，但是增加了對端口的限制。詳細(xì)來說，假設(shè)一個(gè)外部主機(jī)發(fā)送的數(shù)據(jù)包擁有IP地址X源端口號Y，則只有當(dāng)內(nèi)部主機(jī)先前與（IP：X，Port：Y）發(fā)送過數(shù)據(jù)包，內(nèi)部主機(jī)才能接收到外部主機(jī)發(fā)送的數(shù)據(jù)包。

（4）對稱型：來自相同IP地址和端口且傳送至同一目的IP地址和端口的所有請求都映射為同一個(gè)外部IP地址和端口。如果主機(jī)通過相同的IP地址和端口向不同的目的地發(fā)送數(shù)據(jù)包，那么將產(chǎn)生不同的映射。而且只有先前收到內(nèi)部主機(jī)數(shù)據(jù)包的外部主機(jī)才能向內(nèi)部主機(jī)成功發(fā)送數(shù)據(jù)包。

2? NAT穿越方案

2.1? UDP打洞

UDP打洞技術(shù)的核心在于將請求對等方時(shí)的映射添加至地址映射表，以保證后續(xù)的數(shù)據(jù)包可達(dá)。這種穿越方案需要具有公網(wǎng)IP地址的第三方服務(wù)器進(jìn)行協(xié)助。我們假定主機(jī)A與主機(jī)B進(jìn)行通信，兩主機(jī)均已與第三方服務(wù)器建立連接，第三方服務(wù)器已獲得此連接請求中雙方主機(jī)的映射地址與端口，下面按照四種情況分別給出穿越策略[5，6]。

（1）情況1：主機(jī)A（或B）具有公網(wǎng)IP，另一主機(jī)處于私網(wǎng)中。假設(shè)主機(jī)A具有公網(wǎng)IP，此時(shí)主機(jī)A想要向主機(jī)B發(fā)送數(shù)據(jù)包，因?yàn)橹鳈C(jī)B位于NAT后且先前主機(jī)B未與主機(jī)A發(fā)送過消息，所以此數(shù)據(jù)包會(huì)被丟棄。這時(shí)主機(jī)A只能向第三方服務(wù)器請求打洞。第三方服務(wù)器指示主機(jī)B向主機(jī)A發(fā)送打洞消息，因?yàn)橹鳈C(jī)A位于公網(wǎng)，所以主機(jī)A可以正確接收消息，當(dāng)主機(jī)A接收到打洞消息后，按此消息中的源地址與源端口號回復(fù)應(yīng)答消息，因?yàn)橹鳈C(jī)B發(fā)送打洞消息時(shí)，地址映射表中已經(jīng)具有主機(jī)A的表項(xiàng)，所以主機(jī)B也能正確接收應(yīng)答消息。這種打洞方式也稱為反向連接。

（2）情況2：主機(jī)A（或B）在完全錐型或限制錐型NAT后，另一主機(jī)在任意類型NAT后。兩主機(jī)均位于NAT后，若此前未互通消息，則任一主機(jī)發(fā)消息均會(huì)被丟棄。如圖1所示，假設(shè)NATA是完全錐型或限制錐型，此時(shí)主機(jī)A想與主機(jī)B通信，主機(jī)A首先向服務(wù)器請求主機(jī)B映射后的公網(wǎng)地址，并向此公網(wǎng)地址定時(shí)發(fā)送打洞消息，此時(shí)主機(jī)A的地址映射表中就包含了請求主機(jī)B的表項(xiàng)，然后主機(jī)A請求服務(wù)器協(xié)助打洞，服務(wù)器將主機(jī)A映射后的公網(wǎng)地址發(fā)送給主機(jī)B并指示主機(jī)B向主機(jī)A發(fā)送打洞消息，此時(shí)主機(jī)B的地址映射表中也有了請求主機(jī)A的表項(xiàng)，主機(jī)A和主機(jī)B均可接收到對方的打洞消息，通信線路建立。

（3）情況3：主機(jī)A、B均在端口限制型NAT后。采用情況2的方法，由于兩主機(jī)地址映射后的端口未發(fā)生改變，所以打洞依然可以成功。

（4）情況4：主機(jī)A（或B）在端口限制型或?qū)ΨQ型NAT后，另一主機(jī)在對稱型NAT后。文獻(xiàn)[7]給出了一種基于UDP打洞的通信實(shí)現(xiàn)。由于位于對稱型NAT后的主機(jī)的映射端口會(huì)隨著數(shù)據(jù)包中目標(biāo)地址與目標(biāo)端口的改變而發(fā)生變化，UDP打洞方法不適用于對稱型NAT。周敏等[8]將UDP打洞與HTTP代理相結(jié)合實(shí)現(xiàn)了對稱型NAT和UDP報(bào)文受阻的穿越，保證了即使只允許HTTP傳輸?shù)腘AT也可實(shí)現(xiàn)穿越。劉繼明等[9]根據(jù)對稱型NAT的特性，采用端口預(yù)測機(jī)制實(shí)現(xiàn)了對稱性NAT的穿越，端口預(yù)測機(jī)制僅適用于增量型的NAT分配策略，當(dāng)NAT隨機(jī)分配端口時(shí)，此機(jī)制不能正常工作。邱耀群等[10]對對稱性NAT采用小范圍端口預(yù)測機(jī)制，在實(shí)驗(yàn)結(jié)果中使小范圍隨機(jī)型NAT達(dá)到了100%的成功率。

2.2? STUN

STUN[11]是一個(gè)輕量級的NAT穿越協(xié)議，它提供了一個(gè)標(biāo)準(zhǔn)的NAT類型檢測方法并允許主機(jī)得知自己被NAT分配的映射地址和端口，它可以在兩主機(jī)間具有任意數(shù)量的NAT時(shí)正常工作，解決了兩個(gè)重要問題：

（1）獲得主機(jī)映射后地址與端口。STUN Client向STUN Server發(fā)送Binding Request，Binding Request是STUN定義的一種消息類型，當(dāng)此請求到達(dá)STUN Server時(shí)，它可能經(jīng)過了一個(gè)或多個(gè)NAT，因?yàn)楫?dāng)Binding Request經(jīng)過NAT時(shí)，NAT會(huì)更改數(shù)據(jù)包中的源地址和源端口號，結(jié)果Server接收到的數(shù)據(jù)包中的源地址和源端口號就是最靠近Server的NAT分配的公網(wǎng)IP和端口號。STUN Server將此傳輸?shù)刂房截愔罛inding Response的XOR-MAPPED-ADDRESS屬性中，并發(fā)送至STUN Client。之后STUN Client就可以得知其最外層NAT分配的映射公網(wǎng)地址與端口。

（2）檢測NAT類型：

前提條件：STUN Server具有兩個(gè)公網(wǎng)IP，假設(shè)為（IP1，Port1）（IP2，Port2）。

以下為NAT類型檢測的流程：

步驟1：選擇STUN Server的（IP1，Port1），經(jīng)過（1）中的交互后STUN Client獲得映射后地址與端口，將此地址和端口與發(fā)送此數(shù)據(jù)包時(shí)的本地地址與端口比較。如果不匹配，說明STUN Client在NAT后，否則，STUN Client具有公網(wǎng)地址。

步驟2：STUN Client向（IP2，Port2）再次發(fā)送Binding Request，如果應(yīng)答中的地址與端口與步驟1中的地址與端口不匹配，則Client位于對稱型NAT后，否則繼續(xù)步驟3。

步驟3：STUN Client向（IP1，Port1）發(fā)送Binding Request并攜帶改變IP和端口的Flag，STUN Server根據(jù)Flag用（IP2，Port2）向源地址發(fā)送Binding Response，若STUN Client接收到此應(yīng)答消息，則Client位于完全錐型NAT后，否則繼續(xù)步驟4。

步驟4：STUN Client向（IP1，Port1）發(fā)送Binding Request并僅攜帶改變端口的Flag，STUN Server根據(jù)Flag用（IP2，Port2）向源地址發(fā)送Binding Response，若STUN Client接收到此應(yīng)答消息，則Client位于限制錐型NAT后，否則位于端口限制型NAT后。

解決上述兩個(gè)問題后，就可根據(jù)UDP打洞策略擴(kuò)展STUN協(xié)議，實(shí)現(xiàn)NAT穿越。STUN在穿越環(huán)節(jié)需要大量信息交換，所以造成了有效數(shù)據(jù)的傳輸滯后，文獻(xiàn)[12]將數(shù)據(jù)庫技術(shù)應(yīng)用于STUN中，數(shù)據(jù)庫存儲(chǔ)公私網(wǎng)映射條目，簡化了STUN的交互過程，提高了15%的有效數(shù)據(jù)傳輸率。文獻(xiàn)[13]將UPnP與STUN結(jié)合，通過運(yùn)用UPnP服務(wù)增加了NAT穿越的成功率。

2.3? TURN

TURN是一種使用中繼手段實(shí)現(xiàn)NAT穿越的方案。它允許主機(jī)使用中繼手段與對等方交換數(shù)據(jù)包，允許一個(gè)客戶端使用一個(gè)中繼地址與多個(gè)對等方通信。TURN協(xié)議可以實(shí)現(xiàn)所有類型的NAT穿越，包括對稱型NAT穿越，但它實(shí)現(xiàn)穿越的代價(jià)是增加服務(wù)器的帶寬負(fù)擔(dān)。

如圖2的網(wǎng)絡(luò)拓?fù)?，TURN的交互流程[14]大致如下：

Client可以使用主機(jī)傳輸?shù)刂钒l(fā)送TURN消息至TURN Server，消息經(jīng)過NAT時(shí)，源地址與端口會(huì)被映射為服務(wù)器反射傳輸?shù)刂?。在?shí)現(xiàn)中繼的過程中，Client首先使用TURN命令在Server上創(chuàng)建一個(gè)Allocation，Allocation是一個(gè)數(shù)據(jù)結(jié)構(gòu)，其中包含了Server為Client與Peers實(shí)現(xiàn)通信而分配的中繼傳輸?shù)刂?，Peers可以使用此傳輸?shù)刂分欣^數(shù)據(jù)至Client。一個(gè)中繼傳輸?shù)刂穼?yīng)一個(gè)唯一的Allocation。

當(dāng)Allocation建立后，Client可以使用TURN消息發(fā)送數(shù)據(jù)至Server并指示發(fā)送至哪一個(gè)Peer，Server根據(jù)指示中繼此數(shù)據(jù)至相應(yīng)的Peer。而Peer可以將數(shù)據(jù)發(fā)送至一個(gè)與Allocation對應(yīng)的中繼傳輸?shù)刂?，Server收到數(shù)據(jù)后將數(shù)據(jù)包裝成TURN消息，中繼至相應(yīng)的Client。這就實(shí)現(xiàn)了一次對等主機(jī)間的交互。每一個(gè)Allocation只屬于一個(gè)Client，且只包含一個(gè)中繼傳輸?shù)刂?。因此，?dāng)數(shù)據(jù)包到達(dá)Server的中繼傳輸?shù)刂窌r(shí)，Server可以識別出數(shù)據(jù)包對應(yīng)的Client。

文獻(xiàn)[15]在TURN協(xié)議上增加了對IPv6的支持，實(shí)現(xiàn)了IPv4至IPv6、IPv6至IPv4和IPv6至IPv6的中繼方案。文獻(xiàn)[16]在原標(biāo)準(zhǔn)中加入了TCP Allocation，為Client分配TCP端口提供了一種解決方案。文獻(xiàn)[17]將自動(dòng)發(fā)現(xiàn)機(jī)制加入至原有的標(biāo)準(zhǔn)中，避免了手動(dòng)配置的必要，增強(qiáng)了TURN的可移植性。

2.4? ICE

當(dāng)前已經(jīng)有許多協(xié)議可以實(shí)現(xiàn)NAT穿越，如ALGs、STUN、TURN等，但是這些方案都具有一定的局限性，在應(yīng)用的實(shí)現(xiàn)中更是呈現(xiàn)出零零散散的狀態(tài)。于是，ICE作為一種NAT穿越的整合框架被定義出來。

ICE[18]是一個(gè)使用SDP offer/answer模型[19]建立的基于UDP的多媒體會(huì)話的NAT穿越協(xié)議。ICE使用STUN協(xié)議及其擴(kuò)展TURN協(xié)議，其背后的基本思想是：每一個(gè)Agent，即主機(jī)，都具有不同類型的候選傳輸?shù)刂?，用來使用這些地址同其他Agent進(jìn)行通信。這些候選傳輸?shù)刂房赡苁且韵聨追N：

（1）直接與網(wǎng)絡(luò)接口相聯(lián)系的傳輸?shù)刂贰?/p>

（2）位于NAT公共側(cè)的服務(wù)器反射傳輸?shù)刂贰?/p>

（3）TURN Server分配的中繼傳輸?shù)刂贰?/p>

ICE的工作流程如下：

（1）收集候選地址。為執(zhí)行ICE，Agent需要識別自己所有的Candidate。這些Candidate的關(guān)系如圖3所示。首先，Host Candidate與本地網(wǎng)絡(luò)接口相聯(lián)系，十分容易確定，需要注意的是Host Candidate可能有多個(gè)。其次，Agent可以通過STUN或TURN獲得其他的Candidate，這些Candidate包括Server Reflexive Candidate和Relayed Transport Candidate。當(dāng)TURN Server被使用時(shí)，這兩種Candidate均可通過TURN Server獲得，但如果僅僅使用了STUN Server，則只能從中獲得Server Reflexive Candidate。在圖3中，X：x為Host Candi-date，Y：y為Server Reflexive Candidate，而Z：z是TURN Server分配給Agent的Relayed Transport Candidate。

（2）連接性檢測。一旦Agent獲得它所有的Candidate，它就對其以從高到低的優(yōu)先級進(jìn)行排序，并將這些Candidate放入SDP offer中發(fā)送給要進(jìn)行通信的另一方Agent。當(dāng)另一方收到此Offer，也會(huì)進(jìn)行相同的處理，將自身的Candidate列表作為應(yīng)答送回。最終兩Agent均具有自身及對方的所有Candidate。他們將兩列表中的Candidate兩兩組合形成一個(gè)Check List。列表中的每一個(gè)Check都是一次STUN Request/Response交互，其中STUN Request從Local Candidate發(fā)往Remote Candidate。

連接性檢測的基本準(zhǔn)則十分簡單：

（1）使用特定算法對 進(jìn)行優(yōu)先級排序;

（2）根據(jù)優(yōu)先級順序在每一Candidate Pairs間發(fā)送Check消息;

（3）從其他Agent接收Check確認(rèn)。

實(shí)際上，Candidate Pairs的一次檢測過程即是一個(gè)四次握手的交互過程，如圖4所示。

（3）斷定ICE。在連接性檢測過程中會(huì)出現(xiàn)連接成功的Candidate Pair，ICE安排兩Agent之一來確認(rèn)用來進(jìn)行后續(xù)媒體通信的合法Candidate Pair，此Agent稱為Controlling Agent。確認(rèn)最終Candidate Pair有兩種策略，即Regular Nomination和Aggressive Nomination。前者是在Controlling Agent找到合法的Pair后再發(fā)送一個(gè)額外的STUN Request，并在請求中添加完成標(biāo)志以告知另一Agent。而后者則要求Controlling Agent的每一個(gè)STUN Request都帶有完成標(biāo)志，第一次檢測成功后，Controlling Agent就無需再發(fā)送額外的請求，這種方式更加快速，但缺乏靈活性。在找到合法的Candidate Pair后通信雙方就可以順利地進(jìn)行后續(xù)的媒體通信。

文獻(xiàn)[20]使用NAT類型對連通性檢測過程進(jìn)行制約，避免了多余的地址對檢測，縮短了連通性檢測時(shí)間。文獻(xiàn)[21]則調(diào)整了檢測過程，將收集-檢測過程分類多次執(zhí)行，盡可能減少對候選地址的收集，減少了連通性檢測時(shí)間，提高了NAT穿透效率。

3? 結(jié)? 論

本文總結(jié)提煉一些主流可行的NAT穿越技術(shù)，首先說明NAT產(chǎn)生的背景以及其對P2P網(wǎng)絡(luò)通信帶來的問題，之后詳細(xì)地闡述的NAT的不同類型，剖析了不同類型NAT所具有的特性，最后詳細(xì)描述了四種NAT穿越方案，即UDP打洞、STUN協(xié)議、TURN協(xié)議和ICE框架，并說明了各方案近期的研究進(jìn)展。其中UDP打洞簡單易實(shí)現(xiàn)，但欠缺安全性且不能穿透對稱型NAT;STUN協(xié)議靈活易擴(kuò)展，且可以實(shí)現(xiàn)多級NAT穿越，但不可實(shí)現(xiàn)對稱型NAT穿越;TURN協(xié)議可以實(shí)現(xiàn)任何類型的NAT穿越但會(huì)增加服務(wù)器的帶寬負(fù)擔(dān);ICE整合了多種NAT穿越協(xié)議，安全可靠、局限性小但是實(shí)現(xiàn)相對復(fù)雜。本文為具有P2P通信需求的應(yīng)用程序提供了一系列靈活有效的方案實(shí)現(xiàn)NAT穿越，在實(shí)際應(yīng)用中可根據(jù)所處的網(wǎng)絡(luò)環(huán)境，選擇合適的解決方案以滿足項(xiàng)目需求。

參考文獻(xiàn)：

[1] SRISURESH P，EGEVANG K. Traditional IP Network Address Translator （Traditional NAT） [M]. RFC Editor，2001：1-2.

[2] 賀文華，劉浩，賀勁松.P2P網(wǎng)絡(luò)現(xiàn)狀與發(fā)展研究 [J].軟件工程，2019，22（4）：1-5.

[3] 曹申會(huì).NAT穿越技術(shù)的研究與實(shí)現(xiàn) [D].南京：南京郵電大學(xué)，2013：8-11.

[4] ROSENBERG J，WEINBERGER J，HUITEMA C，et al.STUN-Simple traversal of user datagram protocol （UDP） through network address translators （NATs） [J]. Ietf Rfc，2003：5-6.

[5] 姚秋紅.基于P2P的網(wǎng)絡(luò)視頻會(huì)議系統(tǒng)的研究和開發(fā) [D].上海：上海交通大學(xué)，2010：38-40.

[6] FORD B，SRISURESH P，KEGEL D. Peer-to-Peer Communication Across Network Address Translators [C]. USENIX Annual Technical Conference，Anaheim，CA，2005：13.

[7] 李自薦，趙順，劉宏，等.P2P網(wǎng)絡(luò)通信中NAT穿越技術(shù)的研究及實(shí)現(xiàn) [J].數(shù)字技術(shù)與應(yīng)用，2015（8）：34-35.

[8] 周敏，余慕春，黃維豐.綜合UDP打洞與Http代理的SIP穿越NAT方案 [J].計(jì)算機(jī)技術(shù)與發(fā)展，2014，24（8）：147-151+156.

[9] 劉繼明，馬樂，李波.一種基于NAT穿越的優(yōu)化STUN算法 [J].西安郵電大學(xué)學(xué)報(bào)，2019，24（3）：19-24.

[10] 邱耀群，金光，江先亮，等.對稱型NAT穿越技術(shù)的研究 [J].移動(dòng)通信，2015，39（7）：57-60+65.

[11] ROSENBERG J，MAHY R，MATTHEWS P，et al.Session traversal utilities for NAT （STUN）：RFC 5389 [S].IETF，2008：5-8.

[12] 楊金花.STUN技術(shù)通信問題的研究 [J].電子設(shè)計(jì)工程，2015，23（6）：92-94+98.

[13] 任浩，王勁林，魯逸峰.UPnP和STUN相結(jié)合的NAT穿越技術(shù)研究 [J].計(jì)算機(jī)工程與應(yīng)用，2009，45（2）：99-101.

[14] MAHY R，MATTHEWS P，ROSENBERG J.Traversal Using Relays around NAT （TURN）：Relay Extensions to Session Traversal Utilities for NAT （STUN）：RFC 5766 [S].IETF，2010：5-11.

[15] CAMARILLO G，NOVO O，PERREAULT S.Traversal using relays around NAT （TURN） extension for IPv6：RFC 6156 [S].IETF，2011：4-10.

[16] PERREAULT S，ROSENBERG J.Traversal using relays around NAT （TURN） extensions for TCP allocations：RFC 6062 [S].IETF，2010：6-11.

[17] PATIL P，REDDY T，WING D，.Traversal using relays around NAT （TURN） server auto discovery：RFC 8155 [S].IETF，2017：4-9.

[18] ROSENBERG J.Interactive connectivity establishment （ICE）：A protocol for network address translator （NAT） traversal for Offer/Answer protocols：RFC 5245 [S].IETF，2010：6-16.

[19] ROSENBERG J，SCHULZRINNE H.An Offer/Answer model with the session description protocol （SDP）：RFC 3264 [S].IETF，2002：3-5.

[20] 王夢杰，何加銘.基于ICE的SIP穿越NAT方法的研究 [J].移動(dòng)通信，2015，39（2）：45-50.

[21] 劉繼明，王逸凡，呂芳，等.一種優(yōu)化連接速率的ICE算法實(shí)現(xiàn) [J].西安郵電大學(xué)學(xué)報(bào)，2017，22（6）：92-97.

作者簡介：陳恒勛（1998-），男，漢族，河南商丘人，本科在讀，研究方向：移動(dòng)Adhoc網(wǎng)絡(luò);通訊作者：閆永航（1981-），男，漢族，河南周口人，副教授，研究生導(dǎo)師，博士，研究方向：互聯(lián)網(wǎng)體系結(jié)構(gòu)、移動(dòng)Ad hoc網(wǎng)絡(luò)、網(wǎng)絡(luò)安全、物聯(lián)網(wǎng)、區(qū)塊鏈;孟丹（1995-），女，漢族，河南商丘人，碩士研究生，研究方向：網(wǎng)絡(luò)體系結(jié)構(gòu);夏倫（1996-），男，漢族，河南信陽人，碩士研究生，研究方向：網(wǎng)絡(luò)體系結(jié)構(gòu)。