WebRTC在对称NAT场景下无法穿透问题解析和方案

目录

• 什么是WebRTC？
  • 核心组件
  • 交互步骤
• 未使用Coturn案例
  • 场景1：A设备连接普通宽带
  • 场景2：A设备使用4G网络
• 使用Coturn案例
• 术语解释
  • SDP
  • 锥形 NAT（宽松 NAT）
  • 对称 NAT
  • ICE
  • STUN
  • TURN
  • 信令服务器

什么是WebRTC？

是一种支持浏览器之间实时音视频通信和数据传输的开放标准技术，无需安装插件或第三方软件。它被广泛应用于视频会议、在线教育、远程医疗、直播互动等场景。

核心组件

1. MediaStream（媒体流）
   获取用户的摄像头/麦克风
2. RTCPeerConnection（点对点连接）
   负责建立和管理音视频通信通道；处理编解码、带宽自适应、NAT 穿透等
3. RTCDataChannel（数据通道）
   支持低延迟的任意数据传输

交互步骤

以A、B两个设备作为例子，A呼叫B

1. 初始化 PeerConnection
   A 和 B 各自在本地创建 RTCPeerConnection 对象，此时只是设定服务相关代码配置，并无网络通信。

   const pc = new RTCPeerConnection({iceServers: [{ urls: "stun:stun.l.google.com:19302" },{ urls: "turn:your-turn.com:3478", username: "...", credential: "..." }]
   });
   

2. A 创建 Offer（生成 SDP）
   • 收集所有 ICE candidate（host / srflx / relay）
     • host：本机局域网地址（如 192.168.0.2）
     • srflx：通过 STUN 获取的公网反射地址（如 100.100.100.100:50000）
     • relay：通过 TURN 获取的中继地址（如 200.200.200.200:50001）
   • 列出支持的音视频编解码器
   • 生成一个 SDP Offer 文本
   • 通过信令服务器将 SDP Offer 发送给 B
3. B 收到 Offer，创建 Answer（生成 SDP）
   • 解析 A 的能力
   • 选择双方都支持的编解码器
   • 收集自己的 ICE candidate（host / srflx / relay）
   • 生成 SDP Answer 文本
   • B 通过信令服务器将 SDP Answer 发回给 A
4. ICE 候选地址交换（Trickle ICE）
   • 在步骤2、3之后，浏览器会持续发现新的 ICE candidate
     • 在连通性检查中动态发现的地址叫prflx
   • 每当发现一个新 candidate，A/B 将每个 candidate 单独通过信令服务器发送给对方
5. ICE 连接检查
   • 双方拿到对方的 candidate 后，开始 ICE 配对测试
     • 尝试所有组合：A 的 candidate × B 的 candidate
   • 发送 STUN binding request 测试连通性
     • 优先尝试 host → srflx（直连），如果失败，自动降级到 relay（中继）
   • 一旦某对地址能互通（如 A 的 relay ↔ B 的 srflx），就选定该路径
     • 双方发送 STUN Binding Request 中各包含一个 transaction ID
     • 双方各自收到Request后，用STUN Binding Request的 transaction ID 回复 STUN Binding Response
     • 收到对方的 STUN Binding Response，WebRTC 引擎验证 transaction ID 匹配
     • ICE 状态变为 connected → 媒体流开始传输
   • 建立 DTLS 加密通道 → SRTP 媒体流开始传输
6. 媒体流传输
   • 音视频数据通过选定的 UDP 路径直接传输（P2P）或经 TURN 中继

sequenceDiagramparticipant A as 客户端Aparticipant B as 客户端Bparticipant S as 信令服务器A->>A: 1. 创建 RTCPeerConnectionA->>A: 2. 收集 ICE Candidates (host/srflx/relay)B->>B: 同上A->>S: 3. 发送 offer + candidatesS->>B: 转发B->>S: 4. 发送 answer + candidatesS->>A: 转发A->>B: 5. 双方尝试所有 candidate pairsA->>B: 6. 进行连通性检查（STUN Binding Request）A->>B: 7. 选择最佳连通路径A-->>B: 8. 建立媒体/数据通道

未使用Coturn案例

A设备是一台4G移动终端，B设备是一台服务器，C设备是一台PC主机，B、C在一个局域网内，此局域网有公网IP。
这里假设：
- A：内网IP：10.0.0.2，WebRTC随机端口：1000，出口公网IP：100.0.0.2，Wi-Fi连接宽带IP：150.0.0.2
- B：内网IP：192.0.0.2，公网IP：200.0.0.2，信令服务器WebSocket端口：3000
- C：内网IP：192.0.0.3，公网IP：200.0.0.2，WebRTC随机端口4000
- D：STUN服务器IP：50.0.0.2:3478

场景1：A设备连接普通宽带

1. A设备发起对C设备的视频&语音通信，可以正常通信。
2. 步骤分析：
   1. 当 A 和 C 分别连接信令服务器（如 WebSocket）时，会建立一条 出站 TCP 连接。
      • A (10.0.0.2:1000) → 公网出口 (100.0.0.2:2000) → 信令服务器 (200.0.0.2:3000)
      • C (192.0.0.3:4000) → 公网出口 (200.0.0.2:4000) → 信令服务器 (200.0.0.2:3000)
   2. A向C发起请求的时候，其实是向信令服务器发送了自己的网络情况，让信令服务器把自己的信息发给C，然后C接收到了A的信息，也把自己的网络信息通过信令服务器发给了A。
   3. 等A接收到以后，A和C都往对方的公网IP发送连通请求包，这样又是在自己的网关端创建了A和C的NAT通道。
      • A (10.0.0.2:1000) → 公网出口 (100.0.0.2:2000) → C 公网出口 (200.0.0.2:4000)
      • C (192.0.0.3:4000) → 公网出口 (200.0.0.2:4000) → A 公网出口 (100.0.0.2:2000)
   4. 等着A和C完成 ICE 连通性检查，就连接成功了。
   sequenceDiagramparticipant Aparticipant Sig as 信令服务器participant CA->>Sig: WebSocket 连接（创建 NAT 通道1）C->>Sig: WebSocket 连接（创建 NAT 通道2）A->>Sig: 发送 offer + candidatesSig->>C: 转发C->>Sig: 发送 answer + candidatesSig->>A: 转发A->>C: UDP STUN Request（创建 NAT 通道3）C->>A: UDP STUN Request（创建 NAT 通道4）Note over A,C: 双方收到 STUN Response ICE 连通性检查成功 P2P 连接建立！

场景2：A设备使用4G网络

1. A设备发起对C设备的视频&语音通信，B、C可以收到通信请求，但是无法连接。
2. 核心原因：
   • 由于 4G 网络通常采用对称型 NAT（Symmetric NAT），A 设备访问不同目标（STUN 服务器 vs C 设备）时，会被分配不同的公网端口。因此，A 通过 STUN 获取的公网地址（100.0.0.2:2000）仅对 STUN 服务器有效，C 设备向该地址发包会被运营商丢弃，导致 ICE 连通性检查失败，无法建立 P2P 连接。
3. 步骤分析：
   1. A设备对C设备的公网地址200.0.0.2发起视频&语音通信。
   2. 此时处于WebRTC的步骤2收集ICE candidate阶段，A设备需要调用STUN服务查询公网IP和端口，所以运营商网关分配了一个100.0.0.2:2000外网端口，A设备（10.0.0.2:1000）通过此端口向STUN服务器发送请求：从运营商网关（100.0.0.2:2000）发送到STUN服务器（50.0.0.2:3478）。
   3. 运营商接收到A设备发起的请求，在NAT表中记录了一条：将STUN服务器（50.0.0.2:3478）发送向运营商网关（100.0.0.2:2000）的数据包转发给A设备（10.0.0.2:1000）。
   4. STUN服务器收到运营商网关（100.0.0.2:2000）的数据包以后，向运营商网关（100.0.0.2:2000）发送了一个响应包，告诉请求方的公网IP地址是多少。
   5. 运营商网关（100.0.0.2:2000）收到了STUN服务器（50.0.0.2:3478）的响应包，从NAT表中查询到这个数据包应该转发给A设备（10.0.0.2:1000）。
   6. A设备接收到了STUN服务器的响应包，于是把100.0.0.2:2000当作自己的公网IP地址，然后封装到SDP Offer中。
   7. 接着A设备（10.0.0.2:1000）会把SDP Offer包通过信令服务器WebSocket服务（200.0.0.2:3000）发送给C设备（200.0.0.2:4000）。
   8. 运营商网关收到了10.0.0.2:1000 → 200.0.0.2:3000的发包请求，由于100.0.0.2:2000的端口被50.0.0.2:3478使用过了，根据对称NAT的安全策略要求，所以运营商网关为这个请求创建了新的端口100.0.0.2:2001，然后在NAT表上记录了一条：将信令服务器WebSocket服务（200.0.0.2:3000）发送给运营商网关（100.0.0.2:2001）的数据包转发给A设备（10.0.0.2:1000），之后数据包顺着100.0.0.2:2001发送了出去。
   9. 信令服务器WebSocket服务收到A设备的SDP Offer包以后，将包转发给了C设备。
   10. C设备收到A设备的SDP Offer包，解析后知道了A设备的公网IP是100.0.0.2:2000，于是开始准备自己的SDP Answer包，也执行了一遍STUN服务器请求，将STUN服务器返回的C设备的公网IP（200.0.0.2:4000）。
   11. C设备（200.0.0.2:4000）将SDP Answer包发送给信令服务器WebSocket服务（200.0.0.2:3000），信令服务器检查到是C设备对A设备的回包，所以信令服务器将SDP Answer包发往A设备请求时来的运营商网关（100.0.0.2:2001）。
   12. 运营商网关（100.0.0.2:2001）接收到了信令服务器WebSocket服务（200.0.0.2:3000）的数据包，检查NAT表发现需要将数据转发给A设备（10.0.0.2:1000），所以将SDP Answer包转发给了A设备。
   13. A设备接收到C设备的SDP Answer包，知道了C设备的公网IP是200.0.0.2:4000，所以开始WebRTC的ICE 连通性检查阶段（步骤5），通过尝试A设备和C设备的候选地址组合，尝试建立连接；C设备在发出SDP Answer包的同时，也开始尝试C设备和A设备的候选地址组合，尝试建立连接。
   14. A设备（10.0.0.2:1000）拿着C设备的公网200.0.0.2:4000尝试建立连接，运营商网关发现这又是一个新的目标IP，所以根据对称NAT的安全策略要求，创建了新的端口100.0.0.2:2002，然后在NAT表中创建了一条：将C设备（200.0.0.2:4000）发送给运营商网关（100.0.0.2:2002）的数据包转发给A设备（10.0.0.2:1000），之后把测试连接数据包发送给C设备。
   15. C 设备尝试向 A 报告的 srflx 地址 100.0.0.2:2000 发送 STUN Binding Request，但该端口仅对 STUN 服务器 50.0.0.2:3478 开放。由于对称 NAT 的端口绑定策略，来自 200.0.0.2:4000 的数据包被运营商网关视为非法，直接丢弃。而 A 向 C 发起的连接使用的是新端口 100.0.0.2:2002，双方端口不匹配，导致双向打洞失败。
   16. 从而导致设备A和设备C无法构建P2P连接。
   sequenceDiagramtitle WebRTC 连接失败：A(4G, 对称NAT) → C(公网可达)participant A as A设备<br/>(10.0.0.2:1000)participant GW as 运营商网关<br/>(对称NAT)participant STUN as STUN服务器<br/>(50.0.0.2:3478)participant Sig as 信令服务器<br/>(200.0.0.2:3000)participant C as C设备<br/>(192.0.0.3 → 公网200.0.0.2:4000)Note over A,GW: 阶段1: A收集ICE候选地址（调用STUN）A->>GW: 出站UDP → STUNGW->>STUN: 转发 (源: 100.0.0.2:2000)Note right of GW: NAT表:<br/>10.0.0.2:1000 ↔ 100.0.0.2:2000<br/>仅允许50.0.0.2:3478回包STUN-->>GW: 响应 (目标: 100.0.0.2:2000)GW-->>A: 转发响应A->>A: 记录 candidate: srflx 100.0.0.2:2000Note over A,Sig: 阶段2: 通过信令交换SDPA->>GW: 出站TCP → 信令服务器GW->>Sig: 转发 (源: 100.0.0.2:2001) Note right of GW: 对称NAT!<br/>新目标 → 新端口2001<br/>NAT表新增:<br/>10.0.0.2:1000 ↔ 100.0.0.2:2001<br/>仅允许200.0.0.2:3000回包Sig->>C: 转发 SDP Offer<br/>(含A的candidate: 100.0.0.2:2000)C->>C: 收集自身candidate<br/>(如 200.0.0.2:4000)C->>Sig: 发送 SDP AnswerSig->>GW: 转发 Answer 到 100.0.0.2:2001GW->>A: 转发 AnswerNote over A,C: 阶段3: ICE连通性检查（打洞尝试）A->>GW: 出站UDP → C (200.0.0.2:4000)GW->>C: 转发 (源: 100.0.0.2:2002)Note right of GW: 又一新目标 → 新端口2002!<br/>NAT表新增:<br/>10.0.0.2:1000 ↔ 100.0.0.2:2002<br/>仅允许200.0.0.2:4000回包C->>C: 尝试向A报告的地址发包<br/>(100.0.0.2:2000)C->>GW: UDP → 100.0.0.2:2000Note right of GW: ❌ 匹配失败!<br/>端口2000只接受<br/>50.0.0.2:3478的回包<br/>来自200.0.0.2:4000的包被丢弃!Note over GW,C: 结果: 双向打洞失败Note over A,C: A用2002发包，C往2000发包 → 端口不匹配!
4. 与场景1的区别
   1. 因为设备A是在普通宽带场景下，运营商执行的是锥形NAT策略，A设备可以先通过运营商网关（100.0.0.2:2000）的2000端口发送请求，然后再次使用2000端口发送给WebSocket服务（200.0.0.2:3000），等着A设备与C设备通信的时候，依旧使用的是运营商网关的2000端口，这样就实现了P2P直连。

使用Coturn案例

解决办法可见【Docker - 使用Coturn实现WebRTC稳定连接】

术语解释

SDP

Session Description Protocol，会话描述协议。是 WebRTC 和许多实时通信系统中用于协商媒体通信参数的核心文本格式。

• SDP 的本质：一份“通信能力清单 + 联系方式”
  我的 IP 和端口是多少？（网络层）
  我支持 H.264 还是 VP8 视频？（编解码）
  音频用 Opus 还是 G.711？
  是否支持屏幕共享？
  如何加密？（DTLS/SRTP）

锥形 NAT（宽松 NAT）

1. 分类
   • 完全锥形 NAT（Full Cone）：允许任何外部 IP 发包进来
   • 受限锥形 NAT（Restricted Cone）：只允许曾通信过的外部 IP发包进来
   • 端口受限锥形 NAT（Port-Restricted Cone）：只允许曾通信过的外部 IP + 端口发包
2. 特点
   • 同一个内网 IP:Port，无论访问哪个外部地址，映射的公网端口是固定的。
   • STUN 能正确获取公网地址（srflx candidate），双方同时向对方公网地址发包（“打洞”），即可建立直连。
3. 使用场景
   • 家庭宽带
   • 普通企业NAT

对称 NAT

1. 特点
   • 同一个内网 IP:Port，访问不同外部目标时，会分配不同的公网端口！
   • srflx candidate 无法用于直连，必须依赖 TURN 中继（relay candidate）
2. 使用场景
   • 企业防火墙
   • 校园网
   • 4G/5G 网络
   • 云服务器

ICE

是一套用于建立端到端网络连接的标准化框架，尤其用于解决 NAT（网络地址转换） 和 防火墙 带来的通信障碍

1. 核心思想
   不依赖单一地址，而是收集所有可能的网络地址（本地、公网、中继）。
   尝试所有可能的地址组合（称为 candidate pairs）。
   通过 连通性检查（Connectivity Checks） 找出能通的路径。
   选择延迟最低、质量最好的路径进行通信。
2. 技术
   • STUN：获取公网反射地址（srflx candidate）
   • TURN：获取中继地址（relay candidate），用于保底通信
   • SDP：在信令阶段交换 ICE 候选地址
   • UDP/TCP：实际传输协议

STUN

STUN 是一种轻量级协议，用于帮助客户端发现自己的公网 IP 地址和端口（即“NAT 映射后的地址”），并检测 NAT 类型

1. 工作原理
   • 客户端向公网 STUN 服务器发送请求。
   • STUN 服务器看到请求来自某个公网 IP:Port（例如 100.100.100.100:50000）。
   • 服务器将这个公网地址返回给客户端。
   • 客户端得知在外网看来是 100.100.100.100:50000。
2. 用途
   • 获取 srflx（server reflexive）类型的 ICE 候选地址
   • 用于 P2P 直连（如果双方 NAT 允许打洞）
3. 局限
   • 无法穿透对称型 NAT（Symmetric NAT）
   • 不提供数据中继，仅用于“地址发现”

TURN

TURN 是一种中继协议，当 P2P 直连失败时，通过 TURN 服务器中转音视频或数据流。

1. 工作原理
   • 客户端向 TURN 服务器申请一个“中继地址”（如 turn.example.com:50001）
   • TURN 服务器分配一个公网 IP 和端口，并告知客户端。
   • 双方都将数据发送到该中继地址，由 TURN 服务器转发。
2. 用途
   • 提供 relay（中继）类型的 ICE 候选地址
   • 100% 确保连接成功（即使在对称 NAT 或防火墙严格环境下）
3. 缺点
   • 消耗服务器带宽和资源（所有流量经过服务器）。
   • 增加延迟（非直连）。
   • 需要认证和计费管理（防止滥用）。

信令服务器

信令服务器 是 WebRTC 中用于交换连接元数据（metadata） 的中间服务器。它不传输音视频或数据内容，只负责“牵线搭桥”

1. 信令
   • 网络地址（ICE candidates）
   • 媒体能力（音频/视频编码格式、分辨率等）
   • 会话控制信息（谁发起、谁应答）
2. 为什么要用
   • WebRTC 本身 没有内置信令机制。两个浏览器要建立 P2P 连接，必须先知道对方的信令，需要通过一个双方都能访问的第三方服务器传递。
3. 传递数据类型
   • SDP：描述媒体能力与会话参数
   • ICE Candidates：网络候选地址
4. 传递流程
   sequenceDiagram participant A as 浏览器A participant S as 信令服务器 participant B as 浏览器BA->>S: 发送 SDP offer S->>B: 转发 offer B->>S: 发送 SDP answer S->>A: 转发 answer loop ICE候选地址A->>S: 发送 candidateS->>B: 转发 candidateB->>S: 发送 candidateS->>A: 转发 candidate end A-->>B: WebRTC P2P 连接建立
5. 在WebRTC中生效的阶段
   第2->5步（见WebCRT交互步骤）
6. 技术实现
   可以用任何双向通信方式实现信令服务器，例如：WebSocket、Socket.IO、MQTT