WebRTC基本概念(一)

作者: Mr__C | 来源:发表于2016-06-12 00:39 被阅读1296次

    子曰:“不患无位,患 所以立;不患莫己,求 为可知也。”

    前言

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

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


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

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


    • ICE(Interactive Connectivity Establishment)框架

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


    当处于以上网络时,Peer和Peer之间基本都是通过NAT和防火墙连接上互联网的,所以当我们要建立两端之间的直接通信时,我们需要服务器对两端进行Signalling,具体如何进行Signalling会在下篇文章中介绍。本文假设两端已经Signalling完毕[1]
    ICE框架 (ICE会尝试找到端与端之间最优连接路径)会完成以下工作:
    • 首先ICE会直接利用主机地址和网卡地址进行连接,如果刚好端拥有公网IP(无NAT),那么此时可以直接建立连接。
    • 如果第一步失败,ICE会尝试建立STUN[2]连接。
    • 如果第二步失败,ICE会利用TURN[3]服务器建立连接。

    在本章中,我们只需要知道,ICE是一个提供了连接建立的服务框架。

    • STUN(Session Traversal Utilities for NAT)

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

    • TURN(Traversal Using Relay NAT)

    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。

    TURN 和 STUN
    STUN服务在查询出客户端所在IP和端口后,其所成功建立的连接是直接通过端与端之间的连接的。
    TURN服务是通过TURN服务器(拥有公网地址)作为中间人进行转发,所以如果TURN服务速度比STUN慢,而且是需要消耗TURN服务器带宽。


    1. WebRTC in the real world: STUN, TURN and signaling

    2. RFC5766

    3. RFC5389

    相关文章

      网友评论

      • j春雨:正计划学习这个,为啥不更新了?期待中
        Mr__C:@jcy_sls 已更新 :smile:
      • Monktan::+1:很不错
      • 郭克:正在学习wrt,

      本文标题:WebRTC基本概念(一)

      本文链接:https://www.haomeiwen.com/subject/gzledttx.html