本文永久链接 – https://tonybai.com/2024/11/27/webrtc-first-lesson-network-architecture-and-how-nat-work

2023年下旬,OpenAI与Livekit的合作在科技圈引起了不小的轰动。这两家公司联手,通过WebRTC技术和大型语言模型(LLM)的结合,使AI模型具有了看、听和说话的能力。这一举动不仅彰显了WebRTC在现代通信技术中的重要地位,也为我们揭示了AI与实时通信融合的无限可能。WebRTC技术在大流行后再一次进入技术人的视野,恰好在我们今年打造的产品中,WebRTC也是技术栈的核心。

在去年9月份,我写了一篇WebRTC入门科普的文章:使用Go和WebRTC data channel实现端到端实时通信,在那篇文章中,我对WebRTC技术做了一些概述说明,并通过一个基于Go语言的实例,展示了如何实现端到端的实时通信。大家可以通过那篇文章了解WebRTC技术的基础概念和核心架构

WebRTC端到端实时通信的效果主要取决于两个重要因素,一个通信质量,一个是音视频编解码质量。对于入门类文章来说,改进通信质量或音视频编解码质量还为时尚早,我们亟需了解的是其背后的原理。

在这篇文章以及后续的几篇文章中,我们先来关注一下“WebRTC网络通信”。我们会先了解一下WebRTC网络架构,然后对WebRTC中的难点,诸如NAT打洞、基于信令与ICE的建连等做深入分析。

在这篇文章中,我们先来学习NAT的工作原理,探讨不同类型的NAT网络行为是如何影响点对点通信的,为后续理解WebRTC的NAT打洞(也称为NAT穿透)和端到端建连做准备。

1. WebRTC网络架构

我们知道WebRTC(Web Real-Time Communication)是一种支持网页浏览器/应用进行端到端实时语音对话或视频对话的技术,其中支持端到端建立连接和后续数据传输的网络架构是十分重要的,这也是理解WebRTC技术栈的一个重点。下面是WebRTC网络架构图的示意图:

这个架构包含以下主要组件:

  • 浏览器/App:这是进行WebRTC的端(Peer),可以是浏览器,也可以是App。WebRTC API在浏览器中实现,使得web应用能够直接访问媒体设备和建立点对点连接。App也可以利用WebRTC的实现(比如Pion)与对端进行RTC通信。

  • 信令服务器(Signaling Server):虽然不是WebRTC标准的一部分,但对于WebRTC建立连接至关重要,任何non-trivial的基于WebRTC的系统都会有专属的信令服务器,它会帮助通信双方交换会话描述协议(SDP)信息和ICE候选地址。这个在使用Go和WebRTC data channel实现端到端实时通信一文中介绍过,在后续的文章中还会有系统说明。

  • STUN服务器(Session Traversal Utilities for NAT):该服务器可以帮助客户端发现自己的公网IP地址和端口,这个服务器是NAT打洞时所必须的。

  • TURN服务器(Traversal Using Relays around NAT):当通过常规方式点对点连接失败时(通常是NAT打洞失败),可以使用TURN服务器作为媒体数据的中继服务器使用。两端发送的数据都会要通过TURN的中继才能转发给对端。

  • ICE框架(Interactive Connectivity Establishment):综合使用各种NAT打洞技术来协助两端建立连接,这个我们会在后面文章中系统说明。

我们看到这个架构略有些复杂,但该架构允许WebRTC应用在复杂的网络环境中建立直接的点对点连接,即使客户端位于NAT或防火墙后面

2. 网络世界的真相:我们都在NAT后面

在理想的网络世界中,每个设备都有一个唯一的公网IP地址,可以直接相互连接和通信。这种理想状态下,网络是完全开放和对等的,没有任何障碍阻止设备之间的直接交互。

但现实情况却很骨感,出于IPv4地址空间的限制(IPv4地址的数量不够了)、网络管理以及网络安全的考虑,大多数设备都隐藏在NAT(网络地址转换)后面。

NAT(网络地址转换)技术于1994年由Egevang等人在RFC 1631中提出,旨在作为缓解IPv4地址不足问题的临时技术方案。通过将私有IP地址和端口映射到公共IP地址和端口,NAT使得在私有网络中的设备可以使用公共地址(共享一个或多个)访问互联网。


NAT转换示意图(来自维基百科)

这种技术的出现大大缓解了IPv4地址的紧张状况,并成为当时乃至现在(IPv6的推广与使用未及预期)网络地址管理的重要手段。不过,NAT技术的广泛应用也意味着大部分设备只有私网IP,无法从外网直接访问,这一定程度上限制了端到端的直接通信。另外,由于不同类型的NAT行为有所不同,进一步增加了端到端网络连接的复杂性。

注:私网IP地址是指在局域网(LAN)中使用的IP地址,这些地址不能在公共互联网(公网)中被路由。私网IP地址主要用于内部网络中设备之间的通信,通常用于家庭、企业或组织的网络。根据IETF的标准,私网IP地址的范围包括(以CIDR(无类域间路由)格式表示):10.0.0.0/8、172.16.0.0/12和192.168.0.0/16。

于是便有了NAT打洞技术(NAT hole punching)。NAT打洞技术为在NAT环境中实现设备间直接通信提供了一种有效的解决方案,它允许位于不同NAT后面的设备建立直接的点对点(P2P)连接,而无需手工配置端口转发。在P2P文件共享、VoIP通信、在线游戏、即时通信以及视频会议系统等领域,NAT打洞都有着广泛的应用。

不过,要理解NAT打洞,我们需要要先得弄清楚NAT的工作原理、主要的NAT类型以及它们的行为差异。

3. NAT的工作原理与主要类型的行为差异

我们先来看看NAT工作原理。

3.1 NAT的工作原理

网络地址转换(NAT)的核心工作原理还是比较好理解的,就是在请求数据包通过NAT设备时修改其源IP和源端口信息。以下图为例,即将内网主机通过X1:x1发往外网主机Y1:y1的网络请求中的源IP和源端口从X1:x1修改为X1′:x1′后,再发给目的端点(Y1:y1)。NAT设备会维护一个映射表(也叫会话表),记录X1:x1与X1′:x1′的映射关系。当请求的应答包回来时(Y1:y1 -> X1′:x1′),NAT设备将根据映射表将X1′:x1′再替换回X1:x1,这样应答包就可以正常回到X1:x1了。

为了管理资源(每个NAT的对外端口数量有限),NAT设备会内置超时机制,它会为每个会话/映射设置一个生存时间(TTL)。如果在TTL内没有新的数据包,这个映射会被删除。

随着NAT技术的演进,同时考虑到网络管理和网络安全因素,NAT设备出现了不同的映射表管理方式,与之相对应的就出现了不同的NAT类型与行为特征。接下来,我们就来看看NAT的主要类型、映射表的管理方式以及它们的行为差异。

注:NAT打洞的主流方式是通过UDP包,因此下面的关于NAT类型和行为的描述都是基于UDP的。UDP是面向数据报的传输层协议,相对于面向连接的TCP,它更加灵活,延迟更低,在实时性要求更高的场景,比如视频会议、语音通信等。

3.2 NAT的主要类型

根据2003年RFC 3489中对市面上NAT实现类型的归纳,NAT可以分为完全锥形(Full Cone)、受限锥形(Restricted Cone)、端口受限锥形(Port Restricted Cone)和对称型(Symmetric)四种主要类型。下面我们分别来说一下这四种类型的NAT映射表构成以及行为特征。

3.2.1 完全锥型NAT

完全锥型是最宽松的NAT类型,它在NAT映射表中只存储了一个四元组:(内网ip(internal_ip), 内网端口(internal_port), 映射ip(external_ip), 映射端口(external_port))。我们看下图中的完全锥形类型的NAT::

在上图中,内部地址X1:x1被映射到了外部地址E:x1′,所有从X1:x1发到外部的数据都由E:x1′向外发送。相应的外部应答(比如: Y1:y1 -> E:x1′)的流量会在NAT设备上被转换回到X1:x1的流量。

那么为什么这个类型的NAT会被称为完全锥形呢?这就要从NAT设备对外部流量的限制来说了。对于NAT设备来说,一旦建立了X1:x1->E:x1′的映射规则,就好比X1在该NAT设备上“打了一个洞”,内部来自X1:x1的流量可以从该洞发送出去,但NAT设备是否允许外部流量从该洞回到X1:x1以及允许哪些流量从该洞返回到X1:x1就决定了该NAT的类型

如果任何外部主机都可以通过上面的洞E:x1′向内部主机X1:x1发送数据包,那么这个NAT就是完全锥形。我们再用一副示意图来说明一下完全锥形NAT的行为特点:

这里故意将右侧的外部主机排列成像圆锥的形状,位于锥子范围内的所有主机都能通过图中的“洞”将数据包发到内部主机X1:x1上。

很显然完全锥形NAT虽然管理简单,也具有很好的开放性,但它在安全性上较弱,外部很容易利用NAT上的洞向内部主机上的服务发起攻击。

为此,后面的几种NAT都是为了增强NAT安全性的,而且一个比一个更严格,我们先来看受限锥形NAT。

3.2.2 受限锥型NAT

受限锥形NAT又被称为IP受限锥型NAT,它在完全锥形NAT的映射表的基础上,增加了“IP白名单(如下图中的allowed_external_ips)”,下面是受限锥形NAT的示意图:

我们看到:X1主机通过X1:x1在向Y1:y1和Y2:y2分别发起请求后,NAT设备上便有了一条映射规则(一个洞):X1:x1被映射到了外部地址E:x1′,但映射表也记录了两个请求的目标主机的IP,记录在规则的allowed_external_ips中。

规则中的这个allowed_external_ips对后续外部主机通过E:x1′向X1:x1发送数据包会做出限制,如下图:

我们看到:只有在“白名单”中的IP对应的主机(如Y1、Y2)才可以在“洞”建立后,通过E:x1′向内部主机X1:x1成功发送数据包,其它主机发送的数据包都会被拦截和丢弃。

我们看到上述的限制是限制是基于IP地址的,而位于Y1和Y2上的服务,可以使用任意端口向E:x1′成功发送数据包,这显然也是一个安全隐患。于是便有了下面限制更为严格的端口受限锥形NAT。

3.2.3 端口受限锥型NAT

端口受限锥型NAT在受限锥形NAT映射表的基础上,又进一步限制了端口,通过allowed_external_endpoints实现对外部端点的限制,如面示意图:

注:IP:port合在一起称为一个端点(endpoint)。

我们看到:X1主机通过X1:x1在向Y1:y1和Y2:y2分别发起请求后,NAT设备上便有了一条映射规则(一个洞):X1:x1被映射到了外部地址E:x1′,映射表同时记录了两个请求的目标主机的端点(ip:port),记录在规则的allowed_external_endpoints中。

规则中的这个allowed_external_pointss对后续外部主机通过E:x1′向X1:x1发送数据包会做出更严格的限制,如下图:

我们看到:只有在“allowed_external_endpoints”中的端点(如Y1:y1、Y2:y2)发起的请求才可以在“洞”建立后,通过E:x1′向内部主机X1:x1成功发送数据包,其它主机或Y1、Y2上其他端口发送的数据包都会被拦截和丢弃。

下面我们再来看看最严格的NAT类型:对称型NAT。

3.2.4 对称型NAT

和上面由X1:x1发出的数据包(无论目的端点是什么)在NAT上只建立一条映射规则不同,在对称型NAT中,由X1:x1向不同端点发送数据会在NAT上建立多条映射规则,如下图所示:

我们看到每条规则中还包含了目的端点的信息(dest_ip和dest_port),也正因为如此,对称型NAT对外部请求的限制也是最严格的,如下图所示:

我们看到:只有来自规则中dest_ip和dest_port组成的端点的数据包才能进入内部,即只有那些收到数据的外部主机才能够“顺原路返回”地回送数据

3.3 新的分类

上面提到的四种NAT类型是stun的RFC在早期对NAT实现的分类(基于UDP传输),一直沿用至今,也是目前使用最多的一种分类方法。不过这种分类方法将NAT的两个正交的行为混在一起说了,即分配行为Assignment Behavior和过滤行为Filtering Behavior。其实我们更多关注的使其过滤行为的特征。

在较新的RFC 4787中,NAT的行为被细分为两个独立的维度:分配行为(Assignment Behavior)和过滤行为(Filtering Behavior)。这两种行为的各自分类描述了NAT在处理映射和过滤时的不同方式。以下是这两种行为的分类及其对应的早期NAT类型的对照。

3.3.1 分配行为(Assignment Behavior)

分配行为定义了NAT设备如何为内网设备的流量分配外部端口和地址。RFC 4787将其分为三类:

  • Endpoint-Independent Mapping(端点独立映射)

不管内网设备与哪个外部设备通信,只要内网设备使用同一个源IP和源端口,NAT都会为其分配相同的外部IP和端口。这意味着内网设备的源IP和源端口在外部网络上呈现为固定的外部IP和端口组合,独立于目标设备的地址和端口,即独立于目标设备的端点。

端点独立映射这种类别对应的早期NAT类型是完全锥形NAT(Full Cone NAT),前面我们讲过,在完全锥形NAT中,无论内网设备的通信目标是什么,NAT设备都会使用相同的外部端口映射,因此完全符合端点独立映射的定义。

  • Address-Dependent Mapping(地址依赖映射)

在地址依赖映射中,内网设备的外部端口是根据其通信的目标IP地址来分配的。如果内网设备改变了目标IP地址,即使源IP和源端口不变,NAT设备也会为其分配一个新的外部端口。

在分配行为上,我们似乎无法找到与早期分类一模一样的类型,它有些类似于对称NAT,但对称NAT不仅考虑目标IP,还考虑目标端口。

  • Address and Port-Dependent Mapping(地址和端口依赖映射)

在这种映射行为中,内网设备的外部端口是根据其通信的目标IP地址和目标端口组合来分配的。如果内网设备改变了目标IP或端口,即使源IP和源端口不变,NAT设备仍会分配一个新的外部端口。该类型对应的是早期NAT类型中的对称NAT(Symmetric NAT)。对称NAT的行为正是基于目标IP和端口的组合来分配外部端口,因此它完全符合地址和端口依赖映射的定义。

3.3.2 过滤行为(Filtering Behavior)

过滤行为描述了NAT设备如何决定是否允许外部设备通过NAT与内网设备通信。RFC 4787将其分为三类:

  • Endpoint-Independent Filtering(端点独立过滤)

这种类型的NAT设备不考虑外部设备的地址或端口,只要内网设备先发起了一个会话,任何外部设备都可以通过NAT设备与内网设备的相同源IP和源端口通信。这和早期NAT类型中的完全锥形NAT完全契合。

  • Address-Dependent Filtering(地址依赖过滤)

这种类型的NAT设备只允许内网设备已经与之通信的外部IP地址与其通信。换句话说,只有内网设备先与某个特定的外部IP地址通信后,该外部IP地址的设备才能通过NAT与内网设备通信。这和早期NAT类型中的限制锥形NAT(Restricted Cone NAT)在过滤行为的特征上是一致的。

  • Address and Port-Dependent Filtering(地址和端口依赖过滤)

这种类型的NAT设备要求外部设备的IP地址和端口都与内网设备已经建立连接的目标IP地址和端口匹配,才能允许通信。这意味着,只有内网设备先与某个特定的外部IP和端口组合通信后,该组合才能与内网设备通信。这与早期NAT类型中的端口限制锥形NAT(Port Restricted Cone NAT)以及对称NAT的行为特征是一致的。

可以看出,RFC 4787中的分类方法更为细致地将NAT的分配行为和过滤行为分开讨论,使得对NAT的行为理解更加明确。这种分类不仅帮助理解了不同NAT类型的工作机制,也为更精确地描述NAT行为提供了标准化的术语。

当然对于NAT打洞来说,我们更关心的显然是过滤行为

4. 小结

好了,这篇文章到这里就告一段落了。

在这篇文章中,我们探讨了WebRTC网络架构和NAT的工作原理。

我们首先了解了WebRTC的网络架构,包括信令服务器、STUN服务器、TURN服务器和ICE框架等组件和其作用。

然后,我们讨论了为什么需要NAT,包括解决IPv4地址短缺、提高安全性和简化网络管理等原因。

接着,我们详细解释了NAT的工作原理,以及完全圆锥型、受限圆锥型、端口受限圆锥型和对称型这四种主要的早期NAT类型。

最后,我们介绍了RFC 4787中对NAT行为的新分类方法,将NAT行为分为分配行为和过滤行为两个维度。

了解WebRTC网络架构以及NAT工作原理是理解NAT打洞机制以及WebRTC端到端建立连接过程的前提,在后续文章中,我们会继续WebRTC网络部分的内容,比如NAT打洞以及端到端建连过程。

5. 参考资料


Gopher部落知识星球在2024年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。同时,我们也会加强代码质量和最佳实践的分享,包括如何编写简洁、可读、可测试的Go代码。此外,我们还会加强星友之间的交流和互动。欢迎大家踊跃提问,分享心得,讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落,享受coding的快乐! 欢迎大家踊跃加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2024, bigwhite. 版权所有.

Related posts:

  1. 使用Go和WebRTC data channel实现端到端实时通信
  2. 如何在Go语言中使用Websockets:最佳工具与行动指南
  3. Hello,WireGuard
  4. 从简单到强大:再次探索Caddy服务器的魅力
  5. 通过实例理解Go Web身份认证的几种方式