Управляющие протоколы Internet

 

Помимо протокола IP, используемого для передачи данных, в Интернете есть несколько управляющих протоколов, применяемых на сетевом уровне, к которым относятся ICMP, ARP, IGMP, RARP, ВООТР и DHCP.

IСМР - протокол управляющих сообщений Интернета (коды ICMP)

За работой Интернета следят маршрутизаторы. Когда случается что-то неожиданное, о происшествии сообщается по протоколу ICMP (InternetControlMessageProtocol — протокол управляющих сообщений Интернета), используемому также для тестирования Интернета. Протоколом ICMP определено около дюжины типов сообщений. Каждое ICMP-сообщение вкладывается в IP-пакет.

Основные типы ICMP сообщений

Сообщение АДРЕСАТ НЕДОСТУПЕН используется, когда подсеть или маршрутизатор не могут обнаружить пункт назначения или когда пакет с битом DF (не фрагментировать) не может быть доставлен, так как путь ему преграждает сеть с маленьким размером пакетов.

Сообщение ВРЕМЯ ИСТЕКЛО посылается, когда пакет игнорируется, так как его счетчик уменьшился до нуля. Это событие является признаком того, что пакеты двигаются по замкнутым контурам, что имеется большая перегрузка или установлено слишком низкое значение таймера.

Сообщение ПРОБЛЕМА ПАРАМЕТРА указывает на то, что обнаружено неверное значение в поле заголовка. Это является признаком наличия ошибки в программном обеспечении хоста, отправившего этот пакет, или промежуточного маршрутизатора.

Сообщение ГАШЕНИЕ ИСТОЧНИКА ранее использовалось для усмирения хостов, которые отправляли слишком много пакетов. Хост, получивший такое сообщение, должен был снизить обороты. В настоящее время подобное сообщение редко используется, так как при возникновении перегрузки подобные пакеты только подливают масла в огонь, еще больше загружая сеть. Теперь борьба с перегрузкой в Интернете осуществляется в основном на транспортном уровне. Это будет подробно обсуждаться в главе 6.

Сообщение ПЕРЕАДРЕСОВАТЬ посылается хосту, отправившему пакет, когда маршрутизатор замечает, что пакет адресован неверно.

Сообщения ЗАПРОС ОТКЛИКА и ОТКЛИК посылаются, чтобы определить, достижим ли и жив ли конкретный адресат. Получив сообщение ЗАПРОС ОТКЛИКА, хост должен отправить обратно сообщение ОТКЛИК. Сообщения ЗАПРОС ВРЕМЕННОГО ШТАМПА и ОТКЛИК С ВРЕМЕННЫМ ШТАМПОМ имеют то же назначение, но при этом в ответе проставляется время получения сообщения и время отправления ответа. Это сообщение используется для измерения производительности сети.

ARP — протокол разрешения адресов

При рассылке хостом 1 по сети Ethernet широковещательного пакета с вопросом: «Кому принадлежит IP-адрес 192.31.65.5?» Этот пакет будет получен каждой машиной сети Ethernet 192.31.65.0, а хост 2 ответит на вопрос своим Ethernet-адресом Е1. Таким образом, хост 1 узнает, что IP-адрес 192.31.65.5 принадлежит хосту с Ethernet-адресом Е2. Протокол, который задает подобный вопрос и получает ответ на него, называется ARP (AddressResolutionProtocol — протокол разрешения адресов) и описан в RFC 826. Он работает почти на каждой машине в Интернете.

Преимущество протокола ARP над файлами конфигурации заключается в его простоте. Системный администратор должен всего лишь назначить каждой машине IP-адрес и решить вопрос с маской подсети. Все остальное сделает протокол ARP.

Затем программное обеспечение протокола IP хоста 1 создает Ethernet-кадр для Е2, помещает в его поле полезной нагрузки IP-пакет, адресованный 192.31.65.5, и посылает его по сети Ethernet. Сетевая карта Ethernet хоста 2 обнаруживает кадр, замечает, что он адресован ей, считывает его и вызывает прерывание. Ethernet-драйвер извлекает IP-пакет из поля полезной нагрузки и передает его IP-программе, которая, видя, что пакет адресован правильно, обрабатывает его.

Существуют различные методы повышения эффективности протокола АRР. Во-первых, машина, на которой работает протокол ARP, может запоминать результат преобразования адреса на случай, если ей придется снова связываться с той же машиной. В следующий раз она найдет нужный адрес в своем кэше, сэкономив, таким образом, на рассылке широковещательного пакета. Скорее всего, хосту 2 понадобится отослать ответ на пакет, что также потребует от него обращения к ARP для определения адреса отправителя. Этого обращения можно избежать, если отправитель включит в ARP-пакет свои IP- и Ethernet-адреса. Когда широковещательный ARP-пакет прибудет на хост 2, пара (192.31.65.7, El) будет сохранена хостом 2 в ARP-кэше для будущего использования. Более того, эту пару адресов могут сохранить у себя все машины сети Ethernet.

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

Чтобы разрешить изменение соответствий адресов, например, при поломке и замене сетевой карты на новую (с новым Ethernet-адресом), записи в ARP-кэше должны устаревать за несколько минут.

Многоадресное (групповое) вещание и протокол IGMP

Групповое вещание (multicast) требует некоторых расширений в протоколах узлов. IGMP (InternetGroupManagementProtocol — протокол управления группами). Поддержка группового вещания узлами может быть реализована на трех уровнях:

— не поддерживается.

— поддерживается передача групповых сообщений (необходимые дополнительные средства минимальны).

— поддерживается передача и прием.

Каждый из адресов диапазона класса D (224.0.0.0—239.0.0.0) представляет идентификатор вещательной группы. Группы делятся на постоянные (permanent) и временные (transient). Адреса постоянных групп назначаются административно. Для временных групп адреса выделяются динамически из незанятых постоянными. Адрес 224.0.0.0 использовать запрещается. Адрес 224.0.0.1 (all-hostsaddress) используется как общий адрес для всех абонентов группового вешания, непосредственно подключенных к конкретной подсети. Адрес 224.0.0.2 (allrouters) используется для обращения ко всем маршрутизаторам IGMP. Эти два адреса служат для распространения информации по протоколу IGMP. Нет способа задать групповой адрес сразу всех узлов глобальной сети. Группы получателей формируются динамически, узел может быть членом нескольких групп.

Распространение межсетевого группового трафика управляется протоколом IGMP. Все сообщения этого протокола передаются по адресам 224.0.0.1 и 224.0.0.2, поле TTL=1, так что сообщение не выходит за пределы, доступные непосредственно по локальному интерфейсу. Узел, желающий вступить в группу, передает сообщение HostMembershipReport, в котором указывается идентификатор группы. Для верности это сообщение он повторяет 1-2 раза (подтверждений в IGMP не предусматривается). Маршрутизатор, поддерживающий IGMP, принимает это сообщение и заносит идентификатор в свою таблицу с привязкой к порту, от которого получено сообщение. Маршрутизатор периодически посылает запросы HostMembershipQuery, на которые отвечают узлы, считающие себя членами какой-либо группы. Если на пару опросов для определенной группы никто не отозвался, маршрутизатор исключает эту группу из своей таблицы. Для сокращения избыточного служебного трафика узлы отвечают не сразу, а через случайный интервал времени. Если за время этой задержки узел, собравшийся ответить, услышал такой же ответ от другого узла, он свой ответ аннулирует. О выходе из группы узел явно не сообщает, он просто перестает отвечать на опросы. Протокол IGMP используется и для обмена информацией об используемых группах между маршрутизаторами, поддерживающими групповую пересылку. Маршрутизаторы организуют пересылку пакетов группового вещания между портами, для которых в таблицы занесены соответствующие идентификаторы. Конечно, распространение этого трафика контролируется и средствами сетевого администрирования.

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

Версия IGMP V.2, обратно совместимая с исходной. В версии 2 введены следующие изменения:

- Определен выбор маршрутизатора-опросчика IGMP — для каждой локальной сети им будет маршрутизатор с наименьшим IP-адресом.

- Определен новый тип сообщения — Group-SpecificQuery, в котором указывается список групп, принадлежность к которым интересует маршрутизатор в данный момент.

- Определено новое сообщение LeaveGroup, которым хост явно указывает на намерение выйти из группы (групп). Сообщение посылается по спецпальному адресу 224.0.0.2 (allrouters).

Эти меры нацелены на экономию полосы пропускания — сокращение лишнего группового трафика.

Версия 3 предполагает возможность выбора источников, данные от которых интересуют групповых получателей. До сих пор, как только узлы заявляли о вхождении в какую-либо группу, маршрутизаторы доставляли им пакеты от всех источников (их может быть множество) данной группы. Теперь сообщением InclusionGroup-SourceReport хост заказывает трафик интересующих источников, а сообщением ExclusionGroup-SourceReport отказывается от его получения. Таким образом сеть освобождается от ненужного трафика.

Для передачи группового трафика требуется сеть маршрутизаторов (и коммутаторов), поддерживающих протоколы IGMP. Поскольку' в глобальной сети на это способны далеко не все маршрутизаторы, применяют туннелированпе. Пакеты с групповыми адресами инкапсулируются в обычные одноадресные пакеты (IP-Over-IP) и в таком виде пересылаются между шлюзами. Туннели, по которым проходят инкапсулированные пакеты, соединяют шлюзы, расположенные в «островках» сети, на которых имеется полная поддержка группового вещания. В шлюзе на конце туннеля многоадресные пакеты извлекаются из одноадресных и далее рассылаются в пределах «островка» вышеописанным способом. Построение магистральной сети распространения группового трафика MulticastBackbone (MBONE), являющееся нетривиальной задачей, отметим лишь, что для передачи этого трафика используются протоколы DVMRP (DistanceVectorMulticastRoutingProtocol), MOSPF (Multicast OSPF) или PIM (Protocol-IndependentMulticast).

Протоколы RARP, ВООТР и DHCP

Протокол ARP решает проблему определения по заданному IP-адресу Ethernet-адреса хоста. Иногда бывает необходимо решить обратную задачу, то есть по заданномуEthernet-адресу определить IP-адрес. В частности, эта проблема возникает при загрузке бездисковой рабочей станции. Обычно такая машина получает двоичный образ своей операционной системы от удаленного файлового сервера. Но как ей узнать его IP-адрес?

Первым для решения проблемы был разработан протокол RARP (ReverseAddressResolutionProtocol — протокол обратного определения адреса). Этот протокол позволяет только что загрузившейся рабочей станции разослать всем свой Ethernet-адрес и сказать: «Мой 48-разрядный Ethernet-адрес — 14.04.05.18.01.25. Знает ли кто-нибудь мой IP-адрес?» RARP-сервер видит этот запрос, ищет Ethernet-адрес в своих файлах конфигурации и посылает обратно соответствующий IP-адрес.

Использование протокола RARP лучше внедрения IP-адреса в образ загружаемой памяти, так как это позволяет использовать данный образ памяти для разных машин. Если бы IP-адреса хранились бы где-то в глубине образа памяти, каждой машине понадобился бы свой отдельный образ.

Недостаток протокола RARP заключается в том, что в нем для обращения к RARP-серверу используется адрес, состоящий из одних единиц (ограниченное широковещание). Однако эти широковещательные запросы не переправляются маршрутизаторами в другие сети, поэтому в каждой сети требуется свой RARP-сервер. Для решения данной проблемы был разработан альтернативный загрузочный протокол ВООТР. В отличие от RARP, он использует UDP-сообщения, пересылаемые маршрутизаторами в другие сети. Он также снабжает бездисковые рабочие станции дополнительной информацией, включающей IP-адрес файлового сервера, содержащего образ памяти, IP-адрес маршрутизатора по умолчанию, а также маску подсети.

Серьезной проблемой, связанной с применением ВООТР, является то, что таблицы соответствия адресов приходится настраивать вручную. Когда к ЛВС подключается новый хост, протокол ВООТР невозможно использовать до тех пор, пока администратор сети не присвоит ему IP-адрес и не пропишет вручную в конфигурационных таблицах пару (Ethernet-адрес, IP-адрес). Для устранения влияния этого фактора протокол ВООТР был изменен и получил новое имя: DHCP (DynamicHostConfigurationProtocol — протокол динамической настройки хостов). DHCP позволяет настраивать таблицы соответствия адресов как вручную, так и автоматически. Этот протокол описан в RFC 2131 и 2132. В большинстве систем он уже практически заменил RARP и ВООТР.

Подобно RARP и ВООТР, DHCP основан на идее специализированного сервера, присваивающего IP-адреса хостам, которые их запрашивают. Такой сервер не обязательно должен быть подключен к той же ЛВС, что и запрашивающий хост. Поскольку сервер DHCP может быть недоступен с помощью широковещательной рассылки, в каждой ЛВС должен присутствовать агент ретрансляции.

Для отыскания своего IP-адреса загружаемая машина широковещательным способом распространяет специальный пакет DISCOVER (Поиск). Агент ретрансляции DHCP перехватывает все широковещательные пакеты, относящиеся к протоколу DHCP. Обнаружив пакет DISCOVER, он превращает его из широковещательного в одноадресный и доставляет DHCP-серверу, который может находиться и в другой ЛВС. Агенту ретрансляции необходимо знать всего одну деталь: IP-адрес DHCP-сервера.

Встает вопрос: на какое время можно выдавать в автоматическом режиме IP-адреса из пула? Если хост покинет сеть и не освободит захваченный адрес, этот адрес будет навсегда утерян. С течением времени будет теряться все больше адресов. Для предотвращения этих неприятностей нужно выдавать IP-адреса не навсегда, а на определенное время. Такая технология называется лизингом. Перед окончанием срока действия лизинга хост должен послать на DHCP-сервер запрос о продлении срока пользования IP-адресом. Если такой запрос не был сделан или в просьбе было отказано, хост не имеет права продолжать использование выданного ранее адреса.

 

Протоколы передачи данных (протокол PPP, протокол HDLC)

 

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

High-LevelDataLinkControl (HDLC) — бит-ориентированный протокол канального уровня сетевой модели OSI, разработанный ISO.

HDLC может быть использован в соединениях с множественным доступом, но в настоящее время в основном используется в соединениях точка-точка с использованием асинхронного сбалансированного режима (ABM).

Типы станций

Первичная (ведущая) станция (Primaryterminal) ответственна за управление каналом и восстановление его работоспособности. Она производит кадры команд. В соединениях точка-многоточка поддерживает отдельные связи с каждой из вторичных станций.

Вторичная (ведомая) станция (Secondaryterminal) работает под контролем ведущей, отвечая на её команды. Поддерживает только 1 сеанс связи.

Комбинированная станция (Combinedterminal) сочетает в себе функции как ведущей, так и ведомой станций. Производит и команды и ответы. Только соединения точка-точка.

Каждая из станций в каждый момент времени находится в одном из 3 логических состояний:

1. Состояние логического разъединения (LDS — LogicalDisconnectState)

Если вторичная станция находится в режиме нормального разъединения (NDM), то она может принимать кадры только после получения явного разрешения от первичной. Если же в асинхронном режиме разъединения (ADM), то вторичная станция может самовольно инициировать передачу.

2. Состояние инициализации (IS — InitializationState)

Используется для передачи управления на удалённую комбинированную станцию и для обмена параметрами между удалёнными станциями.

3. Состояниепередачиинформации (ITS — Information Transfer State)

Всем станциям разрешено вести передачу и принимать информацию. Станции могут находиться в режимах NRM, ARM, ABM.

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

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

Режим асинхронного ответа (AsynchronousResponseMode, ARM) даёт возможность вторичной станции самой инициировать передачу. В основном используется в соединениях типа кольцо и многоточечных с неизменной цепочкой опроса, так как в этих соединениях одна вторичная станция может получить разрешение на передачу от другой вторичной и в ответ начать передачу. То есть разрешение на передачу передаётся по типу маркера (token). За первичной станцией сохраняются обязанности по инициализации линии, определению ошибок передачи и логическому разъединению. Позволяет уменьшить накладные расходы, связанные с началом передачи.

Асинхронный сбалансированный режим (AsynchronousBalancedMode, ABM) используется комбинированными станциями. Передача может быть инициирована с любой стороны, может происходить в полном дуплексе. В режиме ABM оба устройства равноправны и обмениваются кадрами, которые делятся на кадры-команды и кадры-ответы.

Для обеспечения совместимости между станциями, которые могут менять свой статус(тип), в протоколе HDLC предусмотрены 3 конфигурации канала:

Несбалансированная конфигурация (UN — UnbalancedNormal) обеспечивает работу 1 первичной и одной или нескольких вторичных станций в (симплексном)полудуплексном и полнодуплексном режимах, с коммутируемым или некоммутируемым каналом.

Симметричная конфигурация (UA — UnbalancedAsynchronous) обеспечивает взаимодействие двух двухточечных несбалансированных станций. Используется 1 канал передачи, в который мультиплексируются и команды и ответы. В данное время не используется.

Сбалансированная конфигурация (BA — BalancedAsynchronous) состоит из 2 комбинированных станций. Передача в(симплексном) полудуплексном и полнодуплексном режимах, с коммутируемым или некоммутируемым каналом. Каждая станция несёт одинаковую ответственность за управление каналом.

PPP (англ. Point-to-PointProtocol) — двухточечный протокол канального уровня (DataLink) сетевой модели OSI. Обычно используется для установления прямой связи между двумя узлами сети, причем он может обеспечить аутентификацию соединения, шифрование и сжатие данных. Используется на многих типах физических сетей: нуль-модемный кабель, телефонная линия, сотовая связь и т. д.

Часто встречаются подвиды протокола PPP такие, как Point-to-PointProtocoloverEthernet (PPPoE), используемый для подключения по Ethernet, и иногда через DSL; и Point-to-PointProtocolover ATM (PPPoA), который используется для подключения по ATM AdaptationLayer 5 (AAL5), который является основной альтернативой PPPoE для DSL.PPP представляет собой целое семейство протоколов: протокол управления линией связи (LCP), протокол управления сетью (NCP), протоколы аутентификации (PAP, CHAP), многоканальный протокол PPP (MLPPP).

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

PPP позволяет работать нескольким протоколам сетевого уровня на одном канале связи. Другими словами, внутри одного PPP-соединения могут передаваться потоки данных различных сетевых протоколов (IP, Novell IPX и т. д.), а также данные протоколов канального уровня локальной сети. Для каждого сетевого протокола используется NetworkControlProtocol (NCP) который его конфигурирует (согласовывает некоторые параметры протокола).

Так как в PPP входит LCP протокол, то можно управлять следующими LCP параметрами:

1. Аутентификация. RFC 1994 описывает ChallengeHandshakeAuthenticationProtocol (CHAP), который является предпочтительным для проведения аутентификации в PPP, хотя PasswordAuthenticationProtocol (PAP) иногда еще используется. Другим вариантом для аутентификации является ExtensibleAuthenticationProtocol (EAP).

2. Сжатие. Эффективно увеличивает пропускную способность PPP соединения, за счет сжатия данных в кадре. Наиболее известными алгоритмами сжатия PPP кадров являются Stacker и Predictor.

3. Обнаружение ошибок. Включает Quality-Protocol и помогает выявить петли обратной связи посредством MagicNumbers RFC 1661.

4. Многоканальность. Multilink PPP (MLPPP, MPPP, MLP) предоставляет методы для распространения трафика через несколько физических каналов, имея одно логическое соединение. Этот вариант позволяет расширить пропускную способность и обеспечивает балансировку нагрузки.