我想通过WebRTC数据通道发送单向流数据，并且正在寻找最佳配置选项（高带宽，低延迟/抖动）以及此类应用中预期比特率的其他经验。
我的测试程序发送了2k的块，其中bufferedAmountLowThreshold事件回调为2k，并再次发送调用，直到bufferedAmount超过16k。在Chrome中使用此功能，我在局域网上实现了约135Mbit / s的速度，而从/到远程连接的两端实现了约20Mbit / s的速度，两端均具有100Mbit / s的WAN连接。
这里的限制因素是什么？
如何查看数据是否真的直接对等，或者是否使用TURN服务器？
我的最终应用程序将使用Android上的google-webrtc库-我仅使用JS进行原型制作。我可以设置选项来加快库中的比特率，而我在官方JS API中无法做到这一点？
答案 0 :(得分：3)
有许多影响吞吐量的变量，并且高度取决于您的测量方式。但是，我将列出一些为提高WebRTC数据通道的吞吐量而进行调整的事情。
免责声明：我尚未对libwebrtc进行这些调整，但对我自己的名为RAWRTC的WebRTC数据通道库进行了调整，顺便说一下，该库也为Android编译。但是，它们都在下面使用相同的SCTP库，都使用一些类似OpenSSL的库和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 rtt_ms=20，理论上您将获得100 Mbit / s的最大值。
实际最大值低于该最大值……实际上比理论最大值要低（请参阅my test results）。这可能是usrsctp堆栈中的错误（请参见sctplab/usrsctp#245）。
在Firefox中，缓冲区大小已增加（请参见bug 1051685），但在Chrom（e | ium）使用的libwebrtc中却没有。
优化级别3会有所不同（du！）。
您可能想发送256 KiB大小的消息。
除非您需要支持Chrome issue 7774）。
除非您还需要支持Firefox <56，否则最大邮件大小为16 KiB（请参阅bug 979417）。
这还取决于您在暂停发送之前发送了多少（即缓冲区的高水位标记），以及在耗尽缓冲区后继续发送的时间（即缓冲区的 low水印）。我的测试表明，将高水印设置为1 MiB，将低水印设置为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。