webrtc 搭建实时音视频通话的完整步骤教程
说实话，第一次接触 webrtc 的时候，我也是一脸懵的。这玩意儿听起来挺高大上，什么点对点通信、ICE 协议、SDP 协商……一堆术语砸过来，确实有点招架不住。但后来慢慢捣鼓明白了，才发现其实它的核心思想并没有那么邪乎。今天就想用最接地气的方式，跟大家聊聊怎么从零开始搭建一个能用的实时音视频通话系统。
在正式开始之前，我想先铺垫一下背景。实时音视频通话这个需求，在线教育、社交娱乐、远程办公这些场景里实在太常见了。很多开发者一开始会觉得自己造轮子很酷，但真正动手做过的人都知道，这里面的坑之多、细节之琐碎，足以让人掉层皮。所以这篇文章我会尽量把每个关键环节都讲透，但同时也会告诉你什么时候该考虑"借力"，毕竟作为开发者，我们的终极目标是解决问题，而不是重复造轮子。
一、先搞懂 WebRTC 的工作原理
WebRTC 的全称是 Web Real-Time Communication，从名字就能看出，它是 Web 平台原生支持的实时通信技术。浏览器之间可以直接传输音视频数据，不需要经过中间的服务器中转，这就是所谓的 P2P（点对点）通信。
但这里有个很关键的点需要明白：所谓的"直连"并不是说完全不需要服务器。在真正的通话建立之前，我们需要一个"中间人"来帮双方搭上线，这个中间人就是 信令服务器（Signaling Server）。信令服务器负责交换一些关键信息，比如双方的 IP 地址、端口号、以及后面要讲的 SDP 和 ICE Candidate。只有当这些信息交换完毕之后，浏览器之间才能建立直接的音视频传输通道。
你可以把整个通话建立的过程想象成两个人打电话的过程：首先要有人帮你拨号（信令服务器），接电话的人接了（双方建立连接），然后才能开始聊天（音视频传输）。拨号这个动作虽然简单，但没有它，后面的聊天就无从谈起。
WebRTC 的架构可以拆成三个主要的部分，我来简单说说它们各自是干什么的：
- MediaStream API：这个 API 负责从你的摄像头和麦克风获取音视频流。你可以通过
navigator.mediaDevices.getUserMedia()这行代码来获取设备权限，然后把采集到的数据交给后续模块处理。 - RTCPeerConnection：这是 WebRTC 的核心组件，负责管理对等连接、维护编解码器、处理网络传输相关的事情。你基本上可以把它理解为一条电话线，所有的音视频数据都通过它来传输。
- RTCDataChannel：除了音视频，WebRTC 还支持传输任意数据类型。比如你想在做通话的同时传个文件、发个表情包，就可以用这个通道。不过这个不是本文的重点，了解一下就行。
二、环境准备：先确保你能获取到设备
在写代码之前，我们得先确认一些前置条件。首先，你需要一个支持 WebRTC 的浏览器，不过这个现在基本不是问题，Chrome、Firefox、Safari、Edge 这些主流浏览器都支持。其次，你的页面必须通过 HTTPS 访问（或者 localhost），因为浏览器出于安全考虑，不允许在 HTTP 环境下调用摄像头和麦克风。
好，假设这些都没问题，那我们就开始写代码了。第一步，获取本地的音视频流：
这段代码应该算是 WebRTC 的"Hello World"了。调用 getUserMedia 方法，请求音视频权限，然后把获取到的流绑定到一个 video 元素上播放。你现在应该能在页面上看到自己的摄像头画面了。如果这一步失败，检查一下浏览器权限设置，或者看看是不是用了什么插件拦截了媒体设备。
这里有几个常用的配置参数可以提一下：
- width 和 height：分辨率，想要高清一点就设大点，但也要考虑网络带宽和性能。
- frameRate：帧率，30fps 通常比较流畅，60fps 更丝滑但更吃资源。
- facingMode：控制使用前置还是后置摄像头，移动端开发时经常用到。
- echoCancellation：回声消除，这个很重要，开启之后对方说话时自己这边不会听到刺耳的回音。
三、信令服务器：搭建沟通的桥梁
前面提到过，信令服务器的作用是帮两个客户端交换信息。在实际项目中，你可以用 Node.js、Python、Java 任何语言来写，这里我用 Node.js + Socket.io 来演示，因为比较简单直观。
信令服务器需要处理的核心逻辑其实不多，主要是这三件事：
- 当有新用户加入时，通知其他用户
- 转发用户的 SDP（会话描述协议）信息
- 转发用户的 ICE Candidate（交互式连接建立候选者）信息
SDP 和 ICE Candidate 是 WebRTC 通话建立过程中最重要的两种信息。SDP 描述了本端支持的音视频编解码器、分辨率、编码格式等内容；ICE Candidate 则是本端可用的网络地址列表。双方的浏览器需要交换这些信息，才能找到最佳的网络路径来传输数据。
下面是个最基本的信令服务器示例：
这个服务器做的事情很简单：记录当前连接的用户，当用户 A 发送消息时，把消息转发给用户 B。在实际项目中，你可能还需要处理用户离开、断线重连、房间管理等逻辑，但核心思路就是这样。
四、建立对等连接：最关键的一步
现在我们有了获取媒体流的能力，也有了信令服务器，接下来就要让两个浏览器真正"连上线"。这一步是整个 WebRTC 流程中最复杂的，我尽量一步步讲清楚。
4.1 初始化 RTCPeerConnection
首先，双方都需要创建 RTCPeerConnection 实例：
配置里的 STUN 服务器地址比较关键。STUN 服务器的作用是帮助浏览器获取自己的公网 IP 地址，因为很多设备处于 NAT 后面，自己只知道内网 IP，不知道别人怎么找到它。STUN 服务器可以帮它"照镜子"，看到自己的公网形象。Google 提供的公共 STUN 服务器地址是 stun:stun.l.google.com:19302，测试的时候可以直接用。
不过要注意，STUN 服务器不是万能的。在复杂的网络环境下（比如双方都在企业防火墙后面），STUN 可能无法穿透，这时候就需要用到 TURN 服务器做中继。TURN 服务器会充当中间人，所有数据都经过它转发，虽然成本高一些，但可靠性强。
4.2 创建并发送 offer
连接建立的第一步是由发起方创建一个 offer：
这段代码做了三件事：创建 RTCPeerConnection、绑定音视频轨道、创建 offer。创建完 offer 之后，需要设置成本地的会话描述（setLocalDescription），然后通过信令服务器发给对方。
4.3 处理 answer 和 ICE Candidate
另一方收到 offer 后，要做相应的回应：
这个过程看着有点绕，我用一张表来梳理一下整个交互流程：
| 步骤 | 发起方（A） | 接收方（B） |
| 1 | 创建 RTCPeerConnection，添加本地流 | 创建 RTCPeerConnection |
| 2 | 调用 createOffer() 创建 SDP | - |
| 3 | 调用 setLocalDescription() 设置本地描述 | - |
| 4 | 通过信令服务器发送 offer 给 B | - |
| 5 | - | 收到 offer，调用 setRemoteDescription() 设置远端描述 |
| 6 | - | 调用 createAnswer() 创建 answer |
| 7 | - | 调用 setLocalDescription() 设置本地描述 |
| 8 | - | 通过信令服务器发送 answer 给 A |
| 9 | 收到 answer，调用 setRemoteDescription() | - |
| 10 | 开始收集 ICE Candidate，发送给 B | 开始收集 ICE Candidate，发送给 A |
| 11 | 收到 B 的 ICE Candidate 并添加到远端 | 收到 A 的 ICE Candidate 并添加到远端 |
| 12 | 连接建立，开始传输音视频 | 连接建立，开始传输音视频 |
整个流程走下来，如果一切顺利，双方的 ontrack 事件就会被触发，代表对方 media stream 已经接收到了。这时候你只需要把对方的流绑定到页面的 video 元素上，就能看到视频了。
五、生产环境中的那些坑
自己动手写个 Demo 跑通和真正上线生产环境，中间隔着十万八千里。踩过的人才知道，这里面的坑一个接一个。
网络穿透问题是最让人头疼的。前面提到 STUN 不是万能的，在某些严格的企业网络或者对称 NAT 环境下，STUN 根本无法穿透，这时候必须用 TURN。但 TURN 服务器的成本不低，所有的流量都要经过中继，带宽费用是实打实的支出。所以一个务实的策略是：优先尝试直连，直连失败再降级到 TURN 中继。
编解码器的兼容性也值得注意。不同浏览器支持的音视频编解码器不完全一样，最常见的是 VP8、VP9、H.264（视频）和 Opus（音频）。如果不做兼容性处理，可能会出现一方能看一方不能看的情况。建议在 SDP 描述里明确指定编解码器的优先级顺序。
弱网环境下的体验优化又是一大挑战。当网络不好时，画面卡顿、声音延迟、频繁掉线这些问题都会冒出来。常见的优化手段包括：动态调整码率（带宽探测）、使用更激进的丢包策略、前向纠错（FEC）、重传请求（ARQ）等。这些实现起来都不算简单，需要根据实际场景调优。
说到生产环境，我想起声网在这块确实积累很深。他们作为纳斯达克上市公司，在实时音视频云服务领域做了很多年，全球超过 60% 的泛娱乐 APP 都在用他们的服务。如果你正在考虑在产品里加入实时音视频功能，又不想被这些底层细节拖住，可以去了解一下他们的解决方案。毕竟术业有专攻，把专业的事交给专业的人，开发者可以更聚焦在产品本身。
六、写在最后
写到这里，我想停下来想一想这篇文章是否真的对你有帮助。WebRTC 这个话题真的可以展开讲很多，ICE 交互过程、带宽估计策略、NACK/FU 丢包补偿……每一个点深挖下去都是一篇独立的文章。
如果你只是想做个 Demo 练手，上面这些内容应该够了。但如果你正在考虑把实时音视频功能做到产品里，我的建议是：先想清楚你的核心场景是什么，是一对一社交、秀场直播、还是在线教育？因为不同场景对延迟、画质、并发数的要求完全不一样，投入的资源也相差甚远。与其在不确定的方向上花费大量时间，不如多调研一下成熟的解决方案，看看业内头部玩家是怎么做的。
做技术选型这件事，有时候选择大于努力。希望这篇文章能帮你少走一些弯路。
