什么可能导致webrtc数据通道消息中的＆gt; 1000ms滞后？

Question

当我在两个浏览器之间设置数据通道（在同一网络上的两台不同机器上进行测试）时，在以下两种情况下，我得到的滞后结果不同。

案例1：仅发送/接收

当我设置一侧发送测试消息时，间隔为例如70ms，我看到它们在另一侧进入而没有明显的延迟。每个收到的消息之间的时间接近70毫秒。到目前为止一切都很好。

案例2：双方依次发送和接收

当我设置双方在收到来自另一方的消息后立即发送消息并且距离上次发送超过70ms之前，一切都很顺利，有时除外。每隔几秒钟（不一致）我测量~1000ms的延迟。奇怪的是，绝大多数消息之间的时间要么是＆lt; 200ms OR> 〜1000毫秒。

我测试了chrome和firefox（组合）中的两个案例，行为类似。我还在移动电话网络（使用网络共享）上进行了测试，虽然频率较低，但仍显示相同的延迟。数据通道未配置任何特殊选项，因此它使用可靠的有序连接。

可能导致这种情况的原因是什么？在我看来，它可以修复，因为在一个方向（任一方向）发送工作正常没有滞后。我也尝试使用单独的数据通道进行发送/接收，这无关紧要。

实施例

以下是第二种情况的测试结果示例。这是1000次往返的所有往返时间列表，高于200毫秒。

(Delay index) round trip time - round trip number - time
(0) 2192 - 0 - "2016-05-06T12:34:18.193Z"
(1) 1059 - 111 - "2016-05-06T12:34:22.777Z"
(2) 1165 - 372 - "2016-05-06T12:34:32.485Z"
(3) 1062 - 434 - "2016-05-06T12:34:35.585Z"
(4) 1157 - 463 - "2016-05-06T12:34:37.598Z"
(5) 1059 - 605 - "2016-05-06T12:34:43.264Z"
(6) 1160 - 612 - "2016-05-06T12:34:44.633Z"
(7) 1093 - 617 - "2016-05-06T12:34:45.857Z"
(8) 1158 - 624 - "2016-05-06T12:34:47.204Z"
(9) 1162 - 688 - "2016-05-06T12:34:50.401Z"
(10) 1158 - 733 - "2016-05-06T12:34:52.962Z"
(11) 1161 - 798 - "2016-05-06T12:34:56.163Z"
(12) 1157 - 822 - "2016-05-06T12:34:58.077Z"
(13) 1158 - 888 - "2016-05-06T12:35:01.281Z"
(14) 1160 - 893 - "2016-05-06T12:35:02.563Z"
(15) 1085 - 898 - "2016-05-06T12:35:03.768Z" 

这是另一个例子，包括来自chrome：// webrtc-internals的'PacketsSentPerSecond'图：

在此测试中，发送了大约2100个数据包，导致以下26次往返超过900毫秒： [1762.6050000000014, 1179.7200000000012, 1765.375, 1149.945000000007, 1180.1399999999994, 1180.9550000000017, 1246.2450000000026, 1750.2649999999994, 1388.0149999999994, 1100.7499999999854, 4130.475000000006, 1160.1150000000052, 1082.4399999999878, 1055.2300000000105, 1498.715000000011, 1105.8850000000093, 1478.1600000000035, 2948.649999999994, 1538.2549999999756, 1839.9099999999744, 1768.6449999999895, 1167.929999999993, 1139.1750000000175, 1173.8850000000093, 1245.6600000000035, 1075.375]

我仍然没有弄清楚导致这种滞后的原因。我期待更平滑的图表。

Answer 1

虽然我仍然不确定导致问题的原因，但我找到了解决方案。我最好的猜测是，当其中一个对等体暂时不发送数据（或者它们只是没有到达另一个）时，问题是由流量控制引起的。

我注意到当两个对等体以70ms的间隔向彼此发送数据包时，当它们不等待彼此的数据包时，没有问题。一旦我在等待传入数据包时延迟发送数据包，我就会得到> 1000ms的滞后。

所以我现在所做的实际上是以稳定的速率发送数据包，如果它们是空的。我的应用程序需要依次发送数据，但我只是检查是否有任何要发送的内容，如果没有，我仍然发送一个空数据包。这样，问题似乎在我到目前为止的测试中得到了解决！

Answer 2

也许这与人们讨论的1000毫秒滞后有关？ （像这样setTimeout/setInterval 1000ms lag in background tabs (Chrome and Firefox)）

您将发送间隔配置为70毫秒，这是一个相对较小的间隔。你试过使用更大的间隔吗？此外，您可能还想使用WebRTC iOS或Android本机解决方案进行一些测试，以便您可以知道问题是来自核心WebRTC实现（似乎不太可能），还是某些浏览器限制。

Answer 3

我几乎可以肯定这是由您的TURN服务器引起的。 我在上个月做了一个非常相似的测试，所有的数据包都是通过TURN（使用我们自己的TURN服务器）在几毫秒内收到的。测试是在Firefox和Chrome上完成的。