Сказ о том, как я изобретал велосипед для домашнего видеонаблюдения. Часть вторая: технологии и протоколы
В прошлой части я подробно разобрал, как эволюционировала моя система домашнего видеонаблюдения: от простых решений «из коробки» до попыток собрать что‑то действительно гибкое, управляемое и независимое от сторонних облаков. Конечной точкой этой эволюции стала идея: раз уж готовые протоколы не устраивают меня полностью, нужно построить собственный протокол передачи видеопотоков, но опереться при этом на проверенную и современную технологию. Базой вполне логично оказался WebRTC.
Ниже — подробный разбор того, чем вообще является WebRTC, почему он хорошо ложится на задачу домашнего видеонаблюдения, как устроено согласование параметров и обход NAT, и как поверх всего этого можно собрать «свой» протокол — грубо говоря, WebRTSP: RTSP‑подобную логику управления видеопотоками, но работающую через WebRTC.
Что такое WebRTC и зачем он нужен
WebRTC — это набор протоколов и технологий, предназначенный для передачи данных напрямую между двумя устройствами: как в пределах одной локальной сети, так и через интернет. Под «данными» в контексте WebRTC обычно понимают:
- видеопотоки;
- аудиопотоки;
- произвольные данные приложений (через DataChannel).
Изначально WebRTC создавался как технология для голосовых и видеозвонков прямо в браузере, но по сути это универсальный транспорт для медиа в режиме реального времени. Для домашнего видеонаблюдения это звучит особенно интересно.
Ключевые свойства WebRTC, полезные для видеонаблюдения
Для задачи «домашняя камера — клиент (телефон / ПК / планшет)» важны следующие особенности WebRTC:
1. Минимальная задержка
Задержка между захватом изображения камерой и отображением на экране получателя легко укладывается в сотни миллисекунд. Для онлайн‑просмотра это критично: наблюдать «прошлую жизнь» с лагом в 5–10 секунд неудобно, а WebRTC как раз решает эту проблему.
2. Сквозное шифрование
Все передаваемые медиа и данные шифруются. Для домашнего видеонаблюдения это не просто «приятная опция», а вопрос приватности: вы явно не хотите, чтобы видеопотоки с квартиры или дома можно было подслушать на пути следования.
3. Встроенный механизм обхода NAT
Устройства могут находиться за роутерами, с «серой» адресацией, в разных сетях и даже разных странах. WebRTC содержит инструменты для того, чтобы всё равно попытаться установить между ними прямое или, в крайнем случае, проксируемое соединение.
В результате WebRTC отлично подходит для сценария: «камера стоит дома за роутером, я с телефона из любой точки мира хочу посмотреть, что там происходит — быстро, безопасно и без проброса портов».
Популярные реализации WebRTC
WebRTC — не одна конкретная библиотека, а спецификация и набор протоколов. Поэтому есть множество реализаций под разные языки и задачи. Наиболее известные:
1. WebRTC.org
Эталонная реализация от Google на C++. Используется в браузерах на основе Chromium (Chrome, новые версии Edge и другие). Существуют официальные обвязки для Java/Kotlin и Objective‑C/Swift, благодаря чему её применяют в мобильных приложениях для Android и iOS.
2. Элемент `webrtcbin` в GStreamer
Реализация на C, интегрированная в мультимедийный фреймворк GStreamer. Удобна, если вы уже живёте в экосистеме GStreamer и хотите добавить WebRTC в существующий конвейер обработки медиа.
3. Pion
Реализация WebRTC на Go. Хорошо подходит для серверных приложений и микросервисов, где важна простота параллелизма и развёртывания.
4. Mediasoup
Серверная библиотека (C++, Rust) для построения сложной WebRTC‑инфраструктуры: конференций, MCU/SFU, микширования потоков и т.п.
5. Janus Gateway (Janus WebRTC Server)
Лёгкий, модульный сервер на C, который позволяет принимать и ретранслировать WebRTC‑потоки, подключать плагины, конвертировать форматы и строить вокруг него кастомную логику.
6. Jitsi Videobridge / Jitsi Meet
Решение на Java, ориентированное в первую очередь на видеоконференции, но часть его стека можно использовать и для иных задач.
Главное для меня как разработчика своего протокола: реализации WebRTC в целом совместимы между собой на уровне протокола. То есть, если я подниму свою камеру на основе Pion, а клиент будет в браузере с WebRTC.org, они договорятся между собой по стандартным правилам.
Почему нельзя просто «поднять WebRTC и радоваться»
WebRTC — это универсальный транспорт, но он не определяет:
- как именно организовать управление потоками (подключение/отключение, выбор камеры, смена качества);
- какие именно команды передавать;
- как описать бизнес‑логику устройства (например, «дай мне поток с камеры №2 в таком‑то разрешении»);
- как синхронизировать медиа с метаданными (события детекции движения, состояние сенсоров и т.п.).
Традиционно для видеонаблюдения используют RTSP: там есть команды PLAY, PAUSE, SETUP и т.д., есть понятная модель сессий. Но RTSP сам по себе не умеет ни в шифрование по умолчанию, ни в удобный обход NAT. Отсюда и родилась идея: взять идеи RTSP (управление медиа) и транспорт WebRTC (безопасность, низкая задержка, NAT‑traversal) — и скрестить их.
Условно назовём результат WebRTSP — протокол, в котором мы управляем видеопотоками RTSP‑подобными командами, но доставляем их через WebRTC.
С чего вообще начинается WebRTC‑соединение
Прежде чем устройства смогут обмениваться видео, им нужно:
1. Договориться, что и в каком виде они будут друг другу отправлять.
2. Понять, как соединиться друг с другом в сети.
Для первого шага в WebRTC существует механизм SDP‑согласования (Session Description Protocol) — та самая пара offer/answer.
Offer / Answer: согласование возможностей
Так как заранее неизвестно, какие кодеки и параметры поддерживают устройства, одна из сторон инициирует процесс:
1. Инициатор формирует offer — описание того, что он:
- умеет отправлять (видео, аудио, данные);
- хочет получать (например, только видео);
- какие кодеки и параметры поддерживает.
2. Вторая сторона, получив offer, формирует answer:
- выбирает из предложенного набора то, что реально поддерживает;
- при необходимости уточняет параметры (битрейт, разрешения, частоту кадров);
- может отказаться от отдельных потоков.
В процессе согласуются:
- набор медиа‑потоков
Например, камера отправляет: видеопоток + аудио + поток данных (метаданные, события). Клиент хочет получать только видео и метаданные — это отражается в SDP.
- кодеки и параметры
Выбираются конкретные кодеки (H.264, VP8, Opus и т.д.) и их настройки: профили, уровни, целевая скорость, определённые расширения.
Для домашнего видеонаблюдения это важно, потому что:
- разные клиенты могут поддерживать разный набор кодеков (старые телефоны, смарт‑ТВ, браузеры);
- иногда имеет смысл отдать клиенту не оригинальный поток с камеры, а перекодированную версию полегче (меньше битрейт, ниже разрешение), если интернет у клиента слабый.
ICE: как договориться о сетевом пути
Когда медиа‑возможности согласованы, остаётся главный практический вопрос: как добраться до устройства по сети, если оба сидят где‑то за роутерами?
Для этого в WebRTC используется механизм ICE (Interactive Connectivity Establishment). Процесс упрощённо выглядит так:
1. Каждое устройство собирает список возможных способов, по которым к нему можно подключиться:
- локальные IP‑адреса (внутри сети);
- публичные адреса, если они есть;
- адреса, полученные с помощью STUN/TURN‑серверов.
2. Эти варианты передаются другой стороне в виде ICE‑кандидатов (ICE candidates).
3. Обе стороны начинают перебирать комбинации «мой кандидат — твой кандидат» и пытаются установить по ним соединение.
Зачем столько сложности
Если отбросить экзотику и смотреть на бытовые сценарии, обычно встречаются три варианта:
1. Оба устройства в одной сети или между ними настроен роутинг
Например, камера и клиент в одной домашней Wi‑Fi‑сети.
В этом случае используется прямое соединение по локальным адресам — минимальные задержки и отсутствие лишней маршрутизации.
2. Одно из устройств за NAT
Типичный случай: камера дома за роутером (частный IP), а клиент в интернете с «белым» адресом.
В этом случае задействуются техники типа STUN: камера узнаёт, какой внешний адрес и порт ей выделил роутер, и сообщает об этом клиенту. Если NAT не слишком строгий, получается установить соединение напрямую.
3. Оба устройства за жёстким NAT или фаерволами
Бывает, что ни один из вариантов прямого соединения не срабатывает. Тогда в ход идёт TURN‑сервер — это по сути прокси, через который идёт весь медиа‑трафик. Задержки и нагрузка выше, но связь всё равно устанавливается.
Для домашнего видеонаблюдения такое поведение крайне удобно: вы не лезете в настройки роутера, не пробрасываете порты, не открываете наружу потенциально дырявые веб‑морды устройств. Всё общение ложится на WebRTC и его механизмы обхода NAT.
Как поверх WebRTC построить собственный «WebRTSP»
Теперь, когда у нас есть:
- безопасный транспорт с минимальными задержками,
- согласование кодеков,
- механизмы соединения через NAT,
можно думать о том, как организовать управление видеопотоками.
Мне хотелось получить от протокола следующее:
- возможность выбирать, какой именно поток запрашивать у камеры (основной/дополнительный, разное разрешение);
- возможность динамически менять параметры без разрыва соединения (например, при переключении с Wi‑Fi на мобильную сеть);
- поддержку нескольких клиентов на одну камеру;
- передачу не только медиа, но и метаданных (движение, события, состояние датчиков).
Классический RTSP решает схожие задачи, но не обладает преимуществами WebRTC. Поэтому логика получилась такой:
1. Управляющие команды и метаданные идут по WebRTC DataChannel в виде простых сообщений (например, JSON).
2. Медиа‑потоки (видео/аудио) передаются как обычные WebRTC‑треки.
3. Протокол команд вдохновлён RTSP: есть аналоги PLAY, PAUSE, SETUP, DESCRIBE, но они формализованы как сообщения поверх DataChannel.
Условно это и есть «WebRTSP»: RTSP‑подобный по командам, но с транспортом и инфраструктурой WebRTC.
Особенности домашнего видеонаблюдения, которые нужно учитывать в протоколе
Когда вы проектируете не абстрактный видеочат, а именно систему видеонаблюдения, появляются дополнительные требования:
1. Надёжная передача и запись
WebRTC ориентирован на живой стрим, где допустима потеря пакетов ради скорости. Для видеонаблюдения важно уметь дублировать поток на запись, возможно, через отдельный компонент, который получает WebRTC‑стрим и пишет его на диск или в архив в удобном формате.
2. Ограниченный аплинк камеры
Домашний интернет часто асимметричен: исходящий канал слабее входящего. Значит, камера не может вечно раздавать десяток FullHD‑потоков одновременно. Протокол должен учитывать количество клиентов, поддерживать понижение качества и ограничение числа одновременных подключений.
3. Работа с событиями
Видеонаблюдение — это не только «смотреть картинку». Есть детекция движения, события от датчиков (дверь открыта, сработала сигнализация). Протокол должен позволять отправлять такие события в реальном времени вместе с видео.
4. Авторизация и права доступа
Не все пользователи равны: кому‑то можно только смотреть, кому‑то — управлять PTZ‑камерой или менять настройки. Это тоже отражается в логике запросов и ответов поверх WebRTC‑канала управления.
5. Поддержка разных клиентов
Одни клиенты — это мобильные приложения, другие — браузер, третьи — настольная программа. Значит, протокол должен быть достаточно простым и однозначным, чтобы его можно было реализовать на разных платформах без «танцев с бубном».
Преимущества и слабые места подхода «WebRTSP поверх WebRTC»
Чтобы трезво оценить идею «самодельного» протокола, стоит сразу честно видеть плюсы и минусы.
Плюсы:
- современный защищённый транспорт с минимальной задержкой;
- NAT‑traversal «из коробки»;
- одно и то же ядро технологии для браузеров, мобильных и настольных клиентов;
- гибкость в описании команд и логики устройства;
- возможность интеграции с существующей экосистемой WebRTC‑серверов и библиотек.
Минусы:
- сложность реализации: WebRTC сам по себе не прост, плюс поверх него нужно придумать и реализовать свой протокол;
- необходимость поддерживать совместимость клиентов и камер по вашей собственной спецификации;
- повышенные требования к тестированию: нужно проверять поведение при разных типах NAT, потере пакетов, реконнектах;
- зависимость от качества сетевой инфраструктуры: при плохих сетях придётся мудро балансировать между качеством и стабильностью.
Практическое применение: как это выглядит «в поле»
В реальной домашней системе это может выглядеть так:
1. Камера (или «умный» видеорегистратор) поднимает WebRTC‑стек и ждёт подключений.
2. Клиент, зная адрес сервера сигналинга (канал, через который обмениваются offer/answer и ICE‑кандидатами), инициирует соединение.
3. Стороны договариваются о кодеках и параметрах медиа.
4. По DataChannel клиент отправляет команду наподобие:
`PLAY camera=1 stream=main resolution=1080p bitrate=2Mbps`.
5. Камера начинает передавать нужный видеопоток и, при необходимости, параллельно шлёт метаданные (например, зоны движения).
6. При смене сети или падении скорости клиент может запросить `SWITCH_STREAM` или `SET_PARAMS`, чтобы уменьшить качество и сохранить стабильность трансляции.
Вся сложная магия подключения через NAT, шифрования и передачи медиа с минимальной задержкой остаётся за WebRTC, а вы управляете лишь своей надстройкой — тем самым «велосипедом», который делает из WebRTC именно систему видеонаблюдения, а не абстрактный видеочат.
Куда развивать такую архитектуру дальше
После того как базовый протокол и первая реализация заработали, становятся возможны дальнейшие улучшения:
- добавление адаптивного битрейта с автоматической подстройкой качества под сеть;
- внедрение аналитики на стороне камеры или сервера (распознавание объектов, людей, номеров автомобилей);
- организация мультипросмотра с одной камеры сразу на нескольких клиентов с минимальной нагрузкой (через SFU/relay‑сервер на WebRTC);
- гибкая система прав доступа и временных токенов для гостевого просмотра;
- интеграция с другими системами умного дома.
Все эти задачи проще решать, когда у вас уже есть понятная собственная спецификация поверх WebRTC, а не хаотический набор разрозненных скриптов и утилит.
***
Таким образом, технологическая часть моего «велосипеда» для домашнего видеонаблюдения сводится к следующему: использовать WebRTC как надёжный, безопасный и низколатентный транспорт, а поверх него построить протокол управления видеопотоками в духе RTSP. Это сочетание даёт возможность получать от камер всё, что нужно для реальной эксплуатации дома или в квартире, не жертвуя ни безопасностью, ни удобством подключения из любой точки мира.
