WebRTC 和 WebSocket 有什么区别？实时音视频为什么需要 STUN 和 TURN？

知识点详解：两个人知道对方是谁，还需要知道怎样连上

WebSocket 能传字节，但媒体问题不止传字节

假设我们已有 WebSocket 服务，浏览器把数据发给服务端，服务端再发给另一个浏览器。

它可以承担消息通道，但如果用来传实时音视频，我们仍需要自己考虑编码、播放节奏、丢包与延迟处理，以及拥塞下怎样保持体验。

WebRTC 提供为实时媒体设计的能力；其 DataChannel 还可以传其他数据，并能配置不同交付特性。不能把所有 WebRTC 通信都说成“永远不可靠、永远无序”。

选择不是根据名字中有没有“实时”，而是根据需要的媒体与连接能力。

信令把协商信息送过去，不负责所有媒体传输

双方需要交换会话描述与 ICE 候选等信息。应用通常需要一个信令服务，把这些信息送到对方。

WebSocket 可以承担这个角色，也可以用其他通信方式。WebRTC 不替我们规定房间管理、用户登录或完整信令协议。官方建立连接说明

信令经过服务器，不代表建立后的所有媒体也走同一个 WebSocket。它们是两条职责不同的路径。

STUN 查地址，TURN 提供中继

浏览器通常在 NAT 或防火墙之后。自己的局域网地址，不一定能被另一方直接访问。

STUN 帮助确定外部观察到的映射地址，产生相关候选。ICE 再通过连通检查确定哪条路径可用。获得一个公网映射，不代表对方必然能接通。

TURN 则分配中继资源。当需要中继时，双方通过这条路径传数据。它要承担流量，因此有带宽与运行成本，不是一个只返回地址的轻量查询服务。协议说明

ICE 会综合候选和策略选择路径，不应该把所有实现简化成“STUN 失败后才临时考虑 TURN”。例如应用可以明确要求只用中继。

多人会议还会改变拓扑

两人通话可以评估直连；多人都互相传多路媒体，连接数量与上行负担会迅速增加。

SFU 等架构让客户端将媒体发送给服务端，再由服务端选择并转发给参与者。这仍然可以使用 WebRTC，不与浏览器协议冲突。

因此，方案里要画清信令路径、媒体路径和中继或转发节点。没有这张关系图，“我们使用 WebRTC”还不足以解释实际成本和故障点。

图中只示意了部分会话信息连接，绿色虚线表示需要时可用的 TURN 中继路径。实际项目仍要补齐各参与者的信令连接，不能把这张示意图直接当成完整部署图。

面试官继续追问

有 STUN，就不用部署 TURN 吗？

不能保证。需要根据网络覆盖和连通目标评估中继。只在自己家 Wi-Fi 测通，不代表移动网络和企业防火墙环境都能使用。

TURN 和 SFU 是同一个东西吗？

不是。TURN 提供连接层面的中继路径；SFU 面向会议媒体选择和转发。它们可能出现在同一系统，但职责不同。

WebSocket 断了，媒体一定立即断吗？

不一定，已经建立的媒体连接与信令连接不是同一条通道。但新协商、房间管理与恢复可能受影响，应按系统机制判断。

面试速记卡

• WebSocket：持续双向消息通道，可以承担信令。
• WebRTC：实时媒体与 DataChannel，另有连接协商机制。
• ICE：收集并检查候选，选择可用连接路径。
• STUN：帮助发现映射地址，不负责媒体中继。
• TURN：提供中继；多人会议还可能使用 SFU。