Любая сеть рано или поздно сталкивается с ситуацией, когда сообщение нужно доставить не одному адресату, а многим. Иногда "многие" означает всех без исключения, иногда - только добровольных слушателей. Для этих двух случаев придуманы два разных механизма: broadcast, который кричит на весь сегмент, и multicast, который общается с подписанной группой. Понимание разницы между ними отличает сеть, которая работает тихо и эффективно, от сети, похожей на комнату, где все одновременно перебивают друг друга.
Широковещальный трафик и его адрес 255.255.255.255
Broadcast - это отправка одного пакета, который обязаны принять все узлы в пределах широковещательного домена. На третьем уровне существует ограниченный широковещательный адрес 255.255.255.255: пакет с таким получателем никогда не покидает локальный сегмент, маршрутизаторы его не пропускают. Ещё бывает направленный broadcast вроде 192.168.1.255 для подсети 192.168.1.0/24, когда рассылка адресована всей конкретной подсети.
На втором уровне той же идее соответствует MAC-адрес FF:FF:FF:FF:FF:FF. Коммутатор, получив кадр с таким получателем, копирует его во все порты, вдобавок откуда он пришёл. Никакой таблицы комутации не требуется - решение встроено в сам адрес.
Классические примеры broadcast-трафика знакомы каждому администратору:
- ARP-запрос. Хост знает IP-адрес соседа, но не знает его MAC, поэтому спрашивает у всего домена: "Кто владеет адресом 192.168.1.1, ответьте мне". Слышат все, отвечает один.
- DHCP Discover. Компьютер только что включился и не имеет ни адреса, ни шлюза. Он отправляет широковещательный запрос в надежде, что где-то в сегменте отзовётся DHCP-сервер.
- Разного рода объявления устаревших протоколов, уведомления о службах, служебные рассылки сетевых печатных систем старого поколения.
Важно понимать главное свойство: каждый хост в домене обязан принять широковещательный кадр, поднять его по стеку и решить, относится ли он к нему. Даже если ответа не будет, процессорное время и прерывание уже потрачены.
Широковещательные штормы и кричащая комната
Пока сегмент мал, broadcast незаметен: десяток ARP-запросов в минуту никого не беспокоит. Проблема начинается с ростом. В плоской сети из нескольких тысяч хостов широковещательный фон становится постоянным шумом - ARP, DHCP, служебные объявления сыплются непрерывно, и каждый кадр доходит до каждой сетевой карты. Сеть превращается в кричащую комнату, где полезный разговор тонет в общем гуле.
Хуже фона бывает шторм. Широковещательный шторм возникает, когда в сети появляется кольцевая топология без защиты: кадр, разосланный во все порты, возвращается обратно, снова копируется, и число копий растёт стремительно. За секунды пропускная способность съедается целиком, коммутаторы захлёбываются, сеть фактически останавливается. Протоколы семейства spanning tree придуманы именно для того, чтобы ломать такие кольца до запуска шторма.
Лекарство от шума - деление. Каждый механизм сокращает широковещательный домен:
- VLAN разрезает один физический коммутатор на множество логических сегментов; кадр FF:FF:FF:FF:FF:FF никогда не пересекает границу своей VLAN.
- Деление на подсети с маршрутизацией делает то же самое на третьем уровне: 255.255.255.255 и направленный broadcast подсети умирают на границе маршрутизатора.
- Ограничение плоских сетей разумным размером - старый эмпирический принцип проектирования: чем больше хостов в одном домене, тем громче фон и тем выше цена любой ошибки.
Multicast как избирательная реклама
Multicast решает ту же задачу "один говорит - многие слушают", но без принуждения. Адреса групп живут в диапазоне 224.0.0.0/4, то есть от 224.0.0.0 до 239.255.255.255. Отправитель шлёт один поток на групповой адрес, а получают его только те, кто явно в группу вступил.
Подписка оформляется протоколом IGMP. Хост сам сообщает своему маршрутизатору: "я в группе 239.1.2.3, присылайте мне этот поток". Роутер запоминает интерес и строит ветвь многоадресной маршрутизации в сторону подписчика. Ушёл слушатель - отправлено сообщение о выходе или просто протухла запись по таймауту, и поток в эту сторону прекращается.
На втором уровне есть тонкость. Обычный коммутатор без дополнительного интеллекта обращается с multicast-кадром как с broadcast: рассылает во все порты, ведь в таблице MAC-адресов группового адресата нет. Здесь помогает IGMP snooping - коммутатор подслушивает IGMP-диалоги между хостами и маршрутизатором, узнаёт, за какими портами сидят подписчики каждой группы, и пересылает поток только туда. Тот же принцип поддерживает соответствие групповых IP-адресов групповым MAC-адресам семейства 01:00:5E.
Принцип экономии очевиден на цифрах. Конференция, которую смотрят триста сотрудников, при unicast потребовала бы трёхсот отдельных копий потока. При multicast по магистрали идёт один поток, который размножается только в точках ветвления, ближайших к слушателям. Один поток вместо сотни копий - вся суть идеи.
Где multicast живёт сегодня
Самая массовая сфера - IPTV у операторов связи. Канал вещается одним потоком на групповой адрес, приставка подписывается через IGMP при переключении канала, и сеть не дублирует гигабиты видео на каждого зрителя.
Вторая сфера - корпоративные и учебные сети: потоковое видео с общих собраний, трансляция рабочего стола лектора на компьютеры аудитории, системы оповещения, раздача образов на множество машин одновременно.
Третья, самая незаметная сфера - обнаружение служб в локальном сегменте. Здесь multicast используется с очень маленьким радиусом действия:
- mDNS на адресе 224.0.0.251 - механизм, благодаря которому устройства находят принтеры, колонки и друг друга без центрального сервера имён.
- LLMNR в Windows - похожий резервный способ разрешения имён, когда DNS не ответил.
- SSDP в составе UPnP - поиск сетевых устройств: медиаплееров, шлюзов, камер.
Все эти протоколы опираются на многоадресные адреса с локальной дальностью и потому не выходят за пределы сегмента.
Почему глобальный multicast в интернете не состоялся
Когда-то существовала идея всемирной многоадресной магистрали, где трансляции всего мира распространялись бы как телевидение. Она не прижилась по нескольким причинам. Многоадресная маршрутизация требует, чтобы каждый транзитный роутер хранил состояние о каждой активной группе, а это плохо масштабируется на миллионы потоков. Межоператорская координация оказалась сложной: кто оплачивает размножение трафика на чужой сети, как фильтруются злоупотребления, как выделяются групповые адреса глобально. Наконец, экономика сместилась в сторону сетей доставки контента, которые решают ту же задачу массового видео обычным unicast-потоком с ближайшего к зрителю сервера, без всякой курьёзов в ядре сети.
Внутри отдельных сетей, где один владелец контролирует оборудование от начала до конца, multicast остался жив и полезен. Там его недостатки превращаются в достоинства: контролируемое число групп, предсказуемые подписчики, серьёзная экономия полосы.
IPv6 выкинул broadcast совсем
Проектировщики IPv6 посмотрели на опыт четвёртой версии и сделали радикальный вывод: широковещательного трафика в протоколе нет вообще. Адреса вида "последний в подсети" не были зарезервированы под рассылку всем, а вся служебная жизнь переведена на multicast с тонко нарезанными областями видимости.
На практике это изменило всю автонастройку. Вместо ARP работает протокол обнаружения соседей через специальные solicited-node-группы, которые вычисляются из адреса искомого узла - запрос слышат единицы хостов вместо тысяч. Роутеры объявляют себя в группу всех узлов, хосты запрашивают параметры в группу всех маршрутизаторов. Автонастройка адреса стала быстрее и тише: станция получает префикс, строит адрес, проверяет уникальность точечным групповым вопросом и готова к работе без единого широковещательного кадра.
Семейство протоколов обнаружения служб, условный Bonjour и его родственники, в IPv6 получили естественную среду: mDNS перешёл на групповой адрес ff02::fb с локальной областью, и вся "болтовня" устройств друг о друге осталась аккуратно отфильтрованной по группам и областям видимости, а не лилась сплошным фоном на всех. То, что в четвёртой версии было компромиссом, в шестой стало архитектурной нормой.
Диагностика шумного общения
Первый инструмент при подозрении на нездоровый фон - анализатор трафика вроде Wireshark. Достаточно встать снифером в сегмент и посмотреть статистику по протоколам и адресатам: доля широковещательных и групповых кадров, их частота, главные источники. Здоровая сеть показывает умеренный фон; проблемная выдаёт себя тысячами одинаковых ARP-запросов, зацикленными кадрами, хостом, который рассылает объявления с ненормальной скоростью.
Полезны и штатные средства коммутаторов: счётчики broadcast и multicast на портах, пороги storm control, которые ограничивают долю такого трафика на интерфейсе и гасят шторм в зародыше. Просмотр таблиц IGMP snooping показывает, какие группы реально активны и куда утекает поток.
Общая диагностическая логика проста: широковещательный и групповой трафик - это пульс сети. В норме он ровный и слабый. Любой аритмии - всплеску ARP, неожиданным группам, растущей доле не-unicast кадров - есть причина, и найти её почти всегда можно, просто слушая, кто и зачем кричит в общей комнате.
Границы экономии. Мультикаст превращается в экономию только там, где интерес принимающей стороны ретранслируется инфраструктурой осознанно: маршрутизатор хранит запросы на группу продолжительный промежуток, парсирование превращается в рабочее место фильтрации, и нелегитимно собранные списки нарушают это равновесие мгновенно. Правила семейной гигиены советуют отделять домашний аудио-видеотрафик от служебных устройств и дисциплинировать широковещательный диапазон разумной работы сети, которая не позволяет домовладению твориться анонсам.
Диагностический контур на будущее. В сложных материалах низменного звена сети особо решающие два приёма: изолированный раздел multicast-групп и уставной выход на уровень широковещательной критики сетевой связи собственных ролей. Потребности широкоформатных систем вроде отчётов о потоках или расцветящих услугах предполагают считывание огромных долей информации за мгновения - именно здесь явно выстраивается и бережная логистика сигнала, и защищённость обеих точек, по которым масштаб начинает быть радиоаппаратной задачей.
Сетевое телевидение как стажёрский пример. Вещание на группы полезно лишь тогда, когда строка подачи одна и та же для многих: корпоративное телевидение, распределение обновлений образов, трансляция канала камер. Без маркировки устройств и промокашки IGMP snooping все пакеты долетают во все розетки, и польза вырождается в пустой набор слушателей. Именно поэтому настройка multicast начинается с карты групп: кто подписан, кто рассылает, какие диапазоны адресов заблокированы, и где особенно важно ту же меру аудита времени проживания регистраций.
Промежутки между рекомендациями и оборудованием. На практике производители и администраторы заботятся о цене компромисса: бытовые точки доступа не умеют обрабатывать паттерны IGMP со вкусом, корпоративные платформы требуют настройки домашней сети по стандарту контрольной задержки, а WiFi вообще является хозяйством под ключ, практически каждое подключение читается всеми, хотя мощность модуляции не одна и та же. Поэтому опытный сетевик рекомендует проверку на пустом канале: запустить известное объявление, записать метаданные и проверить, наблюдают ли его принадлежащие члены группы отдельно, а прочие - нет.