Основы работы в сети IP камер

Позвольте обсудить новичку базовую топологию подключения. Несколько ip камер, (пока 3 шт., наверное еще добавить парочку придется) на данный момент работают подключенными непосредственно к роутеру. NVR отсутствует, поскольку цель наблюдения удаленный просмотр объекта, но не исключено, что со временем возникнет необходимость в видеоархивации происходящего, а пока все работает на живую трансляцию. Все камеры используют ip адреса выдаваемые NAT службой маршрутизатора, то есть имеется одна локальная сеть 192.168.0.x, от роутера, в которой работают 3(три) ip камеры под адресами 192.168.0.11, 192.168.0.12, 192.168.0.13 и несколько других не требовательных, сетевых устройств—банковский терминал эквайринга, компьютер в качестве товароучетной системы. Поскольку, как я уже сказал, основная цель удаленное видеонаблюдение, и маршрутизатор имеет "белый", статичный ip адрес от провайдера, а все ip камеры настроены на разные порты,и есть возможность удаленно просматривать поток с камер, в основном смотрят через RTSP. Вроде бы всё понятно и топология рабочая, но мне всё же кажется, что правильнее было бы выделить ip камерам отдельную подсеть (192.168.1.x), подключив к примеру все камеры отдельно к коммутатору, а коммутатор уже в свою очередь к роутеру. Но, как потом связать эту новую подсеть (192.168.1.x) ip камер с существующей от роутера (192.168.0.1)? У будет ли она доступна извне, через интернет по прежнему? И в целом, будет ли эффективна такая настройка в плане производительности, сократятся ли задержки? Сейчас например задержки в трансляции наблюдаются, не критичные, но есть, где-то около секунды, полторы. Одним словом, как-то так, буду рад и признателен, если кому-то интересно будет на эту дилетантскую тему пообщаться и помочь, спасибо.

Реализовать проброс портов через роутер - вы можете для любого логического сегмента сети и это как раз не проблема, только вот никакого положительного результат в виде прироста скорости - вы не получите, потому как на физическом уровне - сеть всё равно будет одна.

Можно конечно сделать две физические сети - одну под видео - на одном коммутаторе, другую - под офисные приложения - на другом, ну а в роутере установить три сетевые карты, - две под локальные сети и одну под сеть интернет.

- НО УЗКИМ МЕСТОМ ДЛЯ УДАЛЕННОГО ПРОСМОТРА - останетается ширина интернет канал, которая будет и в этом случае делиться между пользователями офисных приложений и пользователями видеосистемы.

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

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

спасибо за развернутый ответ прежде всего, всё достаточно понятно, но есть некоторые моменты:

- НО УЗКИМ МЕСТОМ ДЛЯ УДАЛЕННОГО ПРОСМОТРА

Может ли узким местом для удаленного просмотра являться физическое устройство, в моем случае бытовой роутер с трансляцией адресов. Ширина интернет канала в данном месте достаточна, это синхронный канал на 100 м/бит, замер закачки дает более чем хороший результат, загрузка файлов со скоростью 7-8 МБ/с, именно 7-8 мегабайт в секунду, почти такая же скорость на выгрузку, то есть ip камеры имеют широкий канал на трансляцию видео. Но, вот задержки,? Возможно ли, что простой, слабый по производительности роутер тормозит поток с камер и внутри локальной сети и для удаленного зрителя? Ведь поток с камер и внутри локальной сети не совсем в реальном времени! Задержки может и не драматические, но разве внутри шустрой, не загруженной 100 мегабитной, локальной сети они должны иметь место!? Мои подозрения на данный момент к сожалению голословны, следовало бы вначале создать одноранговую сеть без роутера и подключив все камеры к обычному коммутатору оценить качество видео реального времени в локальной сети, но как-то сразу об этом не додумался честно говоря, но постараюсь подобный эксперимент провести при первой возможности.

в моем случае бытовой роутер с трансляцией адресов

Что подразумевается под словом бытовой роутер: - это эзернет-коммутатор второго уровня с аппаратным роутером на борту? Или это же это некий роутер-сервер на базе персонального компьютера? Или это некий железный-роутер - ADSL модем? Или же это некий оптический модем технологии G-PON?

Короче - название то у модели Вашего роутера хоть какое-то есть?

загрузка файлов со скоростью 7-8 МБ/с, именно 7-8 мегабайт в секунду

Это скорость передачи файлов имеющих конечный размер и не требующей жестко фиксированного времени для их передачи, Вам же - важна скорость передачи непрерывного видеопотока с очень жесткими временными рамками - нужно успеть передать именно n-кадров (причем имеющих вполне определенный и не малый размер) каждую секунду. Так что передача файла и передача потока - это разные вещи. Да к тому же и скорость исходящего потока - зачастую не бывает выше скорости входящего - так уж устроен эзернет.

Но, вот задержки,?

Задержи при передачи потокового IP видео складываются из многих факторов.

Ну а для того чтобы ориентировочно определить какова же доля в возникновении задержек связана с работой самой сети - можете просто провести процедуру трассировки от Вашего удаленного (локального) места просмотра - до камеры.

- это не так сложно:

Как несложно понять из примера выше, задержка в получении IP пакетов на моем рабочем месте от сервера на котором расположен сайт http://www.security-bridge.com/ составляет 466 мс (1000мс в 1сек) следовательно если бы данный сервер имел видеовещание - то задержка в получении с данного сервера видеопотока сжатого даже кодеком MJPEG - составила бы приблизительно полсекунды.

И это в лучшем случае.

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

Ну и заканчивая производительностью конечно же Вашего компьютера, которая будет уже напрямую зависит от параметров сжатия видеопотока: - чем больше процент сжатие, но с сохранением максимально возможного качества самой картинки - тем поток получается более "тяжелом" для декодирования, а это так уже приводит к задержкам непосредственно на приемной стороне, и связанны данные задержки - с необходимостью буферизации для декодирования потока MGPE-X именно - удаленным PC (причем в Вашем случае - обрабатывающем уже сейчас, три потока одновременно).

Или это некий железный-роутер - ADSL модем?

Простонародный зухель, Zyxel Kinetic. Получает инет по витой паре от провайдера в WAN порт (настроен статичный, "белый" адрес), раздает через NAT в локалку. В настройках этого маршрутизатора есть возможность отключения NAT в локалку и настройки статической маршрутизации, но я так понимаю, это не прокатит с одним реальным адресом от провайдера? Или можно будет без NAT маршрутизировать внутренние адреса типа (192.168.0.10) наружу?

Ну а для того чтобы ориентировочно определить какова же доля в возникновении задержек связана с работой самой сети - можете просто провести процедуру трассировки от Вашего удаленного (локального) места просмотра - до камеры.

До ip адреса роутера трейсрут таков:

А вот конкретно до камеры "трейснуть" окончательно не удается. В конце вечные "звездочки".

Может устройства которые за нестандартными портами скрыты нужно трейсрутить по другому? Пробовал ipadress:номерпорта, но такой адрес команда не принимает. Могу временно одну из камер вывести в DMZ, чтобы все порты были доступны, если это момент существенен. Поскольку кроме того, что камеры под нестандартными портами настроены, также переброшены и открыты только необходимые порты, 8000, 80, 554.

Вообще, я бы с удовольствием избавился от этого роутера и приобрел бы коммутатор второго уровня, чтобы так сказать выжить из инет канала максимум. Но, вот, к сожалению не совсем до конца понимаю, как будут работать внутренние, локальные адреса с одним, "белым", можно ли будет без NAT, с помощью статической маршрутизации решить эту задачу?

Простонародный зухель, Zyxel Kinetic.

С возможностями данного роутера - лично я к сожалению не знаком.

Или можно будет без NAT маршрутизировать внутренние адреса типа (192.168.0.10) наружу?

Пробрасывать в этом случае Вы будете не IP адреса, а пробрасываете порты.

Но вот только как при (как Вы говорите белом IP) и насколько я понимаю он у Вас 87.117.134.105, вдруг - ваша камера стала иметь наружний IP 87.117.134.106 вот этого я что-то не понимаю.

По идее либо IP 87.117.134.106 принадлежать не Вам, либо же всеми пробросами рулит ваш провайдер и пользуетесь тогда Вы NAT службой вашего провайдера , а вовсе не своей собственной.

А как Вы вообще удаленно подключаетесь к камерам

- через IE и три разных порта, ну типа того 87.117.134.105:8081, 87.117.134.105:8082, 87.117.134.105:8083,

или через разные IP x.x.x.106 ( x.x.x.107, x.x.x.108)

или же через удаленный клинский софт,

или же просто через некий облачный сервис?

Но вот только как при (как Вы говорите белом IP) и насколько я понимаю он у Вас 87.117.134.105, вдруг - ваша камера стала иметь наружний IP 87.117.134.106 вот этого я что-то не понимаю.

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

да, именно так. Внешний айпи адрес один. Поток смотриться через rtsp, на VLC, это если со стационарных компьютеров, ipadress:554,555,556. С планшетов и смартфонов с помощью фирменной утилиты, там также, только там порты 80xx. Можно также через http, через браузер, на контрольную панель камеры лезть и смотреть трансляцию оттуда, но это несколько криво реализовано, поэтому наиболее практичный и эффективный способ снимать поток по RTSP.

Пробрасывать в этом случае Вы будете не IP адреса, а пробрасываете порты.

То есть можно избавиться от домашнего роутера и заменить его "взрослым" коммутатором второго уровня ? Я вообще так предполагаю, что топология "камеры в soho роутер" в проектировании серьезного ip видеонаблюдения не имеет право на жизнь? По хорошему нужно подобрать "правильную" железку для управления ip камерами? Управляемый коммутатор второго/третьего уровня? Что-то можете посоветовать из классики? Я понимаю, что в моем случае это избыточно и цена там другие, но все-же для общего развития хотелось бы понять.

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

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

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

:-))

Ну теперь осталось выпустить все камеры в DMZ. просто разграничив IP форвардинг по разным портами на три разных локальных IP адреса.

А вообще, судя по Вашим скринам и по тому так быстро Вы нашли решение с DMZ и насколько я понимаю

- Вы же сидите под консольными Unix-сами?

И похоже что это мне у Вас - впору консультироваться!

;-))

105 это адрес железки провайдера, который стоит адресом шлюза в настройках моего роутера. Выделенный провайдером адрес хоста 106,

Да-уж, что-то замес жуткий получается :-(( аж через два NAT-та, через Ваш собственный в Zyxel Kinetic и через NAT роутера провайдера установленного видимо у Вас в здании.

Вот Вам и лишний хоп, - с дополнительными задержками на еще одной переадресации. :-((

но это несколько криво реализовано, поэтому наиболее практичный и эффективный способ снимать поток по RTSP.

Существует - вот такая вещь Luxriot - попробуйте, может понравиться, там ничего сложного нет, правда она под винду и под вайном не поднимется, но это всяко удобней - чем открывать 3 окна VLC.

Ну теперь осталось выпустить все камеры в DMZ. просто разграничив IP форвардинг по разным портами на три разных локальных IP адреса.

В DMZ железка более одного устройства не пускает; думаете ip камерам/nvr необходима работа "нараспашку", минимально необходимого диапазона портов открыть и перебросить не достаточно? У меня из открытых для камер только лишь; 80, 8000, 554, 443, трансляция с этими портами работает. Причина задержек может быть связана с недоступностью еще неких портов? Вы рекомендуете вынести все камеры в демилитаризированную зону, или я не так Вас понял?

знания у меня очень поверхностные, поверьте наслово, я не тролль ;) и на самом деле нуждался/нуждаюсь в консультации. Консоль никсовая, да, но я за макинтош работаю в основном, поэтому и терминал пришлось запустить. Поэтому, продолжайте пожалуйста консультировать по мере возможности, я думая многие начинающие будут благодарны и много нового узнают для себя из подобных обсуждений, и я конечно же в первую очередь.

Существует - вот такая вещь Luxriot - попробуйте,

Вообще, в целом фирменная утилита Hikvision, а камеры именно этой марки, достаточно не плоха, и десктопная и на мобильные платформы android/ios, но как-то VLC подхватывает и транслирует бодрее что-ли, поэтому чаще всего запускаю ее. За ссылку спасибо, попробую обязательно в действии.