WebRTC基本概念 | WebRTC编风网
0

WebRTC基本概念

已有 737 人阅读此文 - - 简书 - Mr__C

前言

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

What is WebRTC?

官方介绍:

WebRTC is a free, open project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs.The WebRTC components have been optimized to best serve this purpose.

Our mission: To enable rich, high-quality RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow themall to communicate via a common set of protocols.

WebRTC是一个free的开源项目,该项目提供了一组可以在浏览器、手机应用平台(再次声明,目前只支持iOS和Android。)实现实时通信的简单API(s),WebRTC的目标是将实时通信过程做得最优化。

我们的任务(指WebRTC官方):在手机应用平台、浏览器和物联网设备之间用同一组协议实现高质量实时通信。

RTC基本框架

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

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

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

1

怎么办?这时我们就要考虑另外一种解决方案了。我们让发送端直接发送数据给接收端,这样就可以省掉服务器的转发功能了是不是?当然是,但是如我们上述例子所说,中国人不懂俄语,俄罗斯人不懂中文,鸡同鸭讲眼碌碌。他们之间怎么通信呢?邮局觉得上述方式太不靠谱了,于是决定通过一种技术,当有一个中国人或者外国人寻求转发时,邮局通过“魔法”查找出了对方地址,并且不说话丢给了对方一只翻译面包,对方接收到翻译面包后可以习得对方语言,直接和对方通话。

例子中的“魔法”就是本文要介绍的 ICE框架,而翻译面包就是NAT穿越技术。

2

ICE(Interactive Connectivity Establishment)框架

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

3

当处于以上网络时,Peer和Peer之间基本都是通过NAT和防火墙连接上互联网的,所以当我们要建立两端之间的直接通信时,我们需要服务器对两端进行Signalling,具体如何进行Signalling会在下篇文章中介绍。本文假设两端已经Signalling完毕。

ICE框架 (ICE会尝试找到端与端之间最优连接路径)会完成以下工作:

·首先ICE会直接利用主机地址和网卡地址进行连接,如果刚好端拥有公网IP(无NAT),那么此时可以直接建立连接。

·如果第一步失败,ICE会尝试建立STUN连接。

4

·如果第二步失败,ICE会利用TURN服务器建立连接。

 

5

STUN(Session Traversal Utilities for NAT)

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

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

TURN(Traversal Using Relay NAT)

TURN是一个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。

6

TURN 和 STUN

STUN服务在查询出客户端所在IP和端口后,其所成功建立的连接是直接通过端与端之间的连接的。

TURN服务是通过TURN服务器(拥有公网地址)作为中间人进行转发,所以如果TURN服务速度比STUN慢,而且是需要消耗TURN服务器带宽。

 

6
相关文章!
  • 1486631713(1) WebRTC视频采集模块和数据流水线建立
    - 阅 837

    本文在深入分析WebRTC视频采集、SDP协商和VideoEngine源代码的基础上,重点研究其视频采集模块的实现,视频数据流水线的建立,和视频数据从采集到待编码的流向。

  • 0-1 WebRTC的模块处理机制
    - 阅 748

    本文在深入分析WebRTC源代码基础上,学习研究其模块处理机制的实现细节,从另一个角度理解WebRTC的技术原理。

  • 0 Web 前端实时化
    - 阅 490

    实时作为 H5 的核心思想之一,意味着便捷的交互体验、高效的网络传输、快速的交流和更多的机遇,但由于 Web 对于实时天然缺乏支持,传统的 Web 技术并不适合实时化场景。

  • 0 webrtc中的网络反馈与控制
    - 阅 1,471

    本文主要介绍WebRTC中网络反馈与控制的方法和策略。