
                         1.  Введение


     Семейство протоколов TCP/IP широко  применяется  во  всем  мире  для
объединения компьютеров в сеть Internet.  Единая сеть Internet состоит из
множества сетей различной физической природы,  от  локальных  сетей  типа
Ethernet  и Token Ring, до глобальных сетей типа NSFNET.  Основное внима-
ние в книге уделяется принципам организации  межсетевого  взаимодействия.
Многие технические детали, исторические вопросы опущены.  Более подробную
информацию о протоколах TCP/IP можно найти в RFC (Requests For  Comments)
-  специальных  документах,  выпускаемых  Сетевым  Информационным Центром
(Network Information Center - NIC).  Приложение 1  содержит  путеводитель
по  RFC,  а  приложение 2 отражает положение дел в области стандартизации
протоколов семейства TCP/IP на начало 1991 года.

     В книге приводятся примеры, основанные на  реализации  TCP/IP  в  ОС
UNIX.  Однако основные положения применимы ко всем реализациям TCP/IP.

     Надеюсь, что эта книга будет полезна тем, кто профессионально  рабо-
тает или собирается начать работать в среде TCP/IP: системным администра-
торам, системным программистам и менеджерам сети.

                              2.  Основы TCP/IP

     Термин "TCP/IP" обычно обозначает все, что связано с протоколами TCP
и  IP.   Он охватывает целое семейство протоколов, прикладные программы и
даже саму сеть.  В состав семейства входят протоколы UDP, ARP, ICMP, TEL-
NET,  FTP  и  многие другие.  TCP/IP - это технология межсетевого взаимо-
действия,  технология  internet.   Сеть,  которая  использует  технологию
internet, называется "internet".  Если речь идет о глобальной сети, объе-
диняющей множество сетей с технологией internet, то ее называют Internet.

2.1.  Модуль IP создает единую логическую сеть


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

     Когда необходимо передать пакет между машинами, подключенными к раз-
ным подсетям, то машина-отправитель посылает пакет в соответствующий шлюз
(шлюз подключен к подсети также как обычный узел).  Оттуда пакет  направ-
ляется по определенному маршруту через систему шлюзов и подсетей, пока не
достигнет шлюза, подключенного к той же подсети, что и машина-получатель;
там  пакет  направляется  к  получателю.   Объединенная сеть обеспечивает
датаграммный сервис.

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


2.2.  Структура связей протокольных модулей


     Логическая структура сетевого программного обеспечения, реализующего
протоколы  семейства  TCP/IP  в  каждом узле сети internet, изображена на
рис.1.  Прямоугольники обозначают обработку данных, а линии,  соединяющие
прямоугольники,  -  пути  передачи  данных.   Горизонтальная  линия внизу
рисунка обозначает кабель сети Ethernet, которая используется в  качестве
примера  физической  среды;  "o"  - это трансивер.  Знак "*" - обозначает


                         ------------------------------
                         |    прикладные процессы     |
                         |  ... \ | / ... \ | / ...   |
                         |     -------   -------      |
                         |     | TCP |   | UDP |      |
                         |     -------   -------      |
                         |           \    /           |
                         |           ------           |
                         |  -------  | IP |           |
                         |  | ARP |  -*----           |
                         |  -------   |               |
                         |         \  |               |
                         |        --------            |
                         |        | ENET |            |
                         |        ---@----            |
                         |           |                |
                         ------------|-----------------
                                     |
                  -------------------o--------
                   кабель Ethernet

        Рис.1. Структура протокольных модулей в узле сети TCP/IP

IP-адрес, а "@" - адрес узла в сети Ethernet (Ethernet-адрес).  Понимание
этой  логической структуры является основой для понимания всей технологии
internet.  В дальнейшем мы будем часто ссылаться на эту схему.

2.3.  Терминология

     Введем ряд базовых терминов, которые мы будем использовать  в  даль-
нейшем.

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

     Название блока данных, передаваемого по сети, зависит  от  того,  на
каком уровне стека протоколов он находится.  Блок данных, с которым имеет
дело сетевой интерфейс, называется кадром;  если  блок  данных  находится
между сетевым интерфейсом и модулем IP, то он называется IP-пакетом; если
он - между модулем IP и модулем UDP, то  -  UDP-датаграммой;  если  между
модулем  IP  и  модулем TCP, то - TCP-сегментом (или транспортным сообще-
нием); наконец, если блок данных находится на уровне  сетевых  прикладных
процессов,  то  он  называется  прикладным сообщением.

     Эти определения, конечно, несовершенны и неполны.   К  тому  же  они
меняются  от   публикации   к  публикации.   Более подробные  определения
можно  найти в RFC-1122,  раздел 1.3.3.

2.4.  Потоки данных

     Рассмотрим потоки данных, проходящие через стек протоколов,  изобра-
женный на рис.1.  В случае использования протокола TCP (Transmission Con-
trol Protocol - протокол управления передачей), данные  передаются  между
прикладным  процессом  и  модулем  TCP.   Типичным  прикладным процессом,
использующим протокол TCP, является модуль FTP (File Transfer Protocol  -
протокол   передачи   файлов).   Стек  протоколов  в  этом  случае  будет
FTP/TCP/IP/ENET.  При использовании протокола UDP (User Datagram Protocol
-  протокол пользовательских датаграмм), данные передаются между приклад-
ным процессом и модулем UDP.  Например, SNMP (Simple  Network  Management
Protocol  -  простой  протокол управления сетью) пользуется транспортными
услугами UDP.  Его стек протоколов выглядит так: SNMP/UDP/IP/ENET.

     Модули TCP, UDP и драйвер Ethernet являются мультиплексорами n x  1.

Действуя  как  мультиплексоры,  они  переключают несколько входов на один

выход.  Они также являются демультиплексорами 1 x n.   Как  демультиплек-

соры,  они переключают один вход на один из многих выходов в соответствии

с полем типа в заголовке протокольного блока данных (рис.2).


     Когда Ethernet-кадр попадает в драйвер сетевого интерфейса Ethernet,

он  может быть направлен либо в модуль ARP (Address Resolution Protocol -

адресный протокол), либо в модуль IP (Internet Protocol - межсетевой про-

токол).   На то, куда должен быть направлен Ethernet-кадр, указывает зна-

чение поля типа в заголовке кадра.


     Если IP-пакет попадает в модуль IP, то  содержащиеся  в  нем  данные

могут  быть  переданы  либо  модулю TCP, либо UDP, что определяется полем

"протокол" в заголовке IP-пакета.


     Если UDP-датаграмма попадает в модуль UDP, то на основании  значения

поля  "порт"  в  заголовке  датаграммы определяется прикладная программа,

которой должно быть передано прикладное  сообщение.   Если  TCP-сообщение

попадает в модуль TCP, то выбор прикладной программы, которой должно быть

передано сообщение, осуществляется на основе значения поля "порт" в заго-

ловке TCP-сообщения.


     Мультиплексирование  данных  в   обратную   сторону   осуществляется

довольно  просто,  так  как из каждого модуля существует только один путь

вниз.  Каждый протокольный модуль добавляет к пакету свой  заголовок,  на

основании которого машина, принявшая пакет, выполняет демультиплексирова-

ние.




         1  2  3 .... n     |           1  2  3 .... n      ^
          \ |  |     /      |            \ |  |     /       |
        -----------------  поток      -------------------  поток
        | мультиплексор |  данных     | демультиплексор |  данных
        -----------------   |         -------------------   |
               |            |                 ^             |
               v            V                 |             |
               1                              1

            Рис.2. Мультиплексор n x 1 и демультиплексор 1 x n













                                  -- 55 --


     Данные от прикладного процесса проходят через модули  TCP  или  UDP,

после  чего  попадают  в  модуль IP и оттуда - на уровень сетевого интер-

фейса.


     Хотя технология internet поддерживает много различных сред  передачи

данных,  здесь  мы  будем  предполагать  использование  Ethernet, так как

именно эта среда  чаще  всего  служит  физической  основой  для  IP-сети.

Машина  на  рис.1  имеет  одну точку соединения с Ethernet.  Шестибайтный

Ethernet-адрес является уникальным для каждого сетевого адаптера  и  рас-

познается драйвером.


     Машина имеет также четырехбайтный IP-адрес.  Этот  адрес  обозначает

точку  доступа к сети на интерфейсе модуля IP с драйвером.  IP-адрес дол-

жен быть уникальным в пределах всей сети Internet.


     Работающая машина всегда знает свой IP-адрес и Ethernet-адрес.


2.5.  Работа с несколькими сетевыми интерфейсами


     Машина может быть подключена одновременно к нескольким средам  пере-

дачи данных.  На рис.3 показана машина с двумя сетевыми интерфейсами Eth-

ernet.  Заметим, что она имеет 2 Ethernet-адреса и 2 IP-адреса.


     Из представленной схемы видно, что для машин с несколькими  сетевыми

интерфейсами  модуль  IP выполняет функции мультиплексора n x m и демуль-

типлексора m x n (рис.4).



                    ---------------------------------
                    |      прикладные процессы      |
                    |   ... \ | / .... \ | / ...    |
                    |      -------    -------       |
                    |      | TCP |    | UDP |       |
                    |      -------    -------       |
                    |            \    /             |
                    |            ------             |
                    |   -------  | IP |  -------    |
                    |   | ARP |  -*--*-  | ARP |    |
                    |   -------   |  |   -------    |
                    |        \    |  |    /         |
                    |      --------  --------       |
                    |      | ENET |  | ENET |       |
                    |      ---@----  ---@----       |
                    |         |         |           |
                    ----------|---------|------------
                              |         |
                              |      ---o---------------
                --------------o----          Ethernet 2
                Ethernet 1

          Рис.3. Узел сети TCP/IP с двумя сетевыми интерфейсами












                                  -- 66 --



      1  2  3 .... n      |           1  2  3 ...... n      ^
       \ |  |     /       |            \ |  |       /       |
     -----------------  поток        -------------------  поток
     | мультиплексор |  данных       | демультиплексор |  данных
     -----------------    |          -------------------    |
       / |  | ... \       V            / |  | ..... \       |
      1  2  3      m                  1  2  3        m

         Рис.4. Мультиплексор n x m и демультиплексор m x n



Таким образом, он осуществляет  мультиплексирование  входных  и  выходных

данных  в  обоих  направлениях.  Модуль IP в данном случае сложнее, чем в

первом примере, так как может передавать  данные  между  сетями.   Данные

могут  поступать  через  любой  сетевой  интерфейс и быть ретранслированы

через любой другой сетевой интерфейс.  Процесс передачи пакета  в  другую

сеть  называется ретрансляцией IP-пакета.  Машина, выполняющая ретрансля-

цию, называется шлюзом. [1]


     Как показано на рис.5, ретранслируемый пакет не  передается  модулям

TCP или UDP.  Некоторые шлюзы вообще могут не иметь модулей TCP и UDP.


                                3.  Ethernet


     В этом разделе мы кратко рассмотрим технологию Ethernet.


     Кадр Ethernet содержит адрес назначения, адрес источника, поле  типа

и  данные.  Размер  адреса  в  Ethernet - 6 байт.  Каждый сетевой адаптер

имеет свой Ethernet-адрес.  Адаптер контролирует обмен информацией,  про-



                         -------      -------
                         | TCP |      | UDP |
                         -------      -------
                               \      /
                              ----------
                              |        |
                              |   IP   |
                              |  ____  |
                              | /    \ |
                              ----------
                              /        \
                          данные      данные
                         поступают  отправляются
                          отсюда       сюда

         Рис.5. Пример межсетевой ретрансляции пакета модулем IP


____________________

     [1]   В  документации  по  TCP/IP  термины  шлюз  (gateway)  и   IP-
маршрутизатор (IP-router) часто используются как синонимы.  Мы сочли воз-
можным использовать более распространенный термин "шлюз".













                                  -- 77 --


исходящий в сети, и принимает адресованные ему  Ethernet-кадры,  а  также

Ethernet-кадры с адресом "FF:FF:FF:FF:FF:FF" (в 16-ричной системе), кото-

рый обозначает "всем", и используется при широковещательной передаче.


     Ethernet реализует метод МДКН/ОС (множественный доступ  с  контролем

несущей  и  обнаружением  столкновений).  Метод МДКН/ОС предполагает, что

все устройства взаимодействуют в одной среде,  в  каждый  момент  времени

может  передавать  только одно устройство, а принимать могут все одновре-

менно.  Если два устройства пытаются передавать одновременно, то происхо-

дит  столкновение  передач,  и оба устройства после случайного (краткого)

периода ожидания пытаются вновь выполнить передачу.


3.1.  Аналогия с разговором


     Хорошей аналогией взаимодействиям в  среде  Ethernet  может  служить

разговор группы вежливых людей в небольшой темной комнате.  При этом ана-

логией электрическим сигналам в коаксиальном кабеле служат звуковые волны

в комнате.


     Каждый человек слышит речь других  людей  (контроль  несущей).   Все

люди в комнате имеют одинаковые возможности вести разговор (множественный

доступ), но никто не говорит слишком долго, так как  все  вежливы.   Если

человек  будет  невежлив,  то  его попросят выйти (т.е.  удалят из сети).

Все молчат, пока кто-то говорит.  Если  два  человека  начинают  говорить

одновременно,  то они сразу обнаруживают это, поскольку слышат друг друга

(обнаружение столкновений).  В этом случае они замолкают и ждут некоторое

время,  после чего один из них вновь начинает разговор.  Другие люди слы-

шат, что ведется разговор, и ждут, пока он кончится, а затем могут начать

говорить  сами.  Каждый человек имеет собственное имя (аналог уникального

Ethernet-адреса). Каждый раз,  когда  кто-нибудь  начинает  говорить,  он

называет  по имени того, к кому обращается, и свое имя, например, "Слушай

Петя, это Андрей, ... ля-ля-ля ..." Если кто-то хочет обратиться ко всем,

то  он говорит: "Слушайте все, это Андрей, ... ля-ля-ля ..." (широковеща-

тельная передача).


                              4.  Протокол ARP


     В этом разделе мы рассмотрим то, как при посылке IP-пакета определя-

ется  Ethernet-адрес  назначения.  Для отображения IP-адресов в Ethernet-

адреса используется протокол ARP (Address Resolution Protocol -  адресный










                                  -- 88 --


протокол).   Отображение  выполняется только для отправляемых IP-пакетов,

так как только в момент отправки создаются заголовки IP и Ethernet.


4.1.  ARP-таблица для преобразования адресов


     Преобразование адресов выполняется путем поиска в таблице.  Эта таб-

лица,  называемая  ARP-таблицей,  хранится в памяти и содержит строки для

каждого узла сети.  В двух столбцах  содержатся  IP-  и  Ethernet-адреса.

Если  требуется преобразовать IP-адрес в Ethernet-адрес, то ищется запись

с соответствующим  IP-адресом.   Ниже  приведен  пример  упрощенной  ARP-

таблицы.



            ---------------------------------------------
            |      IP-адрес           Ethernet-адрес    |
            ---------------------------------------------
            |     223.1.2.1          08:00:39:00:2F:C3  |
            |     223.1.2.3          08:00:5A:21:A7:22  |
            |     223.1.2.4          08:00:10:99:AC:54  |
            ---------------------------------------------

                    Табл.1. Пример ARP-таблицы




     Принято все байты 4-байтного IP-адреса записывать  десятичными  чис-

лами, разделенными точками.  При записи 6-байтного Ethernet-адреса каждый

байт указывается в 16-ричной системе и отделяется двоеточием.


     ARP-таблица необходима потому, что IP-адреса и Ethernet-адреса выби-

раются  независимо, и нет какого-либо алгоритма для преобразования одного

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

сети  internet.   Если машину перемещают в другую часть сети internet, то

ее IP-адрес должен быть изменен.  Ethernet-адрес  выбирает  производитель

сетевого  интерфейсного  оборудования из выделенного для него по лицензии

адресного пространства.  Когда у машины заменяется плата  сетевого  адап-

тера, то меняется и ее Ethernet-адрес.


4.2.  Порядок преобразования адресов


     В ходе обычной работы сетевая программа, такая как  TELNET,  отправ-

ляет  прикладное сообщение, пользуясь транспортными услугами TCP.  Модуль

TCP посылает соответствующее транспортное сообщение через модуль  IP.   В

результате  составляется  IP-пакет,  который должен быть передан драйверу

Ethernet.   IP-адрес  места  назначения  известен  прикладной  программе,

модулю  TCP  и  модулю IP.  Необходимо на его основе найти Ethernet-адрес










                                  -- 99 --


места назначения.  Для определения искомого Ethernet-адреса  используется

ARP-таблица.


4.3.  Запросы и ответы протокола ARP


     Как же заполняется ARP-таблица?  Она заполняется автоматически моду-

лем ARP, по мере необходимости.  Когда с помощью существующей ARP-таблицы

не удается преобразовать IP-адрес, то происходит следующее:


1)   По сети передается широковещательный ARP-запрос.


2)   Исходящий IP-пакет ставится в очередь.


     Каждый сетевой адаптер принимает  широковещательные  передачи.   Все

драйверы  Ethernet  проверяют поле типа в принятом Ethernet-кадре и пере-

дают ARP-пакеты модулю ARP.  ARP-запрос можно интерпретировать так: "Если

ваш  IP-адрес совпадает с указанным, то сообщите мне ваш Ethernet-адрес".

Пакет ARP-запроса выглядит примерно так:



     -----------------------------------------------------------
     |   IP-адрес отправителя              223.1.2.1           |
     |   Ethernet-адрес отправителя        08:00:39:00:2F:C3   |
     -----------------------------------------------------------
     |   Искомый IP-адрес                  223.1.2.2           |
     |   Искомый Ethernet-адрес            <пусто>             |
     -----------------------------------------------------------

                    Табл.2. Пример ARP-запроса




     Каждый модуль ARP проверяет поле  искомого  IP-адреса  в  полученном

ARP-пакете и, если адрес совпадает с его собственным IP-адресом, то посы-

лает ответ прямо по Ethernet-адресу отправителя запроса.  ARP-ответ можно

интерпретировать  так:  "Да, это мой IP-адрес, ему соответствует такой-то

Ethernet-адрес".  Пакет с ARP-ответом выглядит примерно так:



     -----------------------------------------------------------
     |   IP-адрес отправителя              223.1.2.2           |
     |   Ethernet-адрес отправителя        08:00:28:00:38:A9   |
     -----------------------------------------------------------
     |   Искомый IP-адрес                  223.1.2.1           |
     |   Искомый Ethernet-адрес            08:00:39:00:2F:C3   |
     -----------------------------------------------------------

                    Табл.3. Пример ARP-ответа
















                                 -- 1100 --


     Этот ответ получает  машина,  сделавшая  ARP-запрос.   Драйвер  этой

машины  проверяет  поле типа в Ethernet-кадре и передает ARP-пакет модулю

ARP.  Модуль ARP анализирует ARP-пакет и добавляет  запись  в  свою  ARP-

таблицу.


     Обновленная таблица выглядит следующим образом:



            ---------------------------------------------
            |      IP-адрес           Ethernet-адрес    |
            ---------------------------------------------
            |     223.1.2.1          08:00:39:00:2F:C3  |
            |     223.1.2.2          08:00:28:00:38:A9  |
            |     223.1.2.3          08:00:5A:21:A7:22  |
            |     223.1.2.4          08:00:10:99:AC:54  |
            ---------------------------------------------

             Табл.4. ARP-таблица после обработки ответа




4.4.  Продолжение преобразования адресов


     Новая запись в ARP-таблице  появляется  автоматически,  спустя  нес-

колько  миллисекунд  после  того, как она потребовалась.  Как вы помните,

ранее на шаге 2 исходящий IP-пакет был поставлен  в  очередь.   Теперь  с

использованием  обновленной  ARP-таблицы  выполняется  преобразование IP-

адреса в Ethernet-адрес, после чего  Ethernet-кадр  передается  по  сети.

Полностью порядок преобразования адресов выглядит так:


1)   По сети передается широковещательный ARP-запрос.


2)   Исходящий IP-пакет ставится в очередь.


3)   Возвращается ARP-ответ, содержащий информацию о соответствии  IP-  и

     Ethernet-адресов.  Эта информация заносится в ARP-таблицу.


4)   Для преобразования IP-адреса в Ethernet-адрес у  IP-пакета,  постав-

     ленного в очередь, используется ARP-таблица.


5)   Ethernet-кадр передается по сети Ethernet.


     Короче говоря, если с помощью ARP-таблицы не удается сразу  осущест-

вить  преобразование адресов, то IP-пакет ставится в очередь, а необходи-

мая для преобразования информация получается с помощью запросов и ответов

протокола ARP, после чего IP-пакет передается по назначению.














                                 -- 1111 --


     Если в сети нет машины с искомым IP-адресом, то ARP-ответа не  будет

и не будет записи в ARP-таблице.  Протокол IP будет уничтожать IP-пакеты,

направляемые по этому адресу.  Протоколы верхнего уровня не  могут  отли-

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

мым IP-адресом.


     Некоторые реализации IP и ARP не ставят в очередь  IP-пакеты  на  то

время, пока они ждут ARP-ответов.  Вместо этого IP-пакет просто уничтожа-

ется, а его восстановление возлагается на модуль TCP или прикладной  про-

цесс,  работающий  через UDP.  Такое восстановление выполняется с помощью

таймаутов и повторных передач.   Повторная  передача  сообщения  проходит

успешно, так как первая попытка уже вызвала заполнение ARP-таблицы.


     Следует отметить, что каждая машина имеет отдельную ARP-таблицу  для

каждого своего сетевого интерфейса.


                         5.  Межсетевой протокол IP


     Модуль IP является базовым элементом технологии  internet,  а  цент-

ральной частью IP является его таблица маршрутов.  Протокол IP использует

эту таблицу при принятии всех решений о маршрутизации IP-пакетов.  Содер-

жание  таблицы  маршрутов  определяется администратором сети.  Ошибки при

установке маршрутов могут заблокировать передачи.


     Чтобы понять технику межсетевого взаимодействия,  нужно  понять  то,

как  используется таблица маршрутов.  Это понимание необходимо для успеш-

ного администрирования и сопровождения IP-сетей.


5.1.  Прямая маршрутизация


     На рис.6 показана небольшая IP-сеть, состоящая из 3 машин: A, B и C.

Каждая машина имеет такой же стек протоколов TCP/IP как на рис.1.  Каждый

сетевой адаптер этих машин имеет свой Ethernet-адрес.  Менеджер сети дол-

жен присвоить машинам уникальные IP-адреса.



                                 A      B      C
                                 |      |      |
                   --------------o------o------o------
                    Ethernet 1
                    IP-сеть "development"

                         Рис.6. Простая IP-сеть













                                 -- 1122 --


     Когда A посылает IP-пакет B, то заголовок IP-пакета содержит в  поле

отправителя  IP-адрес  узла A, а заголовок Ethernet-кадра содержит в поле

отправителя Ethernet-адрес A.  Кроме этого, IP-заголовок содержит в  поле

получателя  IP-адрес узла B, а Ethernet-заголовок содержит в поле получа-

теля Ethernet-адрес B.



        -----------------------------------------------------
        |         адрес             отправитель  получатель |
        -----------------------------------------------------
        |   IP-заголовок                A            B      |
        |   Ethernet-заголовок          A            B      |
        -----------------------------------------------------

    Табл.5. Адреса в Ethernet-кадре, передающем IP-пакет от A к B




     В этом простом примере протокол  IP  является  излишеством,  которое

мало  что  добавляет  к  услугам, предоставляемым сетью Ethernet.  Однако

протокол IP требует дополнительных расходов на создание, передачу и обра-

ботку  IP-заголовка.   Когда  в  машине  B модуль IP получает IP-пакет от

машины A, он сопоставляет IP-адрес места  назначения  со  своим  и,  если

адреса совпадают, то передает датаграмму протоколу верхнего уровня.


     В данном случае при взаимодействии A с B используется прямая маршру-

тизация.


5.2.  Косвенная маршрутизация


     На рис.7 представлена более реалистичная картина сети  internet.   В

данном случае сеть internet состоит из трех сетей Ethernet, на базе кото-

рых работают три IP-сети, объединенные шлюзом D.  Каждая IP-сеть включает

четыре  машины;  каждая  машина  имеет  свои  собственные IP- и Ethernet-

адреса.


                             ----- D -------
           A     B     C     |     |       |     E     F     G
           |     |     |     |     |       |     |     |     |
       ----o-----o-----o-----o--   |     --o-----o-----o-----o---
        Ethernet 1                 |          Ethernet 2
        IP-сеть "development"      |          IP-сеть "accounting"
                                   |
                                   |    H     I     J
                                   |    |     |     |
                                 --o----o-----o-----o----------
                                             Ethernet 3
                                             IP-сеть "fuctory"

           Рис.7. Сеть internet, состоящая из трех IP-сетей













                                 -- 1133 --


     За исключением D все машины имеют стек протоколов, аналогичный пока-

занному  на рис.1.  Шлюз D соединяет все три сети и, следовательно, имеет

три IP-адреса и три Ethernet-адреса.   Машина  D  имеет  стек  протоколов

TCP/IP,  похожий на тот, что показан на рис.3, но вместо двух модулей ARP

и двух драйверов, он содержит три модуля ARP  и  три  драйвера  Ethernet.

Обратим внимание на то, что машина D имеет только один модуль IP.


     Менеджер сети присваивает каждой  сети  Ethernet  уникальный  номер,

называемый  IP-номером  сети.  На рис.7 IP-номера не показаны, вместо них

используются имена сетей.


     Когда машина A посылает IP-пакет машине B, то процесс передачи  идет

в  пределах одной сети.  При всех взаимодействиях между машинами, подклю-

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

в предыдущем примере.


     Когда машина D взаимодействует с машиной A, то  это  прямое  взаимо-

действие.  Когда машина D взаимодействует с машиной E, то это прямое вза-

имодействие.  Когда машина D взаимодействует с машиной H, то  это  прямое

взаимодействие.   Это  так,  поскольку каждая пара этих машин принадлежит

одной IP-сети.


     Однако, когда машина A взаимодействует  с  машинами,  включенными  в

другую  IP-сеть, то взаимодействие уже не будет прямым.  Машина A должена

использовать шлюз D для ретрансляции IP-пакетов в другую IP-сеть.   Такое

взаимодействие называется "косвенным".


     Маршрутизация IP-пакетов выполняется модулями IP и является прозрач-

ной для модулей TCP, UDP и прикладных процессов.


     Если машина A посылает машине E IP-пакет, то  IP-адрес  и  Ethernet-

адрес  отправителя  соответствуют  адресам  A.  IP-адрес места назначения

является адресом E, но поскольку модуль IP в A посылает IP-пакет через D,

Ethernet-адрес места назначения является адресом D.






















                                 -- 1144 --



         ----------------------------------------------------
         |          адрес         отправитель   получатель  |
         ----------------------------------------------------
         |   IP-заголовок             A             E       |
         |   Ethernet-заголовок       A             D       |
         ----------------------------------------------------

    Табл.6. Адреса в Ethernet-кадре, содержащем IP-пакет от A к E
            (до шлюза D)




     Модуль IP в машине D получает IP-пакет и  проверяет  IP-адрес  места

назначения.   Определив,  что  это  не его IP-адрес, шлюз D посылает этот

IP-пакет прямо к E.



         ----------------------------------------------------
         |          адрес        отправитель    получатель  |
         ----------------------------------------------------
         |   IP-заголовок             A             E       |
         |   Ethernet-заголовок       D             E       |
         ----------------------------------------------------

    Табл.7. Адреса в Ethernet-кадре, содержащем IP-пакет от A к E
            (после шлюз D)




     Итак, при прямой маршрутизации  IP-  и  Ethernet-адреса  отправителя

соответствуют  адресам  того  узла,  который  послал  IP-пакет,  а  IP- и

Ethernet-адреса места назначения соответствуют адресам  получателя.   При

косвенной маршрутизации IP- и Ethernet-адреса не образуют таких пар.


     В данном примере сеть internet  является  очень  простой.   Реальные

сети могут быть гораздо сложнее, так как могут содержать несколько шлюзов

и несколько типов физических сред передачи.  В приведенном  примере  нес-

колько  сетей  Ethernet  объединяются шлюзом для того, чтобы локализовать

широковещательный трафик в каждой сети.


5.3.  Правила маршрутизации в модуле IP


     Выше мы показали, что происходит при передаче  сообщений,  а  теперь

рассмотрим правила или алгоритм маршрутизации.


     Для отправляемых IP-пакетов, поступающих от модулей верхнего уровня,

модуль  IP  должен  определить способ доставки - прямой или косвенный - и

выбрать сетевой интерфейс.  Этот выбор делается на основании  результатов

поиска в таблице маршрутов.













                                 -- 1155 --


     Для принимаемых IP-пакетов, поступающих от сетевых драйверов, модуль

IP  должен  решить,  нужно ли ретранслировать IP-пакет по другой сети или

передать его на верхний уровень.  Если модуль IP решит, что IP-пакет дол-

жен быть ретранслирован, то дальнейшая работа с ним осуществляется также,

как с отправляемыми IP-пакетами.


     Входящий IP-пакет никогда не ретранслируется через  тот  же  сетевой

интерфейс, через который он был принят.


     Решение о маршрутизации принимается до того, как IP-пакет передается

сетевому драйверу, и до того, как происходит обращение к ARP-таблице.


5.4.  IP-адрес


     Менеджер сети присваивает IP-адреса машинам в соответствии с тем,  к

каким IP-сетям они подключены.  Старшие биты 4-х байтного IP-адреса опре-

деляют номер IP-сети.  Оставшаяся часть IP-адреса  -  номер  узла  (хост-

номер).   Для машины из табл.1 с IP-адресом 223.1.2.1 сетевой номер равен

223.1.2, а хост-номер - 1.  Напомним, что  IP-адрес  узла  идентифицирует

точку доступа модуля IP к сетевому интерфейсу, а не всю машину.


     Существуют 5 классов  IP-адресов,  отличающиеся  количеством  бит  в

сетевом  номере  и  хост-номере.  Класс адреса определяется значением его

первого октета.


     В табл.8 приведено соответствие классов  адресов  значениям  первого

октета и указано количество возможных IP-адресов каждого класса.





                0              8         16          24        31
               ---------------------------------------------------
      Класс A  |0| номер сети |            номер узла            |
               ---------------------------------------------------
               ---------------------------------------------------
      Класс B  |10|      номер сети      |       номер узла      |
               ---------------------------------------------------
               ---------------------------------------------------
      Класс C  |110|          номер сети            | номер узла |
               ---------------------------------------------------
               ---------------------------------------------------
      Класс D  |1110|            групповой адрес                 |
               ---------------------------------------------------
               ---------------------------------------------------
      Класс E  |11110|           зарезервировано                 |
               ---------------------------------------------------

                      Рис.8. Структура IP-адресов













                                 -- 1166 --



       -------------------------------------------------------
       | Класс Диапазон значений  Возможное      Возможное   |
       |        первого октета   кол-во сетей   кол-во узлов |
       -------------------------------------------------------
       |   A       1 - 126           126          16777214   |
       |   B       128-191          16382           65534    |
       |   C       192-223         2097150           254     |
       |   D       224-239            -             2**28    |
       |   E       240-247            -             2**27    |
       -------------------------------------------------------

             Табл.8. Характеристики классов адресов




     Адреса класса A предназначены  для  использования  в  больших  сетях

общего  пользования.   Они  допускают  большое  количество номеров узлов.

Адреса класса B используются в сетях среднего  размера,  например,  сетях

университетов и крупных компаний.  Адреса класса C используются в сетях с

небольшим числом компьютеров.  Адреса класса D используются  при  обраще-

ниях к группам машин, а адреса класса E зарезервированы на будущее.


     Некоторые IP-адреса являются выделенными и трактуются по-особому.



    ------------------------------
    |         все нули           |  Данный узел
    ------------------------------
    ------------------------------
    |  номер сети |   все нули   |  Данная IP-сеть
    ------------------------------
    ------------------------------
    |   все нули  |  номер узла  |  Узел в данной (локальной) IP-сети
    ------------------------------
    ------------------------------
    |        все единицы         |  Все узлы в данной (локальной) IP-сети
    ------------------------------
    ------------------------------
    |  номер сети |  все единицы |  Все узлы в указанной IP-сети
    ------------------------------
    ------------------------------
    | 127 | что-нибудь (часто 1) |  "Петля"
    ------------------------------

                    Рис.9. Выделенные IP-адреса




     Как показано на рис.9, в выделенных IP-адресах все  нули  соответст-

вуют  либо  данному  узлу, либо данной IP-сети, а IP-адреса, состоящие из

всех единиц, используются при широковещательных передачах.  Для ссылок на

всю IP-сеть в целом используется IP-адрес с нулевым номером узла.  Особый

смысл имеет IP-адрес, первый октет которого равен 127.   Он  используется

для  тестирования  программ  и  взаимодействия процессов в пределах одной

машины.  Когда программа посылает данные по IP-адресу 127.0.0.1, то обра-

зуется  как  бы  "петля".   Данные  не передаются по сети, а возвращаются










                                 -- 1177 --


модулям верхнего уровня, как только что принятые.  Поэтому в IP-сети зап-

рещается присваивать машинам IP-адреса, начинающиеся со 127.


5.5.  Выбор адреса


     Прежде чем вы начнете использовать сеть с TCP/IP, вы должны получить

один  или несколько официальных сетевых номеров.  Выделением номеров (как

и многими другими вопросами) занимается DDN  Network  Information  Center

(NIC) [2].  Выделение номеров производится  бесплатно  и  занимает  около

недели.   Вы  можете  получить сетевой номер вне зависимости от того, для

чего предназначена ваша сеть.  Даже если ваша сеть не имеет связи с объе-

диненной сетью 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












                                 -- 1188 --


класса 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-адреса, когда это произойдет, можно  заранее

выделить для этой сети три подсетевых номера - по одному на здание.  (Это

полезно и в том случае, когда не  планируется  физическое  деление  сети.

Просто  такая  адресация позволяет сразу определить, где находится та или

иная машина.) Однако прежде, чем выделять три различных подсетевых номера











                                 -- 1199 --


одной  физической  сети, тщательно проверьте, что все ваши программы спо-

собны работать в такой среде.


     Вы также должны выбрать "маску подсети".  Она  используется  сетевым

программным  обеспечением  для  выделения  номера  подсети из 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 доступен по  любому  из










                                 -- 2200 --


этих  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-пакета.











                                 -- 2211 --


     Таблица маршрутов содержит по одной  строке  для  каждого  маршрута.

Основными  столбцами  таблицы  маршрутов являются номер сети, флаг прямой

или косвенной маршрутизации, 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. Пример таблицы маршрутов




В данном простом примере все узлы сети имеют одинаковые  таблицы  маршру-

тов.


     Для сравнения ниже представлена та же таблица,  но  вместо  названия

сети указан ее номер.
















                                 -- 2222 --



     ----------------------------------------------------------
     |  сеть          флаг вида         шлюз        номер     |
     |              маршрутизации                 интерфейса  |
     ----------------------------------------------------------
     | 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














                                 -- 2233 --




                             -------------
                             |   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-адрес места










                                 -- 2244 --


назначения 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-пакете  сообщение  передается  протокольному  модулю  верхнего

уровня.

















                                 -- 2255 --


                           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-адресом сети, второй адрес










                                 -- 2266 --


указывает шлюз, который должен использоваться для доступа  к  данной  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-сети приходится менять информацию во всех машинах.  Например,

при отключении какого-нибудь канала связи для  восстановления  нормальной










                                 -- 2277 --


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











                                 -- 2288 --


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 и уметь вычислять опти-

мальные маршруты доступа к каждой подсети.  Обычно они  поддерживают  эту

картину,  обмениваясь  информацией между собой.  Для этой цели существуют











                                 -- 2299 --


несколько специальных протоколов  маршрутизации.   Один  из  способов,  с

помощью  которого узлы могут определять действующие шлюзы, состоит в сле-

жении за обменом сообщениями  между  ними.   Для  большинства  протоколов

маршрутизации  существует  программное  обеспечение,  позволяющее обычным

узлам осуществлять такое слежение.  При этом на узлах поддерживается пол-

ная картина положения дел в сети internet точно также, как это делается в

шлюзах.  Динамическая корректировка таблицы маршрутов позволяет  посылать

IP-пакеты по оптимальным маршрутам.


     Таким  образом,  слежение  за  маршрутизацией  в  некотором   смысле

"решает"  проблему  поддержания  корректности  таблиц  маршрутов.  Однако

существуют несколько причин, по которым этот метод применять не  рекомен-

дуется.   Наиболее серьезной проблемой является то, что протоколы маршру-

тизации пока еще подвергаются частым пересмотрам и  изменениям.   Появля-

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

программном обеспечении всех машин.


     Несколько более специальная проблема связана с бездисковыми рабочими

станциями.   По своей природе бездисковые машины сильно зависят от сети и

от файл-серверов, с которых они осуществляют  загрузку  программ,  и  где

располагается  их  область  своппинга.   Исполнение программ, следящих за

широковещательными передачами в сети, на бездисковых  машинах  связано  с

большими  трудностями.   Протоколы  маршрутизации построены в основном на

широковещательных передачах.  Например, все сетевые шлюзы могут широкове-

щательно  передавать  содержание  своих  таблиц маршрутов через каждые 30

секунд.  Программы, которые следят за такими передачами, должны быть заг-

ружены  на  бездисковые станции через сеть.  На достаточно занятой машине

программы, которые не используются в течение  нескольких  секунд,  обычно

отправляются в область своппинга.  Поэтому программы, следящие за маршру-

тизацией, большую часть времени находятся в своппинге.  Когда  они  вновь

активизируются,  должна  производиться подкачка из своппинга.  Как только

посылается широковещательное сообщение,  все  машины  активизируют  прог-

раммы,  следящие за маршрутизацией.  Это приводит к тому, что многие без-

дисковые станции будут выполнять подкачку из  своппинга  в  одно  и  тоже

время.   Поэтому  в  сети возникнет временная перегрузка.  Таким образом,

исполнение программ, прослушивающих широковещательные передачи,  на  без-

дисковых рабочих станциях очень нежелательно.












                                 -- 3300 --


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).













                                 -- 3311 --



                  сеть 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-сети есть узел, который не умеет работать с подсетями;













                                 -- 3322 --


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 - простой протокол управления сетью).













                                 -- 3333 --


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.  Однако рекомендуется всегда выпол-

нять контрольное суммирование, так как возможно в какой-то момент измене-

ния  в таблице маршрутов приведут к тому, что датаграммы будут посылаться

через менее надежную среду.













                                 -- 3344 --


     Если контрольная сумма правильная (или равна нулю),  то  проверяется

порт  назначения,  указанный  в заголовке датаграммы.  Если к этому порту

подключен прикладной процесс, то  прикладное  сообщение,  содержащееся  в

датаграмме,  становится  в  очередь  для  прочтения.  В остальных случаях

датаграмма отбрасывается.  Если  датаграммы  поступают  быстрее,  чем  их

успевает  обрабатывать  прикладной  процесс,  то при переполнении очереди

сообщений поступающие датаграммы отбрасываются модулем 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-порт, они проходят по сети, и другой  приклад-











                                 -- 3355 --


ной процесс читает их из своего TCP-порта.


     Протокол TCP разбивает поток байт на пакеты; он не сохраняет  границ

между  записями.  Например, если один прикладной процесс делает 5 записей

в TCP-порт, то прикладной процесс на  другом  конце  виртуального  канала

может  выполнить  10 чтений для того, чтобы получить все данные.  Но этот

же процесс может получить все данные сразу, сделав только  одну  операцию

чтения.   Не  существует зависимости между числом и размером записываемых

сообщений с одной стороны и числом и  размером  считываемых  сообщений  с

другой стороны.


     Протокол TCP требует, чтобы все отправленные данные  были  подтверж-

дены  принявшей их стороной.  Он использует таймауты и повторные передачи

для обеспечения надежной доставки.   Отправителю  разрешается  передавать

некоторое  количество данных, недожидаясь подтверждения приема ранее отп-

равленных данных.  Таким образом, между отправленными  и  подтвержденными

данными существует окно уже отправленных, но еще неподтвержденных данных.

Количество байт, которые можно передавать без  подтверждения,  называется

размером окна.  Как правило, размер окна устанавливается в стартовых фай-

лах сетевого программного обеспечения.  Так как TCP-канал  является  дуп-

лексным,  то  подтверждения для данных, идущих в одном направлении, могут

передаваться вместе с данными,  идущими  в  противоположном  направлении.

Приемники  на  обеих  сторонах  виртуального  канала выполняют управление

потоком передаваемых данных для того,  чтобы  не  допускать  переполнения

буферов.


                      9.  Протоколы прикладного уровня


     Почему существуют два транспортных протокола TCP и UDP, а не один из

них?   Дело в том, что они предоставляют разные услуги прикладным процес-

сам.  Большинство прикладных программ пользуются  только  одним  из  них.

Вы,  как  программист,  выбираете тот протокол, который наилучшим образом

соответствует вашим потребностям.  Если вам нужна надежная  доставка,  то

лучшим может быть TCP.  Если вам нужна доставка датаграмм, то лучше может

быть UDP.  Если вам нужна эффективная доставка по длинному и  ненадежному

каналу  передачи данных, то лучше может подойти протокол TCP.  Если нужна

эффективность на быстрых сетях с короткими соединениями, то лучшим  может

быть  протокол  UDP.  Если ваши потребности не попадают ни в одну из этих

категорий, то выбор транспортного протокола не ясен.   Однако  прикладные










                                 -- 3366 --


программы  могут  устранять  недостатки  выбранного протокола.  Например,

если вы выбрали UDP, а вам необходима надежность, то прикладная программа

должна  обеспечить  надежность.  Если вы выбрали TCP, а вам нужно переда-

вать записи, то прикладная программа должна  вставлять  маркеры  в  поток

байтов так, чтобы можно было различить записи.


     Какие же прикладные программы доступны в сетях с TCP/IP?


     Общее их количество велико  и  продолжает  постоянно  увеличиваться.

Некоторые  приложения существуют с самого начала развития internet.  Нап-

ример, TELNET и FTP.  Другие появились недавно: X-Window, SNMP.


     Протоколы прикладного уровня ориентированы на конкретные  прикладные

задачи.  Они определяют как процедуры по организации взаимодействия опре-

деленного типа между прикладными процессами, так  и  форму  представления

информации  при  таком  взаимодействии.  В этом разделе мы коротко опишем

некоторые из прикладных протоколов.


9.1.  Протокол TELNET


     Протокол TELNET позволяет  обслуживающей  машине  рассматривать  все

удаленные  терминалы  как  стандартные  "сетевые  виртуальные  терминалы"

строчного типа, работающие в коде ASCII, а также обеспечивает возможность

согласования  более  сложных  функций  (например, локальный или удаленный

эхо-контроль, страничный режим, высота и ширина  экрана  и  т.д.)  TELNET

работает  на  базе  протокола TCP.  На прикладном уровне над TELNET нахо-

дится либо программа поддержки реального терминала (на стороне  пользова-

теля),  либо  прикладной  процесс  в обсуживающей машине, к которому осу-

ществляется доступ с терминала.


     Работа с TELNET походит на набор телефонного  номера.   Пользователь

набирает на клавиатуре что-то вроде

                              telnet delta


и получает на экране приглашение на вход в машину delta.


     Протокол TELNET существует уже давно.  Он хорошо опробован и  широко

распространен.   Создано множество реализаций для самых разных операцион-

ных систем.  Вполне допустимо, чтобы процесс-клиент работал, скажем,  под

управлением ОС VAX/VMS, а процесс-сервер под ОС UNIX System V.












                                 -- 3377 --


9.2.  Протокол FTP


     Протокол FTP (File Transfer Protocol  -  протокол  передачи  файлов)

распространен  также  широко  как TELNET.  Он является одним из старейших

протоколов семейства TCP/IP.  Также как TELNET он  пользуется  транспорт-

ными  услугами TCP.  Существует множество реализаций для различных опера-

ционных систем, которые хорошо взаимодействуют между собой.  Пользователь

FTP  может  вызывать  несколько  команд, которые позволяют ему посмотреть

каталог удаленной машины, перейти из одного каталога в  другой,  а  также

скопировать один или несколько файлов.


9.3.  Протокол SMTP


     Протокол SMTP (Simple Mail  Transfer  Protocol  -  простой  протокол

передачи почты) поддерживает передачу сообщений (электронной почты) между

произвольными узлами сети internet.  Имея механизмы промежуточного хране-

ния почты и механизмы повышения надежности доставки, протокол SMTP допус-

кает использование различных транспотных служб.  Он может работать даже в

сетях, не использующих протоколы семейства TCP/IP.  Протокол SMTP обеспе-

чивает как группирование сообщений в адрес одного получателя, так и разм-

ножение  нескольких  копий  сообщения  для передачи в разные адреса.  Над

модулем SMTP располагается почтовая служба конкретных вычислительных сис-

тем.


9.4.  r-команды


     Существует целая серия "r-команд" (от remote -  удаленный),  которые

впервые появились в ОС UNIX.  Они являются аналогами обычных команд UNIX,

но предназначены для работы с удаленными машинами.  Например, команда rcp

является аналогом команды cp и предназначена для копирования файлов между

машинами.  Для передачи файла на узел delta достаточно ввести


                            rcp file.c delta:


Для выполнения команды "cc file.c" на  машине  delta  можно  использовать

комаду rsh:


                           rsh delta cc file.c


Для организации входа в удаленную систему предназначена команда rlogin:


                              rlogin delta










                                 -- 3388 --


     Команды r-серии используются главным образом в системах,  работающих

под  управлением  ОС  UNIX.   Существуют  также  реализации  для  MS-DOS.

Команды избавляют пользователя от необходимости набирать пароли при входе

в удаленную систему и существенно облегчают работу.


9.5.  NFS


     Сетевая файловая система NFS (Network File System) впервые была раз-

работана  компанией  Sun  Microsystems  Inc.  NFS использует транспортные

услуги UDP и позволяет монтировать в единое целое файловые  системы  нес-

кольких  машин  с ОС UNIX.  Бездисковые рабочие станции получают доступ к

дискам файл-сервера так, как-будто это их локальные диски.


     NFS значительно увеличивает нагрузку на сеть.  Если в сети использу-

ются  медленные линии связи, то от NFS мало толку.  Однако, если пропуск-

ная способность сети позволяет NFS нормально  работать,  то  пользователи

получают большие преимущества.  Поскольку сервер и клиент NFS реализуются

в ядре ОС, все обычные несетевые программы получают возможность  работать

с  удаленными  файлами,  расположенными  на  подмонтированных NFS-дисках,

точно также как с локальными файлами.


9.6.  Протокол SNMP


     Протокол SNMP (Simple Network Management Protocol - простой протокол

управления  сетью)  работает на базе UDP и предназначен для использования

сетевыми управляющими станциями.  Он позволяет управляющим станциям соби-

рать  информацию  о  положении  дел в сети internet.  Протокол определяет

формат данных, их обработка и интерпретация остаются на усмотрение управ-

ляющих станций или менеджера сети.


9.7.  X-Window


     Система X-Window использует протокол X-Window, который  работает  на

базе  TCP,  для  многооконного  отображения графики и текста на растровых

дисплеях рабочих станций.  X-Window - это гораздо больше, чем просто ути-

лита  для  рисования окон; это целая философия человеко-машинного взаимо-

действия.

















                                 -- 3399 --


              10.  Взаимозависимость протоколов семейства TCP/IP


     Ниже на рисунке предсавлена  схема  взаимосвязей  между  протоколами

семейства TCP/IP.


    Прикладной    FTP  TELNET  SMTP  TFTP  DNS  Сужба времени  Эхо
    уровень        |      |     |      |    |         |         |
                   --------------      --------------------------
                          |                             |
    Транспортный         TCP      GGP  HMP  EGP        UDP
    уровень               |        |    |    |          |
                          -------------------------------
                                        |
    Межсетевой                       IP/ICMP
    уровень                             |
                      --------------------------------------
                      |            |          |            |
    Сетевой       Локальные     ARPANET     SATNET      Пакетная
    уровень         сети                                радиосеть

      Рис.13. Структура взаимосвязей протоколов семейства TCP/IP



     Подробное описание протоколов можно найти в RFC, тематический  ката-

лог  которых  приведен  в Приложении 1, а состояние стандартов отражено в

Приложении 2.



















































                                 -- 4400 --


Приложение 1.  Путеводитель по RFC


     Более подробную информацию по протоколам семейства TCP/IP и способам

организации сетей internet можно найти в RFC - документах, распространяе-

мых DDN Network Information Center.  Полный каталог  RFC,  а  также  сами

документы  можно  получить  по  электронной  почте, обратившись по адресу

service@nic.ddn.mil.  Поле "Subject:" в вашем  запросе  должно  содержать

название  желаемого документа.  Например, для получения RFC 822 вы должны

указать


                            Subject: RFC 822


     Для получения дополнительной информации пошлите письмо, указав


                              Subject: HELP


     Каталог RFC  содержит  полный  список  документов,  упорядоченный  в

обратном хронологическом порядке.  Его можно получить, послав запрос


                           Subject: RFC INDEX


















































                                 -- 4411 --


ТЕМАТИЧЕСКИЙ КАТАЛОГ RFC



   1.  Административные вопросы

       Administrative


      1а.  RFC о выделенных номерах

           Assigned Numbers RFCs


         1117, 1062, 1020, 1010, 997, 990, 960, 943, 923, 900, 870,

         820, 790, 776, 770, 762, 758, 755, 750, 739, 717, 604, 503,

         433, 349, 322, 317, 204, 179, 175, 167.


      1b.  Официальные стандарты IAB и другие списки протоколов

           Official IAB Standards and Other Lists of Protocols


         1130, 1100, 1083, 1011, 991, 961, 944, 924, 901, 880, 840,

         694, 661, 617, 582, 580, 552.

         774 - Internet Protocol Handbook Table of Contents


      1c.  Отчеты о заседаниях рабочих групп

           Meeting Notes and Minutes


         1152 - Workshop report: Internet research steering

                group workshop on very-high-speed networks

         1077 - Critical issues in high bandwidth networking

         1019 - Report of the Workshop on Environments for

                Computational Mathematics

         1017 - Network requirements for scientific research:

                Internet task force on scientific computing

         898 - Gateway Special Interest Group Meeting Notes

         808, 805, 469 - Computer Mail Meeting Notes

         910, 807 - Multimedia Mail Meeting Notes

         585 - ARPANET Users Interest Working Group Meeting

         549, 396, 282, 253 - Graphics Meeting Notes

         371 - International Computer Communications Conference

         327 - Data and File Transfer Workshop Notes

         316 - Data Management Working Group Meeting Report

         164, 131, 116, 108, 101, 082, 077, 066, 063, 037, 021 - Network

               Working Group Meeting












                                 -- 4422 --


      1d.  Oбъявления

           Meeting Announcements and Group Overviews


         1120 - Internet Activities Board

         828 - Data Communications:  IFIP's International "Network" of

               Experts

         631 - Call for Papers:  International Meeting on Minicomputers

               and Data Communication

         584 - Charter for ARPANET Users Interest Working Group

         537 - Announcement of NGG Meeting

         526 - Technical Meeting - Digital Image Processing Software

               Systems

         504 - Workshop Announcement

         483 - Cancellation of the Resource Notebook Framework Meeting

         474, 314, 246, 232, 134 - Network Graphics Working Group

         471 - Announcement of a (Tentative) Workshop on Multi-Site

               Executive Programs

         461 - Telnet Meeting Announcement

         457 - TIPUG

         456 - Memorandum

         454 - File Transfer Protocol Meeting Announcement

         453 - Meeting Announcement to Discuss a Network Mail System

         374 - IMP System Announcement

         359 - The Status of the Release of the New IMP System (2600)

         343, 331 - IMP System Change Notification

         324 - RJE Protocol Meeting

         323 - Formation of Network Measurement Group (NMG)

         320 - Workshop on Hard Copy Line Graphics

         309 - Data and File Transfer Workshop Announcement

         299 - Information Management System

         295 - Report of the Protocol Workshop

         291, 188, 173 - Data Management Meetings

         245, 234, 207, 188, 173, 140, 116, 099, 087, 085, 075, 043, 035

               - Network Working Group Meetings

         222 - System Programmer's Workshop

         212 - NWG Meeting on Network Usage

         157 - Invitation to the Second Symposium on Problems in the











                                 -- 4433 --


               Optimization of Data Communication Systems

         149 - The Best Laid Plans...

         147 - The Definition of a Socket

         111 - Pressure from the Chairman

         048 - A Possible Protocol Plateau

         046 - ARPA Network Protocol Notes


      1e.  Списки распространения информации

           Distribution List


         402, 363, 329, 303, 300, 211, 168, 155 - ARPA Network Mailing

               Lists

         069 - Distribution List Change for MIT

         052 - Updated Distribution List


      1f.  Официальные вопросы

           Policies


         1124 - Policy issues in interconnecting networks

         1087 - Ethics and the Internet

         1052 - IAB recommendations for the development of

                Internet network management standards

         1039 - DoD statement on Open System Interconnection protocols

         980 - Protocol Document Order Form

         952, 810, 608 - Host Table Specification

         945 - A DoD Statement on the NRC Report

         902 - ARPA-Internet Protocol Policy

         849 - Suggestions for Improved Host Table Distribution

         678 - Document Formats

         602 - The Stockings Were Hung by the Chimney With Care

         115 - Some Network Information Center Policies on Handling

               Documents

         053 - An Official Protocol Mechanism


      1g.  Документы о RFC

           Request for Comments Administrative


         1150 - F.Y.I. on F.Y.I.: Introduction to the F.Y.I. notes

         1111 - Request for comments on Request for Comments:

                Introductions to RFC authors










                                 -- 4444 --


         1000 - Request For Comments reference guide

         999, 899, 800, 699 - Requests for Comments Summary

         825 - Request for Comments on Requests for Comments

         629 - Scenario for Using the Network Journal

         628 - Status of RFC Numbers and a Note on Pre-assigned Journal

               Numbers

         598, 200, 170, 160, 100, 084 - RFC Index


      1h.  Библиография

           Bibliographies


         1012 - Bibliography of Request For Comments 1 through 999

         829 - Packet Satellite Technology Reference Sources

         290 - Computer Network and Data Sharing: A Bibliography

         243 - Network and Data Sharing Bibliography


      1i.  Разное

           Other


         637 - Change of Network Address for SU-DSL

         634 - Change in Network Address for Haskins Lab

         616 - Latest Network Maps

         609 - Statement of Upcoming Move of NIC/NLS Service

         590 - MULTICS Address Change

         588 - London Node is Now Up

         551 - NYU, ANL, and LBL Joining the Net

         544 - Locating On-Line Documentation at SRI-ARC

         543 - Network Journal Submission and Delivery

         518 - ARPANET Accounts

         511 - Enterprise Phone Service to NIC From ARPANET Sites

         510 - Request for Network Mailbox Addresses

         432 - Network Logical Map

         423, 389 - UCLA Campus Computing Network Liaison Staff for APRA

               Network

         421 - A Software Consulting Service for Network Users

         419 - MIT-DMS on Vacation

         416 - The ARC System will be Unavailable for Use During

               Thanksgiving Week

         405 - Correction to RFC 404










                                 -- 4455 --


         404 - Host Address Changes Involving Rand and ISI

         403 - Desirability of a Network 1108 Service

         386 - Letter to TIP Users - 2

         384 - Official Site IDENTS for Organizations in the ARPA

               Networks

         381 - Three Aids to Improved Network Operation

         356 - ARPA Network Control Center

         334 - Network Use on May 8

         305 - Unknown Host Numbers

         301 - BBN IMP No. 5 and NCC Schedule for March 4, 1972

         276 - NIC Course

         249 - Coordination of Equipment and Supplies Purchase

         223 - Network Information Center Schedule for Network Users

         185 - NIC Distribution of Manuals and Handbooks

         154 - Exposition Style

         136 - Host Accounting and Administrative Procedures

         118 - Information Required for Each Service Available to the

               Network

         095 - Distribution of NWG/RFC's Through the NIC

         016 - MIT


   2.  Основные требования

       Requirements Documents And Major Protocol Revisions


      2a.  Требования к узлам

           Host requirements


         1127 - Perspective on the Host Requirements RFCs

         1123 - Requirements for Internet hosts - application

                and support

         1122 - Requirements for Internet hosts - communication layers


      2b.  Требования к шлюзам

           Gateway requirements


         1009 - Requirements for Internet gateways


      2c.  Другие требования

           Other












                                 -- 4466 --


   3.  Уровень интерфейса с сетью

       Network Interface Level


      3а.  Отображение адресов (ARP, RARP)

           Address Binding


         1027 - Using ARP to implement transparent subnet gateways


      3b.  Межсетевой протокол IP в различных сетях

           Internet Protocol over another network


         1149 - Standard for the transmission of IP datagrams

                on avian carriers

         1103 - Proposed standard for the transmission of IP datagrams

                over FDDI Networks

         1088 - Standard for the transmission of IP datagrams over

                NetBIOS networks

         1055 - Nonstandard for transmission of IP datagrams over

                serial lines: SLIP

         1051 - Standard for the transmission of IP datagrams and

                ARP packets over ARCNET networks

         1044 - Internet Protocol on Network System's HYPERchannel:

                Protocol specification

         1042 - Standard for the transmission of IP datagrams over

                IEEE 802 networks

         948 - Two Methods for the Transmission of IP Datagrams Over

               IEEE 802.3 Networks

         907 - Host Access Protocol

         903 - A Reverse Address Resolution Protocol

         895 - A Standard for the Transmission of IP Datagrams over

               Experimental Ethernet Networks

         894 - A Standard for the Transmission of IP Datagrams over

               Ethernet Networks

         893 - Trailer Encapsulations

         891 - Internet Protocol on DC Networks

         877 - A Standard for the Transmission of IP Datagrams Over

               Public Data Networks

         826 - Address Resolution Protocol

         796 - Address Mappings










                                 -- 4477 --


         795 - Service Mappings


      3c.  Разное

           Other


   4.  Межсетевой уровень

       Internet Level


      4a.  Межсетевой протокол IP

           Internet Protocol


         1154 - Encoding header field for internet messages

         1141 - Incremental updating of the Internet checksum

         1071 - Computing the Internet checksum

         1063 - IP MTU discovery options

         1025 - TCP and IP bake off

         815 - IP Datagram Reassembly Algorithms

         791, 760 - Internet Protocol (IP)

         781 - A Specification of the Internet Protocol IP Timestamp

               Option


      4b.  Межсетевой протокол управляющих сообщений ICMP

           Internet Control Message Protocol


         1018 - Some comments on SQuID

         1016 - Something a host could do with source quench:

                The Source Quench Introduced Delay (SQuID)

         792, 777 - Internet Control Message Protocol (ICMP)


      4c.  Межсетевой протокол групповых передач IGMP

           Internet Group Multicast Protocol


         1112 - Host extentions for IP multicasting

         1054 - Host extentions for IP multicasting


      4d.  Маршрутизация и шлюзовые протоколы GGP, RIP, OSPF

           Routing and Gateway Protocols


         1136 - Administrative Domains and Routing Domains:

                A model for routing in the Internet

         1133 - Routing between the NSFNET and the DDN

         1131 - OSPF specification










                                 -- 4488 --


         1126 - Goals and functional requirements for inter-

                autonomous system routing

         1125 - Policy requirements for inter Administrative

                Domain routing

         1105 - Border Gateway Protocol (BGP)

         1104 - Models of policy based routing

         1102 - Policy routing in Internet protocols

         1093 - NSFNET routing architecture

         1092 - EGP and policy based routing in the new NSFNET

                backbone

         1075 - Distance Vector Multicast Routing Protocol

         1074 - NSFNET backbone SPF based Interior Gateway Protocol

         1058 - Routing Information Protocol

         1046 - Queuing algorithm to provide type-of-service for IP

                links

         985 - Requirements for Internet Gateways

         975 - Autonomous Confederations

         970 - On Packet Switches With Infinite Storage

         911 - EGP Gateway under Berkeley Unix

         904, 890, 888, 827 -  Exterior Gateway Protocol

         875 - Gateways, Architectures, and Heffalumps

         823 - Gateway Gateway Protocol


      4e.  Разное

           Other


         986 - Working Draft - Guidelines for the Use of Internet-IP

               Addressing in the ISO Connectionless-Mode Network

         981 - An Experimental Multiple-Path Routing Algorithm

         963 - Some Problems with the Specification of the Military

               Standard Internet Protocol

         950 - Internet Standard Subnetting Procedure

         947 - Multi-Network Broadcasting Within the Internet

         940, 917, 925, 932, 936, 922 - Internet Subnets Protocol

         925, 917, 826 - Multi-LAN Address Resolution Protocol

         919, 922 - Broadcasting Internet Datagrams

         891 - DCN Local-Network Protocols

         871 - A Perspective on the ARPANET Reference Model










                                 -- 4499 --


         831 - Backup Access to the European Side of SATNET

         817 - Modularity and Efficiency in Protocol Implementation

         816 - Fault Isolation and Recovery

         814 - Name, Addresses, Ports, and Routes

         796 - Address Mapping

         795 - Service Mappings

         730 - Extensible Field Addressing


   5.  Транспортный уровень

       Transport Level


      5a.  Протокол пользовательских датаграмм UDP

           User Datagram Protocol


         768 - User Datagram Protocol


      5b.  Протокол управления передачей TCP

           Transmission Control Protocol


         1146, 1145 - TCP alternate checksum options

         1144 - Compressing TCP/IP headers for low-speed serial

                links

         1110 - Problem with the TCP big window option

         1106 - TCP big window and NAK options

         1078 - TCP port service Multiplexer (TCPMUX)

         1072 - TCP extensions for long-delay paths

         983 - ISO Transport Services on Top of the TCP

         964 - Some Problems with the Specification of the Military

               Standard Transmission Control Protocol

         896 - Congestion Control in IP/TCP Internetworks

         889 - Internet Delay Experiments

         879 - The TCP Maximum Segment Size and Related Topics

         872 - TCP-ON-A-LAN

         817 - Modularity and Efficiency in Protocol Implementation

         816 - Fault Isolation and Recovery

         814 - Name, Addresses, Ports, and Routes

         794 - Pre-Emption

         793, 761, 675 - Transmission Control Protocol

         721 - Out of Band Control Signals in a Host to Host Protocol











                                 -- 5500 --


         700 - A Protocol Experiment


      5c.  Протоколы для двухточечных каналов

           Point-To-Point Protocols


         1134 - Point-to-Point Protocol: A proposal for multi-

                protocol transmission of datagrams over Point-

                to-Point links

         1055 - Nonstandard for transmission of IP datagrams

                over serial lines: SLIP


      5d.  Протоколы надежной доставки датаграмм RDP, VMTP

           Reliable Datagram Protocols


         1151 - Version 2 of the Reliable Data Protocol (RDP)

         1045 - VMTP: Versatile Message Transaction Protocol:

                Protocol specification


      5e.  Транзакции и распределенные операционные системы

           Transaction Protocols and Distributed Operating Systems


         955 - Towards a Transport Service for Transaction Processing

               Applications

         938 - Internet Reliable Transaction Protocol Functional and

               Interface Specification

         908 - Reliable Data Protocol

         722 - Thoughts on Interactions in Distributed Services

         713 - MSDTP -- Message Services Data Transmission Protocol

         712 - A Distributed Capability Computing System DCCS

         708 - Elements of a Distributed Programming System

         707 - A High-Level Framework for Network-Based Resource Sharing

         684 - A Commentary on Procedure Calling as A Network Protocol

         677 - The Maintenance of Duplicate Databases

         674 - Procedure Call Documents--Version 2

         672 - A Multi-Site Data Collection Facility

         671 - A Note on Reconnection Protocol

         645 - Network Standard Data Specification Syntax

         615 - Proposed Network Standard Data Pathname Syntax

         610 - Further Datalanguage Design Concepts

         592 - Some Thoughts on System Design to Facilitate Resource










                                 -- 5511 --


               Sharing

         578 - Using MIT-MATHLAB MACSYMA From MIT-DMS Muddle - An

               Experiment in Automated Resource Sharing

         515 - Specifications for Datalanguage, Version 0/9

         500 - The Integration of Data Management Systems on a Computer

               Network

         441 - Inter-Entity Communication - An Experiment

         437 - Data Reconfiguration Service at UCSB

         203 - Achieving Reliable Communication

         076 - Connection-by-Name: User-Oriented Protocol

         062 - A System for Interprocess Communication in a Resource

               Sharing Computer Network

         061 - A Note on Interprocess Communication in a Resource

               Sharing Computer Network

         051 - Proposal for a Network Interchange Language

         031 - Binary Message Forms in Computer Networks

         005 - DEL

         001 - Host Software


      5f.  Протоколы для персональных компьютеров (NETBIOS)

           Protocols For Personal Computers


      5g.  Разное

           Other


         998, 969 - NETBLT: A Bulk Data Transfer Protocol

         988 - Host Extensions for IP Multicasting

         979 - PSN End-to-End Functional Specification

         966 - A Multicast Extension to the Internet Protocol

         869 - Host Monitoring Protocol

         741 - Specifications for the Network Voice Protocol NVP

         643 - Cross Net Debugger

         162 - NETBUGGER3


   6.  Прикладной уровень

       Application Level


      6a.  Протокол сетевого терминала TELNET

           Telnet Protocol











                                 -- 5522 --


         854, 764 - Telnet Protocol Specification

         818 - The Remote User Telnet Service

         801 - NCP/TCP Transition Plan

         782 - A Virtual Terminal Management Model

         764 - Telnet Protocol Specification

         728 - A Minor Pitfall in the Telnet Protocol

         688 - Tentative Schedule for the New Telnet Implementation for

               the TIP

         681 - Network Unix

         600 - Interfacing an Illinois Plasma Terminal to the ARPANET

         596 - Second Thoughts on Telnet Go-Ahead

         595 - Some Thoughts in Defense of the Telnet Go-Ahead

         593 - Telnet and FTP Implementation Schedule Change

         576 - Proposal for Modifying Linking

         570 - Experimental Input Mapping Between NVT ASCII and UCSB

               Online System

         562 - Modifications to the Telnet Specification

         559 - Comments on the New Telnet Protocol and Its

               Implementation

         529 - A Note on Protocol Synch Sequences

         513 - Comments on the New Telnet Specifications

         495 - Telnet Protocol Specification

         466 - Telnet Logger/Server for Host LL-67

         461 - Telnet Meeting Announcement

         452 - Telnet Command at Host LL

         435 - Telnet Issues

         426 - Reconnection Protocol

         393 - Comments on Telnet Protocol Changes

         377 - Using TSO Via ARPA Network Virtual Terminal

         357 - An Echoing Strategy for Satellite Links

         355, 346 - Satellite Considerations

         340 - Proposed Telnet Changes

         339 - MLTNET - A "Multi-Telnet" Subsystem for TENEX

         328 - Suggested Telnet Protocol Changes

         318 - Ad Hoc Telnet Protocol

         216 - Telnet Access to UCSB's On-Line System

         215 - NCP, ICP, and Telnet: The Terminal IMP Implementation










                                 -- 5533 --


         206 - A User Telnet Description of an Initial Implementation

         205 - NETCRT - A Character Display Protocol

         190 - DEC PDP-10 - IMLAC Communication System

         158 - Proposed Telnet Protocol

         139 - Discussion of Telnet Protocol

         137 - Telnet Protocol - A Proposed Document

         135, 110 - Conventions for Using an IBM 2741 Terminal as a User

               Console for Access to Network Server Hosts

         103 - Implementation of Interrupt Keys

         097 - A First Cut at a Proposed Telnet Protocol

         091 - A Proposed User-User Protocol

         015 - Network Subsystem for Time Sharing Hosts


      6b.  Опции Telnet

           Telnet Options


         1143 - Q method of implementing Telnet option negotiation

         1116 - Telnet Linemode option

         1097 - Telnet subliminal-message option

         1096 - Telnet X display location option

         1091 - Telnet terminal-type option

         1080 - Telnet remote flow control option

         1079 - Telnet terminal speed option

         1073 - Telnet window size option

         1053 - Telnet X.3 PAD option

         1043 - Telnet Data Entry Terminal option: DODIIS implementation

         1041 - Telnet 3270 regime option

         946 - Telnet Terminal Location Number Option

         933 - Output Marking Telnet Option

         930 - Telnet Terminal Type Option

         927 - TACACS User Identification Telnet Option

         885 - Telnet End of Record Option

         884 - Telnet Terminal Type Option

         861 - Telnet Extended Options - List Option

         860 - Telnet Timing Mark Option

         859 - Telnet Status Option

         858 - Telnet Suppress Go Ahead Option

         857 - Telnet Echo Option










                                 -- 5544 --


         856 - Telnet Binary Transmission

         855 - Telnet Option Specifications

         854 - Telnet Protocol Specifications

         779 - Telnet Send-Location Option

         749 - Telnet SUPDUP-OUTPUT Option

         748 - Telnet Randomly-Lose Option

         736 - Telnet SUPDUP Option

         735 - Revised Telnet Byte Macro Option

         734 - SUPDUP Protocol

         747 - Recent Extensions to the SUPDUP Protocol

         746 - The SUPDUP Graphics Extension

         732 - Telnet Data Entry Terminal Option

         731 - Telnet Data Entry Terminal Option

         729 - Telnet Byte Macro Option

         727 - Telnet Logout Option

         726 - Remote Controlled Transmission and Echoing Telnet Option

         719 - Discussion on RCTE

         718 - Comments on RCTE from the Tenex Implementation Experience

         703, 702, 701 - Survey of New-Protocol Telnet Servers

         698 - Telnet Extended ASCII Option

         679 - February, 1975, Survey of  New-Protocol Telnet Servers

         669 - November 1974, Survey of New-Protocol Telnet Servers

         659 - Announcing Additional Telnet Options

         658 - Telnet Output Line Feed Disposition

         657 - Telnet Output Vertical Tab Disposition Option

         656 - Telnet Output Vertical Tab Stops Option

         655 - Telnet Output Form Feed Disposition Option

         654 - Telnet Output Horizontal Tab Disposition Option

         653 - Telnet Output Horizontal Tab Stops Option

         652 - Telnet Output Carriage Return Disposition Option

         651 - Revised Telnet Status Option

         587 - Announcing New Telnet Options

         581 - Corrections to RFC 560 - Remote Controlled Transmission

               and Echoing Telnet Option

         563 - Comments on the RCTE Telnet Option

         560 - Remote Controlled Transmission and Echoing Telnet Option












                                 -- 5555 --


      6c.  Протоколы передачи и доступа к файлам (FTP, TFTP, SFTP, NFS)

           File Transfer and Access Protocols


         1094 - NFS: Network File System Protocol specification

         1068 - Background File Transfer Program (BFTP)

         1037 - NFILE - a file access protocol

         959, 542, 354, 265, 172, 114 - The File Transfer Protocol

         949 - FTP Unique-Named Store Command

         913 - Simple File Transfer Protocol

         906 - Bootstrap Loading Using TFTP

         822 - Standard for the Format of ARPA Internet Text Messages

         821, 788 - Simple Mail Transfer Protocol

         783, 768, 764 - The TFTP Protocol Revision 2

         775 - Directory Oriented FTP Commands

         743 - FTP Extension: XRSQ/XRCP

         737 - FTP Extension: XSEN

         697 - CWD Command of FTP

         691 - One More Try on the FTP

         686 - Leaving Well Enough Alone

         683 - FTPSRV -- Tenex Extension for Paged Files

         678 - Document File Format Standards

         662 - Performance Improvement in ARPANET File Transfers from

               Multics

         640 - Revised FTP Reply Codes

         630 - FTP Error Code Usage for More Reliable Mail Service

         624 - Comments on the File Transfer Protocol

         614 - Response to RFC 607 - Comments on the FTP

         607 - NIC-21255 Comments on the File Transfer Protocol

         573 - Data and File Transfer - Some Measurement Results

         571 - Tenex FTP Problem

         535 - Comments on File Access Protocol

         532 - The UCSD-CC Server-FTP Facility

         520 - Memo to FTP Group (Proposal for File Access Protocol)

         506 - An FTP Command Naming Problem

         505 - Two Solutions to a File Transfer Access Problem

         501 - Un-Muddling "Free File Transfer"

         487 - Host-Dependent FTP Parameters











                                 -- 5566 --


         486 - Data Transfer Revisited

         480 - Host-Dependent FTP Parameters

         479 - Use of FTP by the NIC Journal

         478 - FTP Server-Server Interaction - II

         475 - FTP and the Network Mail System

         468 - FTP Data Compression

         463 - FTP Comments and Response to RFC 430

         458 - Mail Retrieval via FTP

         454 - File Transfer Protocol - Meeting Announcement and a New

               Proposed Document

         448 - Print Files in FTP

         438 - FTP Server-Server Interaction

         430 - Comments on File Transfer Protocol

         418 - Server File Transfer Under TSS/360 at NASA/Ames Research

               Center

         414 - File Transfer Protocols (FTP): Status and Further

               Comments

         412 - User FTP Documentation

         385 - Comments on the File Transfer Protocol (RFC 354)

         310  - Another Look at Data and File Transfer Protocols

         294 - The Use of "Set Data Type" Transaction in the File

               Transfer Protocol

         281 - A Suggested Addition to File Transfer Protocol

         269 - Some Experience with File Transfer

         264, 171 - The Data Transfer Protocol

         250 - Some Thoughts on File Transfer

         242 - Data Descriptive Language for Shared Data

         238 - Comments on DTP and FTP Protocols

         163 - Data Transfer Protocols

         141 - Comments on RFC 114 (A File Transfer Protocol)

         133 - File Transfer and Error Recovery


      6d.  Справочная служба имен

           Domain Name System


         1101 - DNS encoding of network names and other types

         1035 - Domain names - implementation and specification

         1034 - Domain names - concepts and facilities










                                 -- 5577 --


         1033 - Domain administrators operations guide

         1032 - Domain administrators guide

         1031 - MILNET name domain transition

         974 - Mail Routing and the Domain System

         973 - Domain System Changes and Observations

         953, 811, 810 - HOSTNAME Protocol

         921, 897 - Domain Name System Implementation Schedule

         920 - Domain Requirements

         883 - Domain Names - Implementation and Specification

         882 - Domain Names - Concepts and Facilities

         881 - The Domain Names Plan and Schedule

         830 - A Distributed System for Internet Name Service

         819 - The Domain Naming Convention for Internet User

               Applications

         799 - Internet Name Domains

         756 - The NIC Name Server -- A Datagram-Based Information

               Utility

         752 - A Universal Host Table


      6e.  Почтовая служба и система передачи сообщений (SMTP)

           Mail and Message Systems


         1153 - Digest message format

         1148, 1138 - Mapping between X.400(1988)/ISO 10021 and RFC 822

         1137 - Mapping between full RFC 822 and RFC 822 with

                restricted encoding

         1090 - SMTP on X.25

         1082 - Post Office Protocol - version 3: Extended service

                offerings

         1081 - Post Office Protocol - version 3

         1064 - Interactive Mail Access Protocol: Version 2

         1056 - PCMAIL: A distributed mail system for personal

                computers

         1049 - Content-type header field for Internet messages

         1047 - Duplicate messages and SMTP

         1026 - Addendum to RFC 987: (Mapping between X.400 and

                RFC-822)

         994, 983 - PCMAIL: A Distributed Mail System










                                 -- 5588 --


         977 - Network News Transfer Protocol

         976 - UUCP Mail Interchange Format Standard

         974 - Mail Routing and the Domain System

         934 - Proposed Standard for Message Encapsulation

         915 - Network Mail Path Service

         886 - Proposed Standard for Message Header Munging

         850 - Standard for Interchange of USENET Messages

         841 - Specification for Message Format for Computer Based

               Message Systems

         822 - Standard for the Format of ARPA Internet Text Messages

         821 - Simple Mail Transfer Protocol

         806 - Specification for Message Format for Computer Based

               Message Systems

         780, 772 - Mail Transfer Protocol

         786 - Mail Transfer Protocol - ISI TOPS-20 MTP-NIMAIL Interface

         785 - Mail Transfer Protocol - ISI TOPS-20 File Definitions

         784 - Mail Transfer Protocol - ISI TOPS-20 Implementation

         771 - Mail Transition Plan

         763 - Role Mailboxes

         757 - A Suggested Solution to the Naming, Addressing, and

               Delivery Problem for ARPANET Message Systems

         754 - Out-of-Net Host Addresses for Mail

         753 - Internet Message Protocol

         751 - Survey of FTP Mail and MLFL

         733 - Standard for the Format of ARPA Network Text Messages

         724 - Proposed Official Standard for the Format of ARPA Network

               Messages

         720 - Address Specification Syntax for Network Mail

         706 - On the Junk Mail Problem

         680 - Message Transmission Protocol

         644 - On the Problem of Signature Authentication for Network

               Mail

         577 - Mail Priority

         574 - Announcement of a Mail Facility at UCSB

         561 - Standardizing Network Mail Headers

         555 - Responses to Critiques of the Proposed Mail Protocol

         539, 524 - A Proposed Mail Protocol










                                 -- 5599 --


         498 - On Mail Service to CCN

         491 - What is "Free"?

         475 - On FTP and the Network Mail System

         458 - Mail Retrieval via FTP

         333 - A Proposed Experiment with a Message Switching Protocol

         278, 224, 221, 196 - A Mail Box Protocol


      6f.  Факсимиле

           Facsimile


         809 - UCL Facsimile System

         804 - Facsimile Formats

         803 - Dacom 450/500 Facsimile Date Transcoding

         798 - Decoding Facsimile Data From the Rapicom 450

         797 - Bitmap Formats

         769 - Rapicom 450 Facimile File Format


      6g.  Графические и многооконные системы

           Graphics and Window Systems


         1013 - X Window System Protocol, version 11:

                Alpha update April 1987

         965 - A Format for a Graphical Communication Protocol

         553 - Draft Design for a Text/Graphics Protocol

         493 - Graphics Protocol

         401 - Conversion of NGP-0 Coordinates to Device Specific

               Coordinates

         398 - UCSB Online Graphics

         387 - Some Experiences in Implementing Network Graphics

               Protocol Level 0

         351 - Information Form for the ARPANET Graphics Resources

               Notebook

         336 - Level 0 Graphics Input Protocol

         296 - DS-1 Display System

         292 - Graphics Protocol - Level 0 only

         285 - Network Graphics

         268 - Graphics Facilities Information

         199 - Suggestions for a Network Data-Telnet Graphics Protocol

         192 - Some Factors Which a Network Graphics Protocol Must










                                 -- 6600 --


               Consider

         191 - Graphics Implementation and Conceptualization at ARC

         186 - A Network Graphics Loader

         184 - Proposed Graphic Display Modes

         181, 177 - A Device Independent Graphical Display Description

         178 - Network Graphics Attention Handling

         125, 086 - Proposal for a Network Standard Format for a Data

               Stream to Control Graphics Display

         094 - Some Thoughts on Network Graphics


      6h.  Управление данными

           Data Management


         304 - A Data Management System Proposal for the ARPA Network

         195 - Data Computers - Data Descriptions and Access Language

         194 - The Data Reconfiguration Service - Compiler/Interpreter

               Implementation Notes

         166 - Data Reconfiguration Service - An Implementation

               Specification

         144 - Data Sharing on Computer Networks

         138 - Status Report on Proposed Data Reconfiguration Service

         083 - Language-Machine for Data Reconfiguration


      6i.  Удаленный ввод заданий (NETRJE, NETRJS)

           Remote Job Entry


         740, 599, 589, 325, 189, 088 - CCN Network Remote Job Entry

               Program - NETRJS

         725 - An RJE Protocol for a Resource Sharing Network

         499 - Harvard's Network RJE

         490 - Surrogate RJS for UCLA-CCN

         477, 436 - Remote Job Service at UCSB

         407 - Remote Job Entry

         368 - Comments on "Proposed Remote Job Entry Protocol"

         360 - Proposed Remote Job Entry Protocol

         338 - EBCDIC/ASCII Mapping for Network RJE

         307 - Using Network Remote Job Entry

         283 - NETRJT - Remote Job Service Protocol for TIPS

         105 - Network Specification for Remote Job Entry and Remote Job










                                 -- 6611 --


               Output Retrieval at UCSB


      6j.  Удаленный вызов процедур (RPC)

           Remote Procedure Call


         1057 - RPC: Remote Procedure Call Protocol specification

                version 2

         1050 - RPC: Remote Procedure Call Protocol specification


      6k.  Дата и время (NTP)

           Time And Date


         1129 - Internet time synchronization:

                The Network Time Protocol

         1128 - Measured performance of the Network Time Protocol

                in the Internet system

         1119 - Network Time Protocol (version 2) specification and

                implementation

         1059 - Network Time Protocol (version 1) specification and

                implementation

         958, 957, 956 - Network Time Protocol

         868 - Time Server Protocol

         867 - Daytime Protocol

         778 - DCNET Time Server Protocol

         738 - Time Server

         685 - Response Time in Cross-network Debugging

         034 - Some Brief Preliminary Notes on the ARC Clock

         032 - Some Thoughts on SRI's Proposed Real Time Clock

         028 - Time Standards


      6l.  Представление данных (XDR)

           Presentation and Representation


         1014 - XDR: External Data Representation standard

         1003 - Issues in defining an equations representation standard


      6m.  Управление в сетях (SNMP, CMOT, MIB)

           Network Management


         1109 - Report of the second Ad Hoc Network Management

                Review Group










                                 -- 6622 --


         1095 - Common Management Information Services and

                Protocol over TCP/IP (CMOT)

         1089 - SNMP over Ethernet

         1076 - HEMS monitoring and control language

         1067 - Simple Network Management Protocol

         1156, 1066 - Management Information Base for network

                management of TCP/IP-based internets

         1155, 1065 - Structure and identification of management

                information for TCP/IP-based internets

         1028 - Simple Gateway Monitoring Protocol

         1024 - HEMS variable definitions

         1023 - HEMS monitoring and control language

         1022 - High-level Entity Management Protocol (HEMP)

         1021 - High-level Entity Management System (HEMS)


      6n.  Служба каталогов

           Directory Services


         1107 - Plan for Internet directory services

         1157, 1098 - Simple Network Management Protocol (SNMP)


      6o.  Протоколы начальной загрузки (BOOTP)

           Bootstrap Protocols


         1084 - BOOTP vendor information extensions

         1048 - BOOTP vendor information extensions


      6p.  Разное

           Other


         978 - Voice File Interchange Protocol (VFIP)

         972 - Password Generator Protocol

         954, 812 - Whois Protocol

         951 - Bootstrap Protocol

         937, 918 - Post Office Protocol

         931, 912 - Authentication Service

         913 - Simple File Transfer Protocol

         909 - Loader Debugger Protocol

         891 - DCN Local Net Protocol

         887 - Resource Location Protocol










                                 -- 6633 --


         866 - Active Users Protocol

         865 - Quote of the Day Protocol

         864 - Character Generator Protocol

         863, 361, 348 - Discard Protocol

         862, 361, 347 - Echo Protocol

         821, 822 - Simple Mail Transfer Protocol

         783 - Trivial File Transfer Protocol

         767 - Document Formats

         759 - Internet Message Protocol

         742 - Finger Protocol

         734 - SUPDUP Protocol

         726 - Remote Controlled Transmission and Echoing Telnet Option

         666 - Specification of the Unified User-Level Protocol

         621 - NIC User Directories at SRI-ARC

         569 - Network Standard Text Editor

         470 - Change in Socket for TIP News Facility

         451 - Tentative Proposal for a Unified User Level Protocol

         098, 079 - Logger Protocol

         029 - Note in Response to Bill English's Request for Comments


   7.  Документация к программам

       Program Documentation


         496 - A TNLS Quick Reference Card is Available

         494 - Availability of MIX and MIXAL in the Network

         488 - NLS Classes at Network Sites

         485 - MIS and MIXAL at UCSB

         431 - Update on SMFS Login and Logout

         411 - New Multics Network Software Features

         409 - TENEX Interface to UCSB's Simple-Minded File System

         399 - SMFS Login and Logout

         390 - TSO Scenario Batch Compilation and Foreground Execution

         382 - Mathematical Software on the ARPA Network

         379 - Using TSO at CCN

         373 - Arbitrary Character Sets

         350 - User Accounts for UCSB On-Line System

         345 - Interest Mixed Integer Programming (MPSX on 360/91 at

               CCN)










                                 -- 6644 --


         321 - CBI Networking Activity at MITRE

         317 - Official Host-Host Protocol Modification: Assigned Link

               Numbers

         311 - New Console Attachments to the UCSB Host

         251 - Weather Data

         223 - Network Information Center Schedule for Network Users

         217 - Specification Changes for OLS, RJE/RJOR, and SMFS

         174 - UCLA-Computer Science Graphics Overview

         122 - Network Specifications for UCSB's Simple-Minded File

               System

         121 - Network On-Line Operators

         120 - Network PL1 Subprograms

         119 - Network FORTRAN Subprograms

         074 - Specifications for Network Use of the UCSB On-Line System


   8.  Особенности некоторых сетей

       Network Specific


      8a.  Сеть ARPANET


         1005, 878, 851, 802 - The ARPANET 1822L Host Access Protocol

         852 - The ARPANET Short Blocking Feature

         789 - Vulnerabilities of Network Control Protocols: An Example

         716 - Interim Revision to Appendix F of BBN 1822

         704 - IMP/Host and Host/IMP Protocol Change

         696 - Comments on the IMP/HOST and HOST/IMP Protocol Changes

         695 - Official Change in Host-Host Protocol

         692 - Comments on IMP/Host Protocol Changes

         690 - Comments on the Proposed Host/IMP Protocol Changes

         687 - IMP/Host and Host/IMP Protocol

         667 - BBN Host Ports

         660 - Some Changes to the IMP and the IMP/Host Interface

         642 - Ready Line Philosophy and Implementation

         638, 633 - IMP/TIP Preventive Maintenance Schedule

         632 - Throughput Degradation for Single Packet Message

         627 - ASCII Text File of Hostnames

         626 - On a possible Lockup Condition in IMP Subnet due to

               Message Sequencing











                                 -- 6655 --


         625 - On Line Hostnames Service

         623 - Comments on On-line Host Name Service

         622 - Scheduling IMP/TIP Down Time

         620 - Request for Monitor Host Table Updates

         619 - Mean Round-Trip Times in the ARPANET

         613 - Network Connectivity: A Response to RFC 603

         611 - Two Changes to the IMP/Host Protocol

         606 - Host Names On-Line

         594 - Speedup of Host-IMP Interface

         591 - Addition to the Very Distant Host Specification

         568, 567 - Cross-Country Network Bandwidth

         548 - Hosts Using the IMP Going Down Message Specification

         547 - Change to the Very Distant Host Specification

         533 - Message-ID Numbers

         534 - Lost Message Detection

         528 - Software Checksumming in the IMP and Network Reliability

         521 - Restricted Use of IMP DDT

         508 - Real-Time Data Transmission on the ARPANET

         476, 434 - IMP/TIP Memory Retrofit Schedules

         449, 442 - The Current Flow-Control Scheme for IMPSYS

         447, 445 - IMP/TIP Preventive Maintenance Schedule

         417 - LINK Usage Violation

         410 - Removal of the 30-second Delay When Hosts Come Up

         406 - Scheduled IMP Software Releases

         395 - Switch Settings on IMPs and TIPs

         394 - Two Proposed Changes to the IMP-HOST Protocol

         369 - Evaluation of ARPANET Services (January through March,

               1972)

         335 - New Interface-IMP/360

         312 - Proposed Change in IMP-to-Host Protocol

         297 - TIP Message Buffers

         280 - A Draft Set of Host Names

         274 - Establishing a Local Guide for Network Usage

         271 - IMP System Change Notification

         270 - Correction to the BBN Report No. 1822

         263 - "Very Distant" Host Interface

         254 - Scenarios for Using ARPANET Computers










                                 -- 6666 --


         247 - Proffered Set of Standard Host Names

         241 - Connecting Computers to NLC Ports

         239 - Host Mnemonics Proposed in RFC 226

         237 - The NIC's View of Standard Host Names

         236 - Standard Host Names

         233 - Standardization of Host Call Letters

         230 - Toward Reliable Operation of Minicomputer-based Terminals

               on a TIP

         229 - Standard Host Names

         228 - Clarification

         226 - Standardization of Host Mnemonics

         218 - Changing the IMP Status Reporting

         213 - IMP System Change Notification

         209 - Host/IMP Interface Documentation

         208 - Address Tables

         073, 067 - Proposed Change to Host/IMP Spec to Eliminate

               Marking

         071 - Reallocation in Case of Input Error

         070 - A Note On Padding

         064 - Getting Rid of Marking

         041 - IMP/IMP Teletype Communication

         025 - No High Link Numbers

         019 - Two Protocol Suggestions to Reduce Congestion at

               Swap-Bound Nodes

         017a, 017 - Some Questions Re: HOST-IMP Protocol

         012 - IMP-HOST Interface Flow Diagrams

         007 - HOST-IMP Interface

         006 - Conversation with Bob Kahn


      8b.  Протоколы сетевого доступа

           Host Front End Protocols


         929, 928, 705, 647 - Host-Front End Protocol


      8c.  Протокол NCP сети ARPANET (предшественник TCP/IP)

           ARPANET NCP (Obsolete predecessor of TCP/IP)


         801 - NCP/TCP Transition Plan

         773 - Comments on NCP/TCP Mail Service Transition Strategy










                                 -- 6677 --


         714 - A Host/Host Protocol for an ARPANET-type Network

         689 - Tenex NCP Finite State Machine for Connections

         663 - A Lost Message Detection and Recovery Protocol

         636 - TIP/TENEX Reliability Improvements

         635 - An Assessment of ARPANET Protocols

         534, 516, 512 - Lost Message Detection

         492, 467 - Proposed Change to Host-Host Protocol

               Resynchronization of Connection Status

         489 - Comment on Resynchronization of Connection Status

               Proposal

         425 - "But my NCP Costs $500 a day..."

         210 - Improvement of Flow Control

         197 - Initial Connection Protocol - Revised

         176 - Comments on Byte Size for Connections

         165 - A Proferred Official Initial Connection Protocol

         147 - The Definition of a Socket

         142 - Time-out Mechanism in the Host-Host Protocol

         132, 124, 107, 102 - Output of the Host-Host Protocol Glitch

               Cleaning Committee

         129 - A Request for Comments on Socket Name Structure

         128 - Bytes

         117 - Some Comments on the Official Protocol

         072 - Proposed Moratorium on Changes to Network Protocol

         068 - Comments on Memory Allocation Control Commands (CEASE,

               ALL, GVB, RET) and RFNM

         065 - Comments on Host-Host Protocol Document Number 1

         060 - A Simplified NCP Protocol

         059 - Flow Control-Fixed Versus Demand Allocation

         058 - Logical Message Synchronization

         057, 054 - An Official Protocol Proffering

         056 - Third Level Protocol

         055 - A Prototypical Implementation of the NCP

         050, 049, 048, 047, 046, 045, 044, 040, 039, 038, 036, 033 -

               New Host-Host Protocol

         042 - Message Data Types

         023 - Transmission of Multiple Control Messages

         022 - Host-Host Control Message Formats










                                 -- 6688 --


         018 - Comments Re: Host-Host control link

         015 - Network Subsystem for Time Sharing Hosts

         011 - Implementation of the Host-Host Software Procedures in

               GORDO

         009, 001 - Host Software

         008 - ARPA Network Functional Specifications

         005 - DEL

         002 - Links


      8d.  Протокол ICP сети ARPANET

           ARPANET Initial Connection Protocol


         202 - Possible Deadlock in ICP

         197 - Initial Connection Protocol - Revised

         161 - A Solution to the Race Condition in the ICP

         151, 148, 143, 127, 123 - A Proferred Official ICP

         150 - The Use of IPC Facilities

         145 - Initial Connection Protocol Control Commands

         093 - Initial Connection Protocol

         080 - Protocol and Data Formats

         066 - 3rd Level Ideas and Other Noise


      8e.  Сеть USENET


         1036 - Standard for interchange of USENET messages


      8f.  Разное

           Other


         1132 - Standard for the transmission of 802.2 packets

                over IPX networks

         935 - Reliable Link Layer Protocols

         916 - Reliable Asynchronous Transfer Protocol

         914 - Thinwire Protocol

         824 - The Cronus Virtual Local Network


   9.  Измерение

       Measurement


      9a.  Общие вопросы

           General










                                 -- 6699 --


         573 - Data and File Transfer - Some Measurement Results

         557 - Revelations in Network Host Measurements

         546 - Tenex Load Averages for July 1973

         462 - Responding to User Needs

         415 - TENEX Bandwidth

         392 - Measurement of Host Costs for Transmitting Network Data

         352 - TIP Site Information Form

         308 - ARPANET Host Availability Data

         286 - Network Library Information System

         274 - Establishing a Local Guide for Network Usage

         214, 193 - Network Checkout

         198 - Site Certification - Lincoln Labs

         182 - Compilation of List of Revelant Site Reports

         180 - File System Questionnaire

         156 - Status of the Illinois Site (Response to RFC 116)

         153 - SRI ARC-NIC Status

         152 - SRI Artificial Intelligence Status Report

         126 - Ames Graphics Facilities at Ames Research Center

         112 - User/Server Site Protocol Network HOST Questionnaire

         104 - Link 191

         106 - USER/SERVER Site Protocol Network Host Questionnaire


      9b.  Обзоры

           Surveys


         971 - A Survey of Data Representation Standards

         876 - Survey of SMTP Implementations

         848 - Who Provides the "Little" TCP Services?

         847 - Summary of Smallberg Surveys

         844 - Who Talks ICMP, too?  Survey of 18 February 1983

         846, 845, 843, 842, 839, 838, 837, 836, 835, 834, 833, 832 -

               Who Talks TCP?

         787 - Connectionless Data Transmission Survey/Tutorial

         703, 702, 701, 679, 669 - Survey of New-Protocol Telnet Servers

         565 - Storing Network Survey Data at the Datacomputer

         545 - Of What Quality be the UCSB Resource Evaluators?

         530 - A Report on the SURVEY Project

         523 - SURVEY is in Operation Again










                                 -- 7700 --


         519 - Resource Evaluation

         514 - Network Make-Work

         464 - Resource Notebook Framework

         460 - NCP Survey

         459 - Network Questionnaire

         450 - Multics Sampling Timeout Change

         446 - Proposal to Consider a Network Program Resource Notebook

         096 - An Interactive Network Experiment to Study Modes of

               Access to the Network Information Center

         090 - CCN as a Network Service Center

         081 - Request for Reference Information

         078 - NCP Status Report: UCSB/Rand


      9c.  Статистика

           Statistics


         1128 - Measured performance of the Network Time Protocol

                in the Internet system

         1030 - On testing the NETBLT Protocol over divers networks

         996 - Statistics Server

         618 - A Few Observations on NCP Statistics

         612, 601, 586, 579, 566, 556, 538, 522, 509, 497, 482, 455,

               443, 422, 413, 400, 391, 378 - Traffic Statistics

         603, 597, 376, 370, 367, 366, 362, 352, 344, 342, 332, 330,

               326, 319, 315, 306, 298, 293, 288, 287, 267, 266 -

               Network Host Status

         550 - NIC NCP Experiment

         388 - NCP Statistics

         255, 252, 240, 235 - Site Status


   10.  Безопасность и конфиденциальность

        Privacy And Security


      10a.  Общие вопросы

            General


         1135 - Helminthiasis of the Internet

         1115 - Privacy enhancement for Internet electronic mail:

                Part III - algorithms, modes, and identifiers [Draft]











                                 -- 7711 --


         1114 - Privacy enhancement for Internet electronic mail:

                Part II - certificate-based key management [Draft]

         1113 - Privacy enhancement for Internet electronic mail:

                Part I - message encipherment and authentication

                procedures [Draft]

         1040 - Privacy enhancement for Internet electronic mail:

                Part I: Message encipherment and authentication

                procedures

         1038 - Draft revised IP security option

         1004 - Distributed-protocol authentication scheme


   11.  Опыт в области сетей

        Network Experience and Demonstrations


      11a.  Общие вопросы

            General


         968 - 'Twas the Night Before Start-up

         967 - All Victims Together

         573 - Data and File Transfer - Some Measurement Results

         527 - ARPAWOCKY

         525 - MIT-Mathlab Meets UCSB-OLS

         439 - PARRY Encounters the Doctor

         420 - CCA ICC Weather Demo

         372 - Notes on a Conversation with Bob Kahn on the ICCC

         364 - Serving Remote Users on the ARPANET

         302 - Excercising the ARPANET

         231 - Service Center Standards for Remote Usage - A User's View

         227 - Data Transfer Rates (RAND/UCLA)

         113 - Network Activity Report: UCSB and Rand

         089 - Some Historic Moments in Networking

         004 - Network Timetable


   12. О документации

       Site Documentation


      12a.  Общие вопросы

            General


         30, 27, 24, 16, 10, 3 - Documentation Conventions










                                 -- 7722 --


   13. Стандарты организаций, не связанных с IAB

       Protocol Standards By Other Groups Of Interest


      13a.  ANSI


         570 - Experimental Input Mapping Between NVT ASCII and UCSB

               Online System

         183 - The EBCDIC Codes and Their Mapping to ASCII

         020 - ASCII Format for Network Interchange


      13b.  CCITT


         987 - Mapping Between X.400 and RFC 822

         874 - A Critique of X.25


      11c.  NRC


         942 - Transport Protocols for Department of Defense Data

               Networks

         939 - Executive Summary of the NRC Report on Transport

               Protocols for Department of Defense Data Networks


      13d.  ISO


         1139 - Echo function for ISO 8473

         1008 - Implementation guide for the ISO Transport Protocol

         1007 - Military supplement to the ISO Transport Protocol

         995 - End System to Intermediate System Routing Exchange

               Protocol for Use in Conjunction with ISO 8473

         994 - Final Text of DIS 8473, Protocol for Providing the

               Connectionless Mode Network Service

         982 - Guidelines for the Specification of the Structure of the

               Domain Specific Part (DSP) of the ISO Standard NSAP

               Address

         941 - Addendum to the Network Service Definition Covering

               Network Layer Addressing

         926 - Protocol for Providing the Connectionless-Mode Network

               Services

         905 - ISO Transport Protocol Specification (ISO DP 8073)

         892 - ISO Transport Protocol

         873 - The Illusion of Vendor Support










                                 -- 7733 --


   14. Взаимодействие с протоколами, не входящими в семейство TCP/IP

       Interoperability With Other Protocols


      14a.  Согласование протоколов и мосты

            Protocol Translation And Bridges


         1086 - ISO-TP0 bridge between TCP and X.25

         1029 - More fault tolerant approach to address resolution

                for a Multi-LAN system of Ethernets


      14b.  Согласование уровней протоколов

            Tunneling And Layering


         1090 - SMTP on X.25

         1089 - SNMP over Ethernet

         1085 - ISO presentation services on top of TCP/IP based

                internets

         1070 - Use of the Internet as a subnetwork for experimentation

                with the OSI network layer

         1006 - ISO transport services on top of TCP: Version: 3

         1002 - Protocol standard for a NetBIOS service on a TCP/UDP

                transport: Detailed specifications

         1001 - Protocol standard for a NetBIOS service on a TCP/UDP

                transport: Concepts and methods


      14c.  Отображение имен, адресов и идентификаторов

            Mapping of Names, Addresses and Identifiers


         1148, 1138 - Mapping between X.400(1988)/ISO 10021 and RFC 822

         1069 - Guidelines for the use of Internet-IP addresses

                in the ISO Connectionless-Mode Network Protocol

         1026 - Addendum to RFC 987: (Mapping between X.400 and

                RFC-822)

         987 - Mapping Between X.400 and RFC 822


      14d.  Разное

            Other


   15. Разное

       Miscellaneous












                                 -- 7744 --


      15а.  Общие вопросы

            General


         1121 - Act one - the poems

         1118 - Hitchhikers guide to the Internet

         1015 - Implementation plan for interagency research Internet


   16. Неклассифицированные RFC

       Unissued


      16a.  Старые документы

            Never Issued


         014, 026, 092, 159, 201, 220, 244, 248, 257, 258, 259, 260,

         261, 262, 272, 275, 277, 279, 284, 337, 341, 358, 375, 380,

         383, 397, 424, 427, 428, 444, 465, 481, 484, 502, 507, 517,

         536, 540, 541, 554, 558, 564, 572, 575, 583, 605, 639, 641,

         646, 648, 649, 650, 664, 665, 668, 670, 673, 676, 682, 693,

         709, 710, 711, 715, 723, 853.


      16b.  Новые документы

            Not yet Issued


         1060, 1061, 1099, 1108, 1140, 1142, 1147










































                                 -- 7755 --


Приложение 2.  Стандарты семейства протоколов TCP/IP


     Internet Activities Board (IAB) [3] присваивает протоколам семейства

TCP/IP состояние и статус. Везде далее под  словом  "стандарт"  мы  будем

иметь в виду стандарт IAB.



1.1.  Состояния протоколов


Состояние           Значение

=================   =================================================

Предлагаемый        Протокол был предложен в качестве стандарта

протокол            и находится в стадии начального рассмотрения.


Предварительный     Протокол прошел начальное рассмотрение и

стандарт            находится в почти законченном виде.

                    Существуют по крайней мере две независимых

                    реализации.


Стандартный         Протокол пересмотрен и принят как полный

протокол            стандарт. Он является составной частью TCP/IP.


Экспериментальный   Протокол пока не предлагался для стандартизации,

протокол            но используется в экспериментах.


Ознакомительный     Протокол разработан сторонней организацией и

протокол            находится вне компетенции IAB. Он может быть

                    опубликован в виде RFC для ознакомления.


Устаревший          Протокол устарел и в нстоящее время не

протокол            используется.
















____________________

     [3]  Совет по развитию сети Internet.












                                 -- 7766 --


1.2.  Статус протокола


Статус              Значение

=================   =================================================

Обязательный        Все узлы и шлюзы, использующие TCP/IP,

                    должны реализовывать этот протокол.


Рекомендуемый       Поощряется использование данного протокола

                    во всех узлах и шлюзах.


Выбираемый          Узлы и шлюзы могут реализовывать этот протокол.


Ограниченного       Протокол не предназначен для широкого

пользования         использования, например, он может быть

                    экспериментальным.


Нерекомендуемый     Данным протоколом пользоваться не рекомендуется.

                    Например, не рекомендуются устаревшие протоколы.





















































                                 -- 7777 --


2.1.  Стандартные протоколы

      Standard Protocols


Протокол   Название                                  Статус       RFC

========   =====================================     =========== ====

--------   Assigned Numbers                          Об.         1060

--------   Gateway Requirements                      Об.         1009

--------   Host Requirements - Communications        Об.         1122

--------   Host Requirements - Applications          Об.         1123

IP         Internet Protocol                         Об.          791

            с расширениями:

--------     IP Subnet Extension                     Об.          950

--------     IP Broadcast Datagrams                  Об.          919

--------     IP Broadcast Datagrams with Subnets     Об.          922

ICMP       Internet Control Message Protocol         Об.          792

IGMP       Internet Group Multicast Protocol         Рек.        1112

UDP        User Datagram Protocol                    Рек.         768

TCP        Transmission Control Protocol             Рек.         793

SMI        Structure of Management Information       Рек.        1155

MIB        Management Information Base               Рек.        1156

SNMP       Simple Network Management Protocol        Рек.        1157

DOMAIN     Domain Name System                        Рек.   1034,1035

TELNET     Telnet Protocol                           Рек.         854

FTP        File Transfer Protocol                    Рек.         959

SMTP       Simple Mail Transfer Protocol             Рек.         821

MAIL       Format of Electronic Mail Messages        Рек.         822

CONTENT    Content Type Header Field                 Рек.        1049

EGP        Exterior Gateway Protocol                 Рек.         904

ECHO       Echo Protocol                             Рек.         862

NTP        Network Time Protocol                     Рек.        1119

NETBIOS    NetBIOS Service Protocols                 Выб.   1001,1002

DISCARD    Discard Protocol                          Выб.         863

CHARGEN    Character Generator Protocol              Выб.         864

QUOTE      Quote of the Day Protocol                 Выб.         865

USERS      Active Users Protocol                     Выб.         866

DAYTIME    Daytime Protocol                          Выб.         867

TIME       Time Server Protocol                      Выб.         868











                                 -- 7788 --


2.2.  Стандартные протоколы разных сетей

      Network-Specific Standard Protocols


Протокол   Название                                 Статус        RFC

========   =====================================    ============ ====

ARP        Address Resolution Protocol              Выб.          826

RARP       A Reverse Address Resolution Protocol    Выб.          903

IP-ARPA    Internet Protocol on ARPANET             Выб.     BBN 1822

IP-WB      Internet Protocol on Wideband Network    Выб.          907

IP-X25     Internet Protocol on X.25 Networks       Выб.          877

IP-E       Internet Protocol on Ethernet Networks   Выб.          894

IP-EE      Internet Protocol on Exp. Ethernet Nets  Выб.          895

IP-IEEE    Internet Protocol on IEEE 802            Выб.         1042

IP-DC      Internet Protocol on DC Networks         Выб.          891

IP-HC      Internet Protocol on Hyperchannel        Выб.         1044

IP-ARC     Internet Protocol on ARCNET              Выб.         1051

IP-SLIP    Transmission of IP over Serial Lines     Выб.         1055

IP-NETBIOS Transmission of IP over NETBIOS          Выб.         1088

IP-FDDI    Transmission of IP over FDDI             Выб.         1103

IP-IPX     Transmission of 802.2 over IPX Networks  Выб.         1132













































                                 -- 7799 --


2.3.  Предварительные стандарты протоколов

      Draft Standard Protocols


Протокол   Название                                 Статус        RFC

========   =====================================    ============ ====

FINGER     Finger Protocol                          Выб.         1196

IP-FDDI    Internet Protocol on FDDI Networks       Выб.         1188

TOPT-LINE  Telnet Linemode Option                   Выб.         1184

MIB-II     MIB-II                                   Выб.         1213

PPP        Point to Point Protocol                  Выб.         1171

--------   Mail Privacy: Procedures                 Выб.         1113

--------   Mail Privacy: Key Management             Выб.         1114

--------   Mail Privacy: Algorithms                 Выб.         1115

BOOTP      Bootstrap Protocol                       Выб.951,1048,1084

RIP        Routing Information Protocol             Выб.         1058

TP-TCP     ISO Transport Service on top of the TCP  Выб.         1006

NICNAME    WhoIs Protocol                           Выб.          954

TFTP       Trivial File Transfer Protocol           Выб.          783

















































                                 -- 8800 --


2.4.  Предлагаемые стандарты протоколов

      Proposed Standard Protocols


Протокол   Название                                 Статус        RFC

========   =====================================    ============ ====

OIM-MIB-II OSI Internet Management: MIB-II          Выб.         1214

Concise-MIB Concise MIB Definitions                 Выб.         1212

IP-SMDS    IP Datagrams over the SMDS Service       Выб.         1209

IP-ARCNET  Transmitting IP Traffic over ARCNET Networks Выб.     1201

IS-IS      Use of OSI IS-IS for Routing in TCP/IP   Выб.         1195

           and Dual Environments

IP-MTU     Path MTU Discovery                       Выб.         1191

CMOT       Common Management Information Services   Выб.         1189

           and Protocol over TCP/IP

PPP-INIT   PPP Initial Configuration Options        Выб.         1172

BGP        Border Gateway Protocol                  Выб.    1163,1164

IP-CMPRS   Compressing TCP/IP Headers               Выб.         1144

--------   Echo for ISO-8473                        Выб.         1139

OSPF       Open Shortest Path First Routing         Выб.         1131

TOPT-ENV   Telnet Environment Option                Выб.         1116

SUN-NFS    Network File System Protocol             Выб.         1094

POP3       Post Office Protocol, Version 3          Выб.    1081,1082

SUN-RPC    Remote Procedure Call Protocol           Выб.         1057

PCMAIL     Pcmail Transport Protocol                Выб.         1056

NFILE      A File Access Protocol                   Выб.         1037

--------   Mapping between X.400(84) and RFC-822    Выб.     987,1026

NNTP       Network News Transfer Protocol           Выб.          977

HOSTNAME   HOSTNAME Protocol                        Выб.          953

SFTP       Simple File Transfer Protocol            Выб.          913

RLP        Resource Location Protocol               Выб.          887

SUPDUP     SUPDUP Protocol                          Выб.          734























                                 -- 8811 --


2.5.  Экспериментальные протоколы

      Experimental Protocols


Протокол   Название                                 Статус        RFC

========   =====================================    ============ ====

MPP        Message Posting Protocol                 Огр.         1204

ST-II      Stream Protocol                          Огр.         1190

SNMP-BULK  Bulk Table Retrieval with the SNMP       Огр.         1187

DNS-RR     New DNS RR Definitions                   Огр.         1183

NTP-OSI    NTP over OSI Remote Operations           Огр.         1165

MSP        Message Send Protocol                    Огр.         1159

EHF-MAIL   Encoding Header Field for Mail           Выб.         1154

DMF-MAIL   Digest Message Format for Mail           Выб.         1153

RDP        Reliable Data Protocol                   Огр.     908,1151

--------   Mapping between X.400(88) and RFC-822    Выб.         1148

TCP-ACO    TCP Alternate Checksum Option            Нерек.       1146

--------   Mapping full 822 to Restricted 822       Выб.         1137

IP-DVMRP   IP Distance Vector Multicast Routing     Нерек.       1075

TCP-LDP    TCP Extensions for Long Delay Paths      Огр.         1072

IMAP2      Interactive Mail Access Protocol         Огр.    1176,1064

IMAP3      Interactive Mail Access Protocol         Огр.         1203

VMTP       Versatile Message Transaction Protocol   Выб.         1045

COOKIE-JAR Authentication Scheme                    Нерек.       1004

NETBLT     Bulk Data Transfer Protocol              Нерек.        998

IRTP       Internet Reliable Transaction Protocol   Нерек.        938

AUTH       Authentication Service                   Нерек.        931

LDP        Loader Debugger Protocol                 Нерек.        909

NVP-II     Network Voice Protocol                   Огр.     ISI-memo

PVP        Packet Video Protocol                    Огр.     ISI-memo



























                                 -- 8822 --


2.6.  Ознакомительные протоколы

      Informational Protocols


Протокол   Название                                               RFC

=======    =====================================                 ====

SNMP-TRAPS A Convention for Defining Traps for use with SNMP     1215

DAS        Directory Assistance Service                          1202

-------    FYI on the X Window System                            1198

ODA        Office Document Architecture                          1197

MD4        MD4 Message Digest Algorithm                          1186

LPDP       Line Printer Daemon Protocol                          1179



2.7.  Устаревшие протоколы

      Historic Protocols


Протокол   Название                                 Статус        RFC

=======    =====================================    ============ ====

SGMP       Simple Gateway Monitoring Protocol       Нерек.       1028

HEMS       High Level Entity Management Protocol    Нерек.       1021

STATSRV    Statistics Server                        Нерек.        996

POP2       Post Office Protocol, Version 2          Нерек.        937

RATP       Reliable Asynchronous Transfer Protocol  Нерек.        916

THINWIRE   Thinwire Protocol                        Нерек.        914

HMP        Host Monitoring Protocol                 Нерек.        869

GGP        Gateway Gateway Protocol                 Нерек.        823

RTELNET    Remote Telnet Service                    Нерек.        818

CLOCK      DCNET Time Server Protocol               Нерек.        778

MPM        Internet Message Protocol                Нерек.        759

NETRJS     Remote Job Service                       Нерек.        740

NETED      Network Standard Text Editor             Нерек.        569

RJE        Remote Job Entry                         Нерек.        407

XNET       Cross Net Debugger                       Нерек.    IEN-158

NAMESERVER Host Name Server Protocol                Нерек.    IEN-116

MUX        Multiplexing Protocol                    Нерек.     IEN-90

GRAPHICS   Graphics Protocol                        Нерек.  NIC-24308



















                               Содержание


1.  Введение .......................................................    1


2.  Основы TCP/IP ..................................................    1

2.1.  Модуль IP создает единую логическую сеть .....................    1

2.2.  Структура связей протокольных модулей ........................    2

2.3.  Терминология .................................................    3

2.4.  Потоки данных ................................................    3

2.5.  Работа с несколькими сетевыми интерфейсами ...................    5


3.  Ethernet .......................................................    6

3.1.  Аналогия с разговором ........................................    7


4.  Протокол ARP ...................................................    7

4.1.  ARP-таблица для преобразования адресов .......................    8

4.2.  Порядок преобразования адресов ...............................    8

4.3.  Запросы и ответы протокола ARP ...............................    9

4.4.  Продолжение преобразования адресов ...........................   10


5.  Межсетевой протокол IP .........................................   11

5.1.  Прямая маршрутизация .........................................   11

5.2.  Косвенная маршрутизация ......................................   12

5.3.  Правила маршрутизации в модуле IP ............................   14

5.4.  IP-адрес .....................................................   15

5.5.  Выбор адреса .................................................   17

5.6.  Подсети ......................................................   17

5.7.  Как назначать номера сетей и подсетей ........................   18

5.8.  Имена ........................................................   19

5.9.  IP-таблица маршрутов .........................................   20

5.10.  Подробности прямой маршрутизации ............................   21

5.11.  Порядок прямой маршрутизации ................................   22

5.12.  Подробности косвенной маршрутизации .........................   22

5.13.  Порядок косвенной маршрутизации .............................   23


6.  Установка маршрутов ............................................   25

6.1.  Фиксированные маршруты .......................................   25

6.2.  Перенаправление маршрутов ....................................   26

6.3.  Слежение за маршрутизацией ...................................   28

6.4.  Протокол ARP с представителем ................................   30













7.  Протокол UDP ...................................................   32

7.1.  Порты ........................................................   33

7.2.  Контрольное суммирование .....................................   33


8.  Протокол TCP ...................................................   34


9.  Протоколы прикладного уровня ...................................   35

9.1.  Протокол TELNET ..............................................   36

9.2.  Протокол FTP .................................................   37

9.3.  Протокол SMTP ................................................   37

9.4.  r-команды ....................................................   37

9.5.  NFS ..........................................................   38

9.6.  Протокол SNMP ................................................   38

9.7.  X-Window .....................................................   38


10.  Взаимозависимость протоколов семейства TCP/IP .................   39


Приложение 1.  Путеводитель по RFC .................................   40


Приложение 2.  Стандарты семейства протоколов TCP/IP ...............   75

