前言

近几年实时音视频通信应用呈现出了大爆发的趋势。在这些实时通信技术的背后，有一项不得不提的技术——WebRTC。

今年 1 月，WebRTC 被 W3C 和 IETF 发布为正式标准。据调研机构 GrandViewReseach 的报告显示，预计 2025 年全球 WebRTC 市场规模将达到 210.23 亿美元，相较 2019 年 23 亿美元的市场规模，5 年的复合年增长率为 43.6％。

本系列内容将和大家一起来探讨，为什么 WebRTC 受到开发者及企业的青睐 ？未来 WebRTC 又将如何发展？以及声网Agora 是怎样基于 WebRTC 进行二次开发，又将如何支持 WebRTC NV 版本的？

 

WebRTC可以被看作是一个不需要安装任何插件或者下载任何额外程序就能运行的浏览器原生实时通信手段。不同的客户端通过（相同或不同）浏览器跳转到同一个 URL 就能实现实时互通、看见彼此。但这只是“上帝视角”的说法，其中包含的技术框架和实现细节远没那么简单。

基本概念

在我们开始讨论 WebRTC 是如何工作之前，先来理清几个关键的技术概念。

P2P

可以实现实时点对点音视频（即多媒体）通信是 WebRTC 最为显著的一个特征。为了通过 Web 浏览器进行通信，要求每个人的 Web 浏览器都需要同意“开始接通”，知道对方的网络定位，并且还需要绕过网络安全和防火墙保护并实时传输所有多媒体通信才能够得以实现。

在基于浏览器的对等通信中，如何定位和建立与另一台计算机的 Web 浏览器的网络连接并进行高效数据传输是其最大的挑战之一。

当你想要访问一个网站时，一般都是直接输入网址或者点击连接跳转来进行页面查看。在这个过程中，其实是你向通过提供网页（HTML，CSS和JavaScript）进行响应的服务器发出了一个请求。而发出这个访问请求的关键是你向已知且易于定位的服务器（通过DNS）发出HTTP请求，并获得响应（即网页）。

乍看之下，好像这个问题也没那么难，但我们举个例子来看看：现在假设我想和同事进行视频沟通。那我们怎么才能发出请求并实际直接接收到对方的音频和视频数据呢？

上述场景中出现的问题就可以通过 P2P（点对点传输）技术来解决，而 WebRTC 本身就是基于点对点（Peer-to-Peer）连接的，其中的 RTCPeerConnection就是负责建立 P2P 连接以及传输多媒体数据的 API。

防火墙和 NAT 穿透

日常生活中，我们大都是通过工作或家庭网络进行互联网访问，这时候我们的设备通常是在防火墙和网络访问转换设备（NAT）的后面，因此并没有分配静态的公共 IP 地址。更进一步来看，NAT 设备会将防火墙内部的私有 IP 地址转换为面向公众的IP地址，以确保对可用公共 IP 地址的安全性和 IPv4 限制。

让我们带入上一个例子来看看，考虑到 NAT 设备的参与，我怎么才能知道同事的 IP 地址，将音频和视频数据发送到这个地址，同样，他怎么知道我的IP地址可以将音频和视频数据发送回去? 这就是 STUN（Session Traversal Utilities for NAT，NAT会话穿越应用程序）和 TURN（Traversal Using Relays around NAT，中继穿透 NAT）服务器要解决的问题.

为了使 WebRTC 技术正常工作，首先会向 STUN 服务器请求一个面向公众的 IP 地址。如果这个请求得到了回应，并且我们收到了面向公众的 IP 地址和端口，就可以告诉其他人如何直接和我们建立连接。而别人也可以使用 STUN 或 TURN 服务器执行相同的操作。

信令&会话

由于存在 NAT，WebRTC 不能直接与对端建立连接，因此设备之间需要通过信令服务进行发现和协商以进行实时的音视频交换。上述的网络信息发现过程是更大层面上的信令主题之一，在WebRTC 的情况下，它是基于 JavaScript 会话建立协议（JSEP）标准的。信令涉及网络发现和 NAT 穿透，会话创建和管理，通信安全和协调以及错误处理等。

WebRTC 并没有规定信令必须使用何种实现，这是为了让开发者所用技术和协议可以更加灵活。

目前业界使用较多的是 WebSocket + JSON/SDP 的方案。其中 WebSocket 用来提供信令传输通道，JSON/SDP 用来封装信令的具体内容：

WebSocket 建立在 TCP 之上，提供了长连接的能力，解决了 HTTP 仅支持半双工，Header 信息冗余等低效问题。WebSocket 允许服务器和客户端在任何时间推送消息，而与先前的请求没有任何关系。使用WebSockets的一个显着优势是，几乎每个浏览器都支持WebSockets。

JSON 是一种 Web 领域常见的序列化格式，用来封装一些用户自定义的信令内容。（本质是序列化工具，所以类似 Protobuf/Thrift 这样的方案也完全可行）。

SDP（Session Description Protocol）是一个会话描述性协议，用来封装流媒体能力协商的信令内容，两个 WebRTC 代理会将建立连接所需的所有状态通过此协议来分享 。

如果概念性的内容不太好理解，那我们可以把它想象成一个日常交流过程：

当我们准备和一个陌生人进行交流或者一个陌生人希望加入你的聊天，那当你或者对方发出了这个信息，不管你是接受还是拒绝都需要与对方交换这个信息。你们只有交流后才有可能能获更多信息来判断是否你们可以一起愉快地聊天。而帮你快速汇总这些信息的就是 SDP （会话描述协议），它包含了例如使用的是什么代理，它支持什么硬件，它想交换什么类型的媒体等信息。

那当两个人想要开始聊天时总需要有一个人先开口

更多文章请关注《万象专栏》