е зависимости от того, для чего предназначена ваша сеть. Даже если ваша сеть не имеет связи с объе- диненной сетью Internet, получение уникального номера желательно, так как в этом случае есть гарантия, что в будущем при включении в Internet или при подключении к сети другой организации не возникнет конфликта адресов. Одно из важнейших решений, которое необходимо принять при установке сети, заключается в выборе способа присвоения IP-адресов вашим машинам. Этот выбор должен учитывать перспективу роста сети. Иначе в дальнейшем вам придется менять адреса. Когда к сети подключено несколько сотен машин, изменение адресов становится почти невозможным. Организации, имеющие небольшие сети с числом узлов до 126, должны запрашивать сетевые номера класса C. Организации с большим числом машин могут получить несколько номеров класса C или номер класса B. Удобным средством структуризации сетей в рамках одной организации являются под- сети. 5.6. Подсети Адресное пространство сети internet может быть разделено на непере- секающиеся подпространства - "подсети", с каждой из которых можно рабо- тать как с обычной сетью TCP/IP. Таким образом единая IP-сеть организа- ции может строиться как объединение подсетей. Как правило, подсеть соот- ветствует одной физической сети, например, одной сети Ethernet. Конечно, использование подсетей необязательно. Можно просто назна- чить для каждой физической сети свой сетевой номер, например, номер ____________________ [2] SRI International, Room EJ210, 333 Ravenswood Avenue, Menlo Park, California 94025, USA. Тел. 1-800-235-3155. E-mail: NIC@NIC.DDN.MIL класса C. Однако такое решение имеет два недостатока. Первый, и менее существенный, заключается в пустой трате сетевых номеров. Более серьез- ный недостаток состоит в том, что если ваша организация имеет несколько сетевых номеров, то машины вне ее должны поддерживать записи о маршрутах доступа к каждой из этих IP-сетей. Таким образом, структура IP-сети организации становится видимой для всего мира. При каких-либо изменениях в IP-сети информация о них должна быть учтена в каждой из машин, поддер- живающих маршруты доступа к данной IP-сети. Подсети позволяют избежать этих недостатков. Ваша организация должна получить один сетевой номер, например, номер класса B. Стандарты TCP/IP определяют структуру IP-адресов. Для IP-адресов класса B первые два октета являются номером сети. Оставшаяся часть IP-адреса может использоваться как угодно. Например, вы можете решить, что третий октет будет определять номер подсети, а четверый октет - номер узла в ней. Вы должны описать конфигурацию подсетей в файлах, определяющих маршрутизацию IP-пакетов. Это описание является локальным для вашей организации и не видно вне ее. Все машины вне вашей организации видят одну большую IP- сеть. Следовательно, они должны поддерживать только маршруты доступа к шлюзам, соединяющим вашу IP-сеть с остальным миром. Изменения, происхо- дящие в IP-сети организации, не видны вне ее. Вы легко можете добавить новую подсеть, новый шлюз и т.п. 5.7. Как назначать номера сетей и подсетей После того, как решено использовать подсети или множество IP-сетей, вы должны решить, как назначать им номера. Обычно это довольно просто. Каждой физической сети, например, Ethernet или Token Ring, назначается отдельный номер подсети или номер сети. В некоторых случаях имеет смысл назначать одной физической сети несколько подсетевых номеров. Например, предположим, что имеется сеть Ethernet, охватывающая три здания. Ясно, что при увеличении числа машин, подключенных к этой сети, придется ее разделить на несколько отдельных сетей Ethernet. Для того, чтобы избе- жать необходимости менять IP-адреса, когда это произойдет, можно заранее выделить для этой сети три подсетевых номера - по одному на здание. (Это полезно и в том случае, когда не планируется физическое деление сети. Просто такая адресация позволяет сразу определить, где находится та или иная машина.) Однако прежде, чем выделять три различных подсетевых номера одной физической сети, тщательно проверьте, что все ваши программы спо- собны работать в такой среде. Вы также должны выбрать "маску подсети". Она используется сетевым программным обеспечением для выделения номера подсети из IP-адресов. Биты IP-адреса, определяющие номер IP-сети, в маске подсети должны быть равны 1, а биты, определяющие номер узла, в маске подсети должны быть равны 0. Как уже отмечалось, стандарты TCP/IP определяют количество октетов, задающих номер сети. Часто в IP-адресах класса B третий октет используется для задания номера подсети. Это позволяет иметь 256 подсе- тей, в каждой из которых может быть до 254 узлов. Маска подсети в такой системе равна 255.255.255.0. Но, если в вашей сети должно быть больше подсетей, а в каждой подсети не будет при этом более 60 узлов, то можно использовать маску 255.255.255.192. Это позволяет иметь 1024 подсети и до 62 узлов в каждой. (Напомним, что номера узлов 0 и "все единицы" используются особым образом.) Обычно маска подсети указывается в файле стартовой конфигурации сетевого программного обеспечения. Протоколы TCP/IP позволяют также зап- рашивать эту информацию по сети. 5.8. Имена Людям удобнее называть машины по именам, а не числами. Например, у машины по имени alpha может быть IP-адрес 223.1.2.1. В маленьких сетях информация о соответствии имен IP-адресам хранится в файлах "hosts" на каждом узле. Конечно, название файла зависит от конкретной реализации. В больших сетях эта информация хранится на сервере и доступна по сети. Несколько строк из файла "hosts" могут выглядеть примерно так: 223.1.2.1 alpha 223.1.2.2 beta 223.1.2.3 gamma 223.1.2.4 delta 223.1.3.2 epsilon 223.1.4.2 iota В первом столбце - IP-адрес, во втором - название машины. В большинстве случаев файлы "hosts" могут быть одинаковы на всех узлах. Заметим, что о узле delta в этом файле есть всего одна запись, хотя он имеет три IP-адреса (рис.11). Узел delta доступен по любому из этих IP-адресов. Какой из них используется, не имеет значения. Когда узел delta получает IP-пакет и проверяет IP-адрес места назначения, то он опознает любой из трех своих IP-адресов. IP-сети также могут иметь имена. Если у вас есть три IP-сети, то файл "networks" может выглядеть примерно так: 223.1.2 development 223.1.3 accounting 223.1.4 factory В первой колонке - сетевой номер, во второй - имя сети. В данном примере alpha является узлом номер 1 в сети development, beta является узлом номер 2 в сети development и т.д. Показанный выше файл hosts удовлетворяет потребности пользователей, но для управления сетью internet удобнее иметь названия всех сетевых интерфейсов. Менеджер сети, возможно, заменит строку, относящуюся к delta: 223.1.2.4 devnetrouter delta 223.1.3.1 accnetrouter 223.1.4.1 facnetrouter Эти три строки файла hosts задают каждому IP-адресу узла delta сим- вольные имена. Фактически, первый IP-адрес имеет два имени: "dev- netrouter" и "delta", которые являются синонимами. На практике имя "delta" используется как общеупотребительное имя машины, а остальные три имени - для администрирования сети. Файлы hosts и networks используются командами администрирования и прикладными программами. Они не нужны собственно для работы сети inter- net, но облегчают ее использование. 5.9. IP-таблица маршрутов Как модуль IP узнает, какой именно сетевой интерфейс нужно использо- вать для отправления IP-пакета? Модуль IP осуществляет поиск в таблице маршрутов. Ключом поиска служит номер IP-сети, выделенный из IP-адреса места назначения IP-пакета. Таблица маршрутов содержит по одной строке для каждого маршрута. Основными столбцами таблицы маршрутов являются номер сети, флаг прямой или косвенной маршрутизации, IP-адрес шлюза и номер сетевого интерфейса. Эта таблица используется модулем IP при обработке каждого отправляемого IP-пакета. В большинстве систем таблица маршрутов может быть изменена с помощью команды "route". Содержание таблицы маршрутов определяется менеджером сети, поскольку менеджер сети присваивает машинам IP-адреса. 5.10. Подробности прямой маршрутизации Рассмотрим более подробно, как происходит маршрутизация в одной физической сети. ------------- ------------- | alpha | | beta | | 223.1.2.1 | | 223.1.2.2 | | 1 | | 1 | ------------- ------------- | | ------o-----------------------o------- Ethernet 1 IP-сеть "development" 223.1.2 Рис.10. Одна физическая сеть Таблица маршрутов в узле alpha выглядит так: ---------------------------------------------------------- | сеть флаг вида шлюз номер | | маршрутизации интерфейса | ---------------------------------------------------------- | development прямая <пусто> 1 | ---------------------------------------------------------- Табл.9. Пример таблицы маршрутов В данном простом примере все узлы сети имеют одинаковые таблицы маршру- тов. Для сравнения ниже представлена та же таблица, но вместо названия сети указан ее номер. ---------------------------------------------------------- | сеть флаг вида шлюз номер | | маршрутизации интерфейса | ---------------------------------------------------------- | 223.1.2 прямая <пусто> 1 | ---------------------------------------------------------- Табл.10. Пример таблицы маршрутов с номерами сетей 5.11. Порядок прямой маршрутизации Узел alpha посылает IP-пакет узлу beta. Этот пакет находится в модуле IP узла alpha, и IP-адрес места назначения равен IP-адресу beta (223.1.2.2). Модуль IP с помощью маски подсети выделяет номер сети из IP-адреса и ищет соответствующую ему строку в таблице маршрутов. В дан- ном случае подходит первая строка. Остальная информация в найденной строке указывает на то, что машины этой сети доступны напрямую через интерфейс номер 1. С помощью ARP- таблицы выполняется преобразование IP-адреса в соответствующий Ethernet- адрес, и через интерфейс 1 Ethernet-кадр посылается узлу beta. Если прикладная программа пытается послать данные по IP-адресу, который не принадлежит сети development, то модуль IP не сможет найти соответствующую запись в таблице маршрутов. В этом случае модуль IP отб- расывает IP-пакет. Некоторые реализации протокола возвращают сообщение об ошибке "Сеть не доступна". 5.12. Подробности косвенной маршрутизации Теперь рассмотрим более сложный порядок маршрутизации в IP-сети, изображенной на рис.11. Таблица маршрутов в узле alpha выглядит так: ---------------------------------------------------------- | сеть флаг вида шлюз номер | | маршрутизации интерфейса | ---------------------------------------------------------- | development прямая <пусто> 1 | | accounting косвенная devnetrouter 1 | | factory косвенная devnetrouter 1 | ---------------------------------------------------------- Табл.11. Таблица маршрутов в узле alpha ------------- | delta | ------------- | 223.1.2.4 | ------------- | alpha | | 223.1.4.1 | | epsilon | | 223.1.2.1 | | 223.1.3.1 | | 223.1.3.2 | | 1 | | 1 2 3 | | 1 | ------------- ------------- ------------- | | | | | ------o------------------o- | -o-----------------o--------- Ethernet 1 | Ethernet 2 IP-сеть "development" | IP-сеть "accounting" 223.1.2 | 223.1.3 | | ------------- | | iota | | | 223.1.4.2 | | | 1 | | ------------- | | ---o----------o------------------- Ethernet 3 IP-сеть "factory" 223.1.4 Рис.11. Подробная схема трех сетей Та же таблица с IP-адресами вместо названий. ---------------------------------------------------------- | сеть флаг вида шлюз номер | | маршрутизации интерфейса | ---------------------------------------------------------- | 223.1.2 прямая <пусто> 1 | | 223.1.3 косвенная 223.1.2.4 1 | | 223.1.4 косвенная 223.1.2.4 1 | ---------------------------------------------------------- Табл.12. Таблица маршрутов в узле alpha (с номерами) В столбце "шлюз" таблицы маршрутов узла alpha указывается IP-адрес точки соединения узла delta с сетью development. 5.13. Порядок косвенной маршрутизации Узел alpha посылает IP-пакет узлу epsilon. Этот пакет находится в модуле IP узла alpha, и IP-адрес места назначения равен IP-адресу узла epsilon (223.1.3.2). Модуль IP выделяет сетевой номер из IP-адреса (223.1.3) и ищет соответствующую ему строку в таблице маршрутов. Соот- ветствие находится во второй строке. Запись в этой строке указывает на то, что машины требуемой сети дос- тупны через шлюз devnetrouter. Модуль IP в узле alpha осуществляет поиск в ARP-таблице, с помощью которого определяет Ethernet-адрес, соответству- ющий IP-адресу devnetrouter. Затем IP-пакет, содержащий IP-адрес места назначения epsilon, посылается через интерфейс 1 шлюзу devnetrouter. IP-пакет принимается сетевым интерфейсом в узле delta и передается модулю IP. Проверяется IP-адрес места назначения, и, поскольку он не соответствует ни одному из собственных IP-адресов delta, шлюз решает рет- ранслировать IP-пакет. Модуль IP в узле delta выделяет сетевой номер из IP-адреса места назначения IP-пакета (223.1.3) и ищет соответствующую запись в таблице маршрутов. Таблица маршрутов в узле delta выглядит так: ---------------------------------------------------------- | сеть флаг вида шлюз номер | | маршрутизации интерфейса | ---------------------------------------------------------- | development прямая <пусто> 1 | | accounting прямая <пусто> 3 | | factory прямая <пусто> 2 | ---------------------------------------------------------- Табл.13. Таблица маршрутов в узле delta Та же таблица с IP-адресами вместо названий. ---------------------------------------------------------- | сеть флаг вида шлюз номер | | маршрутизации интерфейса | ---------------------------------------------------------- | 223.1.2 прямая <пусто> 1 | | 223.1.3 прямая <пусто> 3 | | 223.1.4 прямая <пусто> 2 | ---------------------------------------------------------- Табл.14. Таблица маршрутов в узле delta (с номерами) Соответствие находится во второй строке. Теперь модуль IP напрямую посы- лает IP-пакет узлу epsilon через интерфейс номер 3. Пакет содержит IP- и Ethernet-адреса места назначения равные epsilon. Узел epsilon принимает IP-пакет, и его модуль IP проверяет IP-адрес места назначения. Он соответствует IP-адресу epsilon, поэтому содержаще- еся в IP-пакете сообщение передается протокольному модулю верхнего уровня.  * 6. Установка маршрутов *  До сих пор мы рассматривали то, как используется таблица маршрутов для маршрутизации IP-пакетов. Но откуда берется информация в самой таб- лице маршрутов? В данном разделе мы рассмотрим методы, позволяющие под- держивать корректность таблиц маршрутов. 6.1. Фиксированные маршруты Простейший способ проведения маршрутизации состоит в установке марш- рутов при запуске системы с помощью специальных команд. Этот метод можно применять в относительно маленьких IP-сетях, в особенности, если их кон- фигурации не часто меняются. На практике большинство машин автоматически формирует таблицы марш- рутов. Например, UNIX добавляет записи о IP-сетях, к которым есть непос- редственный доступ. Стартовый файл может содержать команды ifconfig ie0 128.6.4.4 netmask 255.255.255.0 ifconfig ie1 128.6.5.35 netmask 255.255.255.0 Они показывают, что существуют два сетевых интерфейса, и устанавливают их IP-адреса. Система может автоматически создать две записи в таблице маршрутов: ---------------------------------------------------------- | сеть флаг вида шлюз интерфейс | | маршрутизации | ---------------------------------------------------------- | 128.6.4 прямая <пусто> ie0 | | 128.6.5 прямая <пусто> ie1 | ---------------------------------------------------------- Табл.15. Автоматически создаваемые записи Эти записи определяют, что IP-пакеты для локальных подсетей 128.6.4 и 128.6.5 должны посылаться через указанные интерфейсы. В стартовом файле могут быть команды, определяющие маршруты доступа к другим IP-сетям. Например, route add 128.6.2.0 128.6.4.1 1 route add 128.6.6.0 128.6.5.35 0 Эти команды показывают, что в таблицу маршрутов должны быть добавлены две записи. Первый адрес в командах является IP-адресом сети, второй адрес указывает шлюз, который должен использоваться для доступа к данной IP- сети, а третий параметр является метрикой. Метрика показывает, на каком "расстоянии" находится описываемая IP-сеть. В данном случае метрика - это количество шлюзов на пути между двумя IP-сетями. Маршруты с метрикой 1 и более определяют первый шлюз на пути к IP-сети. Маршруты с метрикой 0 показывают, что никакой шлюз не нужен - данный маршрут задает дополни- тельный сетевой номер локальной IP-сети. Таким образом, команды, приведенные в примере, говорят о том, что для доступа к IP-сети 128.6.2 должен использоваться шлюз 128.6.4.1, а IP-сеть 128.6.6 - это просто дополнительный номер для физической сети, подключенной к интерфейсу 128.6.5.35. --------------------------------------------------------- | сеть флаг вида шлюз интерфейс | | маршрутизации | --------------------------------------------------------- | 128.6.2 косвенная 128.6.4.1 ie0 | | 128.6.6 прямая <пусто> ie1 | --------------------------------------------------------- Табл.16. Записи, добавляемые в таблицу маршрутов Можно определить маршрут по умолчанию, который используется в тех случаях, когда IP-адрес места назначения не встречается в таблице маршру- тов явно. Обычно маршрут по умолчанию указывает IP-адрес шлюза, который имеет достаточно информации для маршрутизации IP-пакетов со всеми возмож- ными адресами назначения. Если ваша IP-сеть имеет всего один шлюз, тогда все, что нужно сде- лать, - это установить единственную запись в таблице маршрутов, указав этот шлюз как маршрут по умолчанию. После этого можно не заботиться о формировании маршрутов в других узлах. (Конечно, сам шлюз требует больше внимания.) Следующие разделы посвящены IP-сетям, где есть несколько шлюзов. 6.2. Перенаправление маршрутов Большинство экспертов по межсетевому взаимодействию рекомендуют оставлять решение проблем маршрутизации шлюзам. Плохо иметь на каждой машине большую таблицу маршрутов. Дело в том, что при каких-либо измене- ниях в IP-сети приходится менять информацию во всех машинах. Например, при отключении какого-нибудь канала связи для восстановления нормальной работы нужно ждать, пока кто-то заметит это изменение в конфигурации IP- сети и внесет исправления во все таблицы маршрутов. Простейший способ поддержания адекватности маршрутов заключается в том, что изменение таблицы маршрутов каждой машины выполняется по коман- дам только одного шлюза. Этот шлюз должен быть установлен как маршрут по умолчанию. (В ОС UNIX это делается командой "route add default 128.6.4.27 1", где 128.6.4.27 является IP-адресом шлюза.) Как было опи- сано выше, каждая машина посылает IP-пакет шлюзу по умолчанию в том слу- чае, когда не находит лучшего маршрута. Однако, когда в IP-сети есть несколько шлюзов, этот метод работает не так хорошо. Кроме того, если таблица маршрутов имеет только одну запись о маршруте по умолчанию, то как использовать другие шлюзы, если это более выгодно? Ответ состоит в том, что большинство шлюзов способны выполнять "перенаправление" в тех случаях, когда они получают IP-пакеты, для которых существуют более выгодные маршруты. "Перенаправление" является специальным типом сообще- ния протокола ICMP (Internet Control Message Protocol - протокол межсете- вых управляющих сообщений). Сообщение о перенаправлении содержит инфор- мацию, которую можно интерпретировать так: "В будущем для IP-адреса XXXX используйте шлюз YYYY, а не меня". Корректные реализации TCP/IP должны использовать сообщения о перенаправлении для добавления записей в таблицу маршрутов. Предположим, таблица маршрутов в начале выглядит следующим образом: -------------------------------------------------------- | адрес флаг вида шлюз интерфейс | | назначения маршрутизации | -------------------------------------------------------- | 127.0.0 прямая <пусто> lo0 | | 128.6.4 прямая <пусто> pe0 | | default косвенная 128.6.4.27 pe0 | -------------------------------------------------------- Табл.17. Таблица маршрутов в начале работы Эта таблица содержит запись о локальной IP-сети 128.6.4 и маршрут по умолчанию, указывающий шлюз 128.6.4.27. Допустим, что существует шлюз 128.6.4.30, который является лучшим путем доступа к IP-сети 128.6.7. Как им воспользоваться? Предположим, что нужно посылать IP-пакеты по IP- адресу 128.6.7.23. Первый IP-пакет пойдет на шлюз по умолчанию, так как это единственный подходящий маршрут, описанный в таблице. Однако шлюз 128.6.4.27 знает, что существует лучший маршрут, проходящий через шлюз 128.6.4.30. (Как он узнает об этом, мы сейчас не рассматриваем. Сущест- вует довольно простой метод определения лучшего маршрута.) В этом случае шлюз 128.6.4.27 возвращает сообщение перенаправления, где указывает, что IP-пакеты для узла 128.6.7.23 должны посылаться через шлюз 128.6.4.30. Модуль IP на машине-отправителе должен добавить запись в таблицу маршру- тов: -------------------------------------------------------- | адрес флаг вида шлюз интерфейс | | назначения маршрутизации | -------------------------------------------------------- | 128.6.7.23 косвенная 128.6.4.30 pe0 | -------------------------------------------------------- Табл.18. Новая запись в таблице маршрутов Все последующие IP-пакеты для узла 128.6.7.23 будут посланы прямо через указанный шлюз. До сих пор мы рассматривали способы добавления маршрутов в IP- таблицу, но не способы их исключения. Что случится, если шлюз будет вык- лючен? Хотелось бы иметь способ возврата к маршруту по умолчанию после того, как какой-либо маршрут разрушен. Однако, если шлюз вышел из строя или был выключен, то он уже не может послать сообщение перенаправления. Поэтому должен существовать метод определения работоспособности шлюзов, с которыми ваша машина связана непосредственно. Лучший способ обнаружения неработающих шлюзов основан на выявлении "плохих" маршрутов. Модуль TCP поддерживает различные таймеры, которые помогают ему определить разрыв соединения. Когда случается сбой, то можно пометить маршрут как "плохой" и вернуться к маршруту по умолчанию. Аналогичный метод может использо- ваться при обработке ошибок шлюза по умолчанию. Если два шлюза отмечены как шлюзы по умолчанию, то машина может использовать их по очереди, переключаясь между ними при возникновении сбоев. 6.3. Слежение за маршрутизацией Заметим, что сообщения перенаправления не могут использоваться самими шлюзами. Перенаправление - это просто способ оповещения обычного узла о том, что нужно использовать другой шлюз. Сами шлюзы должны иметь полную картину о положении дел в сети internet и уметь вычислять опти- мальные маршруты доступа к каждой подсети. Обычно они поддерживают эту картину, обмениваясь информацией между собой. Для этой цели существуют несколько специальных протоколов маршрутизации. Один из способов, с помощью которого узлы могут определять действующие шлюзы, состоит в сле- жении за обменом сообщениями между ними. Для большинства протоколов маршрутизации существует программное обеспечение, позволяющее обычным узлам осуществлять такое слежение. При этом на узлах поддерживается пол- ная картина положения дел в сети internet точно также, как это делается в шлюзах. Динамическая корректировка таблицы маршрутов позволяет посылать IP-пакеты по оптимальным маршрутам. Таким образом, слежение за маршрутизацией в некотором смысле "решает" проблему поддержания корректности таблиц маршрутов. Однако существуют несколько причин, по которым этот метод применять не рекомен- дуется. Наиболее серьезной проблемой является то, что протоколы маршру- тизации пока еще подвергаются частым пересмотрам и изменениям. Появля- ются новые протоколы маршрутизации. Эти изменения должны учитываться в программном обеспечении всех машин. Несколько более специальная проблема связана с бездисковыми рабочими станциями. По своей природе бездисковые машины сильно зависят от сети и от файл-серверов, с которых они осуществляют загрузку программ, и где располагается их область своппинга. Исполнение программ, следящих за широковещательными передачами в сети, на бездисковых машинах связано с большими трудностями. Протоколы маршрутизации построены в основном на широковещательных передачах. Например, все сетевые шлюзы могут широкове- щательно передавать содержание своих таблиц маршрутов через каждые 30 секунд. Программы, которые следят за такими передачами, должны быть заг- ружены на бездисковые станции через сеть. На достаточно занятой машине программы, которые не используются в течение нескольких секунд, обычно отправляются в область своппинга. Поэтому программы, следящие за маршру- тизацией, большую часть времени находятся в своппинге. Когда они вновь активизируются, должна производиться подкачка из своппинга. Как только посылается широковещательное сообщение, все машины активизируют прог- раммы, следящие за маршрутизацией. Это приводит к тому, что многие без- дисковые станции будут выполнять подкачку из своппинга в одно и тоже время. Поэтому в сети возникнет временная перегрузка. Таким образом, исполнение программ, прослушивающих широковещательные передачи, на без- дисковых рабочих станциях очень нежелательно. 6.4. Протокол ARP с представителем Протокол ARP с представителем является альтернативным методом, поз- воляющим шлюзам принимать все необходимые решения о маршрутизации. Он применяется в сетях с широковещательной передачей, где для отображения IP-адресов в сетевые адреса используется протокол ARP или ему подобный. Здесь мы вновь будем предполагать, что имеем дело с сетью Ethernet. Во многом метод, реализуемый протоколом ARP с представителем, анало- гичен использованию маршрутов по умолчанию и сообщений перенаправления. Но протокол ARP с представителем не затрагивает таблиц маршрутов, все делается на уровне адресов Ethernet. Протокол ARP с представителем может использоваться либо для маршрутизации IP-пакетов ко всем сетям, либо только в локальной сети, либо в какой-то комбинации подсетей. Проще всего продемонстрировать его использование при работе со всеми адресами. Чтобы использовать протокол, нужно настроить узел так, как будто все машины в мире подключены непосредственно к вашей локальной сети Ethernet. В ОС UNIX это делается командой "route add default 128.6.4.2 0", где 128.6.4.2 - IP-адрес вашего узла. Как уже отмечалось, метрика 0 говорит о том, что все IP-пакеты, которым подходит данный маршрут, должны посы- латься напрямую по локальной сети. Когда нужно послать IP-пакет узлу в локальной сети Ethernet, ваша машина должна определить Ethernet-адрес этого узла. Для этого она использует ARP-таблицу. Если в ARP-таблице уже есть запись, соответству- ющая IP-адресу места назначения, то из нее просто берется Ethernet-адрес, и кадр, содержащий IP-пакет, отправляется. Если такой записи нет, то посылается широковещательный ARP-запрос. Узел с искомым IP-адресом наз- начения принимает его и в ARP-ответе сообщает свой Ethernet-адрес. Эти действия соответствуют обычному протоколу ARP, описанному выше. Протокол ARP с представителем основан на том, что шлюзы работают как представители удаленных узлов. Предположим, в подсети 128.6.5 имеется узел 128.6.5.2 (узел A на рис.12). Он желает послать IP-пакет узлу 128.6.4.194, который подключен к другой сети Ethernet (узел B в подсети 128.6.4). Существует шлюз с IP-адресом 128.6.5.1, соединяющий две под- сети (шлюз R). сеть 1 сеть 2 128.6.5 128.6.4 ----o----------------o--- --o---------------o-------- | | | | ------------- ------------- --------------- | 128.6.5.2 | | 128.6.5.1 | | 128.6.4.194 | | A | | 128.6.4.1 | | B | ------------- | R | --------------- ------------- Рис.12. Сеть, использующая протокол ARP с представителем Если в ARP-таблице узла A нет маршрута доступа к узлу B, то узел A посы- лает ARP-запрос узлу B. Фактически машина A спрашивает: "Если кто-нибудь знает Ethernet-адрес узла 128.6.4.194, сообщите мне его". Узел B не может ответить на запрос самостоятельно. Он подключен к другой сети Eth- ernet и никогда даже не увидит этот ARP-запрос. Однако шлюз R может работать от его имени. Шлюз R отвечает: "Я здесь, IP-адресу 128.6.4.194 соответствует Ethernet-адрес 2:7:1:0:EB:CD", где 2:7:1:0:EB:CD в действи- тельности является Ethernet-адресом шлюза. Это создает иллюзию, что узел 128.6.4.194 подключен непосредственно к той же локальной сети Ethernet, что и узел A, и имеет Ethernet-адрес 2:7:1:0:EB:CD. Когда узел A захочет послать новый IP-пакет узлу B, он использует указанный Ethernet-адрес. Кадр, содержащий IP-пакет, попадет к шлюзу R, а он переправит его по наз- начению. Заметим, что полученный эффект такой же, как если бы в таблице марш- рутов была запись -------------------------------------------------------- | адрес флаг вида шлюз интерфейс | | назначения маршрутизации | -------------------------------------------------------- | 128.6.4.194 косвенная 128.6.5.1 pe0 | -------------------------------------------------------- за исключением того, что маршрутизация выполняется на уровне модуля ARP, а не модуля IP. Обычно рекомендуется использовать таблицу маршрутов, так как архи- тектура протоколов TCP/IP предусматривает выполнение маршрутизации на межсетевом уровне. Однако иногда протокол ARP с представителем очень полезен. Он может помочь в следующих случаях: 1) в IP-сети есть узел, который не умеет работать с подсетями; 2) в IP-сети есть узел, который не может соответствующим образом реаги- ровать на сообщения перенаправления; 3) нежелательно выбирать какой-либо шлюз как маршрут по умолчанию; 4) программное обеспечение не способно восстанавливаться при сбоях на маршрутах. Иногда протокол ARP с представителем выбирают из-за удобства. Дело в том, что он упрощает работу по начальной установке таблицы маршрутов. Даже в простейших IP-сетях требуется устанавливать маршрут по умолчанию, то есть использовать команду типа "route add defailt ...", как в ОС UNIX. При изменении IP-адреса шлюза эту команду приходится менять во всех узлах. Если же использовать протокол ARP с представителем, т.е. в команде установки маршрута по умолчанию указать метрику 0, то при замене IP-адреса шлюза команду начальной установки менять не придется, так как протокол ARP с представителем не требует явного задания IP-адресов шлю- зов. Любой шлюз может ответить на ARP-запрос. Для того, чтобы избавить пользователей от обязательной начальной установки маршрутов, некоторые реализации TCP/IP используют протокол ARP с представителем по умолчанию в тех случаях, когда не находят подходящих записей в таблице маршрутов.  * 7. Протокол UDP *  Протокол UDP (User Datagram Protocol - протокол пользовательских датаграмм) является одним из двух основных протоколов, расположенных непосредственно над IP. Он предоставляет прикладным процессам транспорт- ные услуги, которые не многим отличаются от услуг, предоставляемых прото- колом IP. Протокол UDP обеспечивает ненадежную доставку датаграмм и не поддерживает соединений из конца в конец. К заголовку IP-пакета он добавляет два поля, одно из которых, поле "порт", обеспечивает мультип- лексирование информации между разными прикладными процессами, а другое поле - "контрольная сумма" - позволяет поддерживать целостность данных. Примерами сетевых приложений, использующих UDP, являются NFS (Net- work File System - сетевая файловая система) и SNMP (Simple Network Management Protocol - простой протокол управления сетью). 7.1. Порты Взаимодействие между прикладными процессами и модулем UDP осуществ- ляется через UDP-порты. Порты нумеруются начиная с нуля. Прикладной процесс, предоставляющий некоторые услуги другим прикладным процессам (сервер), ожидает поступления сообщений в порт, специально выделенный для этих услуг. Сообщения должны содержать запросы на предоставление услуг. Они отправляются процессами-клиентами. Например, сервер SNMP всегда ожидает поступлений сообщений в порт 161. Если клиент SNMP желает получить услугу, он посылает запрос в UDP- порт 161 на машину, где работает сервер. В каждом узле может быть только один сервер SNMP, так как существует только один UDP-порт 161. Данный номер порта является общеизвестным, то есть фиксированным номером, офици- ально выделенным для услуг SNMP. Общеизвестные номера определяются стан- дартами Internet. Данные, отправляемые прикладным процессом через модуль UDP, дости- гают места назначения как единое целое. Например, если процесс- отправитель производит 5 записей в UDP-порт, то процесс-получатель должен будет сделать 5 чтений. Размер каждого записанного сообщения будет сов- падать с размером каждого прочитанного. Протокол UDP сохраняет границы сообщений, определяемые прикладным процессом. Он никогда не объединяет несколько сообщений в одно и не делит одно сообщение на части. 7.2. Контрольное суммирование Когда модуль UDP получает датаграмму от модуля IP, он проверяет контрольную сумму, содержащуюся в ее заголовке. Если контрольная сумма равна нулю, то это означает, что отправитель датаграммы ее не подсчиты- вал, и, следовательно, ее нужно игнорировать. Если два модуля UDP взаи- модействуют только через одну сеть Ethernet, то от контрольного суммиро- вания можно отказаться, так как средства Ethernet обеспечивают достаточ- ную степень надежности обнаружения ошибок передачи. Это снижает наклад- ные расходы, связанные с работой UDP. Однако рекомендуется всегда выпол- нять контрольное суммирование, так как возможно в какой-то момент измене- ния в таблице маршрутов приведут к тому, что датаграммы будут посылаться через менее надежную среду. Если контрольная сумма правильная (или равна нулю), то проверяется порт назначения, указанный в заголовке датаграммы. Если к этому порту подключен прикладной процесс, то прикладное сообщение, содержащееся в датаграмме, становится в очередь для прочтения. В остальных случаях датаграмма отбрасывается. Если датаграммы поступают быстрее, чем их успевает обрабатывать прикладной процесс, то при переполнении очереди сообщений поступающие датаграммы отбрасываются модулем UDP.  * 8. Протокол TCP *  Протокол TCP предоставляет транспортные услуги, отличающиеся от услуг UDP. Вместо ненадежной доставки датаграмм без установления соеди- нений, он обеспечивает гарантированную доставку с установлением соедине- ний в виде байтовых потоков. Протокол TCP используется в тех случаях, когда требуется надежная доставка сообщений. Он освобождает прикладные процессы от необходимости использовать таймауты и повторные передачи для обеспечения надежности. Наиболее типичными прикладными процессами, использующими TCP, являются FTP (File Transfer Protocol - протокол передачи файлов) и TELNET. Кроме того, TCP используют система X-Window, rcp (remote copy - удаленное копи- рование) и другие "r-команды". Большие возможности TCP даются не бесп- латно. Реализация TCP требует большой производительности процессора и большой пропускной способности сети. Внутренняя структура модуля TCP гораздо сложнее структуры модуля UDP. Прикладные процессы взаимодействуют с модулем TCP через порты. Для отдельных приложений выделяются общеизвестные номера портов. Например, сервер TELNET использует порт номер 23. Клиент TELNET может получать услуги от сервера, если установит соединение с TCP-портом 23 на его машине. Когда прикладной процесс начинает использовать TCP, то модуль TCP на машине клиента и модуль TCP на машине сервера начинают общаться. Эти два оконечных модуля TCP поддерживают информацию о состоянии соединения, называемого виртуальным каналом. Этот виртуальный канал потребляет ресурсы обоих оконечных модулей TCP. Канал является дуплексным; данные могут одновременно передаваться в обоих направлениях. Один прикладной процесс пишет данные в TCP-порт, они проходят по сети, и другой приклад- ной процесс читает их из своего TCP-порта. Протокол TCP разбивает поток байт на пакеты; он не сохраняет границ между записями. Например, если один прикладной процесс делает 5 записей в TCP-порт, то прикладной процесс на другом конце виртуального канала может выполнить 10 чтений для того, чтобы получить все данные. Но этот же процесс может получить все данные сразу, сделав только одну операцию чтения. Не существует зависимости между чис