WebRTC协议底层与架构演进：从实时通讯到低延迟直播的选型指南

我在做实时音视频方案选型的那几年，几乎每年都会遇到同样的问题：产品经理拿着白板说“我们想要低延迟、要连麦、要直播、还要省钱”，然后技术团队就在 RTMP、HLS、WebSocket、自研 UDP 协议里反复横跳。直到后来把 WebRTC 的协议底层和架构演进完整梳理了一遍，才发现很多争论其实早就有答案。这篇不打算做那种列一堆官方文档式对比的“科普”，就从一个实际经历过选型、踩坑、迁移的从业者角度，把 WebRTC 为什么能在实时通讯里成为“事实标准”这件事讲透，顺便把大家最近都在搜的 Freeswitch WebRTC 配置、WebRTC demo、WHIP 是什么、斗鱼 WebRTC 是怎么回事，一并串起来讲。如果你正在为会议、直播连麦、远程协作或者 IoT 音视频挑技术栈，这篇文章应该能帮你省掉不少调研时间。

1. 为什么“实时通讯”这件事，最后都会绕回 WebRTC

1.1 实时通讯要解决的本质问题，不是“传输”而是“实时”

很多人一提到 WebRTC，第一反应是“浏览器里可以互相视频”。这个理解不能说错，但太浅了。实时通讯真正要解决的是三件事：低延迟交互、复杂网络穿透、端到端安全。这三件事缺了任何一件，产品体验都会崩。

先说低延迟。电话也好、视频会议也好，人体对声音延迟的感知阈值大约是 150ms 以内，超过 400ms 就能明显感觉到“对话不在一个节奏上”。所以实时通讯的可接受延迟目标不是 3 秒也不是 1 秒，而是几百毫秒。你要知道，传统 HLS 直播延迟普遍在 5-10 秒，RTMP 虽然推流延迟低一些，但播放端经过厂商播放器自带缓冲后往往也有 2-5 秒。在这种量级下做双向交互，根本不可能。

再说网络穿透。互联网环境下绝大多数终端都在 NAT 后面，没有公网 IP。两个人要直连，必须做端口映射预测，打洞失败还要走服务器中转。这部分 WebRTC 有完整的协议栈解决，而自己做 UDP 协议的话，光 NAT 穿透就能拖垮一个团队。

最后说安全。WebRTC 强制 DTLS 握手和 SRTP 加密，也就是从设计上就默认“所有媒体流必须是加密的”，不需要开发者在业务层补丁式地加一个 TLS。这个特性在现实部署中极其重要，尤其是医疗、金融、远程办公场景，安全合规是硬指标，不是可选项。

1.2 对比 HTTP 轮询、WebSocket、RTMP、HLS：谁在“实时”上掉队了

我经常用一张表给团队讲“为什么不能拿 WebSocket 直接做音视频”。很多人以为 WebSocket 是全双工，理应是实时通讯的首选，但实际上 WebSocket 基于 TCP，而 TCP 在传输音视频时有天然的缺陷：队头阻塞。

简单类比一下，TCP 就像一列火车，车厢必须按顺序到达。如果中间某一节车厢丢了，后面所有车厢都得等在隧道里，直到丢失的车厢被重传过来。对于网页、JSON 数据来说，这种可靠性是好事；但对于音视频帧来说，你其实并不想为了等一个丢失的音频包而让后面的视频帧全部卡住。网络一抖动，WebSocket 视频就会变得断断续续，延迟还逐级放大。

这张表看起来很直接，但选型的时候很多人还是会被“我们只需要推流到服务器再分发”的思路带偏。RTMP 的问题在于它是上行推流协议，设计时根本没有考虑观众端要“说话”的场景，你没法用 RTMP 做双向连麦。HLS 则是为了大并发观看牺牲了延迟。WebSocket 没解决媒体传输的可靠性策略，而且没有内置任何音视频编解码器的适配层。

所以你会发现一个有趣的现象：做实时通讯的厂商，不管是声网、Twilio 还是腾讯云，底层媒体传输都是 WebRTC 内核，只是外面包了一层自己的信令和调度。因为大家心里都清楚，从协议底层看，WebRTC 是当前唯一一个把“传输、穿透、加密、丢包恢复、拥塞控制”全部都标准化掉的方案。

1.3 “唯一选择”不是吹捧，而是一种“标准拥挤效应”

说 WebRTC 是唯一选择，并不是因为它没有缺点。事实上它协议复杂度高、排查问题难度大、服务端成本也不低，这些都真实存在。但关键在于，浏览器、操作系统、硬件设备、CDN 厂商已经全部围绕 WebRTC 做兼容了，你再自研一套媒体协议，哪怕技术上更先进，也很难让 Chrome、Safari、Edge 这类体积庞大的终端默认支持你。

这就是标准的“生态效应”：当一个技术方案已经成为所有终端和云厂商的默认底座，它的替代成本就高到了不可想象。从产品角度说，选择 WebRTC 不是在选一个“最优技术”，而是在选一个“不会错的技术底座”。这一层想通了，后续很多架构争论就都可以停止了。

2. 协议底层拆解：WebRTC 是怎么在不可靠的 UDP 上做到“像电话一样稳”的

2.1 为什么是 UDP？TCP 的“可靠”反而成了实时媒体的大敌

很多刚接触 WebRTC 的工程师第一反应是：“UDP 不丢包吗？用 UDP 不是很不靠谱吗？”这个直觉没有错，但你要先理解音视频流的一个特点：可以容忍少量丢包，但不能容忍乱序等待。

当一个视频帧在网络上丢了，你是要等它重传回来再播放，还是会直接跳过这一帧、继续播后面的帧？真实的用户体验告诉你，轻微卡一下、花一下屏，都能接受，但要是为了等一个旧包导致整条链路延迟拉高，用户立刻就会觉得“卡得没法用”。TCP 的“可靠”是通过丢弃后续数据块来等待丢失数据重传，这在文件传输里是优点，在实时音视频里就是灾难。

WebRTC 的选择是：用 UDP 承载 RTP 包，把可靠性交给上层智能处理。媒体引擎会根据自己的丢包率实时调整发送策略，比如重传关键帧、增加冗余包、降低码率、切换更稳定的编码参数。这些策略都建立在“UDP 快但不可靠”这个前提上，因为只有快速到达的数据才有机会在用户可感知的延迟窗口内被播放出来。

2.2 ICE、STUN、TURN：穿透 NAT 的“打洞”艺术与兜底方案

这部分是 WebRTC 工程实践里最常出问题的环节，也是“网络穿透”能力的核心。我用大白话解释一下。

STUN 的作用，是让设备问服务器“我的公网地址是什么”。NAT 会改写内网设备的 IP 和端口，设备自己不知道出口地址，所以要借助一个公网端点来“照镜子”。打洞就是两个设备互换了各自在 NAT 上映射出来的公网地址后，尝试直接向对方发包。能通，就叫“打洞成功”，媒体流就可以走点对点。

但现实网络里还有对称型 NAT，这种 NAT 映射目标地址不同就会分配不同端口，单纯 STUN 打洞基本失败。这时候就要用 TURN 服务器做中继，由 TURN 给双方各自的连接腾出一对公网端口，媒体流全部经过 TURN 转发。代价是带宽成本和额外的 30-80ms 延迟。

我建议自建实时通讯平台时，把 TURN 当成必选项，而不是可选项。见过太多团队只搭了 STUN，然后测试时发现同一 WiFi 下没问题，一到跨运营商网络就“黑屏”“卡在连接中”。在 chrome://webrtc-internals 里看 ICE candidate，你会发现大量连接只有 host 类型的候选，没有 srflx 或 relay，那说明 STUN 没生效或者 TURN 没有配置。排查这个方向时，优先级排在编解码前面。

2.3 SDP 协商与 DTLS-SRTP：WebRTC 为什么默认就是加密的

WebRTC 的呼叫流程里，两个端需要交换 SDP（Session Description Protocol），里面描述了各自支持的音视频编解码器、网络候选、加密指纹、带宽限制等信息。这套机制叫 offer/answer。信令服务器本身不传输媒体数据，它只负责把 SDP 和 ICE 候选转发给对端。

很多人在这里会问：“SDP 协商我看不太懂，浏览器不是自动生成吗？为什么还要关心？”因为你一旦要对接 Freeswitch、SRS、Janus、mediasoup 这类服务端，SDP 里某些字段就直接决定呼叫成不成功。比如 m-line 的顺序，有的服务端只取第一个 audio m-line，如果你的浏览器没有输出 opus，而是先列了 H.264，就可能协商失败。再比如 a=setup 字段，主动端是 actpass 还是主动方，主动/被动方配置反了，DTLS 握手就会卡住。

WebRTC 的安全模型是“先 DTLS 握手，再通过 DTLS 协商 SRTP 密钥，最终媒体流用 SRTP 加密”。这带来一个实际后果：WebRTC 不接受“裸 RTP”或“不加密的媒体流”。如果你自己写服务端做转发，必须实现 DTLS-SRTP，否则 WebRTC 客户端会直接拒绝连接。这让开发量上了一个台阶，但也意味着你用 WebRTC 做出来的产品，默认就满足了很多合规需求。

2.4 GCC 拥塞控制、NetEQ 与 FEC：WebRTC 弱网稳的底层逻辑

WebRTC 的弱网表现好，不只是一个“用 UDP”的功劳，关键在于拥塞控制算法 GCC（Google Congestion Control）。GCC 同时监控丢包率和网络延迟变化，来判断当前网络是“带宽不足”还是“延迟增大”。丢包多就降低发送码率，延迟增大说明缓冲排队了也要降低码率，传输稳定后再试探性地增加码率。

另一个核心组件叫 NetEQ，它在接收端做抖动缓冲和音频平滑。网络抖动会导致包到达时间忽快忽慢，NetEQ 会先做短期缓冲，再把音频以稳定的节奏送给扬声器，同时尽量压低延迟。这种“自适应缓冲”策略很难在自研协议里快速复制，WebRTC 已经帮你调校得非常成熟了。

再加上前向纠错（FEC）和丢包重传（NACK）机制，WebRTC 可以在丢包率 10%-20% 的网络里仍然维持可用的音视频体验。相比之下，RTMP 在相同丢包率下会因为 TCP 重传导致延迟迅速拉长。所以在实际连麦、面试、远程手术这类场景下，WebRTC 的抗弱网能力就是最大的护城河。

3. 架构演进：从点对点通话到万人直播，SFU 与 WHIP 重构了实时流媒体

3.1 P2P 的尽头是 Mesh，Mesh 的尽头是 SFU

WebRTC 最早的产品原型是浏览器间的点对点视频通话。两个人互相连，媒体流直连，服务器只负责信令，这种模式最省钱。但一旦通话人数增多，问题就来了：3 个人开会需要 3 条连接链路，4 个人是 6 条，10 个人是 45 条。每一个客户端都要同时上传自己的视频流给所有其他人，这个上行带宽消耗是任何家庭宽带都承受不起的。

于是行业里出现了三种典型的服务端架构：Mesh（网状）、MCU（多点控制单元）、SFU（选择性转发单元）。Mesh 让每个终端互连，服务器负担最小但终端带宽爆炸；MCU 在服务器上把所有视频流混合成一路再发给观众，终端负担最小但服务器 CPU 开销巨大，因为需要实时转码合流；SFU 则取了一个聪明的中间值：服务器转发所有流，但不做解码、转码或合流，只负责把每个发布者的流原样转给每个订阅者。

SFU 之所以后来成为主流，是因为它把昂贵的转码开销从服务器剥离，只保留带宽成本。现在几乎所有视频会议服务，包括 Google Meet、Zoom、腾讯会议，底层都是 SFU 架构。自研时如果不想从零造轮子，可以直接基于 mediasoup 或 LiveKit 这类开源 SFU 起步，它们已经帮你把 RTP 转发、带宽控制、丢包重传都实现好了。

3.2 斗鱼 WebRTC 与低延迟直播：直播平台为什么要“倒向” WebRTC

传统直播平台喜欢用 RTMP 推流、HLS 分发，但体验瓶颈很明显：弹幕和直播画面总是对不上，主播说“欢迎大家”，观众在 5 秒后才听到。互动玩法（连麦 PK、实时问答、线上 K 歌）更没法做，因为 WebSocket 能解决弹幕，但解决不了音视频的延迟。

斗鱼 WebRTC 这个热搜背后，本质上就是直播行业在探索“低延迟直播”这个方向。把采集端的音视频直接用 WebRTC 推流到服务器，再用 WebRTC 拉流给播放器，延迟能压到 1 秒甚至更低，同时还能享受 WebRTC 的弱网抗性。这个方案看起来和在浏览器里打开一个会议一样，但规模完全不同。直播是“一对万”的场景，服务端需要把主播的流复制给成千上万个观众，这就不能只靠单个 SFU，还要在 CDN 边缘节点上做级联分发。

所以在架构上，直播平台会把 WebRTC 接入到现有的流媒体传输网里，而不是重新搭建一套完整的音视频网络。边缘节点接收 WebRTC 流后，一部分观众可以直接从边缘节点拉流，同时边缘节点还能通过标准协议把流推到上游源站，源站再分发到更多节点。这种“WebRTC 接入 + 传统 CDN 分发”的混合模式，是现在低延迟直播比较成熟的落地方式。

3.3 WHIP 与 WHEP：把 WebRTC “标准化”成 HTTP 推拉流

“webrtc whip 是啥意思”是最近很多人搜的问题。WHIP 的全称是 WebRTC-HTTP Ingestion Protocol，它做的事情非常简单：把“建立 WebRTC 推流会话”这个流程，用普通的 HTTP POST 请求标准化掉。

在传统直播里，你用 OBS 推流到 RTMP 地址，只需要配置一个 rtmp:// 地址就行。但在 WebRTC 世界里，以前要推流得先部署一个信令服务，由推流端和接收端协商 SDP，非常繁琐。WHIP 的出现让 OBS、ffmpeg、摄像头这些推流端可以像 RTMP 一样，通过一个 HTTP 地址就能完成 WebRTC 推流：推流端发送一个 POST 请求，把 offer SDP 放在 body 里，服务器返回 201 Created 和 answer SDP，WebRTC 连接就建立起来了。整个过程只有一次 HTTP 往返。

WHEP 则是对称的拉流协议，全称 WebRTC-HTTP Egress Protocol。播放器用 GET 请求拿到 answer SDP 后，就可以开始接收 WebRTC 流了。这套协议的意义在于，它把 WebRTC 从“浏览器的私有语音通话协议”变成了“标准媒体推拉流协议”，SRS、MediaMTX 这些流媒体服务器都开始支持 WHIP/WHEP，意味着以后从 OBS 推流到云端再分发给 WebRTC 播放器，可以全链路用标准 HTTP 对接，不用再自己写一套私有信令。这是实时流媒体架构演进里非常关键的一步，它让 WebRTC 从“会议场景”走向“广播与直播场景”。

3.4 未来架构的基石：数据通道、AI 实时处理与端侧算力

WebRTC 的价值不只是音视频。它还有一个经常被忽略的 DataChannel，走 SCTP over DTLS，可以在同一套连接上传二进制数据。这个通道很适合做游戏指令同步、文档协作、点对点文件传输。因为它与媒体流共用同一套连接和加密通道，所以 RTT 低、穿透能力强，比 WebSocket 在复杂网络下更可靠。

随着 AI 实时处理兴起，WebRTC 架构里开始流行“端侧跑 AI + 服务端跑重模型”的分层推理。比如摄像头端用 WebRTC 把画面传给服务器，服务器跑实时姿态估计或手势识别，再把识别结果通过 DataChannel 回落给端侧。这种分工让 AI 能力复用一套传输底座，不需要为每一种 AI 应用重写网络协议。从架构演进的角度看，WebRTC 已经从“音视频通话协议”演化为“实时交互基础设施”，这也是我判断它未来地位只会增强、不会削弱的原因。

4. 实操：从零搭一个 WebRTC demo，把关键坑踩一遍

4.1 环境准备：localhost 能跑，但你要知道浏览器安全上下文限制

WebRTC 的 getUserMedia 和 RTCPeerConnection 在普通 HTTP 非 localhost 环境下是跑不通的，浏览器会报 getUserMedia() is not allowed 类似的错误，原因是摄像头和麦克风属于敏感权限，浏览器强制要求安全上下文。localhost 默认被视为安全上下文，所以开发时直接用 http://localhost 就能跑。

如果你需要在手机或者局域网里联调，有两条路：一条是给电脑配上自签名 HTTPS 证书，在手机上信任证书；另一条是直接用内网穿透工具打一个 HTTPS 隧道。我试过自签名证书在桌面 Chrome 上附加忽略校验参数后能用，但手机浏览器信任自签名证书的流程比较繁琐，所以团队开发期我更喜欢直接起一个带 HTTPS 的本地服务，用 mkcert 生成证书，让局域网设备统一安装根证书，这样最省心。

4.2 最小 WebRTC 通话 Demo：浏览器原生 API + Node.js 信令

下面这个 demo 是“一个页面里两个 video 标签互相显示本地和远端流”的最小模型。信令服务器我选用 Node.js + ws 库写一个最基本的转发服务，只做 SDP 和 ICE 候选转发，不做任何业务逻辑。

先写信令服务器 server.js：

javascript复制const WebSocket = require('ws');

const wss = new WebSocket.Server({ port: 8080 });

let clients = [];

wss.on('connection', (ws) => {
  clients.push(ws);
  ws.on('message', (message) => {
    // 把消息原样转发给其他客户端
    clients.forEach(client => {
      if (client !== ws && client.readyState === WebSocket.OPEN) {
        client.send(message.toString());
      }
    });
  });

  ws.on('close', () => {
    clients = clients.filter(client => client !== ws);
  });
});

console.log('信令服务器已启动: ws://localhost:8080');

再写页面 index.html，这里的关键是处理 ICE 候选的交换。ICE 候选不能直接塞进 offer SDP 里，必须在连接过程中通过信令单独转发：

javascript复制const ws = new WebSocket('ws://localhost:8080');
const pc = new RTCPeerConnection({
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' }
  ]
});

let isCaller = false;

// 本地画面采集
const localVideo = document.getElementById('localVideo');
navigator.mediaDevices.getUserMedia({ video: true, audio: true })
  .then(stream => {
    localVideo.srcObject = stream;
    stream.getTracks().forEach(track => pc.addTrack(track, stream));
  });

// 远端画面渲染
const remoteVideo = document.getElementById('remoteVideo');
pc.ontrack = (event) => {
  remoteVideo.srcObject = event.streams[0];
};

// 收集本地网络候选后，通过信令发送给对端
pc.onicecandidate = (event) => {
  if (event.candidate) {
    ws.send(JSON.stringify({ type: 'candidate', candidate: event.candidate }));
  }
};

// 信令处理：offer/answer/candidate
ws.onmessage = async (event) => {
  const data = JSON.parse(event.data);

  if (data.type === 'offer') {
    isCaller = false;
    await pc.setRemoteDescription(data.sdp);
    const answer = await pc.createAnswer();
    await pc.setLocalDescription(answer);
    ws.send(JSON.stringify({ type: 'answer', sdp: pc.localDescription }));
  } else if (data.type === 'answer') {
    await pc.setRemoteDescription(data.sdp);
  } else if (data.type === 'candidate') {
    await pc.addIceCandidate(data.candidate);
  }
};

// 页面上的“呼叫”按钮：第一个用户点击后作为发起方
document.getElementById('callBtn').onclick = async () => {
  isCaller = true;
  const offer = await pc.createOffer();
  await pc.setLocalDescription(offer);
  ws.send(JSON.stringify({ type: 'offer', sdp: pc.localDescription }));
};

这个 demo 能跑通的核心前提是两个浏览器标签页都连到同一个 ws 信令服务器。如果你在同一个浏览器里开两个标签页，要注意摄像头可能只被一个标签页占用，此时可以把第二个标签页的 video: false，只做音频测试。另外在实际多人系统里，信令服务器必须做房间管理和一对一关联，否则消息会广播给所有客户端。

4.3 Freeswitch 集成 WebRTC：从浏览器呼叫 SIP 终端的配置要点

很多人搜“freeswitch webrtc 配置”，是想把 WebRTC 浏览器端接入到现有的 FreeSWITCH 呼叫中心里，用浏览器替代软电话。这个方向和纯 WebRTC 点对点不同，浏览器需要以 SIP 协议对接 FreeSWITCH，常见方案是 SIP.js 或 JsSIP，然后让 FreeSWITCH 提供 WSS 信令接入。

配置上有几个重点。第一，确保 FreeSWITCH 模块加载了 mod_sofia 和 mod_wss，并监听 WSS 端口 7443。第二，在 vars.xml 里设置外部 IP，external_rtp_ip 要改成你的公网 IP 或特定网卡地址，否则媒体流会用一个内网地址协商出去，导致远端媒体不可达。第三，防火墙必须放行 UDP 媒体端口段，通常 FreeSWITCH 默认 RTP 端口范围是 16384-32768，如果这个段被防火墙挡住，呼叫虽能建立但双方听不到声音。第四，SIP 注册时最好使用 wss:// 地址，不用纯 ws://，因为浏览器安全策略对非安全 WebSocket 的限制很严格。

我实际排查过的案例里，最常见的问题是证书。自签名证书在浏览器里调用 getUserMedia 时可能通过了，但 SIP.js 的 WebSocket 连接会因为证书不可信而失败。解决方案是申请一张正式的 HTTPS 证书，或者内部 CA 签发然后统一安装到企业电脑信任列表。其次常见的是 488 错误，这通常表示媒体协商不匹配，需要检查编解码器列表，WebRTC 偏好 opus 音频和 VP8 视频，但 FreeSWITCH 可能默认只启用了 PCMU/PCMA，需要在拨号方案或 Sofia profile 中显式启用 opus。

4.4 如果不想从零写 SFU：几个能直接上手的开源引擎

自研一个 WebRTC 服务端转发模块的复杂度远比大多数人想象的高，光 RTP 包的时间戳处理和 RTCP 反馈就够写很久。所以在这个领域，我的习惯是“能站到巨人肩膀上就不重复造轮子”。

• mediasoup：基于 Node.js 和 C++ 的 SFU 引擎，API 设计很底层，灵活度高，适合团队有能力自己做音视频调度和业务封装的情况。
• LiveKit：Go 写的开源 SFU，自带服务端、客户端 SDK 和多功能面板，对前端友好，适合快速上线会议产品。
• Janus：C 语言写的通用 WebRTC 网关，插件机制成熟，适合对接 SIP、录制、媒体控制等复杂场景。
• SRS：国产流媒体服务器，近期大力支持 WHIP/WHEP，如果你想做低延迟直播分发而不是会议，它的上手成本最低。

选型的核心判断标准，是“你的产品瓶颈在并发规模还是业务复杂度”。并发规模大而业务简单，优先看 SRS 和 LiveKit；业务逻辑复杂，比如要对接传统呼叫中心、需要深度定制媒体流，就考虑 Janus 或 mediasoup。

5. 常见问题与排查技巧实录

5.1 高频问题速查表：黑屏、卡顿、延迟、音频全在这

这里整理一份我在实际项目中遇到的典型问题表，基本覆盖了 WebRTC 上线后绝大多数工单场景。

5.2 用 chrome://webrtc-internals 定位问题才是专业做法

遇到 WebRTC 问题，第一反应不应该看业务日志，而是打开 chrome://webrtc-internals。这个页面会记录每次连接的完整事件，包括 SDP 交换内容、ICE 候选状态、流统计、丢包率、往返延迟、帧率和码率。

排查顺序我一般是这样：先看 ICE Connection State 是不是 connected，不是的话直接定位网络穿透和 TURN 部分。再看 inbound-rtp 里的 packetsLost 和 framesDecoded，如果 packetsLost 高而 framesDecoded 低，说明网络丢包严重或者上行拥塞。最后看 outbound-rtp 里的 encodeTimeUsage 和 bitrate，如果编码时间很长，那是终端 CPU 性能导致编码慢，不是网络问题。用这套顺序基本能区分“客户端问题、服务端问题、网络问题”三个大方向。

5.3 几个容易忽略的工程细节：候选排序、码率上限和编解码选择

先讲候选排序。WebRTC 连接会同时尝试多个 ICE 候选，默认会根据优先级排序。但在实际部署中，如果主机在同一内网，我们会通过 iceCandidatePoolSize 或自定义 ICE 服务器配置来优化候选。更务实的做法是保证 TURN 服务器永远可用，因为公网场景下一旦打洞失败，TURN 就是唯一出路，不要因为费用问题把它关掉。

码率上限这件事经常被忽略。WebRTC 默认会自适应调节码率，但在某些场景（比如视频录制、需要固定清晰度直播），我们希望码率不要超过某个阈值。可以通过修改 SDP 中的 b=AS: 值，或者调用 RTCRtpSender 的 setParameters 设置 maxBitrate。不然你会发现同一个会议里有人用 4K 摄像头，直接把上行带宽打满，其他人全部降画质。

编解码选择也很重要。Chrome、Firefox 对 VP8 支持最好，Safari 对 H.264 更友好，而硬件编解码器的兼容性决定了相同设备下的发热和画质差异。跨平台产品我建议服务端统一协商为 H.264，因为大多数移动端芯片都有 H.264 硬编硬解，功耗低且兼容性最好。但如果服务端要做 SVC 分层、需要多分辨率适配，VP9 的优势又更明显一些。这个取舍要看你的目标用户是什么终端。

6. 写在最后：这套方案，后续还能怎么用

坦白讲，WebRTC 不是一个完美的技术，它的学习曲线陡峭、调试工具复杂、服务端成本也不能忽视。但如果你要从零搭建一套实时通讯体系，它依然是性价比最高、生态最完善的选择。我在实际项目里从 RTMP 迁移到 WebRTC 之后，最大的感受是“以前为了低延迟设计的一套私有缓冲和重传逻辑，现在都不需要维护了”，媒体引擎、拥塞控制、加密、穿透方案全都有成熟实现，团队可以集中精力做产品业务而不是音视频底层。

最后再分享一个小技巧：如果你在考虑产品未来要做实时 AI 交互，不妨现在就把 WebRTC 的数据通道（DataChannel）接入到你的基础架构里，因为它和媒体流是一体的，后面不管你加实时字幕、虚拟形象驱动，还是服务端智能分析，都能在同一套连接内完成，省掉很多跨协议转发的硬编码工作。这也是我在 WebRTC 上持续投入的原因——它不只是解决今天的问题，更是给下一阶段的实时交互留好了接口。