Технология webrtc. Почему WebRTC определяет мой настоящий IP-адрес? Секреты WebRTC: как вендоры извлекают пользу из прорывной веб-технологии

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

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

Браузеры пользователей благодаря технологии 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 в браузерах

Быстрая навигация по этой странице.

Как отключить WebRTC в Mozilla Firefox

Браузер Mozilla Firefox - это единственный браузер, позволяющий отключить технологию WebRTC без установки дополнительных плагинов.

Ручная настройка

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

Чтобы отключить технологию WebRTC в Mozilla Firefox необходимо в адресной строке браузера ввести следующий текст и нажать кнопку Enter.

About:config

Нажмите, кнопку Я принимаю на себя риск.

Выполните следующее:

1. В поисковую строку введите текст и нажмите Enter.
media.peerconnection.enabled
2. Нажмите правой кнопкой мышки на строку и выберите Переключить. Или дважды кликните по строке.

После этих действий WebRTC будет отключен.

Настройка через плагин WebRTC Control

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

Откройте Дополнения.

Выберите:

1. Раздел Поиск
2. Введите название плагина в поисковую строку: WebRTC Control
3. Нажмите кнопку Установить

Как отключить WebRTC в браузере Opera

Для отключения WebRTC в браузере Opera перейдите в галерею Расширений.

Выполните следующие действия:

1. Введите название плагина в поисковой строке: WebRTC Control
2. Нажмите на плагин

Нажмите Добавить в Opera.

Активируйте плагин. Иконка плагина должна стать синего цвета для блокировки WebRTC.

Как отключить WebRTC в Google Chrome

Для отключения WebRTC в браузере Google Chrome перейдите в раздел Расширения.

Пролистайте страницу вниз и нажмите Еще расширения.

Выполните следующие действия:

1. Введите в поисковую строку название плагина: WebRTC Control
2. Нажмите кнопку Установить.

Активируйте плагин. Иконка плагина должна стать синего цвета для блокировки WebRTC.

Как отключить WebRTC в Яндекс Браузере

Для отключения WebRTC в Яндекс Браузере перейдите в раздел Дополнения.

Пролистайте страницу вниз и нажмите Каталог расширений для Яндекс Браузера.

Выполните действия:

1. Введите в поисковой строке название плагина: WebRTC Control
2. Нажмите на плагин для установки.

Нажмите Добавить в Яндекс Браузер.

Нажмите Установить расширение.

Активируйте плагин. Иконка плагина должна стать синего цвета для блокировки WebRTC.

Как отключить WebRTC в браузере SRWare Iron

Браузер SRWare Iron сделан на базе Google Chrome.

Установите плагин WebRTC Control по инструкции для .

Очень много пользователей даже и не знают о том, что такое WebRTC (ну в принципе ничего интересного) и что эта технология может вас выдать, если вы используете прокси… и даже Tor! WebRCT, если простыми словами, то это такая штука, которая была создана компанией Google для обеспечения передачи каких-то там потоковых данных между браузерами или другими программами, которые поддерживают эту штуку.

Но, не знаю где она применяется, однако WebRTC стоит отключить, так как она спокойно может выдать ваш IP-адрес с потрохами… и что самое интересное, это можно проверить при помощи сайта IPLeak.net (возьмите его в закладки лучше) — включите VPN, или установите прокси и посмотрите, что вам выдаст этот сайт

А выдаст он вам очень и очень интересную инфу — вверху будет адрес прокси или VPN, а вот в нижней строчки как раз ваш, хотя вы его типа поменяли:

Что лучше делать, как избавится от этого косяка? Нужно отключить вообще эту технологию в вашем браузере! Сегодня это точно возможно в Хроме и Мозилле, это в принципе и так самые популярные браузеры, особенно учитывая то, что много других также основаны на Хроме.

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

Переходим, нажимаем УСТАНОВИТЬ:

Теперь подтверждаем:

Расширение установилось, можно и проверить, снова заходим на IPLeak.net и проверяем, что теперь WebRTC теперь не вмешивается в нашу анонимность.

Ну, а как быть с Мозиллой? Тут тоже не сложно, открываем ее и пишем в адресной строке вот такое — about:config, после чего попадем на специальную страницу с кучей параметров.

Теперь вам нужно ввести в поиске (вверху строчка) вот этот параметр — media.peerconnection.enabled, и изменить значение с true на false:

Все, можно перезапустить браузер и проверить, теперь ваш IP-адрес не будет видно в сети при использовании VPN или прокси. Как я уже писал, что возможно и другие браузеры на основе Хрома смогут использовать вышеприведенное расширение, но гарантий нет, и, особенно это касается браузера Opera (она вроде тоже использует движок Хрома). Пока что стопудово работает в Хроме и Мозилле!

02.02.2016

Технологиям для звонков из браузера уже много лет: Java, ActiveX, Adobe Flash... В последние несколько лет стало ясно, что плагины и левые виртуальные машины не блещут удобством (зачем мне вообще что-то устанавливать?) и, самое главное, безопасностью. Что же делать? Выход есть!

До последнего времени в IP-сетях использовалось несколько протоколов для IP-телефонии или видео: SIP, наиболее распространенный протокол, сходящие со сцены H.323 и MGCP, Jabber/Jingle (используемый в Gtalk), полуоткрытые Adobe RTMP* и, конечно, закрытый Skype. Проект WebRTC, инициированный Google, пытается перевернуть положение дел в мире IP- и веб-телефонии, сделав ненужными все программные телефоны, включая Skype. WebRTC не просто реализует все коммуникационные возможности непосредственно внутри браузера, установленного сейчас практически на каждом устройстве, но пытается одновременно решить более общую задачу коммуникаций между пользователями браузеров (обмен различными данными, трансляция экранов, совместная работа с документами и многое другое).

WebRTC со стороны веб-разработчика

С точки зрения веб-разработчика WebRTC состоит из двух основных частей:

• управление медиапотоками от локальных ресурсов (камеры, микрофона или экрана локального компьютера) реализуется методом navigator.getUserMedia, возвращающим объект MediaStream;
• peer-to-peer коммуникации между устройствами, генерирующими медиапотоки, включая определение способов связи и непосредственно их передачу - объекты RTCPeerConnection (для отправки и получения аудио- и видеопотоков) и RTCDataChannel (для отправки и получения данных из браузера).

Что будем делать?

Мы разберемся, как организовать простейший многопользовательский видеочат между браузерами на основе WebRTC с использованием веб-сокетов. Экспериментировать начнем в Chrome/Chromium, как наиболее продвинутых в плане WebRTC браузерах, хотя вышедший 24 июня Firefox 22 почти их догнал. Нужно сказать, что стандарт еще не принят, и от версии к версии API может меняться. Все примеры проверялись в Chromium 28. Для простоты не будем следить за чистотой кода и кросс-браузерностью.

MediaStream

Первый и самый простой компонент WebRTC - MediaStream. Он предоставляет браузеру доступ к медиапотокам с камеры и микрофона локального компьютера. В Chrome для этого необходимо вызвать функцию navigator.webkitGetUserMedia() (так как стандарт еще не завершен, все функции идут с префиксом, и в Firefox эта же функция называется navigator.mozGetUserMedia()). При ее вызове пользователю будет выведен запрос о разрешении доступа к камере и микрофону. Продолжить звонок можно будет только после того, как пользователь даст свое согласие. В качестве параметров этой функции передаются параметры требуемого медиапотока и две callback-функции: первая будет вызвана в случае успешного получения доступа к камере/микрофону, вторая - в случае ошибки. Для начала создадим HTML-файл rtctest1.html с кнопкой и элементом

getUserMedia

Microsoft CU-RTC-Web

Microsoft не была бы Microsoft, если бы в ответ на инициативу Google не выпустила немедленно свой собственный несовместимый нестандартный вариант под названием CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web.htm). Хотя доля IE, и так небольшая, продолжает сокращаться, количество пользователей Skype дает Microsoft надежду потеснить Google, и можно предположить, что именно этот стандарт будет использоваться в браузерной версии Skype. Стандарт Google ориентирован в первую очередь на коммуникации между браузерами; в то же время основная часть голосового трафика по-прежнему остается в обычной телефонной сети, и шлюзы между ней и IP-сетями необходимы не только для удобства использования или более быстрого распространения, но и в качестве средства монетизации, которое позволит большему числу игроков их развивать. Появление еще одного стандарта может не только привести к неприятной необходимости разработчикам поддерживать сразу две несовместимых технологии, но и в перспективе дать пользователю более широкий выбор возможного функционала и доступных технических решений. Поживем - увидим.

Включение локального потока

Внутри тегов нашего HTML-файла объявим глобальную переменную для медиапотока:

Var localStream = null;

Первым параметром методу getUserMedia необходимо указать параметры запрашиваемого медиапотока - например просто включить аудио или видео:

Var streamConstraints = { "audio": true, "video": true }; // Запрашиваем доступ и к аудио, и к видео

Либо указать дополнительные параметры:

Var streamConstraints = { "audio": true, "video": { "mandatory": { "maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5" }, "optional": } };

Вторым параметром методу getUserMedia необходимо передать callback-функцию, которая будет вызвана в случае его успешного выполнения:

Function getUserMedia_success(stream) { console.log("getUserMedia_success():", stream); localVideo1.src = URL.createObjectURL(stream); // Подключаем медиапоток к HTML-элементу

Третий параметр - callback-функция обработчик ошибки, который будет вызван в случае ошибки

Function getUserMedia_error(error) { console.log("getUserMedia_error():", error); }

Собственно вызов метода getUserMedia - запрос доступа к микрофону и камере при нажатии на первую кнопку

Function getUserMedia_click() { console.log("getUserMedia_click()"); navigator.webkitGetUserMedia(streamConstraints, getUserMedia_success, getUserMedia_error); }

Получить доступ к медиапотоку из файла, открытого локально, невозможно. Если попытаться так сделать, получим ошибку:

NavigatorUserMediaError {code: 1, PERMISSION_DENIED: 1}"

Выложим получившийся файл на сервер, откроем в браузере и в ответ на появившийся запрос разрешим доступ к камере и микрофону.

Выбрать устройства, к которым получит доступ Chrome, можно в Settings («Настройки»), линк Show advanced settings («Показать дополнительные настройки»), раздел Privacy («Личные данные»), кнопка Content («Настройки контента»). В браузерах Firefox и Opera выбор устройств осуществляется из выпадающего списка непосредственно при разрешении доступа.

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

Обрати внимание на пульсирующий кружок в иконке на закладке и значок камеры в правой части адресной строки:

RTCMediaConnection

RTCMediaConnection - объект, предназначенный для установления и передачи медиапотоков по сети между участниками. Кроме того, этот объект отвечает за формирование описания медиасессии (SDP), получение информации об ICE-кандидатах для прохождения через NAT или сетевые экраны (локальные и с помощью STUN) и взаимодействие с TURN-сервером. У каждого участника должно быть по одному RTCMediaConnection на каждое соединение. Медиапотоки передаются по шифрованному протоколу SRTP.

TURN-серверы

ICE-кандидаты бывают трех типов: host, srflx и relay. Host содержат информацию, полученную локально, srflx - то, как узел выглядит для внешнего сервера (STUN), и relay - информация для проксирования трафика через TURN-сервер. Если наш узел находится за NAT’ом, то host-кандидаты будут содержать локальные адреса и будут бесполезны, кандидаты srflx помогут только при определенных видах NAT и relay будут последней надеждой пропустить трафик через промежуточный сервер.

Пример ICE-кандидата типа host, с адресом 192.168.1.37 и портом udp/34022:

A=candidate:337499441 2 udp 2113937151 192.168.1.37 34022 typ host generation 0

Общий формат для задания STUN/TURN-серверов:

Var servers = { "iceServers": [ { "url": "stun:stun.stunprotocol.org:3478" }, { "url": "turn:[email protected]:port", "credential": "password" } ]};

Публичных STUN-серверов в интернете много. Большой список, например, есть . К сожалению, решают они слишком малую часть проблем. Публичных же TURN-серверов, в отличие от STUN, практически нет. Связано это с тем, что TURN-сервер пропускает через себя медиапотоки, которые могут значительно загружать и сетевой канал, и сам сервер. Поэтому самый простой способ подключиться к TURN-серверам - установить его самому (понятно, что потребуется публичный IP). Из всех серверов, на мой взгляд, наилучший rfc5766-turn-server . Под него есть даже готовый образ для Amazon EC2.

С TURN пока не все так хорошо, как хотелось бы, но идет активная разработка, и хочется надеяться, через какое-то время WebRTC если не сравняется со Skype по качеству прохождения через трансляцию адресов (NAT) и сетевые экраны, то по крайней мере заметно приблизится.

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

Выбор способа передачи возлагается на разработчика - хоть вручную. Как только обмен необходимыми данными пройдет, RTCMediaConnection установит медиапотоки автоматически (если получится, конечно).

Модель offer-answer

Для установления и изменения медиапотоков используется модель offer/answer (предложение/ответ; описана в RFC3264) и протокол SDP (Session Description Protocol). Они же используются и протоколом SIP. В этой модели выделяется два агента: Offerer - тот, кто генерирует SDP-описание сессии для создания новой или модификации существующей (Offer SDP), и Answerer - тот, кто получает SDP-описание сессии от другого агента и отвечает ему собственным описанием сессии (Answer SDP). При этом в спецификации требуется наличие протокола более высокого уровня (например, SIP или собственного поверх веб-сокетов, как в нашем случае), отвечающего за передачу SDP между агентами.

Какие данные необходимо передать между двумя RTCMediaConnection, чтобы они смогли успешно установить медиапотоки:

• Первый участник, инициирующий соединение, формирует Offer, в котором передает структуру данных SDP (этот же протокол для той же цели используется в SIP), описывающую возможные характеристики медиапотока, который он собирается начать передавать. Этот блок данных необходимо передать второму участнику. Второй участник формирует Answer, со своим SDP и пересылает его первому.
• И первый и второй участники выполняют процедуру определения возможных ICE-кандидатов, с помощью которых к ним сможет передать медиапоток второй участник. По мере определения кандидатов информация о них должна передаваться другому участнику.

Формирование Offer

Для формирования Offer нам понадобятся две функции. Первая будет вызываться в случае его успешного формирования. Второй параметр метода createOffer() - callback-функция, вызываемая в случае ошибки при его выполнении (при условии, что локальный поток уже доступен).

Дополнительно понадобятся два обработчика событий: onicecandidate при определении нового ICE-кандидата и onaddstream при подключении медиапотока от дальней стороны. Вернемся к нашему файлу. Добавим в HTML после строк с элементами еще одну:

createOffer

И после строки с элементом

Также в начале JavaScript-кода объявим глобальную переменную для RTCPeerConnection:

Var pc1;

При вызове конструктора RTCPeerConnection необходимо указать STUN/TURN-серверы. Подробнее о них см. врезку; пока все участники находятся в одной сети, они не требуются.

Var servers = null;

Параметры для подготовки Offer SDP

Var offerConstraints = {};

Первый параметр метода createOffer() - callback-функция, вызываемая при успешном формировании Offer

Function pc1_createOffer_success(desc) { console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:", desc); pc1.setLocalDescription(desc); // Зададим RTCPeerConnection, сформированный Offer SDP методом setLocalDescription. // Когда дальняя сторона пришлет свой Answer SDP, его нужно будет задать методом setRemoteDescription // Пока вторая сторона не реализована, ничего не делаем // pc2_receivedOffer(desc); }

Второй параметр - callback-функция, которая будет вызвана в случае ошибки

Function pc1_createOffer_error(error){ console.log("pc1_createOffer_success_error(): error:", error); }

И объявим callback-функцию, которой будут передаваться ICE-кандидаты по мере их определения:

Function pc1_onicecandidate(event){ if (event.candidate) { console.log("pc1_onicecandidate():\n"+ event.candidate.candidate.replace("\r\n", ""), event.candidate); // Пока вторая сторона не реализована, ничего не делаем // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); } }

А также callback-функцию для добавления медиапотока от дальней стороны (на будущее, так как пока у нас только один RTCPeerConnection):

Function pc1_onaddstream(event) { console.log("pc_onaddstream()"); remoteVideo1.src = URL.createObjectURL(event.stream); }

При нажатии на кнопку «createOffer» создадим RTCPeerConnection, зададим методы onicecandidate и onaddstream и запросим формирование Offer SDP, вызвав метод createOffer():

Function createOffer_click() { console.log("createOffer_click()"); pc1 = new webkitRTCPeerConnection(servers); // Создаем RTCPeerConnection pc1.onicecandidate = pc1_onicecandidate; // Callback-функция для обработки ICE-кандидатов pc1.onaddstream = pc1_onaddstream; // Callback-функция, вызываемая при появлении медиапотока от дальней стороны. Пока что его нет pc1.addStream(localStream); // Передадим локальный медиапоток (предполагаем, что он уже получен) pc1.createOffer(// И собственно запрашиваем формирование Offer pc1_createOffer_success, pc1_createOffer_error, offerConstraints); }

Сохраним файл как rtctest2.html, выложим его на сервер, откроем в браузере и посмотрим в консоли, какие данные формируются во время его работы. Второе видео пока не появится, так как участник всего один. Напомним, SDP - описание параметров медиасессии, доступные кодеки, медиапотоки, а ICE-кандидаты - возможные варианты подключения к данному участнику.

Формирование Answer SDP и обмен ICE-кандидатами

И Offer SDP, и каждого из ICE-кандидатов необходимо передать другой стороне и там после их получения у RTCPeerConnection вызвать методы setRemoteDescription для Offer SDP и addIceCandidate для каждого ICE-кандидата, полученного от дальней стороны; аналогично в обратную сторону для Answer SDP и удаленных ICE-кандидатов. Сам Answer SDP формируется аналогично Offer; разница в том, что вызывается не метод createOffer, а метод createAnswer и перед этим RTCPeerConnection методом setRemoteDescription передается Offer SDP, полученный от вызывающей стороны.

Добавим еще один видеоэлемент в HTML:

И глобальную переменную для второго RTCPeerConnection под объявлением первой:

Var pc2;

Обработка Offer и Answer SDP

Формирование Answer SDP очень похоже на Offer. В callback-функции, вызываемой при успешном формировании Answer, аналогично Offer, отдадим локальное описание и передадим полученный Answer SDP первому участнику:

Function pc2_createAnswer_success(desc) { pc2.setLocalDescription(desc); console.log("pc2_createAnswer_success()", desc.sdp); pc1.setRemoteDescription(desc); }

Callback-функция, вызываемая в случае ошибки при формировании Answer, полностью аналогична Offer:

Function pc2_createAnswer_error(error) { console.log("pc2_createAnswer_error():", error); }

Параметры для формирования Answer SDP:

Var answerConstraints = { "mandatory": { "OfferToReceiveAudio":true, "OfferToReceiveVideo":true } };

При получении Offer вторым участником создадим RTCPeerConnection и сформируем Answer аналогично Offer:

Function pc2_receivedOffer(desc) { console.log("pc2_receiveOffer()", desc); // Создаем объект RTCPeerConnection для второго участника аналогично первому pc2 = new webkitRTCPeerConnection(servers); pc2.onicecandidate = pc2_onicecandidate; // Задаем обработчик события при появлении ICE-кандидата pc2.onaddstream = pc_onaddstream; // При появлении потока подключим его к HTML

Для того чтобы в рамках нашего примера передать Offer SDP от первого участника ко второму, раскомментируем в функции pc1createOffer success() строку вызова:

Pc2_receivedOffer(desc);

Чтобы реализовать обработку ICE-кандидатов, раскомментируем в обработчике события готовности ICE-кандидатов первого участника pc1_onicecandidate() его передачу второму:

Pc2.addIceCandidate(new RTCIceCandidate(event.candidate));

Обработчик события готовности ICE-кандидатов второго участника зеркально подобен первому:

Function pc2_onicecandidate(event) { if (event.candidate) { console.log("pc2_onicecandidate():", event.candidate.candidate); pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); } }

Сallback-функцию для добавления медиапотока от первого участника:

Function pc2_onaddstream(event) { console.log("pc_onaddstream()"); remoteVideo2.src = URL.createObjectURL(event.stream); }

Завершение соединения

Добавим еще одну кнопку в HTML

Hang Up

И функцию для завершения соединения

Function btnHangupClick() { // Отключаем локальное видео от HTML-элементов

Сохраним как rtctest3.html, выложим на сервер и откроем в браузере. В этом примере реализована двусторонняя передача медиапотоков между двумя RTCPeerConnection в рамках одной закладки браузера. Чтобы организовать через сеть обмен Offer и Answer SDP, ICE-кандидатами между участниками и другой информацией, потребуется вместо прямого вызова процедур реализовать обмен между участниками с помощью какого-либо транспорта, в нашем случае - веб-сокетов.

Трансляция экрана

Функцией getUserMedia можно также захватить экран и транслировать как MediaStream, указав следующие параметры:

Var mediaStreamConstraints = { audio: false, video: { mandatory: { chromeMediaSource: "screen" }, optional: } };

Для успешного доступа к экрану должно выполняться несколько условий:

• включить флаг снимка экрана в getUserMedia() в chrome://flags/,chrome://flags/;
• исходный файл должен быть загружен по HTTPS (SSL origin);
• аудиопоток не должен запрашиваться;
• не должно выполняться несколько запросов в одной закладке браузера.

Библиотеки для WebRTC

Хотя WebRTC еще и не закончен, уже появилось несколько базирующихся на нем библиотек. JsSIP предназначена для создания браузерных софтфонов, работающих с SIP-коммутаторами, такими как Asterisk и Camalio. PeerJS упростит создание P2P-сетей для обмена данными, а Holla сократит объем разработки, необходимый для P2P-связи из браузеров.

Node.js и socket.io

Для того чтобы организовать обмен SDP и ICE-кандидатами между двумя RTCPeerConnection через сеть, используем Node.js с модулем socket.io.

Установка последней стабильной версии Node.js (для Debian/Ubuntu) описана

$ sudo apt-get install python-software-properties python g++ make $ sudo add-apt-repository ppa:chris-lea/node.js $ sudo apt-get update $ sudo apt-get install nodejs

Установка под другие операционные системы описана

Проверим:

$ echo "sys=require("util"); sys.puts("Test message");" > nodetest1.js $ nodejs nodetest1.js

С помощью npm (Node Package Manager) установим socket.io и дополнительный модуль express:

$ npm install socket.io express

Проверим, создав файл nodetest2.js для серверной части:

$ nano nodetest2.js var app = require("express")() , server = require("http").createServer(app) , io = require("socket.io").listen(server); server.listen(80); // Если порт 80 свободен app.get("/", function (req, res) { // При обращении к корневой странице res.sendfile(__dirname + "/nodetest2.html"); // отдадим HTML-файл }); io.sockets.on("connection", function (socket) { // При подключении socket.emit("server event", { hello: "world" }); // отправим сообщение socket.on("client event", function (data) { // и объявим обработчик события при поступлении сообщения от клиента console.log(data); }); });

И nodetest2.html для клиентской части:

$ nano nodetest2.html

Запустим сервер:

$ sudo nodejs nodetest2.js

и откроем страницу http://localhost:80 (если запущен локально на 80-м порту) в браузере. Если все успешно, в консоли JavaScript браузера мы увидим обмен событиями между браузером и сервером при подключении.

Обмен информацией между RTCPeerConnection через веб-сокеты

Клиентская часть

Сохраним наш основной пример (rtcdemo3.html) под новым именем rtcdemo4.html. Подключим в элементе библиотеку socket.io:

И в начале сценария JavaScript - подключение к веб-сокетам:

Var socket = io.connect("http://localhost");

Заменим прямой вызов функций другого участника отправкой ему сообщения через веб-сокеты:

Function createOffer_success(desc) { ... // pc2_receivedOffer(desc); socket.emit("offer", desc); ... } function pc2_createAnswer_success(desc) { ... // pc1.setRemoteDescription(desc); socket.emit("answer", desc); } function pc1_onicecandidate(event) { ... // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice1", event.candidate); ... } function pc2_onicecandidate(event) { ... // pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice2", event.candidate); ... }

В функции hangup() вместо прямого вызова функций второго участника передадим сообщение через веб-сокеты:

Function btnHangupClick() { ... // remoteVideo2.src = ""; pc2.close(); pc2 = null; socket.emit("hangup", {}); }

И добавим обработчики получения сообщения:

Socket.on("offer", function (data) { console.log("socket.on("offer"):", data); pc2_receivedOffer(data); }); socket.on("answer", function (data) {е console.log("socket.on("answer"):", data); pc1.setRemoteDescription(new RTCSessionDescription(data)); }); socket.on("ice1", function (data) { console.log("socket.on("ice1"):", data); pc2.addIceCandidate(new RTCIceCandidate(data)); }); socket.on("ice2", function (data) { console.log("socket.on("ice2"):", data); pc1.addIceCandidate(new RTCIceCandidate(data)); }); socket.on("hangup", function (data) { console.log("socket.on("hangup"):", data); remoteVideo2.src = ""; pc2.close(); pc2 = null; });

Серверная часть

На серверной стороне сохраним файл nodetest2 под новым именем rtctest4.js и внутри функции io.sockets.on("connection", function (socket) { ... } добавим прием и отправку сообщений клиентов:

Socket.on("offer", function (data) { // При получении сообщения "offer", // так как клиентское соединение в данном примере всего одно, // отправим сообщение обратно через тот же сокет socket.emit("offer", data); // Если бы было необходимо переслать сообщение по всем соединениям, // кроме отправителя: // soket.broadcast.emit("offer", data); }); socket.on("answer", function (data) { socket.emit("answer", data); }); socket.on("ice1", function (data) { socket.emit("ice1", data); }); socket.on("ice2", function (data) { socket.emit("ice2", data); }); socket.on("hangup", function (data) { socket.emit("hangup", data); });

Кроме этого, изменим имя HTML-файла:

// res.sendfile(__dirname + "/nodetest2.html"); // Отдадим HTML-файл res.sendfile(__dirname + "/rtctest4.html");

Запуск сервера:

$ sudo nodejs nodetest2.js

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

Заключение

Получившийся пример очень условен, но если немного универсализировать обработчики событий, чтобы они не различались у вызывающей и вызываемой стороны, вместо двух объектов pc1 и pc2 сделать массив RTCPeerConnection и реализовать динамическое создание и удаление элементов

Можно предположить, что совсем скоро благодаря WebRTC произойдет переворот не только в нашем представлении о голосовой и видеосвязи, но и в том, как мы воспринимаем интернет в целом. WebRTC позиционируется не только как технология для звонков из браузера в браузер, но и как технология коммуникаций реального времени. Видеосвязь, которую мы разобрали, лишь небольшая часть возможных вариантов его использования. Уже есть примеры трансляции экрана (скриншаринга) , и совместной работы , и даже P2P-сеть доставки контента на основе браузеров с помощью RTCDataChannel.

Следующий скрин говорит о том, что в вашем браузере включена функция WebRTC. Кроме этого, сайт предоставляет и другую интересную информацию.

Как отключить WebRTC?

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

Отключение WebRTC Firefox

Для отключения в браузере Firefox необходимо ввести в адресной строке команду about:config , после чего появится это сообщение.

Нажимаем на кнопку «Я обещаю…» и продолжаем дальше.

В окне настроек, в строке поиска (не в адресной строке!), как это показано на скрине ниже вводим команду media.peerconnection.enabled . Появится необходимая нам строка. Нажмем на нее правым шелчком мышки и в выпадающем меню выберем первый пункт «Переключить «.

После переключения в поле «Значение» вы должные увидеть параметр «False «. Теперь закрываем это окно и перегружаем браузер.

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

Есть еще более простой способ - скачать утилиту ConfigFox, которая кроме данной операции может значительно улучшить конфиденциальность и анонимность браузера Firefox. Об этой программе мы писали в статье «Настройки безопасности Firefox «. Я очень рекомендую использовать данную утилиту всем пользователям браузера Mozilla Firefox. Программа не устанавливает себя в браузер, а просто позволяет изменять файл настроек.

Отключение WebRTC Chrome

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

Также существует дополнение ScriptSafe , которое тоже может помочь в решении данной проблемы. На мой взгляд это лучший способ решить проблему WebRTC в Хроме.

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

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

Отключение WebRTC Opera / Яндекс Браузер

Для браузера Opera есть несколько плагинов: WebRTC Leak Prevent и WebRTC Control . Лично не проверял пробуйте и пишите, что помогло, а что нет.

В заключение хочу сказать, что на данный момент не существует надежного сто процентного способа отключить WebRTC в Chromium браузерах таких как: Chrome, Yandex, Opera и т.д. Поэтому я советуют всем, кто использует VPN и кому важна анонимность, временно прекратить пользоваться этими браузерами. Я думаю в скором будущем, эта дыра будет закрыта и вы сможете вернутся к ним. А пока можете временно переехать на Firefox.

На этом все. В следующих статьях будем говорить об анонимности и надежности VPN и публичных Proxy. Будет весело, будем ломать стереотипы. Вам это понравится;)!

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

Chrome, Opera, Яндекс.Браузер

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

Мобильные устройства

Firefox на Android

WebRTC отключается вручную аналогично с настольной версией:

1. В адресной строке браузера введите about:config
2. Нажмите кнопку «Я обещаю, что буду осторожен!»
3. Найдите строку «media.peerconnection.enabled»
4. Двойным кликом измените значение на “false”

Chrome на Android

1. Откройте браузер
2. Нажмите «Enable»

Яндекс.Браузер на Android

1. Откройте браузер
2. В адресную строку введите: chrome://flags/#disable-webrtc
3. Нажмите «Enable»
4. Закройте приложение или перезагрузите устройство

На данный момент, нет безопасного способа отключить WebRTC в Opera для Android.