Сети для самых маленьких. Часть 9.1. Мультикаст. Общее понимание Multicast
Наш умозрительный провайдер linkmeup взрослеет и обрастает по-тихоньку всеми услугами обычных операторов связи. Теперь мы доросли до IPTV.
Отсюда вытекает необходимость настройки мультикастовой маршрутизации и в первую очередь понимание того, что вообще такое мультикаст.
Это первое отклонение от привычных нам принципов работы IP-сетей. Всё-таки парадигма многоадресной рассылки в корне отличается от тёплого лампового юникаста.
Можно даже сказать, это в некоторой степени бросает вызов гибкости вашего разума в понимании новых подходов.
В этой серии статей сосредоточимся на следующем:
Содержание серии статей про мультикаст
На заре моего становления, как инженера, тема мультикаста меня неимоверно пугала, и я связываю это с психотравмой моего первого опыта с ним.
«Так, Марат, срочно, до полудня нужно пробросить видеопоток до нашего нового здания в центре города — провайдер отдаст его нам тут на втором этаже» — услышал я одним чудесным утром. Всё, что я тогда знал о мультикасте, так это то, что отправитель один, получателей много, ну и, кажется, протокол IGMP там как-то задействован.
В итоге до полудня мы пытались всё это дело запустить — я пробросил самый обычный VLAN от точки входа до точки выхода. Но сигнал был нестабильным — картинка замерзала, разваливалась, прерывалась. Я в панике пытался разобраться, что вообще можно сделать с IGMP, тыркался, тыркался, включал мультикаст роутинг, IGMP Snooping, проверял по тысяче раз задержки и потери — ничего не помогало. А потом вдруг всё заработало. Само собой, стабильно, безотказно.
Это послужило мне прививкой против мультикаста, и долгое время я не проявлял к нему никакого интереса.
Уже гораздо позже я пришёл в к следующему правилу:
И теперь с высоты оттраблшученных кейсов я понимаю, что там не могло быть никаких проблем с настройкой сетевой части — глючило конечное оборудование.
Сохраняйте спокойствие и доверьтесь мне. После этой статьи такие вещи вас пугать не будут.
Общее понимание Multicast
Как известно, существуют следующие типы трафика:
Unicast Одноадресная рассылка — один отправитель, один получатель. (пример: запрос HTTP-странички у WEB-сервера). Broadcast Широковещательная рассылка — один отправитель, получатели — все устройства в широковещательном сегменте. (пример: ARP-запрос). Multicast Многоадресная рассылка — один отправитель, много получателей. (пример: IPTV). Anycast Одноадресная рассылка ближайшему узлу — один отправитель, вообще получателей много, но фактически данные отправляются только одному. (пример: Anycast DNS).
Раз уж мы решили поговорить о мультикасте, то, пожалуй, начнём этот параграф с вопроса, где и как он используется.
Первое, что приходит на ум, — это телевидение (IPTV) — один сервер-источник отправляет трафик, который хочет получать сразу много клиентов. Это и определяет сам термин — multicast — многоадресное вещание. То есть, если уже известный вам Broadcast означает вещание всем, мультикаст означает вещание определённой группе.
Второе применение — это, например, репликация операционной системы на множество компьютеров разом. Это подразумевает загрузку больших объёмов данных с одного сервера.
Возможные сценарии: аудио и видеоконференции (один говорит — все слушают), электронная коммерция, аукционы, биржи. Но это в теории, а на практике редко тут всё-таки используется мультикаст.
Ещё одно применение — это служебные сообщения протоколов. Например, OSPF в своём широковещательном домене рассылает свои сообщения на адреса 224.0.0.5 и 224.0.0.6. И обрабатывать их будут только те узлы, на которых запущен OSPF.
Сформулируем два основных принципа мультикастовой рассылки:
В данной статье для практики мы возьмём IPTV, как наиболее наглядный пример.
Пример 1
Начнём с самого простого случая:
На сервере-источнике настроено вещание в группу 224.2.2.4 — это означает, что сервер отправляет трафик на IP-адрес 224.2.2.4. На клиенте видеоплеер настроен принимать поток группы 224.2.2.4.
При этом, заметьте, клиент и сервер не обязательно должны иметь адреса из одной подсети и пинговать друг друга — достаточно, чтобы они были в одном широковещательном домене. Мультикастовый поток просто льётся с сервера, а клиент его просто принимает. Вы можете попробовать это прямо у себя на рабочем месте, соединив патчкордом два компьютера и запустив, например, VLC.
Надо заметить, что в мультикасте нет никакой сигнализации от источника, мол, «Здрасьте, я Источник, не надо немного мультикаста?». Сервер-источник просто начинает вещать в свой интерфейс мультикастовые пакеты. В нашем примере они напрямую попадают клиенту и тот, собственно, сразу же их и принимает.
Если на этом линке отловить пакеты, то вы увидите, что мультикастовый трафик — это ни что иное, как море UDP-пакетов.
Содержимое мультикастового трафика
Мультикаст не привязан к какому-то конкретному протоколу. По сути, всё, что его определяет — адреса. Однако, если говорить о его применении, то в абсолютном большинстве случаев используется именно UDP. Это легко объясняется тем, что обычно с помощью многоадресной рассылки передаются данные, которые нужны здесь и сейчас. Например, видео. Если кусочек кадра потеряется, и отправитель будет пытаться его послать повторно, как это происходит в TCP, то, скорее всего, этот кусочек опоздает, и где его тогда показывать? Поезд ушёл. Ровно то же самое со звуком.
Соответственно не нужно и устанавливать соединение, поэтому TCP здесь ни к чему.
Чем же так разительно отличается мультикаст от юникаста? Думаю, у вас есть уже предположение. И вы, наверняка, правы.
В обычной ситуации у нас 1 получатель и 1 отправитель — у каждого из них один уникальный IP-адрес. Отправитель точно знает, куда надо слать пакет и ставит этот адрес в заголовок IP. Каждый промежуточный узел благодаря своей таблице маршрутизации точно знает, куда переслать пакет. Юникастовый трафик между двумя узлами беспрепятственно проходит сквозь сеть. Но проблема в том, что в обычном пакете указывается только один IP-адрес получателя.
Что делать, если у одного и того же трафика несколько получателей? В принципе можно расширить одноадресный подход и на такую ситуацию — отправлять каждому клиенту свой экземпляр пакета. Клиенты не заметят разницы — хоть он один, хоть их тысяча, но разница будет отчётливо различима на ваших каналах передачи данных.
Зависимость нагрузки на сеть от количества пользователей при передаче юникаст и мультикаст трафика
Предположим у нас идёт передача одного SD-канала с мультикаст-сервера. Пусть, он использует 2 Мб/с. Всего таких каналов 30, а смотрит каждый канал по 20 человек одновременно. Итого получается 2 Мб/с * 30 каналов * 20 человек = 1200 Мб/с или 1,2 Гб/с только на телевидение в случае одноадресной рассылки. А есть ведь ещё HD каналы, где можно смело умножать эту цифру на 2. И где тут место для торрентов?
Вот почему в IPv4 был заложен блок адресов класса D: 224.0.0.0/4 (224.0.0.0-239.255.255.255). Адреса этого диапазона определяют мультикастовую группу. Один адрес — это одна группа, обычно она обозначается буквой «G».
То есть, говоря, что клиент подключен к группе 224.2.2.4, мы имеем ввиду, что он получает мультикастовый трафик с адресом назначения 224.2.2.4.
Пример 2
Добавим в схему коммутатор и ещё несколько клиентов:
Мультикастовый сервер по-прежнему вещает для группы 224.2.2.4. На коммутаторе все 4 порта должны быть в одном VLAN. Трафик приходит на коммутатор и по умолчанию рассылается во все порты одного VLAN’а. Значит все клиенты получают этот трафик. На них на всех в видеопроигрывателе так же указан групповой адрес 224.2.2.4.
Собственно, все эти устройства становятся членами данной мультикастовой группы. Членство в ней динамическое: кто угодно, в любой момент может войти и выйти из неё.
В данной ситуаци трафик будут получать даже те, кто этого в общем-то и не хотел, то есть на нём не запущен ни плеер, ни что бы то ни было другое. Но только, если он в том же VLAN’е. Позже мы разберёмся, как с этим бороться.
Обратите внимание, что в данном случае от сервера-источника приходит только одна копия трафика на коммутатор, а не по отдельной копии на каждого клиента. И в нашем примере с SD каналами загрузка порта между источником и коммутатором будет не 1,2 Гб/с, а всего 60 Мб/с (2Мб/с * 30 каналов).
Собственно говоря, весь этот огромный диапазон (224.0.0.0-239.255.255.255) можно использовать. Ну, почти весь — первые адреса (диапазон 224.0.0.0/23) всё-таки зарезервированы под известные протоколы.
| Адрес | Значение |
|---|---|
| 224.0.0.0 | Не используется |
| 224.0.0.1 | Все узлы данного сегмента |
| 224.0.0.2 | Все мультикастовые узлы данного сегмента |
| 224.0.0.4 | Данный адрес выделялся для покойного протокола DVMRP |
| 224.0.0.5 | Все OSPF-маршрутизаторы сегмента |
| 224.0.0.6 | Все DR маршрутизаторы сегмента |
| 224.0.0.9 | Все RIPv2-маршрутизаторы сегмента |
| 224.0.0.10 | Все EIGRP-маршрутизаторы сегмента |
| 224.0.0.13 | Все PIM-маршрутизаторы сегмента |
| 224.0.0.18 | Все VRRP-маршрутизаторы сегмента |
| 224.0.0.19-21 | Все IS-IS-маршрутизаторы сегмента |
| 224.0.0.22 | Все IGMP-маршрутизаторы сегмента (v2 и v3) |
| 224.0.0.102 | Все HSRPv2/GLBP-маршрутизаторы сегмента |
| 224.0.0.107 | PTPv2 — Precision Time Protocol |
| 224.0.0.251 | mDNS |
| 224.0.0.252 | LLMNR |
| 224.0.0.253 | Teredo |
| 224.0.1.1 | NTP |
| 224.0.1.39 | Cisco Auto-RP-Announce |
| 224.0.1.40 | Cisco Auto-RP-Discovery |
| 224.0.1.41 | H.323 Gatekeeper |
| 224.0.1.129-132 | PTPv1/PTPv2 |
| 239.255.255.250 | SSDP |
Диапазон 224.0.0.0/24 зарезервирован под link-local коммуникации. Мультикастовые пакеты с такими адресами назначения не могут выходить за пределы одного широковещательного сегмента.
Диапазон 224.0.1.0/24 зарезервирован под протоколы, которым необходимо передавать мультикаст по всей сети, то есть проходить через маршрутизаторы.
Вот, собственно, самые базисные вещи касательно мультикаста.
Мы рассмотрели простую ситуацию, когда источник и получатель находятся в одном сегменте сети. Трафик, полученный коммутатором, просто рассылается им во все порты — никакой магии.
Но пока совсем непонятно, как трафик от сервера достигает клиентов, когда между ними огромная провайдерская сеть линкмиап? Да и откуда, собственно, будет известно, кто клиент? Мы же не можем вручную прописать маршруты, просто потому что не знаем, где могут оказаться клиенты. Не ответят на этот вопрос и обычные протоколы маршрутизации. Так мы приходим к пониманию, что доставка мультикаст — это нечто совершенно новое для нас.
Вообще, чтобы доставить мультикаст от источника до получателя на данный момент существует много протоколов — IGMP/MLD, PIM, MSDP, MBGP, MOSPF, DVMRP.
Мы остановимся на двух из них, которые используются в настоящее время: PIM и IGMP.
С помощью IGMP конечные получатели-клиенты сообщают ближайшим маршрутизаторам о том, что хотят получать трафик. А PIM строит путь движения мультикастового трафика от источника до получателей через маршрутизаторы.
Использование протоколов PIM и IGMP на участках сети
Мультикаст
Что такое мультикаст? Наверняка хоть один из читателей данной статьи задастся таким вопросом, поэтому необходимо пояснить смысл данного термина. Multicast – с английского групповая передача. Легче не стало? J Разберемся чуть подробнее. По-русски – multicast – мультивещание. Это форма широковещания, при которой используется принцип от одного к многим. Мультикаст различают по уровням передачи:
Думаю, что все еще довольно все размыто. Давайте разберемся на примере. В Интернете существуют разные рассылки. Пусть это будет в нашем случае подписка на видеоуроки по программированию на почту. Многоадресное вещание использовать учителю намного проще, так как он посылает единственный экземпляр урока, и он доходит всем, кто подписался на рассылку. Когда учитель добавляет новых учеников, ему не нужно увеличивать мощность и пропускную способность оборудования, это, безусловно, большой плюс мультикасту.
Но более ясный пример служит телевидение. Один сервер и тысячи клиентов. Он вещает определенной группе, в отличии от Broadcast, что делает процесс передачи картинки и звука зрителю удобным. Эта технология называется IPTV. С помощью нее можно обойтись без необходимости использовать спутниковую тарелку или антенну, чтобы посмотреть любимый канал, все приходит в ваш дом посредством интернет-канала.
Что такое мультикаст в роутере?
Как всем современным пользователям известно, роутер это такая коробочка, которая раздает Интернет на наши девайсы. Любимый Wi-Fi. Но не все знают, что через роутер можно передавать телевизионный сигнал, так называемое телевидение IPTV. Производители беспроводных маршрутизаторов сейчас все чаще включают поддержку IPTV на уровне аппаратных компонентов и низкоуровневого ПО в свои агрегаты. Давайте попробуем разобраться как же все-таки настроить эту функцию у себя дома, если ваш роутер поддерживает данный формат телепередачи.
Мультикаст настройка
К сожалению, настройка во многом зависит от той модификации, к которой принадлежит ваш роутер. Перед пользователем стоит задача: правильно задействовать данную функцию на своем маршрутизаторе. Давайте коротко разберем тот вариант, который может подойти роутерам от компании ASUS. Для начала включаем любой девайс (телефон, планшет, ноутбук) и подключаем его к вашему домашнему Wi-fi. Открываем браузер и вводим адрес 192.168.1.1. Наверняка он будет правильным, но стоит на всякий случай его уточнить в инструкции (руководство пользователю) к роутеру. Логин и пароль, если вы ничего не меняли будет идентичным – admin.
На открывшемся сайте мы переходим во вкладку ЛВС – «Маршрут». Находим пункт многоадресная маршрутизация. Включаем его, ставим галочку. Конечно же, не забудем сохранить настройки. Далее открываем вкладку «управление девайсом» — WAN – «Интернет-соединения» и даем определенному порту, например, второму, эту задачу.
Выбираем правильный роутер для IPTV
Напомним, что роутер работает с IPTV только через мультикаст, а значит, нам нужен такой роутер, который бы поддерживал данную функцию. Она называется IGMP. Если возникло желании подключить ресивер для цифрового ТВ, эта функция называется STB, необходимо это учесть заранее, так как к маршрутизаторам, которые работают с IPTV через UDP-to-HTTP, подключить ресивер нет возможности. Думаю, не будет лишнем предоставить топ-десятку лучших маршрутизаторов с поддержкой IPTV:
Отличия мультикаст и юникаст
Юникаст (Unicast) – технологический термин, который обозначает похожие с мультикастом функции. Правда, Юникаст – это односторонняя передачи информации единственному адресату. Как вы могли заметить, это полна противоположность широковещательной схеме маршрутизации, то есть мультивещание. У Юникаста есть определенный IP адрес, для которого он предназначен. У мультикаста же есть свои зарезервированные «айпишники», которые они используют для дальнейшего пункта назначения.
Передающий хост в заголовке Юникаста оставляет свой IP адрес, как источник, а IP принимающего, как адрес получателя. Пакеты Юникаст могут использовать всю сеть и подсети, чтобы выполнить эту задачу.
Юникаст в отличии от мультикаста доступен обычному пользователю, что делает его, конечно, предпочтительнее для непрофессионалов.
Современные технологии активно пытаются стать частью нашей жизни, а значит мы должны стараться научиться разбираться в них, даже если иногда будет немножко тяжело. Удачи!
Настройка Multicast в системах видеонаблюдения
Настройка Multicast в системах видеонаблюдения
Мультикаст (multicast) – технология передачи данных, позволяющая доставить одни и те же данные большому числу пользователей, не перегружая при этом источник данных и сеть.
При использовании multicast в системе видеонаблюдения камера или видеосервер отправляет в сеть один единственный поток данных, который затем дублируется маршрутизатором или коммутатором с функцией маршрутизации мультикаст-трафика.
Поток может приниматься практически неограниченным количеством пользователей. Например, поток с видеосервера может приниматься на десятках рабочих мест операторов видеонаблюдения, не нагружая при этом ни видеосервер, ни сетевой порт видеосервера.
Для применения технологии multicast необходимо выполнение следующих условий:
Преимуществами мультикаста являются:
Также мультикаст не пригоден для работы с архивами видеосервера с удаленных рабочих мест. При просмотре архива подразумевается выборочное воспроизведение записей на разных рабочих местах. Это, в свою очередь, вынуждает использовать «традиционный» Unicast и, соответственно, увеличивать трафик сети.
Но если вы все же хотите использовать в своей системе мультикаст, нужно его включить. Однако перед включением обязательно проверьте, что сСетевое оборудование не блокирует мультикаст трафик, а в настройках вашего VLC плеера нет флажка RTP поверх RTSP (TCP).
Для разного оборудования для видеонаблюдения мультикаст включается по разному. Приведем несколько примеров.
Dahua
Адрес UDP по умолчанию — 224.1.2.3, диапазон изменения — 224.X.X.X.to 239.X.X.X
OMNY PRO
Включение мультикаст выполняется в WEB интерфейсе.
Заходим Configuration—Advance Set—Access Platform—PU SetRegister Server> вводим адреса между 224—239 сегментом, например, 224.168.1.100, указываем порт 10102.
Сохраняем, устройство перезагружается. Открываем VLC плеер для проверки (Media /открыть URL/сеть) и вводим строку запроса udp://@224.168.1.100:10102 (соответствующий адрес и порт).
Новые модели имеют другое расположение настроек мультикаст:
Configuration>>network management>>Network Service>>MUC
OMNY Base
Включение мультикаст выполняется в WEB интерфейсе. Путь Settings/Network/RTSP — Multicast Settings / Enable Multicast, затем вводим адреса между 224—239 сегментом, например, 224.1.2.3, указываем порт 10000 и сохраняем.
Открываем VLC плеер для проверки (Медиа/открыть URL/сеть) и вводим строку запроса как RTSP.
Убедитесь, что в настройках вашего VLC плеера нет флажка RTP поверх RTSP (TCP).
Вот, пожалуй, и все. Мы же напоминаем, что наша компания «Запишем всё» с 2010 года занимается проектированием, монтажом, обслуживанием и ремонтом систем видеонаблюдения и видеодомофонов в Москве и Подмосковье.
Мы работаем быстро, качественно и по доступным ценам. Перечень услуг и цены на их вы можете посмотреть здесь.
Звоните +7 (499) 390-28-45 с 8-00 до 22-00 в любой день недели, в том числе и в выходные. Мы будем рады Вам помочь!
Передача видео Multicast: простые решения сложных проблем
Илья Назаров
Системный инженер
компании «Интелком лайн»
Рассмотрим некоторые конкретные задачи, которые могут возникнуть при работе с IP-сетями.
Обеспечение надежности передачи Multicast
На сегодня различные возможности QoS реализованы практически на любом сетевом оборудовании. С принципами их работы и примерами настроек можно ознакомиться в Интернете, поэтому рассматривать их не будем. Сложности возникают, когда даже при обеспечении гарантированной пропускной способности на канале все равно возникают потери пакетов. Такая ситуация типична для каналов последней мили, где потери пакетов происходят вследствие ошибок на физическом уровне. Наиболее актуальной данная проблема является для операторов услуг IPTV, которые не всегда могут обеспечить качественный канал до оборудования абонента Производители решений IPTV решают данную проблему, встраивая возможность повторной отправки потерянного пакета. В общем случае для этого используются специальные серверы, кэширующие видеопотоки, которые устанавливаются на периферийных узлах. Абонентские устройства (set top box) отслеживают состояние потоков и при возникновении потерь пакетов запрашивают повторную передачу этих пакетов у ближайшего сервера. Если поток передается в формате Multicast, повторные пакеты передаются абонентскому устройству в виде Unicast, чтобы не нагружать каналы других пользователей.
В настоящее время ведутся разработки стандартного протокола Pragmatic General Multicast (RFC 3208), который также предназначен для отслеживания потерь пакетов Multicast и повторной их отправки. Некоторые производители сетевого оборудования и операционных систем уже реализуют функционал PGM в своих продуктах.
Передача поверх сетей Unicast
В качестве примера можно привести популярную утилиту OpenVPN с открытым исходным кодом, которая может работать в любом из этих режимов. Режим маршрутизации здесь используется по умолчанию, в этом случае создается виртуальный TUN-интерфейс с присвоенным IP-адресом. Для настройки туннеля в режиме коммутации требуется, во-первых, установить пакет утилит Bridge UtiIs, во-вторых, произвести дополнительные изменения в файле конфигурации. Вместо TUN указываем тип интерфейса ТАР (этот тип используется для прозрачной передачи кадров Ethernet) и указываем сценарии инициализации и отключения туннеля:
dev tap0
up «/etc/openvpn/up.sh»
down «/etc/openvpn/down.sh»
В сценарии инициализации (up.sh) включаем виртуальный интерфейс в режиме прозрачной передачи кадров и присваиваем ему соответствующий идентификатор bridge:
/sbin/ip link set tap0 up promise on
/usr/sbin/brctl addif br0 tap0
В сценарии отключения (down.sh) отвязывается идентификатор и отключается интерфейс:
/usr/sbin/brctl delif br0 tap0
/sbin/ip link set tap0 down
При этом в файле /etc/network/interfaces уже должны быть прописаны настройки интерфейса bridge:
auto br0
iface br0 inet static
bridge_ports eth0
На интерфейсе br0 при этом можно настроить IР-адрес, который будет использоваться для удаленного доступа на сам сервер. Таким образом, туннельный интерфейс и интерфейс локальной сети (eth0) оказываются в одной группе с общим идентификатором br0, и трафик между этими интерфейсами будет передаваться прозрачно, аналогично тому, как это делает обычный коммутатор.
Объединение доменов
Использование шлюза
Кардинальным решением при объединении доменов вещания будет использование специального шлюза. Такой вариант, несмотря на дороговизну, обладает наибольшей гибкостью и иногда является единственным способом решить проблему совместимости. Шлюз может не только осуществлять трансляцию адресов, но и полностью преобразовывать потоки на более глубоком уровне. Например, можно, принимая постоянный поток RTP из одного домена, осуществлять его перекодировку (transcoding) на лету и добавить возможность подписки на поток по протоколу RTSP в другом домене. При этом для приема и передачи потоков можно использовать адреса и Multicast, и Unicast, а также их комбинации при дублировании потоков. Решения IPTV и VoD различных производителей, как правило, содержат в себе подобный функционал, чтобы обеспечить совместимость с различными абонентскими устройствами и сетевой инфраструктурой.
Еще один вариант использования:
Опция duplicate позволяет дублировать потоки, используя разные IP-адреса и UDP-порты. В данном примере мы принимаем тот же поток и передаем его в двух экземплярах: с адресами 239.2.2.2 и 192.168.1.1. Указывая в качестве параметра dst-адреса Unicast, можно также решить проблему с передачей потока через сети, которые не поддерживают маршрутизацию Multicast.
Изучайте протоколы!
Мы рассмотрели далеко не полный список проблем, связанных с передачей IP Multicast. Но в любой ситуации поиск решения не составит труда, если специалист обладает хорошими знаниями принципов работы технологий и протоколов. Поэтому главной рекомендацией будет доскональное изучение стандартов и постоянное совершенствование своих знаний, что позволит избежать большинства проблем или свести к минимуму расходы на их решение.
Источник: Журнал «Системы безопасности» #4, 2012
