WebRTC 初探

引言

webrtc是一种免费开源的实时通信技术，集成了音视频采集、编解码、流媒体传输、渲染等功能，并在Native代码基础上，封装了简单的JavaScript api，仅通过几行代码即可实现点对点通信，且具有良好的跨平台特性，目前主流的浏览器都已支持。

基本概念

SDP：即会话描述协议，主要保存当前会话的媒体和传输信息，其中媒体信息包括媒体类型、传输协议、媒体格式等，传输信息包括媒体的远程地址信息、带宽等；它由多行kv格式的文本信息组成，具体可参考这里。（https://tools.ietf.org/pdf/draft-nandakumar-rtcweb-sdp-08.pdf）

Offer：通信的发起方对自己的sdp描述

Answer：通信的接收方对自己的sdp描述

信令：协调发起方、接收方通信的数据信息，其中包括sdp描述信息、会话控制信息（节点加入、退出及各类的业务控制信息等）、网络信息、错误信息等。

webrtc通信

基于webrtc的点对点音视频通信示意图如下图所示：

其具体的流程如下：

1. 客户端A初始化本地音视频设备，创建一个用于offer的SDP对象，其中SDP对象中保存当前音视频的相关信息；

2. 客户端A通过信令服务器将SDP信息发送给客户端B；

3. 客户端B在接收到客户端A发送的SDP信息并保存后，初始化本地音视频设备并创建用于answer的SDP对象；

4. 客户端B通过信令服务器将SDP信息发送给客户端A；

5. 客户端A、B通过交换SDP等信息，建立P2P通道进行音视频传输；

Webrtc ICE（交互式连接建立）

在现实世界中，客户端A、B大部分位于NAT之后，只具有一个内网访问的私有ip，不足以提供足够的信息来建立一条端对端的连接。为了克服由NAT产生的网络问题，一般情况下，webrtc采用ICE框架，通过ICE来找到一条对等连接的最佳道路。

举个栗子，小A和小B是好朋友，某天他们都换了手机号，而且都绑定了一个手机短号（短号不在一个集团网中），然而都忘记新的号码是多少。为了两个人通话联系，小A尝试用短号拨号不通后，小A拨打114询问自己的电话号码，114看到来电显示后将手机号告诉小A；小B以同样的方式获得了自己的手机号；这样两人就可以相互通话了。

类似于上边的例子，客户端A和客户端B处在不同的内网环境中，首先ICE尝试采用从操作系统和网卡获得的主机地址建立连接，如果连接建立失败，ICE会发送binding request给STUN服务器，服务器探测到客户端A的公网地址后将信息加在binding request中，并返回给客户端A，这样客户端A获取到了自己的公网地址。以同样的方式客户端B获取到自己的公网地址。这样，客户端A、B就可以将SDP中的地址信息替换为公网地址进行通信了。

然而，有些情况并不是那么顺利，比如114显示小A、小B电话未知来电或者小A、小B通话线路故障等原因，导致小A、小B不能通话。这个时候114说，要不这样吧，我给你们各发一个临时号，如果你们要通信，我直接按照你们的临时号给中转一下通话信息。同理，webrtc中，如果STUN建连失败，可以采用TURN服务器的方式。TRUN可以担任中间人的角色，将客户端A、B的数据进行中继转发，实现不同内网的客户端通信。

Stun/turn服务器可以采用coturn（https://github.com/coturn/coturn），服务器验证方式可以参考这里（https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/）。

Webrtc与直播：

以下根据自己的理解，简要的说明几种直播方案的优缺点。

1、rtmp方式

众所周知，目前主流的直播方案一般采用rtmp方式，首先客户端采集音视频流，并通过rtmp协议推流到流媒体服务器，流媒体服务器做一些编码处理等将流分发给各个客户端，进而拉流播放。出于成本、安全等考虑，可能会将不同流按照一定的配比推送到不同的流媒体服务商，在特殊情况下可采用调度方式进行切流处理。

优点：

• CDN 支持良好，主流的 CDN 厂商都支持

• 技术比较成熟，集成方便，例如声网、即构等，集成对应平台的sdk即可进行推流。

• 相较于端对端的webrtc方式，并发度高，适合多人直播场景；

缺点：

• 协议基于tcp，相对于webrtc方式延时较大，对于某些低延时场景体验较差；

• 不支持浏览器推流等；

2、基于端对端的webrtc

基于端对端的webrtc方式，严格来说不属于常规的直播场景，其主要适用于人数较少的视频会议等场景，各个节点分别建立p2p连接进行音视频的传输，主要工作流程如上边webrtc所示。

优点：

• 在web端，对于开发者和使用者来说，音视频通信的开发和使用简单化；对于开发者来说，门槛低，不必熟悉流媒体，仅调用js api即可实现；对于使用者来说，打开浏览器等浏览器即可。

• 点对点通信，节省服务器带宽费用。

• 相对于基于tcp的rtmp推拉流方式，支持udp的webrtc方式延时低。

缺点：

• 客户端浏览器的性能有局限。如果是1v1方式的直播连麦，尚好；如果多人同时进行直播连麦，浏览器需要同时给多人进行视频传输，性能欠佳。

• 音视频处理相对来说比较困难。webrtc开放的api接口较少，集成第三方音视频处理方案较难，比如秀场直播的美颜等。

• 音视频的传输质量难以保障，尤其在跨地区、跨运营商的情况下，仅能做一下端对端质量控制算法，无法保障。

• 兼容性问题。在pc端，目前的主流浏览器都支持webrtc，但是在移动端，只有部分浏览器支持（目前国内的主流手机浏览器均不支持）。

• 关于直播内容的后续工作不好展开，内容质量难以把控。比如rtmp推拉流方式生成的回放、内容审核等很难处理了。

3、基于媒体服务器的webtrc直播：

基于端对端的webrtc受限于客户端性能、连接人数等限制，很难适用于直播场景。为了解决这些问题，可以引入媒体服务器，客户端仅传输一路音视频流到媒体服务器，其余客户端通过与媒体服务器建立连接进行音视频显示。

目前开源的主流webrtc媒体服务器如下：

• Kurento（https://github.com/Kurento/kurento-media-server）

• licode（https://github.com/lynckia/licode）

• janus（https://github.com/meetecho/janus-gateway）

优点：

• 相对于端对端的webrtc方式，避免了客户端性能低、音视频处理、内容审核等问题，支持更为复杂的应用场景；

• 支持多人进行同时观看直播，并发度高；

• 在web端集成相对简单容易，采用浏览器即可接入，且延时较低；

缺点：

• 该种方式相对于端对端的webrtc方式，开发成本较高，需要实现自己的媒体服务器，而目前没有比较成熟的方案。

• 相对于成熟的rtmp配套解决方案，周边设施相对较少。

综上所述，基于端对端的webrtc直播的方式不适合直播场景；基于媒体服务器的webtrc直播，目前还没有成熟的解决方案，需要自己实现媒体服务器，门槛较高，具体可根据开发成本与收益进行定夺。