Как отправить пакет UDP с веб-RTC - Javascript?

Как вы отправляете пакет UDP, используя Web RTC?

Источник

3 ответа

Решение

Вы должны проверить sipml5, http://code.google.com/p/sipml5/ получить код и заглянуть в папку: sipml5/src/tinySIP/src/transports

Источник

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

Вы можете отправить SRTP на хост с поддержкой ICE. Это, вероятно, не то, что вы ищете.

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

Это может звучать не так уж плохо, в конце концов, хосты в Интернете должны иметь возможность справиться с этим правом? Проблема заключается в том, что некоторые браузеры находятся в защищенных средах, где доступ к сети ограничен. В этих сетях некоторые хосты гораздо менее защищены, чем хост в общедоступном Интернете. Это было бы нормально, так как доступ к сети контролируется.

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

WebRTC отправляет только определенные типы пакетов UDP при определенных условиях. Если хост, с которым вы заинтересованы в общении, понимает ICE и способен использовать RTP с SRTP или SCTP через DTLS (маловероятно, что это происходит). Тогда, возможно, вы могли бы заставить браузер отправлять что-то.

Источник

@Martin Thomson очень хорошо объяснил проблему. Взяв мотивацию из его поста, этот пост может послужить руководством для некоторых гиков и новичков.

Говорят, что WebRtc Real-time, Bi-directional, Secureобщение между двумя и более сверстниками. Я больше сосредоточусь на слове: Безопасный .

Политики безопасности корпоративных сетей обычно требуют фильтрации входящего незапрошенного трафика , блокировки определенных протоколов , а также фильтрации и сканирования на уровне приложений.spam, malware, а также intellectual property.

Теперь на ум приходят два новых вопроса;

  1. Почему обход TCP не проблематичен?
  2. Почему обход UDP проблематичен?

Почему обход TCP не проблематичен?

TCP ясно указывает на две вещи;

  • Начало потока (SYN)а также,
  • Конец потока (FIN or RST).

Это используется брандмауэрами для openа также close дырочки . В исключительных случаях TCP-соединение, которое долгое время не получало трафика, также закрывается (чтобы приспособиться к изменениям топологии сети или отказу обоих узлов TCP). Брандмауэры также выполняют проверку протокола для устранения проблем с

  • TCP-сегменты вне окна и,
  • Перекрывающиеся сегменты TCP

Это позволяет брандмауэру защищать сеть и хосты от нескольких векторов атак (атаки повторного воспроизведения, зондирование IP-адреса хоста, DDOS-атаки и т. д.).

Почему обход UDP проблематичен?

Для потоков UDP первый исходящий пакет из 5-кортежа будет использоваться брандмауэром в качестве start-of-sessionиндикатор. Но UDP не имеет end-of-sessionиндикатор, поэтому брандмауэр имеет только two waysчтобы закрыть дырочку:

  • Время выхода пинхола после interior hostне отправляет трафик в течение нескольких секунд или
  • Внутренний хост генерирует фатальный ICMP error.

Поскольку нет надежного способа определить, что сеанс был остановлен, у брандмауэра гораздо более сложная задача. Он может реализовать шлюз уровня приложений. (ALG)и быть в курсе любой семантики, наложенной кодом более высокого уровня поверх UDP.

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

Использование ALG, брандмауэр может определить, когда вызов завершен, и закрыть все динамические сопоставления, созданные для мультимедийного сеанса. Но проблема заключается в передаче сигналов сеанса между приложением WebRTC, работающим в браузере, и веб-сервером, который может использовать TLS, и в этом случае ALG больше не имеет доступа к сигнализации.

Вывод:

Таким образом, на шлюзе уровня приложений Webrtc использует комбинацию SDPа также ICE. WebRtc в основном обертывается таким образом, что

  1. Для аудио и видео каналов WebRtc использует комбинации RTP, RTCP, SRTPнад DTLS.
  2. Для каналов данных webrtc использует протокол передачи управления потоком. (SCTP), определенный в RFC 2960 .

SCTP — это протокол транспортного уровня, который был задуман как альтернатива TCPили же UDP. Для WebRtc мы используем его как протокол прикладного уровня, который работает через наше соединение DTLS.

Эти протоколы также поставляются с некоторыми новыми протоколами, такими как STUN, TURN. Для основных реализаций WebRtc, пожалуйста, следуйте;

Я надеюсь, что это объяснение может помочь некоторым фанатам. Спасибо

Источник
Другие вопросы по тегам