1.1 从插件时代到原生通话
文档摘要
1.1 从插件时代到原生通话 本节摘要：本节是全册的起点，回答「WebRTC 从哪来、解决什么问题、凭什么值得学」。浏览器在插件时代就具备音视频能力，但安全、性能与跨平台三座大山让插件路线走向终结；WebRTC 把采集、编码、传输、加密整套能力搬进浏览器内核，并用「信令留白」换取了应用层的自由。理解这段历史，后面每个看似奇怪的设计决定都会有出处。 读完本节你能 阅读完本节，你应当能够： 说清楚插件时代浏览器音视频方案的三个结构性缺陷； 讲出 WebRTC 的两个基因（点对点直连、强制加密）分别来自哪段历史； 用「信令留白」解释为什么 WebRTC 标准里没有规定信令协议； 拿到一个实时类需求时，快速判断它是否真的需要 WebRTC。
1.1 从插件时代到原生通话
本节摘要：本节是全册的起点，回答「WebRTC 从哪来、解决什么问题、凭什么值得学」。浏览器在插件时代就具备音视频能力，但安全、性能与跨平台三座大山让插件路线走向终结；WebRTC 把采集、编码、传输、加密整套能力搬进浏览器内核，并用「信令留白」换取了应用层的自由。理解这段历史，后面每个看似奇怪的设计决定都会有出处。
读完本节你能
阅读完本节，你应当能够：
- 说清楚插件时代浏览器音视频方案的三个结构性缺陷；
- 讲出 WebRTC 的两个基因（点对点直连、强制加密）分别来自哪段历史；
- 用「信令留白」解释为什么 WebRTC 标准里没有规定信令协议；
- 拿到一个实时类需求时，快速判断它是否真的需要 WebRTC。
一、问题与直觉：能力有，为什么用不了
最初，浏览器并不是不能播放音视频——恰恰相反，那会儿的网页音视频能力多到眼花。RealPlayer、Windows Media Player 各有自己的浏览器插件，后来 Flash 一统江湖，视频网站、网页游戏、甚至企业级视频会议全跑在一个黑色矩形框里。问题从来不是「没有能力」，而是这能力长在别人家的地盘上：插件是独立进程，有自己的安全边界、自己的更新节奏、自己的性能开销，浏览器既管不住它，也护不住它。
把插件时代的结构性问题拆开看，有三条贯穿始终的痛：
安全层面，插件是浏览器的法外之地。 用户授权一次，插件就能长期占用摄像头麦克风；插件的漏洞浏览器补不了，只能等厂商发版。实时通信偏偏是最依赖摄像头麦克风的能力，等于把家里最私密的房间钥匙交给了一个你无法审查的租客。
性能层面，数据要绕一大圈。 插件拿到摄像头数据后，要走自己的一套编码与传输栈，与浏览器渲染层来回拷贝内存。在 2010 年前后的移动设备上，一路 Flash 视频通话就能把 CPU 吃满，发热降频接踵而至。
体验层面，移动端直接缺席。 iOS 与 Android 都没有给 Flash 生存空间，智能手机浪潮一起来，插件路线等于判了死刑——而移动端恰恰是最需要视频通话的地方。
所以浏览器厂商的结论是：与其让第三方在浏览器外面凿洞，不如把实时通信做成浏览器的原生器官。这就是 WebRTC 诞生的动因。Google 在收购了 GIPS（一家做实时音频引擎多年的瑞典公司）之后，把其核心代码开源，连同 Chrome 一起在 2011 年推向市场；随后 W3C 与 IETF 接手，把接口与协议拆成标准，Firefox、Safari 相继跟进。到今天，只要用户用的是持续维护的主流浏览器，WebRTC 能力就在那里，不装任何东西。
图：浏览器实时通信方案的演化时间线
二、核心原理：两个基因与一处留白
基因一：点对点直连
传统流媒体是「客户端—服务器」模型：服务器推流，观众拉流，所有数据都过服务器。WebRTC 的默认形态却是两台终端直接对话，服务器只在建立连接时牵线。这个取向来自它的出身——GIPS 的技术本来就是给运营商做语音引擎的，点对点意味着低延迟与低成本，服务器的角色被压缩到「帮你找到对方」为止。
代价也很清楚：连接建立变难了（两端都躲在 NAT 后，第 4 章专讲怎么打洞），多方场景的架构变复杂了（三个人通话总得有人转发，第 7 章专讲拓扑）。这两章的厚度，都是这个基因的账单。
基因二：强制加密
WebRTC 规范直接规定：媒体流必须走 SRTP，数据通道必须走 DTLS 加密的 SCTP，不提供明文开关。这与插件时代形成鲜明对比——当年很多商用视频方案传的是明文 RTP，抓包工具就能看个大概。强加密让「通话内容不落服务器、不被中间链路窥探」成为默认承诺，也是远程医疗、金融面签这类行业敢把业务搬到网页上的前提。
一处留白：信令不设标准
初学者最容易困惑的一点：两台浏览器怎么互相找到对方？WebRTC 标准的回答是——这个问题我们不管。交换网络地址（ICE 候选）与媒体描述（SDP）的过程叫信令，标准刻意不规定信令用什么协议、走什么服务器，只要求这条通道能在两端之间传文本。WebSocket、HTTP 长轮询、甚至二维码都可以充当信令。
留白是深思熟虑的取舍：定死信令协议，就意味着规定「谁有资格当目录服务」，会把 WebRTC 绑死在某种中心化架构上；留给应用层，则会议系统可以用成熟的房间服务，物联网场景可以用极简的配对协议。自由的另一面是责任——信令服务器要自己写、自己部署、自己保证安全，第 3 章会带你从零搭一个。
三、工程实践要点：什么需求该用 WebRTC
判断一个需求是否需要 WebRTC，核心问题是「延迟要求是否苛刻」与「是否双向」：
| 场景 | 合适的方案 | 理由 |
|---|---|---|
| 视频会议、在线问诊、双师课堂 | WebRTC | 双向、延迟要求在几百毫秒以内 |
| 远程协作白板、多人游戏状态同步 | WebRTC 数据通道 | 小消息低延迟，不需经服务器 |
| 直播带货、赛事转播（一对多） | HLS 或 WebRTC+SFU | 观众海量时 P2P 不经济，延迟容忍度高就用 HLS |
| 固件升级、日志上报 | HTTP | 无实时性要求，用 WebRTC 纯属浪费 |
一个实用的判别法：如果你的产品页面里有「面对面」的隐喻（见面、通话、连线），大概率是 WebRTC 的活；如果只是「看」和「下载」，先用更简单的方案。
完整案例：一套在线客服系统从插件迁移到 WebRTC
背景：某 SaaS 客服平台的「视频客服」功能建立在 Flash 之上。移动端根本用不了，桌面端也常被企业安全策略拦截插件；客服坐席必须用指定版本的浏览器，IT 部门疲于应付兼容工单。
操作：团队决定用 WebRTC 重写。第一步，网页端用 getUserMedia 取代插件的摄像头接管，权限弹窗由浏览器统一管理；第二步，信令复用平台已有的 WebSocket 通道，新增坐席与访客两类房间事件；第三步，媒体走点对点直连，访客与坐席之间不经过平台服务器，只在无法直连时回落 TURN 中继；第四步，录屏与文件传输改用数据通道，砍掉了原先一个二进制插件模块。
结果：移动端 Safari 与各主流安卓浏览器全部可用；坐席端不再限定浏览器版本；平台服务器的带宽成本反而下降——原先 Flash 方案媒体必须中转，现在大多数会话是直连，服务器只承担信令与少量中继流量。
解读：这个案例里收益最大的不是技术指标，而是「能力归属」的转移：摄像头权限、加密、传输质量控制全部回到浏览器与应用层手中，插件的版本地狱消失了。同时要注意，迁移的真正工作量不在「调通通话」，而在信令协议设计（坐席怎么接待访客、怎么转移会话）与弱网 fallback（直连失败降级中继）——这两块各占了项目周期的一小半，也正是本册第 3、4 章的主题。
变式：如果该平台要加「多方客服会诊」（一个客户面对多位专家），点对点直连就不够了，需要引入 SFU 做选择性转发；如果客户是银行，合规要求录音录像落库，则要在媒体链路上加服务端录制。需求的每一次变形，都会在架构上砸出一个新坑，本书后续章节会逐一给出填法。
本节要点回顾
- 能力原生内建：WebRTC 把采集、编码、传输、加密搬进浏览器内核，插件时代的三大结构性缺陷（安全失控、性能绕路、移动缺席）随之消解。
- 基因一是点对点：默认直连带来低延迟与带宽成本优势，但把「连接建立」与「多方架构」两块难度转嫁给了应用层。
- 基因二是强制加密：SRTP 与 DTLS 是规范内置项，没有明文开关，这是它进入医疗金融行业的安全底座。
- 信令留白是设计而非缺陷：标准不规定两端如何互识，应用层按需选择信令通道，自由的代价是自己写信令。
- 选型先看延迟与方向：双向低延迟用 WebRTC，单向大并发用 HLS，无实时要求用 HTTP，不为炫技选架构。