WebRTC 初探

栏目: 后端 · 前端 · 发布时间: 4年前

内容简介:webrtc是一种免费开源的实时通信技术,集成了音视频采集、编解码、流媒体传输、渲染等功能,并在Native代码基础上,封装了简单的JavaScript api,仅通过几行代码即可实现点对点通信,且具有良好的跨平台特性,目前主流的浏览器都已支持。SDP:即会话描述协议,主要保存当前会话的媒体和传输信息,其中媒体信息包括媒体类型、传输协议、媒体格式等,传输信息包括媒体的远程地址信息、带宽等;它由多行kv格式的文本信息组成,具体可参考这里。(https://tools.ietf.org/pdf/draft-na

引言

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

基本概念

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

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

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

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

webrtc通信

基于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中的地址信息替换为公网地址进行通信了。

WebRTC 初探

然而,有些情况并不是那么顺利,比如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协议推流到流媒体服务器,流媒体服务器做一些编码处理等将流分发给各个客户端,进而拉流播放。出于成本、安全等考虑,可能会将不同流按照一定的配比推送到不同的流媒体服务商,在特殊情况下可采用调度方式进行切流处理。

WebRTC 初探

优点:

  • 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 初探

目前开源的主流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直播,目前还没有成熟的解决方案,需要自己实现媒体服务器,门槛较高,具体可根据开发成本与收益进行定夺。


以上所述就是小编给大家介绍的《WebRTC 初探》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Web Anatomy

Web Anatomy

Robert Hoekman Jr.、Jared Spool / New Riders / 2009-12-11 / USD 39.99

At the start of every web design project, the ongoing struggles reappear. We want to design highly usable and self-evident applications, but we also want to devise innovative, compelling, and exciting......一起来看看 《Web Anatomy》 这本书的介绍吧!

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

URL 编码/解码
URL 编码/解码

URL 编码/解码

UNIX 时间戳转换
UNIX 时间戳转换

UNIX 时间戳转换