寻常的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 工作流程：
-
收集候选地址
双方收集本地网络地址（私有 IP、公网 IP），并通过 STUN 服务器获取公网候选地址。 -
交换候选地址
通过信令服务器交换各自的候选地址列表。 -
连接测试
双方尝试使用这些候选地址进行连接测试，找出最优路径（如直接 P2P 连接或通过 TURN 中继）。 -
建立通信
一旦找到可用地址，即可开始实时音视频通话。
🔧 相关技术：
- STUN：用于发现公网 IP 和端口
- TURN：当无法穿透 NAT 时，作为中继服务器转发数据
重要事件监听
在实际开发中，需监听以下关键事件：
onicecandidate：当 ICE 收集到新的候选地址时触发，用于发送给对方onaddstream：当对方添加了媒体流时触发，用于播放对方的音视频
总体流程如下
总结
| 问题 | 解决方案 | 关键技术 |
|---|---|---|
| 如何发现对方？ | 信令服务器 | WebSocket、自定义信令协议 |
| 如何沟通编解码？ | 媒体协商 | SDP、createOffer / createAnswer |
| 如何联系对方？ | 网络协商 | ICE、STUN、TURN |