[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Документация для Linux" / Оглавление документа

Разрешение с помощью динамического связывания (ARP)

Ethernet имеет 48-битовые физические адреса, назначаемые производителями при изготовлении интерфейсных плат. Как следствие, при выходе оборудования из строя и замене интерфейсной платы физический адрес машины меняется. Более того, так как адрес в Ethernetе имеет длину 48 бит, не стоит и рассчитывать, что его можно закодировать в 32-битном IP-адресе. Разработчики протоколов TCP/IP нашли конструктивное решение проблемы разрешения адресов для сетей, таких как Chaosnet или Ethernet, которые имеют возможность широковещания. Это решение позволяет добавлять машины к сети без перекомпиляции кода и без создания центральной базы данных. Чтобы избежать создания таблиц отображения разработчики решили использовать низкоуровневый протокол для динамической связки адресов. Названный Протокол Разрешения Адресов(ARP), он обеспечивает механизм, который является как эффективным, так и легким для реализации.

Как показывает рисунок, идея, лежащая в основе динамического разрешения в ARP, проста: когда хост А хочет разрешить IP-адрес Ib, он широковещательно распространяет специальный пакет, который просит хост с IP-адресом Ib ответить ему, указав свой физический адрес Pb. Все хосты, включая В, получают этот запрос, но только хост В узнает свой IP-адрес и посылает ответ, содержащий свой физический адрес. Когда А получает ответ, он использует физический адрес для посылки межсетевого пакета прямо к В. Итоги всего вышесказанного можно изложить так:

Протокол Разрешения Адресов,ARP, позволяет хосту установить физический адрес хоста назначения в той же самой физической сети, имея только IP-адрес назначения.

<---|---------------------------------------->
===============|==========|==========|====================
    |          | |       | |        | |
    |          V |       V |        V |
  -----        -----     -----      -----
  | А |        | X |     | B |      | Y |
  -----        -----     -----      -----
                     (а)
      ---------------------
======|===================|===============================
    | |          |       | |          |
    | V          |       | |          |
  -----        -----     -----      -----
  | А |        | X |     | B |      | Y |
  -----        -----     -----      -----
                     (б)

Рисунок 5.1 Протокол ARP. Чтобы определить физический адрес В, Pb, по его IP-адресу, Ib, (а) ГВМ А широковещательно распространяет запрос ARP, содержащий Ib, по всем машинам, и (б) ГВМ В отвечает на него ответом ARP, содержащим пару (Ib,Pb).

Кэш разрешения адресов

Может показаться глупым то, что А, посылая пакет к В, сначала посылает широковещательный пакет, который достигает В. Или может показаться еще глупее, что А широковещательно задает вопрос:"Как я могу связаться с вами?" вместо того, чтобы просто широковещательно послать пакет, который он хочет передать. Но есть важная причина для таких передач. Широковещание слишком дорого, чтобы использовать его всякий раз, когда одной машине требуется передать пакет другой машине, так как оно требует от каждой машины в сети обработки широковещательного пакета. Чтобы уменьшить затраты на взаимодействие, хосты, использующие ARP, создают кэш недавно узнанных связок между физическим адресом и IP-адресом, и поэтому они не должны повторно использовать ARP. Всякий раз, когда хост получает ответ ARP, он сохраняет IP-адрес машины и соответствующий ему аппаратный адрес в своем кэше для последующих обращений. При передаче пакета хост ищет связку в кэше перед тем, как послать запрос ARP. Если хост нашел нужную связку в своем кэше, ему не надо передавать широковещательный пакет в сеть. Опыт показывает, что так как большинство сетевых взаимодействий включает передачу более чем одного пакета, даже небольшой кэш будет полезен.

Уточнение ARP

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

ARP - это низкоуровневый протокол, который скрывает базовую физическую сетевую адресацию, позволяя назначать IP-адреса по нашему выбору каждой машине. Мы будем думать о нем как о части физической сетевой системы, а не как о части межсетевых протоколов.

Реализация ARP

Функционально ARP состоит из двух частей. Одна часть определяет физические адреса при посылке пакета, а другая отвечает на запросы от других машин. Разрешение адресов для выходящих пакетов кажется элементарным, но некоторые детали усложняют реализацию. Получив IP-адрес назначения, хост просматривает кэш ARP, чтобы проверить, не знает ли он уже физического адреса для этого IP-адреса. Если хост знает его, он выделяет физический адрес, помещает данные в кадр, используя этот адрес, и посылает этот кадр. Если же он не знает отображения, он должен широковещательно передать запрос ARP и ждать ответа. Широковещание запроса ARP для нахождения отображения адреса может оказаться сложным. Машина получателя может быть выключена или быть слишком занята, чтобы принять запрос. Если такое случится, отправитель может не получить ответа или ответ может задержаться. Так как Ethernet является системой с негарантированной доставкой, то исходный широковещательный запрос ARP тоже может быть потерян (в этом случае отправитель должен будет повторно отправлять его по крайней мере еще один раз). Между тем хост должен хранить исходный передаваемый пакет, чтобы его можно было послать, когда будет разрешен адрес (если задержка становится значительной, хост может уничтожить передаваемый пакет). Фактически, хост должен решить, можно ли работать другим прикладным программам, пока он обрабатывает запрос ARP (в большинстве случаев можно). Если можно, то он должен учитывать случай, когда приложение будет генерировать дополнительные запросы ARP для того же адреса, не посылая широковещательный запрос несколько раз для одного и того же получателя.

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

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

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

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

Протоколы верхнего уровня не могут отличить случай повреждения сети Ethernet от случая отсутствия машины с искомым IP-адресом.

Следует отметить, что каждая машина имеет отдельную ARP-таблицу для каждого своего сетевого интерфейса.

Инкапсуляция и идентификация ARP

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

                     -------------------------------------
                     |        сообщение ARP              |
                     -------------------------------------
-----------------------------------------------------------
| заголовок кадра   |      поле данных кадра             |
-----------------------------------------------------------

Рисунок 6. Сообщение ARP, заключенное в кадре физической сети

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

Формат протокола ARP

В отличие от большинства протоколов, данные в пакетах ARP не имеют фиксированного формата заголовка. Вместо этого его сообщения были разработаны так, чтобы их можно было использовать для различных сетевых технологий. Поэтому, первые поля заголовка содержат счетчики, которые указывают длину следующих полей. Фактически, ARP можно использовать с произвольными физическими адресами и произвольными протокольными адресами. Пример на рисунке 7 показывает 28-октетный формат сообщения ARP, используемый для оборудования Ethernetа(у которого физические адреса являются 48-битовыми или 6-октетными) при разрешении протокольных адресов IP(имеющих длину 4 октета).

0 1em	1em	1em	1em	16 1em	1em	24 1em	31
1emEthernet адрес назначения (31:0)
1emEthernet адрес назначения (47:32)				1emEthernet исходящий адрес (47:32)
1emEthernet исходящий адрес (31:0)
1emКод типа				1emПространство аппаратных адресов
1emПространство адресов протокола				1emLHA		1emLPA
1emКод операции				1emАппаратный (Ethernet) и логический (IP)
адреса отправителя и получателя занимают длину, указанную полями LHA и LPA
1emКонтрольная сумма Ethernet

Рисунок 7. Пример формата сообщения ARP/RARP для разрешения адресов IP-Ethernet. Длины полей зависят от длин аппаратных и протокольных адресов, которые имеют значение соответственно 6 октетов для адреса Ethernet и 4 октета для IP-адреса.

Партнёры:

Хостинг: