IGMP: что стоит за протоколом управления интернет-группами

Со времени большого успеха таких потоковых сервисов, как Netflix и Spotify, IP-мультивещание стало незаменимым методом передачи данных в Интернете. Эта техническая процедура позволяет отправителю отправлять потоки данных целым группам получателей, позволяя им оптимально использовать транспортные и маршрутные возможности. Без этого метода передачи отправителю пришлось бы отправлять отдельные пакеты данных каждому принимающему устройству, что потребовало бы огромной пропускной способности и быстро привело бы к перегрузке. Это сделало бы практически невозможным постоянную доступность услуги.

Протокол Internet Group Management Protocol (IGMP) — это протокол, который играет важную роль в организации этих многоадресных групп получателей в сетях IPv4.

Протокол управления группами Интернета — это коммуникационный протокол семейства TCP/IP, разработанный в Стэнфордском университете и впервые указанный в 1989 году в RFC 1112. За первой версией протокола IGMPv1 последовали пересмотренные версии IGMPv2 (RFC 2236) и IGMPv3 (RFC 3376; RFC 4604). Версии всегда обратно совместимы, что означает, что устройство IGMPv3 автоматически поддерживает версии 1 и 2. Протокол Internet Group Management Protocol отвечает исключительно за сети IPv4 — в сетях IPv6 его функции берет на себя аналогичный Multicast Listener Discovery (MLD).

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

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

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

Три опубликованные версии протоколов Internet Group Management Protocols имеют много общего. IGMPv2 и IGMPv3 расширили предшественника в основном за счет функций, в то время как основные характеристики, такие как групповой адрес для общих запросов (0.0.0.0), остались неизменными. Но как выглядят соответствующие расширения в деталях?

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

Все сообщения IGMP передаются в простых IP-пакетах с номером протокола IP 2 (Hex: 0x02). Заголовок IGMP первой версии протокола выглядит следующим образом:

Общая длина заголовка IGMP составляет 64 бита. Первые 8 бит всегда указывают версию протокола IGMPv1 и тип сообщения. Для поля (тип) есть два варианта: «1» (для запросов на членство) и «2» (для уведомлений о многоадресных потоках данных). Далее следуют биты с 8 по 15, но они не имеют никакой функции и состоят только из нулей. Первый 32-битный блок заканчивается контрольной суммой. Если это пакет уведомлений IGMP, то далее следует групповой адрес длиной 32 бита.

В оригинальной версии протокола сама строка протокола не указывает, какой маршрутизатор должен использоваться для многоадресных запросов (регулируется протоколом Multicast Routing Protocol).

Спецификация IGMPv2 датируется 1997 годом, что означает, что первая редакция стандарта появилась примерно через 8 лет после первой публикации протокола. В то время как группа (0.0.0.0) и адрес назначения (224.0.0.1) для автоматических запросов остались неизменными, внутренняя продолжительность по умолчанию была увеличена до 125 секунд. Однако наиболее важной новой особенностью IGMPv2 является ускорение процесса выхода из протокола: таймаут, который требовался в первом варианте протокола, заменен процессом выхода из протокола, инициируемым хостом с помощью сообщения «leave». Адрес назначения для этого типа сообщения — 224.0.0.2.

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

Сообщения IGMPv2 также инкапсулируются в простые IP-пакеты с номером протокола IP 2. Однако в заголовок IGMP были внесены незначительные изменения:

Строка заголовка начинается аналогично первой версии журнала, но без указания номера версии. Возможные коды типов: «0x11» (для запросов), «0x16» (для уведомлений) и «0x17» (для сообщений о выходе). Для обратной совместимости существует также код «0x12» для уведомлений IGMPv1. Биты с 8 по 15 получают конкретную функцию в IGMPv2 — по крайней мере, для запросов о членстве — и определяют максимально допустимое время ответа. Далее следует контрольная сумма (16 бит) и адрес группы (32 бита), который, в свою очередь, имеет типичную для протокола форму 0.0.0.0 для общих запросов.

IGMPv2 определяет правило, согласно которому для многоадресных запросов используется маршрутизатор с наименьшим IP-адресом в подсети.

IGMPv3, третья версия протокола Internet Group Management Protocol, была выпущена в октябре 2002 года. 0.0.0.0 — это адрес группы, а 224.0.0.1 — адрес назначения для общих запросов. Что касается стандартного интервала, то эта версия протокола основана на своем прямом предшественнике со 125 секундами. Новой особенностью является возможность выбора источника многоадресного потока. Эта так называемая многоадресная рассылка с выбором источника значительно снижает требования к сети, а также обеспечивает большую безопасность при передаче, поскольку используются не просто любые и/или неизвестные источники.

Заголовок IGMP также интегрирован в IGMPv3 в IP-пакеты (протокол номер 2), но он гораздо сложнее, чем у двух предшествующих протоколов, что связано, главным образом, с возможностью указания адреса источника. Существуют также специфические различия между запросами и уведомлениями. Заголовок для групповых запросов IGMPv3 выглядит следующим образом:

Первые две 32-битные последовательности идентичны таковым в заголовке IGMPv2 — тип, максимальное время ответа, контрольная сумма и адрес группы. IGMPv3 также предоставляет возможность обмена со старыми версиями протокола: для этого хостам доступны коды «0x12» для версии 1 и «0x16» для версии 2. После адреса группы начинается заголовочная часть IGMPv3, специфичная для запросов, первые 32 бита которой состоят следующим образом:

• Res.: зарезервированное 4-битное поле, которое не имеет никаких функций и содержит только нули
• S (подавлять обработку на стороне маршрутизатора): S-флаг, который устанавливает «1», указывая на то, что маршрутизаторы должны подавлять обычные обновления при получении запроса (если значение равно «0», поле неактивно).
• QRV (Querier’s Robustness Variable): 3 бита, которые могут содержать значение «переменной надежности», используемое запрашивающими узлами.
• QQIC (Querier’s Query Interval Code): 8-битное поле, используемое для указания интервала для IGMPV3 запросов.
• Количество адресов источников: количество адресов источников, перечисленных ниже.

За этой очень специфической информацией следует адрес источника или список отдельных адресов источника (по 32 бита), если необходимо определить несколько источников.

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

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