что такое webrtc в браузере

Что такое WebRTC и как это отключить

WebRTC (сокращенно от Web real-time communications) – это технология, которая позволяет передавать аудио и видео потоковые данные между браузерами и мобильными приложениями.

Разработка этой технологии составляет конкуренцию Skype. WebRTC можно использовать для организации видеоконференций напрямую в браузере. Проект имеет открытый исходный код и активно продвигается компанией Google и в частности командой разработки браузера Google Chrome.

Как работает WebRTC

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

Технология WebRTC поддерживается всеми популярными браузерами Mozilla Firefox, Opera, Google Chrome (и всеми браузерами на базе Google Chrome), а также мобильными приложениями на базе Android и iOS.

Опасность WebRTC

Опасность технологии WebRTC заключается в определении вашего реального IP адреса. Так как подключение идет напрямую с другим пользователем, браузером, веб-сайтом или мобильным приложением, то настройки сети игнорируются. Для создания аудио и видеосвязи браузеры должны обменяться внешними и локальными IP адресами.

Анонимный VPN сервис решает данную проблему и скрывает реальный IP адрес. Максимум, что может быть обнаружено – это локальный IP адрес, присвоенный пользователю VPN сетью. Это не опасно, так как такие же локальные IP адреса будут показываться, если вы используете роутер для раздачи Интернета.

Если вы используете прокси, тогда WebRTC сможет определить ваш реальный IP адрес за прокси или IP адрес VPN сервера, если вы используете цепочку VPN + прокси.

WebRTC также определяет ваш реальный IP адрес при использовании сети Tor.

Самое лучшее решение – отключить технологию WebRTC, если вы этим не пользуетесь.

Источник

WebRTC #1 — Знакомимся

Многие уже слышали о проекте WebRTC, некоторые даже используют его (или пытаются применять в существующих проектах), а кто-то злобно потирает руки, предвкушая постепенную расправу со Skype и Flash.

Погуглив в Хабре (хе-хе) я почему-то не нашел статей, которые углублялись в техническую сторону WebRTC, показывали бы примеры его использования.

Что же, я попытаюсь порадовать вас схемками, кодом. В общем, именно тем, что всем по вкусу. Так пройдем же под кат, мой любимый читатель.

Что это?

По сути, WebRTC являет собой:
1. Media Streams (getUserMedia).
2. Peer Connection.

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

Media Streams

Media Streams — API, позволяющий получить доступ к камере и микрофону через браузер без каких-либо плагинов и флеша.

Следуя WebRTC Public API, нам нужно использовать метод getUserMedia у глобального объекта navigator.
Передавать стоит три параметра:
— объект со списком того, что нам нужно (аудио/видео)
— success callback
— error callback

И пока что есть необходимость в костылях из-за наличия префиксов в различных браузерах:

Браузер мило попросит разрешения.

Ура! Мы получили Stream-объект с аудио и видео. И что же с ним делать?
Можем показать это дело юзеру используя html5 тег «video».

И немножко сахара. Теперь можно смело применять html5 фильтры (webkit) к видео элементу.

Клево, не правда ли?

Peer Connection

Peer Connection — это тот самый API, который позволяет установить Peer-to-Peer соединение между браузерами.

Ниже представлена упрощенная схема соединения между двумя клиентами.

— Первый клиент отправляет так называемый Offer второму клиенту через сервер (PeerConnection Observer).
— Второй клиент (Remote Peer) отправляет через сервер ответ первому клиенту.
— Устанавливается P2P соединение между клиентами.

Примечательно, что в дальнейшем для работы такого соединения сервер становится опциональным. Т.е. после его выключения данные все также будут передаваться. Дальнейшее участие PeerConnection Observer’а нужно для правильного закрытия соединения, добавления участников в поток и т.п.

В спецификации указан конструктор RTCPeerConnection, но пока что мы вынуждены использовать префиксы для различных браузеров:

Здесь пора бы уже и server side рассматривать, но хочется оставить первую статью более обзорной.

Недостатки

Продолжая «осмотр», нужно отметить темную сторону проекта:
1. API изменяется, т.к. проект находится на стадии активной разработки. Следовательно, иногда придется менять свой код.
2. До утверждения аудио и видео кодеков, возможны проблемы с кроссплатформенностью.
3. Кроссбраузерность. Имеем такую картину:

Зачем тогда это все?

Думаю, в недалеком будущем мы все же получим стабильный WebRTC API в современных браузерах. Это откроет невероятные возможности в веб разработке. Интересуясь этим проектом уже сейчас, можно будет намного быстрее вникнуть и начать использовать его потом.
И никто не отменял рассчитанные на определенный браузер (Chrome Stable, к примеру) проекты. Да и интересно же, правда?

Дальше — больше

Заканчивая первую часть цикла статей, хотелось бы составить примерный план:
1. WebRTC #1 — Знакомимся
2. WebRTC #2 — Media Streams
3. WebRTC #3 — Peer Connection: Server Side
4. WebRTC #4 — Peer Connection: Client Side
5.…

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

UPD: спасибо GeorP и egobrain за замечания.

Источник

Что такое WebRTC?

WebRTC (Web Real Time Communications) — это стандарт, который описывает передачу потоковых аудиоданных, видеоданных и контента между браузерами (без установки плагинов или иных расширений) или другими поддерживающими его приложениями в режиме реального времени. Данная технология позволяет превратить браузер в оконечный терминал видеоконференцсвязи. Чтобы начать общение, достаточно просто открыть веб-страницу конференции.

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

Содержание

Примеры сервисов, использующих WebRTC

TrueConf Server — отечественная ВКС платформа, основанная на современной масштабируемой архитектуре SVC, работает как в локальных сетях, так и через Интернет. Сервер вебинаров разворачивается на оборудовании вашей компании, что гарантирует защиту персональных данных от доступа третьих лиц. Благодаря высокому разрешению видео (до 4К) и инструментам для совместной работы прекрасно подходит для трансляций онлайн-мероприятий, дистанционного образования и удаленной работы.

Google Meet

Google Meet — сервис мгновенного обмена сообщениями, а также проведения видео- и аудиозвонков, выпущенный в 2017 году компанией Google. В браузерах, основанных на Chromium (Google Chrome и др.) используется много скрытых возможностей WebRTC, которые не описаны в документации и периодически появляются первыми в его решениях для Meet (как и в его предшественнике Hangouts). Так было с захватом экрана, размытием фона, поддержкой аппаратного кодирования на некоторых платформах.

Jitsi Meet

Jitsi Meet — приложение с открытым исходным кодом, выпущенное компанией 8×8. Технология Jitsi основана на архитектуре Simulcast, что означает нестабильную работу на слабых каналах связи и высокие требования к скорости подключения на стороне сервера. Позволяет проводить веб-конференции только в браузере и не имеет полноценных клиентских приложений для совместной работы, поддержаны конференции с количеством участников не более 75 (до 35 с высоким качеством связи). Для полноценного использования Jitsi в корпоративной среде необходима самостоятельная разработка и установка дополнительного ПО.

BigBlueButton

BigBlueButton – это свободное программное обеспечение для видеоконференцсвязи. Особый акцент разработчики делают на дистанционном образовании (присутствуют такие функции как интерактивная доска, показ контента, поддержка опросов и т. п.). Поддерживает веб-конференции до 100 участников.

А что насчёт Zoom

Как работает WebRTC

Рассмотрим работу технологии на примере звонка между двумя абонентами через браузер:

Особенности работы WebRTC на мобильных устройствах

Преимущества стандарта

Недостатки стандарта

WebRTC для рынка ВКС

Популярность технологии

На сегодняшний день WebRTC второй по популярности после проприетарного протокола Zoom протокол видеосвязи и опережает все остальные стандартные (H.323 и SIP) и проприетарные (Microsoft Teams и Cisco Webex) протоколы.

Увеличение числа ВКС-терминалов

Технология WebRTC оказала сильное влияние на развитие рынка ВКС. После выхода в свет первых браузеров с поддержкой WebRTC в 2013 году потенциальное количество терминалов видеоконференцсвязи по всему миру сразу увеличилось на 1 млрд. устройств. По сути, каждый браузер стал ВКС терминалом, обладающим базовыми возможностями для участия в видеоконференциях.

Использование в специализированных решениях

Использование различных JavaScript библиотек и API облачных сервисов с поддержкой WebRTC позволяет легко добавить поддержку видеосвязи в любые веб-проекты. Ранее для передачи данных в реальном времени разработчикам приходилось изучать принципы работы протоколов и использовать наработки других компаний, которые чаще всего требовали дополнительного лицензирования, что увеличивало расходы. Уже сейчас WebRTC активно используется для организации видео-контакт-центров, проведения вебинаров и т. п.

Конкуренция с Flash

WebRTC и HTML5 стали смертельным ударом для технологии Flash, которая и так переживала свои далеко не лучшие годы. С 2017 года ведущие браузеры официально перестали поддерживать Flash и технология окончательно исчезла с рынка.

Тонкости работы с технологией WebRTC

Кодеки в WebRTC

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

Аудиокодеки

Для сжатия аудиотрафика в WebRTC используются обязательные кодеки (Opus и G.711) и дополнительные (G.722, iLBC, iSAC).

Opus — это аудиокодек с низкой задержкой кодирования (от 2.5 мс до 60 мс), поддержкой переменного битрейта и высоким уровнем сжатия, что идеально подходит для передачи потокового аудиосигнала в сетях с переменной пропускной способностью. Является основным аудиокодеком для WebRTC. Opus — гибридное решение, сочетающее в себе лучшие характеристики кодеков SILK (компрессия голоса, устранение искажений человеческой речи) и CELT (кодирование аудиоданных). Кодек находится в свободном доступе, разработчикам, которые его используют, не нужно платить отчисления правообладателям. По сравнению с другими аудиокодеками, Opus, несомненно, выигрывает по множеству показателей. По ряду параметров он превосходит довольно популярные кодеки с низким битрейтом, такие, как MP3, Vorbis, AAC LC. Opus восстанавливает наиболее приближенную к оригиналу “картину” звука, чем AMR-WB и Speex.

G.711 — устаревший голосовой кодек с высоким битрейтом (64 kbps), который чаще всего применяется в системах традиционной телефонии. Основным достоинством является минимальная вычислительная нагрузка из-за использования лёгких алгоритмов сжатия. Кодек отличается низким уровнем компрессии голосовых сигналов и не вносит дополнительной задержки звука во время общения между пользователями.

G.711 поддерживается большим количеством устройств. Системы, в которых используется этот кодек, более легкие в применении, чем те, которые основаны на других аудиокодеках (G.723, G.726, G.728 и т.д.). По качеству G.711 получил оценку 4.2 в тестировании MOS (оценка в пределах 4-5 является самой высокой и означает хорошее качество, аналогичное качеству передачи голосового трафика в ISDN и даже выше).

G.722 — является стандартом ITU-T, принят в 1988 году, в настоящее время является бесплатным. Может работать со скоростью 48, 56 и 64 кбит/с, обеспечивая качество звука на уровне G.711. И аналогично G.711 является устаревшим. Поддерживается в Chrome, Safari и Firefox.

iLBC (internet Low Bitrate Codec) — узкополосный речевой кодек с открытым исходным кодом. Доступен в Chrome и Safari. Из-за высокого сжатия потока при использовании данного кодека возрастает нагрузка на процессор.

iSAC (internet Speech Audio Codec) — широкополосный речевой аудиокодек, ранее проприетарный, который в настоящее время является частью проекта WebRTC, тем не менее не обязателен для использования. Поддерживается в Chrome и Safari. В реализации для WebRTC используется адаптивный битрейт от 10 до 52 кбит/с с частотой дискретизации 32 kHz.

Видеокодеки

Вопросы выбора видеокодека для WebRTC заняли у разработчиков несколько лет, в итоге в стандарт вошли VP8 и H.264. Также существуют реализации необязательных видеокодеков (H.265, VP9, AV1).

VP8 — свободный видеокодек с открытой лицензией, отличается высокой скоростью декодирования видеопотока и повышенной устойчивостью к потере кадров. Кодек универсален, его легко внедрить в аппаратные платформы, поэтому очень часто разработчики систем видеоконференцсвязи используют его в своих продуктах. Совместим с браузерами Chrome, Edge, Firefox и Safari (12.1+).

Платный видеокодек H.264 стал известен намного раньше своего собрата. Это кодек с высокой степенью сжатия видеопотока при сохранении высокого качества видео. Широкая распространенность этого кодека среди аппаратных систем видеоконференцсвязи предполагает его использование в стандарте WebRTC. Совместим с браузерами Chrome (52+), Edge, Firefox (в версиях 68+ для Android поддержка была прекращена) и Safari.

VP9 — открытый и бесплатный стандарт сжатия видео, разработанный в 2012 году компанией Google. Является развитием идей, заложенных в VP8 и в последующем был расширен в рамках AV1. Совместим с браузерами Chrome (48+) и Firefox.

H.265 — платный видеокодек, являющийся преемником H.264, обеспечивающий такое же визуальное качество при вдвое меньшем битрейте. Это достигается с помощью более эффективных алгоритмов сжатия. В настоящее время этот кодек конкурирует с бесплатным AV1.

AV1 — открытый кодек для сжатия видео, разработанный специально для передачи видео по сети Интернет. Поддерживается в Chrome (70+) и Firefox (67+).

При указании совместимости кодека с браузером Chrome подразумевается совместимость со всеми Chromium-based браузерами соответствующих версий.

Подключение по WebRTC

В зависимости от конкретной реализации WebRTC возможны отличия в версиях совместимых браузеров. Подробный список поддерживаемых десктопных и мобильных браузеров для TrueConf доступен на странице системных требований.

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

Источник

Знакомимся с WebRTC, как понять, что это и как оно работает?

Что такое WebRTC (Web Real Communication)? «проект с открытым исходным кодом, что позволяет совершать передачу аудио, а также видео данных при этом, не требуя внеочередных расширении веб — обозревателей через P2P ».

Все веб — обозреватели (Firefox, Chromium, Opera, Google Chrome, а также Mozila) стандартно поддерживают WebRTC.

В данной технологии использованы кодеки Opus и G.711 для того чтобы сжать аудио — трафика, видеокодеки H.264 и VP8 для сжатия видео.

С помощью данного проекта становится возможным обмениваться как аудио, так и видео, данными между участниками.

Теперь давайте разберем, WebRTC на первый взгляд состоит из одних плюсов, стоит ли ее периодически выключать?

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

При применении VPN в Opera вероятны следующие утечки:

Как проверить включен ли WebRTC

Вы можете воспользоваться следующими сайтами:

В случае если WebRTC включена, в строке — Browser Supports WebRTC (Either 1.0 or 1.1) появится “Yep”.

Если сравнить сайты, то на втором сайте вся информация предоставлена на русском языке.

WebRTC включена, в том случае если вы видите надпись — Потенциальная утечка.

Для того чтобы идентифицирующая информация не попала в лапы злоумышленников, стоит не пренебрегать безопасностью.

Возможно, ли отключить WebRTC в Firefox, и как это сделать?

Отключение WebRTC в веб – браузере Firefox производится легче всего, на уровне веб – браузера.

В начале вы указываете в адресную строку команду «about:config».

Далее вы увидите предупреждающее окно, для подтверждения действия, нажмите кнопку «Я обещаю быть осторожным»

После чего появится список настроек.

Вы должны найти строку «media.peerconnection.enabled». Чтобы упростить поиск воспользуйтесь командой «поиск».

Данная строка появится при сочетании клавиш Ctrl+ F. Если же вам надо ее выключить, нужно воспользоваться значением «false»

Что означает Плагин WebRTC Control и как им воспользоваться?

Для того чтобы сэкономить свое время при включении и выключении WebRTC просто установите плагин. Все что для этого необходимо, всего лишь открыть дополнения в настройках.

Введите название плагина (WebRTC Control) в поисковую строку.

Для установки нажмите кнопку «добавить в firefox», которую вы увидите внизу. Если вы активировали плагин, тогда в правом верхнем углу значок плагина будет синего цвета. Но данные плагины не могут предоставить 100% защиту ваших идентифицирующих данных. Для найлучщей защиты вы можете воспользоваться плагином NoScript, он запретит все возможные скрипты в веб – браузере. Если же вы хотите создать вашу особую сеть, для того чтобы воспрепятствовать нежеланным лицам идентифицировать ваш IP –адрес, стоит использовать VPN.

Opera

Чтобы отключить WebRTC, зайдите в библиотеку (галерею) расширенный.

Необходимо найти и установить расширение из прошлого пункта, нажмите на него, после чего на кнопку «Добавить в Opera». В случае если плагин будет находиться в рабочем состоянии, тогда иконка будет — синей.

Второй способ отключить WebRTC – перейдите в Меню>Настройки> Безопасность, отметьте галочкой «Показать дополнительные настройки» в разделе WebRTC необходимо выбрать «Отключить непроксированный UDP».

Яндекс

Вы отключите данную функцию с помощью плагина WebRTC Control, как и в Opere значок будет синего цвета во включенном состоянии.

GoogleChrome

Из всех браузеров, в GoogleCrome отключить WebRTC будет сложнее всего, так как для данного действия вы должны скачать дополнения: WebRTC Block либо Script Safe, которое и является самой надежной защитой от утечки информации. Даже если вам покажется не совсем легким путем, это того стоит.

Еще одним способом для отключения WebRTC, является плагин WebRTC Control. Для того чтобы его запустить, вам необходимо перейти в «Расширения», далее перейти ниже в «Еще Расширения» где вы выберете и установите необходимое вам дополнение. Также, как и в других браузерах, если технология будет включена, иконка будет синего цвета.

При желании можете воспользоваться WEbRTC Leak Prevent, и также Easy WebRTC Block, принцип их работы такой же, как и плагина WebRTC Control.

Google CРrome на телефоне

Чтобы отключить данную технологию, вы введете в строку «chrome://flags/#disable-webrtc», далее значение enabled.

Internet Explorer и Microsoft Edge

Браузер Internet Explorer не поддерживается WebRTC, таким образом вы будете им пользоваться, не думая об утечке данных.

Что касается браузера Microsoft Edge – вы сможете только частично блокировать технологию. Для чего вам необходимо выполнить следующие действия:

Safari на macOS

Для отключения технологии – войдите в настройки браузера, в «Дополнениях» поставите галочку о показе раздела «Разработка в меню», после чего ставим галочку на Remove Legacy WebRTC API.

Safari на iOS

Чтобы отключить WebRTC здесь – зайдите в настройки, спуститесь до пункта Safari, после чего нажмите «Дополнения», Experimental Features. Далее нажмите Remove Legacy WebRTC API, теперь вы можете быть уверенны что технология WebRTC отключена.

Источник

Как работает JS: WebRTC и механизмы P2P-коммуникаций

Сегодня мы публикуем перевод 18 части серии материалов, посвящённых всему, что связано с JavaScript. Здесь мы поговорим о технологии WebRTC, которая направлена на организацию прямого обмена данными между браузерными приложениями в реальном времени.

Обзор

Что такое WebRTC? Для начала стоит сказать, что аббревиатура RTC расшифровывается как Real Time Communication (связь в режиме реального времени). Уже одно это даёт немало информации о данной технологии.

WebRTC занимает весьма важную нишу среди механизмов веб-платформы. Ранее P2P-технологии (peer-to-peer, соединения типа «точка-точка», одноранговые, пиринговые сети), используемые такими приложениями, как настольные чаты, давали им возможности, которых не было у веб-проектов. WebRTC меняет ситуацию в лучшую для веб-технологий сторону.

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

P2P-коммуникации

Предположим, два пользователя запустили, каждый в своём браузере, приложение, которое позволяет организовать видеочат с использованием WebRTC. Они хотят установить P2P-соединение. После того, как решение принято, нужен механизм, который позволяет браузерам пользователей обнаружить друг друга и наладить связь с учётом имеющихся в системах механизмов защиты информации. После установки связи пользователи смогут обмениваться мультимедийной информацией в реальном времени.

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

Когда веб-приложению нужны какие-то данные или ресурсы, оно загружает их с сервера и на этом всё заканчивается. Адрес сервера известен приложению. Если же речь идёт, например, о создании P2P-чата, работа которого основана на прямом соединении браузеров, адреса этих браузеров заранее неизвестны. В результате для того, чтобы установить P2P-соединение, придётся справиться с некоторыми проблемами.

Файрволы и протокол NAT Traversal

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

NAT — это механизм, который транслирует внутренние локальные IP-адреса, расположенные за файрволом, во внешние глобальные IP-адреса. Технология NAT используется, во-первых, из соображений безопасности, а во-вторых — из-за ограничений, накладываемым протоколом IPv4 на количество доступных глобальных IP-адресов. Именно поэтому веб-приложения, использующие WebRTC, не должны полагаться на то, что текущее устройство имеет глобальный статический IP-адрес.

Посмотрим как работает NAT. Если вы находитесь в корпоративной сети и подключились к WiFi, вашему компьютеру будет назначен IP-адрес, который существует только за вашим NAT-устройством. Предположим, что это — IP-адрес 172.0.23.4. Для внешнего мира, однако, ваш IP-адрес может выглядеть как 164.53.27.98. Внешний мир, в результате, видит ваши запросы как приходящие с адреса 164.53.27.98, но, благодаря NAT, ответы на запросы, выполненные вашим компьютером к внешним сервисам, будут отправлены на ваш внутренний адрес 172.0.23.4. Это происходит с использованием таблиц трансляций. Обратите внимание на то, что в дополнение к IP-адресу для организации сетевого взаимодействия нужен ещё и номер порта.

Учитывая то, что в процесс взаимодействия вашей системы с внешним миром вовлечён NAT, вашему браузеру, для установления WebRTC-соединения, нужно узнать IP-адрес компьютера, на котором работает браузер, с которым вы хотите связаться.

Именно здесь на сцену выходят серверы STUN (Session Traversal Utilities for NAT) и TURN (Traversal Using Relays around NAT). Для обеспечения работы технологии WebRTC сначала делается запрос к STUN-серверу, направленный на то, чтобы узнать ваш внешний IP-адрес. Фактически, речь идёт о запросе, выполняемом к удалённому серверу с целью выяснить то, с какого IP-адреса сервер получает этот запрос. Удалённый сервер, получив подобный запрос, отправит ответ, содержащий видимый ему IP-адрес.

Исходя из предположения работоспособности этой схемы и того, что вы получили сведения о своём внешнем IP-адресе и порте, затем вы можете сообщить другим участникам системы (будем называть их «пирами») о том, как связаться с вами напрямую. Эти пиры, кроме того, могут сделать то же самое, используя STUN или TURN-серверы, и могут сообщить вам о том, какие адреса назначены им.

Сигналирование, сессии и протоколы

Процесс выяснения сетевой информации, описанный выше, является одной из частей большой системы сигналирования, которая основана, в случае с WebRTC, на стандарте JSEP (JavaScript Session Establishment Protocol). Сигналирование включает в себя обнаружение сетевых ресурсов, создание сессий и управление ими, обеспечение безопасности связи, координацию параметров медиаданных, обработку ошибок.

Для того чтобы соединение работало, пиры должны договориться о форматах данных, которыми они будут обмениваться, и собрать сведения о сетевых адресах компьютера, на котором работает приложение. Механизм сигналирования для обмена этой важнейшей информацией не является частью API WebRTC.

Сигналирование не определяется стандартом WebRTC, и оно не реализуется в его API для того, чтобы обеспечить гибкость в используемых технологиях и протоколах. За сигналирование и серверы, которые его поддерживают, отвечает разработчик WebRTC-приложения.

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

Изначальное обсуждение параметров сессии и установление соединения происходит с использованием протокола сигналирования/связи, специализирующегося на мультимедиа-коммуникациях. Этот протокол, кроме того, отвечает за соблюдение правил, в соответствии с которыми осуществляется управление сессией и её прекращение.

Один из таких протоколов называется SIP (Session Initiation Protocol). Обратите внимание на то, что благодаря гибкости подсистемы сигналирования WebRTC, SIP — это не единственный протокол сигналирования, который можно использовать. Выбранный протокол сигналирования, кроме того, должен работать с протоколом уровня приложения, который называется SDP (Session Description Protocol), который используется при применении WebRTC. Все метаданные, имеющие отношение к мультимедиа-данным, передаются с использованием протокола SDP.

Любой пир (то есть — приложение, использующее WebRTC), который пытается связаться с другим пиром, генерирует набор маршрутов-кандидатов протокола ICE (Interactive Connectivity Establishment). Кандидаты представляют некую комбинацию IP-адреса, порта и транспортного протокола, которые можно использовать. Обратите внимание на то, что один компьютер может обладать множеством сетевых интерфейсов (проводных, беспроводных, и так далее), поэтому ему может быть назначено несколько IP-адресов, по одному на каждый интерфейс.

Вот диаграмма с MDN, иллюстрирующая вышеописанный процесс обмена данными.

Процесс обмена данными, необходимыми для установления P2P-соединения

Установление соединения

Каждый пир сначала выясняет свой внешний IP-адрес как описано выше. Затем динамически создаются «каналы» сигналирующих данных, служащие для обнаружения пиров и поддержки обмена данными между ними, для обсуждения параметров сессий и их установки.

Эти «каналы» неизвестны и недоступны внешнему миру, для доступа к ним требуется уникальный идентификатор.

Обратите внимание на то, что благодаря гибкости WebRTC, и тому факту, что процесс сигналирования не определён стандартом, концепция «каналов» и порядок их использования могут слегка различаться в зависимости от используемых технологий. На самом деле, некоторые протоколы не требуют наличия механизма «каналов» для организации обмена данными. Мы, для целей этого материала, предполагаем, что «каналы» в реализации системы используются.

Если два или более пиров подключены к одному и тому же «каналу», пиры получают возможность обмениваться данными и обсуждать информацию о сессии. Этот процесс похож на шаблон издатель-подписчик. В целом, инициирующий соединение пир отправляет «предложение», используя протокол сигналирования, такой, как SIP или SDP. Инициатор ожидает получения «ответа» от получателя предложения, который подключён к рассматриваемому «каналу».

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

Затем устанавливается активная сетевая сокет-сессия между пирами. Далее, каждый пир создаёт локальные потоки данных и конечные точки каналов данных, и начинается двусторонняя передача мультимедиа-данных с использованием применяемой технологии.

Если процесс переговоров о выборе наилучшего ICE-кандидата успехом не увенчался, что иногда происходит по вине файрволов и NAT-систем, используется запасной вариант, заключающийся в применении, в качестве ретранслятора, TURN-сервера. Этот процесс задействует сервер, который работает как посредник, ретранслирующий данные, которыми обмениваются пиры. Обратите внимание на то, что эта схема не является настоящим P2P-соединением, в которой пиры передают данные напрямую друг другу.

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

Важно понимать, что сейчас речь шла о резервном способе организации связи. TURN-серверы должны быть весьма надёжными, иметь большую полосу пропускания и серьёзную вычислительную мощность, поддерживать работу с потенциально большими объёмами данных. Использование TURN-сервера, таким образом, очевидно, приводит к дополнительным затратам и к увеличению сложности системы.

API WebRTC

Есть три основных категории API, существующих в WebRTC:

API Media Capture and Streams

API Media Capture and Streams, которое часто называют Media Stream API или Stream API — это API, которое поддерживает работу с потоками аудио и видео-данных, методы для работы с ними. Средствами этого API задаются ограничения, связанные с типами данных, здесь имеются коллбэки успешного и неуспешного завершения операций, применяемые при использовании асинхронных механизмов работы с данными, и события, которые вызываются в процессе работы.

Метод getUserMedia() API MediaDevices запрашивает у пользователя разрешение на работу с устройствами ввода, которые производят потоки MediaStream со звуковыми или видео-дорожками, содержащими запрошенные типы медиаданных. Такой поток может включать, например, видеодорожку (её источником является либо аппаратный либо виртуальный видеоисточник, такой как камера, устройство для записи видео, сервис совместного использования экрана и так далее), аудиодорожку (её, похожим образом, могут формировать физические или виртуальные аудиоисточники, наподобие микрофона, аналогово-цифрового конвертера, и так далее), и, возможно, дорожки других типов.

Доступ к синглтону MediaDevice можно получить через объект navigator :

Начиная с версии 25, браузеры, основанные на Chromium, позволяют передавать аудиоданные из getUserMedia() аудио- или видео-элементам (однако, обратите внимание на то, что по умолчанию медиа-элементы будут отключены).

Метод getUserMedia() так же может быть использован как узел ввода для Web Audio API:

Ограничения, связанные с защитой личной информации

Несанкционированный захват данных с микрофона или камеры — это серьёзное вмешательство в личную жизнь пользователя. Поэтому использование getUserMedia() предусматривает реализацию весьма специфических требований по оповещению пользователя о происходящем и по управлению разрешениями. Метод getUserMedia() всегда должен получать разрешение пользователя перед открытием любого устройства ввода, собирающего медиаданные, такого, как веб-камера или микрофон. Браузеры могут предлагать возможность однократной установки разрешения для домена, но они обязаны запросить разрешение, как минимум, при первой попытке обращения к медиа-устройствам, и пользователь должен явно дать подобное разрешение.

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

Интерфейс RTCPeerConnection

Интерфейс RTCPeerConnection представляет собой WebRTC-соединение между локальным компьютером и удалённым пиром. Он предоставляет методы для подключения к удалённой системе, для поддержки соединения и мониторинга его состояния, и для закрытия соединения после того, как оно больше не нужно.

Вот диаграмма архитектуры WebRTC, демонстрирующая роль RTCPeerConnection.

С точки зрения JavaScript, главное знание, которое можно извлечь из анализа этой диаграммы, заключается в том, что RTCPeerConnection абстрагирует веб-разработчика от сложных механизмов, расположенных на более глубоких уровнях системы. Кодеки и протоколы, используемые WebRTC, выполняют огромную работу для того, чтобы сделать возможным обмен данными в реальном времени, причём, даже при использовании ненадёжных сетей. Вот некоторые из задач, решаемые этими механизмами:

API RTCDataChannel

Так же, как в случае с аудио- и видео-данными, WebRTC поддерживает передачу в реальном времени других типов данных. API RTCDataChannel позволяет организовать P2P-обмен произвольными данными.

Существует множество сценариев использования этого API. Вот некоторые из них:

WebRTC в реальном мире

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

Как уже было сказано, ICE — это протокол для соединения пиров, таких, как два клиента видеочата. В самом начале сеанса связи ICE пытается соединить пиров напрямую, с наименьшей возможной задержкой, через UDP. В ходе этого процесса у STUN-серверов имеется единственная задача: позволить пиру, находящемуся за NAT, узнать свой публичный адрес и порт. Взгляните на этот список доступных STUN-серверов (такие серверы есть и у Google).

Обнаружение ICE-кандидатов

Если UDP-подключение установить не удаётся, ICE пробует установить TCP-соединение: сначала — по HTTP, потом — по HTTPS. Если прямое соединение установить не получается — в частности из-за невозможности обхода корпоративных NAT и файрволов, ICE использует посредника (ретранслятор) в виде TURN-сервера. Другими словами, ICE сначала попытается использовать STUN с UDP для прямого соединения пиров, и, если это не получится, воспользуется запасным вариантом с рентанслятором в виде TURN-сервера. Выражение «поиск кандидатов» относится к процессу поиска сетевых интерфейсов и портов.

Поиск подходящих сетевых интерфейсов и портов

Безопасность

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

Итоги

WebRTC — это весьма интересная и мощная технология для проектов, в рамках которых используется передача каких-либо данных между браузерами в реальном времени. Автор материала говорит, что в его компании, SessionStack, используют традиционные механизмы обмена данными с пользователями, предусматривающие применение серверов. Однако, если бы они использовали WebRTC для решения соответствующих задач, это позволило бы организовывать обмен данными напрямую между браузерами, что привело бы к уменьшению задержки при передачи данных и к сокращению нагрузки на инфраструктуру компании.

Уважаемые читатели! Пользуетесь ли вы технологией WebRTC в своих проектах?

Источник