2

将你的TURN服务器部署在与用户近的地方

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

作者:Philipp Hancke(原文链接

翻译:刘通

 

         当亚马逊AWS在伦敦新开设了一个地区时,我们就马上在那里部署了一个新的 TURN服务器。那么这与ICE候选收集时间有什么关系呢?

         正如我之前的一篇博客中写的那样, ICE候选收集时间是对于通话建立时间而言一个很有用的替代值。它比通话建立时间要更容易观察因为其只由一个用户与TURN服务器之间的距离所决定,而不是两个用户各自的所处的位置。显然,这很大程度上取决于,以用户位置为参考你把 TURN服务器部署在那里,这也让我在这种早些时候与别人产生了争论。这个时间也决定于你的用户是仅由 TURN/UDP配置的,还是由 TURN/TCP和 TURN/TLS共同配置的,其中不开玩笑, TURN/TCP和 TURN/TLS共同配置由于需要握手所以花费时间更长。

         当我们在伦敦的新的AWS区域部署 TURN服务器的时候,我想要验证一下我的一个假设:应该把 TURN部署在尽可能低延时的地方。

turn-close1

         在2016年11月以及12月上半月,每周的中位数都是基本稳定的,在225ms左右伴随更大的每日方差。在这期间,来自英国的用户都连入了Frankfurt数据中心。

         在12月19日我们将 TURN服务器部署在伦敦之后,收集时间降到了218ms。与此同时用户使用也因为节日季的原因而发生了重大的改变,这也影响了我们的数据,以及我们分析数据的能力。

         在2017年1月的第一个星期中,收集时间降低到了198ms。这是一个好现象,但是使用情况还是没有回归正常。

         1月9日被认为是使用情况恢复正常的第一天,收集时间大幅降低到了157ms。周二维持在155ms,周三165ms,周四149ms,周五158ms。其均值是155ms并且比之前的225ms要大幅降低。

         而这仅因为我们部署了一个新的 TURN服务器。这是一个提高服务质量事半功倍的方法。并且看起来,我们的用户也注意到了这点,自从我们部署了新的服务器后,appear.in在英国的使用量有了较高的增长。当然这有可能并没有关系,但总归是好事。





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

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