三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

WebRTC通信核心：STUN与TURN服务原理、部署与实战调试指南

发布时间：2026/8/5 9:26:12 三亩地 编程学习日记
WebRTC通信核心：STUN与TURN服务原理、部署与实战调试指南

1. 从一次失败的音视频通话说起：为什么我们需要STUN和TURN？

如果你尝试过自己搭建一个点对点的音视频通话应用，比如一个简单的视频会议Demo，你可能会遇到一个令人困惑的场景：在同一个Wi-Fi网络下，两台电脑可以毫无障碍地通话；但一旦把其中一台电脑拿到公司，另一台放在家里，连接就死活建立不起来，浏览器控制台里可能还会报一个“ICE连接失败”的错误。这个问题的根源，十有八九出在NAT（网络地址转换）和防火墙身上，而解决这个问题的关键，就是WebRTC协议栈中的两个核心服务：STUN和TURN。

简单来说，STUN（Session Traversal Utilities for NAT，NAT会话穿越实用工具）和TURN（Traversal Using Relays around NAT，使用中继穿透NAT）是WebRTC实现P2P（点对点）连接的两大基石。它们共同构成了ICE（Interactive Connectivity Establishment，交互式连接建立）框架的候选地址收集机制。没有它们，在复杂的互联网环境下，想让两个位于不同私有网络后的设备直接“找到”并“连接”彼此，几乎是不可能的任务。

这篇文章，我将结合自己多次部署和调试WebRTC服务的经验，深入拆解STUN和TURN。我不会只停留在概念层面，而是会带你理解它们各自解决什么问题、在什么场景下会失效、以及在实际项目中如何正确地选型和部署。你会发现，理解这两个服务，不仅是使用WebRTC的必备知识，更是理解现代互联网P2P通信底层逻辑的一把钥匙。

2. NAT与防火墙：P2P通信的“天然屏障”与穿越原理

要理解STUN和TURN的价值，必须先搞清楚它们要对抗的“敌人”——NAT和防火墙。这不是枯燥的理论，而是决定你代码能否跑通的关键背景。

2.1 为什么局域网内畅行无阻，公网就“失联”？

想象一下公司的网络。公司路由器有一个公网IP（比如203.0.113.1），而你的办公电脑被分配了一个私有IP（比如192.168.1.100）。当你访问百度时，数据包从192.168.1.100:54321（随机端口）发出，经过公司NAT设备。NAT设备会做一次“地址转换”，记录下这条映射关系：“内网192.168.1.100:54321对应外网203.0.113.1:55000”，然后把源地址改写成公网IP和端口，再发出去。百度的服务器回复到203.0.113.1:55000，NAT设备再根据之前记录的映射表，把数据包转发给你的电脑。

这个过程对客户端访问服务器是透明的，也是互联网能容纳数十亿设备的基础。但它给P2P通信带来了一个致命问题：你的设备没有固定的、可从公网直接访问的地址。你的电脑只知道自己的内网IP（192.168.1.100），而对方设备只知道你公司路由器的公网IP（203.0.113.1），但不知道NAT上为你临时分配的哪个端口（55000）。对方试图向203.0.113.1:55000发送数据时，这个端口映射可能已经过期或根本不存在（因为那是你向外访问时创建的），导致连接失败。

防火墙则增加了另一层规则：它可能阻止所有未经请求的入站连接。即使NAT映射存在，防火墙也可能直接丢弃从公网发来的、试图建立新连接的数据包。

2.2 ICE框架：系统化的连接建立策略

WebRTC不把希望寄托在某种单一的连接方式上，而是采用了一套系统化的探索策略，这就是ICE框架。它的工作流程可以概括为：

  1. 收集候选地址（Candidates）：每个端尽可能收集所有可能用于通信的地址，包括：
    • 主机候选地址（Host Candidate）：本机的内网IP地址。
    • 服务器反射候选地址（Server Reflexive Candidate）：通过STUN服务器探测到的、NAT设备分配给你的公网IP和端口。这是STUN的核心作用。
    • 中继候选地址（Relayed Candidate）：通过TURN服务器分配的中转地址。这是TURN的核心作用。
  2. 交换候选地址：双方通过信令服务器（如WebSocket）交换各自收集到的候选地址列表。
  3. 连接检查（Connectivity Checks）：双方按照优先级，尝试用所有可能的地址对进行连接。例如，A用它的服务器反射地址连接B的主机地址，B用它的中继地址连接A的服务器反射地址等等。
  4. 选择最佳连接：一旦某对地址成功建立连接，ICE就将其选为通信路径，并放弃其他尝试。

这个流程的精妙之处在于其健壮性。它不预设网络环境，而是通过主动探测和多重尝试，找到那条“能走通的路”。而STUN和TURN，就是为这个流程提供关键候选地址的“侦察兵”和“后勤部队”。

3. STUN服务详解：充当“镜子”的侦察兵

STUN协议非常简单，它的核心功能就是充当一面“镜子”。客户端向公网上的STUN服务器发送一个请求：“告诉我，在你看来，我的地址是什么？”

3.1 STUN协议的工作机制与报文解析

STUN是一个轻量级的客户端-服务器协议。客户端发送一个Binding Request报文到STUN服务器（通常使用UDP 3478端口）。STUN服务器收到这个从NAT后面发来的报文时，它会查看报文的源IP地址和源端口。这个源地址已经不是客户端的私有IP了，而是经过了客户端NAT设备转换后的公网IP和端口。

然后，STUN服务器将这个信息包装在一个Binding Response报文中，发回给客户端。响应报文中包含一个XOR-MAPPED-ADDRESS属性，里面就是服务器看到的客户端的公网IP和端口。

// 这是一个概念性的示意，并非真实代码 客户端 (192.168.1.100:54321) ---[请求]---> STUN服务器 (stun.example.com:3478) 源地址: 192.168.1.100:54321 服务器看到源地址: 203.0.113.1:55000 客户端 (192.168.1.100:54321) <---[响应]--- STUN服务器 (stun.example.com:3478) 响应内容: “你的映射地址是 203.0.113.1:55000”

通过这个过程，客户端就获得了一个关键的“服务器反射候选地址”。它可以将这个地址通过信令告诉对端：“嘿，你可以尝试通过203.0.113.1:55000这个地址来联系我。”

3.2 STUN的局限性：并非万能钥匙

STUN虽然巧妙，但它只能解决一部分NAT问题，主要在“锥型NAT”环境下工作良好。它的局限性非常明显：

  1. 对称型NAT（Symmetric NAT）的克星：在对称型NAT下，设备访问不同的外部目标IP和端口，NAT会分配不同的公网端口。这意味着，客户端通过STUN服务器（IP_A）获取的公网端口（Port_X），用于连接另一个对等端（IP_B）时是无效的，因为对等端向IP_A:Port_X发送的数据，NAT不会转发给客户端。STUN在此失效。
  2. 无法穿透防火墙：如果防火墙严格禁止所有入站UDP包，那么即使STUN帮客户端发现了公网地址，对端发来的数据包也会在防火墙处被丢弃。
  3. 依赖第三方服务器：你需要一个部署在公网、拥有固定IP的STUN服务器。虽然有很多公共STUN服务器（如Google的stun.l.google.com:19302），但在生产环境中，出于隐私、稳定性和延迟考虑，通常需要自建。

注意：在实际的WebRTC配置中，你通常需要提供一个STUN服务器地址数组。浏览器会依次尝试，只要有一个成功即可。公共服务器适合开发和测试，但绝不能用于正式产品。

// WebRTC 中配置 STUN 服务器的典型代码片段 const peerConnectionConfig = { iceServers: [ { urls: 'stun:stun.example.com:3478' // 自建STUN服务器 }, { urls: 'stun:stun.l.google.com:19302' // 公共STUN服务器，备用 } // 通常还会配置TURN服务器，见下文 ] };

4. TURN服务详解：当P2P走不通时的“中继枢纽”

当STUN失效，即双方无法建立直接的P2P连接时（例如双方都在对称型NAT之后，或防火墙规则过于严格），TURN就是最后的保障。TURN的角色从一个“侦察兵”变成了“中继站”或“快递中转中心”。

4.1 TURN的核心原理：数据中转

TURN客户端首先通过一个经过认证的请求，在TURN服务器上“分配”一个资源。服务器会为这个客户端在公网上提供一个专有的IP地址和端口（即中继地址）。然后，客户端告诉对端：“请把所有数据都发到TURN服务器的这个中继地址（turn.example.com:3478）。”

此后，所有通信都经由TURN服务器中转：

  1. 客户端A将媒体流发送到TURN服务器。
  2. TURN服务器将数据转发给客户端B的中继地址（如果B也使用了TURN）或直接发送给B（如果B有可达地址）。
  3. 客户端B发送数据的过程同理。

这样一来，通信双方不再需要直接寻址对方，它们只需要能连接到作为中间人的TURN服务器即可。这完美避开了NAT和防火墙的穿透问题。

4.2 TURN与STUN的关系：协议共生

一个常见的误解是TURN和STUN是两个完全独立的东西。实际上，TURN协议是STUN协议的扩展。TURN服务器通常兼容STUN协议。也就是说，一个在UDP 3478端口上监听的TURN服务器，也能响应普通的STUNBinding Request。因此，在WebRTC配置中，你给iceServers添加一个TURN服务器地址，ICE Agent会先尝试用它做STUN（获取服务器反射地址），如果P2P失败，再将其用作TURN中继。

这也是为什么配置里常看到turn:和stun:共用同一个服务器地址和端口。它们本质上是同一个服务，支持不同的功能模式。

4.3 TURN的代价：性能、成本与部署复杂性

使用TURN意味着放弃P2P的低延迟和低成本优势，带来显著的副作用：

  1. 带宽成本翻倍：所有流量都要经过TURN服务器中转，服务器的入站和出站带宽消耗是直接P2P的两倍。如果你的应用流量很大，TURN服务器的带宽费用会成为主要成本。
  2. 增加延迟：数据多走了一趟“弯路”，必然会增加端到端的延迟，对实时音视频体验的影响是直接的。
  3. 成为单点故障和性能瓶颈：TURN服务器的稳定性、处理能力和网络质量，直接决定了所有依赖中继的通信质量。一旦服务器宕机或拥塞，大量通话会中断。
  4. 部署和维护复杂：TURN服务器需要配置用户认证（如长期凭证机制）、管理分配端口、监控带宽和连接数等，比部署一个简单的STUN服务器复杂得多。

因此，一个核心原则是：将TURN作为保底方案，优先使用STUN建立P2P连接。ICE框架的优先级排序正是体现了这一点：主机候选地址优先级最高，服务器反射次之，中继候选地址优先级最低。系统会优先尝试直连。

5. 实战部署：自建STUN/TURN服务器（以coturn为例）

理解了原理，我们来动手部署。在开源世界中，coturn项目是功能最全面、最流行的STUN/TURN服务器实现。下面我将以Ubuntu系统为例，分享从编译安装到关键配置的完整过程，以及我踩过的几个坑。

5.1 环境准备与源码编译

为什么不直接用包管理器安装？因为很多系统仓库中的版本可能较旧，缺少重要特性或存在已知漏洞。编译安装能确保我们获得最新且可定制化的版本。

# 1. 更新系统并安装编译依赖 sudo apt update sudo apt install -y build-essential libssl-dev libevent-dev libhiredis-dev # 2. 下载最新版coturn源码（请访问GitHub releases页面获取最新版本号） wget https://github.com/coturn/coturn/archive/refs/tags/4.6.2.tar.gz -O coturn-4.6.2.tar.gz tar -xzf coturn-4.6.2.tar.gz cd coturn-4.6.2 # 3. 配置、编译和安装 ./configure make -j$(nproc) sudo make install

踩坑记录1：依赖缺失。第一次编译时，因为缺少libevent-dev，configure阶段虽然通过了，但运行时报错找不到相关符号。确保所有开发库都已安装。如果计划使用数据库（如MySQL/Redis）存储用户，还需安装对应的libmysqlclient-dev或libhiredis-dev。

5.2 关键配置文件详解与安全设置

安装后，配置文件通常位于/usr/local/etc/turnserver.conf或/etc/turnserver.conf。我们需要创建一个自定义配置。以下是一个兼顾功能与安全的基础配置：

# 创建配置目录和文件 sudo mkdir -p /etc/coturn sudo nano /etc/coturn/turnserver.conf

将以下配置粘贴进去，并务必根据你的实际情况修改：

# 监听IP和端口。`0.0.0.0`表示监听所有网络接口。3478是STUN/TURN标准UDP端口。 listening-ip=0.0.0.0 listening-port=3478 # 中继数据的IP地址。这里必须设置为服务器的公网IP地址，否则客户端拿到错误的中继地址。 external-ip=你的公网IP地址 # 更安全的方式是，如果服务器有多个IP或处于复杂网络（如AWS），使用以下格式： # external-ip=公网IP/内网IP # 例如：external-ip=60.70.80.90/172.31.32.33 # 设置领域（Realm），用于认证域划分，可以设为你的域名。 realm=yourdomain.com # 用户认证配置（长期凭证机制 - Long-Term Credential Mechanism） # 这是WebRTC推荐的方式。格式为 `user=password`。生产环境应使用动态数据库。 user=username1:password1 user=username2:password2 # 或者使用更安全的密钥派生方式，但需要客户端支持。 # 日志文件路径 log-file=/var/log/turn.log simple-log # 安全与资源限制 # 限制单个进程的文件描述符数量，防止DoS no-loopback-peers no-multicast-peers # 允许的端口范围（中继端口范围） min-port=49152 max-port=65535 # 启用STUN协议支持 stun-only

踩坑记录2：external-ip配置错误。这是新手最容易出错的地方。如果你在云服务器（如AWS EC2、阿里云ECS）上部署，external-ip必须填服务器的弹性公网IP（EIP），而不是内网IP。填错会导致客户端拿到错误的中继地址，从而无法通信。你可以通过命令curl ifconfig.me或ip addr show来确认公网IP。

5.3 系统服务配置与防火墙放行

为了让coturn在系统启动时自动运行，并管理其生命周期，我们将其配置为systemd服务。

sudo nano /etc/systemd/system/coturn.service

输入以下内容：

[Unit] Description=coturn STUN/TURN Server After=network.target [Service] Type=simple User=nobody Group=nogroup ExecStart=/usr/local/bin/turnserver -c /etc/coturn/turnserver.conf Restart=on-failure RestartSec=10 LimitNOFILE=65536 [Install] WantedBy=multi-user.target

然后启动服务并设置开机自启：

sudo systemctl daemon-reload sudo systemctl start coturn sudo systemctl enable coturn sudo systemctl status coturn # 检查运行状态

最后，至关重要的一步：在服务器的防火墙（如ufw或云服务商的安全组）中，开放UDP 3478端口，以及你配置的中继端口范围（如49152-65535）。

# 如果使用ufw sudo ufw allow 3478/udp sudo ufw allow 49152:65535/udp # 如果使用AWS安全组、阿里云安全组等，请在控制台相应配置入站规则。

5.4 服务测试与验证

部署完成后，必须进行测试。可以使用coturn自带的客户端工具，或者在线STUN/TURN测试工具。

方法一：使用turnutils_uclient测试（服务器本地测试）

# 测试STUN功能 turnutils_uclient -v -S -t -s -y -u username1 -w password1 你的服务器IP # 测试TURN中继功能（更全面） turnutils_uclient -v -t -s -y -u username1 -w password1 你的服务器IP

观察输出，看是否有allocate success等成功信息。

方法二：使用在线工具测试访问像https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/这样的页面。在“ICE服务器”配置框中输入：

stun:你的服务器IP:3478 turn:你的服务器IP:3478?transport=udp turn:你的服务器IP:3478?transport=tcp

用户名和密码填你在配置文件中设置的。然后点击“添加服务器”和“收集候选地址”。如果能看到类型为srflx(STUN) 和relay(TURN) 的候选地址，并且状态是“完成”，说明服务器配置成功。

6. 高级议题与优化策略

当基础服务跑通后，在生产环境中我们会面临更多挑战。以下是几个关键的进阶话题。

6.1 TURN服务器的TCP与TLS支持

默认情况下，TURN使用UDP。但在某些极端网络环境下（如某些企业防火墙只允许HTTPS流量），UDP会被完全阻断。此时，需要启用TURN over TCP，甚至TURN over TLS (TCP + SSL加密)。

在coturn配置文件中添加：

# 启用TCP监听 listening-port=3478 tls-listening-port=5349 # TLS监听端口 # 指定证书和私钥文件（用于TLS） cert=/etc/ssl/your_cert.pem pkey=/etc/ssl/your_private.key # 允许的传输协议 allowed-peer-ip=0.0.0.0/0 denied-peer-ip=0.0.0.0/0 no-tcp-relay no-tls no-dtls # 要启用TCP和TLS，需要将上述三个`no-`选项注释掉或设为`no-tcp-relay=false`等。

在WebRTC配置中，则需要添加对应的服务器URL：

{ urls: [ 'turn:turn.example.com:3478?transport=udp', 'turn:turn.example.com:3478?transport=tcp', // TCP回退 'turns:turn.example.com:5349?transport=tcp' // TLS加密，注意是 `turns:` ], username: '...', credential: '...' }

注意：TLS需要有效的SSL证书。对于TURN over TLS (turns:)，浏览器要求证书必须由可信CA签发，自签名证书会导致连接失败。这是与信令服务器WebSocket WSS类似的安全要求。

6.2 负载均衡与高可用部署

单个TURN服务器存在单点故障风险。对于大规模应用，需要部署TURN服务器集群。这带来两个问题：

  1. 负载均衡：如何将客户端请求分发到不同的TURN服务器？
  2. 会话同步：如果客户端A连接到TURN-1，客户端B连接到TURN-2，它们之间如何中继？数据需要在服务器间转发，增加了复杂性和延迟。

常见的解决方案是：

  • DNS负载均衡：为TURN服务配置一个域名，通过DNS轮询返回多个服务器IP。但故障转移不灵敏。
  • 使用支持集群的TURN服务器：如coturn支持与Redis共享分配信息，但服务器间的媒体流转发仍需额外的网络配置（如IP组播或对等连接），实现复杂。
  • 应用层引导：信令服务器根据地理位置、负载情况，动态地为每个会话分配最优的TURN服务器地址。这是更灵活但开发量更大的方案。

在实践中，对于中小规模应用，更务实的做法是：在不同地域的多个云服务商处部署独立的TURN服务器，并在客户端iceServers列表中配置所有这些服务器地址。ICE框架会并行测试，自动选择可用的最佳路径。这提供了简单的故障转移能力。

6.3 监控、日志与成本控制

TURN服务器是资源消耗大户，必须做好监控。

  1. 关键监控指标：

    • 带宽：入站和出站带宽。这是成本核心。
    • 连接数：当前活跃的TURN分配（Allocation）数量。
    • 数据吞吐量：每秒转发的数据包数量。
    • CPU和内存使用率。

  2. 日志分析：coturn的日志可以记录每个分配的创建、销毁、权限绑定和流量统计。定期分析日志，可以识别异常连接（如单个IP大量分配，可能是滥用）、验证认证机制是否正常工作。

  3. 成本控制策略：

    • 设置带宽上限：在云服务商处为TURN服务器实例设置出站带宽告警和硬限制。
    • 使用流量计费套餐：选择按流量计费的云服务器，而非固定带宽。
    • 优化ICE策略：在客户端调整ICE参数，如iceTransportPolicy设置为all（默认，优先P2P）而非relay（强制中继）。鼓励用户改善网络环境（如关闭对称型NAT）。
    • 区分计费：对于中继流量远高于P2P流量的用户（可能处于严格网络环境），考虑采用不同的计费策略。

7. 在WebRTC应用中配置与调试ICE

最后，我们回到代码层面，看看如何在WebRTC应用中正确配置STUN/TURN服务器，以及如何调试ICE连接问题。

7.1 客户端配置的最佳实践

一个健壮的iceServers配置应该包含多个备选方案，并按优先级排序。

const iceServers = [ // 1. 首选自建STUN服务器（延迟最低） { urls: 'stun:stun.yourcompany.com:3478' }, // 2. 备用公共STUN服务器 { urls: [ 'stun:stun1.l.google.com:19302', 'stun:stun2.l.google.com:19302' ] }, // 3. 自建TURN服务器（UDP，主中继） { urls: 'turn:turn.yourcompany.com:3478?transport=udp', username: '动态或静态用户名', credential: '密码' }, // 4. TURN over TCP（针对阻断UDP的网络） { urls: 'turn:turn.yourcompany.com:3478?transport=tcp', username: '动态或静态用户名', credential: '密码' }, // 5. TURN over TLS（最安全，兼容性要求高） { urls: 'turns:turn.yourcompany.com:5349?transport=tcp', username: '动态或静态用户名', credential: '密码' } ]; const pc = new RTCPeerConnection({ iceServers });

关于用户名和凭证：在生产环境中，绝对不要将硬编码的凭证放在前端代码中。应采用“临时凭证”机制。客户端在建立连接前，先从你的应用服务器获取一个有过期时间的临时用户名和密码（通常由TURN服务器和你的应用服务器共享一个密钥生成）。这大大提升了安全性。

7.2 利用ICE连接状态与候选地址进行调试

WebRTC提供了丰富的API来监控ICE状态。

pc.oniceconnectionstatechange = () => { console.log('ICE connection state:', pc.iceConnectionState); // 状态包括：new, checking, connected, completed, failed, disconnected, closed // `failed` 通常意味着所有候选地址对都尝试连接失败，需要检查STUN/TURN配置或网络。 }; pc.onicecandidate = (event) => { if (event.candidate) { console.log('发现新的候选地址:', event.candidate); // candidate.type 可以是 'host', 'srflx' (STUN), 'prflx' (对端反射), 'relay' (TURN) // candidate.protocol 可以是 'udp' 或 'tcp' // candidate.address 是IP地址 // 通过信令服务器发送给对端 } else { console.log('ICE候选地址收集结束'); } }; pc.onicegatheringstatechange = () => { console.log('ICE gathering state:', pc.iceGatheringState); // 状态包括：new, gathering, complete };

当通话连接失败时，首先检查pc.iceConnectionState是否变为failed。然后，检查onicecandidate事件中收集到的候选地址类型：

  • 如果只有host类型，说明STUN服务器没有响应或无法访问。检查STUN服务器地址、端口、防火墙。
  • 如果有srflx类型但没有relay，说明STUN成功但TURN可能未配置或失败。此时如果P2P失败（如双方对称NAT），连接就会失败。
  • 如果有relay类型，说明TURN服务器工作正常。如果此时连接还失败，可能是信令交换候选地址出错，或者TURN服务器分配的中继地址无法连通对端。

7.3 一个真实的排错案例：对称NAT与TCP回退

我曾遇到一个案例：用户A在某个特定企业网络下，只能与部分用户通话，与另一部分用户则失败。通过日志发现：

  • 用户A收集到了srflx地址和relay地址。
  • 与用户B（家庭网络）通话成功，使用的是srflx（P2P）。
  • 与用户C（另一企业网络）通话失败。日志显示双方都尝试了对方的srflx地址但超时，最终似乎没有尝试中继地址。

排查过程：

  1. 检查ICE候选地址交换，确认双方的relay地址都已成功交换。
  2. 在用户A和C的浏览器中打开chrome://webrtc-internals，查看ICE候选地址对和检查结果。发现浏览器确实尝试了relay-relay配对，但状态是“失败”。
  3. 进一步查看TURN服务器日志，发现用户A的连接来自一个UDP端口，但用户C的网络似乎丢弃了所有入站UDP包（极其严格的防火墙）。
  4. 解决方案：在TURN服务器和客户端配置中强制启用TCP回退。在用户C的网络中，TCP 443或80端口通常是开放的。我们将TURN服务器配置为同时监听TCP 3478，并在客户端iceServers中明确添加transport=tcp的配置。之后，用户A和C成功通过TURN over TCP建立了中继连接。

这个案例的教训是：网络环境的多样性远超想象。一个健壮的WebRTC应用必须提供UDP、TCP乃至TLS多种传输层协议的后备选项，并将TURN服务器作为连接成功的最终保障。理解STUN和TURN，就是理解如何在错综复杂的网络迷宫中，为实时通信开辟出一条可靠的道路。

编程学习 学习日记 实战经验
← 返回列表