ShowDocs
搜索文章Ctrl K

外观

← 返回实时通信与 WebRTC列表
信令与传输机制

WebRTC信令、连接与排错 · 信令、SDP与ICE连接建立至ICE排错、多人拓扑与带宽 ​

返回分篇目录

WebRTC信令、连接与排错 ​

信令、SDP与ICE连接建立 ​

前置：理解 Promise、浏览器事件、信令与数据通道的区别；准备支持 RTCPeerConnection 的浏览器，本例不配置 STUN/TURN。教学范围为W3C WebRTC Recommendation；浏览器API；RFC8835传输。核对日期2026-10-17。示例未执行，本轮没有安装依赖、生成协议代码、启动服务或浏览器预览。完整文件与输入见手工信令单页示例与会话顺序练习；推演结论只适用于写明的模型。

信令与媒体为何分开 ​

信令与媒体为何分开：应用负责把会话描述和候选传给对端，WebRTC协商并建立实际传输，规范不规定必须使用WebSocket信令。信令连接成功不证明媒体已通；排查时分别观察信令状态、ICE连接和媒体轨道。

SDP描述什么能力 ​

SDP描述什么能力包括媒体种类、编解码、方向以及建立安全传输所需信息。它是会话描述，不是音视频内容本身。offer/answer设置到正确端的local与remote后才完成相应状态转移，不能把同一描述随意同时当本地和远端。

ICE与STUN及TURN ​

ICE与STUN及TURN分工不同：ICE选择可连通候选对，STUN帮助发现地址和检查连通性，TURN提供中继路径。STUN不是通用媒体转发器，使用中继也不是必然失败；策略、NAT与防火墙共同影响最终路径。

信令通路与实际数据通路 ​

下面是逻辑关系：应用信令传递描述与候选，ICE检查并选择可用候选对；实际数据可能直达，也可能经TURN中继。STUN返回地址信息并参与检查，不是媒体存储或通用转发服务。图中的两条数据路径是可能选项，不表示同一会话必须同时使用两条。

查看图表代码

来源与适用边界 ​

协商状态、DataChannel与媒体安全 ​

协商状态与碰撞 ​

协商状态与碰撞发生在双方同时创建offer时，生产应用需采用明确的含回滚的冲突处理或完美协商模式。稳定状态不表示ICE一定连接成功；本例固定A发起、B应答并等待完整候选收集，故意限制角色以便先理解状态顺序。

DataChannel可靠性选择 ​

DataChannel可靠性选择需按消息时效决定有序交付与重传参数。聊天记录与实时位置可能选择不同策略；消息发送受bufferedAmount等应用缓冲约束，不能把可靠通道当无限队列。连接关闭后的send会失败，需明确重连和业务去重。

媒体权限与传输安全 ​

媒体权限与传输安全分别约束采集和传输。getUserMedia通常需要安全上下文与用户授权，DataChannel不需要采集摄像头。传输加密不替代信令身份与房间授权，否则把会话信息交给错误对端仍可能连接到错误对象。

固定发起方下的协商顺序 ​

本课固定A发起，B应答，避免同时offer的碰撞。A设置本地offer后等待远端answer，B设置远端offer后生成并设置本地answer；回到stable只说明信令状态稳定，DataChannel仍需等open。状态含义依据W3C WebRTC规范，图不包含回滚和重新协商分支。

查看图表代码

来源与适用边界 ​

ICE排错、多人拓扑与带宽 ​

ICE失败如何定位 ​

ICE失败如何定位先检查是否有候选对，再区分连通检查失败与通道未协商。公网受限网络可能需要TURN中继，不能靠把STUN端口当转发端口修复；日志应避免泄露长期凭证和完整私网地址，调试材料按必要范围保存。

多人拓扑与带宽 ​

多人拓扑与带宽在全网状下每人向其余参与者发送，连接数随人数平方增长。SFU转发选择的媒体流减轻上行却引入服务器成本、拥塞控制与隐私边界；MCU混流增加处理成本。不能从两人DataChannel示例直接宣称多人音视频生产可用。

WebRTC规范与历史配置 ​

WebRTC规范与历史配置以W3C接口与RFC8835传输为依据，中文MDN用于API术语对照。旧Coturn部署文保留TURN中继的历史网络和配置案例，不复制其真实地址、证书路径或长期凭证为新默认值；本课没有安装中继或访问媒体设备。

连接失败按阶段排查 ​

先判断描述是否按会话和角色正确交换，再检查候选是否完整送达、候选对能否连通，最后检查DataChannel是否协商并打开。出现relay候选只说明获得中继候选，仍需验证选中路径与实际收发。多人全网状中，n人共有n乘以n减一再除以2条两两连接，每人向其他n减一人发送，不能沿用两人测试的带宽结论。

查看图表代码

来源与适用边界 ​

继续阅读