javascript - 是什么导致 webrtc 数据通道消息出现这种 >1000 毫秒的滞后？

Question

当我在 2 个浏览器之间设置数据通道时(在同一网络上的 2 台不同机器上进行测试)，在以下 2 种情况下，我得到了关于延迟的不同结果。

情况一:只发送/接收

当我将一侧设置为以例如 70 毫秒的间隔发送测试消息时，我看到它们从另一侧传入，没有明显的延迟。每条收到消息之间的时间接近 70 毫秒。到目前为止一切顺利。

情况2:双方轮流发送和接收

当我将双方设置为在收到来自另一方的消息后立即发送消息并且自上次发送以来已超过 70 毫秒时，一切正常，但有时除外。每隔几秒(不一致)，我测量到约 1000 毫秒的延迟。奇怪的是，绝大多数消息之间的时间要么 < 200 毫秒要么 > ~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

虽然我仍然不确定是什么导致了这个问题，但我已经找到了解决方案。我最好的猜测是，当其中一个对等方有一段时间没有发送数据(或者他们只是没有到达另一个)时，问题是由流量控制引起的。

我注意到当两个对等点以 70 毫秒的间隔向对方发送数据包时没有问题，当他们不等待来自对方的数据包时。一旦我在等待传入数据包时延迟发送数据包，就会出现 >1000 毫秒的延迟。

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