WebRTC基本概念(一)

Python013

WebRTC基本概念(一),第1张

WebRTC (Web Real-Time Communication),一个可以让用户用自己流量实现音视频实时通信的框架(APIs),支持浏览器(Firefox、Chrome、Opera)以及iOS、Android 原生系统(Poor WP,默哀)。对于觉得带宽贼贵又需要实现用户之间音视频通信的公司来说,这是一个大大的福利。本系列文章会从WebRTC基本概念慢慢说起。

官方介绍:

按照传统的通信流程,是这样的:

如下图所示,数据发送端和接收端都需要通过公网服务器进行转发(因为发送端和接收端通常都做了NAT,彼此并不知对方实际位置)。

e.g.:犹如一个中国人和一个外国人,他们彼此不懂对方的语言,不知道对方的地址,但是中间有一个邮局知道对方的地址,因为对方都在邮局做了注册地址并且获取了同一个编号,那么如果他们之间需要互相通信的话,就需要和邮局联系,邮局会进行翻译并发往同一编号的对应地址。 但是这中间就会产生一个问题,这时候如果有多个中国人和多个外国人都要进行通信,那么邮局的工作量就会越来越大,当他们的通信超过原有邮局人手可处理规模时,邮局要么扩招(需要钱)要么延缓发送(会造成延迟,甚至丢失信件)。

时间关系,以下内容不再举例说明,需要网络基础的同学才能继续观看。

在真实世界的网络中,因为IPv4的地址个数问题,我们基本都是采用NAT连接的:

STUN服务器提供的功能十分简单,它让使用者获取自己所在的公网地址和在NAT中所映射端口号,这个服务有什么用呢?当使用者知道自己所在公网地址以及内部NAT映射端口时,它便可以讲自己的公网地址和端口号通知对方,这样对方就可以在茫茫大网中找到自己。

在以往统计中,WebRTC通过STUN建立连接的成功率为86%。

TURN [2] 是一个client-server协议。TURN的NAT穿透方法与 STUN 类似,都是通过取得应用层中的公有地址达到NAT穿透。但实现TURN client的终端必须在通讯开始前与TURN server进行交互,并要求TURN server产生"relay port",也就是relayed-transport-address。这时TURN server会建立peer,即远端端点(remote endpoints),开始进行中继(relay)的动作,TURN client利用relay port将资料传送至peer,再由peer转传到另一方的TURN client。

必须要安装的软件如下: SVN,这个是必须的。可以安装TortoiseSVN,找个合适的版本就可以了。【点击免费试用,0成本启动】

WebRTC实现了基于网页的视频会议,标准是WHATWG 协议,目的是通过浏览器提供简单的javascript就可以达到实时通讯(Real-Time Communications (RTC))能力。

WebRTC(Web Real-Time Communication)项目的最终目的主要是让Web开发者能够基于浏览器(Chrome\FireFox\...)轻易快捷开发出丰富的实时多媒体应用,而无需下载安装任何插件,Web开发者也无需关注多媒体的数字信号处理过程,只需编写简单的Javascript程序即可实现,W3C等组织正在制定Javascript 标准API,目前是WebRTC 1.0版本,Draft状态;另外WebRTC还希望能够建立一个多互联网浏览器间健壮的实时通信的平台,形成开发者与浏览器厂商良好的生态环境。

想要了解更多关于这方面的相关信息,推荐咨询ZEGO即构科技。ZEGO即构科技是一家全球云通讯服务商,专注自研音视频引擎,服务覆盖全球,链接 5 亿终端用户。ZEGO即构科技覆盖212个国家/地区,全球用户体验毫秒级互动,日均通话时长达30亿分钟,跻身云通讯行业头部,全方位行业解决方案,满足百余个业务场景需要,服务客户4000家,70%泛娱乐/在线教育客户的选择。