作者：Levent-Levi（原文链接）
翻译：刘通
你不会相信在TCP上的TURN会如何改变WebRTC在网络上的表现。
我之前在BlogGeek.me上写了一篇关于使用TURN以及不要依赖公共IP地址的重要性的文章。但是在那篇文章中没有包括的内容是，TCP上的TURN会如何改变WebRTC的表现，现在让我们来好好把它讲清楚。
这就是为什么我会坐下来花时间在APPRTC上，使用1080p分辨率的摄像头作为输入，通过testRTC来看我周围的网络状况，并且分析最终我们获得的实验报告。
我想与你们分享的是四种不同的网络情况：
#1—不存在丢包的P2P通话
首先让我们来分析这次比较的对比基线。是使用APPRTC，进行一对一的通话，处于没有网络损伤的情况，并且没有用到TURN。
哦，还有，我被迫在这里所有的通话中使用VP8。我们要将注意力放在视频状况上，因为其包含了更多的数据。
我们的输出比特率大概是2.5Mbps，输入比特率在2.3Mbps左右—这与我们在testRTC上做测试的时间有关。较长时间的通话中，上行下行的平均比特率都在2.5Mbps左右。
获得到的视频图标是这个样子的：
这些图标都是用作对照的。当我们分析其他情况时，我们会掉过头来再看这些图表。
我们所关注的参数主要是比特率，丢包，以及延迟。
#2—没有丢包的TCP上TURN通话
第一眼看，我更可能会忽视这一结果—直到我更深度的挖掘。我通过阻拦我们机器上所有的UDP传输，来强制让TCP产生延迟。
这次，我们获得了稍微低一点点的比特率—输出大约为2.4Mbps，输入大约2.2Mbps。
这可能是因为额外添加的TURN延迟，其网络以及配置—或者其他因为在媒体中使用的是TCP而不是UDP而产生的间接影响因素。
与之前不用TCP上的TURN相比，平均来回时间以及抖动值都有小幅度的升高—一个我们将媒体流强制延迟的代价。
下面的图表展现出了一些有意思的事情：
让我们先来看视频的比特率：
看黄色的部分。注意到视频输出的比特率逼输入比特率升高的要快的多吗？这种情况出现的可能原因有两种：
1）WebRTC发送数据的速度很快，但是这些这些数据会被网络驱动器给卡住—TCP尝试做一个好“公民”，在将数据都发送出去前一直在等着。但使用UDP的时候，WebRTC在评估可用比特率方面上会更加的有主动性（和准确性）。所以在输出上，WebRTC估计没有足够的比特率可以使用，但是在输入方面，TCP拖了所有人的后腿，将比特率提升到2.4Mbps用了30秒而不是我们平时用WebRTC时的小于5秒。
2）TURN服务器会接收这些数据，但是不知道为什么决定将其以较慢的速率发出。
我个人更倾向于第一个原因，但是如果你知道真正的原因的话我非常迫切想知道。
第二个有意思的地方是绿色的区域。在视频中这段有趣的“突起”，为什么会突然上升整整1Mbps然后之后又恢复了呢？这段突起也符合丢包的情况—但是这也十分奇怪—因为TCP并没有丢包的情况—它只是重新传送它们。
这很有可能是因为，在输出端比特流平稳之后，在可以继续之前有一些额外的数据被我们尝试加入到了信道中并且需要被传输。并且如果你一定要问的话—我又尝试了一个5分钟的通话，这种突起没有再出现。
最后，但不是不重要，我们得到了平均延迟的图表。其峰值达到了100ms，紧接降到了45ms左右。
把上面说的归纳一下：
TCP上的TURN使WebRTC通话在可用比特率上会更慢的达到稳定。
到现在，我们已经讨论了纯净传输通道上的通话。那么如果给传输通道这盘“沙拉”里面加一点“辣椒”又会发生什么呢？
#3—有0.5%丢包率的P2P通话
在下面两个部分中我们将要做的是模拟DSL连接，加入0.5%的丢包。首先，让我们回到P2P通话—没有任何形式上的强制使用TURN。
我们的比特率就像火箭一样上升了。因为0.5%丢包的影响，我们现在可以看到在同等情况下超过3Mbps的比特率。WebRTC看到了加入更多比特来解决网络问题的机会，于是它真的这么做了。因为我们没有再测试中真正的去限制它，所以看起来还是在正确工作范围内。
我又检查了一下我们屏幕上的图像—看起来还不错：
下面让我们来深入分析一下图表：
确实有丢包的存在，还伴随着更高的比特率以及轻微的更高的延迟。
#4—有0.5%丢包率的TCP上TURN的通话
现在我们用的是同样的配置，但是强制浏览器使用TCP上的TURN。
这就是我们得到的结果：
比特率要低于2Mbps，对比一下我们没有强制使用TURN时大约3Mbps的比特率。
当我们看到视频图表后，其丑陋的面目暴露了出来：
通话完全没有稳定。。。至少在这段90s内的通话中不稳定。
我想这主要是因为TCP的自身特性以及其是如何处理丢包的方法造成的。这也让我注意到了另外一点—丢包的图表看起来格外的“干净”。几乎就不存在丢包。这是因为TCP隐藏了丢包，而且TCP是重新传输数据，所以不会丢包。这还意味着我们使用的比特率远远的高于1.9Mbps—这对WebRTC来说是不可用的—而且大多数情况，这些“重新传输”不会帮到WebRTC解决问题，因为它们延迟的原因，及时可以起到帮助也太晚了。
我们看到了什么？
我尽量将这篇文章总结成两句话：
1 TCP对于WebRTC来说是必须要面对的邪恶力量
2 你会能不用就不用它的
