Как рассылаются broadcast пакеты в wifi сети. Боремся с широковещательным штормом. Широковещательный трафик сетей NetBIOS

Виды широковещательного трафика

Поддержка широковещательного трафика на сетевом уровне

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

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

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

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

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

Стек протоколов сетей NetWare использует наибольшее число различных типов широковещательного трафика:

• SAP (Service Advertising Protocol). Включает два типа сообщений - сообщения серверов о предоставляемых ими сервисах и запросы клиентских станций о поиске соответствующих сервисов в сети. Сообщения серверов включают информацию об имени сервера, типе сервиса (например, файл-сервис или принт-сервис), а также о полном сетевом адресе сервиса, включающем номер сети, номер узла и номер сокета. Сообщения сервера распространяются раз в 60 секунд.
• RIP IPX (Routing Information Protocol). Распространяет по интерсети информацию о составляющих сетях IPX, известных данному маршрутизатору, а также о расстоянии от данного маршрутизатора до каждой сети. Инормация распространяется каждые 60 секунд. Так как каждый сервер NetWare всегда является и маршрутизатором, то уровень трафика RIPIPX прямо пропорционален количеству серверов NetWare в интерсети, к которому следует добавить также количество установленных аппаратных маршрутизаторов, работающих по протоколу RIP.
• NLSP (NetWare Link State Protocol). Новый протокол обмена маршрутной информацией, который серверы NetWare и IPX-маршрутизаторы независимых производителей могут использовать вместо протокола RIP. Протокол NLSP создает меньший уровень широковещательного трафика, так как основную часть его широковещательных сообщений представляют сообщения об изменении состояния связей в сети и состояния самих маршрутизаторов. Очевидно, что в надежной сети такие сообщения генерируются достаточно редко. Протокол NLSP создает также и периодически генерируемый трафик, но он используется только для тестирования связей между соседними маршрутизаторами и порождает пакеты очень небольшой длины.
• NDS (NetWare Directory Services). Служба NDS сетей NetWare представляет собой централизованную справочную службу, хранящую информацию о всех пользователях и ресурсах сети. При наличии в сети сервера, выполняющего функции NDS, отпадает необходимость постоянной генерации трафика протокола SAP остальными серверами сети. Однако сам сервер службы NDS пользуется протоколом SAP для того, чтобы клиенты сети NetWare автоматически смогли узнать о его существовании и адресе. Поэтому служба NDS создает в сети собственный широковещательный трафик взамен трафика, создаваемого отдельными серверами. В сети может существовать несколько серверов NDS, реализующих распределенную и резервируемую структуру справочной службы, поэтому уровень широковещательного трафика NDS может быть значительным.
• Пакеты Keepalive протокола NCP (другое название - watchdog). С помощью пакетов этого типа сервер и клиент сообщают друг другу о том, что они работают и намерены поддерживать логическое соединенение. Пакеты keepalive используются в том случае, когда между сервером и клиентом длительное время (более 5 минут) нет обмена другими данными, что бывает в том случае, когда пользователь на длительное время отлучается от своего компьютера, оставляя его включенным.

2.2.5.2. Широковещательный трафик сетей TCP/IP

Как уже отмечалось, в сетях TCP/IP широковещательный трафик используется гораздо реже, чем в сетях NetWare. Широковещательный трафик в сетях TCP/IP создают протоколы разрешения IP-адресов ARP и RARP (реверсивный ARP), а также протоколы обмена маршрутной информацией RIPIP и OSPF. Протоколы ARP и RARP используются только в локальных сетях, где широковещательность поддерживается на канальном уровне. Протокол RIPIP принципиально ничем не отличается от протокола RIPIPX, а протокол OSPF является протоколом типа "состояния связей" как и протокол NLSP, поэтому он создает широковещательный трафик гораздо меньшей интенсивности, чем RIP.

Вот - фото более крупным планом, чтобы было хорошо видно, о чем я говорю:

Как видите, индикатор «Collision» постоянно "горит" красным!

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

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

• Проблемы с самим концентратором (хабом)
• Проблемы с одним из его портов (такое тоже бывает)
• Неполадки сетевого адаптера одного из компьютеров, к нему подключенных

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

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

Если честно, я не понимаю производителей дешевых коммутаторов (чтобы не обидеть последних - "устройств начального класса") :) Им что трудно сделать дополнительный индикатор, который бы указывал на наличие коллизий и проблем в линии или - на самом устройстве? Почему-то все 5-ти и 8-ми портовые модели до 50-ти долларов лишены этого! Только «Power» и - все!

Представляете что, в один (очень не прекрасный момент) может случиться, если сеть у нас построена только с использованием подобных бюджетных решений? А это - реальный случай, который произошел на одном из моих предыдущих мест работы. Компьютерная сеть там насчитывала долее четырехсот компьютеров и спроектирована была - самым безобразным образом. Вернее, вот именно момент "проектирования" в ней отсутствовал напрочь (везде - самые дешевые свитчи от разных производителей, никакой кабельной схемы, выполненной хотя бы от руки и т.д.)

Не хотел бы напоминать ворчливого старика, но скажу эту фразу: вот раньше было - совсем по другому! :)

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

Потом, видимо, - экономить начали:

На фото выше мы видим, что две карты одного класса кардинально отличаются набором светодиодных индикаторов. На верхней их целых четыре:

1. G - (Green - зеленый) - Tx (transmit - передача)
2. Y - (Yellow - желтый) - Rx (receive - режим получения данных)
3. O - (Orange - оранжевый) - Col (collision - коллизия)
4. R - (Red - красный) - Pol (polar - перепутана полярность подключения контактов кабеля " ")

На нижней - только стандартный на сегодня Link/Akt (один диод с двумя состояниями). Первое Link (Lnk) - обозначает наличие линка (грубо говоря - подключение сетевого кабеля), при этом индикатор просто постоянно светится. Второе Akt - активность обмена данными по сети (индикатор мигает). Риторический вопрос: много ли полезного можно узнать из подобной "светомузыки"? :)

А вот - еще одно фото, гигабитного сетевого адаптера фирмы «ATI»:

Здесь на каждый режим работы (10, 100 и 1000 мегабит в секунду) - свой индикатор.

Итак, дядя помнит, где он остановился и что хотел сказать, поэтому - продолжаем! :) Выдернув очередной линк (сетевой кабель) из хаба, я увидел что индикатор коллизии погас, а коллега, держащий руку "на пульсе" нашего управляемого коммутатора D-Link, сообщил: "трафик - в норме!".

Мы нашли последнее звено в цепи (тот единственный линк, генерирующий широковещательный трафик). Осталось пройти по нему и оказаться возле компьютера, который и явился причиной всего этого безобразия!

Надо сказать, что компьютер этот вообще редко использовался и, в основном, выступал в роли принт-сервера для находящегося рядом с ним ПК. Первым делом, подойдя к , я извлек кабель из его сетевой карты (коллизии прекратились), вставил кабель - начались снова. Как говорит в подобных случаях один мой знакомый байкер: «Счастливый конец найден! »:)

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

Начнем с первого: возможные причины возникновения широковещательного шторма.

1. Различные атаки на сеть
2. Неисправный сетевой адаптер

Поскольку первый вариант сегодня - не наш, второй - не похоже, остается - третий. Железная логика! :) Иногда случается так, что сетевая карта, вместо того чтобы спокойно "умереть", начинает с максимально доступной ей скоростью рассылать по всей сети широковещательные пакеты.

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

Вторая особенность, которая и приводит к лавинообразному или постепенному (как повезет) нарастанию мусорного трафика в сети - вплоть до полного ее ступора, состоит в том, что в заголовке пакетов канального уровня (Ethernet) не указано время жизни пакета, как в случае с IP пакетами (уровень сетевой).

Примечание : временем жизни пакета данных называется поле TTL - (time to live), которое уменьшается на единицу с прохождением каждого нового маршрутизатора на пути следования пакета.

Зачем оно нужно? А именно для того, чтобы пакеты, которые не могут найти своего адресата, вечно, как неупокоенные, не блуждали по линиям связи и не занимали их полосу пропускания. Изначально (на выходе кадра из сетевого адаптера компьютера) полю TTL присваивается значение 255 и при каждом "прыжке" (хопе) через новый маршрутизатор из него вычитается единица. Если при продвижении пакета значение TTL уменьшится до ноля, то такой пакет, попросту, отбрасывается на следующем маршрутизаторе (говорят, что его время "жизни" истекло).

Есть даже такой бородатый анекдот:

Мальчик сказал маме: “Я хочу кушать”.
Мама отправила его к папе.
Мальчик сказал папе: “Я хочу кушать”.
Папа отправил его к маме.
Мальчик сказал маме: “Я хочу кушать”.
Мама отправила его к папе.
И бегал так мальчик, пока в один момент не упал.
Что случилось с мальчиком? TTL кончился

По значению этого поля можно косвенно определить, насколько далеко находится от нас тот или иной удаленный хост. Давайте рассмотрим это на простом примере использования команды «ping». На фото ниже я запустил ее к трем различным серверам в сети: (фото ниже - кликабельно)

На фото выше мы первой позицией видим пример передачи пакетов (команда ping) между сервером yandex.ru (время жизни TTL здесь уменьшилось до 57-ми единиц). Чуть ниже - ответ от сервера нашего местного провайдера ukrtelecom.ua (здесь время жизни больше, потому что сам сервер находится ближе ко мне, на Украине, - TTL равно 122 единицы). И последняя запись: ping 172.16.1.1 это - ответ от маршрутизатора Cisco, который располагается в нашей локальной сети на работе. Поскольку пакет через него не прошел, то в ответе проставлено начальное (выходное) значение поля TTL - 255 единиц.

Вот еще один пример:

Пингуемый нами сервер находится со мной в одном городе (Львове) и поэтому TTL здесь такой высокий - 252 единицы. Пакет проходит всего три маршрутизатора (учитывая тот, что стоит у меня дома), пока доходит до адресата. Попробуйте протестировать связь с этим сервером от себя (уверен, что время жизни пакета у Вас будет меньше) - ему нужно будет пройти больше узлов на пути следования.

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

Сразу скажу, что мы свой центральный управляемый коммутатор D-Link DES-3550 изначально не конфигурировали для борьбы с широковещательным штормом (поэтому сеть и "упала"), но после этого случая - предприняли соответствующие меры. Вот сейчас об этом и поговорим!

Разберем более детально одну из секций настроек нашего коммутатора второго уровня. Нас будет интересовать пункт «Traffic Control»: (кликабельно)

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

На фото выше, обратите внимание на строчку «Storm Type» (тип шторма). Здесь из списка выбираем «Broadcast», (широковещательный, там есть еще «Multicast» - групповая рассылка и «Unicast» - однонаправленная передача). В поле «State» (статус) выбираем «Enable» (задействовать).

В следующей строчке «Action» (действие) выбираем что нужно сделать при обнаружении broadcast storm? Здесь - два варианта: «drop» (отбрасывать широковещательные пакеты) и «shutdown» (полностью отключить порт). Для себя мы выбрали первый вариант.

И еще одна важная строка, на которую надо обратить внимание «Treshold (pps)» (порог PPS - packet per second - пакетов в секунду). Это - предельно допустимое значение количества пакетов, которые попадают на порт коммутатора за одну секунду. Здесь по умолчанию установлено число в 128 000 пакетов.

Хотите узнать почему именно это значение? Давайте разбираться вместе! :)

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

• 14 880 пакетов/сек на порт со скоростью работы 10 Мб/с
• 148 800 пакетов/сек на порт со скоростью работы 100 Мб/с
• 1 148 800 пакетов/сек на порт в 1000 Мб/с (1 Гигабит)

Это - предел самой технологии Ethernet, да и свитч, скорее всего, начнет "захлебываться" приходящими с такой интенсивностью пакетами. Учитывая, что наш управляемый коммутатор D-Link это 100 мегабитное устройство (его предел - значение в 148 800), то и цифра, проставленная в поле «Treshold» (порог) теперь выглядит весьма логичной: чуть меньше максимума (128 000).

После того, как мы нажмем кнопку «Apply» (применить), весь входящий трафик, который превысит цифру 128 000 пакетов в секунду будет просто отбрасываться.

Это - необходимая работа на перспективу! А в нашем случае, борьба с широковещательным штормом, причиной которого была неисправная сетевая карта, закончилась тем, чем и должна была - ее заменой. Сейчас график загрузки порта под номером 19 выглядит вот так: (кликабельно)

Всего 3% от максимума. Это - его нормальный штатный режим работы.

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

Но есть и стандартные алгоритмы, призванные решать те же задачи. Так в 1997-ом году был принят стандарт IEEE 802.3x, для управления потоком данных канального уровня в протоколе Ethernet. Он определяет простую процедуру управления трафиком: наличие двух команд - «приостановить передачу» и «возобновить передачу», которые, при необходимости, передаются конечному узлу.

Причем, команды эти реализуются на уровне кодов физического уровня , поэтому "понятны" для любого, даже самого распоследнего, сетевого адаптера:)

К стандартным методам управления трафиком относятся такие приемы как: «Метод обратного давления на узел» (backpressure) и «Метод захвата среды». Давайте коротко их рассмотрим!

У коммутатора всегда есть возможность воздействовать на конечный узел с помощью правила алгоритма доступа к среде, который конечный узел обязан соблюдать (помните про CSMA/CD ?). Точнее, воздействие происходит с помощью всяческих, самых бессовестных, нарушений этих правил! :) Конечные узлы (компьютеры) строго соблюдают все предписания, описанные в стандарте алгоритма доступа к среде, а вот коммутаторы - нет!

Метод обратного давления состоит в создании видимости коллизии в сегменте сети, который слишком интенсивно генерирует трафик. Для этого коммутатор, на нужном порте, выводит jam-последовательность (из первой части статьи мы должны помнить, что это такое). По факту - коллизии нет, но подобный трюк позволяет, на некоторое время, "заткнуть рот" конечному компьютеру:) Подобные "фокусы" свитч может выкидывать и тогда, когда находится в режиме, близком к перегрузке и ему нужно время, чтобы разгрузить переполненную очередь внутренних буферов портов.

Второй метод "торможения" хоста основан на так называемом агрессивном поведении порта коммутатора при захвате среды. Давайте, рассмотрим и его!

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

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

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

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

Поддержка широковещательного трафика на канальном уровне

Практически все протоколы, используемые в локальных сетях, поддерживают широковещательные адреса (кроме протоколов АТМ). Адрес, состоящий из всех единиц (111...1111), имеет один и тот же смысл для протоколов Ethernet, TokenRing, FDDI, FastEthernet, 100VG-AnyLAN: кадр с таким адресом должен быть принят всеми узлами сети. Ввиду особого вида и регулярного характера широковещательного адреса вероятность его генерации в результате ошибочной работы аппаратуры (сетевого адаптера, повторителя, моста, коммутатора или маршрутизатора) оказывается достаточно высокой. Иногда ошибочный широковещательный трафик генерируется в результате неверной работы программного обеспечения, реализующего функции протоколов верхних уровней.

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

Широковещательный шторм

Обычно протоколы проектируются таким образом, что уровень широковещательного трафика составляет небольшую долю общей пропускной способности сети. Считается, что нормальный уровень широковещательного трафика не должен превышать 8% - 10% пропускной способности сети. Однако, уже при достижении порога в 5% считается целесообразным провести анализ узлов, которые генерируют наибольщую долю широковещательного трафика - возможно, они нуждаются в реконфигурации.

Каждый протокол-источник широковещательных пакетов чаще всего порождает широковещательный трафик постоянной интенсивности, так как посылает в сеть пакеты фиксированного размера через определенные промежутки времени. Например, протокол SAP объявляет о существовании конкретного файл- или принт- сервиса каждые 60 секунд с помощью широковещательного сообщения фиксированного размера. Можно привести пример источника, порождающего широковещательный трафик переменной интенсивности. Таким источником является протокол обмена маршрутной информации RIP, который раз в 30 или 60 секунд рассылает по сети содержимое таблицы маршрутизации, а так как эта таблица может иметь переменный размер, то и интенсивность трафика, создаваемого протоколом RIP, может изменяться.

Общая интенсивность широковещательного трафика в сети будет определяться двумя факторами - количеством источников такого трафика и средней интенсивностью каждого источника. Протоколы локальных сетей разрабатывались в начале 80-х годов в расчете на сравнительно небольшое число компьютеров, генерирующих широковещательный трафик, а также с учетом большого запаса пропускной способности каналов локальных сетей (10 Мб/c) по сравнению с потребностями файлового сервиса миникомпьютеров и настольных компьютеров того времени. Поэтому стеки протоколов, которые проектировались исключительно для применения в локальных сетях - NovellNetWareIPX/SPX и стек NetBIOS/SMB компаний IBM и Microsoft - широко пользовались широковещательными рассылками для создания максимума удобств для пользователей, которым не нужно было запоминать имена и адреса серверов.

Стек TCP/IP проектировался в расчете на работу в любых условиях - как в локальных сетях, так и в глобальных сетях с низкоскоростными каналами. Поэтому стек TCP/IP гораздо реже пользуется широковещательными сообщениями - в основном только тогда, когда это крайне необходимо. Это гарантирует стеку TCP/IP приемлемый уровень широковещательности даже на низкоскоростных каналах, в то время как в сетях NetWare уровень широковещательности на глобальных каналах может достигать нежелательной цифры в 20%.

Превышение широковещательным трафиком уровня более 20% называется широковещательным штормом (bradcaststorm). Это явление крайне нежелательно, так как приводит к возрастанию коэффициента использования сети, а, следовательно, и к резкому увеличению времени ожидания доступа.

В сетях IP существует 3 основных способа передачи данных : Unicast, Broadcast, Multicast.

Unicast (юникаст) – процесс отправки пакета от одного хоста к другому хосту.

Multicast (мультикаст) – процесс отправки пакета от одного хоста к некоторой ограниченной группе хостов.

Broadcast (бродкаст) – процесс отправки пакета от одного хоста ко всем хостам в сети.

Эти 3 типа передачи данных используются для различных целей, давайте рассмотрим более подробно.

Unicast

Тип передачи данных Unicast (индивидуальный) используется для обычной передачи данных от хоста к хосту. Способ Unicast работает в клиент-серверных и пиринговых (peer-to-peer, от равного к равному) сетях.

В unicast пакетах в качестве IP адреса назначения используется конкретный IP адрес устройства, для которого этот пакет предназначен. IP адрес конкретного устройства состоит из порции адреса сети (в которой находится это устройство) и порции адреса хоста (порции, определяющей это конкретное устойчиво в его сети). Это все приводит к возможности маршрутизации unicast пакетов по всей сети.

Multicast и broadcast пакеты, в отличие от unicast пакетов, имеют свои собственные специальные (зарезервированные) IP адреса для использования их в заголовке пакетов в качестве пункта назначения. Из-за этого, broadcast пакеты в основном ограничены пределами локальной сети. Multicast трафик также может быть ограничен границами локальной сети, но с другой стороны также может и маршрутизироваться между сетями.

В IP сетях unicast адрес является адресом, то есть адресом конечного устройства (например, компьютера). Для типа передачи данных unicast, адреса хостов назначаются двум конечным устройствам и используются (эти адреса) как IP адрес источника и IP адрес получателя.

В течение процесса инкапсуляции передающий хост размещает свой IP адрес в заголовок unicast пакета в виде адреса источника, а ИП адрес принимающего хоста размещается в заголовке в виде адреса получателя. Используя эти два IP адреса, пакеты unicast могут передаваться через всю сеть (т.е. через все подсети).

Multicast

Тип передачи multicast разрабатывался для сбережения пропускной способности в IP сетях. Такой тип уменьшает трафик, позволяя хостам отправить один пакет выбранной группе хостов. Для достижения нескольких хостов назначения используя передачу данных unicast, хосту источнику было бы необходимо отправить каждому хосту назначения один и тот же пакет. С типом передачи данных multicast, хост источник может отправить всего один пакет, который может достичь тысячи хостов получателей.

Примеры multicast передачи данных:

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

Multicast клиенты

Хосты, которые хотят получить определенные multicast данные, называются multicast клиентами. Multicast клиенты используют сервисы инициированные (начатые) клиентскими программами для рассылки multicast данных группам.

Каждая multicast группа представляет собой один multicast IP адрес назначения. Когда хост рассылает данные для multicast группы, хост помещает multicast IP адрес в заголовок пакета (в раздел пункта назначения).

Для multicast групп выделен специальный блок IP адресов, от 224.0.0.0 до 239.255.255.255.

Broadcast (Широковещание)

Из-за того, что тип передачи broadcast используется для отправки пакетов ко всем хостам в сети, пакеты использую специальный broadcast IP адрес. Когда хост получает пакет, в заголовке которого в качестве адреса получателя указан broadcast адрес, он обрабатывает пакет так, как будто это unicast пакет.

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

Примеры, когда используется broadcast передача данных:

• создание карты принадлежности адресов верхнего уровня к нижним (например, какой IP адрес на конкретном устройстве со своим MAC адресом)
• запрос адреса (в качестве примера можно взять протокол ARP)
• протоколы маршрутизации обмениваются информацией о маршрутах (RIP, EIGRP, OSPF)

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

Подобным образом, когда хосту необходимо отправить информацию всем хостам в сети, он создаёт широковещательный пакет с его информацией и передаёт его в сеть.

В отличие от unicast передачи, где пакеты могут быть маршрутизированы через всю сеть, broadcast пакеты, как правило, ограничиваются локальной сетью. Это ограничение зависит от настройки маршрутизатора, который ограничивает сеть и следит за типом широковещания (broadcast).

Существует два типа broadcast передачи данных: направленное широковещание и ограниченное широковещание.

Направленный broadcast (направленное широковещание)

Направленный broadcast отправляется всем хостам какой-то конкретной сети. Этот тип широковещания удобно использовать для отправки broadcast трафика всем хостам за пределами локальной сети.

Например, хост хочет отправить пакет всем хостам в сети 172.16.5.0/24, но сам хост находится в другой сети. В данном случае хост-отправитель вложит в заголовок пакета в качестве адреса пункта назначения broadcast адрес 172.16.5.255. Хотя маршрутизаторы должны ограничивать (не передавать) направленный широковещательный трафик, их можно настроить на разрешение передачи broadcast трафика.

Ограниченный broadcast (ограниченное широковещание)

Ограниченный broadcast используется для передачи данных всем хостам в локальной сети. В такие пакеты в качестве пункта назначения вставляется IP адрес 255.255.255.255. Маршрутизаторы такой широковещательный трафик не передают. Пакеты, переданные ограниченным broadcast будут распространяться только в локальной сети. По этой причине локальные сети IP также называют широковещательным доменом (broadcast domain). Маршрутизаторы образуют границу для широковещательного домена. Без границы пакеты бы распространялись по всей сети, каждому хосту, уменьшая быстродействие сетевых устройств и забивая пропускную способность каналов связи.

Приведу пример ограниченного broadcast: хост находится внутри сети 172.16.5.0/24 и хочет передать пакет всем хостам в его сети. Используя в качестве пункта назначения IP адрес 255.255.255.255, он отправляет широковещательный пакет. Этот пакет примут и обработают все хосты только в этой локальной сети (172.16.5.0/24).