做WebRTC,千万别把媒体和信令混在一起

原作者:Tsahi Levent-Levi(原文链接

翻译:刘通

原标题:With WebRTC, Don’t Never Ever Mix Media and Signaling

 

dont-mix1

         如果你想使用WebRTC做一个运行稳定并且足够好的产品,你就必须把下面这三个实体分开。让我们来一一分析。

 

信令服务器

         我们每一个人的WebRTC产品中一定都有信令服务器。

         这是为什么呢?

         因为没有信令服务器,就没有网络通话。完全进行不了任何通话,甚至连简单的Hello World都完成不了。答案就是这么简单。

         你可以将信令服务器和你的应用服务器配置在一起。

         下面这些关于服务器的特点你可能已经知道了:

#1 你可以配置一个服务器来平行地处理1000个,甚至100,000个连接和会话。

#2 这些服务器必须有所连接用户的状态,以保证它们很难超出容量范围。

#3 通常,这些服务器所作出的决定是依据外部数据库得出的。

#4 几百毫秒的延迟对于这些服务器来说是可以接收的,但是但是如果没有正确的设计和实施的话,它很容易出错

         另外信令服务器还是用高层语言编写的,比如Java,Node.js,Rails,Python,PHP(我的天啊)等等。

 

NAT穿越服务器

         我在这里说的是STUN和TURN。

         而且是的,通常我们会把STUN“塞”到TURN中去。在这二种之中,TURN是一头占用资源的巨兽,但是STUN可以被依附到同一个服务器上,因为STUN和TURN的目的是一样的(以合适的方式获取媒体流)。

         这就是我为什么在这里忽略STUN而只是将注意力集中在TURN上的原因。

         有的时候人们会忘记TURN。他们之所以会忘记的原因是WebRTC在两个浏览器标签页之间,或者同一个办公室的两个同事之间运行的很好。这是因为这两个场景根本不需要用到TURN。然后他们就把产品发出去了。后果可想而知。

         TURN作用是在会话参与方无法直接连接其他参与者的时候,在他们之间传递媒体。这种传递机制的两个特点:

#1 TURN会吞噬掉大量的带宽资源。

#2 你要做的是尽可能将你的TURN服务器部署在参与方附近。这是从TURN服务器出发提高媒体质量、降低延时的唯一方法。而你会对网络有更多的控制。

         尽管你有可能不需要用很多TURN服务器,但是你最好还是从你使用的云服务提供商那里办一个。

         我所知的绝大多数NAT穿越服务器都是用C/C++编写的。

 

媒体服务器

         媒体服务器不是必需的。媒体服务器其实并不是规范的一部分—只是用来满足你的一些特定功能的。群组通话和录音就是一个好例子,基本上都是要通过媒体服务器才能进行传输的。

         但是问题是,相比于WebRTC所需的其他服务器,媒体服务器所消耗的资源要多的多。

         而且媒体服务器的规范与其他服务器都不一样。这就是为什么大多数情况下都把媒体服务器“隔离”安放的原因。

         可以将媒体服务器和TURN服务器配置在一起。但是我大多数情况下不赞成这种做法,因为相比于媒体服务器,TURN更要面向网络。而且我现在还没听说过有黑客攻击过媒体服务器,我觉得这可能只是一个时间早晚问题。

         媒体服务器通常是用C/C++编写的。

        

为什么要将他们分开?

         因为他们彼此互不相同。

dont-mix2

         它们有不同的工作。

         而且他们需要被设置在不同的地方。

         所以逻辑上要把它们分开配置,而且准备好在需要的时候也要在现实将它们分开。

填写常用邮箱,接收社区更新

WebRTC 中文社区由

运营