我想通过 WebRTC 数据通道发送单向流数据，并且正在寻找最佳配置选项（高带宽、低延迟/抖动）以及其他人在此类应用程序中的预期比特率体验。
我的测试程序发送 2k 的块，带有 2k 的 bufferedAmountLowThreshold 事件回调并再次调用 send 直到 bufferedAmount 超过 16k。在 Chrome 中使用它，我在 LAN 上实现了 ~135Mbit/s，从/到远程连接达到 ~20Mbit/s，两端都有 100Mbit/s WAN 连接。
这里的限制因素是什么？
如何查看数据是否真正直接点对点传输，或者是否使用了 TURN 服务器？
我的最终应用程序将使用 Android 上的 google-webrtc 库 - 我只使用 JS 进行原型设计。我可以在库中设置一些选项来加快比特率，而这是我在官方 JS API 中无法做到的吗？
【问题讨论】：
标签： webrtc rtcdatachannel webrtc-android
影响吞吐量的变量有很多，而且很大程度上取决于您如何衡量它。但我会列出一些我为提高 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。
好的，让我们开始调整...
默认情况下，Linux 中 UDP 套接字的默认发送/接收缓冲区非常小。如果可以，您可能需要调整它。
大多数 Android 设备都有不支持硬件 AES 的 ARM 处理器。 ChaCha20 通常在软件中表现更好，因此您可能更喜欢它。
（这是RAWRTC默认协商的，所以我没有将它包含在最终结果中。）
usrsctp 的默认发送/接收窗口大小，libwebrtc 使用的 SCTP 堆栈，is 256 KiB 这太小了，无法以适度的延迟实现高吞吐量。理论最大吞吐量受mbits = (window / (rtt_ms / 1000)) / 131072 的限制。因此，使用window=262144 的默认窗口和rtt_ms=20 的相当适中的 RTT，您最终将获得 100 Mbit/s 的理论最大值。
实际最大值低于此值...实际上，远低于理论最大值（请参阅my test results）。这可能是 usrsctp 堆栈中的一个错误（请参阅sctplab/usrsctp#245）。
Firefox 中的缓冲区大小已增加（请参阅 bug 1051685），但 Chrom(e|ium) 使用的 libwebrtc 中没有。
优化级别 3 有所作为（呵呵！）。
您可能希望发送 256 KiB 大小的消息。
除非你需要支持 Chrome issue 7774）。
除非您还需要支持 bug 979417）。
这还取决于您在暂停发送之前发送了多少（即缓冲区的高水位标记），以及在缓冲区耗尽后继续发送的时间（即缓冲区的低位）水印）。我的测试表明，将 high water mark 设为 1 MiB 并将 low water mark 设置为 256 KiB 会产生足够的吞吐量。
这减少了 API 调用的数量并且可以增加吞吐量。
在 RAWRTC 上使用优化级别 3 和默认设置使我达到了 ~600 Mbit/s。
在此基础上，将 SCTP 和 UDP 缓冲区大小增加到 4 MiB，使我进一步提高到了 ~700 Mbit/s，一个 CPU 内核处于 100% 负载。
但是，我相信仍有改进的余地，但不太可能低调。
如何查看数据是否真正直接点对点传输，或者是否使用了 TURN 服务器？
在 Firefox 中打开 about:webrtc 或在 Chrom(e|ium) 中打开 chrome://webrtc-internals 并查找所选的 ICE 候选对。或者使用 Wireshark。
【讨论】：
usrsctp 吞吐量限制适用于每个 数据通道，而不适用于整个系统）。