A.noneline { font-family: Arial, Serif; text-decoration: none; } FONT.arial { font-family: Arial, Serif; } TD.arial { font-family: Arial, Serif; } TH.arial { font-family: Arial, Serif; } PRE { font-family: Monospace; color: navy; } SAMP { font-family: Monospace; color: navy; } TT { font-family: Monospace; color: navy; } VAR { font-family: Monospace; color: navy; }
|
|
|---|
Мы описали схему адресации TCP/IP, в которой каждому ГВМ назначается 32-битовый адрес и сказали, что интернет ведет себя как виртуальная сеть при использовании этих назначенных адресов для посылки и приема пакетов. Мы также рассмотрели несколько физических сетевых технологий и заметили, что две машины в данной физической сети могут взаимодействовать только в том случае, если каждая из них знает физический сетевой адрес другой машины. О чем мы не упоминали, так это о том, как ГВМ или шлюз отображает IP-адрес в корректный физический адрес, когда ему нужно послать пакет по физической сети. Эта глава рассматривает это отображение, показывая, как оно реализуется для двух самых распространенных схем физических адресов.
Рассмотрим две машины А и В, которые присоединены к одной физической сети. Каждая из них имеет назначенный IP-адрес Ia и Ib, а также физический адрес Pa и Pb. Нашей целью является разработка низкоуровневого программного обеспечения, которое скрывало бы физические адреса и позволяло бы программам более высокого уровня работать только с межсетевыми адресами. Тем не менее, в конечном счете взаимодействие реализуется физическими сетями, использующими какую-либо схему физических адресов. Предположим, что машина А хочет послать пакет машине В по физической сети, к которой они обе присоединены, но А знает только межсетевой адрес Ib. Возникает вопрос: как может А отобразить этот адрес в физический адрес Pb ?
Проблема отображения высокоуровневых адресов в физические адреса известна как проблема разрешения адресов и решается несколькими способами. Некоторые связки протоколов хранят на каждой машине таблицы, содержащие пары высокоуровневых и физических адресов. Другие решают проблему, кодируя аппаратные адреса в высокоуровневых адресах. Использование только одного из этих подходов в лучшем случае делает проблему высокоуровневой адресации неудобной. Эта глава рассматривает две технологии для разрешения адресов, используемые протоколами TCP/IP.
Существуют два основных типа физических адресов: характерным представителем первого типа является Ethernet, использующий большие, фиксированные физические адреса, а второго - proNET-10, использующий маленькие легко изменяемые физические адреса. Разрешение адресов трудно для сетей типа Ethernetа, но легко для сетей типа proNET-10. Мы рассмотрим первым легкий случай.
Рассмотрим сеть с маркерным кольцом proNET-10. Как вы помните, из главы 2 мы знаем, что она использует небольшие целые числа в качестве физических адресов и позволяет пользователю выбрать аппаратный адрес при установке платы интерфейса в компьютер. Главной причиной, делающей разрешение адресов легким для сети proNET-10, является то, что раз можно назначать как IP-адреса, так и физические адреса, то можно выбрать их такими, что их части будут совпадать. Обычно при назначении IP-адресов поле идГВМ делается равным 1,2,3 и т.д., а затем при установке сетевого интерфейсного оборудования выбирается физический адрес, совпадающий с полем идГВМ в IP-адресе. Например, можно выбрать физический адрес 3 для машины, имеющей IP-адрес 192.5.48.3, так как 192.5.48.3 является адресом класса С, у которого поле идГВМ равно 3.
Для сетей, таких как proNET-10, вычисление физического адреса на основе IP-адреса тривиально. Вычисление состоит из выделения полу идентификатора ГВМ из IP-адреса. Это вычислительно эффективно, так как требует выполнения нескольких машинных команд. Это легко осуществить, так как может быть выполнено без обращения к внешним данным. И ,наконец, новые машины могут быть добавлены к сети без изменения данных или перекомпиляции кода. Концептуально выбор схемы нумерации, делающей разрешение адресов эффективным, означает выбор функции F, которая отображает IP-адреса в физические адреса. Разработчик может также выбрать схему нумерации физических адресов. Разрешение IP-адреса Ia означает вычисление
Pa=F(Ia)
Мы хотим, чтобы вычисление F было эффективным. Если множество физических адресов ограничено, можно по-другому эффективно сделать это отображение. Например, при использовании X.25 нельзя выбрать физические адреса. Обычно, шлюзы в сетях X.25 хранят пары IP-адресов и физических адресов X.25 в таблице и осуществляют поиск в этой таблице при разрешении IP-адресов. Чтобы сделать разрешение адресов эффективным в таких случаях, программное обеспечение может использовать хэш-функцию для поиска в таблице. Упражнение 5.1 предлагает еще один подход.
Чтобы понять, почему разрешение адресов так трудно в некоторых сетях, рассмотрим технологию Ethernetа. Как вы знаете из главы 2, Ethernet имеет 48-битовые физические адреса, назначаемые производителями при изготовлении интерфейсных плат. Как следствие, при выходе оборудования из строя и замене интерфейсной платы физический адрес машины меняется. Более того, так как адрес в Ethernetе имеет длину 48 бит, не стоит и рассчитывать, что его можно закодировать в 32-битном IP-адресе. Разработчики протоколов TCP/IP нашли конструктивное решение проблемы разрешения адресов для сетей, таких как Chaosnet или Ethernet, которые имеют возможность широковещания. Это решение позволяет добавлять машины к сети без перекомпиляции кода и без создания центральной базы данных. Чтобы избежать создания таблиц отображения разработчики решили использовать низкоуровневый протокол для динамической связки адресов. Названный Протокол Разрешения Адресов(ARP), он обеспечивает механизм, который является как эффективным, так и легким для реализации.
Как показывает рисунок 5.1 , идея, лежащая в основе динамического разрешения в 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, так как ему нужно послать запрос к В, то существует большая вероятность того, что ГВМ В в ближайшем будущем тоже потребуется послать пакеты к А. Если мы учтем потребности В, мы можем избежать передачи лишнего траффика по сети, заставив А включить связку своего IP-адреса с физическим в пакет при посылке запроса к В. Во-вторых, отметим, что так как А широковещательно передает свой начальный запрос, все машины в сети получают его и могут выделить и сохранить в своих кэшах связку между IP-адресом и физическим адресом для А. В-третьих, когда новая машина появляется в сети(например, когда загружается операционная система), мы можем избежать того, что какая-либо другая машина будет запускать ARP, если широковещательно распространим пару IP-адреса и физического адреса новой машины. Следующее правило обобщает уточнения:
ARP - это низкоуровневый протокол, который скрывает базовую физическую сетевую адресацию, позволяя назначать IP-адреса по нашему выбору каждой машине. Мы будем думать о нем как о части физической сетевой системы, а не как о части межсетевых протоколов.
Функционально ARP состоит из двух частей. Одна часть определяет физические адреса при посылке пакета, а другая отвечает на запросы от других машин. Разрешение адресов для выходящих пакетов кажется элементарным, но некоторые детали усложняют реализацию. Получив IP-адрес назначения, ГВМ просматривает кэш ARP, чтобы проверить, не знает ли он уже физического адреса для этого IP-адреса. Если ГВМ знает его, он выделяет физический адрес, помещает данные в кадр, используя этот адрес, и посылает этот кадр. Если же он не знает отображения, он должен широковещательно передать запрос ARP и ждать ответа. Широковещание запроса ARP для нахождения отображения адреса может оказаться сложным. Машина получателя может быть выключена или быть слишком занята, чтобы принять запрос. Если такое случится, отправитель может не получить ответа или ответ может задержаться. Так как Ethernet является системой с негарантированной доставкой, то исходный широковещательный запрос ARP тоже может быть потерян(в этом случае отправитель должен будет повторно отправлять его по крайней мере еще один раз). Между тем ГВМ должен хранить исходный передаваемый пакет, чтобы его можно было послать, когда будет разрешен адрес(если задержка становится значительной, ГВМ может уничтожить передаваемый пакет). Фактически, ГВМ должен решить, можно ли работать другим прикладным программам, пока он обрабатывает запрос ARP(в большинстве случаев можно). Если можно, то он должен учитывать случай, когда приложение будет генерировать дополнительные запросы ARP для того же адреса, не посылая широковещательный запрос несколько раз для одного и того же получателя.
Наконец, рассмотрим случай, когда машина А получила связку для машины В, но оборудование В вышло из строя и было заменено. Хотя адрес В изменился, не изменилась связка в кэше А, поэтому А будет использовать несуществующий аппаратный адрес, делая успешный прием невозможным. Этот случай показывает, почему важно, чтобы программное обеспечение ARP рассматривало свою таблицу связок как кэш и удаляло ее элементы по истечении фиксированного промежутка времени. Конечно, таймер для каждого элемента кэша должен сбрасываться всякий раз, когда прин