69574

Основы группового вещания в IPv4

Практическая работа

Информатика, кибернетика и программирование

Традиционные методы взаимодействия по протоколу IP позволяют отправлять пакеты одному узлу (одноадресная передача) или всем узлам одновременно (широковещательная передача). Многоадресная (групповая) IP-рассылка предоставляет третью возможность...

Русский

2014-10-07

1.18 MB

4 чел.

Урок 14

Основы группового вещания в IPv4

Традиционные методы взаимодействия по протоколу IP позволяют отправлять пакеты одному узлу (одноадресная передача) или всем узлам одновременно (широковещательная передача). Многоадресная (групповая) IP-рассылка предоставляет третью возможность - отправлять пакеты некоторому подмножеству узлов в виде групповой передачи.

Групповое вещание или Multicast является технологией экономии полосы пропускания за счет сокращения трафика однородной информации от сервера к клиентам. В основе группового вещания, как следует из названия технологии, лежит концепция группы. Группа состоит из получателей (клиентов) заинтересованных в получении определенного и однородного потока данных. У этой группы нет никаких физических или географических ограничений: хосты могут находиться в любой точке составной сети.

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

Пусть размер информации, передаваемой клиентам, составляет X байт, тогда трафик от сервера на маршрутизатор к клиентам составит X*n байт, где n – количество клиентских станций подключенных к серверу. При некотором n, трафик может достигнуть значения, которое является пиковым для пропускной способности маршрутизатора, тогда информация будет доставляться с задержками, обусловленными нехваткой полосы пропускания сети между сервером и маршрутизатором, что тем более недопустимо, если передаваемая информация является мультимедийной.

Задача заключается в создании такого механизма доставки однородной информации, при котором, количество клиентов не будет влиять на оперативность процесса доставки информации каждому клиенту. Т.е. сеть между сервером и маршрутизатором должна работать с постоянной и нормальной нагрузкой, при ЛЮБОМ количестве клиентов в корпоративной сети.

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

Но какой ценой, получено данное решение? Проанализируем поэтапно, что происходит в сети при работе предложенным методом.

На участке сервер – маршрутизатор, на канальном уровне информация передается Unicast (на конкретно заданный адрес), т.е. адрес отправителя соответствует МАС адресу интерфейса сервера, адрес получателя – МАС адрес интерфейса маршрутизатора. На сетевом уровне, адрес отправителя – IP адрес сервера, а вот с адресом получателя не все так просто, для того, чтобы обработать пакет сетевого уровня необходимо знать в какую сеть он направляется, но в нашем случае пакет направляется не одному получателю – но всем участникам, подключенным через коммутатор. Пусть, в качестве адреса получателя будет указан широковещательный адрес в заданную сеть, это так же является не более чем допущением, так как для работы протоколов транспортного уровня необходим четко указанный (unicast) IP адрес получателя для формирования сокета. Итак, первый вопрос, возникший при анализе метода – заголовок IP пакета, поле IP адрес получателя.

Продолжим анализ. После обработки маршрутизатором, пакет переправляется на порт соответствующий таблице маршрутизации, где и происходит формирование кадра канального уровня, в который инкапсулируется пакет. При формировании кадра канального уровня, в соответствии с предложенным способом в поле МАС адрес получателя необходимо указать широковещательный адрес вида FF:FF:FF:FF:FF:FF. Т.е. формируется обычный широковещательный кадр. Учитывая характер передаваемого трафика, можно говорить о том, что в такой сети периодически возникают широковещательные штормы, т.е. все сегменты, подключенные к коммутатору, вынуждены транслировать один и тот же кадр. А что если в данной сети не все клиенты нуждаются в подобной услуге по доставке информации? Для них, в этом случае выбора нет – придется получать положенные кадры, анализировать содержимое, расходуя процессорное время, и все равно сбрасывать пакеты, т.к. их появление в системе не ждет ни одно приложение. Кроме этого, в результате широковещательного шторма возрастает нагрузка на коммутатор, происходит так называемый flooding или затопление коммутатора. Т.е. второй вопрос, по предложенному методу касается передачи однородного трафика на канальном уровне конечным пользователям.

Таким образом, внедрение предложенного метода связано со следующими проблемами:

  •  Содержимое поля «IP адрес получателя», при формировании пакета сетевого уровня на сервере, в адрес получателей заданной аудитории.
  •  Предотвращение широковещательного шторма при доставке трафика конечным пользователям. Возможность «выборочного широковещания», если не все участники канального сегмента являются подписчиками (потребителями трафика).

Тем более, указанные проблемы усугубляются при расширении корпоративной сети. Предположим, что подписчики обновлений находятся в разных IP сетях. Как быть в этом случае при формировании заголовка IP пакета на сервере в адрес клиентов? Широковещание в какую сеть указывать?

Вопрос по IP адресу получателя, можно решить, выделив специальный диапазон IP адресов, используемый для обозначения групп получателей независимо от их «обычных IP адресов». Тогда, при формировании заголовка IP пакета, в адрес получателя будет записан IP адрес той группы подписчиков, которой предназначается данный пакет. Так называемый групповой IP адрес.

Вопрос по широковещанию на канальном уровне решается аналогично, необходимо ввести такой тип адресов канального уровня, который бы различался коммутатором, как особый «широковещательный МАС адрес, но только участникам групповой подписки».

Ну и конечно же, необходимо систематизировать следующие взаимодействия:

  •  Способ, которым маршрутизаторы объявляют о том, подписчики какой или каких групп подключены к маршрутизатору.
  •  Способ передачи группового трафика через транзитные маршрутизаторы, не имеющие подписчиков.
  •  Механизм перевода группового IP адреса в специальный широковещательный МАС адрес только для участников группы.

Внедрение приведенных выше рекомендаций привело к возникновению самостоятельной сетевой технологии  - групповому вещанию. Из уроков по IP адресации известен диапазон адресов класса D. Это диапазон используется для присвоения группам абонентов, заинтересованных в получении однородного трафика, называемых так же – подписчики. А сам класс D называется  - Multicast. Диапазон адресов мультикаст имеет вид

224.0.0.0 – 239.255.255.255

т.е. первый байт IP адреса в двоичном виде начинается с 1110

Данный диапазон предназначен только для групповых адресов и адресов получателей многоадресного (группового) IP трафика. Адреса источников многоадресных дейтаграмм всегда unicast, т.е. в поле IP адрес отправителя всегда ставится обычный IP адрес класса A, B или C. Группа может объединять хосты в разных сетях. Членство в группе динамическое - хост может вступать в группу и выходить из группы по собственному желанию. Не существует ограничений на количество хостов в группе, и хост не должен принадлежать к группе, чтобы послать сообщение в эту группу.

Так же IANA (Internet Assigned Numbers Authority), зарезервировало адреса с 224.0.0.0 по 224.0.0.255 для идентификации сетевых протоколов локальных сетевых сегментов и протоколов динамической маршрутизации. Пакеты с такими адресами никогда не проходят через маршрутизатор, т.е. не выходят за пределы своего сегмента LAN. Их время жизни TTL = 1. Сетевые протоколы используют эти адреса для автоматического обнаружения маршрутизаторов и передачи маршрутной  информации. Ниже представлены примеры  некоторых стандартных адресов мультикаст.

  1.  все компьютеры в подсети
    1.  все маршрутизаторы в подсети

224.0.0.22  IGMP – протокол объявления о группе Multicast  

более подробный список IP адресов мультикаст можно получить по адресу

http://www.iana.org/assignments/multicast-addresses

Адреса в диапазоне 224.0.1.0 – 238.255.255.255 являются глобальными. Они могут использоваться для многоадресной передачи данных между организациями по Internet. Некоторые из этих IP адресов так же зарезервированы IANA для приложений использующих мультикаст. Например, адрес 224.0.1.1 зарезервирован для протокола NTP (Network Time Protocol).

В диапазоне с 239.0.0.0 до 239.255.255.255 содержаться адреса ограниченного радиуса действия, или административно ограниченные адреса. Они определяются в RFC 2365 как ограниченные по признаку локальной группы либо организации. Маршрутизаторы обычно имеют фильтры трафика, настроенные так, чтобы многоадресный трафик по этим адресам не выходил за пределы системы, определенной администратором.

Взаимосвязь между групповым и канальным адресом  получателя заключается в специальном методе идентификации канальных адресов, отвечающих за передачу группового трафика конечным получателям – участникам группы. IANA владеет блоком Ethernet адресов, которые в шестнадцатеричном представлении имеют стандартное начало: 00:00:5e.

Это старшие 24 бита Ethernet адреса, означающие, что блок включает адреса в диапазоне

от 00:00:5e:00:00:00 до 00:00:5e:ff:ff:ff

IANA отвела половину этого блока для групповых адресов. Установлено правило, что первый байт Ethernet адреса равный 01 указывает на групповой адрес. Это означает, что Ethernet адреса, соответствующие групповым адресам IP, должны находиться в диапазоне от 01:00:5e:00:00:00 до 01:00:5e:7f:ff:ff. Подобное расположение позволяет 23 битам в Ethernet адресе соответствовать идентификатору группы IP. В процессе преобразования адресов 23 младших бита идентификатора группы помещаются в 23 бита Ethernet адреса. Старшие 5 бит в идентификаторе группы игнорируются, так как они не уникальны. Каждому Ethernet адресу соответствует 32 различных идентификатора группы.

Например, групповой адрес 224.128.64.32 (в шестнадцатеричном представлении e0.80.40.20) и 224.0.64.32 (в шестнадцатеричном представлении e0.00.40.20) оба будут трансформированы в Ethernet адрес 01:00:5e:00:40:20.

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

Существует два варианта реализации групповой адресации в сетевых платах, использующиеся в локальных сетях. Одни осуществляют групповую фильтрацию, основанную на значении аппаратного группового адреса, что означает, что некоторые нежелательные кадры могут пройти. В другом случае имеется небольшое фиксированное количество групповых адресов, принимаемых платой, при этом, если хосту необходимо принять больше групповых адресов, чем поддерживается, интерфейс должен быть помещен в режим "разных групп" (multicast promiscuous). Однако, оба типа интерфейсов все еще требуют, чтобы драйвер устройства осуществлял проверку на предмет того, необходимо ли дальше обрабатывать принятый кадр. Даже если интерфейс осуществляет идеальную групповую фильтрацию (основанную на 48-битном аппаратном адресе) фильтрация все еще необходима, так как сопоставление IP адресов класса D и 48-битных аппаратных адресов осуществляется не один к одному. Однако, если абстрагироваться от несовершенства преобразования адресов и аппаратной фильтрации, групповая адресация все же лучше, чем широковещательная.

 Осуществить групповой запрос в единственную физическую сеть довольно просто. Отправляющий процесс указывает IP адрес назначения, который является групповым адресом, драйвер устройства конвертирует это в соответствующий Ethernet адрес и отправляет. Принимающие процессы должны указать своим IP модулям, что они хотят получать датаграммы, предназначенные определенному групповому адресу, а драйвера устройства должен, получать эти групповые кадры. Этот процесс называется "вступлением в группу". Когда групповая датаграмма получена хостом, копия доставляется всем процессам, которые принадлежат к группе. Это отличается от протокола UDP, где единственный процесс получает входящую персональную UDP датаграмму. Несколько процессов на одном хосте могут принадлежать к одной группе. Однако сложности увеличиваются, когда группа распространяется на несколько сетей, и групповые пакеты должны проходить через маршрутизаторы. Маршрутизаторам необходимо знать, принадлежат ли какие-либо хосты в данной физической сети к определенной группе. Для определения этого, существует протокол, называемый протоколом группового управления Internet (IGMP - Internet Group Management Protocol).

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

  •  Спецификация IGMP 1 описана в RFC 1112. Формат кадра IGMP v1:

В IGMP 1 предусмотрено всего два типа IGMP сообщений:

  •  запрос принадлежности;
  •  ответ о принадлежности.

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

Спецификация IGMP 2 описана в RFC 2236. Формат кадра IGMP v1:

В IGMP 1 предусмотрено уже четыре типа IGMP сообщений:

  •  запрос принадлежности;
  •  ответ о принадлежности по версии 1;
  •  ответ о принадлежности по версии 2;
  •  покинуть группу.

В основном работа IGMP 2 не отличается от IGMP 1. Разница заключается в наличии сообщения о выходе из группы. Хосты могут сообщить маршрутизатору о намерении покинуть группу. В ответ маршрутизатор отсылает группе специальный запрос, что бы определить остались ли еще хосты, желающие принимать данный трафик. Если ответа не поступает - маршрутизатор отключает группу и прекращает передачу трафика. Это значительно сокращает задержки, связанные с прекращение членства в группе по сравнению с IGMP 1.

Спецификация IGMP 3 описана в RFC 3376. В версии 3 была добавлена поддержка фильтрации адресов. С помощью этого механизма узел может сообщить, с каких адресов он хочет получать пакеты, а с каких нет. Т.е. если существует несколько источников группового трафика, хост может выбрать с какого именно источника он будет получать указанный трафик.

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

Рассмотрим пример конфигурации программного маршрутизатора R1 под управлением Windows Server, подключенного по следующей схеме

Добавим протокол IGMP в оснастке «маршрутизация и удаленный доступ»

Добавим интерфейсы, работающие в IGMP и назначаем для каждого интерфейса режим работы – Прокси или Маршрутизатор.

Для включения IGMP-маршрутизатор выберем соответствующий режим

В режиме IGMP-маршрутизатор интерфейс получает возможность прослушивания пакетов IGMP-отчетов о членстве узла и отслеживания членства в группах. Режим IGMP-маршрутизатора включается  на тех интерфейсах, к которым подключены прослушивающие многоадресный трафик узлы.

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

  •  Переключение сетевого адаптера в сквозной многоадресный режим. В сквозном многоадресном режиме все многоадресные пакеты, полученные сетевым адаптером, передаются для обработки сетевым уровням. Не все сетевые адаптеры способны работать в сквозном многоадресном режиме.
  •  Отслеживание членства в группах многоадресной рассылки. При этом, интерфейс прослушивает сообщения IGMP-отчетов о членстве узлов, передаваемые по подключенным к нему локальным сетям, и составляет список записей информации о многоадресной рассылке, имеющих вид {сеть получателя, группа многоадресной рассылки}. Сеть получателя — это код IP-сети, в которой находится сетевой сегмент, содержащий прослушивающий узел. Маршрутизатор с многоадресной поддержкой отслеживает не IP-адреса прослушивающих узлов, а только коды IP-сетей, в которых имеется хотя бы один прослушивающий узел.

IGMP-маршрутизатор периодически опрашивает каждую сеть, чтобы выяснить, прослушивают ли еще узлы, зарегистрированные ими адреса многоадресной рассылки. В ответ на запрос должен быть отправлен IGMP-отчет о членстве узла. Если в одной сети имеется несколько IGMP-маршрутизаторов, один из них выбирается опрашивающим и рассылает все периодические запросы.

  •  Обновление таблицы многоадресного перенаправления TCP/IP.

На основании текущего состояния прослушивающих узлов на интерфейсах в режиме IGMP-маршрутизатора соответствующим образом обновляются записи в таблице многоадресного перенаправления TCP/IP.

Для включения IGMP-прокси выберем соответствующий режим

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

Когда расположенный выше маршрутизатор перенаправляет многоадресный трафик в сеть интерфейса, работающего в режиме IGMP-прокси, этот трафик перенаправляется далее соответствующим узлам сетей интерфейсов, работающих в режиме IGMP-маршрутизатора, по протоколу TCP/IP. Расположенный выше маршрутизатор, получающий перенаправляемый многоадресный трафик, может по своему выбору перенаправить многоадресный трафик дальше или отклонить его. Используя режим IGMP-прокси, многоадресные источники в сетях, подключенных к серверу с запущенной службой «Маршрутизация и удаленный доступ», могут отправлять многоадресный трафик узлам с многоадресной поддержкой, подключенным к расположенным выше маршрутизаторам с многоадресной поддержкой.

Режим IGMP-прокси предназначен для передачи пакетов IGMP-отчетов о членстве узлов из сетей Intranet с одним маршрутизатором в область Интернета с многоадресной поддержкой. Область Интернета с многоадресной поддержкой называется многоадресной магистралью Интернета (Internet multicast backbone), или MBone.

После добавления и конфигурации интерфейсов консоль управления имеет вид

Просмотр таблицы групповых адресов для интерфейса осуществляется следующим образом

Для рассматриваемой схемы подключения, узел 192.168.13.1 (РС1) выполняет приложение использующее групповой адрес 225.0.0.1. Тогда таблица имеет вид

Таблица маршрутизации для R1 содержит маршрут по умолчанию, это необходимо для передачи информации о подключенных группах вышестоящему маршрутизатору R2.

Рассмотрим групповой трафик в сети 192.168.13.0/24. Узлы РС1 и РС2 выполняют приложения использующие групповые адреса.

Приведенный выше захват кадра представляет запрос на членство в группах мультикаст, посылаемый интерфейсом маршрутизатора R2, работающим в режиме IGMP-маршрутизатор. МАС- адрес получателя данного кадра 01:00:5е:00:00:01, что соответствует диапазону МАС адресов для передачи группового трафика на канальном уровне. Сетевой адрес получателя пакета 224.0.0.1 , т.е. пакет с запросом адресуется всем участникам сети 192.168.13.0/24. В опциях IP пакета указывается, что каждый маршрутизатор получивший этот пакет должен проверить содержимое (в данном случае инкапсуляция IGMP-запроса). В IGMP-пакете указывается тип, в данном случае это запрос на участи в группе 0х11 и максимальное время, в течение которого нужно дать ответ 10 с.

Далее в сети появляется сообщение о членстве в группе от станции 192.168.13.3

МАС- адрес получателя данного кадра 01:00:5е:00:00:16, что соответствует сетевой адресу получателя пакета 224.0.0.22 , т.е. пакет с запросом адресуется всем маршрутизаторам работающим в IGMP. Сетевой адрес отправителя соответствует IP адресу станции РС2. В опциях IP пакета указывается, что каждый маршрутизатор получивший этот пакет должен проверить содержимое (в данном случае инкапсуляция IGMP-запроса). В IGMP-пакете указывается тип, в данном случае это объявление об участи в группе 0х22 и адрес группы мультикаст 225.0.0.1.

В свою очередь, маршрутизатор R1 передает в сеть 192.168.13.0/24 о своем участии в группе 224.0.0.2 (т.е. о том, что он является маршрутизатором). И это сообщение предназначается только для маршрутизаторов работающий с IGMP, т.к. адрес получателя 224.0.0.22. Таким образом, маршрутизатор IGMP сообщает о своем присутствии в сети соседним IGMP маршрутизаторам.

Если приложение передает в сеть информацию, адресованную группе, то пакет имеет вид

В данном случае станция РС1 передает информацию всем участникам группы 225.0.0.1. МАС адрес получателя такого кадра имеет вид отличный от широковещательного, но для того чтобы коммутатор передавал подобные пакеты именно участникам группы, а не всем участникам канального сегмента необходима дополнительная поддержка протокола CGMP (Cisco Group Management Protocol) или технологии IGMP-прослушивания. И то и другое имеет своей целью создание дополнительной таблицы коммутатора, содержащей номера портов, к которым подключены участники групп мультикаст. Теоретически, построение такой таблицы не сложно – для этого необходимо, что коммутатор различал в исходящих кадрах канального уровня IGMP-объявления, и в случае совпадения – заносил номер группы из IGMP-ответа в специальную таблицу соответствия вида номер порта – группа мультикаст.

В случае если коммутатор не умеет работать с групповым трафиком канального уровня, происходит обычная широковещательная раздача группового трафика всем участникам канального уровня, что, конечно же, сказывается на производительности сети, особенно если интенсивность группового трафика возрастает.

Продолжим конфигурацию предложенной схемы

Итак, интерфейс 192.168.13.2/24 работает в режиме IGMP-маршрутизатора, интерфейс 192.168.12.2/24 – в режиме IGMP-прокси. Назначим интерфейс маршрутизатора R2 192.168.12.5/24 в качестве IGMP-маршрутизатора, после чего изменим членство в группе для РС1 с 225.0.0.1 на 225.0.0.5.

После получения объявления от станции РС1 маршрутизатор R1 перестраивает таблицу групповых адресов

И, т.к. внешний интерфейс маршрутизатора R1 работает в режиме IGMP-прокси, данный маршрутизатор посылает маршрутизаторам IGMP уведомление о том, что R1 обслуживает подключения к группе 225.0.0.5, используя для этого интерфейс 192.168.12.2/24.

После чего, таблица групповых адресов R2, содержит запись о том, что группа 225.0.0.5 достижима через шлюз 192.168.12.2.

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

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

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


 

А также другие работы, которые могут Вас заинтересовать

36259. Обеспечение информационной безопасности. Система обнаружения атак RealSecure: назначение, компоненты, возможности 83.5 KB
  Система обнаружения атак RelSecure: назначение компоненты возможности. Система RelSecure Система обнаружения атак RelSecure разработана американской компанией Internet Security Systems Inc. Система RelSecure – это интеллектуальный анализатор пакетов с расширенной базой сигнатур атак который позволяет обнаруживать враждебную деятельность и распознавать атаки на узлы Вашей корпоративной сети. Система RelSecure построена по технологии анализа сетевых пакетов в реальном масштабе времени reltime pcket nlysis относится к...
36260. Аппаратно-программные платформы администрирования. Административная консоль Exchange. Средства мониторинга серверов и трассировки сообщений 92.5 KB
  Средства мониторинга серверов и трассировки сообщений. Внешний вид административной консоли сервера Exchnge Из утилиты администрирования возможно выполнение таких функций как: создание модификация и удаление объектов каталога; создание настройка и удаление коннекторов; настройка синхронизации каталогов и репликации общих папок; контроль за состоянием серверов путем создания и запуска мониторов; установка степени подробности диагностических сообщений; трассировка сообщений; экспорт и импорт объектов...
36261. Службы Windows. Назначение и управление службами. Журнал событий. Планировщик заданий 130 KB
  Отключено Авто или Вручную У службы есть три возможности запуска: Отключено Эта служба никогда не стартует. Вручную Эта служба не будет запущена автоматически но возможен её запуск через другую службу или программу. Оставьте тип запуска Вручную если Вы не подключены к локальной сети.Оставьте его запускаемым Вручную.
36262. Технологии сбора информации 250.5 KB
  Технологии сбора информации. Информационные процессы сбор обработка и передача информации всегда играли важную роль в науке технике и жизни общества. Сбор информации это деятельность субъекта в ходе которой он получает сведения об интересующем его объекте. Обмен информацией это процесс в ходе которого источник информации ее передает а получатель принимает.
36263. Хранение информации. Структура базовой информационной технологии 130 KB
  Хранение информации данных не является самостоятельной фазой в информационном процессе а входит в состав фазы обработки. Различают структурированные данные в которых отражаются отдельные факты предметной области это основная форма представления данных в СУБД и неструктурированные произвольные по форме включающие и тексты и графику и прочие данные. Эта форма представления данных широко используется например в Интернеттехнологиях а сами данные предоставляются пользователю в виде отклика поисковыми системами. Организация того или...
36264. Информационные технологии поиска информации 274.5 KB
  Информационные технологии поиска информации Поиск информации: основные понятия виды и формы организации Поиск информации или информационный поиск представляет один из основных информационных процессов. Цели возможности и характер поиска всегда зависели от наличия информации её важности и доступности а также средств организации поиска. Цель любого поиска заключается в потребности необходимости или желании находить различные виды информации способствующие получению лицом осуществляющим поиск нужных ему сведений знаний и т. Это...
36265. Интерфейсы ИПС. Особенности ИПС глобальных сетей. Поиск в Internet 142.5 KB
  Глобальные поисковые системы в отличие от локальных стремятся объять необъятное по возможности наиболее полно описать ресурсы всего информационного пространства сети Интернет. Следует отметить что поисковые системы WWW весьма оперативно индексируют группы новостей и содержат информацию о статьях реально существующих в сети. Локальные и глобальные сети Internet В зависимости от удаленности компьютеров сети условно разделяют на локальные и глобальные. Произвольная глобальная сеть может включать другие глобальные сети локальные сети а также...
36266. Технологии обработки информации. Распределенная обработка информации. Системы централизованной обработки информации 43 KB
  Технологии обработки информации. Системы централизованной обработки информации. Информационная технология обработки данных предназначена для решения хорошо структурированных задач по которым имеются необходимые входные данные и известны алгоритмы и другие стандартные процедуры их обработки. Режим реализации технологии зависит от объемновременных особенностей решаемых задач: периодичности и срочности требований к быстроте обработки сообщений а также от режимных возможностей технических средств и в первую очередь ЭВМ.
36267. Системы распределенной обработки информации 99 KB
  Возможность взаимодействия вычислительных систем при реализации распределенной обработки информации определяют как их способность к совместному использованию данных или к совместной работе с использованием стандартных интерфейсов. Распределённые системы обработки данных В современных сетевых информационных технологиях всё чаще используют распределённую обработку данных. Под распределённой обработкой данных понимают обработку приложений несколькими территориально разделёнными ЭВМ. При этом в приложениях связанных с обработкой базы данных...