2

我想通过 WebRTC 数据通道发送单向流数据,并且正在寻找最佳配置选项(高带宽、低延迟/抖动)以及其他人在此类应用程序中预期比特率的体验。

我的测试程序发送 2k 的块,带有 2k 的 bufferedAmountLowThreshold 事件回调并再次调用 send 直到 bufferedAmount 超过 16k。在 Chrome 中使用它,我在 LAN 上实现了 ~135Mbit/s,从/到远程连接实现了 ~20Mbit/s,两端都有 100Mbit/s 的 WAN 连接。

这里的限制因素是什么?

如何查看数据是否真正直接点对点,或者是否使用了 TURN 服务器?

我的最终应用程序将使用 Android 上的 google-webrtc 库——我只使用 JS 进行原型设计。我可以在库中设置一些选项来加快比特率,而这是我在官方 JS API 中无法做到的吗?

4

1 回答 1

11

影响吞吐量的变量有很多,而且很大程度上取决于您如何衡量它。但我将列出一些我为增加 WebRTC 数据通道的吞吐量而进行的调整。

免责声明:我没有对 libwebrtc 进行这些调整,而是对我自己的名为RAWRTC的 WebRTC 数据通道库进行了这些调整,顺便说一下,它也可以为 Android 编译。但是,两者都使用相同的 SCTP 库,都使用一些 OpenSSL-ish 库和 UDP 套接字,所以所有这些都应该适用于 libwebrtc。

请注意,使用usrsctp的 WebRTC 数据通道实现在同一台机器上执行时通常受 CPU 限制,因此在测试时请记住这一点。使用 RAWRTC 的默认设置,我可以在 i7 5820k 上达到约 520 Mbit/s。根据我自己的测试,Chrom(e|ium) 和 Firefox 在默认设置下都能达到约 350 Mbit/s。

好吧,让我们深入研究调整...

UDP 发送/接收缓冲区大小

默认情况下,Linux 中 UDP 套接字的默认发送/接收缓冲区非常小。如果可以,您可能需要调整它。

DTLS 密码套件

大多数 Android 设备都有 ARM 处理器,但不支持硬件 AES。ChaCha20 通常在软件中表现更好,因此您可能更喜欢它。

(这是 RAWRTC 默认协商的,所以我没有将它包含在最终结果中。)

SCTP 发送/接收缓冲区大小

usrsctp(libwebrtc 使用的 SCTP 堆栈)的默认发送/接收窗口大小为 256 KiB,这太小了,无法以适度的延迟实现高吞吐量。理论最大吞吐量受限于mbits = (window / (rtt_ms / 1000)) / 131072. 因此,在默认窗口为window=262144和相当适中的 RTT 的情况下rtt_ms=20,您最终将获得 100 Mbit/s 的理论最大值。

实际最大值低于……实际上,远低于理论最大值(见我的测试结果)。这可能是 usrsctp 堆栈中的错误(请参阅sctplab/usrsctp#245)。

Firefox 中的缓冲区大小已增加(请参阅错误 1051685),但 Chrom(e|ium) 使用的 libwebrtc 中没有。

发布版本

优化级别 3 有所作为(呃!)。

消息大小

您可能想要发送 256 KiB 大小的消息。

除非你需要支持 Chrome < ??? (对不起,我目前不知道它落在哪里......),那么最大消息大小为 64 KiB(参见issue 7774)。

除非您还需要支持 Firefox < 56,在这种情况下,最大消息大小为 16 KiB(请参阅错误 979417)。

它还取决于您在暂停发送之前发送了多少(即缓冲区的高水位线),以及在缓冲区耗尽后何时继续发送(即缓冲区的低水位线)。我的测试表明,针对1 MiB的高水位标记并设置256 KiB的低水位标记会产生足够的吞吐量。

这减少了 API 调用的数量并可以增加吞吐量。

最终结果

在 RAWRTC 上使用优化级别 3 和默认设置使我达到了 ~600 Mbit/s。

基于此,将 SCTP 和 UDP 缓冲区大小增加到 4 MiB 使我进一步提高到 ~700 Mbit/s,一个 CPU 内核处于 100% 负载。

但是,我相信仍有改进的空间,但不太可能低调。


如何查看数据是否真正直接点对点,或者是否使用了 TURN 服务器?

about:webrtc在 Firefox 或Chrom(e|ium) 中打开chrome://webrtc-internals并查找所选的 ICE 候选对。或者使用 Wireshark。

于 2019-05-27T18:13:57.083 回答