4

在哪里部署TURN(或者其他中继)服务器

已有 1,712 阅读此文人 - - NAT穿透 -

Philipp Hancke

        我在NoJitter上读到了一篇很有意思的文章,是讨论Cisco部署Spark的方法。通过把媒体服务器铺设在离用户近的数据中心内,Cisco希望所有参与用户的延迟都保证在150毫秒之内。

        仿照Dag-Inge的博客中讨论 TURN服务器决定连接设定时间,我也在考虑我们是不是也能通过连接时间的长短来告诉我们TURN服务器是部署在正确的地点,或者我们是否需要改善我们的部署状态。毕竟,就像我之前写过的,这类运行设备是WebRTC服务中最重要的方面之一。

        我们目前在appear.in的部署策略是基于负载的。在所有我们能够使用的AWS数据中心,我们都部署了至少一个 TURN服务器,检测着流量以及当一个实例太过于拥挤的情况下启用其他实例。之后我们通过路由器53来将客户路由到最近的 TURN服务器。

        但是这样部署到底有多快多高效呢?

        对于端到端的连接,从 TURN服务器收集中继候选所花费的时间可以非常好地体现client和 TURN服务器之间的往返时长。通过RTCPeerConnection.setLocalDescription调用和第一次icecandidate事件之间的延时来测量上面所说的时间。大概就像这样

turn1

        同时不会因为客户跨区域而影响。实时上,浏览器会要求 TURN服务器产生一个分配,返回一个未授权错误并且再次要求授权信任。所以这会来回进行两次往返(除非过程中发生了丢包)。在候选中的中继地址也给了我们关于所使用的中继服务器的参数。我们之前并没有收集它们,但是很容易添加的。

        因为数据中包括了很多异常值,所以我们只取5000毫秒内的数据:

turn2

        直觉上我们知道在用户近的地点运行 TURN服务器是非常合适的。需要注意的是,我们测量的是两个来回的路径,所以我们可以将其除二来粗略的估计端到端延时。

        我们可以利用这些指标来判断是否需要再部署另一个 TURN服务器来改善延时,或者我们是否需要再另一个数据中心内启用其他服务器。上图中的新加坡和孟买的数据中心就是两个例子。

        有一个奇怪的事情是,Firefox收集候选的延时要比Chrome多20毫秒。所以Firefox还是有空间来提升的。





加入WebRTC技术交流群,免费获得学习资料,交流经验
群号:659922087
q群
期待你一针见血的评论,Come on!

不用想啦,马上 "登录"  发表自已的想法.