用SRS快速搭建WebRTC推流和播放

用SRS快速搭建WebRTC推流和播放,第1张

项目中需要做远程控制,可以传输指令和音频,领导说用前端做,整合到h5中,于是研究了一下webRTC,基本能解决需求就把项目简化写了一个demo分享出来

核心就是两端通过内网nat穿透建立p2p连接,这里我将peerB作为主控端,初始化时,连接本机获取本地icecandidate,这里icecandidate可以理解为内网nat对外网的映射,可以直接在公网访问的地址,可以是一个公网域名,也可以是服务器ip+端口,获取之后,通过>

WebRTC(Web Real-Time Communication)也被称为网络实时通信,是由 Google、Mozilla 和其他公司推动的一个开源项目,它通过 Javascript API 实现无插件的实时通信,以及在不需要中介的情况下在浏览器之间交换任意数据

WebRTC的优点:

WebRTC技术的诞生,有一个很重要的原因在于,在浏览器实现实时音视频通话,需要依赖相关插件或程序,而插件安全漏洞问题则更为关键。浏览器开发人员无法控制这些插件以及更新,因此插件带来的安全风险也相对较大。

在WebRTC诞生之前,开发实时音视频应用的成本是非常高,需要考虑的技术问题很多,如音视频的编解码,数据传输延时、丢包、网络抖动、回音处理和消除等,如果要兼容浏览器端的实时音视频通信,还需要额外安装插件。当然,可以考虑使用第三方成熟技术,比如当时世界顶级的互联网音视频方案GIPS(Global IP Solutions),支付相应的费用就行。很多知名的应用或者软件服务商也都在用GIPS,如Yahoo,AOL,IBM,SKYPE,QQ等。

WebRTC项目的愿景:实时通信web化,让WebRTC成为互联网音视频实时通信的规范,让开发者基于此规范快速开发出安全、可靠的应用。未来的音视频实时通信,必定是现代化生产活动中极其重要的板块。以下是WebRTC的部分应用场景:

两个不同网络环境的(具备摄像头/麦克风多媒体设备的)客户端(浏览器或APP),要实现点对点的实时音视频对话,难点在哪里?

要实现P2P通信,首先需要了解彼此是否都支持相同的媒体能力,WebRTC默认使用V8编解码器,如果要连接的对方不支持V8解码,如果没有媒体协商过程。那么即使连接成功,把视频数据发给对方,对方也无法播放

比如:Peer-A端可支持VP8、H264多种编码格式,而Peer-B端支持VP9、H264,要保证二端都正确的编解码,最简单的办法就是取它们的交集H264

有一个专门的协议 ,称为Session Description Protocol (SDP),可用于描述上述这类信息,在WebRTC中,参与视频通讯的双方必须先交换SDP信息,这样双方才能知根知底,而交换SDP的过程,也称为"媒体协商"。

交换数据会通过一个中间服务来完成,在这里,我们称之为信令服务器

在建立P2P连接时,需要交换的信息有:

最理想的场景

然而,在大多数情况下,两个对等端都是各自处于某个局域网之中,相互之间隔着NAT与防火墙

NAT(Network Address Translation)即为网路地址转换协议

局域网-->公网

公网-->局域网

可以借助STUN服务器,穿越NAT

在NAT四种主要类型中有三种是可以使用STUN穿透:完全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT。但大型公司网络中经常采用的对称型 NAT(又称为双向NAT)则不能使用STUN穿透,这类路由器会透过 NAT 布署所谓的「Symmetric NAT」限制。也就是说,路由器只会接受之前连线过的节点所建立的连线。

可以点对点连接的情况与需要中转的情况(数据来源于Google)

不过在国内大部分局域网无法穿越。

1、 WebRTC是什么?

2、 WebRTC能做什么

3、 常用API

4、 基本原理

WebRTC全称是Web Real-Time communication,是一种实时音视频通讯技术,通过WebRTC可以使浏览器之间建立点对点的连接,并实时传输数据。

通过上述可以看到浏览器M和浏览器L可以在不依赖于Web服务器的情况下点对点实时传输数据。上图中的Web服务器不是用于数据传输,而是用于协助浏览器M和浏览器L进行连接,进行协助连接的服务器也叫信令服务器。

WebRTC主要分为四部分,分别是信令、建立连接、安全加密、数据传输,下面分别介绍四个步骤。

信令是指通信两端基于交换的数据进行协商。通俗的解释就是在互联网中两个浏览器之间如果要进行点对点的数据传输,连接双方需要交换对方的一些基本信息,基本信息包括对方的地址,带宽,数据的编解码格式,是否支持音视频等等信息。

通信双方的基本信息完成交换后,浏览器双方开始建立连接。在网络中,浏览器双方可能在同一个内网,可能不在同一个内网,中间可能还隔着交换机、路由器,还会存在防火墙。在网络的环境复杂的情况下,通信的双方需要找到一条最佳路径传输数据建立连接。建立连接主要使用的协议就是ICE协议。ICE协议又需要依赖STUN协议和TURN协议。

在WebRTC中,为了保证媒体传输的安全性,引入了DTLS作为传输加密协议,DTLS原理和作用类似于SSL/TLS,DTLS主要适用于UDP通信过程的加密,SSL/TLS主要适用于TCP通信过程的加密。

在WebRTC中,音视频数据传输是使用RTP协议,然后通过 DTLS 协商出加密密钥之后,RTP 也需要升级为 SRTP,通过密钥加密后进行通信。协议栈如下图所示:

上面说了对数据加密是使用DTLS,传输数据则分为两种情况,一种是传输音视频数据,另一种是传输自定义应用数据。

1、音视频数据传输,主要使用RTP/SRTP、RTCP/SRTCP协议

前面主要对WebRTC做了一个简单介绍,跳过了很多细节,有些地方可能不够严谨,如果有兴趣的读者,可以对技术做进一步研究,比如:

1、信令如何进行协商?

2、传输层用了UDP,UDP本身是不可靠的,那么,音视频数据、自定义用户数据的时序、质量是如何保证的?

3、RTP用来传递音视频数据,为什么还需要有RTCP?

4、SCTP如何从协议层面兼顾传输的效率和质量?如何实现自定义数据的高效传递?

5、ICE协议的完整流程。

6、其他。

以上就是关于用SRS快速搭建WebRTC推流和播放全部的内容,包括:用SRS快速搭建WebRTC推流和播放、WebRTC 通信原理、[webrtc] 交互式连接建立(ICE)等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/web/9740254.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-01
下一篇 2023-05-01

发表评论

登录后才能评论

评论列表(0条)

保存