WebRTC实时通信

导读摘要：WebRTC 让浏览器之间不装插件、不经中转，就能互传音视频与任意数据，且全程强制加密。本册以「一次通话要闯过的关卡」为主线，从媒体采集、信令协商、NAT 穿越，一路讲到加密传输、抗弱网与生产化部署，带工程师把实时通信真正做上线。

某天深夜，公司值班群弹出一条求助：海外客户打开网页会议，摄像头图标亮了，双方却互相看不见；换到另一间办公室，画面又时断时续。前端同事盯着控制台日志无从下手——页面没有任何报错，媒体却像消失在网络的迷宫里。这类问题几乎每天都在全球的实时通信团队上演，而它们的答案，全部藏在 WebRTC 这套技术栈的地基里。

WebRTC（Web Real-Time Communication）是一组让网页获得实时通信能力的标准与接口：采集麦克风和摄像头、描述自己支持哪些编解码格式、穿越层层 NAT 找到对方、再以加密通道互传媒体和数据。它的特殊之处在于，浏览器厂商把这些原本属于电信设备商的核心能力直接内建进了内核——开发者只需要几十行 JavaScript，就能搭出一场点对点视频通话，而且媒体数据不必经过自己的服务器中转，密钥也不出设备。

这套能力带来的自由，也带来了复杂。点对点意味着没有中心节点替你兜底：信令要自己选、服务器要自己部署、失败要自己诊断。市面上大量教程停在「调通一个 demo」，而真实项目里真正耗费工期的，恰恰是 demo 之后的那段路——为什么双方都收集到了候选地址却连不通？为什么 Wi-Fi 下清晰流畅、切到蜂窝网立刻花屏？为什么两百人同时在线的房间把上行带宽挤爆？本册就是为了这些问题而写。

全册主线：一次通话的四道关卡

本册把一次 WebRTC 通话从发起到稳定运行的全过程，拆解为四道必须闯过的关卡，再用一章收尾于生产化战场：

第一道关·采集关（第 2 章）。通话的前提是拿到合规的媒体流：约束参数怎么写、权限被拒怎么降级、屏幕共享怎么采集、设备热插拔怎么接住。这是整条链路的源头，源头不稳，后面全白搭。

第二道关·协商关（第 3 章）。两端必须先谈拢：用什么编解码器、什么分辨率、向谁发送。这场谈判通过信令服务器交换 SDP 文本完成。这一章讲清 offer-answer 模型的时机与陷阱，并带你从零写一个可用的信令服务。

第三道关·接线关（第 4 章）。谈拢了还不一定能碰面：两端多半都躲在 NAT 后面，彼此的地址互相不可见。ICE 框架收集候选地址、逐对试探、必要时借道 TURN 中继。这是 WebRTC 最容易出故障、也最少被讲透的一环，本章给出完整的部署与诊断方案。

第四道关·开讲关（第 5、6 章）。DTLS 握手验明身份、导出密钥，SRTP 开始加密传输；之后还要面对真实网络的丢包、抖动与带宽波动——拥塞控制、丢包恢复、动态降级，这一关决定了用户嘴里「卡不卡」。

通关只是起点。第 1 章补齐整体认知框架，第 7 章把视野拉到生产环境：多方会议的拓扑选型、端到端代码走读、线上指标观测与工具链。

图：全册知识地图与学习依赖

你将在本册获得什么

读完本册，你应当能够独立完成一个生产可用的 1v1 通话功能，并对多人架构做出有依据的选型。具体到可检验的能力：写出带完整约束与错误处理的媒体采集代码；读懂一份 SDP 报文并定位协商失败的原因；部署 STUN 与 TURN 服务并用命令行验证连通性；从连接状态事件与统计指标中判断卡顿、花屏、延迟的根因；在 Mesh、SFU、MCU 之间为你的业务场景选出合适的多方拓扑。

学习本册需要具备的底子不多：熟悉 JavaScript 的异步写法（Promise 与事件回调），理解 HTTP 与 WebSocket 的大致分工，对 TCP、UDP 的区别有概念。不需要任何音视频编解码经验——需要的时候，正文会把必要的背景就地补上。

各章之间的依赖关系如上图：主线沿关卡顺序推进，跳章阅读是可行的，但第 4 章的诊断内容需要第 3 章的 SDP 语义作铺垫，第 7 章的实战则默认你已经走完四道关。每章开头都有一张本章知识地图与学习目标，每节开头会点明这一节承接哪里、通往哪里。如果时间有限，至少把第 3 章和第 4 章读透——工程实践里最常见的两类事故「协商失败」与「连不上」，都出在这两道关。

实时通信是一门「出了问题才知道它在」的技术：一切正常时用户毫无感知，出问题时却往往发生在最重要的场合。把每一道关的原理与排错手段都握在手里，你才有底气在深夜的求助消息弹出来时，从容地打开诊断面板。