CN105141711B - 一种基于大数据分析的对称nat穿越方法及系统 - Google Patents

Abstract

本发明提供一种在P2P应用中基于大数据分析实现对称NAT穿越的方法与系统，包括：处于对称NAT之后的用户节点将NAT的内、外网IP与端口信息发往NAT端口分析服务器；分析服务器若查找到端口分配规则，则返回端口预测列表给用户节点；若未找到则返回失败信息，用户节点随即向STUN服务器群发起绑定请求并将获得的NAT端口分配信息发送给分析服务器以获得端口预测列表；用户节点交换彼此IP及端口信息并开始协商与穿越；成功穿越之后将NAT最新端口分配信息发送至分析服务器。本发明在提升对称NAT穿越成功率与效率的同时还降低了用户节点的端口预测性能消耗。简便的引擎策略更新、维护方式则体现了灵活性与可维护性。

Description

一种基于大数据分析的对称NAT穿越方法及系统

技术领域

一般而言，本发明涉及数据通信领域。具体地讲，本发明涉及一种基于大数据分析的对称网络地址转换(Network Address Translation，NAT)设备穿越方案应用于点对点(Peer-to-Peer，P2P)通信模式的网络应用系统之中，属于网络实时数据传输技术领域。

背景技术

随着互联网技术与业务的飞速发展，可分配的IPv4地址空间几经枯竭。NAT设备应运而生，它既缓解了IP地址空间不足的困境，又带来了隐藏并保护网络内部计算机避免外部攻击的好处。因而时至今日，NAT设备大行其道。但同时它也违反了IP地址结构模型的设计原则与基本的网络分层结构模型的设计原则。对那些P2P应用的直接通信造成了极大的障碍。许多诸如实时多媒体通信、游戏类应用却要求位于NAT之后的节点能够直接通信，从而达到提升数据包传输速率、降低延迟、削减服务器带宽成本支出的目的。目前穿越NAT设备的常用方法大致分为以下几种：

1、uPNP协议实现穿越

其实现原理是动态创建端口映射规则，前提则需要连接客户端和NAT设备本身支持uPNP协议。uPNP穿越的最大局限在于NAT设备的支持。无法大规模应用于现今互联网的实际环境之中。

2、ALG方式(Application Layer Gateways)

ALG主要完成了对应用层报文的处理，通常情况下NAT只对报头中的IP、PORT(端口)信息进行转换，不对应用层数据载荷中的字段进行分析，如果开启了ALG，那么在识别了相应报文之后便会对IP报头以外的载荷信息进行解析，然后进行地址转换，重新计算校验和。具体的来说，ALG可以处理的协议有如下这些：DNS，FTP，H323，SIP，HTTP，ILS，MSN/QQ，NBT，RTSP，PPTP，TFTP、GRE等。使用该穿越技术，则需要NAT转换设备进行升级，否则无法支持。对于个别协议该技术无法解决问题，如IPSEC协议。

3、MIDCOM方式

与NAT/ALG不同的是，MIDCOM的基本框架是采用可信的第三方(MIDCOM Agent)对Middlebox(NAT/FW)进行控制，VOIP协议的识别不由Middlebox(中间盒)完成，而是由外部的MIDCOM Agent完成，因此VOIP使用的协议对Middlebox是透明的。在安全性上，MIDCOM方式可支持控制报文的加密，可支持媒体流的加密，因此安全性比较高。但由于要求现有的NAT/FW设备需升级支持MIDCOM协议，从这一点上来说，对已大量部署的NAT/FW设备来说，也是很困难的，同NAT/ALG方式有相同的问题。

4、STUN技术(Simple Traversal of User Datagram Protocol Through NetworkAddress Translators)

该穿越技术主要是借助UDP协议进行UDP打洞，相应RFC可以参考RFC 3489和RFC5398，仅按照上述协议则只能在非对称NAT情况下成功穿越。它的优势是无需对设备进行改造、升级。在RFC3489/STUN[1]中，基于UDP的NAT穿透技术把主机划分为如下七种NAT类型UDP Blocked、Open Intemet、Symmetric Firewall、Full Cone NAT、Restricted ConeNAT、Port Restricted Cone NAT、Symmetric NAT。

(1)Open Intemet：主机具有公网IP，允许主动发起和被动响应两种方式的UDP通信。

(2)UDP Blocked：位于防火墙之后，并且防火墙阻止了UDP通信。

(3)Symmetric Firewall：主机具有公网IP，但位于防火墙之后，且防火墙阻止了外部主机的主动UDP通信。

(4)Full Cone NAT：当内网主机创建一个UDP socket并通过它第一次向外发送UDP数据包时，NAT会为之分配一个固定的公网{IP：端口}。此后，通过这个socket发送的任何UDP数据包都是通过这个公网{IP：端口}发送出去的；同时，任何外部主机都可以使用这个公网{IP：端口}向该socket发送UDP数据包。即是说，NAT维护了一个映射表，内网主机的内网{IP：端口}与公网{IP：端口}是一一对应的关系。一旦这个映射关系建立起来(内部主机向某一外部主机发送一次数据即可)，任何外部主机就可以直接向NAT内的这台主机发起UDP通信了，此时NAT透明化了。

(5)Restricted ConeNAT(受限锥型NAT)：当内网主机创建一个UDP socket并通过它第一次向外发送UDP数据包时，NAT会为之分配一个公网{IP：端口}。此后，通过这个socket向外发送的任何UDP数据包都是通过这个公网{IP：端口}发送出去的；而任何收到过从这个socket发送来的数据的外部主机(由IP标识)，都可以通过这个公网{IP：端口}向该socket发送UDP数据包。即是说，NAT维护了一个内网{IP：端口}到公网{IP：端口}的映射，还维护了一个{外部主机 IP，公网{IP：端口}}到内网{IP：端口}的映射。因此，要想外部主机能够主动向该内部主机发起通信，必须先由该内部主机向这个外部发起一次通信。

(6)Port Restricted Cone NAT(端口限制锥型NAT)：当内网主机创建一个UDPsocket并通过它第一次向外发送UDP数据包时，NAT会为之分配一个公网{IP：端口}。此后，通过这个socket向外部发送的任何UDP数据包都是通过这个公网{IP：端口}发送出去的；一旦外部主机在{IP：端口}上收到过从这个socket发送来的数据后，都可以通过这个外部主机{IP：端口}向该socket发送UDP数据包。即是说，NAT维护了一个从内网{IP：端口}到公网{IP：端口}的映射，还维护了一个从{外部主机{IP：端口}，公网{IP：端口}}到内网{IP：端口}的映射。

(7)Symmetrict NAT(对称NAT)：当内网主机创建一个UDP socket并通过它第一次向外部主机1发送UDP数据包时，NAT为其分配一个公网{IP1：端口1}，以后内网主机发送给外部主机1的所有UDP数据包都是通过公网{IP1：端口1}发送的；当内网主机通过这个socket向外部主机2发送UDP数据包时，NAT为其分配一个公网{IP2：端口2}，以后内网主机发送给外部主机2的所有UDP数据包都是通过公网{IP2：端口2}发送的。公网{IP1：端口1}和公网{IP2：端口2}一定不会完全相同(即要么IP不同，要么端口不同，或者都不同)。这种情况下，外部主机只能在接收到内网主机发来的数据时，才能向内网主机回送数据。

UDP Blocked及Symmetric Firewall不作为本发明涉及之列。还剩下三种锥型NAT(即全锥NAT、受限锥型NAT、端口限制锥型NAT)、公网IP以及对称型NAT五种类型。利用STUN协议，可以满足对前四种类型接入网络得设备之间的穿越。但对于对称型NAT却无能为力。作为本发明的前置条件，需要先探明用户节点所处的NAT类型。具体检测方法可以根据RFC3489中的描述按照下述步骤执行：

位于NAT之后的用户终端的STUN协议模块向STUN服务器发起一系列绑定请求。以某台STUN服务器为例，分别在77.72.169.211的3478及3479，以及在77.72.169.212的3478及3479等4个端口上提供STUN服务。STUN协议模块分别按照如下步骤发送STUN绑定请求(请参考图3)：

步骤1011.开始TEST1测试，STUN协议模块向77.21.169.211：3478发送绑定请求，没有设置CHANGED-REQUEST属性中的任何标志，且没有RESPONSE-ADDRESS属性。这引起服务器回发响应到发出请求的地址和端口上。如果没有收到响应，则停止测试并返回该网络或设备阻止UDP协议的响应消息。否则进行下一步骤测试。

步骤1012.开始TEST2测试，STUN协议模块向77.21.169.211：3478发送绑定请求，并设置CHANGED-REQUEST属性中的“改变IP”和“改变端口”标志。这引起服务器以另一个服务器与另一个端口(如：77.72.169.212：3479)回发响应到发出请求的地址和端口上。；如果收到响应且上一步骤中的MAPPED-ADRESS地址与本地地址不同，则停止测试并返回该NAT为Full Cone(全锥NAT)的响应消息；如果收到响应且上一步骤中的MAPPED-ADRESS地址(映射地址)与本地地址相同，则停止测试并返回该设备处于开放的Intemet中的响应消息；如果未收到响应且上一步骤中的MAPPED-ADRESS地址与本地地址相同，则停止测试并返回该网络设备为对称型防火墙的响应消息；如果未收到响应且上一步骤中的MAPPED-ADRESS地址与本地地址不同，则开始进行下一步骤测试。

步骤1013.开始TEST1B测试，STUN协议模块向步骤I返回的另一个地址与端口(即CHANGED-ADDRESS地址，本例为77.21.169.212：3479)发送绑定请求，并且没有设置CHANGED-REQUEST属性中的任何标志，且没有RESPONSE-ADDRESS属性。这引起服务器回发响应到发出请求的地址和端口上。收到响应后，如果本步骤测试返回的MAPPED-ADDRESS地址与步骤1011返回的MAPPED-ADDRESS地址不同，则停止测试并返回该NAT类型为对称型NAT(即为本发明所述的一种NAT)的响应消息。否则，则进入下一步骤。

步骤1014.开始TEST3测试，STUN协议模块向77.21.169.211：3478发送绑定请求，并只设置CHANGED-REQUEST属性中的“改变端口”标志。这引起服务器回以另一个端口(77.72.169.211：3479)发响应到发出请求的地址和端口上。如果收到响应，则停止测试并返回该NAT为Restricted Cone(受限锥型NAT)的响应消息；否则停止测试并返回该NAT为PortRestricted NAT(端口限制锥型NAT)的响应消息。

5、TURN技术(Traversal Using Relay NAT)

该穿越技术思路与STUN相似，也是私网中的VOIP终端通过某种机制预先得到公网上的服务地址(STUN方式得到的地址为出口NAT上外部地址，TURN方式得到地址为TURNServer上的公网地址)，然后在报文净载中所要求的地址信息就直接填写该公网地址。然后通过中继的方式实现位于NAT设备后的节点之间的直接通信。它解决了STUN应用无法穿透对称NAT以及类似防火墙设备的缺陷。但局限于中继的存在，它增大了包的延迟和丢包的可能性、极大地增加了P2P应用对服务器带宽的需求与成本的支出。

6、ICE技术(Interactive Connectivity Establishment)

ICE是目前在NAT穿透中最常用的方式。ICE是一种综合性的NAT穿越的技术。交互式连接建立是由IETF的MMUSIC工作组开发出来的一种framework，可整合各种NAT穿透技术，如STUN、TURN(Traversal Usmg Relay NAT)、RSIP(Realm Specific IP，特定域IP)等。该framework可以让SIP的客户端利用各种NAT穿透方式打穿远程的防火墙。该技术同样存在对称NAT穿越时仍然采用中继模式实现，同样存在TURN技术的局限。

综上，除去对设备依赖性较强的uPNP技术、ALGs方式、MIDCOM方式之外，能够广泛应用于现今互联网设备环境之上的技术就只有STUN、TURN及ICE技术。这也是目前大多数P2P应用所采用的技术。

但采用现有的技术，都无法实现对对称NAT设备实现理想的点对点穿越，经常因为客户端用于预测数据有限以及客户端运算资源限制导致预测失准，预测周期过长而导致UDP会话失效，或者由于多终端同时使用NAT造成端口号增加速率过快，或者因无法适应NAT端口映射规则的变化，而导致端口预测失败。从而使得大多数的P2P必须经由中继服务器中转才能实现对称NAT的穿越。无法避免地带来了：增大了包的延迟和丢包的可能性、极大地增加了P2P应用对服务器带宽的需求与成本的支出的缺陷。因此，如何实现对称NAT点对点穿越是各家提供P2P应用服务运营商的关键所在。

发明内容

本发明为解决上述现有技术中存在的技术问题，提供了一种基于大数据分析的对称NAT穿越方法，以及实现该方法的系统。

本发明的系统采用以下技术方案：

一种基于大数据(NAT端口分配历史信息)分析的对称NAT穿越的系统，包括用户终端、端口分析服务器、端口分配历史及规则数据库以及端口分析引擎管理客户机。所述用户终端是指由预测端口请求模块、端口分配更新模块、UDP协商模块等部分组成的用户通信节点，最终由其承载P2P应用终端的角色。所述端口分析服务器用于接收终端提交上来的对称NAT内外网映射IP地址及端口信息，并可执行对称NAT端口分配规则挖掘发现、根据用户提交的IP地址与端口信息执行对称NAT预测端口的生成与发送、依据端口分析引擎管理客户机的指令执行端口分析引擎的查看、更新及维护操作等功能，它包括接口模块、调度控制模块、策略管理模块以及分析引擎模块等部分。该服务器架构可依据系统规模的不同以不同形式部署，其中各模块的部署可以采用服务器之中的模块，或以逻辑或物理独立的服务器形式部署。所述的端口分配历史及规则数据库则是用于记录各个对称NAT的端口分配历史信息以供端口分析服务器进行分配规则的挖掘，以及用于记录被分析出来的各对称NAT端口分配规则以便依据传入的对称NAT已分配端口信息给出端口预测列表。所述端口分析引擎管理客户机是用于对端口分析引擎策略的查看、更新及维护操作。从而实现应对各NAT端口分配规则的各种异常变化，增强系统的灵活性，提升端口预测适应变化的稳定性。

所述端口分析服务器由接口模块、调度控制模块、策略控制模块及分析引擎模块所组成。所述接口模块负责接收来自用户终端的对称NAT预测端口查询、对称NAT端口分配信息更新等请求。所述调度控制模块负责管理端口分析队列，并分别接收来自接口模块、策略管理模块的请求以实现触发分析引擎执行分析、查询、引擎策略更新及维护操作等。由于将对称NAT的端口分配规则的挖掘工作置于端口分析服务器之中。实现了各终端共享集中计算资源与分析成果。极大地提升了P2P用户终端的端口预测效率及准确性，并且也节省了客户端的计算资源消耗，提升了客户端的性能；引擎策略的在线更新及维护特性又为适应NAT分配策略不确定性提供了良好的稳定性及灵活性支持。

本发明的方法采用以下技术方案：所述系统的完整流程如下(请参考图2)：

步骤101.处于对称NAT之后的用户终端的预测端口请求模块向端口分析服务器的接口模块发送本端NAT的各类内外网IP地址及端口信息。

步骤102.端口分析服务器的接口模块根据NAT外网IP地址查询端口分配规则数据库，查询是否存在明确的端口分配规则。若存在，则依据传入的已分配端口，生成一系列的预测端口列表返回给用户终端，并跳转至步骤201。否则返回预测失败信息给用户节点，进入下一个步骤。

步骤103.用户终端的STUN协议模块再次向STUN服务器群发起一系列绑定请求。绑定请求可向每台STUN服务器依次按照：同一IP、不同端口，不同IP的顺序发起。以某台stun服务器为例，分别在217.10.68.152的3478及3479，以及在217.116.122.138的3478与3479等4个端口上提供STUN服务。那么，用户节点则分别向：217.10.68.152：3478、217.10.68.152：3479与217.116.122.138：3479等端口发起STUN绑定请求，没有设置CHANGED-REQUEST属性中的任何标志，且没有RESPONSE-ADDRESS属性。在网络及服务正常的前提下，用户节点将会获得一系列的包含NAT内外网IP地址及端口信息的响应消息。

步骤104.用户终端的预测端口请求模块通过调用端口分析服务器的接口模块的接口将上一步获得的STUN响应消息中的内外网IP地址及端口信息列表写入端口分配历史数据库中。接口模块的调用协议包括但不限于HTTP、SOCKET通信协议等。

步骤105.接口模块调用调度控制模块以向分析引擎队列插入待分析IP。

步骤106.调度控制模块调用分析引擎模块对指定IP进行端口分析操作。

步骤107.分析引擎模块根据对指定IP的分析，将分配规则写入端口分配规则数据库中。此处对端口分配规则的挖掘会根据NAT的特性，采用不同的方法。对于单一的PortSensitive(也即端口敏感型)或Address Sensitive(也即地址敏感型)NAT只需做简单的线性预测即可。但对于复合型的随机分配的对称NAT，则可以利用NAT端口历史分配记录并依据现有的有关预测的算法进行有效挖掘。这些方法包括但不限于以下方法：回归分析预测法、马尔科夫链、生日攻击算法等方法。借助于本发明的架构，利用端口分析引擎管理客户机可以分别将以上各种算法引入到端口分析引擎模块中从而提升、改善端口预测的准确性与效率。

步骤108.预测端口请求模块调用端口分析服务器的接口模块请求预测端口，接口模块向端口分配规则数据库查询出指定IP地址对应的端口分配规则之后，在依据传入的已分配端口，生成一系列的预测端口列表，并返回给用户终端。

步骤201.用户终端的UDP协商模块通过信令服务器将本机的内外网地址及预测端口信息发送给对端用户，并接收对端传入的内外网IP地址及端口信息。并开始UDP协商操作。由于有准确的端口预测，则极大地提升了UDP协商成功率。协商成功后则进入下一步骤。

步骤202.用户终端的端口分配更新模块则调用端口分析服务器的接口模块将协商成功的本端对称NAT的外网IP及端口信息写入至端口分配历史数据库中。以便进一步提升对指定IP的端口分配规则分析效率。

步骤301.端口分析管理客户机调用端口分析服务器的策略管理模块发起对端口分析效率的查看、端口分析引擎策略的更新及维护等操作请求，以应对对称NAT的接入IP及端口映射规则的变更。此处的端口分析管理客户机包括但不限于浏览器或独立的客户端程序，调用策略管理模块的协议包括但不限于HTTP、Socket等通信协议。

步骤302.端口分析服务器的策略管理模块调用调度控制模块以实现对端口分析引擎策略的更新、维护及分析效率查看的操作。

附图说明

图1为本发明一种基于大数据分析的对称NAT穿越方法的步骤流程及示意图；

图2为本发明一种基于大数据分析的对称NAT穿越系统的架构示意图；

图3为用户终端进行NAT类型检测的步骤流程图；

图4为实施例一的示意图；

图5为实施例二的示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加明晰，下面将结合附图对本发明实施方式进一步地详细描述。根据图2所示架构进行部署进行了实施例一(请参考图4与图2)的实施：

步骤101.处于对称NAT之后的用户终端的预测端口请求模块向端口分析服务器的接口模块发送本端NAT的各类内外网IP地址及端口信息。此时的NAT外网地址及端口信息为67.105.121.10：40101(也即E103所示)；

步骤102.端口分析服务器的接口模块根据NAT外网IP地址(也即67.105.121.10)查询端口分配规则数据库，查询是否存在明确的端口分配规则。

由于之前在NAT端口分配历史记录数据库中已经保存了该NAT的端口分配历史，端口分析引擎根据分配历史得出该NAT(67.105.121.10)的端口分配遵循端口敏感分配规则，也即根据不同目标IP地址或端口递增一等量端口号。如表E101所示，端口的增量(即DeltaP)为+1。分析引擎将此规则写入NAT端口分配规则数据库中(如表E102所示)。当接口以IP(67.105.121.10)查询分配规则时则获得该端口的分配规律为每次递增1。因此，接口将立即按照此规律生成预测端口为40102(也即40101+1)并返回给用户终端。用户终端程序则直接跳转至步骤201。考虑到NAT共享，为提高分辨率服务器也可选择返回以40102为开始的多个连续端口号(如40102、40103、40104、40105、40106、40107、40108、40109、40110等)返回给客户端，以提升UDP协商的成功率。返回端口范围可以由端口分析引擎管理客户机进行配置。为了简化篇幅，以下仅以一个端口号作为预测端口返回值举例。

步骤201.用户终端的UDP协商模块通过信令服务器将本机的内外网地址及预测端口信息(即67.105.121.10：40102)发送给对端用户，并接收对端传入的内外网IP地址及端口信息。并开始UDP协商操作。由于有准确的端口预测，则极大地提升了UDP协商成功率。协商成功后则进入下一步骤。

步骤202.用户终端的端口分配更新模块则调用端口分析服务器的接口模块将协商成功的本端对称NAT的外网IP及端口信息(67.105.121.10：40102)写入至端口分配历史数据库中，以便进一步提升对指定IP的端口分配规则分析效率。

综上，本实施例解释了对于端口敏感型的对称NAT，利用端口分析服务器发现的分配规则，客户端避免了多次的STUN请求及端口猜测运算，提升了客户端的运行效率及穿越成功率。并通过协商成功后的端口更新机制提升了服务器的NAT端口预测准确性。

请参考图5，其示出了本发明的另一实施例(也即实施例二)所提供的对称NAT穿越过程：

步骤101.处于对称NAT之后的用户终端的预测端口请求模块向端口分析服务器的接口模块发送本端NAT的各类内外网IP地址及端口信息。此时的NAT外网地址及端口信息为119.10.12.101：49206(也即E103所示)；

步骤102.端口分析服务器的接口模块根据NAT外网IP地址(也即119.10.12.101)查询端口分配规则数据库，查询是否存在明确的端口分配规则。

由于之前在NAT端口分配历史记录数据库中已经保存了该NAT的端口分配历史，端口分析引擎根据分配历史得出该NAT(119.10.12.101)的端口分配遵循地址敏感分配规则，也即根据不同目标IP地址递增一等量端口号；对同一IP地址的不同端口访问时则分配相同的端口。如表E101所示，端口的增量(即DeltaP)为+2。分析引擎将此规则写入NAT端口分配规则数据库中(如表E102所示)。当接口以IP(119.10.12.101)查询分配规则时则获得该端口的分配规律为每次递增2。且数据库中未发现由访问当前IP的记录。因此，接口将立即按照此规律生成预测端口为49208(也即49206+2)并返回给用户终端。用户终端程序则直接跳转至步骤201。考虑到NAT共享，为提高分辨率服务器也可选择返回以40102为开始的多个连续端口号(如49208、49210、49212、49214、49216、49218、49220、49222、49224等)返回给客户端，以提升UDP协商的成功率。返回端口范围可以由端口分析引擎管理客户机进行配置。为了简化篇幅，以下仅以一个端口号作为预测端口返回值举例。

步骤201.用户终端的UDP协商模块通过信令服务器将本机的内外网地址及预测端口信息(即119.10.12.101：49208)发送给对端用户，并接收对端传入的内外网IP地址及端口信息。并开始UDP协商操作。由于有准确的端口预测，则极大地提升了UDP协商成功率。协商成功后则进入下一步骤。

步骤202.用户终端的端口分配更新模块则调用端口分析服务器的接口模块将协商成功的本端对称NAT的外网IP及端口信息(119.10.12.101；49208)写入至端口分配历史数据库中，以便进一步提升对指定IP的端口分配规则分析效率。

综上，本实施例解释了对于地址敏感型的对称NAT，利用端口分析服务器发现的分配规则，客户端避免了多次的STUN请求及端口猜测运算，提升了客户端的运行效率及穿越成功率。并通过协商成功后的端口更新机制提升了服务器的NAT端口预测准确性。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

上述发明实施例仅用于解释本发明使用方法，并不表示仅有实施例情况下才可适用。特别是有关随机分配的对称NAT端口预测，完全可以利用NAT端口历史分配记录并依据现有的有关预测的算法进行有效挖掘。这些方法包括但不限于以下方法：线性回归预测、马尔科夫链、生日攻击算法等方法。借助于本发明的架构，利用端口分析引擎管理客户机可以分别将以上各种算法引入到端口分析引擎模块中从而提升、改善端口预测的准确性与效率。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过软件程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本发明的实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种基于大数据分析的对称NAT穿越的系统，其特征在于，包括用户终端、端口分析服务器、信令服务器、端口分配历史及规则数据库以及端口分析引擎管理客户机；

所述系统的完整流程如下：

步骤101.处于对称NAT之后的用户终端的预测端口请求模块向端口分析服务器的接口模块发送本端NAT的各类内外网IP地址及端口信息；

步骤102.端口分析服务器的接口模块根据NAT外网IP地址查询端口分配规则数据库，查询是否存在明确的端口分配规则；若存在，则依据传入的已分配端口，生成一系列的预测端口列表返回给用户终端，并跳转至步骤201；否则返回预测失败信息给用户节点，进入下一个步骤；

步骤103.用户终端的STUN协议模块再次向STUN服务器群发起一系列绑定请求，绑定请求可向每台STUN服务器依次按照：同一IP、不同端口的顺序发起，在网络及服务正常的前提下，用户终端将会获得一系列的包含NAT内外网IP地址及端口信息的响应消息；

步骤104.用户终端的预测端口请求模块通过调用端口分析服务器的接口模块的接口将步骤103获得的STUN响应消息中的内外网IP地址及端口信息列表写入端口分配历史及规则数据库中，接口模块的调用协议可以是HTTP或SOCKET通信协议；

步骤105.端口分析服务器的接口模块调用端口分析服务器的调度控制模块以向分析引擎队列插入待分析IP；

步骤106.端口分析服务器的调度控制模块调用端口分析服务器的分析引擎模块对指定IP进行端口分析操作；

步骤107.分析引擎模块根据对指定IP的分析，将分配规则写入端口分配规则数据库中；此处对端口分配规则的挖掘会根据NAT的特性，采用不同的方法；对于单一的端口敏感型(也即Port Sensitive)或地址敏感型(也即Address Sensitive)NAT只需做简单的线性预测即可；但对于复合型的随机分配的对称NAT，则利用NAT端口历史分配记录并依据现有的有关预测的算法进行有效挖掘，所述有关预测的算法是回归分析预测法、马尔科夫链、生日攻击算法；利用端口分析引擎管理客户机分别将以上各种算法引入到端口分析引擎模块中从而提升、改善端口预测的准确性与效率；

步骤108.预测端口请求模块调用端口分析服务器的接口模块请求预测端口，接口模块向端口分配规则数据库查询出指定IP地址对应的端口分配规则之后，在依据传入的已分配端口，生成一系列的预测端口列表，并返回给用户终端；

步骤201.用户终端的UDP协商模块通过信令服务器将本机的内外网地址及预测端口信息发送给对端用户，并接收对端传入的内外网IP地址及端口信息，开始UDP协商操作；由于有准确的端口预测，则极大地提升了UDP协商成功率；协商成功后则进入下一步骤；

步骤202.用户终端的端口分配更新模块则调用端口分析服务器的接口模块将协商成功的本端对称NAT的外网IP及端口信息写入至端口分配历史数据库中，以便进一步提升对指定IP的端口分配规则分析效率；

步骤301.端口分析引擎管理客户机调用端口分析服务器的策略管理模块发起对端口分析效率的查看、端口分析引擎策略的更新及维护操作请求，以应对对称NAT的接入IP及端口映射规则的变更；此处的端口分析引擎管理客户机可以是浏览器或独立的客户端程序；

步骤302.端口分析服务器的策略管理模块调用端口分析服务器的调度控制模块以实现对端口分析服务器的端口分析引擎策略的更新、维护及分析效率查看的操作。

2.如权利要求1所述的基于大数据分析的对称NAT穿越的系统，其特征为：所述用户终端是指由预测端口请求模块、端口分配更新模块、UDP协商模块、STUN协议模块、数据传输模块组成的用户通信节点；最终由其承载P2P应用终端的角色。

3.如权利要求1所述的基于大数据分析的对称NAT穿越的系统，其特征为：所述端口分析服务器用于接收用户终端提交上来的对称NAT内外网映射IP地址及端口信息，并可执行对称NAT端口分配规则挖掘及发现、根据用户终端提交的IP地址与端口信息执行对称NAT预测端口的生成与发送、依据端口分析引擎管理客户机的指令执行端口分析引擎的查看、更新及维护操作功能；它由接口模块、调度控制模块、策略管理模块以及分析引擎模块构成。

4.如权利要求1所述的基于大数据分析的对称NAT穿越的系统，其特征为：所述端口分析服务器架构可依据系统规模的不同以不同形式部署；其中各模块可以部署于同一物理服务器之中，或以逻辑或物理独立的服务器形式部署。

5.如权利要求1所述的基于大数据分析的对称NAT穿越的系统，其特征为：所述的端口分配历史及规则数据库则是用于记录各个对称NAT的端口分配历史信息以供端口分析服务器进行分配规则的挖掘，以及用于记录被分析出来的各对称NAT端口分配规则以便依据传入的对称NAT已分配端口信息给出端口预测列表。

6.如权利要求1所述的基于大数据分析的对称NAT穿越的系统，其特征为：所述端口分析引擎管理客户机是用于对端口分析引擎策略进行查看、更新及维护操作，从而实现应对各NAT端口分配规则的各种异常变化，增强系统的灵活性，提升端口预测适应变化的稳定性。

7.根据权利要求1所述的基于大数据分析的对称NAT穿越的系统，其特征为：所述端口分析服务器中的接口模块负责接收来自用户终端的对称NAT预测端口查询、对称NAT端口分配信息更新请求。

8.根据权利要求1所述的基于大数据分析的对称NAT穿越的系统，其特征为：所述端口分析服务器的调度控制模块负责管理端口分析队列，并分别接收来自接口模块、策略管理模块的请求以实现触发分析引擎执行分析、查询、引擎策略更新及维护操作；将对称NAT的端口分配规则的挖掘工作置于端口分析服务器之中，实现了各终端共享集中计算资源与分析成果，极大地提升了P2P用户终端的端口预测效率及准确性，同时节省了用户终端的计算资源消耗，提升了用户终端的性能；引擎策略的在线更新及维护特性又为适应NAT分配策略不确定性提供了良好的稳定性及灵活性支持。