Введение
Всем добрый день. Меня зовут Максим. Мы занимаемся разработкой систем автоматизации, диспетчеризации и мониторинга различных объектов, начиная от умных домов и заканчивая промышленными установками и предприятиями. Вы спросите, причем же тут WebRTC, который в основном используется для создания аудио, видеоконференций между различными устройствами. Сейчас постараюсь объяснить.
WebRTC. Идея альтернативного использования.
Наша система автоматизации является полноценным веб приложением с возможностью разработки проекта через веб браузер. Как вы все знаете, браузер поддерживает только 3 типа технологии для передачи данных: HTTP, WebSocket, WebRTC. Задача первых двух — получение/передача данных с веб сервера. А вот WebRTC создавалась для обмена данными между браузерами и различными устройствами, поддерживающими данную технологию. Интересная особенность данной технологии в том, что соединяться друг с другом пользователи могут, находясь в абсолютно разных сетях и находясь за несколькими NATами, то есть не имея прямого доступа друг к другу. Тут нам пришла идея, а что если организовать обмен данными не между клиентами браузера, а между нашей системой и браузером. При этом осуществлять обмен только данными, без видео и аудио вообще. Так как мы работаем полностью через веб, то мы решили «завернуть» интерфейс системы в WebRTC канал данных и иметь к нему доступ из любой точки мира через обычный браузер. Как в итоге все это работает?
Сигнальный сервер. STUN и TURN
Для организации связи между нашей системой и клиентами в браузере мы в интернете поднимаем сигнальный сервер WebRTC, к которому подключаются клиенты для обмена кандидатами через Http. Также на этом сервере разворачиваем TURN сервер (например COTURN) для того, чтобы проксировать подключения, которые не пошли через STUN (прямое подключение через одноранговую сеть). Это может произойти по нескольким причинам. Первая причина в скорости ответа кандидата по сети. Если ICE агент поймет, что напрямую соединяться через STUN слишком долго или невозможно, то он автоматически направит тебя через TURN сервер. Вторая причина симметричный NAT на стороне провайдера. В симметричных NAT’ах внешний IP-адрес/порт зависит от внутреннего IP-адреса/порта duo и назначения. Запросы от 198.145.1.2:3000 к серверу TURN сопоставляются с заданным IP-адресом и портом внешнего источника. Но если один и тот же внутренний хост отправляет пакет в другое место назначения, например в одноранговый узел, с которым он пытается связаться, внешний IP-адрес/порт будет отличаться. Кроме того, внешний хост должен получить пакет от внутреннего хоста, прежде чем он сможет отправить пакет обратно. Если клиенты находятся за симметричным NAT, они не смогут общаться напрямую и пойдут через TURN. Так как WebRTC использует протокол UDP, то нагрузка на наш сервер TURN не очень высокая, так как он не держит сокеты, а просто проксирует UDP трафик. Да и количество подключений через TURN не так велико.
Завернем весь трафик
Теперь нам нужно завернуть весь наш HTTP и WebSocket трафик через WebRTC на наш сервер и обратно. Для этого используем библиотеку node-webrtc с готовыми скомпилированными модулями .node для всех современных ОС и железа. Библиотека хорошо оптимизирована и, самое главное, не требует сборки. С помощью нее мы получаем кандидатов и передаем эти данные на наш сигнальный сервер.
Также мы добавили возможность пробрасывать порты в локальную сеть, где установлен сервер. Это очень удобно, если надо получить доступ не только к веб серверу нашей системы, а например, к сервису ssh локальной машины или к чему-нибудь другому. На текущий момент поддерживается только TCP/IP соединение. Реализовано это все в виде плагина, который запускается системой и контролирует его работоспособность.
Клиенты на удаленке
Теперь остается только создать WebRTC клиента в браузере для доступа к интерфейсу системе. На сайте создаем сервис для доступа к необходимой нам машине по уникальному ключу, который получает наша система при установке. Ключ уникальный и создается исходя из нескольких серийных номеров вашего оборудования. Например, жесткого диска, сетевой карты, процессора и т.д. Пример ключа 213 678 945. Данный ключ регистрируется на сигнальном сервере с помощью Http.
Заключение
Если хотите попробовать, как это все работает в жизни, вам достаточно установить нашу бесплатную версию сервера по ссылке в сеть, где вам нужен удаленный доступ. Зайти в интерфейс разработчика, перейти на вкладку удаленный доступ и скопировать p2p ключ. Далее зайти на сайт https://p2p.ih-systems.com, ввести ключ и выбрать тип интерфейса — интерфейс пользователя или интерфейс разработчика, Нажимаем подключить и вуа-ля мы на сервере.
Для проброса портов из удаленной локальной сети в вашу вам необходимо включить режим эксперт на сервере в меню доступ на учетной записи (это сделано специально для безопасности) и скачать приложения для десктопа по ссылке. Это приложение сделано с помощью Electron, и по сути своей является браузером, но с небольшими дополнениями, которые в браузере реализовать невозможно. Это открытие локального порта на вашей машине для доступа к удаленному порту в локальной сети, где установлена наша система.
