作者：Philipp Hancke（原文链接）
翻译：刘通
当亚马逊AWS在伦敦新开设了一个地区时，我们就马上在那里部署了一个新的TURN服务器。那么这与ICE候选收集时间有什么关系呢？
正如我之前的一篇博客中写的那样，ICE候选收集时间是对于通话建立时间而言一个很有用的替代值。它比通话建立时间要更容易观察因为其只由一个用户与TURN服务器之间的距离所决定，而不是两个用户各自的所处的位置。显然，这很大程度上取决于，以用户位置为参考你把TURN服务器部署在那里，这也让我在这种早些时候与别人产生了争论。这个时间也决定于你的用户是仅由TURN/UDP配置的，还是由TURN/TCP和TURN/TLS共同配置的，其中不开玩笑，TURN/TCP和TURN/TLS共同配置由于需要握手所以花费时间更长。
当我们在伦敦的新的AWS区域部署TURN服务器的时候，我想要验证一下我的一个假设：应该把TURN部署在尽可能低延时的地方。
在2016年11月以及12月上半月，每周的中位数都是基本稳定的，在225ms左右伴随更大的每日方差。在这期间，来自英国的用户都连入了Frankfurt数据中心。
在12月19日我们将TURN服务器部署在伦敦之后，收集时间降到了218ms。与此同时用户使用也因为节日季的原因而发生了重大的改变，这也影响了我们的数据，以及我们分析数据的能力。
在2017年1月的第一个星期中，收集时间降低到了198ms。这是一个好现象，但是使用情况还是没有回归正常。
1月9日被认为是使用情况恢复正常的第一天，收集时间大幅降低到了157ms。周二维持在155ms，周三165ms，周四149ms，周五158ms。其均值是155ms并且比之前的225ms要大幅降低。
而这仅因为我们部署了一个新的TURN服务器。这是一个提高服务质量事半功倍的方法。并且看起来，我们的用户也注意到了这点，自从我们部署了新的服务器后，appear.in在英国的使用量有了较高的增长。当然这有可能并没有关系，但总归是好事。
