什么可能导致webrtc数据通道消息中的这个> 1000ms滞后?

use*_*661 9 javascript network-programming lag webrtc

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

案例1:仅发送/接收

当我设置一侧发送测试消息时,间隔为例如70ms,我看到它们在另一侧进入而没有明显的延迟.每个收到的消息之间的时间接近70毫秒.到现在为止还挺好.

案例2:双方轮流发送和接收

当我安装双方尽快发送消息,因为它收到来自对方的消息,这是超过70ms的前自去年发送,一切都很好,除了有时.每隔几秒钟(不一致)我测量~1000ms的延迟.奇怪的是,绝大多数消息之间的时间是<200ms OR> ~1000ms.


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

可能是什么导致了这个?在我看来,它可以修复,因为在一个方向(任一方向)发送工作正常没有滞后.我也尝试使用单独的数据通道进行发送/接收,这无关紧要.


例子

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

(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" 
Run Code Online (Sandbox Code Playgroud)

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

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]

我仍然没有弄清楚导致这种滞后的原因.我希望图表更平滑.

use*_*661 2

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

我注意到,当两个对等方以 70 毫秒的间隔向对方发送数据包且不等待对方发送的数据包时,不会出现任何问题。一旦我在等待传入数据包时延迟发送数据包,就会出现 >1000 毫秒的延迟。

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