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

作者: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 中文社区由

运营