作者：Philipp Hancke（原文链接）
翻译：刘通
原标题：What kind of TURN server is being used?
TURN作为WebRTC基础设施的重要一员，它负责帮助NAT穿透。但是使用它们有多频繁呢？以及使用情况可以告诉我们什么关于WebRTC开销的内容呢？
两星期以前，我的朋友Gustavo Garcia在推特上问有多少WebRTC通话是通过TURN传递的。因为我喜欢钻研数据，所以我回答了他，但是要想在140个字之内说明白很困难。所以我想要在这篇博文中回答以下几个问题：
# 失败率是多少？
# 通过TURN服务器传递的通话占比有多少？
# UDP，TCP和TLS TURN变体的相对占比是多少？
这些数据对于运行WebRTC平台或者决定开发优先顺序来说都至关重要。
首先，这些数据要如何测量？我们在appear.in运行rtcstats来进行这项工作，被提取出的一个特征就是类型，第一个有效ICE候选对的局部类型优先（local type preference）点击此处查看。
局部类型优先（RFC 5245）会根据浏览器实现特定的值。对于Chrome来说，值是2代表“TURN/UDP”，1是“TURN/TCP”，0是“TURN/TLS”。Firefox用5来表示TURN/UDP，0同时表示TURN/TCP和TURN/TLS。
在ICE连接正在进行或者已经完成的时候测量这些数据，但是因为有效的候选对也有可能改变，所以可能会存在潜在的错误来源。
失败率是多少？
“大数据”允许我们使用上千万条记录，这些都是用Chrome进行端到端通话产生的。
重新看一下我们去年的一篇文章，当时有多少通话失败了呢？
现在失败率大概是0.5%左右，看上去比上次要强。
通过TURN服务器传递的通话占比有多少，以及TURN/UDP，TURN/TCP和TURN/TLS TURN的相对占比是多少？
然后，有多少工作（且没有失败）的通话使用了TURN呢？让我们来对数据集稍微进行一点改动来只包括已连接的通话。
然后运行一个select：
显示的数据是有局地类型优先量是2的TURN/UDP有12.1%的通话，TURN/TCP有5%，0.5%的TURN/TLS。加在一起一共有17.7%的通话被传递，比我在推特上回答Gustavo的稍微多一点，因为在发现P2P和我们的SFU有一点差别之后我调整了一下数据。而且好像大家都比较喜欢饼状图，所以：
对我们的SFU重复进行一次分析
给我们的SFU进行一次同样的分析比较让人吃惊。因为直到最近Firefox才可以用ICE-TCP（Firefox 54），所以我们还是使用TURN服务器。
数据集现在只限于使用TURN的通话，这样可以更加方便的看出发生了什么。因为只有4%的SFU-通话最终使用的是TURN，所以数据集会更小一点。
最终结果是20%的中继通话使用TURN/UDP，78%的使用TURN/TCP，2%的使用TURN/TLS。为什么差距会这么大？
主要原因是我们的SFU是一个运行在互联网上的服务器，所以有很好的UDP连接性。还有，我们允许通过UDP进行的直接连接。意味着剩下20%TURN/UDP流量是从客户端来的，他们不可以直接连到SFU，而是需要通过监听UDP 443端口来通过TURN服务器进行连接。这就建议虽然有一些网络会屏蔽UDP随机端口，但是还是会允许在443端口上有UDP流量。这是我在进行数据钻研之后得到的一大惊喜。
