WebRTC DataChannel поток/управление/противодавление

RTCDataChannel API не обеспечивает никакого потока/управления или противодавления. Значит ли это, что отправитель теоретически может привести к сбою браузера получателя? По моему мнению, браузер (Chrome, Firefox и т. д. все используют SCTP под капотом) считывает из SCTP-соединения и планирует запуск js-обратного вызова, потребляющего пакет. Если очередь событий не может не успевать за отправителем, браузер в основном непрерывно читает пакеты, сохраняя пакеты в буфере, который увеличивается на неопределенный срок. Таким образом, когда вы подключаете два браузера, отправитель фактически всегда может подавлять другой, потому что нет барьера, такого как окна приема TCP или что-то подобное.

Это относится и к websocket api.

Я просто что-то пропустил или эти API просто сломаны? Если я прав, это будет серьезной проблемой безопасности при общении с браузерами, не прошедшими проверку подлинности (например, в сценарии торрента).


javascript websocket webrtc backpressure flow-control
person Kr0e    schedule 21.11.2014    source источник
comment
Я бы ПРЕДПОЛОЖИЛ, что базовый код в браузере примет это во внимание, но вы знаете, что происходит, когда вы делаете предположение...   -  person Benjamin Trent    schedule 21.11.2014
comment
К вашему сведению: наоборот, тоже возникают проблемы. Если вы попытаетесь отправить данные, вы можете отправить их как можно быстрее. Данные буферизуются внутри. Но в какой-то момент у вас закончится память, потому что сеть не может справиться с буферизованными данными. WebRTC предлагает информацию о размере буфера, но это означает, что вы должны опрашивать эту переменную, чтобы поддерживать размер буфера в пределах верхнего и нижнего водяных знаков. Сумасшедший... Это кажется просто сломанным (или, по крайней мере, не до конца продуманным)   -  person Kr0e    schedule 21.11.2014

Ответы (1)


arrow_upward
3
arrow_downward

Канал данных webrtc раньше был основан на UDP. В течение этого времени браузер искусственно навязывал дросселирование, чтобы предотвратить переполнение сети. Так было до chrome v32, я полагаю.

В настоящее время канал данных основан на SCTP со встроенным управлением потоком (FC) и больше нет дросселирования браузера (слава Богу). Параметры, управляющие FC, не доступны через API, но это не означает, что FC нет.

Я не знаком с реализацией webrtc в Chrome/FF, но я не думаю, что вы можете сломать браузер простой атакой флуда. Производитель быстрее, чем потребитель — довольно старая проблема.

Тем не менее, я работаю с каналом данных уже более года и почти ежедневно вижу, как мой браузер вылетает из строя, поэтому, вероятно, в реализации webrtc много ошибок. Надеюсь, они не будут представлять никакой угрозы для безопасности.

Отправка больших кусков данных с использованием канала данных webrtc не особенно приятна. API не предлагает обратный вызов канала готов к записи или что-то в этом роде, поэтому да!, вы должны опросить значение bufferedamount и попытаться удержать его в оптимальном окне. Чтобы добавить оскорбление к травме, bufferedamount раньше не работал в версиях Chrome для Windows, он всегда был 0. Но я думаю, что они исправили это в chrome v37 или примерно в то же время.

ИМХО, API-интерфейс webrtc не очень хорошо продуман, но он выполняет свою работу, и, честно говоря, я не могу придумать ни одного хорошо продуманного API-интерфейса js.

person Svetlin Mladenov    schedule 23.11.2014
comment
Я понимаю. Насколько я могу судить, реализация SCTP определенно способна управлять потоком, но она применяется только к ядру браузера. Если ядро ​​браузера недостаточно быстрое для чтения, тогда да. Но браузер ДОЛЖЕН продолжать чтение, поскольку каждый канал данных, подключенный к одному и тому же хосту, мультиплексируется одним соединением SCTP. Таким образом, браузер не может сказать, для какого канала данных предназначен следующий пакет. - person Kr0e; 23.11.2014
comment
Представьте себе приложение, которое открывает канал данных и позволяет пользователю выбрать каталог для хранения данных. Если пользователь ждет, другая сторона должна иметь возможность непрерывно отправлять данные, которые должны обрабатываться приложением js. Приложение не может сказать "стоп!" Я надеюсь, что они действительно думают об этом вопросе в более поздней версии. - person Kr0e; 23.11.2014
comment
Если производитель бездумно просто отправляет данные, а потребитель не может их использовать по какой-либо причине, буферы с обеих сторон начнут увеличиваться. Однако буфер на стороне отправки не может увеличиваться бесконечно. После определенного порога (думаю, это была пара мегабайт) канал данных будет принудительно закрыт, а все буферизованные данные отброшены. - person Svetlin Mladenov; 23.11.2014
comment
Извините, мой пример был немного неполным. Производитель отправляет как можно быстрее без буферизации. Я утверждаю, что потребительский браузер будет читать данные и передавать их обратному вызову js. Обратный вызов js должен решить, что делать. Когда оно все еще ожидает действий пользователя, приложение должно буферизовать данные или замедлить производитель. И это моя точка зрения. Любое приложение, основанное на таком поведении, в корне ошибочно. Или давайте представим, что потребитель должен получить запрос к базе данных. Эта проблема повлияет на любой сценарий запроса‹-›ответа. - person Kr0e; 23.11.2014