Главная » Каталог    
рефераты Разделы рефераты
рефераты
рефератыГлавная

рефератыБиология

рефератыБухгалтерский учет и аудит

рефератыВоенная кафедра

рефератыГеография

рефератыГеология

рефератыГрафология

рефератыДеньги и кредит

рефератыЕстествознание

рефератыЗоология

рефератыИнвестиции

рефератыИностранные языки

рефератыИскусство

рефератыИстория

рефератыКартография

рефератыКомпьютерные сети

рефератыКомпьютеры ЭВМ

рефератыКосметология

рефератыКультурология

рефератыЛитература

рефератыМаркетинг

рефератыМатематика

рефератыМашиностроение

рефератыМедицина

рефератыМенеджмент

рефератыМузыка

рефератыНаука и техника

рефератыПедагогика

рефератыПраво

рефератыПромышленность производство

рефератыРадиоэлектроника

рефератыРеклама

рефератыРефераты по геологии

рефератыМедицинские наукам

рефератыУправление

рефератыФизика

рефератыФилософия

рефератыФинансы

рефератыФотография

рефератыХимия

рефератыЭкономика

рефераты
рефераты Информация рефераты
рефераты
рефераты

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


                               Содержание
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
                                  -- 11 --
                                1. 
Введение
     Семейство
протоколов TCP/IP широко 
применяется  во  всем 
мире  для
объединения компьютеров в сеть Internet.  Единая сеть Internet состоит из
множества сетей различной физической природы,  от 
локальных  сетей  типа
Ethernet  и Token
Ring, до глобальных сетей типа NSFNET. 
Основное внима-
ние в книге удел                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                                                               имеры, основанные
на  реализации  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 предназначена для 
объединенной  сети,
состоящей  из  соединенных 
друг  с  другом шлюзами отдельных разнородных
пакетных подсетей, к которым подключаются разнородные
машины.  Каждая  из
подсетей  работает в
соответствии со своими специфическими требованиями и
имеет свою природу средств связи.  Однако предполагается, что каждая под-
сеть  может  принять 
пакет  информации (данные с
соответствующим сетевым
заголовком) и доставить его по указанному адресу в этой  конкретной 
под-
                                  -- 22
--
сети.   Не  требуется, 
чтобы подсеть гарантировала обязательную доставку
пакетов и имела надежный сквозной протокол.  Таким образом,  две  машины,
подключенные к одной подсети могут обмениваться пакетами.
     Когда необходимо
передать пакет между машинами, подключенными к раз-
ным подсетям, то машина-отправитель посылает пакет в
соответствующий шлюз
(шлюз подключен к подсети также как обычный узел).  Оттуда пакет  направ-
ляется по определенному маршруту через систему шлюзов и
подсетей, пока не
достигнет шлюза, подключенного к той же подсети, что и
машина-получатель;
там  пакет  направляется  к  получателю.   Объединенная сеть обеспечивает
датаграммный сервис.
     Проблема
доставки пакетов в такой системе решается путем  реализации
во  всех  узлах 
и  шлюзах  межсетевого протокола IP.  Межсетевой уровень
является по существу базовым элементом во  всей 
архитектуре  протоколов,
обеспечивая возможность стандартизации протоколов верхних
уровней.
2.2.  Структура
связей протокольных модулей
     Логическая
структура сетевого программного обеспечения, реализующего
протоколы 
семейства  TCP/IP  в 
каждом узле сети internet, изображена на
рис.1. 
Прямоугольники обозначают обработку данных, а линии,  соединяющие
прямоугольники, 
-  пути  передачи  данных.   Горизонтальная  линия внизу
рисунка обозначает кабель сети Ethernet, которая
используется в  качестве
примера 
физической  среды;  "o"  - это трансивер.  Знак
"*" - обозначает
                        
------------------------------
                        
|    прикладные процессы     |
                        
|  ... \ | / ... \ | / ...   |
                        
|     -------   -------      |
                        
|     | TCP |   | UDP |      |
                        
|     -------   -------      |
                        
|           \    /           |
                        
|           ------           |
                        
|  -------  | IP |           |
                         |  | ARP |  -*----           |
                        
|  -------   |               |
                        
|         \  |               |
                        
|        --------            |
                        
|        | ENET |            |
                        
|        ---@----            |
                        
|           |                |
                        
------------|-----------------
                                     |
                 
-------------------o--------
                  
кабель Ethernet
        Рис.1.
Структура протокольных модулей в узле сети TCP/IP
                                  -- 33 --
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
                                  -- 44 --
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.   Если машину перемещают в другую часть                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                ортное
сообщение через модуль  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
                                                                                                                                                                                                                                                               
                                                                                                                                                                                                                                                                         
         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 Implem                                                                                                                                                                                
                                                                                                                                                                                                                                                                                                                                               
                                 -- 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 Tim
                                 -- 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
                                                                                                                         
                                                                                                                                                                                                                                                                                                                                                                                                      2,
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        
Огр.         120                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                acket
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
Міністерство Освіти України
Київський
Університет імені Тараса Шевченка
Факультет Кібернетики
Кафедра Теорії
Програмування
Курсова робота
На тему
Протоколи в локальних та
глобальних мережах на прикладі TCP/IP”
Виконавець:
Студент 3-го курсу
Групи ТП
Тягло О.О.
Науковий керівник
Доцент В.М. Волохов
Київ 1999р.
0.
Постановка задачи и результаты
С развитием
компьютерной техники широкое использование приобрели компьютерные сети. По
своему размеру, т.е. количеству машин и расстоянию между ними, они делятся на
локальные и глобальные. Примерами локальных могут быть сети вуза, предприятия,
нескольких фирм, находящихся недалеко друг от друга, глобальных – Internet.
Для передачи данных в сети
используются сетевые протоколы передачи данных. Некоторое время назад
существовало несколько протоколов несовместимых между собой, что зачастую
создавало большие проблемы при объединении сетей. Примером же универсального
протокола является семейство TCP/IP. История его возникновения
связана с задачей, поставленной после второй мировой войны правительством США.
Требовалось создать единую сеть, которая бы могла своими средствами находить
маршруты передачи их, а также в случае повреждения некоторых каналов связи
перенаправлять поток информации по другим каналам. При реализации этого проекта
были созданы отдельные представители семейства протоколов TCP/IP.
Сама сеть через некоторое время разрослась до необычайных размеров, её
представление сейчас известно всем как Internet.
В работе рассмотрены основные
моменты функционирования протоколов семейства TCP/IP.
В связи с особенностями протоколов
TCP/IP - широкая используемость как в локальных, так и
глобальных сетях, реализация практически во всех современных операционных
системах, можно смело говорить об их универсальности.  
1. Введение
Семейство протоколов TCP/IP широко применяется во всем
мире для объединения компьютеров в сеть Internet, реализации обмена данными
межу машинами. Основное внимание уделено примерам, основанным на реализации
TCP/IP в ОС UNIX. Однако основные положения применимы ко всем реализациям
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" - это трансивер. Знак "*" –
обозначает IP-адрес, а "@" - адрес узла в сети Ethernet
(Ethernet-адрес). Понимание этой логической структуры является основой для
понимания всей технологии internet. В дальнейшем мы будем часто ссылаться на
эту схему.
Рисунок 1
2.3.
Терминология
Введем ряд базовых терминов, которые мы будем
использовать в дальнейшем.
Драйвер -
это программа, непосредственно взаимодействующая с сетевым адаптером.
Модуль - это
программа, взаимодействующая с драйвером, сетевыми прикладными программами или
другими модулями.
Драйвер сетевого адаптера и, возможно, другие модули,
специфичные для физической сети передачи данных, предоставляют сетевой
интерфейс для протокольных модулей семейства TCP/IP.
Название блока данных, передаваемого по сети, зависит
от того, на каком уровне стека протоколов он находится. Блок данных, с которым
имеет дело сетевой интерфейс, называется кадром; если блок данных
находится между сетевым интерфейсом и модулем IP, то он называется IP-пакетом;
если он между модулем IP и модулем UDP, то - UDP-датаграммой; если между
модулем IP и модулем TCP, то - TCP-сегментом (или транспортным сообщением);
наконец, если блок данных находится на уровне сетевых прикладных процессов, то
он называется прикладным сообщением.
2.4. Потоки
данных
Рассмотрим потоки данных, проходящие через стек
протоколов, изображенный на рис.1. В случае использования протокола TCP
(Transmission Control 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 являются
мультиплексорами . Действуя как мультиплексоры, они переключают несколько
входов на один выход. Они также являются демультиплексорами . Как демультиплексоры, они переключают один вход на один из многих
выходов в соответствии с полем типа в заголовке протокольного блока данных
(рис.2).
Когда Ethernet-кадр попадает в драйвер сетевого
интерфейса Ethernet, он может быть направлен либо в модуль ARP (Address
Resolution Protocol - адресный протокол), либо в модуль IP (Internet Protocol -
межсетевой протокол). На то, куда должен быть направлен Ethernet-кадр,
указывает значение поля типа в заголовке кадра.
Если IP-пакет попадает в модуль IP, то содержащиеся в
нем данные могут быть переданы либо модулю TCP, либо UDP, что определяется
полем "протокол" в заголовке IP-пакета.
Если UDP-датаграмма попадает в модуль UDP, то на
основании значения поля "порт" в заголовке датаграммы определяется
прикладная программа, которой должно быть передано прикладное сообщение. Если
TCP-сообщение попадает в модуль TCP, то выбор прикладной программы, которой
должно быть передано сообщение, осуществляется на основе значения поля
"порт" в заголовке TCP-сообщения.
Мультиплексирование данных в обратную сторону
осуществляется довольно просто, так как из каждого модуля существует только
один путь вниз. Каждый протокольный модуль добавляет к пакету свой заголовок,
на основании которого машина, принявшая пакет, выполняет демультиплексирование.
Рисунок 2
Данные от прикладного процесса проходят через модули
TCP или UDP, после чего попадают в модуль IP и оттуда - на уровень сетевого
интерфейса.
Хотя технология internet поддерживает много различных
сред передачи данных, здесь мы будем предполагать использование Ethernet, так
как именно эта среда чаще всего служит физической основой для IP-сети. Машина
на рис.1 имеет одну точку соединения с Ethernet. Шестибайтный Ethernet-адрес
является уникальным для каждого сетевого адаптера и распознается драйвером.
Машина имеет также четырехбайтный IP-адрес. Этот адрес
обозначает точку доступа к сети на интерфейсе модуля IP с драйвером. IP-адрес
должен быть уникальным в пределах всей сети Internet.
Работающая машина всегда знает свой IP-адрес и
Ethernet-адрес.
2.5. Работа
с несколькими сетевыми интерфейсами
Машина может быть подключена одновременно к нескольким
средам передачи данных.
Для машин с несколькими сетевыми интерфейсами модуль
IP выполняет функции мультиплексора  и демультиплексора . Схема аналогична рис.2.
Таким образом, он осуществляет мультиплексирование
входных и выходных данных в обоих направлениях. Модуль IP в данном случае
сложнее, чем в первом примере, так как может передавать данные между сетями.
Данные могут поступать через любой сетевой интерфейс и быть ретранслированы
через любой другой сетевой интерфейс. Процесс передачи пакета в другую сеть
называется ретрансляцией IP-пакета. Машина, выполняющая ретрансляцию,
называется шлюзом.
Как показано на рис.3, ретранслируемый пакет не передается модулям TCP или
UDP. Некоторые шлюзы вообще могут не иметь модулей TCP и UDP.
3. Ethernet
Кадр Ethernet содержит адрес назначения, адрес
источника, поле типа и данные. Размер адреса в Ethernet - 6 байт. Каждый
сетевой адаптер имеет свой Ethernet-адрес. Адаптер контролирует обмен
информацией, про исходящий в сети, и принимает адресованные ему Ethernet-кадры,
а также Ethernet-кадры с адресом "FF:FF:FF:FF:FF:FF" (в
16-ричной системе), который обозначает "всем", и используется при
широковещательной передаче.
Рисунок 3
В документации по TCP/IP термины шлюз (gateway)
и IP-маршрутизатор (IP-router) часто используются как синонимы. Мы сочли
возможным использовать более распространенный термин "шлюз".
Ethernet реализует метод МДКН/ОС (множественный доступ
с контролем несущей и обнаружением столкновений). Метод МДКН/ОС предполагает,
что все устройства взаимодействуют в одной среде, в каждый момент времени может
передавать только одно устройство, а принимать могут все одновременно. Если два
устройства пытаются передавать одновременно, то происходит столкновение
передач, и оба устройства после случайного (краткого) периода ожидания пытаются
вновь выполнить передачу.
3.1.
Аналогия с разговором
Хорошей аналогией взаимодействиям в среде Ethernet
может служить разговор группы вежливых людей в небольшой темной комнате. При
этом аналогией электрическим сигналам в коаксиальном кабеле служат звуковые
волны в комнате.
Каждый человек слышит речь других людей (контроль
несущей). Все люди в комнате имеют одинаковые возможности вести разговор
(множественный доступ), но никто не говорит слишком долго, так как все вежливы.
Если человек будет невежлив, то его попросят выйти (т.е. удалят из сети). Все
молчат, пока кто-то говорит. Если два человека начинают говорить одновременно,
то они сразу обнаруживают это, поскольку слышат друг друга (обнаружение
столкновений). В этом случае они замолкают и ждут некоторое время, после чего
один из них вновь начинает разговор. Другие люди слышат, что ведется разговор,
и ждут, пока он кончится, а затем могут начать говорить сами. Каждый человек
имеет собственное имя (аналог уникального Ethernet-адреса). Каждый раз, когда
кто-нибудь начинает говорить, он называет по имени того, к кому обращается, и
свое имя, например, "Слушай Петя, это Андрей, /*текст сообщения*/"
Если кто-то хочет обратиться ко всем, то он говорит: "Слушайте все, это
Андрей, /*текст сообщения*/" (широковещательная передача).
 4. Протокол ARP
При посылке IP-пакета определяется Ethernet-адрес
назначения следующим образом: для отображения IP-адресов в Ethernet адреса используется протокол ARP (Address Resolution
Protocol – адресный протокол). Отображение выполняется только для отправляемых
IP-пакетов, так как только в момент отправки создаются заголовки IP и Ethernet.
4.1.
ARP-таблица для преобразования адресов
Преобразование адресов выполняется путем поиска в
таблице. Эта таблица, называемая ARP-таблицей, хранится в памяти и содержит
строки для каждого узла сети. В двух столбцах содержатся IP- и Ethernet-адреса.
Если требуется преобразовать IP-адрес в Ethernet-адрес, то ищется запись с
соответствующим IP-адресом. Ниже приведен пример упрощенной ARP-таблицы.
Таблица
1. 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
Принято все байты 4-байтного IP-адреса записывать десятичными
числами, разделенными точками. При записи 6-байтного Ethernet-адреса каждый
байт указывается в 16-ричной системе и отделяется двоеточием.
ARP-таблица необходима потому, что IP-адреса и
Ethernet-адреса выбираются независимо, и нет какого-либо алгоритма для
преобразования одного в другой. Поэтому для определения искомого
Ethernet-адреса используется ARP-таблица.
4.3.
Запросы и ответы протокола ARP
Как же заполняется ARP-таблица? Она заполняется
автоматически модулем ARP, по мере необходимости. Когда с помощью существующей
ARP-таблицы не удается преобразовать IP-адрес, то происходит следующее:
1) По сети передается широковещательный ARP-запрос.
2) Исходящий IP-пакет ставится в очередь.
Каждый сетевой адаптер принимает широковещательные
передачи. Все драйверы Ethernet проверяют поле типа в принятом Ethernet-кадре и
передают ARP-пакеты модулю ARP. ARP-запрос можно интерпретировать так:
"Если ваш IP-адрес совпадает с указанным, то сообщите мне ваш
Ethernet-адрес". Пакет ARP-запроса выглядит примерно так:
Таблица
2. IP-адрес отправителя 223.1.2.1 Ethernet-адрес отправителя 08:00:39:00:2F:C3 Искомый IP-адрес 223.1.2.2 Искомый Ethernet-адрес <пусто>
 
Каждый модуль ARP проверяет поле искомого IP-адреса в
полученном ARP-пакете и, если адрес совпадает с его собственным IP-адресом, то
посылает ответ прямо по Ethernet-адресу отправителя запроса. ARP-ответ можно
интерпретировать так: "Да, это мой IP-адрес, ему соответствует такой-то
Ethernet-адрес". Пакет с ARP-ответом выглядит примерно так:
Таблица
3. IP-адрес отправителя 223.1.2.2 Ethernet-адрес отправителя 08:00:28:00:38:A9 Искомый IP-адрес 223.1.2.1 Искомый Ethernet-адрес 08:00:39:00:2F:C3
Этот ответ получает машина, сделавшая ARP-запрос.
Драйвер этой машины проверяет поле типа в Ethernet-кадре и передает ARP-пакет
модулю ARP. Модуль ARP анализирует ARP-пакет и добавляет запись в свою
ARP-таблицу.
Обновленная таблица выглядит следующим образом:
Таблица
4. 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.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-пакет передается по назначению.
Если в сети нет машины с искомым IP-адресом, то
ARP-ответа не будет и не будет записи в ARP-таблице. Протокол IP будет
уничтожать IP-пакеты, направляемые по этому адресу. Протоколы верхнего уровня
не могут отличить случай повреждения сети Ethernet от случая отсутствия машины
с искомым IP-адресом.
Некоторые реализации IP и ARP не ставят в очередь
IP-пакеты на то время, пока они ждут ARP-ответов. Вместо этого IP-пакет просто
уничтожается, а его восстановление возлагается на модуль TCP или прикладной
процесс, работающий через UDP. Такое восстановление выполняется с помощью
таймаутов и повторных передач. Повторная передача сообщения проходит успешно,
так как первая попытка уже вызвала заполнение ARP-таблицы.
Следует отметить, что каждая машина имеет отдельную
ARP-таблицу для каждого своего сетевого интерфейса.
 5. Межсетевой протокол IP
Модуль IP является базовым элементом технологии
internet, а центральной частью IP является его таблица маршрутов. Протокол IP
использует эту таблицу при принятии всех решений о маршрутизации IP-пакетов.
Содержание таблицы маршрутов определяется администратором сети. Ошибки при
установке маршрутов могут заблокировать передачи.
5.1. Прямая
маршрутизация
На рис.4 показана небольшая IP-сеть, состоящая из 3
машин: A, B и C. Каждая машина имеет такой же стек протоколов TCP/IP как на
рис.1. Каждый сетевой адаптер этих машин имеет свой Ethernet-адрес. Менеджер
сети должен присвоить машинам уникальные IP-адреса.
Рисунок 4  (IP-сеть
"development")
Когда A посылает IP-пакет B, то заголовок IP-пакета
содержит в поле отправителя IP-адрес узла A, а заголовок Ethernet-кадра
содержит в поле отправителя Ethernet-адрес A. Кроме этого, IP-заголовок
содержит в поле получателя IP-адрес узла B, а Ethernet-заголовок содержит в
поле получателя Ethernet-адрес B.
Таблица
5. Адрес отправитель Получатель IP-заголовок A B Ethrnet-заголовок A B
В этом простом примере протокол IP является
излишеством, которое мало что добавляет к услугам, предоставляемым сетью
Ethernet. Однако протокол IP требует дополнительных расходов на создание,
передачу и обработку IP-заголовка. Когда в машине B модуль IP получает IP-пакет
от машины A, он сопоставляет IP-адрес места назначения со своим и, если адреса
совпадают, то передает датаграмму протоколу верхнего уровня.
В данном случае при взаимодействии A с B используется
прямая маршрутизация.
5.2.
Косвенная маршрутизация
На рис.5 представлена
более реалистичная картина сети internet. В данном случае сеть internet состоит
из трех сетей Ethernet, на базе которых работают три IP-сети, объединенные
шлюзом D. Каждая IP-сеть включает четыре машины; каждая машина имеет свои
собственные IP- и Ethernet-адреса.
Рисунок 5
За исключением D все машины имеют стек протоколов,
аналогичный показанному на рис.1. Шлюз D соединяет все три сети и,
следовательно, имеет три IP-адреса и три Ethernet-адреса. Машина D имеет стек
протоколов TCP/IP, который содержит три модуля ARP и
три драйвера Ethernet. Обратим внимание на то, что машина D имеет только один
модуль IP.
Менеджер сети присваивает каждой сети Ethernet
уникальный номер, называемый IP-номером сети. На рис.5 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.
Таблица
6. Адрес Отправитель Получатель IP-заголовок A E Ethrnet-заголовок A D
 
Модуль IP в машине D получает IP-пакет и проверяет
IP-адрес места назначения. Определив, что это не его IP-адрес, шлюз D посылает
этот IP-пакет прямо к E.
Таблица
7. Адрес отправитель Получатель IP-заголовок A E Ethrnet-заголовок D E
Итак, при прямой маршрутизации IP- и Ethernet-адреса
отправителя соответствуют адресам того узла, который послал IP-пакет, а IP- и
Ethernet-адреса места назначения соответствуют адресам получателя. При
косвенной маршрутизации IP- и Ethernet-адреса не образуют таких пар.
В данном примере сеть internet является очень простой.
Реальные сети могут быть гораздо сложнее, так как могут содержать несколько
шлюзов и несколько типов физических сред передачи. В приведенном примере
несколько сетей Ethernet объединяются шлюзом для того, чтобы локализовать
широковещательный трафик в каждой сети.
5.3.
Правила маршрутизации в модуле IP
Выше мы показали, что происходит при передаче
сообщений, а теперь рассмотрим правила или алгоритм маршрутизации.
Для отправляемых IP-пакетов, поступающих от модулей
верхнего уровня, модуль IP должен определить способ доставки - прямой или
косвенный – и выбрать сетевой интерфейс. Этот выбор делается на основании
результатов поиска в таблице маршрутов.
Для принимаемых 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-адресов каждого
класса.
Таблица
8. Класс Диапазон значений первого октета Возможное количество сетей Возможное количество узлов A 1-126 126 16777214 B 128-191 16382 65534 C 192-223 2097150 254 D 224-239 - 268435456 E 240-247 - 134217728
Адреса класса A предназначены для использования в
больших сетях общего пользования. Они допускают большое количество номеров
узлов. Адреса класса B используются в сетях среднего размера, например, сетях
университетов и крупных компаний. Адреса класса C используются в сетях с небольшим
числом компьютеров. Адреса класса D используются при обращениях к группам
машин, а адреса класса E зарезервированы на будущее.
Некоторые IP-адреса являются выделенными и трактуются
по-особому. В выделенных IP-адресах все нули соответствуют либо данному узлу,
либо данной IP-сети, а IP-адреса, состоящие из всех единиц, используются при
широковещательных передачах. Для ссылок на всю IP-сеть в целом используется
IP-адрес с нулевым номером узла. Особый смысл имеет IP-адрес, первый октет
которого равен 127. Он используется для тестирования программ и взаимодействия
процессов в пределах одной машины. Когда программа посылает данные по IP-адресу
127.0.0.1, то образуется как бы "петля". Данные не передаются по
сети, а возвращаются модулям верхнего уровня, как только что принятые. Поэтому
в IP-сети запрещается присваивать машинам IP-адреса, начинающиеся со 127.
5.5. Выбор
адреса
Прежде чем вы начнете использовать сеть с TCP/IP, вы
должны получить один или несколько официальных сетевых номеров. Выделением
номеров (как и многими другими вопросами) занимается DDN Network Information
Center (NIC). Выделение номеров производится бесплатно и занимает около недели.
Вы можете получить сетевой номер вне зависимости от того, для чего
предназначена ваша сеть. Даже если ваша сеть не имеет связи с объединенной
сетью Internet, получение уникального номера желательно, так как в этом случае
есть гарантия, что в будущем при включении в Internet или при подключении к
сети другой организации не возникнет конфликта адресов.
Одно из важнейших решений, которое необходимо принять
при установке сети, заключается в выборе способа присвоения IP-адресов вашим
машинам. Этот выбор должен учитывать перспективу роста сети. Иначе в дальнейшем
вам придется менять адреса. Когда к сети подключено несколько сотен машин,
изменение адресов становится почти невозможным.
Организации, имеющие небольшие сети с числом узлов до
126, должны запрашивать сетевые номера класса C. Организации с большим числом
машин могут получить несколько номеров класса C или номер класса B. Удобным
средством структуризации сетей в рамках одной организации являются подсети.
5.6.
Подсети
Адресное пространство сети internet может быть
разделено на непересекающиеся подпространства - "подсети", с каждой
из которых можно работать как с обычной сетью TCP/IP. Таким образом, единая
IP-сеть организации может строиться как объединение подсетей. Как правило,
подсеть соответствует одной физической сети, например, одной сети Ethernet.
Конечно, использование подсетей необязательно. Можно
просто назначить для каждой физической сети свой сетевой номер, например, номер
класса C. Однако такое решение имеет два недостатка. Первый, и менее
существенный, заключается в пустой трате сетевых номеров. Более серьезный
недостаток состоит в том, что если ваша организация имеет несколько сетевых
номеров, то машины вне ее должны поддерживать записи о маршрутах доступа к
каждой из этих IP-сетей. Таким образом, структура IP-сети организации
становится видимой для всего мира. При каких-либо изменениях в IP-сети информация
о них должна быть учтена в каждой из машин, поддерживающих маршруты доступа к
данной IP-сети.
Подсети позволяют избежать этих недостатков. Ваша
организация должна получить один сетевой номер, например, номер класса B.
Стандарты TCP/IP определяют структуру IP-адресов. Для IP-адресов класса B
первые два октета являются номером сети. Оставшаяся часть IP-адреса может
использоваться как угодно. Например, вы можете решить, что третий октет будет
определять номер подсети, а четвёртый октет - номер узла в ней. Вы должны
описать конфигурацию подсетей в файлах, определяющих маршрутизацию IP-пакетов.
Это описание является локальным для вашей организации и не видно вне ее. Все
машины вне вашей организации видят одну большую IP-сеть. Следовательно, они
должны поддерживать только маршруты доступа к шлюзам, соединяющим вашу IP-сеть
с остальным миром. Изменения, происходящие в IP-сети организации, не видны вне
ее. Вы легко можете добавить новую подсеть, новый шлюз и т.п.
5.7. Как
назначать номера сетей и подсетей
После того, как решено использовать подсети или
множество IP-сетей, вы должны решить, как назначать им номера. Обычно это
довольно просто. Каждой физической сети, например, Ethernet или Token Ring,
назначается отдельный номер подсети или номер сети. В некоторых случаях имеет
смысл назначать одной физической сети несколько подсетевых номеров. Например,
предположим, что имеется сеть Ethernet, охватывающая три здания. Ясно, что при
увеличении числа машин, подключенных к этой сети, придется ее разделить на несколько
отдельных сетей Ethernet. Для того чтобы избежать необходимости менять
IP-адреса, когда это произойдет, можно заранее выделить для этой сети три
подсетевых номера - по одному на здание. (Это полезно и в том случае, когда не планируется физическое деление сети. Просто такая адресация позволяет сразу определить, где находится та или иная машина). Однако прежде, чем выделять три
различных подсетевых номера одной физической сети, тщательно проверьте, что все
ваши программы способны работать в такой среде.
Вы также должны выбрать "маску подсети". Она
используется сетевым программным обеспечением для выделения номера подсети из
IP-адресов. Биты IP-адреса, определяющие номер IP-сети, в маске подсети должны
быть равны 1, а биты, определяющие номер узла, в маске подсети должны быть
равны 0. Как уже отмечалось, стандарты TCP/IP определяют количество октетов,
задающих номер сети. Часто в IP-адресах класса B третий октет используется для
задания номера подсети. Это позволяет иметь 256 подсетей, в каждой из которых может
быть до 254 узлов. Маска подсети в такой системе равна 255.255.255.0. Но, если
в вашей сети должно быть больше подсетей, а в каждой подсети не будет при этом
более 60 узлов, то можно использовать маску 255.255.255.192. Это позволяет
иметь 1024 подсети и до 62 узлов в каждой. (Напомним, что номера узлов 0 и
"все единицы" используются особым образом.)
Обычно маска подсети указывается в файле стартовой
конфигурации сетевого программного обеспечения. Протоколы TCP/IP позволяют
также запрашивать эту информацию по сети.
5.8. Имена
Людям удобнее называть машины по именам, а не числами.
Например, у машины по имени alpha может быть IP-адрес 223.1.2.1. В маленьких
сетях информация о соответствии имен IP-адресам хранится в файлах
"hosts" на каждом узле. Конечно, название файла зависит от конкретной
реализации. В больших сетях эта информация хранится на сервере и доступна по
сети. Несколько строк из файла "hosts" могут выглядеть примерно так:
223.1.2.1 alpha
223.1.2.2 beta
223.1.2.3 gamma
223.1.2.4 delta
223.1.3.2 epsilon
223.1.4.2 iota
В
первом столбце - IP-адрес, во втором - название машины.
В большинстве случаев файлы "hosts" могут
быть одинаковы на всех узлах. Заметим, что об узле delta в этом файле есть
всего одна запись, хотя он имеет три IP-адреса. Узел delta доступен по любому
из этих IP-адресов. Какой из них используется, не имеет значения. Когда узел
delta получает IP-пакет и проверяет IP-адрес места назначения, то он опознает
любой из трех своих IP-адресов.
IP-сети также могут иметь имена. Если у вас есть три
IP-сети, то файл "networks" может выглядеть примерно так:
223.1.2 development
223.1.3 accounting
223.1.4 factory
В
первой колонке - сетевой номер, во второй - имя сети.
В данном примере alpha является узлом номер 1 в сети
development, beta является узлом номер 2 в сети development и т.д.
Показанный выше файл hosts удовлетворяет потребности
пользователей, но для управления сетью internet удобнее иметь названия всех
сетевых интерфейсов. Менеджер сети, возможно, заменит строку, относящуюся к
delta:
223.1.2.4 devnetrouter delta
223.1.3.1 accnetrouter
223.1.4.1 facnetrouter
Эти три строки файла hosts задают каждому IP-адресу
узла delta символьные имена. Фактически, первый IP-адрес имеет два имени:
"devnetrouter" и "delta", которые являются синонимами. На
практике имя "delta" используется как общеупотребительное имя машины,
а остальные три имени - для администрирования сети.
Файлы hosts и networks используются командами
администрирования и прикладными программами. Они не нужны собственно для работы
сети internet, но облегчают ее использование.
5.9.
IP-таблица маршрутов
Как модуль IP узнает, какой именно сетевой интерфейс
нужно использовать для отправления IP-пакета? Модуль IP осуществляет поиск в
таблице маршрутов. Ключом поиска служит номер IP-сети, выделенный из IP-адреса
места назначения IP-пакета.
Таблица маршрутов содержит по одной строке для каждого
маршрута. Основными столбцами таблицы маршрутов являются номер сети, флаг
прямой или косвенной маршрутизации, IP-адрес шлюза и номер сетевого интерфейса.
Эта таблица используется модулем IP при обработке каждого отправляемого
IP-пакета.
В большинстве систем таблица маршрутов может быть
изменена с помощью команды "route". Содержание таблицы маршрутов
определяется менеджером сети, поскольку менеджер сети присваивает машинам
IP-адреса.
5.10.
Подробности прямой маршрутизации
Рассмотрим более подробно, как происходит
маршрутизация в одной физической сети.
Таблица маршрутов в узле alpha выглядит так:
Таблица
9. Сеть Флаг вида маршрутизации Шлюз Номер интерфейса Development прямая <пусто> 1
В данном простом примере все узлы сети имеют
одинаковые таблицы маршрутов.
Для сравнения ниже представлена та же таблица, но
вместо названия сети указан ее номер.
Таблица
10. Сеть Флаг вида маршрутизации Шлюз Номер интерфейса 223.1.2 прямая <пусто> 1
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-сети, изображенной на рис.5 (в данном случае  A – alfa, D – delta, E – epsilon, I - iota).
Таблица маршрутов в узле alpha выглядит так:
Таблица
11. Сеть Флаг вида маршрутизации Шлюз Номер интерфейса Development Прямая <пусто> 1 Accouting Косвенная Devnetrouter 1 Factory Косвенная Devnetrouter 1
Та же таблица с IP-адресами вместо названий.
Таблица
12. Сеть Флаг вида маршрутизации Шлюз Номер интерфейса 223.1.2 Прямая <пусто> 1 223.1.3 Косвенная 223.1.2.4 1 223.1.4 косвенная 223.1.2.4 1
В столбце "шлюз" таблицы маршрутов узла
alpha указывается IP-адрес точки соединения узла delta с сетью development.
5.13.
Порядок косвенной маршрутизации
Узел alpha посылает IP-пакет узлу epsilon. Этот пакет
находится в модуле IP узла alpha, и IP-адрес места назначения равен IP-адресу
узла epsilon (223.1.3.2). Модуль IP выделяет сетевой номер из IP-адреса
(223.1.3) и ищет соответствующую ему строку в таблице маршрутов. Соответствие
находится во второй строке.
Запись в этой строке указывает на то, что машины
требуемой сети доступны через шлюз devnetrouter. Модуль IP в узле alpha
осуществляет поиск в ARP-таблице, с помощью которого определяет Ethernet-адрес,
соответствующий IP-адресу devnetrouter. Затем IP-пакет, содержащий IP-адрес места
назначения epsilon, посылается через интерфейс 1 шлюзу devnetrouter.
IP-пакет принимается сетевым интерфейсом в узле delta
и передается модулю IP. Проверяется IP-адрес места назначения, и, поскольку он
не соответствует ни одному из собственных IP-адресов delta, шлюз решает
ретранслировать IP-пакет.
Модуль IP в узле delta выделяет сетевой номер из
IP-адреса места назначения IP-пакета (223.1.3) и ищет соответствующую запись в
таблице маршрутов. Таблица маршрутов в узле delta выглядит так:
Таблица
13. Сеть Флаг вида маршрутизации Шлюз Номер интерфейса Development прямая <пусто> 1 Accouting прямая <пусто> 2 Factory прямая <пусто> 3
Та же таблица с IP-адресами вместо названий:
Таблица
14. Сеть Флаг вида маршрутизации Шлюз Номер интерфейса 223.1.2 прямая <пусто> 1 223.1.3 прямая <пусто> 2 223.1.4 прямая <пусто> 3
Соответствие находится во второй строке. Теперь модуль
IP напрямую посылает IP-пакет узлу epsilon через интерфейс номер 3. Пакет
содержит IP- и Ethernet-адреса места назначения равные epsilon.
Узел epsilon принимает IP-пакет, и его модуль IP
проверяет IP-адрес места назначения. Он соответствует IP-адресу epsilon,
поэтому содержащееся в IP-пакете сообщение передается протокольному модулю
верхнего уровня.
6. Установка маршрутов
До сих пор мы рассматривали то, как используется
таблица маршрутов для маршрутизации IP-пакетов. Но откуда берется информация в
самой таблице маршрутов? В данном разделе мы рассмотрим методы, позволяющие
поддерживать корректность таблиц маршрутов.
6.1.
Фиксированные маршруты
Простейший способ проведения маршрутизации состоит в
установке маршрутов при запуске системы с помощью специальных команд. Этот
метод можно применять в относительно маленьких IP-сетях, в особенности, если их
конфигурации не часто меняются.
На практике большинство машин автоматически формирует
таблицы маршрутов. Например, UNIX добавляет записи о IP-сетях, к которым есть
непосредственный доступ. Стартовый файл может содержать команды
ifconfig ie0 128.6.4.4 netmask 255.255.255.0
ifconfig ie1 128.6.5.35 netmask 255.255.255.0
Они
показывают, что существуют два сетевых интерфейса, и устанавливают их
IP-адреса.
Система может автоматически создать две записи в таблице
маршрутов:
Таблица
15. Сеть Флаг вида маршрутизации Шлюз Номер интерфейса 128.6.4 прямая <пусто> ie0 128.6.5 прямая <пусто> ie1
Эти записи определяют, что IP-пакеты для локальных
подсетей 128.6.4 и 128.6.5 должны посылаться через указанные интерфейсы.
В стартовом файле могут быть команды, определяющие
маршруты доступа к другим IP-сетям. Например:
route add 128.6.2.0 128.6.4.1 1
route add 128.6.6.0 128.6.5.35 0
Эти команды показывают, что в таблицу маршрутов должны
быть добавлены две записи. Первый адрес в командах является IP-адресом сети,
второй адрес указывает шлюз, который должен использоваться для доступа к данной
IP-сети, а третий параметр является метрикой. Метрика показывает, на каком
"расстоянии" находится описываемая IP-сеть. В данном случае метрика -
это количество шлюзов на пути между двумя IP-сетями. Маршруты с метрикой 1 и
более определяют первый шлюз на пути к IP-сети. Маршруты с метрикой 0
показывают, что никакой шлюз не нужен - данный маршрут задает дополнительный
сетевой номер локальной IP-сети.
Таким образом, команды, приведенные в примере, говорят
о том, что для доступа к IP-сети 128.6.2 должен использоваться шлюз 128.6.4.1,
а IP-сеть 128.6.6 - это просто дополнительный номер для физической сети,
подключенной к интерфейсу 128.6.5.35.
Таблица
16. Сеть Флаг вида маршрутизации Шлюз Номер интерфейса 128.6.2 косвенная 128.6.4.1 ie0 128.6.6 прямая <пусто> ie1
Можно определить маршрут по умолчанию, который
используется в тех случаях, когда IP-адрес места назначения не встречается в
таблице маршрутов явно. Обычно маршрут по умолчанию указывает IP-адрес шлюза,
который имеет достаточно информации для маршрутизации IP-пакетов со всеми
возможными адресами назначения.
Если ваша IP-сеть имеет всего один шлюз, тогда все,
что нужно сделать, - это установить единственную запись в таблице маршрутов,
указав этот шлюз как маршрут по умолчанию. После этого можно не заботиться о
формировании маршрутов в других узлах. (Конечно, сам шлюз требует больше
внимания.)
6.2.
Перенаправление маршрутов
Большинство экспертов по межсетевому взаимодействию
рекомендуют оставлять решение проблем маршрутизации шлюзам. Плохо иметь на
каждой машине большую таблицу маршрутов. Дело в том, что при каких-либо
изменениях в IP-сети приходится менять информацию во всех машинах. Например,
при отключении какого-нибудь канала связи для восстановления нормальной работы
нужно ждать, пока кто-то заметит это изменение в конфигурации IP-сети и внесет
исправления во все таблицы маршрутов.
Простейший способ поддержания адекватности маршрутов
заключается в том, что изменение таблицы маршрутов каждой машины выполняется по
командам только одного шлюза. Этот шлюз должен быть установлен как маршрут по
умолчанию. (В ОС UNIX это делается командой "route add default 128.6.4.27
1", где 128.6.4.27 является IP-адресом шлюза.) Как было описано выше,
каждая машина посылает IP-пакет шлюзу по умолчанию в том случае, когда не
находит лучшего маршрута. Однако когда в IP-сети есть несколько шлюзов, этот
метод работает не так хорошо. Кроме того, если таблица маршрутов имеет только
одну запись о маршруте по умолчанию, как использовать другие шлюзы, если это
более выгодно? Ответ состоит в том, что большинство шлюзов способны выполнять
"перенаправление" в тех случаях, когда они получают IP-пакеты, для
которых существуют более выгодные маршруты. "Перенаправление"
является специальным типом сообщения протокола ICMP (Internet Control Message
Protocol - протокол межсетевых управляющих сообщений). Сообщение о
перенаправлении содержит информацию, которую можно интерпретировать так:
"В будущем для IP-адреса XXXX используйте шлюз YYYY, а не меня".
Корректные реализации TCP/IP должны использовать сообщения о перенаправлении
для добавления записей в таблицу маршрутов. Предположим, таблица маршрутов в
начале выглядит следующим образом:
Таблица
17. Адрес назначения Флаг вида маршрутизации Шлюз Интерфейс 127.0.0 косвенная <пусто> lo0 128.6.4 прямая <пусто> pe0 Default прямая 128.6.4.27 pe0
Эта
таблица содержит запись о локальной IP-сети 128.6.4 и маршрут по умолчанию,
указывающий шлюз 128.6.4.27. Допустим, что существует шлюз 128.6.4.30, который
является лучшим путем доступа к IP-сети 128.6.7. Как им воспользоваться?
Предположим, что нужно посылать IP-пакеты по IP-адресу 128.6.7.23. Первый
IP-пакет пойдет на шлюз по умолчанию, так как это единственный подходящий
маршрут, описанный в таблице. Однако шлюз 128.6.4.27 знает, что существует
лучший маршрут, проходящий через шлюз 128.6.4.30. (Как он узнает об этом, мы
сейчас не рассматриваем. Существует довольно простой метод определения лучшего
маршрута.) В этом случае шлюз 128.6.4.27 возвращает сообщение перенаправления,
где указывает, что IP-пакеты для узла 128.6.7.23 должны посылаться через шлюз
128.6.4.30. Модуль IP на машине-отправителе должен добавить запись в таблицу
маршрутов:
Таблица
18. Адрес назначения Флаг вида маршрутизации Шлюз Интерфейс 128.6.7.23 косвенная 128.6.4.30 pe0
Все последующие IP-пакеты для узла 128.6.7.23 будут
посланы прямо через указанный шлюз.
До сих пор мы рассматривали способы добавления
маршрутов в IP-таблицу, но не способы их исключения. Что случится, если шлюз
будет выключен? Хотелось бы иметь способ возврата к маршруту по умолчанию после
того, как какой-либо маршрут разрушен. Однако если шлюз вышел из строя или был
выключен, то он уже не может послать сообщение перенаправления. Поэтому должен
существовать метод определения работоспособности шлюзов, с которыми ваша машина
связана непосредственно. Лучший способ обнаружения неработающих шлюзов основан
на выявлении "плохих" маршрутов. Модуль TCP поддерживает различные
таймеры, которые помогают ему определить разрыв соединения. Когда случается
сбой, то можно пометить маршрут как "плохой" и вернуться к маршруту
по умолчанию. Аналогичный метод может использоваться при обработке ошибок шлюза
по умолчанию. Если два шлюза отмечены как шлюзы по умолчанию, то машина может
использовать их по очереди, переключаясь между ними при возникновении сбоев.
6.3.
Слежение за маршрутизацией
Заметим, что сообщения перенаправления не могут
использоваться самими шлюзами. Перенаправление - это просто способ оповещения
обычного узла о том, что нужно использовать другой шлюз. Сами шлюзы должны
иметь полную картину о положении дел в сети internet и уметь вычислять
оптимальные маршруты доступа к каждой подсети. Обычно они поддерживают эту
картину, обмениваясь информацией между собой. Для этой цели существуют
несколько специальных протоколов маршрутизации. Один из способов, с помощью
которого узлы могут определять действующие шлюзы, состоит в слежении за обменом
сообщениями между ними. Для большинства протоколов маршрутизации существует
программное обеспечение, позволяющее обычным узлам осуществлять такое слежение.
При этом на узлах поддерживается полная картина положения дел в сети internet
точно так же, как это делается в шлюзах. 
Динамическая корректировка таблицы маршрутов позволяет посылать
IP-пакеты по оптимальным маршрутам.
Таким образом, слежение за маршрутизацией в некотором
смысле "решает" проблему поддержания корректности таблиц маршрутов.
Однако существуют несколько причин, по которым этот метод применять не
рекомендуется. Наиболее серьезной проблемой является то, что протоколы
маршрутизации пока еще подвергаются частым пересмотрам и изменениям. Появляются
новые протоколы маршрутизации. Эти изменения должны учитываться в программном
обеспечении всех машин.
Несколько более специальная проблема связана с
бездисковыми рабочими станциями. По своей природе бездисковые машины сильно
зависят от сети и от файл-серверов, с которых они осуществляют загрузку
программ, и где располагается их область своппинга. Исполнение программ,
следящих за широковещательными передачами в сети, на бездисковых машинах
связано с большими трудностями. Протоколы маршрутизации построены в основном на
широковещательных передачах. Например, все сетевые шлюзы могут широковещательно
передавать содержание своих таблиц маршрутов через каждые 30 секунд. Программы,
которые следят за такими передачами, должны быть загружены на бездисковые
станции через сеть. На достаточно занятой машине программы, которые не
используются в течение нескольких секунд, обычно отправляются в область своппинга.
Поэтому программы, следящие за маршрутизацией, большую часть времени находятся
в своппинге. Когда они вновь активизируются, должна производиться подкачка из
своппинга. Как только посылается широковещательное сообщение, все машины
активизируют программы, следящие за маршрутизацией. Это приводит к тому, что
многие бездисковые станции будут выполнять подкачку из своппинга в одно и тоже
время. Поэтому в сети возникнет временная перегрузка. Таким образом, исполнение
программ, прослушивающих широковещательные передачи, на бездисковых рабочих
станциях очень нежелательно.
6.4.
Протокол ARP с представителем
Протокол ARP с представителем является альтернативным
методом, позволяющим шлюзам принимать все необходимые решения о маршрутизации.
Он применяется в сетях с широковещательной передачей, где для отображения
IP-адресов в сетевые адреса используется протокол ARP или ему подобный. Здесь
мы вновь будем предполагать, что имеем дело с сетью Ethernet.
Во многом метод, реализуемый протоколом ARP с
представителем, аналогичен использованию маршрутов по умолчанию и сообщений
перенаправления. Но протокол ARP с представителем не затрагивает таблиц
маршрутов, все делается на уровне адресов Ethernet. Протокол ARP с
представителем может использоваться либо для маршрутизации IP-пакетов ко всем
сетям, либо только в локальной сети, либо в какой-то комбинации подсетей. Проще
всего продемонстрировать его использование при работе со всеми адресами.
Чтобы использовать протокол, нужно настроить узел так,
будто все машины в мире подключены непосредственно к вашей локальной сети
Ethernet. В ОС UNIX это делается командой "route add default 128.6.4.2
0", где 128.6.4.2 - IP-адрес вашего узла. Как уже отмечалось, метрика 0
говорит о том, что все IP-пакеты, которым подходит данный маршрут, должны
посылаться напрямую по локальной сети.
Когда нужно послать IP-пакет узлу в локальной сети
Ethernet, ваша машина должна определить Ethernet-адрес этого узла. Для этого
она использует ARP-таблицу. Если в ARP-таблице уже есть запись, соответствующая
IP-адресу места назначения, то из нее просто берется Ethernet-адрес, и кадр,
содержащий IP-пакет, отправляется. Если такой записи нет, то посылается
широковещательный ARP-запрос. Узел с искомым IP-адресом назначения принимает
его и в ARP-ответе сообщает свой Ethernet-адрес. Эти действия соответствуют
обычному протоколу ARP, описанному выше.
Протокол ARP с представителем основан на том, что
шлюзы работают как представители удаленных узлов. Предположим, в подсети
128.6.5 имеется узел 128.6.5.2 (узел A). Он желает послать IP-пакет узлу
128.6.4.194, который подключен к другой сети Ethernet (узел B). Существует шлюз
с IP-адресом 128.6.5.1, соединяющий две подсети (шлюз R).
Если в ARP-таблице узла A нет маршрута доступа к узлу
B, то узел A посылает ARP-запрос узлу B. Фактически машина A спрашивает:
"Если кто-нибудь знает Ethernet-адрес узла 128.6.4.194, сообщите мне
его". Узел B не может ответить на запрос самостоятельно. Он подключен к
другой сети Ethernet и никогда даже не увидит этот 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, а он переправит его по назначению.
Заметим, что полученный эффект такой же, как если бы в
таблице маршрутов была запись
Таблица
19. Адрес назначения Флаг вида маршрутизации Шлюз Интерфейс 128.6.4.194 косвенная 128.6.5.1 pe0
за
исключением того, что маршрутизация выполняется на уровне модуля ARP, а не
модуля IP.
Обычно рекомендуется использовать таблицу маршрутов,
так как архитектура протоколов TCP/IP предусматривает выполнение маршрутизации
на межсетевом уровне. Однако иногда протокол ARP с представителем очень
полезен. Он может помочь в следующих случаях:
1)в IP-сети есть узел, который не умеет работать с
подсетями;
2)в IP-сети есть узел, который не может
соответствующим образом реагировать на сообщения перенаправления;
3)нежелательно выбирать какой-либо шлюз как маршрут по
умолчанию;
4)программное обеспечение не способно
восстанавливаться при сбоях на маршрутах.
Иногда протокол ARP с представителем выбирают из-за
удобства. Дело в том, что он упрощает работу по начальной установке таблицы
маршрутов. Даже в простейших IP-сетях требуется устанавливать маршрут по
умолчанию, то есть использовать команду типа "route add default ...", как в ОС UNIX. При изменении IP-адреса
шлюза эту команду приходится менять во всех узлах. Если же использовать
протокол ARP с представителем, т.е. в команде установки маршрута по умолчанию
указать метрику 0, то при замене IP-адреса шлюза команду начальной установки
менять не придется, так как протокол ARP с представителем не требует явного
задания IP-адресов шлюзов. Любой шлюз может ответить на ARP-запрос.
Для того, чтобы избавить пользователей от обязательной
начальной установки маршрутов, некоторые реализации TCP/IP используют протокол
ARP с представителем по умолчанию в тех случаях, когда не находят подходящих
записей в таблице маршрутов.
7. Протокол UDP
Протокол UDP (User Datagram Protocol - протокол
пользовательских датаграмм) является одним из двух основных протоколов,
расположенных непосредственно над IP. Он предоставляет прикладным процессам
транспортные услуги, которые не многим отличаются от услуг, предоставляемых
протоколом IP. Протокол UDP обеспечивает ненадежную доставку датаграмм и не
поддерживает соединений из конца в конец. К заголовку IP-пакета он добавляет
два поля, одно из которых, поле "порт", обеспечивает
мультиплексирование информации между разными прикладными процессами, а другое
поле - "контрольная сумма" - позволяет поддерживать целостность
данных.
Примерами сетевых приложений, использующих UDP,
являются NFS (Network File System - сетевая файловая система) и SNMP (Simple
Network Management Protocol - простой протокол управления сетью).
7.1. Порты
Взаимодействие между прикладными процессами и модулем
UDP осуществляется через UDP-порты. Порты нумеруются начиная с нуля. Прикладной
процесс, предоставляющий некоторые услуги другим прикладным процессам (сервер),
ожидает поступления сообщений в порт, специально выделенный для этих услуг.
Сообщения должны содержать запросы на предоставление услуг. Они отправляются
процессами-клиентами.
Например, сервер SNMP всегда ожидает поступлений
сообщений в порт 161. Если клиент SNMP желает получить услугу, он посылает
запрос в UDP-порт 161 на машину, где работает сервер. В каждом узле может быть
только один сервер SNMP, так как существует только один UDP-порт 161. Данный
номер порта является общеизвестным, то есть фиксированным номером, официально
выделенным для услуг SNMP. Общеизвестные номера определяются стандартами
Internet.
Данные, отправляемые прикладным процессом через модуль
UDP, достигают места назначения как единое целое. Например, если
процесс-отправитель производит 5 записей в UDP-порт, то процесс-получатель
должен будет сделать 5 чтений. Размер каждого записанного сообщения будет
совпадать с размером каждого прочитанного. Протокол UDP сохраняет границы
сообщений, определяемые прикладным процессом. Он никогда не объединяет
несколько сообщений в одно и не делит одно сообщение на части.
7.2.
Контрольное суммирование
Когда модуль UDP получает датаграмму от модуля IP, он
проверяет контрольную сумму, содержащуюся в ее заголовке. Если контрольная
сумма равна нулю, то это означает, что отправитель датаграммы ее не
подсчитывал, и, следовательно, ее нужно игнорировать. Если два модуля UDP
взаимодействуют только через одну сеть Ethernet, то от контрольного
суммирования можно отказаться, так как средства Ethernet обеспечивают
достаточную степень надежности обнаружения ошибок передачи. Это снижает
накладные расходы, связанные с работой UDP. Однако рекомендуется всегда
выполнять контрольное суммирование, так как возможно в какой-то момент
изменения в таблице маршрутов приведут к тому, что датаграммы будут посылаться
через менее надежную среду.
Если контрольная сумма правильная (или равна нулю), то
проверяется порт назначения, указанный в заголовке датаграммы. Если к этому
порту подключен прикладной процесс, то прикладное сообщение, содержащееся в
датаграмме, становится в очередь для прочтения. В остальных случаях датаграмма
отбрасывается. Если датаграммы поступают быстрее, чем их успевает обрабатывать
прикладной процесс, то при переполнении очереди сообщений поступающие датаграммы
отбрасываются модулем UDP.
8. Протокол TCP
Протокол TCP предоставляет транспортные услуги,
отличающиеся от услуг UDP. Вместо ненадежной доставки датаграмм без
установления соединений, он обеспечивает гарантированную доставку с
установлением соединений в виде байтовых потоков.
Протокол TCP используется в тех случаях, когда
требуется надежная доставка сообщений. Он освобождает прикладные процессы от
необходимости использовать таймауты и повторные передачи для обеспечения
надежности. Наиболее типичными прикладными процессами, использующими TCP,
являются FTP (File Transfer Protocol - протокол передачи файлов) и TELNET.
Кроме того, TCP используют система X-Window, rcp (remote copy - удаленное
копирование) и другие "r-команды". Большие возможности TCP даются не
бесплатно. Реализация TCP требует большой производительности процессора и
большой пропускной способности сети. Внутренняя структура модуля TCP гораздо
сложнее структуры модуля UDP.
Прикладные процессы взаимодействуют с модулем TCP
через порты. Для отдельных приложений выделяются общеизвестные номера портов.
Например, сервер TELNET использует порт номер 23. Клиент TELNET может получать
услуги от сервера, если установит соединение с TCP-портом 23 на его машине.
Когда прикладной процесс начинает использовать TCP, то
модуль TCP на машине клиента и модуль TCP на машине сервера начинают общаться.
Эти два оконечных модуля TCP поддерживают информацию о состоянии соединения,
называемого виртуальным каналом. Этот виртуальный канал потребляет ресурсы
обоих оконечных модулей TCP. Канал является дуплексным; данные могут
одновременно передаваться в обоих направлениях. Один прикладной процесс пишет
данные в TCP-порт, они проходят по сети, и другой прикладной процесс читает их
из своего TCP-порта.
Протокол TCP разбивает поток байт на пакеты; он не
сохраняет границ между записями. Например, если один прикладной процесс делает
5 записей в TCP-порт, то прикладной процесс на другом конце виртуального канала
может выполнить 10 чтений для того, чтобы получить все данные. Но этот же
процесс может получить все данные сразу, сделав только одну операцию чтения. Не
существует зависимости между числом и размером записываемых сообщений с одной
стороны и числом и размером считываемых сообщений с другой стороны.
Протокол TCP требует, чтобы все отправленные данные
были подтверждены принявшей их стороной. Он использует таймауты и повторные
передачи для обеспечения надежной доставки. Отправителю разрешается передавать
некоторое количество данных, не дожидаясь подтверждения приема ранее отправленных
данных. Таким образом, между отправленными и подтвержденными данными существует
окно уже отправленных, но еще неподтвержденных данных. Количество байт, которые
можно передавать без подтверждения, называется размером окна. Как правило,
размер окна устанавливается в стартовых файлах сетевого программного
обеспечения. Так как TCP-канал является дуплексным, то подтверждения для
данных, идущих в одном направлении, могут передаваться вместе с данными,
идущими в противоположном направлении. Приемники на обеих сторонах виртуального
канала выполняют управление потоком передаваемых данных для того, чтобы не
допускать переполнения буферов.
9. Протоколы прикладного уровня
Почему существуют два транспортных протокола TCP и
UDP, а не один из них? Дело в том, что они предоставляют разные услуги
прикладным процессам. Большинство прикладных программ пользуются только одним
из них. Вы выбираете тот протокол, который наилучшим образом соответствует
вашим потребностям. Если вам нужна надежная доставка, то лучшим может быть TCP.
Если вам нужна доставка датаграмм, то лучше может быть UDP. Если вам нужна
эффективная доставка по длинному и ненадежному каналу передачи данных, то лучше
может подойти протокол TCP. Если нужна эффективность на быстрых сетях с
короткими соединениями, то лучшим может быть протокол UDP. Если ваши
потребности не попадают ни в одну из этих категорий, то выбор транспортного
протокола не ясен. Однако прикладные программы могут устранять недостатки
выбранного протокола. Например, если вы выбрали UDP, а вам необходима
надежность, то прикладная программа должна обеспечить надежность. Если вы
выбрали TCP, а вам нужно передавать записи, то прикладная программа должна
вставлять маркеры в поток байтов так, чтобы можно было различить записи.
Какие же прикладные программы доступны в сетях с
TCP/IP? Общее их количество велико и продолжает постоянно увеличиваться.
Некоторые приложения существуют с самого начала развития internet. Например,
TELNET и FTP.
Протоколы прикладного уровня ориентированы на
конкретные прикладные задачи. Они определяют как процедуры по организации
взаимодействия определенного типа между прикладными процессами, так и форму
представления информации при таком взаимодействии. В этом разделе мы коротко
опишем некоторые из прикладных протоколов.
9.1.
Протокол TELNET
Протокол TELNET позволяет обслуживающей машине
рассматривать все удаленные терминалы как стандартные "сетевые виртуальные
терминалы" строчного типа, работающие в коде ASCII, а также обеспечивает
возможность согласования более сложных функций (например, локальный или
удаленный эхо-контроль, страничный режим, высота и ширина экрана и т.д.) TELNET
работает на базе протокола TCP. На прикладном уровне над TELNET находится либо
программа поддержки реального терминала (на стороне пользователя), либо
прикладной процесс в обсуживающей машине, к которому осуществляется доступ с
терминала.
Работа с TELNET походит на набор телефонного номера.
Пользователь набирает на клавиатуре что-то вроде telnet delta и получает
на экране приглашение на вход в машину delta.
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.
Протокол SNMP
Протокол SNMP (Simple Network Management Protocol -
простой протокол управления сетью) работает на базе UDP и предназначен для
использования сетевыми управляющими станциями. Он позволяет управляющим
станциям собирать информацию о положении дел в сети internet. Протокол
определяет формат данных, их обработка и интерпретация остаются на усмотрение
управляющих станций или менеджера сети.
10. Взаимозависимость протоколов семейства TCP/IP
В табл. 20 представлена схема взаимосвязей между
протоколами семейства TCP/IP.
Таблица
20. Прикладной уровень FTP TELNET SMTP <нет> TFTP DNS Сл. времени Эхо Транспортный уровень TCP GGP HMP EGP UDP Межсетевой уровень IP/ICMP Сетевой уровень Локальные сети ARPANET SATNET Пакетная радиосеть
11. Список использованной литературы
1)Ежемесячный журнал CHIP
2)Ежемесячный журнал “Компьютерное обозрение”.
3)Лекции спецкурса “Операционные системы
рефераты Рекомендуем рефератырефераты

     
Рефераты @2011