WebRTC协议

打开你的浏览器，来一场"加密直觉"的视频通话
[一、WebRTC 是什么？------浏览器自己就能"打电话"](#一、WebRTC 是什么？——浏览器自己就能“打电话”)
[二、为什么 WebRTC 这么"实时"？](#二、为什么 WebRTC 这么“实时”？)
[三、WebRTC 是怎么"握手"建立连接的？](#三、WebRTC 是怎么“握手”建立连接的？)
四、连接建立之后，数据如何安全流动？
[五、WebRTC 有哪些令人兴奋的应用场景？](#五、WebRTC 有哪些令人兴奋的应用场景？)
[六、WebRTC 的"边界"与未来方向](#六、WebRTC 的“边界”与未来方向)

打开你的浏览器，来一场"加密直觉"的视频通话

你或许有过这样的体验：点击一个网页链接，下一秒摄像头就亮了，屏幕上浮现出对方的笑脸。没有下载安装，没有插件弹窗，甚至在完全不懂技术的人看来，它就应该如此自然。

而在九年前，这几乎是一件不可思议的事。

想象一下那时要实现一个视频通话的流程：下载专用客户端，安装一堆依赖插件，反复调试麦克风，最后却发现对方用着不同版本的软件，画面根本连不上。Flash 还统治着网页动画和视频的世界，想实现在线通话，几乎不可能绕过这些遍地陷阱的插件和私有协议。

但如今，这一切已经被一项技术彻底改变了------它叫做 WebRTC (Web Real-Time Communication)，一个让浏览器"原厂自带"实时音视频通话能力的神奇协议。

一、WebRTC 是什么？------浏览器自己就能"打电话"

WebRTC 诞生于 2010 年，源于 Google 对 Global IP Solutions（GIPS）公司的收购，后者正好掌握着关键的语音和视频处理技术。2011 年 Google 将它开源，2012 年 Chrome 21 抢先集成了 WebRTC API；多年努力之后，它终于在 2021 年 1 月正式被 W3C（万维网联盟）和 IETF（互联网工程任务组）确立为官方标准。

更通俗地讲，WebRTC 是一套"零摩擦力"的实时通信技术。开发者通过它提供的 JavaScript API，就能像调用一块积木一样，让网站直接访问你的摄像头、麦克风甚至屏幕，在两个设备之间建立点到点（P2P）的直接连接，并传输音视频或者任意文件数据------全程不需要安装任何插件，没有额外的第三方软件。Google Meet、Slack、WhatsApp、Discord 等我们日常使用的工具，底层都在悄悄依赖着它。

二、为什么 WebRTC 这么"实时"？

传统的直播流协议（如 HLS 或 RTMP）通常会引入几秒甚至更长时间的延迟，以换取大规模分发的稳定性；而 WebRTC 的设计目标从诞生之初就极其明确------获得最低的端到端延迟，通常可以压缩到 200~500 毫秒以内。

这背后的关键选择，是 WebRTC 坚持在传输层使用 UDP 而不是 TCP。

为什么不用更可靠的 TCP？因为 TCP 为了保证数据完整性，如果中间丢了一个小包，它会卡住后面所有数据，直到那个包重传成功------这种现象叫作"队头阻塞"。但在实时语音或视频聊天中，偶尔丢一个包远没有"画面突然卡住等两三秒"那么令人抓狂。UDP 直接放弃了这个阻塞机制，让 WebRTC 只对偶尔的丢包做基本的恢复，比如通过前向纠错或自适应缓冲，而不是把整个通话拖入困境。

如果再深入一层，你会发现 WebRTC 的设计远不止"选 UDP"这么简单。它整个协议栈的复杂性，恰恰是为了把"直接通信"这个看似简单的想法，在真实、复杂、充满各种各样防火墙和 NAT（网络地址转换）的互联网环境中变成现实。

三、WebRTC 是怎么"握手"建立连接的？

第一步：捕获本地媒体

通话的第一步，总得先拿到画面和声音。WebRTC 通过 getUserMedia() 这个 API 来请求用户授权，一旦你点了"允许"，它就能把麦克风、摄像头甚至屏幕共享的原始数据包装成一个 MediaStream 数据流。

这层 API 在设计上对开发者非常友好：不管你的电脑上插了什么样的摄像头，或者麦克风是高端的还是普通的，WebRTC 都能提供一个统一的接口。你还能够指定分辨率、帧率，甚至开启回声消除和降噪------一边打电话一边打字时，对方不会被键盘声吓一跳。

第二步：信令------交换"会话名片"

拿到媒体流之后，真正的"找人"过程才刚刚开始。WebRTC 自己不负责解决"怎么找到对方"这个问题，而是交由一个叫做**信令服务器（Signaling Server）**的中间人角色来完成。

信令服务器并不传输实际的音视频数据，它只负责交换两样关键信息：

SDP （Session Description Protocol，会话描述协议）------相当于双方的"能力名片"。A 告诉 B：我支持哪些音视频编码（比如 VP8、H.264、Opus），我的网络端口大概是什么样的。B 收到后回复它自己的 Answer。
ICE 候选地址（ICE Candidate）------更直白地说，就是"我的真实网络地址"。由于大多数设备被藏在复杂的家庭路由器或公司防火墙后面（也就是 NAT 环境中），真正的 IP 地址是隐藏的，ICE 候选地址要尝试找出可以打到对方的最优路径。

信令本身怎么传递呢？WebRTC 没有做硬性规定，你用 WebSocket、HTTP 长轮询甚至发电子邮件都行，只要能把这段协商信息送达即可。

第三步：ICE + STUN/TURN------穿过网络的层层迷雾

ICE（交互式连接建立）是 WebRTC 里的"探路者"。要建立点对点连接，必须知道"你在哪"和"我在哪"。这时 STUN 和 TURN 两个服务器就登场了：

STUN 服务器：简单说，它能帮忙问一下"请告诉我，从公网视角看过来，我的 IP 和端口是多少？"。由此得到的公网地址会放到 ICE 候选列表里。
如果 STUN 也穿不透层层 NAT ，那就要靠 TURN 服务器 做最后的"保底"------由它负责在两个设备之间中转数据。虽然这样会增加一点点延迟，但至少能确保在任何复杂网络下都可以连接成功。

简单来说，信令服务器先让双方握上手，交换网络"名片"；STUN/TURN 解决的是握手之后，数据究竟该往哪个方向发的问题。两者配合起来，才是 WebRTC 连接能够"打通"的关键。

四、连接建立之后，数据如何安全流动？

当 SDP 和 ICE 协商完成后，真正的音视频数据开始在浏览器之间直接流动。但这里还有一个重要问题：既然数据走的是公网，怎么保证不被别人偷听？

WebRTC 的回答是"强制加密"。所有传输的媒体数据都必须使用 SRTP（安全实时传输协议） 进行加密，而底层的密钥协商和证书交换则依赖 DTLS（数据报安全传输协议） ，相当于 UDP 版的 TLS------你平时网购时浏览器用的 HTTPS，其底层加密在 UDP 套件里就是 DTLS。WebRTC 规定所有组件都必须启用加密，因此它在设计之初就把隐私放在了非常重要的位置，JavaScript API 也强制要求运行在 HTTPS 等安全环境下。

如果你需要传输文本聊天消息、文件或者游戏同步数据，WebRTC 还提供了 RTCDataChannel API。它既可以走类似 TCP 的"可靠传输"，也可以走类似 UDP 的"不可靠但快"的方式，用来配套不同的业务场景。

五、WebRTC 有哪些令人兴奋的应用场景？

视频会议与协作平台：基于 WebRTC，Google Meet、Zoom 网页版、Teams 等都能让你直接通过浏览器加入会议，无需安装任何客户端。企业还可以利用 WebRTC 实现屏幕共享、实时协作白板等功能。
远程医疗：医生和患者通过浏览器直接进行高清视频问诊，甚至结合 AI 辅助诊断。WebRTC 的低延迟和安全加密特性，让诊疗过程更加可靠和私密。
AI 智能体：越来越多的人工智能助手开始通过 WebRTC 实现"对话式交互"。WebRTC 的极低延迟（通常在 500 毫秒内）能让人类与 AI 的对话几乎接近自然交流的体验，AI 还能一边听一边对语流做实时处理。
实时体育直播与在线拍卖：体育赛事或拍卖场景中，几秒钟的延迟就意味着"别人先看到进球我才看到"。WebRTC 的实时性能够实现真正的同步直播感受，竞拍者也能几乎同时看到出价结果。
远程教育与互动课堂：一对一教学或小班课场景中，WebRTC 让师生能够面对面交流，共享电子白板、演示幻灯片等，几乎重现线下课堂的即时互动感。
文件共享与实时游戏 ：利用 RTCDataChannel，可以实现浏览器之间的点对点文件传输（不需要上传到某个云服务器），或者在多人联网游戏中同步玩家位置和操作状态，延迟极低。

六、WebRTC 的"边界"与未来方向

WebRTC 当然不是所有场景的万能答案。如果你需要给几千甚至几万观众同时推流高清直播，纯点对点架构会很快到达瓶颈，这时通常需要配合 SFU（Selective Forwarding Unit，选择性转发单元） 转发服务器来分担压力。

但它依然是实时通信领域的"王牌协议"。在 2026 年的今天，WebRTC 全球市场规模已约为 90 多亿美元 ，而预计到 2034 年，这一数字可能上升至 约 1220 亿美元，预测期内的复合年增长率超过 30%。在可预见的未来，低延迟交互与 AI 结合的实时通信只会越来越深入人们的工作和生活方式。

同时，标准化组织也已经在推动 WHIP（WebRTC HTTP Ingest Protocol） 等新协议，让浏览器推流到直播平台更加标准化；视频编解码方面，更高效的压缩技术（如新一代的 AV1 以及尚未正式落地的 H.266/VVC 后续演进）也被源源不断地引入 WebRTC，进一步降低带宽成本，提升移动端续航。