H5 和 WebRTC 实时通讯方案的不同

目前，实时音视频通讯的实现方案在浏览器上有两种，分别是 H5 和 WebRTC，前者可以拉流观看，后者可以实现推流和拉流。

正文

在浏览器上实现音视频实时通讯，H5 和 WebRTC 是两种可选方案，但是二者有明显的区别，优劣也比较突出。

H5 的实时通讯方案

浏览器 H5 的实时方案有明显的优势和劣势，优势是开发成本比较低，开发周期短，劣势是只能拉流，不能推流，不能实现互动连麦。另外，浏览器 H5 方案延迟比较大。

如果使用 RTMP 或者 HTTP-FLV 协议，延迟会在 1 秒到 3 秒之间，如果使用 HLS 协议延迟会更大，当然也可以通过限制 ts 分片大小实现较低的延时，太大的延迟是不适合做直播连麦的。但是对于类似大班课和会议的场景，上述媒体协议都是适合的，因为音视频流是单向的，没有延时上感知。

WebRTC 的实时通讯方案

尽管浏览器 H5 方案非常普遍，开发方便但是不能连麦直播。那么在浏览器上能不能实现连麦直播呢？答案是肯定的，它就是 WebRTC。最早是由谷歌发起的 P2P 实时通讯方案，在 Chrome 浏览器上进行了长期而广泛的验证，目前很多浏览器都已经支持了 WebRTC。

WebRTC 包括了音频引擎，视频引擎、传输引擎等，其中，音频引擎包括了两个编解码器：iSAC 和 iLBC，前者针对宽带和超宽带的音频编解码，后者针对窄带音频编解码，其实就是 Opus 音频编码。音频引擎还包括了回声消除、噪音抑制和自动增益模块。视频引擎包括了 VP8 和 VP9 的视频编解码器，目前谷歌正打算推出 AV1。视频引擎还包括视频抖动缓冲和图像质量增强等模块。传输引擎的话，WebRTC 使用 SRTP（Secured Realtime Transport Protocol）进行音视频实时的安全传输。其中，密钥的生成依赖于 DTLS 协议的协商过程。

同样，浏览器 WebRTC 方案也有自己的不足：

1）没有自定义模块设置接口，在浏览器端不能实现较好的美颜和贴图效果。

2）WebRTC 没有统一的信令标准，一方面给了技术方案的灵活性，另一方面也造成多系统互通时的转换成本。

3）音频编码格式和视频编码格式必须依靠 WebRTC，不能自行定制化。

4）很多流浏览器支持 WebRTC 不是很友好，存在差异性。

5）相比较传统的 CDN 方案，费用成本比较高。