е зависимости от того, длЯ
чего предназначена ваша сеть.  „аже если ваша сеть не имеет свЯзи с объе-
диненной сетью 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 чтений длЯ того, чтобы получить все данные.  Ќо этот
же процесс может получить все данные сразу, сделав только  одну  операцию
чтениЯ.   Ќе  существует зависимости между чис