WebRTC 是怎么建立连接的？信令、STUN、TURN 和 ICE 分别做什么？

简化版

WebRTC 用于浏览器或客户端之间实时音视频和数据通信。它真正的媒体数据尽量走 P2P，但建立连接前需要业务信令交换 SDP offer/answer 和候选地址；STUN 用来发现公网映射地址；TURN 在 P2P 打不通时中继流量；ICE 负责收集候选地址、连通性检查并选出可用路径。

详细版

WebRTC 建连可以拆成四步：

1. 信令服务器交换 SDP offer/answer
2. 双方收集 host / srflx / relay 候选地址
3. ICE 做连通性检查
4. 选出最佳候选对，建立 DTLS/SRTP 加密媒体通道

信令不是 WebRTC 标准强制规定的协议，可以用 WebSocket、HTTP、MQTT 等实现。STUN 只帮助发现 NAT 后的公网映射，不转发媒体；TURN 会转发媒体，成功率高但带宽成本大；ICE 是协调者，把本机地址、STUN 地址、TURN 地址都拿来尝试，选出能通且优先级最高的路径。

面试重点是不要把信令、STUN、TURN 混在一起。信令传“协商信息”，STUN 查“我在公网看起来是谁”，TURN 做“中继兜底”，ICE 做“候选收集和路径选择”。

完整版教学

一、WebRTC 为什么建连这么复杂

如果两台机器都有公网 IP，它们可以直接互连。但现实中客户端大多在 NAT 后面：家庭路由器、公司网关、运营商 NAT 都会把内网地址隐藏起来。A 看到自己是 192.168.1.10，B 看到自己是 10.0.0.8，这些地址对互联网彼此不可达。

WebRTC 的目标是尽量让两端直接传媒体，降低延迟和服务器带宽成本。但为了在 NAT、企业防火墙、移动网络下尽可能连通，它需要信令、STUN、TURN、ICE 这一整套机制。

A(192.168.1.10) --NAT--> Internet <--NAT-- B(10.0.0.8)
       本地地址不可直接被对方访问

二、信令负责交换协商信息

信令不是媒体通道，它只是让双方“见面”和交换参数。WebRTC 标准不规定信令协议，所以业务可以用 WebSocket、HTTP、SSE 或自研长连接。信令里常交换 SDP offer/answer、ICE candidates、房间信息和用户状态。

SDP 里包含编解码器、媒体方向、安全参数、候选地址等信息。一个简化流程是：

A createOffer
A --offer SDP--> 信令服务器 --> B
B createAnswer
B --answer SDP--> 信令服务器 --> A
A/B 继续交换 ICE candidates

信令服务器不一定转发音视频流。小型会议里，信令只负责协商，媒体可能直接 P2P；多人会议或录制场景可能还会引入 SFU/MCU。

三、STUN 用来发现公网映射地址

STUN 服务器的作用是告诉客户端：“你发到我这里的包，在公网看起来来自哪个 IP 和端口。”这个地址叫 server reflexive candidate，常缩写为 srflx。客户端把这个候选地址通过信令告诉对方，对方就可以尝试打这个公网映射地址。

Client 192.168.1.10:5000 -> NAT -> 203.0.113.8:62000 -> STUN
STUN 返回: 你看起来是 203.0.113.8:62000

STUN 不转发媒体，成本低。但如果 NAT 类型严格、企业防火墙限制 UDP、或映射只允许特定目标访问，STUN 得到的地址也可能无法让对端连通。

STUN 不是中继服务器，它只是帮客户端照镜子：看看自己在公网被映射成什么地址。

四、TURN 是连不通时的中继兜底

TURN 服务器会分配一个 relay address，双方都连到 TURN，由 TURN 转发媒体。它几乎能穿过更多网络限制，因为双方都只需要主动连一个公网服务器。但代价是服务器带宽非常高，音视频流量都要经过 TURN。

假设一对一视频通话码率 2 Mbps，如果走 P2P，服务器只承担信令；如果走 TURN，中继服务器至少要接收 2 Mbps 再发出 2 Mbps，单通话就约 4 Mbps 转发流量。1000 路同时走 TURN，就是约 4 Gbps 级别带宽。

A -> TURN -> B
B -> TURN -> A

所以 TURN 是成功率兜底，不是首选路径。工程上要监控 TURN 使用比例，比例突然升高往往说明网络策略、STUN 可用性或 ICE 配置出了问题。

五、ICE 负责候选收集和连通性检查

ICE 会收集多类候选地址：host 本机地址、srflx 通过 STUN 得到的公网映射地址、relay 通过 TURN 得到的中继地址。然后双方把候选地址互相交换，尝试不同候选对的连通性，最终选择优先级高且能通的路径。

候选类型	来源	特点
host	本机网卡地址	局域网内可能直连
srflx	STUN 返回	NAT 映射地址，成本低
relay	TURN 分配	成功率高，成本高

ICE 的价值是自动尝试多条路径。局域网同网段时可能选 host；普通 NAT 下可能选 srflx；严格网络下才选 relay。

六、媒体通道还要加密和拥塞控制

WebRTC 建连成功后，音视频通常走 SRTP，密钥协商依赖 DTLS。也就是说，即使媒体是 P2P，内容也不是裸奔明文。数据通道通常基于 SCTP over DTLS，用于低延迟传输任意数据。

实时媒体还要做拥塞控制。网络变差时，WebRTC 会根据丢包、RTT、抖动等反馈调整码率。例如 720p 视频原来 2 Mbps，丢包升高后可能降到 800 Kbps，优先保证通话不断，而不是坚持原画质导致卡死。

RTT 升高 / 丢包增加
        |
        v
降低码率、调整分辨率或帧率
        |
        v
维持实时性

七、WebRTC、WebSocket 和直播协议不要混淆

WebSocket 是双向消息通道，不自带音视频采集、编解码、抖动缓冲、回声消除、拥塞控制和 NAT 穿透。WebRTC 是完整实时通信栈，面向音视频和低延迟数据。直播协议如 HLS 更适合大规模分发，但延迟通常更高。

场景	更合适技术
双人视频通话	WebRTC
在线客服文字聊天	WebSocket
大规模赛事直播	HLS/低延迟直播方案
浏览器实时共享数据	WebRTC DataChannel 或 WebSocket

面试回答时强调：WebRTC 不只是协议名，而是一套实时通信能力集合。

八、常见误区与追问

误区：WebRTC 不需要服务器。 它通常需要信令服务器，也常需要 STUN/TURN，P2P 只是媒体路径的理想情况。
误区：STUN 会转发音视频。 STUN 只发现公网映射地址，TURN 才负责中继流量。
误区：TURN 越多越好。 TURN 提高成功率但带宽成本高，应作为兜底路径并监控使用比例。
误区：信令协议就是 WebRTC 标准的一部分。 WebRTC 不规定信令实现，业务可以选择 WebSocket、HTTP 等。
追问：ICE candidate 有哪些类型？ 常见有 host、srflx 和 relay，分别来自本机、STUN 和 TURN。
追问：为什么企业网络下常常只能走 TURN？ 防火墙可能限制 UDP 或 NAT 类型严格，P2P 连通性检查失败后只能中继。
追问：WebRTC 媒体是否加密？ 是，通常通过 DTLS 协商密钥并使用 SRTP 保护媒体。

九、加强记忆

WebRTC 建连按“信令交换 SDP，STUN 找公网映射，TURN 中继兜底，ICE 选择可通路径”来记。信令传协商信息，不一定传媒体；STUN 是照镜子，TURN 是转发站，ICE 是路径选择器。真正的媒体通道还包含 DTLS/SRTP 加密、拥塞控制和实时音视频处理能力，这些是它区别于 WebSocket 的关键。

简化版

详细版