Есть много переменных, которые влияют на пропускную способность, и это также сильно зависит от того, как вы ее измерили.Но я перечислю несколько вещей, которые я настроил для увеличения пропускной способности каналов данных WebRTC.
Отказ от ответственности: я не делал эти корректировки для libwebrtc, но для моей собственной библиотеки каналов данных WebRTC под названием RAWRTC, который, кстати, также компилируется для Android.Однако оба используют одну и ту же библиотеку SCTP, оба используют некоторую библиотеку OpenSSL-ish и UDP-сокеты, поэтому все это должно быть применимо к libwebrtc.
Обратите внимание, что реализации канала данных WebRTC с использованием usrsctp обычно связаны с процессором, когда выполняются на одной машине, так что имейте это в виду при тестировании.С настройками RAWRTC по умолчанию я могу достичь ~ 520 Мбит / с на моем i7 5820k.Исходя из моих собственных тестов, и Chrom (e | ium), и Firefox смогли достичь ~ 350 Мбит / с с настройками по умолчанию.
Хорошо, так что давайте углубимся в настройки ...
UDPРазмер буфера отправки / получения
По умолчанию буфер отправки / получения UDP-сокетов в Linux довольно мал.Если вы можете, вы можете настроить его.
DTLS Cipher Suites
Большинство устройств Android имеют процессоры ARM без аппаратной поддержки AES.ChaCha20 обычно лучше работает в программном обеспечении, и поэтому вы можете предпочесть его.
(Это то, что RAWRTC согласовывает по умолчанию, поэтому я не включил его в конечные результаты.)
SCTP Send/ Размер буфера приема
Размер окна отправки / получения по умолчанию: usrsctp, стек SCTP, используемый libwebrtc, равен 256 КиБ , что слишком мало для достижения высокой пропускной способности при умеренной задержке.Теоретическая максимальная пропускная способность ограничена mbits = (window / (rtt_ms / 1000)) / 131072.Итак, с окном по умолчанию window=262144 и довольно умеренным RTT rtt_ms=20 вы получите теоретический максимум 100 Мбит / с.
Практический максимум ниже этого ... на самом деле, ниже теоретического максимума (см. мои результаты теста ).Это может быть ошибка в стеке usrsctp (см. sctplab / usrsctp # 245 ).
Размер буфера был увеличен в Firefox (см. bug 1051685 ), ноне в libwebrtc, используемом Chrom (e | ium).
Release Builds
Уровень оптимизации 3 имеет значение (дух!).
Размер сообщения
Вы, вероятно, хотите отправлять сообщения размером 256 КБ.
Если вам не нужна поддержка Chrome <???(извините, в настоящее время я не знаю, где он приземлился ...), тогда максимальный размер сообщения составляет 64 КБ (см. <a href="https://bugs.chromium.org/p/webrtc/issues/detail?id=7774" rel="nofollow noreferrer"> выпуск 7774 ).
Если вам не требуется поддержка Firefox<56, и в этом случае максимальный размер сообщения составляет 16 КиБ (см. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=979417" rel="nofollow noreferrer"> ошибка 979417 ).
Это также зависит от того, сколько вы отправляете перед тем, как приостановить отправку (то есть буфер максимальная отметка воды ), и когда вы продолжаете отправку после того, как буфер опустошен (то есть, отметка минимальной отметки буфера ).Мои тесты показали, что нацеливание на отметку максимальной воды в 1 МБ и установление отметки низкой воды в 256 КиБ приводит к достаточной пропускной способности.
Это уменьшает количествоВызовы API и могут увеличить пропускную способность.
Конечные результаты
Использование уровня оптимизации 3 с настройками по умолчанию в RAWRTC привело меня к ~ 600 Мбит / с.
Исходя из этого, увеличение размеров буфера SCTP и UDP до 4 МБ позволило мне подняться еще до ~ 700 Мбит / с с одним ядром процессора при 100% нагрузке.
Однако я считаю, что еще есть местодля улучшений, но это вряд ли будет зависать.
Как я могу узнать, действительно ли данные будут одноранговыми напрямую, или используется сервер TURN?
Откройте about:webrtc в Firefox или chrome://webrtc-internals в Chrom (e | ium) и найдите выбранную пару кандидатов ICE.Или используйте Wireshark.