WebRTC实时音视频通信核心原理

寻常的WebSocket流程是这样的

如果都与服务器进行交流，会造成服务器压力大，通讯时间长，实时效果不好，那么怎么解决？
这就要用到我们接下来讲的WebRTC实时通讯
拿出笔记本，让我们开冲！！

概念

WebRTC(Web Real-Time Communication)是一项支持浏览器和移动应用在不借用中间媒介的条件下，建立通信双方的点对点连接，其核心原理在于去中心化，低延迟，端到端（P2P地实现音视频流的采集传输播放

实现两个客户端之间的实时音视频通信，尤其是在不同网络环境和设备下，需要解决以下三大核心问题：1.如何发现对方？ 2.不同的音视频编解码能力如何沟通？ 3.如何联系上通信双方？

1.如何发现对方？

为了实现通信双方的发现和管理，需要利用一个中间代理，也就是信令服务器（signaling server）

• 信令服务器也常被称为“房间服务器”
• 主要职责包括：
  • 通知谁加入了房间
  • 通知谁离开了房间
  • 告知第三方房间是否已满、是否可加入
• WebRTC 标准未规定具体信令协议，通常使用 WebSocket 搭建信令服务器
• 信令过程用于交换媒体信息、网络数据等元数据，这一过程称为 信令（signaling）

✅ 作用：建立通信双方的联系通道，协调会话流程

2. 不同的音视频编解码能力如何沟通？

由于不同浏览器对音视频的编解码支持存在差异，需通过 媒体协商（Media Negotiation） 来达成一致。

使用 SDP（Session Description Protocol）

• SDP 是一个专门用于描述媒体会话信息的协议
• 包含内容：支持的音视频格式、编码方式、带宽、端口等
• 双方通过交换 SDP 信息来确定共同支持的媒体格式，如同“找共同语言”

媒体协商关键方法

| 方法 | 说明
| createOffer | 创建一个 SDP Offer，发起方调用 |
| createAnswer | 创建一个 SDP Answer，接收方响应 Offer |
| setLocalDescription | 设置本地 SDP 描述（Offer 或 Answer） |
| setRemoteDescription | 设置远程 SDP 描述（收到对方的 Offer 或 Answer） |

🔄 协商流程：
发起方 → createOffer → 发送 Offer → 接收方 → createAnswer → 回传 Answer → 双方设置本地/远程描述

3. 如何联系上对方？

即 网络协商（Network Negotiation），目的是找到一条可用的通信链路。

使用 ICE（Interactive Connectivity Establishment）机制

ICE 是 WebRTC 中用于建立网络连接的核心技术，通过 STUN 和 TURN 服务器实现 NAT 穿越。

ICE 工作流程：

1. 收集候选地址
   双方收集本地网络地址（私有 IP、公网 IP），并通过 STUN 服务器获取公网候选地址。

2. 交换候选地址
   通过信令服务器交换各自的候选地址列表。

3. 连接测试
   双方尝试使用这些候选地址进行连接测试，找出最优路径（如直接 P2P 连接或通过 TURN 中继）。

4. 建立通信
   一旦找到可用地址，即可开始实时音视频通话。

🔧 相关技术：

• STUN：用于发现公网 IP 和端口
• TURN：当无法穿透 NAT 时，作为中继服务器转发数据

重要事件监听

在实际开发中，需监听以下关键事件：

• onicecandidate：当 ICE 收集到新的候选地址时触发，用于发送给对方
• onaddstream：当对方添加了媒体流时触发，用于播放对方的音视频

总体流程如下

总结

问题	解决方案	关键技术
如何发现对方？	信令服务器	WebSocket、自定义信令协议
如何沟通编解码？	媒体协商	SDP、createOffer / createAnswer
如何联系对方？	网络协商	ICE、STUN、TURN