NAT透明性、P2P通信与NAT穿透技术

原创已于 2025-10-29 00:41:41 修改 · 1k 阅读

16 ·

CC 4.0 BY-SA版权

文章标签：

#p2p #服务器 #网络协议

于 2025-10-28 16:56:40 首次发布

起因：没看懂下文

解读：

①“并不完全透明”的含义：

NAT允许多个内网设备共享一个公共IP地址访问互联网：当内部设备发送数据包到外网时，NAT设备会将源私有IP和端口替换为自己的公网IP和映射端口，并在内部维护一个转换表，以便把返回流量送回正确的内部设备。这种转换过程对于典型的客户端-服务器（C/S）应用（如浏览网页、收发邮件）而言通常是透明的，因为请求由内部发起，响应能够依据NAT表顺利返回。

虽然对普通的网络使用者而言，NAT似乎是不知不觉就完成了地址转换，但它对所有网络应用并非百分之百透明。NAT破坏了互联网的端到端原则，即通信的两个端点应该直接彼此可达。因为NAT修改了IP地址和端口信息，对于那些依赖端到端直接通信或在协议中嵌入自己IP地址的应用，NAT可能导致不可预期的问题。举例来说，一些VPN协议或早期的FTP、SIP等，需要在数据负载中传递自己的IP地址或建立双向连接，如果NAT不做特殊处理（通过应用层网关ALG修改这些嵌入信息），这些应用可能无法正常工作。正如RFC文档所指出的：“NAT设备（尤其是NAPT类型）破坏了端到端模型的多数基本优势，降低了整体灵活性，并增加了操作复杂性”。换句话说，NAT并不能对所有应用都做到完全无感知，一些应用需要为穿越NAT做额外设计。

②NAT对应用行为的影响：

NAT对网络应用最大的影响在于阻止了外部直接发起的连接。默认情况下，NAT只允许内部网络主动发起连接，外部主机无法直接连接到内网的设备。这对需要端到端双向通信的应用造成困难，例如点对点（P2P）应用、实时音视频通话、网络游戏联机等。当两个终端都在各自的内网（各自的NAT之后）时，双方都无法直接建立连接，因为都没有公开的可被直接寻址的IP和端口。这种情况下，如果没有额外措施，一个节点发送的数据包到了对方的NAT路由器时会被丢弃，因为对方NAT没有对应的会话映射。NAT并不影响传统的客户端-服务器模式通信（例如家里的电脑访问网页服务器）是因为服务器拥有公网IP且一直监听，而NAT使内部请求能得到响应。但对于对等通信而言，NAT相当于在两端之间设置了单向的阀门：只允许内部流量出去及响应回来，堵住了外部直接进来的请求

实际案例 – 视频会议和在线游戏： 视频会议应用和网络游戏很好地体现了NAT的影响。在视频通话中，为了降低延迟通常希望两端用户直接点对点传输媒体流。然而，如果双方都在公司或家庭路由器后面（尤其遇到严格的对称NAT），往往无法直接建立通路，只能退而求其次通过中继服务器转发视频数据，增加了延迟和带宽消耗。例如，有些用户在使用Zoom、Teams等会议软件时，如果所处网络的NAT类型是“端口限制锥型”甚至“对称型”，就会发现点对点连接建立困难，可能出现呼叫掉线、视频卡顿等问题。这并非软件本身的Bug，而是NAT造成的连接受限，需要靠服务器中转或者特殊手段打洞才能通信。再如在主机游戏或P2P网游中，玩家常听说“NAT类型：严格/中等/开放”一说。严格的NAT会导致玩家无法作为主机（服务器）让别人加入游戏，或者匹配困难；只有NAT类型开放（类似全锥型NAT）时，才能顺利进行直连联机。因此说，NAT对这些网络应用并不透明，需要应用开发者或用户采取NAT穿透措施（如手动端口映射、UPnP或利用中继服务等）才能恢复正常的点到点通信体验。

③ P2P通信及其与客户端-服务器模式的区别

1、P2P通信的定义：P2P（Peer-to-Peer，点对点）通信是一种网络通信模型，在这种模式下网络中每一个参与节点地位对等，既可以充当客户端也可以充当服务器，每个节点都直接与其他节点交换数据。这打破了传统C/S架构中“服务提供者”和“服务使用者”的固定角色划分：在P2P网络里，所有的计算机既是资源或服务的提供者，同时也是使用者。节点间通常通过直接连接来共享各自的部分资源（如文件、计算能力等），从而整体上构成一个去中心化或分布式的系统。典型的P2P通信例子包括：文件共享（如Napster、eMule、电驴以及现在常用的BitTorrent）、点对点语音视频通话（如早期Skype的通话架构）、分布式计算和区块链网络等。在这些应用中，没有绝对集中的服务器来中转全部数据，大量数据传输在终端节点之间直接发生。

2、客户端-服务器模式： 相比之下，传统的客户端/服务器（C/S）模式是一种中心化架构：由某些节点专门作为服务器，掌控或提供资源，其他节点作为客户端向服务器请求服务。服务器通常拥有固定的公网IP地址和持续运行的服务进程，客户端通过该地址发起请求，服务器处理后响应。常见的C/S应用如Web服务（浏览器-网页服务器）、Email（邮件客户端-邮件服务器）、FTP文件传输、DNS域名解析等。在这种模型下，客户端之间不直接通信，所有交互都经由服务器进行；服务器的性能和可靠性对整体系统影响重大，而客户端则相对被动，只消费由服务器提供的数据或功能。

3、两者区别与优缺点： P2P模式和C/S模式在架构上有明显区别，也各有优劣。首先，中心节点依赖：C/S有中心服务器，易于管理和控制，但也成为单点故障和性能瓶颈；P2P没有单一中心，系统更具弹性和扩展性，不会因为一台服务器宕机导致全网瘫痪。其次，资源利用：P2P充分利用网络边缘大量节点的带宽、存储等资源，降低中心服务器的负载，在大规模文件分发时效率更高（例如BitTorrent下载会从许多节点并行获取片段）；而C/S模式下服务器需要足够带宽和性能支撑所有客户端请求。再次，延迟路径：P2P通信有机会让地理上接近的节点直接互传数据，减少绕远经服务器的延迟，但在现实中由于NAT等原因往往需要经过一些中介协调连接。安全和管理上，C/S因为集中更容易控制权限和监控，而P2P的去中心特性带来管理上的分散和内容可控性的问题。两种模式在实际应用中经常结合使用：例如早期的Skype有集中登录服务器用于用户认证和查找，但语音通话媒体走点对点直连路径（若可能）；BitTorrent有tracker服务器帮助节点发现彼此，但文件数据通过各节点互传。

4、P2P通信中的NAT问题： 正如上文所述，NAT对P2P通信是一个天然的障碍。因为在P2P网络中，每个节点既要主动发起连接也需被动接受连接，但NAT的存在使得一个节点无法被外部直接访问。除非一方节点拥有公网IP或双方的NAT都进行了特殊设置，否则纯粹的对等连接难以建立。这导致许多P2P应用不得不设计额外的机制绕过NAT。例如，早期Skype在两端用户都被NAT封锁时，会借助位于公网的第三方节点（称为“超级节点”）充当中转，临时接力音视频数据。又比如，BitTorrent客户端如果检测到自己在NAT后无法被连接，会通过打洞或请求路由器打开端口（例如使用UPnP）来提升连通性，否则它在网络中只能充当“受限节点”，只能连接到那些不在NAT后或已打洞成功的对端，从而影响下载/upload效率。总体来说，NAT倾向于强制网络走向客户端-服务器模型，因为服务器必须在公网可达，阻碍了对等节点直接互联。因此，为了实现真正的P2P通信，必须克服NAT带来的障碍，这就引出了各种NAT穿透技术。

④常见的NAT穿透技术简介

面对NAT对端到端通信的阻碍，工程师们提出了多种NAT穿透（NAT Traversal）技术来恢复节点间的直接通信路径。所谓NAT穿透，就是通过技术手段使得处于不同NAT后的设备能够直接建立和保持IP连接。这些方法大体可分为两类：利用NAT的“漏洞”打通直连，或者借助中继服务器绕过NAT。下面介绍几种主流方案，包括STUN、TURN、UPnP以及“打洞”技术等，并说明其工作原理、应用场景和优缺点。

STUN：发现外部地址，实现UDP打洞

STUN（Session Traversal Utilities for NAT，会话穿越工具）是一种由IETF定义的用于NAT环境的网络协议，主要功能是帮助设备发现自己经过NAT后的公网IP地址和端口号，并利用该信息尝试建立可直通NAT的P2P通信。简单来说，内部的客户端向一个公网上的STUN服务器发送请求，STUN服务器会看见该请求来自哪个公网IP和端口，并在响应中将这个地址告知客户端。客户端由此了解到“自己在互联网上看起来的地址”，可以把这个地址提供给想与其通信的对端。之后两端就可以尝试直接互相发送UDP数据报，从而打洞打开双方NAT的临时入口，使P2P数据直接通过。这个打洞过程得名于这样的比喻：每当内网主机向外发送一个UDP包，NAT就像在防火墙上开了一个“小洞”允许对应响应通过，而双方协调好互相发送探测包，就等于在各自NAT上打开了指向对方的洞口。

应用场景： STUN广泛用于需要P2P连接的场景，例如VoIP电话、视频会议（WebRTC协议中就大量使用STUN）、P2P文件分享、在线游戏等。当双方都在普通的锥型NAT或端口限制锥型NAT后时，UDP打洞往往能够成功建立直接连接。这种方法的优点是效率高——后续通信数据走直连，延迟低、带宽不受服务器限制；且不需要修改现有NAT设备或路由器配置，只需部署一台STUN服务器提供探测服务，比较方便。正因为此，STUN成为主流IM和WebRTC应用首选的NAT穿透方案。

局限与缺点： STUN并非在所有网络环境都奏效。其主要限制是NAT类型：如果任一端处于对称NAT（Symmetric NAT）或双方都有非常严格的防火墙策略，那么简单的UDP打洞可能失败。对称NAT会为不同目的地的通信分配不同的映射端口，而且严格限制只有先发过流量的外部地址才能进来。这种情况下，即使双方知道了彼此的公网地址，也无法穿透对方的NAT（因为NAT会丢弃不认识的外部来源数据包）。此外，STUN主要适用于UDP协议，针对TCP的打洞要复杂得多且成功率低，因此STUN对需要可靠传输的场景帮助有限。总的来说，STUN提供了一种“尽力而为”的直连尝试机制，在多数家庭/办公NAT环境下有效，但无法保证在所有环境中成功建立直连。当STUN打洞不可行时，就需要借助下一种方案TURN来弥补。

TURN：借助中继服务器转发流量

TURN（Traversal Using Relays around NAT，通过中继绕过NAT）是一种NAT穿越方法，核心思想是不再强求点对点直接互通，而是利用一个中继服务器充当中转站。当两个客户端无法直接建立连接（例如遇到对称NAT或防火墙阻挡UDP）时，他们可以各自与位于公网的TURN服务器建立连接，将想发送给对方的数据先发送到TURN服务器，由服务器再“转交”给对方。这样，对双方而言，通信似乎就是与TURN服务器在通信，而服务器负责把双方的数据来回转发。因为数据经过第三方转发，相当于绕开了两端NAT的限制（外部通信对NAT来说是与TURN服务器交互，都属于允许的出站/入站响应流量）。TURN保证了无论何种苛刻的NAT类型，都能实现通信，是一种可靠的保底方案。

应用场景： TURN通常作为STUN失败后的备援机制使用。例如在WebRTC架构的ICE框架中，会先尝试STUN打洞获取“直连候选”，如果所有直连路径都打不通，最终才使用TURN提供的中继候选地址进行通信。实际应用中，大概只有10~15%的困难网络环境（如企业级防火墙、对称NAT、移动运营商的CGNAT等）会最终需要TURN，但对于那些场景TURN是确保通话/连接成功的关键。常见的云通信平台（如Twilio、Zoom等）都会提供TURN服务器以保证服务可靠性。当我们进行视频会议时，如果发现走直连不通，就会“不知不觉”切换到TURN中继，从而牺牲一些性能换取不断线的连接。

优缺点： TURN的优点在于可靠——只要服务器可达，它几乎100%能建立起通信；而且对于协议和数据类型透明，即使P2P直连受限，通过中继也能传输任何数据。然而缺点也很明显：因为所有通信的数据包都要经由服务器转发，这带来了额外的延迟和带宽消耗。尤其是视频流、大文件传输，这对服务器带宽是巨大开销，成本高昂。因此TURN服务器需要有足够的带宽和处理能力，同时为了覆盖全球用户通常要部署在各地区云节点上，这些都增加了运营复杂度。另外，从用户角度看，经由TURN的连接往往时延更高，对实时应用的体验有一定负面影响。因此，TURN一般作为不得已的最后手段，在能直连就直连，不能直连再用中继的策略下使用。

UPnP：路由器自动端口映射

UPnP（Universal Plug and Play，即插即用）并不是专门为NAT穿透设计的协议，但它包含的IGD（Internet Gateway Device）Profile提供了自动端口映射功能，可用于解决内网设备被外网访问的问题。简单说，如果路由器支持UPnP，内网一台设备可以通过UPnP协议请求路由器打开一个端口并将其映射到该设备。这样外部网络访问路由器这个指定端口时，路由器会将流量转发给内部对应设备，从而实现外部直接访问内网服务。UPnP使这种端口转发配置自动化：过去用户需要登录路由器手工添加端口映射规则，有了UPnP后，应用程序本身就能与路由器通信完成映射，大大提高了便利性。

应用场景： UPnP常用于家庭网络环境。当用户通过NAT上网又需要使用P2P软件（如BitTorrent、电驴eMule等）或玩P2P联机游戏时，UPnP能自动把这些应用监听的端口公布到公网，让外网用户也可以发起连接进来。例如，很多下载工具启动时会尝试通过UPnP打开端口，这样其他P2P节点就能主动连接到你，提高下载速度和资源交流效率。又如一些即时通讯软件、远程桌面、网络摄像头等需要从外网访问内网设备的场景，UPnP也提供了免配置的即插即用体验。它适合掌控自身路由器的环境（家庭、自建网络），解决小型网络的NAT穿透很有效。

优缺点： 优点方面，UPnP使用起来极其方便，对用户透明，无需手动设置复杂的端口转发规则；而且是在本地网络环境解决NAT问题，不需要额外云服务支持，没有中继的性能损耗。但UPnP也有局限：首先双方网络的NAT设备都要支持并开启UPnP功能才能奏效。很多企业或运营商级NAT出于安全考虑并不启用UPnP，公共Wifi环境下用户往往也无法控制路由器设置。其次，安全性是UPnP经常被诟病的一点——由于其无需认证的设计，局域网内的任意应用都可以请求路由器打开端口，这可能被恶意程序利用打开后门。因此一些进阶用户会选择关闭UPnP功能。总体来说，UPnP适合家庭/小型办公环境下提升P2P连接成功率，但在大型网络或对安全要求高的环境中用得较少。

Hole Punching（打洞技术）：协调建立直连会话

“打洞”并非某个特定协议，而是对一类NAT穿透技术的形象称呼，其典型代表就是前面介绍的UDP打洞。打洞的原理是：利用NAT对于内部发出通信的响应流量会放行这一行为，令双方内网主机各自主动向对方的地址发送探测数据包。即便最初不知道对方确切的公网端口，这个过程通常借助一个信令服务器（比如STUN服务器或信令交换服务器）来互相告知彼此的公网IP和端口，然后同步地尝试互相发送UDP包。这样做的效果是，在双方的NAT路由器上几乎同时建立起针对对方地址的会话表项（一个进入“洞”），随后真正的数据就可以通过这个洞直接通信，而不再被NAT拦截。这种方法类比为在两边墙上各凿一孔，并正好对上形成一条通道，所以称为“打洞”。

打洞的类型： 最常用的是UDP打洞，因为UDP是无连接的协议，NAT对其处理相对简单，容易利用。不仅UDP，实际上TCP也可以打洞，但过程更复杂成功率更低，因为TCP要建立连接握手，双方的SYN报文和NAT行为更难巧妙地配合。不过在一些P2P应用中（例如部分P2P网络库，或Xbox/PlayStation等游戏主机联网），也存在TCP打洞技巧。**ICE（交互式连接建立）**框架可以看作是对各种打洞的统一管理：它会同时尝试多个候选（包括不同网络接口、UDP/TCP、打洞或中继等），选取成功的最佳路径。

应用场景与优缺点： 打洞作为一种技术思想，广泛应用于P2P通信建立过程中。其优点和STUN类似：只要成功，通信效率高且不依赖中转；缺点则是不保证成功，尤其在复杂NAT情况下（对称NAT打洞几乎必败）或者双方同时位于受限环境时（例如双方都在公司防火墙后）。此外，打洞过程通常需要一个第三方服务器进行信令协调，比如常见的做法是通过一个协调服务器把Peer A的公网地址发给Peer B，Peer B的发给Peer A，然后引导双方互发包。如果没有协调机制，双方可能不知道往哪儿发“探测”数据。当然，这个协调耗费的流量和时间很少，与TURN中继大量转发数据不可同日而语。总结来说，Hole Punching是一种技巧，配合STUN等协议使用，为NAT后的点对点通信提供可能性，但在实际工程中必须与其他方案（如TURN）配合以应对各种网络环境