Канал данных WebRTC для приложений с высокой пропускной способностью

Есть много переменных, влияющих на пропускную способность, и она также сильно зависит от того, как вы ее измерили. Но я перечислю пару вещей, которые я настроил для увеличения пропускной способности каналов данных WebRTC.

Отказ от ответственности: я сделал эти настройки не для libwebrtc, а для моей собственной библиотеки каналов данных WebRTC под названием RAWRTC, которая, кстати, также компилируется для Android. Тем не менее, оба используют одну и ту же библиотеку SCTP внизу, оба используют некоторую библиотеку OpenSSL и сокеты UDP, поэтому все это должно быть применимо к libwebrtc.

Обратите внимание, что реализации канала данных WebRTC с использованием usrsctp обычно привязаны к ЦП при выполнении на одном компьютере, поэтому имейте это в виду при тестировании. С настройками RAWRTC по умолчанию я могу достичь ~ 520 Мбит / с на моем i7 5820k. По моим собственным тестам, и Chrom(e|ium), и Firefox смогли достичь ~350 Мбит/с с настройками по умолчанию.

Итак, приступим к настройкам...

Размер буфера отправки/получения UDP

Буфер отправки/получения UDP-сокетов по умолчанию в Linux по умолчанию довольно мал. Если вы можете, вы можете настроить его.

Наборы шифров DTLS

Большинство устройств Android имеют процессоры ARM без аппаратной поддержки AES. ChaCha20 обычно работает лучше в программном обеспечении, поэтому вы можете предпочесть его.

(Это то, что RAWRTC согласовывает по умолчанию, поэтому я не включил это в конечные результаты.)

Размер буфера отправки/получения SCTP

Размер окна отправки/получения по умолчанию для usrsctp, стека SCTP, используемого libwebrtc, составляет 256 КиБ, который слишком мал для достижения высокой пропускной способности с умеренной задержкой. Теоретическая максимальная пропускная способность ограничена mbits = (window / (rtt_ms / 1000)) / 131072. Таким образом, с окном по умолчанию window=262144 и довольно умеренным RTT rtt_ms=20 вы получите теоретический максимум 100 Мбит/с.

Практический максимум ниже этого... на самом деле намного ниже теоретического максимума (см. мои результаты теста). Это может быть ошибка в стеке usrsctp (см. sctplab/usrsctp#245).

Размер буфера был увеличен в Firefox (см. ошибка 1051685), но не в libwebrtc, используемом Chrom(e|ium).

Выпуск сборок

Уровень оптимизации 3 имеет значение (да!).

Размер сообщения

Вероятно, вы хотите отправлять сообщения размером 256 КиБ.

Если вам не нужно поддерживать Chrome < ??? (извините, в настоящее время я не знаю, куда оно попало...), то максимальный размер сообщения составляет 64 КиБ (см. выпуск 7774).

Если вам также не требуется поддержка Firefox < 56, в этом случае максимальный размер сообщения составляет 16 КиБ (см. ошибка 979417).

Это также зависит от того, сколько вы отправляете до того, как приостановите отправку (т. е. высокая отметка уровня воды буфера), и когда вы продолжите отправку после опустошения буфера (т. е. отметка низкого уровня воды буфера). Мои тесты показали, что установка высокая отметка уровня воды на 1 МБ и установка отметка низкого уровня воды на 256 КиБ дают адекватную пропускную способность.

Это уменьшает количество вызовов API, а могу увеличивает пропускную способность.

Конечные результаты

Использование уровня оптимизации 3 с настройками по умолчанию на RAWRTC увеличило скорость до ~600 Мбит/с.

Исходя из этого, увеличение размеров буфера SCTP и UDP до 4 МБ увеличило скорость до ~ 700 Мбит/с при загрузке одного ядра ЦП на 100%.

Тем не менее, я считаю, что еще есть возможности для улучшений, но вряд ли они будут незначительными.

How can I see if the data is truly going peer to peer directly, or whether a TURN server is used?

Откройте about:webrtc в Firefox или chrome://webrtc-internals в Chrom(e|ium) и найдите выбранную пару кандидатов ICE. Или используйте Wireshark.