Почему 10 камер почти никогда не означают 10 потоков: скрытая сетевая математика современного видеонаблюдения

Есть одна особенно коварная ошибка, которую в видеонаблюдении совершают с завидной регулярностью. Система проектируется вроде бы аккуратно, камеры подобраны, сервер выбран с запасом, диски посчитаны, PoE-бюджет не забыт, коммутаторы не самые стыдные на рынке, даже кабель проложен не по принципу «и так сойдет». А потом объект запускается, и вдруг выясняется, что сеть нагружена сильнее, чем ожидалось, интерфейс местами подтормаживает, удаленные рабочие места жалуются на задержки, а камеры ведут себя так, будто у них внезапно началась вторая смена без доплаты.

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

Классическая архитектура IP-видеонаблюдения уже давно опирается как минимум на два потока с камеры. Первый, основной, или main stream, используется для записи архива, просмотра в полном качестве, детального разбора событий и хранения доказательной базы. Он обычно идет в высоком разрешении, с более высоким битрейтом, нередко с H.264 или H.265, и именно он становится главным потребителем дисков и одним из главных источников сетевой нагрузки. Второй поток, sub stream, традиционно легче: ниже разрешение, ниже битрейт, проще декодирование, меньше нагрузка на клиентские машины и каналы связи. Он нужен для сетки камер в интерфейсе оператора, для быстрых превью, удаленных клиентов, мобильного доступа, а в некоторых системах и для работы детекторов движения или части аналитики.

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

Проблема в том, что даже эта формула, 10 камер = 20 потоков, в реальной жизни часто оказывается не верхней оценкой, а почти наивным минимумом. Потому что современные системы видеонаблюдения редко состоят только из камер и одного сервера. Почти всегда есть дополнительные потребители потоков. Операторское рабочее место открывает сетку и тянет sub stream. Пост охраны открывает выбранную камеру в полном качестве и тянет main stream. Удаленный пользователь через VPN смотрит живое видео. Мобильное приложение запрашивает адаптированный поток. Аналитический модуль получает свое видео для обработки. Облачный сервис запрашивает снимки, клипы или live-view. А если архитектура построена неаккуратно, часть клиентов еще и подключается к камерам напрямую, минуя центральный сервер. В итоге камера, которая по замыслу должна была спокойно отдавать два потока, начинает обслуживать четыре, пять или шесть одновременных сессий.

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

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

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

Для простоты представим типовой объект с десятью IP-камерами. Каждая камера выдает основной поток 4 Мбит/с и дополнительный поток 0,5 Мбит/с. На первый взгляд кажется, что все очень комфортно: 10 x 4 Мбит/с = 40 Мбит/с на запись, и еще 10 x 0,5 Мбит/с = 5 Мбит/с на легкий просмотр. Итого около 45 Мбит/с. На гигабитной сети вроде бы даже смешно переживать. Но дальше в картину входят реальные пользователи. Один оператор открывает сетку из всех камер и берет 10 sub stream, это еще 5 Мбит/с. Второй оператор разворачивает две камеры в полный экран, это уже еще 8 Мбит/с. Удаленный начальник охраны открывает четыре камеры через WAN, и пусть даже в sub stream, это еще 2 Мбит/с плюс накладные расходы. Модуль видеоаналитики работает по основному потоку на трех критичных камерах, еще 12 Мбит/с. Облачный сервис получает тревожные клипы и метаданные. И вот система, которая в проекте выглядела как скромные 45 Мбит/с, уже легко превращается в 60, 70 или 80 Мбит/с только по видеочасти. А если где-то есть прямые подключения к камерам вместо серверной ретрансляции, эта цифра начинает расти еще веселее.

При этом важно понимать, что дело не только в полосе пропускания. Лишние потоки нагружают не только сеть, но и сами камеры, серверы, клиентские станции и декодирующие узлы. Камера должна параллельно кодировать, обслуживать сетевые соединения, иногда держать разные профили потока, а на дешевых моделях это быстро приводит к странным симптомам: скачет задержка, отваливается второй поток, проседает FPS, глючит web-интерфейс, нестабильно работают ONVIF-события. Видеонаблюдение вообще умеет очень артистично демонстрировать, что «почти хватает» и «хватает» в инженерии разделяет целая пропасть.

Отдельный вопрос, о котором тоже часто забывают, это то, какой поток используется для аналитики и детекторов. Многие по привычке думают, что если в системе есть детектор движения или модуль распознавания, то он как-то существует отдельно от видео. На практике нет. Аналитика почти всегда работает на видеоданных, а значит, тоже потребляет поток. И дальше начинается важная инженерная развилка. Если детектор работает по sub stream, нагрузка одна. Если по main stream, особенно в высоком разрешении и с H.265, нагрузка уже совсем другая. Если аналитика расположена в самой камере, нагрузка на сеть может быть ниже, но выше требования к самой камере. Если аналитика серверная, надо считать и входящий поток, и вычислительные ресурсы CPU или GPU, и внутренние перемещения данных между сервисами. И это уже не абстрактная теория, а то место, где сеть, вычисления и архитектура перестают быть разными темами и начинают жить одной общей жизнью.

Еще интереснее становится, когда система имеет локальные и удаленные сервисы одновременно. Например, запись идет на локальном сервере, но события отправляются в облако. Оператор работает на объекте, а руководитель смотрит камеры из центрального офиса. Архив хранится локально, но тревожные клипы дублируются во внешний контур. В этом случае нельзя считать только локальный коммутатор и трафик внутри объекта. Нужно учитывать uplink, интернет-канал, резервные маршруты, ограничения по VPN, приоритеты QoS и поведение системы в моменты пиковых событий. Потому что спокойный режим и тревожный режим для видеонаблюдения, это две очень разные реальности. В спокойном режиме камера просто пишет. В тревожном режиме она может одновременно начать отправлять фото, клип, метаданные, включить live-view на нескольких рабочих местах и еще разбудить мобильные клиенты. И если все это не было учтено заранее, неприятный сюрприз приходит ровно тогда, когда система особенно нужна.

Отсюда следует довольно простое, но важное правило. При проектировании системы видеонаблюдения нужно считать не только среднюю постоянную нагрузку, но и сценарии пикового потребления. Сколько потоков будет в обычный рабочий день. Сколько потоков появится при открытии полной сетки на нескольких постах. Что произойдет, если оператор начнет одновременно смотреть архив и live-view. Как изменится нагрузка при срабатывании аналитики. Будет ли сервер сам раздавать клиентам уже полученный поток или каждый клиент полезет в камеру заново. Есть ли транскодирование. Есть ли адаптивные профили. Работает ли мобильный клиент через сервер или напрямую. Это не придирки и не бюрократия. Это и есть реальная инженерия.

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

Есть и еще одна проблема. Когда в расчетах забывают про дополнительные потоки, обычно одновременно забывают и про запас. А видеонаблюдение, как и любая живая инфраструктура, почти никогда не стоит на месте. Сегодня на объекте 10 камер, завтра 14. Сегодня один оператор, завтра два поста и мобильный доступ. Сегодня запись только локальная, завтра появляется облачная репликация. Сегодня детекция движения, завтра распознавание лиц и номеров. Если система спроектирована впритык, без учета скрытой многопоточности, любое развитие превращается в маленькую реконструкцию с большим количеством разговоров о том, почему «раньше вроде работало».

Поэтому правильный подход к проектированию звучит так: у каждой камеры нужно учитывать все реально используемые профили потока и всех реальных потребителей этих потоков. Отдельно считать запись. Отдельно live-view. Отдельно удаленные рабочие места. Отдельно серверную или облачную аналитику. Отдельно мобильный доступ, ретрансляцию, экспорт, тревожные клипы и межсерверный обмен. И только после этого подбирать каналы связи, коммутаторы, серверы и настройки битрейта. Иначе проектируется не система, а надежда.

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

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