Хезер Остерлох

TCP/IP

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

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

( Е книга-почтой f -магазин ]
www. diasoft. kiev. ua

S/iMS

PUBLISHING

ТЛИ издательство

Г DiaSoft
Хезер Остерлох

TCP/IP.

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

Под научной редакцией член-корр.
Украинской Академии Информатики
Алишова Н.И.

ТТТШ| торгов©-издательский дом

DiaSoft
Primer Plus

Heather Osterloh

sAms

201 West 103rd., Indianapolis, Indiana, 46290 Usa
Семейство протоколов
передачи данных в
сетях компьютеров

Хезер Остерлох
УДК 681.3. 06(075)

ББК 32.973.2

021

ОСТЕРЛОХ ХЕЗЕР

О 21 TCP/IP. Семейство протоколов передачи данных в сетях компьютеров: Пер. с
англ./Хезер Остерлох — СПб.: ООО «ДиаСофтЮП», 2002. — 576 с.

ISBN 5-93772-039-3

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

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

ББК 32.973.2

Authorized translation from the English language edition, entitled TCP/IP Primer Plus, 1st Edition by
Osterloh, Heather, published by Pearson Education, Inc. publishing as Sams,

Copyright © 2002

AH rights reserved. No part of this book may be reproduced or transmitted in any form or by any
means, electronic or mechanical, including photocopying, recording or by any information storage
retrieval system, without pennission from Pearson Education, Inc.

Russian language edition published by DiaSoft Publishing.

Copyright © 2002

Лицензия предоставлена издательством Sams.

Все права зарезервированы, включая право на полное или частичное воспроизведение в какой бы
то ни было форме.

ISBN 5-93772-039-3 (рус.)	© Перевод на русский язык. ООО «ДиаСофтЮП», 2002

ISBN 0-672-32208-0 (англ.) © Sams. 2002

© Оформление. ООО «ДиаСофтЮП», 2002

Гигиеническое заключение № 77.99.6.953.П.438.2.99 от 04.02.1999
Оглавление

Об авторе.................................................................15

Глава 1. Обзор моделей и стандартов сетевых технологий....................18

Обзор эталонной модели OSI............................................... 18

Обзор модели DoD ..........................................................21

Преимущества семиуровневой архитектуры модели OSI.........................22

Разграничение функций различных уровней модели OSI.....................22

Модель OSI как основа для разработки программных продуктов и оборудования ... 23

Упрощенный подход к поиску и локализации неисправностей................23

Поддержка принципа узкой специализации.................................24

Краткая характеристика уровней модели OSI.................................24

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

Уровень представления..................................................27

Сеансовый уровень......................................................28

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

Сетевой уровень........................................................30

Канальный уровень......................................................31

Физический уровень .....................................................32

Архитектура канального уровня и различные сетевые топологии...............32

Ethernet и IEEE 802.3................................................. 33

Slow Ethernet..........................................................39

Fast Ethernet..........................................................  41

Gigabit Ethernet .......................................................41

Token-Ring и IEEE 802.5 ............................................... 42

FDDI и ANSI X3T9.5.....................................................45

Технологии организации глобальных сетей (WAN).............................46

Протоколы инкапсуляции данных при передаче по глобальной сети..........49

Запросы на комментарии (RFC)..............................................51

Интернет и интранет.......................................................52

Организации, отвечающие за разработку Интернет-технологий.................52

Резюме....................................................................53

Вопросы для повторения...................................................53

Глава 2. IP-адресация.....................................................54

Преобразование из двоичной системы счисления в десятичную.................54

IP-адресация..............................................................55

Классы адресов ........................................................ 56

Сеть и маска подсети ...................................................61

Выделение подсетей (примеры)...........................................  66

Трансляция сетевых адресов (NAT)..........................................78

Статическая трансляция адресов.........................................80

Динамическая трансляция адресов.........................................80

Резюме....................................................................81

Вопросы для повторения................................................... 82
Глава 3. Протоколы сете ого уровня/Протоколы Интернета ..................83

Протокол Интернета (IP протокол).........................................83

Заголовок дейтаграммы IP...............................................85

Протокол управляющих сообщений Интернета (ICMP) .........................98

Заголовок и формат ICMP сообщений.......................................100

Поле кодов............................................................100

Поле контрольной суммы................................................102

Типы сообщений ICMP.....................................................102

Ping: эхо-запрос и эхо-ответ (типы 8 и	0)...........................  103

Недостижимый пункт назначения (тип	3).............................104

Подавление источника (тип 4)..........................................108

Перенаправление (тип 5)...............................................108

Запрос маршрутизатора (о регистрации) и информация от маршрутизатора
(о регистрации) (типы 9 и 10)......................................110

Время превышено (тип 11).............................................110

Проблема с параметрами (тип 12).......................................112

Запрос и ответ о временной метке (тип 13 и 14)........................112

Информационный запрос и ответ (тип 15 и 16)...........................113

Запрос и ответ о маске адреса (тип 17 и 18)...........................113

Резюме..................................................................113

Вопросы для повторения..................................................114

Глава 4. Разрешение адресов............................................ 115

Протокол ARP............................................................116

Действие протокола ARP................................................117

Механизм внесения изменений в таблицу ARP.............................121

Прокси ARP..............................................................122

Действие прокси ARP............................................   .	. . 122

Заголовок ARP...........................................................123

Поле типа (локальной) сети............................................125

Поле типа протокола...................................................125

Поле длины аппаратного адреса.........................................J26

Поле длины адреса верхнего уровня.....................................126

Поле кода сообщения...................................................126

Поле аппаратного адреса отправителя...................................127

Поле адреса верхнего уровня (IP-адреса) отправителя...................127

Поле аппаратного адреса получателя ...................................127

Поле адреса верхнего уровня (IP-адреса) получателя..................  127

Протокол RARP...........................................................127

Действие протокола RARP.................................................128

Сравнительная характеристика протоколов ARP и RARP....................129

Недостатки протокола RARP.............................................131

Заголовок RaRP..........................................................131

Поле типа (локальной) сети............................................131

Поле типа протокола...................................................131

Поле длины аппаратного адреса.........................................132

Поле длины адреса верхнего уровня............................... ..	132

Поле кода сообщения...................................................132

Поле аппаратного адреса отправителя...................................132
Поле адреса верхнего уровня (IP-адреса) отправителя..................132

Поле аппаратного адреса получателя...................................133

Поле адреса верхнего уровня (IP-адреса) получателя...................133

Протокол ВООТР .........................................................133

Заголовок ВООТР......................................................135

Запрос и ответ ВООТР.................................................139

Протокол DHCP (протокол динамического конфигурирования хостов)..........139

Предоставление хостам конфигурационной информации....................141

Сообщения DHCP.......................................................142

Обмен сообщениями между клиентами и серверами DHCP...................143

Заголовок DHCP.......................................................152

Резюме..................................................................155

Вопросы для повторения..................................................156

Глава 5. 1Р-маршрутизация ............................................. 157

Основы 1Р-маршрутизации.................................................157

Непосредственное сопряжение маршрутизатора с сетью назначения .......158

Статическая маршрутизация............................................158

Маршрутизация по умолчанию...........................................160

Динамическая маршрутизация...........................................161

Протоколы маршрутизации и выбор наилучшего пути.........................162

Дистанционно-векторные протоколы маршрутизации.......................162

Протоколы маршрутизации по состоянию каналов связи...................167

Протоколы маршрутизации смешанного типа..............................169

Резюме..................................................................170

Вопросы для повторения..................................................171

Главаб. Протоколы маршрутизации ....................................... 173

Общая характеристика протоколов маршрутизации...........................173

Протоколы RIP...........................................................174

Протокол RIPvl.......................................................175

Формат и поля заголовка протокола RIPvl..............................179

Недостатки протокола RIPvl .......................................   181

Таймеры, обслуживающие протокол RIP..................................186

Протокол RIP и каналы связи, выделяемые по требованию................187

Протокол RIPv2 ......................................................190

Протокол OSPF...........................................................192

Характеристики протокола OSPF....................................... 194

Базы данных протокола OSPF...........................................196

Действие протокола OSPF..............................................197

Заголовок LSA........................................................202

Состояния маршрутизаторов OSPF.......................................204

Типы маршрутизаторов OSPF............................................209

Функционирование OSPF в сетях с различной архитектурой ............  211

Типы областей........................................................214

Стандартные поля протокола OSPF......................................217

Дополнительные заголовки.............................................219

Протокол IGRP.......................................................... 226

Сети, работающие под управлением протокола IGRP .	  228

Протокол EIGRP..........................................................230
Действие протокола EIGRP.............................................231

Типы пакетов EIGRP...................................................233

Протокол BGP............................................................235

Сравнительная характеристика протоколов категории IGP и EGP..........236

Маршрутизаторы BGP.................................................. 238

Действие протокола BGP...............................................239

Заголовок BGP и его поля............................................ 240

Атрибуты путей.......................................................245

Сравнительная характеристика протоколов BGPv3 и BGPv4................247

Резюме..................................................................248

Вопросы для повторения.................................................251

Глава?. Транспортный/межхостовый уровень................................253

Протоколы транспортного уровня .........................................253

Протоколы, ориентированные на соединение.............................255

Протоколы, не ориентированные на соединение..........................257

Сравнение ориентированных и не ориентированных на соединение протоколов ... 257

Порты и сокеты.......................................................258

Резюме..................................................................260

Вопросы для повторения..................................................261

Глава 8. Протокол управления передачей (TCP)............................262

Краткая характеристика TCP..............................................262

Заголовок TCP ..........................................................263

Поле порта отправителя...............................................264

Поле порта получателя................................................264

Поле порядкового номера ..........................................   265

Поле номера подтверждения............................................265

Поле смещения данных.................................................267

Зарезервированное поле ..............................................267

Поле управляющих флагов (6 битов)....................................267

Поле окна............................................................269

Поле контрольной суммы (2 байта) ................................... 269

Поле указателя срочности.............................................269

Дополнительные параметры TCP (переменная длина)......................270

Основные механизмы протокола TCP........................................270

Установление и закрытие соединения...................................271

Мультиплексирование..................................................272

Передача данных......................................................273

Управление потоком...................................................274

Надежность...........................................................275

Приоритет и защита данных............................................275

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

Установление сеанса связи............................................277

Образование пар сокетов..............................................278

Завершение сеанса связи..............................................283

Упорядочивание и подтверждение кадров................................286

Поддержание соединения активным......................................291

Управление потоком...................................................292

Порты TCP...............................................................295
Резюме .................................................................296

Вопросы для повтсренг.я .	...	.... ......	........	. 297

Глава 9. Протокол передачи пользовательских дейтаграмм (UDP)... 298

Действие протокола	UDP	..	       299

Использование UDP приложениями верхнего уровня.......................300

Порты UDP...............................................................301

Заголовок UDP...........................................................301

Поле порта отправителя...............................................302

Поле порта получателя................................................303

Поле длины дейтаграммы...............................................303

Поле контрольной суммы...............................................303

Резюме ................................................................ 304

Вопросы для повторения.................................................305

Глава 10. Протоколы верхнего уровня ....................................306

Краткая характеристика протоколов верхних уровней.......................306

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

Всемирная "паутина" (World Wide Web — WWW) и протокол передачи
гипертекста HTTP..................................................309

Электронная почта и упрощенный протокол электронной почты (SMTP).....309

Telnet (Служба взаимодействия с удаленными терминалами)..............310

Передача файлов......................................................310

Уровень представления ...	..	................ ... .................. 311

Сеансовый уровень.....................................................  312

NetBIOS (Сетевая базовая система ввода — вывода)........................313

NFS (Сетевая файловая система) и протоколы ONC.......................   314

Резюме..................................................................314

Вопросы для повторения .. .......................................   ....315

Глава 11. Telnet........................................................316

Удаленный доступ......................................................  316

Базовые службы Telnet..............................................   —	-318

Сетевой виртуальный терминал ......................................  319

Обмен информацией через NVT посредством кода ASCII...................319

Команды Telnet ......................................................321

Параметры Telnet.....................................................324

Резюме..................................................................327

Вопросы для повторения.................................................328

Глава 12. Протокол передачи файлов (FTP)................................329

Краткая характеристика протокола FTP....................................329

Сеанс FTP...............................................................331

Представление данных....................................................333

Типы данных FTP ................................................... .336

Структуры данных FTP ....... ...	. .	.................. . 338

Режимы передачи данных FTP...........................................339

Команды FTP.............................................................339

Ответы FTP..............................................................341

Действие протокола FTP..................................................343

Анонимный доступ к FTP	      ..344
Резюме................................................................345

Вопросы для повторения................................................346

Глава 13. Упрощенный протокол электронной почты (SMTP)...............347

Модель именования стандарта Х.400.....................................349

Агенты передачи сообщений (МТА).....................................351

Формат сообщений SMTP.................................................352

Команды SMTP..........................................................354

Ответы SMTP...........................................................355

MIME..................................................................357

Резюме................................................................358

Вопросы для повторения................................................359

Глава 14. Разрешение имен.............................................360

Назначение процедуры разрешения имен..................................360

Пространство имен...................................................361

Делегирование полномочий DNS..........................................364

Имена доменов Интернета.............................................367

Запросы на разрешение имен и таблицы отображения имен в IP-адреса.....368

Кэширование...........................................................368

Формат сообщений сервера доменных имен................................369

Поле идентификатора (ID)............................................369

Поле флага запроса или ответа (QR)..................................370

Поле типа операции (запроса или ответа).............................370

Поле флагов.........................................................370

Поле кода ответа....................................................371

Заголовки запросов и ответов........................................372

Типы доменных имен..................................................373

Примеры работы DNS....................................................374

NetBios...............................................................377

Функционирование NetBIOS на базе стека протоколов TCP/IP............379

Различные методы разрешения имен в NetBIOS..........................381

WINS (Сервер имен сети Интернет для Windows)......................  383

Примеры работы NetBIOS..............................................384

Резюме ...............................................................385

Вопросы для повторения................................................386

Глава 15. Протокол передачи гипертекстовых файлов (HTTP).............387

HTTP и WWW............................................................387

Характеристики HTTP...................................................388

Компоненты HTTP ..................................................... 389

Сеансы HTTP...........................................................390

Формат сообщений HTTP...............................................392

Общий формат начальной строки.......................................392

Общий заголовок сообщений HTTP......................................393

Заголовки сообщений HTTP (заголовок запроса HTTP, заголовок ответа HTTP и

заголовок объектов HTTP) ........................................395

Пустая строка (CRLF)..............................................  396

Тело сообщения.....................................................,397

Ответы HTTP, коды состояния и ошибок..................................397
Сообщения об ошибках HTTP...........................................398

Резюме..............................................................399

Вопросы для повторения..............................................400

Глава 16. Простейший протокол передачи файлов (TFTP)...............401

Краткая характеристика протокола TFTP.............................. 401

Типы пакетов TFTP...................................................402

Пакеты RRQ и WRQ ................................................ 403

Пакеты Data (Данные)..............................................404

Пакет АСК (подтверждение)........................................ 404

Пакеты Error (Ошибка)...........................................  405

Действие TFTP.......................................................406

Расширения TFTP.....................................................407

Пакет ОАСК........................................................409

Резюме..............................................................410

Вопросы для повторения............................................  410

Глава 17. SNMP (Простой протокол управления сетью)..................411

Сетевое администрирование....................................... 	- 411

Протокол SNMP ......................................................413

Диспетчеры SNMP...................................................413

Агенты SNMP...................................................... 414

Прокси-агенты SNMP................................................415

Формат сообщений SNMP........................... .	...............416

Поле версии.......................................................417

Поле имени ассоциации............................................ 417

Поле модулей данных протокола SNMP (PDU)........................  417

Резюме..............................................................419

Вопросы для повторения..............................................419

Глава 18. Протоколы открытой сетевой обработки данных...............420

Краткая характеристика протоколов ONC ............................  420

Основные характеристики NFS.......................................  421

Действие NFS........................................................423

Клиент NFS........................................................424

Сервер NFS........................................................426

Внешнее представление данных (XDR)..................................428

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

Формат сообщения RPC, содержащего запрос на вызов процедуры.......430

Сообщение, содержащее ответ на запрос о вызове процедуры .........435

Примеры работы протокола NFS........................................436

Резюме..............................................................438

Вопросы для повторения............................................. 438

Приложение А. Запросы на комментарии (RFC) по главам................439

Приложение В. Список аббревиатур....................................484

Приложение С. Номера портов TCP/UDP ................................491

Приложение D. Глоссарий.............................................492

Приложение Е. Ответы на вопросы.....................................534

Предметный указатель................................................564
ОТ НАУЧНОГО РЕДАКТОРА

Компьютерные сети представляют собой организационные и аппаратно-программ-
ные средства, позволяющие удаленным пользователям иметь санкционированный дос-
туп к распределенным информационным ресурсам. Необходимость массового внедре-
ния сетей компьютеров обуславливает унификацию средств и технологий для
обеспечения их совместимости. С этой целью в начале 70-х годов министерством обо-
роны США была разработана коммуникационная модель взаимодействия между разно-
типными вычислительными системами (модель DoD). Модель DoD, получившая на
начальном этапе достаточно широкое распространение, в начале 80-х годов почти пол-
ностью уступила место разработанной Международной организацией по стандартиза-
ции эталонной модели взаимодействия открытых систем (модель OSI/ISO). Основная
концепция разработки эгих моделей заключалась в обеспечении инвариантности тех-
нологий взаимодействия сетевых средств относительно аппаратно-программной плат-
формы различных производителей компьютерных и телекоммуникационных средств.
При этом основное внимание уделялось выделению в отдельные уровни тех сетевых
функций, которые относятся к задачам транспортировки данных. Созданный на базе
модели DoD проект объединения локальных сетей в единый сетевой комплекс
("INTERNETting Project") позволил создать компьютерную ceTbARPANet, которая счи-
тается прародителем современной INTERNET. В сети ARPANet в качестве транспорт-
ного протокола передачи данных был разработан Transmission Control Protocol (прото-
кол управления передачей данных) для обеспечения надежной передачи данных между
удаленными хостами, взаимодействующими между собой в сетях с коммутацией пакетов.
Сразу же после создания TCP этот протокол совместно с протоколом 1Р стал стандарт-
ным протоколом Интернета. Эти обстоятельства были учтены автором данной книги и
по этой причине уделено внимание соответствию отдельных протоколов транспортиров-
ки данных к уровням моделей DoD и OSI/ISO.

Содержание книги условно можно разбить на следующие тематические части.

Глава / является введением к многоуровневой организации межсетевого взаимодей-
ствия на базе эталонных моделей DoD и OSI/ISO. Здесь рассматриваются базовые кон-
цептуальные характеристики семиуровневой модели взаимодействия открытых систем,
а также описываются функциональные возможности отдельных уровней. Учитывая то.
что основными подсистемами современных корпоративных и глобальных сетей компь-
ютеров являются локальные сети, в первой главе автор подробно излагает архитектуру
и характеристики функционирования таких распространенных локатьных сетей как
Ethernet, Token Ring и FDD1. Завершается первая глава описанием базовых функций
глобальных сетей.

Вторая часть посвящена описанию собственно протоколов транспортировки дан-
ных TCP и IP (главы № 2. 3, 7, 8, 9). Поскольку IP-адресация является основным
механизмом поиска сетевых узлов в Интернете, для тех читателей, которые желают
разобраться в форматах адресации, во второй главе автор описывает алгоритмы двоич-
но-десятичного преобразования. Это необходимо, так как адреса и маски подсетей вы-
числяются в двоичной системе счисления. В этой же главе достаточно подробно излага-
ются способы выделения подсетей, их масок и диапазонов адресов. В третьей главе
рассматриваются действия протокола IP, его функции и ноля дейтаграммы 1Р, фрагмен-
тация и сборка дейтаграмм, а также сообщения протокола 1СМР и их значения. В гла-
вах 7, 8 и 9 описаны характеристики функционирования и форматы пакетов данных
транспортных протоколов TCP и UDP.

Третий тематический раздел книги посвяшен описанию технологий и алгоритмов
протоколов маршрутизации (главы 5, 6). В пятой главе рассмотрены основные принци-
пы маршрутизации и приведены подробные описания таких классических методов как
статическая, динамическая и дистанционно-векторная маршрутизация, а также описа-
ния методов маршрутизации по состоянию канала и по умолчанию. В шестой главе
приводится подробное описание всех основных протоколов маршрутизации, применяе-
мых в Интернете и других сетях компьютеров массового пользования.

Главы 4 и 14 содержат материалы, описывающие механизмы и протоколы определе-
ния искомых адресов, идентифицирующих сетевые узлы. Рассматриваются три типа
адресов: IP-адрес, аппаратный (физический) адрес и имя хоста. В этих главах подробно
излагаются функции протоколов, обеспечивающие возможность взаимнооднозначного
преобразования этих адресов (определение одного вида адреса по заданному другому
виду адреса).

Наконец, в главах 10-13 и 15-18 приводятся материалы, касающиеся функциониро-
ванию протоколов верхних уровней. Особое внимание удаляется протоколам приклад-
ного уровня, ставшим де-факго международными стандартами. К этим протоколам от-
носятся: протоколы управления передачей файлов (FTP, TFTP, NFS — главы 12, 16, 18),
протоколы передачи электронной почты (SMTP, MIME — глава 13), протокол агента
сетевого управления и мониторинга (SNMP — глава 17) и, наконец, протокол передачи
гипертекстовых файлов (HTTP — глава 15). В главе 18 изложена основная концепция
открытой сетевой обработки компании Sun Microsystems, которая образуется тандемом
сетевой файловой системы (NFS), протоколом внешнего представления данных (XDR)
и удаленным вызовом процедур (RPC).

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

В целом книга предназначается для широкого круга читателей: от новичков, желаю-
щих приумножить свои знания в области Интернет-технологий, до профессиональных
разработчиков сетевых технологий. Содержание книги и упрощенный стиль изложения
достаточно сложных функциональных характеристик протоколов транспортировки дан-
ных позволяют всем читателям использовать данную книгу в качестве настольной. А для
тех, кто желает ознакомиться с отдельными разделами, рекомендую следующую схему
изучения (см. след. стр.).

Научный редактор

Ч 1ен-корр. Украинской Академии Информатики
Надир Алшиов
Новички и любознательные в Интернете 						Студенты и аспиранты	Системные администра торы	Интернет- провайдеры	Добропорядо чные хакеры	Разработчики сетевых технологий 	,	и

г

i ЕМЛТИЧЕСКИЕ РАЗДЕЛЫ КНИГИ

Пользова тельские
протоколы

От научного редактора

►Глава 1  ►Глава 2	Обзор моделей и стандартов сетевых технологий 1Р-адресация	Глава 1  Глава 2
►Глава 3	Протоколы сетевого уровня/Протоколы Интернета	Глава 3
-►Глава 4	Разрешение адресов	Глава 4
-►Глава 5	1Р-маршрутизаиия	Глава 5
-►Глава 6	Протоколы маршрутизации	Глава 6
-►Глава 7	Транспортный/межхостовый уровень	Глава 7
►Глава 8	Протокол управления передачей (TCP)	Глава 8
Глава 9	Протокол передачи пользовательских дейтаграмм	Глава 9
-►Глава 10	Протоколы верхнего уровня	Глава 10
-►Глава И	Telnet	Глава 11
► Глава 12	Протокол передачи файлов (FTP)	Глава 12
Глава 13	Упрощенный протокол электронной почты (SMTP)	Глава 13
-►Глава 14	Разрешение имен	Глава 14
-►Глава 15	Протокол передачи гипертекстовых файлов	Глава 15
► Глава 16	Простейший протокол передачи файлов (TFTP)	Глава 16
•►Глава 17	SNMP (Простой протокол управления сетью)	Глава 17
► Глава 18	Протоколы открытой сетевой обработки данных	Глава 18

Протоколы
маршрутизации

Протоколы
транспортировки

Адресные
протоколы
□6 авторе

Хезер Остерлох (Heather Osterloh) снискала всеобщее признание в качестве ведуще-
го специалиста в сфере информационных технологий. Хезер получила соответствующие
сертификаты после сдачи ряда экзаменов: CCNA — Cisco Certified Network Associate;
CCNP — Cisco Certified Network Professional; CCDA — Cisco Certified Design Professional;
CNX — Certified Network Expert; CNI/ECNE — Novell, MCSE — Microsoft Certified System
Engineer; MCT — Microsoft Certified Trainer. Хезер Остерлох сдала также письменную
часть экзамена CCIE (Cisco Certified Internetworking Expert) и ожидает сдачи практичес-
кой лабораторной части этого экзамена.

Хезер Остерлох посвятила 15 лет своей жизни преподавательской и консультацион-
ной работе по обучению специалистов-сетевиков во всем мире и является признанным
лидером в сфере информационных технологий. Хезер Остерлох является автором од-
ной книги, CCNA 2.0 Prep Kit 640-507 Routing and Switching, а также ряда популярных
(особенно среди профессионалов, страдающих от нехватки времени) видео курсов по
программным продуктам компаний Microsoft, Cisco и Novell. Автор продолжает писать
книги, которые оказывают существенную помощь в подготовке специалистов, занима-
ющихся организацией и обслуживанием вычислительных сетей.

Помимо перечисленных выше видов деятельности, Хезер Остерлох также читала
лекции в Калифорнийском университете (University of California) в Беркли (Berkley), в
Пуэрториканском университете (University of Puerto Rico), а также на конференции
пользователей NetWare (NetuCon's NetWare User) в Сан-Хосе (San Jose). На протяже-
нии трех лет Хезер Остерлох была президентом Академии информационных техноло-
гий (IT Academy).

Хезер Остерлох живет в Северной Калифорнии (Nothem California) вместе со своим
мужем Кэрком и собачками, Коко и Като.

Посвящение

Книга посвящается памяти моего дедушки, Энтони, и моей бабушки, Нины.

Благодарности

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

Прежде всего, я хотела бы поблагодарить компанию Sams Publishing за предостав-
ленную мне возможность написать эту книгу. Особую благодарность хочу выразить тем
сотрудникам компании, которые сделали возможным выход книги в свет, в частности —
Вильяму Брауну (William Brown), Марку Ренфроу (Mark Renfrow), Кристине Смит
(Christina Smith). Рейчел Белл (Rachel Bell), Кипп Джаретт (Kitty Jarrett) и Мишелю
Трумену (Michelle Truman). Все эти люди сделали намного больше, чем входило в их
обязанности, чтобы поддержать меня и мою работу.

Особой благодарности заслуживают также необыкновенные люди, входящие в состав
моего коллектива — Джейсон Бьюрита (Jason Burita) и Кристин Сепиол (Christine Sepiol).
Эти люди помогали мне сосредоточить все мои усилия на написании книги, а также
сделать из черновых набросков пригодный для публикации текст.

Выражаю свою благодарность коллективу Академии информационных технологий (IT
Academy) — Хейди (Heidi), Беверли (Beverly) и Брайсу (Bryce): без их поддержки реа-
лизация данного проекта была бы невозможной.

Особую благодарность выражаю Лоре Чеппел (Laura Chappell), которая первой вве-
ла меня в мир сетевой сертификации и вдохновила на сдачу столь серьезных экзаменов.

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

Благодарю своих родителей, Риту (Rita) и Карла (Karl), которые всегда оказывают
мне всестороннюю поддержку.

Не хочу оставить без внимания и своих собак, Коко и Като, которые прыгали мне
на колени, вынуждая меня тем самым сделать такой необходимый перерыв во время ра-
боты над книгой: это вносило небольшое забавное разнообразие в мою работу и помо-
гало немного расслабиться.

И, наконец, — самая большая благодарность самому важному человеку в моей жиз-
ни: моему мужу Керку (Kirk) — за его бесконечное терпение во время овладевавших мной
на заключительном этапе написания книги приступов паники, связанных с истечением
предельного срока завершения работы над книгой. Его неизменная поддержка согрева-
ет мне душу и позволяет мне быть уверенной в том, что я могу достичь любой постав-
ленной цели. Спасибо, дорогой.

Предисловие

Как-то Франц Кафка написал: "Предназначение книги заключается в том, чтобы
разрушить сковывающие душу человека льды ". Данная книга поможет вам избавиться
от той сложности и неопределенности, которая сопутствует изучению информационных
технологий вообще и мира TCP/IP в частности. В конечном итоге, TCP/IP — это не наука
о ракетах, а всего лишь несколько маршрутизаторов, клавиатур, персональных компь-
ютеров, а также ряд протоколов, которые заставляют все это работать или (в некоторых
случаях) — не работать. Представленных в данной книге сведений вполне достаточно
для того, чтобы без груда разобраться в принципах работы стека протоколов TCP/IP и тем
самым полностью исключить затруднения, связанные с организацией и эксплуатацией
вычислительных сетей.

Изложенный в данной книге материал раскрывается последовательно, согласно ло-
гической структуре моделей OSI и DoD. В самом начале книги представлены базовые
сведения об организации моделей OSI и DoD с подробным анализом канального и фи-
зического уровней. Далее рассматриваются протоколы, обслуживающие различные уров-
ни эталонной модели взаимодействия открытых систем (OSI). Подобная организация
книги позволяет хорошо изучить основные протоколы, входящие в состав стека прото-
колов TCP/IP. В то же время данную книгу можно изучать и не в том порядке, в кото-
ром изложен материал, а по мере заинтересованности читателя в той или иной теме.
Наличие в каждой главе ссылок на другие главы, содержащие более подробное описа-
ние упомянутых в данной главе протоколов, помогает получить целостное представле-
ние об интересующей читателя теме.
Поскольку организация и эксплуатация сетей невозможна без участия человека, ав-
тором приложены максимальные усилия для того, чтобы представить весь материал с
учетом человеческого фактора, а не как теорию в чистом виде. Читатель данной книги —
именно тот человек, который занимается конкретной работой по реализации предос-
тавляемых стеком протоколов TCP/IP возможностей; именно по этой причине книга
организована таким образом, чтобы помочь читателю хорошо усвоить изложенный в ней
материал

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

Во многих случаях на приведенных в книге снимках окон анализатора проюколов
Sniffer выделяется какой-либо отдельный кадр, иллюстрирующий выполняемое прото-
колом действие. В той части окна, которая находится под выделенной частью экрана,
отображается заголовок сообщения того или иного протокола. В таких заголовках со-
держатся самые разнообразные сведения, начиная от IP-адресов и заканчивая кодами
выполняемых протоколом операций. Кроме того, наряду с отображением заголовков раз-
личных протоколов в окнах анализатора протоколов Sniffer в книге приводятся также
схематические изображения этих заголовков. Такие графические схемы представляют
заголовки в формате, определяемом соответствующим документом RFC (Request For
Comments, Запрос на комментарии). Однако иллюстрация заголовков с помощью окна
Sniffer носи г более практичный характер, чем их графическое изображение. Автор кни-
ги считает, что параллельное использование двух указанных выше способов представ-
ления заголовков различных протоколов позволит читателю получить более обширный,
ориентированный на конкретную работу по организации и обслуживанию вычислитель-
ных сетей практический опыт.

В каждой главе данной книги читатель найдет также ссылки на соответствующие до-
кументы "Запросы на комментарии" (RFC) и их номера (например, RFC 1583). Как
правило, в документах RFC содержится сухая фактографическая информация о специ-
фикациях протоколов TCP/IP. В данной книге, вместо тривиального пересказа изложен-
ной в RFC информации, делается ссылка на соответствующий той или иной теме доку-
мент, а содержание документа излагается на более понятном и доступном языке. Дпя
тех читателей, которые желают глубже изучить содержание запросов на комментарии, в
книге приведен организованный по главам список RFC и их номеров (приложение А).
Свободный доступ к необходимым RFC можно получить через соответствующий Web-
сайт, информацию о котором также можно найти в данной книге.

Автор книги надеется на то, что читатель получил достаточно полное представление
о книге и о том, как пользоваться изложенным в ней материалом. В случае возникнове-
ния дополнительных вопросов по поводу содержания книги просьба обращаться к Хе-
зер Остерлох (Heather Osterloh) по следующему адресу: heather@itacademy.com. Автор
книги с удовольствием ответит на все вопросы читателей в кратчайшие сроки.
Глава 1

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

В данной главе рассматриваются следующие темы:

•	Модель взаимодействия открытых систем (OSI, Open System Intercon-
nection)

•	Модель министерства обороны США (DoD, US Department of Defense)

•	Семиуровневая архитектура (Seven-layer Architecture)

•	Архитектура и топологии локальных сетей (Network Architecture and
Topologies)

•	Технологии организации глобальных сетей (Wide Area Network
Technologies)

•	Запросы на комментарии (Requests For Comments)

Обзор эталонной модели OSI

На начальном этапе объединения компьютеров в сети работу корпоративных вы-
числительных сетей обслуживали только являющиеся собственностью той или иной
компании системы и протоколы. Разработанные крупными компаниями операцион-
ные системы, такие как SNA (Systems Network Architecture. Сетевая архитектура вы-
числительных систем) фирмы IBM и DECNet компании Digital Equipment Corporation,
функционировали на базе разработанных специально для этих компаний стеков прото-
колов (protocol suites). Указанные операционные системы и соответствующие им стеки
протоколов в первоначальном их виде обеспечивали процесс коммуникации между вхо-
дящими в состав локальной корпоративной сети мини-компьютерами и мэйнфреймами
(mini- and mainframe network communication). В то же время эти компании не предпри-
нимали никаких мер по разработке программных и аппаратных средств, которые сдела-
ли бы возможным взаимодействие их вычислительных сетей с внешними системами. При
разработке операционных систем SNA и DECNet компании IBM и Digital Equipment
Corporation не смогли предвидеть тот факт, что в будущем широкое распространение
получат самые разнородные вычислительные среды и, следовательно, только сети, фун-
кционирующие на базе совместимых протоколов и операционных систем, смогут осу-
ществлять успешное взаимодействие и обмен данными.
Как можно предположить, процесс коммуникации между системами, разработан-
ными для различных компаний, был чрезвычайно затруднен, если вообще возможен.
Вскоре крайне актуальной стала проблема разработки какого-либо способа преобра-
зования представляемой тем или иным протоколом информации в некую универсаль-
ную форму, распознаваемую разными системами, что позволило бы локальным се-
тям различных компаний взаимодействовать между собой и совместно использовать
имеющуюся в их распоряжении информацию. В начале 70-х гг. министерством обо-
роны США (DoD, Department of Defense) была разработана модель многостороннего
взаимодействия между разнотипными вычислительными системами (intercommunication
model), которая, в свою очередь, стала исходной моделью для разработки и реализа-
ции стека протоколов TCP/IP.

Модель DoD, получившая на начальном этапе достаточно широкое распространение,
в начале 80-х гг. почти полностью уступила место разработанной Международной орга-
низацией по стандартизации (ISO) эталонной модели взаимодействия открытых систем
(OSI Reference Model). Эталонная модель OSI представляет собой семиуровневую иерар-
хическую архитектуру (seven-layer architecture), которая определяет способ реализации
соответствующих каждому уровню действий, направленных на обеспечение процесса
коммуникации между локальными вычислительными сетями (рис. 1.1). В данной книге
при описании назначения и действия каждого протокола, входящего в состав стека про-
токолов TCP/IP. делаются ссылки на обе модели.

OSI Model and Functions

РИСУНОК 1.1

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

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

Уровень представления

Сеансовый уровень

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

Сетевой уровень

Канальный уровень

Физический уровень

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

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

Управление сеансом и управление диалогом

Сквозная передача данных мевду протраммами/процессами

Присвоение логических адресов и маршрутизация

Передача и прием кадров

Кодирование сигналов, физическая среда и соединители
для организации канала передачи данных

Эталонная модель OSI обеспечивает беспроблемный процесс коммуникации как
между однотипными, так и между разнотипными системами. Модель OS1 предоставля-
ет в распоряжение производителей и поставщиков программного и аппаратного обес-
печения некую базовую иерархическую структуру, в соответствии с которой им следует
разрабатывать свое оборудование, протоколы и операционные системы. Модель OSI
обеспечивает специалистов по информационным технологиям стандартными специфи-
кациями, позволяющими создавать аппаратные и программные средства многосторон-
него взаимодействия между различными системами. Предусмотренная в модели OSI
схема организации процесса коммуникации позволяет также реализовать всевозможные
протоколы, входящие в состав стека протоколов TCP/IP, на базе разных сетевых архи-
тектур (network architectures) и различных типов физических носителей, обеспечива-
ющих работу нижних уровней (lower-layered media types). Несмотря на то, что задача
обеспечения беспроблемного взаимодействия между различными системами не все-
гда достижима, эталонная модель OSI рассматривает эту задачу как первостепенную.

Существовавшие до появления модели OSI протоколы с трудом поддавались уни-
фикации: их нелегко было использовать для организации обмена данными между раз-
личными сетями и системами, а модификация этих протоколов в большинстве случа-
ев была просто невыполнимой. Большинство протоколов и соответствующего
оборудования, реализуемых в настоящее время поставщиками и производителями в
области организации и обслуживания компьютерных сетей, приведены в полное со-
ответствие с нормативами модели OSI. Беспрепятственный, быстрый обмен данными
и беспроблемное взаимодействие, столь необходимые для обеспечения работы совре-
менных разнотипных вычислительных систем, целиком и полностью зависят от того,
насколько строго поставщики и производители аппаратных и программных средств
придерживаются предписываемых эталонной моделью OSI стандартных нормативов
и спецификаций.

Модель OSI — это концептуальная модель взаимодействия открытых систем. Она
состоит из ряда стандартов, определяющих способы пакетирования данных и последо-
вательность действий, необходимых для передачи данных по сети в адрес удаленного
хоста. Логическое разбиение процесса коммуникации на различные уровни не предпо-
лагает выполнения на каждом из логических уровней каких-либо конкретных действий;
такое разбиение предусматривает только концептуальное определение свойственного
каждому уровню набора функций, обеспечивающих поддержку соответствующего фраг-
мента процесса передачи данных. Конкретная реализация тех или иных возможностей
на различных уровнях модели OSI зависит от поставщика или производителя, разраба-
тывающего или реализующего какой-либо протокол или оборудование. Отдельные
производители наделены правом выбора степени соответствия разрабатываемого ими
программного или аппаратного продукта стандартным спецификациям того уровня,
который этот продукт должен обслуживать. Конечный программный или аппаратный
продукт не всегда обеспечивает полную совместимость между разнотипными устрой-
ствами. однако строгое следование предписываемым эталонной моделью OSI стан-
дартам является лучшим гарантом подобной совместимости.

Модель OSI состоит из следующих семи уровней (в порядке убывания):

•	Прикладной уровень (Application layer)

•	Уровень представления (Presentation layer)

•	Сеансовый уровень (Session layer)

•	Транспортный уровень (Transport layer)

•	Сетевой уровень (Network layer)

•	Канальный уровень (Data Link layer)

•	Физический уровень (Physical layer)

Каждый из указанных выше уровней модели OSI выполняет особые, свойствен-
ные только этому уровню функции, обшее содержание которых состоит в подготов-
ке данных для передачи по сети с целью их доставки в адрес удаленного хоста. По-
станщик сетевых услуг имеет возможность вводить в состав общего набора функций
сети необходимые ему для определенных целей особые характеристики. Другими сло-
вами, производитель или разработчик отвечает за максимальное соответствие допол-
нительных функциональных возможностей предписываемым моделью OSI сгандар
там, а поставщик определяет способ конкретной реализации этих возможностей.
Результатом строгого следования нормативам Эталонной модели OSI является продукт,
который легко интегрируется с другими обслуживающими модель OS1 про1раммны-
ми и аппаратными продуктами.

Следует обратить внимание на то, что модель OSI может быть задействована толь-
ко тогда, koi да выполняется подготовка и пакетирование данных для их передачи в
адрес удаленного хоста, функционирующего на основе программного обеспечения
(протоколов и операционных систем), совместимого или несовместимого с npoipasiM-
ным обеспечением хоста-отправителя. Эталонная модель OSI не используется, когда
возникает необходимость в получении доступа к локальным данным. Например, что-
бы получить доступ к локальным файловым службам или службам печати, необходи-
мо выполнить обычную процедуру обращения к жесткому диску локального компь-
ютера и открыть локальное приложение. В подобной ситуации нет необходимости во
вмешательстве пользователя в сам процесс получения доступа к требуемым данным.
С другой стороны, если возникает необходимость выполнить такую же операцию на
удаленном хосте, потребуется каким-то образом отправить в адрес этого хоста сооб-
щение, содержащее запрос на получение доступа к файлам или принтеру удаленного
хоста. Ответом на такой запрос будет передача требуемых данных.

Для переадресации запроса на получение доступа к файловым службам или службам
печати удаленного хоста через другой хост требуется специальная npoipa.MMa, эмулиру-
ющая доступ к удаленным файловым системам как к локальным — редиректор
(redirector). Редиректор перенаправляет запрос хоста-отправителя в адрес удаленного
хоста для дальнейшей обработки. Удаленный хост выполняет подготовку полученного
запроса для его передачи по сетевому комплексу, присоединив к содержащему этот зап-
рос сообщению соответствующий заголовок и управляющую информацию. Эта управ-
ляющая информация необходима для того, чтобы хост-получатель знал, что делать с
данными и как ответить на полученный запрос.

Обзор модели DoD

Предыстория создания коммуникационной модели министерства обороны США
(DoD, Department of Defence) уходит в прошлое намного дальше, чем разработка моде-
ли OS1, практически полностью вытеснившей модель DoD впоследствии. В 1973 г. Уп-
равление перспективных исследовательских проектов министерства обороны США
(DARPA. Department of Defense Advanced Research Projects Agency) приступило к реа-
лизации программы, целью которой была разработка гехнолотй, позволяющих обес-
печить взаимосвязь между различными типами сетей с коммутацией пакетов. Этот ис-
следовательский проект получил название "Проект объединения локальных сетей в
единый сетевой комплекс" ("Internetting Project"). Как можно догадаться по названию,
результатом реализации этого проекта стал современный Интернет.

Коммуникационная модель, разработанная организацией DARPA в качестве ис-
ходного стандарта, в строгое соответствие с которым должны быть приведены все ос-
новкые проюколы Интернета приобрела широкую извест-
ность под названием "модель DoD". Эта модель состоит из
следующих четырех уровней:

•	Уровень Процесс/приложение (Process/Application
layer)

•	Межхостовый уровень (Host-to-host layer)

•	Уровень Интернета (Internet layer)

•	Уровень доступа к сети (Network Access layer)

как показано на рис. 1.2, структура модели DoD прибли-
зительно соответствует структуре модели OSI

РИСУНОК 1.2
Модель DoD
состоит из
четырех
различных
уровней.

Модель DoD

Уровень

Процесс/
приложение

Межхостовый

уровень

Уровень
Интернету

Уровень
доступа к сети

Преимущества семиуровневой архитектуры
модели OSI

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

•	Модель OSI позволяет четко определить функции каждого уровня.

•	Модель OS1 предоставляет в распоряжение производителей аппаратных и про-
граммных продуктов строго очерченную логическую основу для создания необ-
ходимых прикладных программ и разработки соответствующего оборудования.

•	Модель OSI снижает уровень сложности процесса организации вычислительных
сетей посредством разделения всей совокупности функций модели OSI на отдель-
ные модули.

•	Модель OSI поддерживает взаимодействие между разнотипными сетями и про-
токолами.

•	Модель OSI упрощает процедуру поиска и устранения затрудняющих работу сети
неисправностей посредс1вом ограничения зоны их локализации.

•	Модель OS! ускоряет совершенствование информационных технологий посред-
ством поддержки узкой специализации при разработке ирщраммных продуктов
и аппаратных средств.

Разграничение функций различных уровней модели
OSI

Ограничение сферы ответственности каждого уровня модели OSI за выполнение
тех или иных функций позволяет снизить затраты производителей и специалистов по
сетевым технологиям на разработку и сопровождение сетевых протоколов и соответ-
ствующего аппаратного обеспечения. Кроме того, минимальный круг обязанностей
каждого уровня устраняет необходимость повторного определения сферы действия
того или иного программного продукта или протокола. Четкое разграничение функ-
ций различных уровней модели OS1 позволяет производителям аппаратного и про-
граммного обеспечения разрабатывать продукты, предназначенные для обслужива-
ния только одного, а не всех семи уровней модели OSI. Это, в свою очередь, делает
возможной узкую специализацию при разработке программных продуктов и снижает
уровень сложности организации работы сети.

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

Производители нро1раммных продуктов и оборудования могут разрабатывать соот-
ветствующие спецификации либо для одного уровня, либо для нескольких — в зависи-
мости от конкретных условий. Многоуровневый подход к организации коммуникаци-
онной модели позволяет разработчикам сосредоточить свои усилия на создании
продуктов, предназначенных специально для обслуживания одного из уровней модели
OSI. Такой подход способствует упрощению процесса взаимодействия между различными
системами, а также позволяет отличающимся по своим характеристикам и функциональ-
ному назначению протоколам сосуществовать в пределах одной открытой сетевой сре-
ды. Например, производитель может создать сетевую интерфейсную карту (NIC —
Network Interface Card), которая может просто взаимодействовать с канальным уровнем
(Data Link Layer) OSI

Модульная структура модели OS1 позволяет разрабатывать и реализовать продукты,
имеющие специальное назначение. Поскольку нет необходимости в поддержке всех
функций модели OSL начиная от верхнего и заканчивая нижним уровнем, разработчи-
ки таких продуктов moi у г сконцентрировать свои усилия на отдельном уровне, выпол-
няющем ограниченную совокупность функций модели OSL Такая возможность облег-
чает разработку и выпуск программного и аппаратного обеспечения. Кроме того,
несмотря на все многообразие подходов различных производителей к выполнению прин-
ципа строгого следования концептуальным нормативам того или иного уровня модели
OSI, само существование такой стандартизованной коммуникационной модели повы-
шает современный уровень взаимной совместимости различных систем. Вместе с тем
следование определяемым эталонной моделью OSI стандартам при разработке прото-
колов, программного н аппаратного обеспечения, позволяет надеяться на то, что эти
продукты будут гармонично сосушествовать в рамках одной сети и в будущем.

Упрощенный подход к поиску и локализации
неисправностей

Многоуровневый подход к организации процесса коммуникации в пределах сети
позволяет специалистам по сетевым технологиям пользоваться методом разделения об-
щей совокупности функций модели OSI на отдельные модули при поиске и устранении
возникающих в процессе коммуникации неисправностей. Знание процессов, происхо-
дящих на каждом из уровней модели OS1, позволяет определить, какой уровень не вы-
полняет должным образом ту или иную функцию. Каждый протокол, обслуживающий
конкретный уровень, а также поддерживающее работу данною уровня оборудование
должны функционировать в соответствии со стандартными спецификациями этого
уровня, определенными моделью OSL

Обстоятельством чрезвычайной важности является то, что модель OS1 предлагает семь
более мелких операционных модулей и не требует охватывать всю структуру для лока-
лизации возникших проблем. Если тот или иной уровень не функционирует должным
образом, эта модель позволяет локализовать проблему на том уровне, где она возникла,
чю делает процесс поиска и устранения неисправностей намного более легким, эконо-
мичным и удобным. В целом все сетевые операции функционируют гораздо лучше, если
процесс коммуникации разбит на отдельные более простые модули, а не выполняется
согласно единой, но более сложной модели.

Поддержка принципа узкой специализации

Использование широко распространенных, общепринятых в сфере информационных
технологий стандартов и нормативов способствует оперативному составлению более
надежных программ и проюколов Разработчики программных продуктов и аппаратно-
го обеспечения, конкурируя между собой в усовершенствовании спецификаций своих
продуктов и их производительности на каждом уровне модели 0S1, доводят эффектив-
ность этих продуктов до самого высокого уровня. Возможность сосредоточиться на удов-
летворении нужд только одного уровня, позволяет разработчикам специализироваться
на создании продуктов, отвечающих конкретным требованиям потребителя (примером
может служить разработка маршрутизатора (уровень 3) для небольшого офиса компа-
ний или домашнего использования).

Краткая характеристика уровней модели OSI

Когда возникает необходимость в пересылке данных (это может быть все что угод-
но, начиная от сообщения электронной почты и заканчивая запросом на чтение файла
с удаленного хоста), запрос на пересылку этих данных подлежит пакетированию и пе-
реадресации. Система, являющаяся отправителем запроса на пересылку данных, долж-
на выполнить соответствующие различным уроьпям эталонной модели OSI действия, а
именно:

1.	Применшь к данному запросу процедуру адресации.

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

3.	Выполнить пакетирование запроса (другими словами, сформировать соответствую-
щее сообщение, в котором данный запрос будет отправлен в пункт назначения)

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

В процессе подготовки системой данных для пересылки по каналу связи передава-
емое сообщение, прежде всего, обрабатывается редиректором, который присоединя-
ет к нему соответствующий заголовок и управляющую информацию, а затем перела-
ет сформированное таким образом сообщение на следующий (нижний) уровень.
Нижние уровни модели OSI (lower layers) обеспечивают поддержку выполнения служб,
функционирующих на верхних уровнях (upper-layers). В состав этих служб входят
транспортные службы (transport services), службы маршрутизации (routing services) и
службы адресации (addressing services). Эти службы позволяют передавать сообщение
между отправителем и получателем так же просто, как один пользователь сказал бы
другому "Привет!".

Каждый уровень модели OSI присоединяет к сообщению свой заголовок и управ-
ляющую информацию таким образом, чтобы равноправный уровень на удаленном
хосте мог удалить этот заголовок и управляющую информацию, предварительно оп-
ределив, какой следующий верхний уровень должен получить передаваемое сообще-
ние. Каждому уровню отведена строго определенная роль в подготовке данных, под-
лежащих пересылке по каналу связи с целью передачи в адрес удаленного хоста (см.
рис. 1.3). Все действия, соответствующие функциям того или иною уровня, являются
прозрачными для конечного пользователя.

РИСУНОК 1.3

На каждом уровне
модели OSi к
сообщению, в котором
передаются данные,
присоединяет ся
заголовок и
управляющая
информация,
используемая для
обработки порученных
данных на
соответствующем
уровне хиста-
получателя.

Соответствующие уровни хоста-отправителя и хоста-получателя
функционируют как равноправные уровни

(РН) — Заголовок уровня представления
(SH) — Заголовок сеансового уровня
(TH) — Заголовок транспортного уровня
(NH) — Заголовок сетевого уровня
(DH) — Заголовок канального уровня
(DIN)—Концевик данных

В процессе передачи данных с одного уровня на следующий, по мерс продвижения
данных в направлении физического уровня и собственно физического носителя, каж-
дый уровень присоединяет к сообщению свой заюловок или управляющую информа-
цию. Каждый уровень, в свою очередь, рассматривает полученное им сообщение как
сообщение, сформированное всеми верхними но отношению к нему уровнями. Процесс
присоединения к сообщению нового заголовка на каждом очередном уровне аналоги-
чен вложению одного конверта в другой (этот процесс называется инкапсуляцией,
encapsulation).

Рассмотрим действие изображенного выше механизма формирования и передачи
сообщений с использованием модели OS1 на конкретном примере. Прикладной уровень
присоединяет к сообщению свой заголовок и управляющую информацию, необходи-
мую для равноправного прикладного уровня удаленного хоста. Сформированное та-
ким образом сообщение, в состав которого входит заголовок, управляющая инфор-
мация прикладного уровня и собственно данные, передается на нижний уровень, а
именно — на уровень представления. Уровень представления считывает информацию,
полученную от верхнего уровня как обычные данные и оставляет эти данные без
внимания (не обрабатывает их). Уровень представления только присоединяет к по-
лученному сообщению свой заголовок и управляющую информацию, необходимую для
равноправного уровня удаленного хоста. Другими словами, каждый очередной ниж-
ний уровень (в данном случае уровень представления) hi норирует указанную в заго-
ловке предыдущего уровня управляющую информацию и рассматривает ее как обыч-
ные данные, которые также не подлежат обработке. На каждом уровне в качестве
управляющей используется только информация, полученная от равноправного уров-
ня удаленного хоста. Каждый последующий уровень присоединяет свой заголовок и
управляющую информацию и передает сформированное таким образом сообщение
вниз, на следующий уровень.

Как только направленный в адрес удаленного хоста модуль данных достигает ка-
нального уровня, система выполняет алгоритм определения ошибок при передаче
данных, так называемый алгоритм CRC (Cyclical Redundancy Check, Алгоритм конт-
роля при помощи циклического избыточного кода) или FCS (Frame Check Sequence,
Алторитм проверки при помощи контрольной последовательности кадров) Данные,
полученные в результате вычисления по алгоритму проверки правильности передачи
данных, присоединяется в конец передаваемого сообщения. Такая операция позво-
ляет хосту -получателю проверить, совпадают ли полученные им данные с данными,
отправленными хостом-отправителем. Это, в свою очередь, позволяет проверить це-
лостность информации при ее передаче на удаленный хост. Термин "кадр" (frame)
обозначает блок данных фиксированного размера, появляющийся в результате логи-
ческого разбиения информации на группы, которому подвергаются данные на каналь-
ном уровне. С этого времени данные передаются по физическому носителю в виде
электрических ситналов — нолей и единиц, поступающих на физический уровень на-
меченного удаленного хоста (см. рис.1.4).

Заголов!- и концовки сообщений

РИСУНОК 1.4  Хост-получатем			
удаляет присоединенный очередны.» уровнем	накладной уровень	"ЗаЫлйАж Уровня1	Сообщения
	Уровень представления	Зато овокуровня 6	Сообщения
хоста-отправителя	сеансовый уровень	ЗаЛЙ.овок уровня 5	Сообщения
заголовок сообщения и заключительную часть перед передачей	Транспортный уровень	затыловок уровня 4	Сегменты
	Сетевой уровень	Заголовок уровня 3 Деитатраыыы ййи пакеты	
сообщения на следующий уровень.	чаналытый кооеень	Заголовок уровня 2	Кадпы	Результат вычислении СЧС
	-яачееккй уровень	Биты — ноли и единиц! i	

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

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

Прикладной уровень модели OS1 часто отождествляют с пользовательскими прило-
жениями, такими как Word, Excel, PowerPoint и т.д. Прикладной уровень не имеет не-
посредственного отношения к собственно прикладным программам; он скорее представ-
ляет собой окно, которое позволяет передавать данные по сети между различными
приложениями. Прикладной уровень является также окном в эталонную модель 0S1,
позволяющим соответствующим образом подготовить данные к пересылке по сети.

Прикладной уровень делает возможным обмен данными между приложениями. На
прикладном уровне приложения получают доступ к нижним уровням, т.е. этот уровень
"открывает окно" в модель OSI. Следует помнить о том, что задача прикладного уровня
состоит в предоставлении пользователю интерфейса между приложением и соответству-
ющим протоколом стека TCP/IP. В отличие от других уровней модели OS1, данный
уровень не предоставляет свои службы ни одному из других уровней; на прикладном
уровне можно получить доступ только к службам этого же уровня.

В состав служб прикладного уровня входят следующие службы:

•	Сетевые (network services) и межсетевые (internetwork services) службы приложе-
ний

•	Файловые службы (file services) и службы печати (print services)

•	Электронная почта (E-mail)

•	Доступ к сети Интернет и протокол передачи гипертекста HTTP (Hypertext Transfer
Protocol)

•	Удаленный доступ к терминалам — служба Telnet

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

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

Уровень представления

На уровне представления пересылаемые ио сети данные преобразуются в единый для
различных платформ формат. Уровень представления отвечает за функционирование
следующих служб:

•	Преобразование данных и их перевод из одного представления в другое (data
conversion and translation)

•	Сжатие и восстановление данных (compression/decompression)

• Кодирование (шифрование) и декодирование (дешифрирование) данных
(encryption/decry ption)

В качестве примера протокола уровня представления можно привести протокол
XDR (cXtemal Data Representation, Протокол внешнего представления данных). Ком-
пания Sun Microsystems использует этот протокол для реализации своей сетевой фай-
ловой системы NFS (Network File System), функционирующей на основе модели вза-
имодействия клиент/сервер. Файловая система NFS использует протокол XDR для
обеспечения платформенной независимости при выполнении операций с файлами. В
настоящее время протокол XDR инкорпорирован в программный код. Файловая си-
стема NFS и протокол XDR рассматриваются в главе 18.

Сеансовый уровень

Сеансовый уровень отвечает за установление, поддержку и разрыв сетевых соеди-
нений между удаленными приложениями, а также за координацию работы сеансов свя-
зи. Каждый сеанс — это диалог между уровнями представления двух систем или бо-
лее. Сеансовый уровень отвечает за передачу между системами запросов па
предоставление различных служб и ответов на эти запросы. Кроме того, данный уро-
вень управляет диалогом между двумя выполняемыми на различных хостах приложе-
ниями. а также регулирует поток информации, передаваемой во время сеанса связи
между этими хостами.

Эффективность управления диалогом между хостами на сеансовом уровне зависит
от того, является ли соединение полудуплексным (half duplex) или полнодуплексным
(full-duplex), т.е. однонаправленным или двунаправленным. В случае полудуплексной
конфщурации соединения только один из партнеров по коммуникации может пере-
давать данные во время одного сеанса связи, в то время как все остальные участники про-
цесса коммуникации остаются в режиме ожидания своей очереди (standby mode). Прини-
мающая сторона должна подождать, пока другой процесс закончит передачу данных, и
только затем сможет выдать партнеру соответствующее подтверждение (acknowledgement)
о приеме данных. В полнодуплексном режиме каждая сторона имеет возможность
отправлять и принимать данные одновременно; следовательно, передача данных в
таком режиме более эффективна, чем в полудуплексном режиме. Подобная произво-
дительность передачи данных в полнодуплексном режиме достигается посредством
включения подтверждения о приеме данных в блок данных обратного направления
(Piggybacking).

Примером протокола сеансового уровня может служить протокол NetBIOS (Network
Basic Input Output System, Сетевая базовая система ввода-вывода). NetBIOS устанавли-
вает сетевое соединение между двумя хостами, функционирующими под управлением
операционной системы Window's NT или Windows 95. Используемый в программных
продуктах компании Microsoft, протокол NetBIOS, будучи сугубо протоколом сеансо-
вого уровня, предоставляет в распоряжение пользователя службы именования и управ-
ления сеансами связи между двумя удаленными хостами посредством простого присва-
ивания имен.

На сеансовом уровне работает также разработанный фирмой Sun протокол RPC
(Remote Procedure Call, Вызов удаленных процедур), который позволяет клиентам де-
лать запросы на удаленное выполнение той или иной процедуры. Эти запросы пере-
даются на удаленный хост для обработки и формирования ответа, что и составляет суть
сетевого взаимодействия между хостами. Для передачи запросов и получения ответов
на них файловая служба NFS использует протокол RPC на сеансовом уровне и про-
токол XDR на уровне представления.
Транспортный уровень

Принято считать, что транспортный уровень обеспечивает только гарантирован-
ную надежную доставку данных между двумя коммуникационными процессами или
программами, выполняемыми на удаленных хостах. Однако это соответствует действи-
тельности только в случае, если поставщик сетевых услуг отдает предпочтение реали-
зации транспортного протокола TCP (Transmission Control Protocol, Протокол управ-
ления передачей), а не протокола UDP (User Datagram Protocol, Протокол передачи
пользовательских дейтаграмм). Потому' что протокол TCP, будучи ориентированным
на соединение протоколом (connection oriented), обеспечивает i арам тированную до-
ставку данных в пункт назначения. С другой стороны, протокол UDP — не ориенти-
рованный на соединение протокол (connectionless) — обеспечивает высокую скорость
передачи данных. Протоколы транспортного уровня TCP и UDP рассматриваются
более подробно в главах 8 и 9 соответственно.

Транспортный уровень выполняет следующие функции.

•	Управление сквозной передачей данных (end-to-end communication) между двумя
выполняемыми на различных хостах процессами.

•	Предоставление верхним уровням ориентированных на установление соединения
(connection-oriented) или не ориентированные на установление соединения
(connectionless) служб.

•	Идентификация выполняемых на хосте процессов по адресам портов приложе-
ний клиента и сервера (client- and server-port addresses).

•	Сегментирование данных для приложений верхних уровней (segmenting data).

Задача транспортного уровня состоит в идентификации взаимодействующих между
собой процессов на каждом хосте. Кроме того, транспортный уровень отвечает за пре-
доставление либо ориентированных на соединение служб и, соответственно, надежного
транспорта, либо не ориентированных на соединение служб, гарантирующих быструю
доставку данных в пункт назначения. В случае установления ориентированного на со-
единение сеанса связи транспортный уровень регулирует поток данных (data flow) и
осуществляет управление этим потоком (flow control). Оба протокола — протокол уп-
равления передачей (TCP) и протокол передачи пользовательских дейтаграмм (UDP) —
предлагают разную по характеристикам доставку данных (TCP — надежность, UDP —
скорость) и поэтому являются равноправными протоколами транспортного уровня, каж-
дый из которых соответствует специфическим требованиям пользователей.

В обязанности транспортного уровня входит также сетментирование данных (сооб-
щений), полученных от приложений верхнего уровня. На транспортном уровне выпол-
няется формирование сокетов (sockets), которые представляют собой комбинацию но-
мера соответствующего приложения TCP- или UDP-nopra и IP-адреса отправителя или
получателя данных. Сокеты (или, другими словами, адреса сокетов) полностью иден-
тифицируют выполняемую на хосте программу, или приложение верхнего уровня. Для
такого управления потоком данных, формирования сегментов данных и отслеживания
их передачи на транспортном уровне используются номера портов (port numbers) для
каждого приложения.
^ОБРАЗОВАНИЕ ПАР СОКЕТОВ

В процесс сквозной передачи данных между хостами вовлекаются как IP-адреса источни-
ка и назначения, так и номера портов соответствующих приложений. Комбинация IP-ад-
реса и номера порта составляет сокет. Пара сокетов (socket pair) — IP-адрес и порт
отправителя в совокупности с IP-адесом и портом получателя — образует сквозное со-
единение между двумя хостами (отправителем и получателем данных) и полностью иден-
тифицирует процесс передачи данных по этому соединению.

Транспортный уровень предлагает протоколам верхнего уровня как ориентирован-
ную, так и не ориентированную на установление соединения службу доставки данных.
Однако каким бы ни был способ доставки данных в пункт назначения — ориентиро-
ванным на соединение или нет, IP-адреса и номера портов полностью идентифициру-
ют выполняемый на хосте процесс. Подробное описание транспортною уровня пред-
ставлено в главе 7.

Сетевой уровень

Первостепенной задачей сетевого уровня является присваивание jot ических адресов
хосту-отправителю (source host) и хосту-получателю (destination host), а также опреде-
ление оптимальною маршрута для передачи данных между сетями. Сетевой уровень
выполняет следующие функции:

•	Сквозная передача данных между хостами (end-to-end communication)

•	Логическая адресация (logical addressing)

•	Доставка пакетов (packet deli very)

•	Маршрутизация (routing)

На сетевом уровне применяются логические адреса хостов, которые следует отли-
чать от МАС-адресов — адресов управления доступом к физической среде (Media Access
Control), или физических адресов, присваиваемых производителем сетевому адаптеру.
В отличие от физических адресов, логические адреса (адреса, присваиваемые хостам на
длительное время) не прошиваются в сетевой плате. Вместо этого сетевой администра-
тор присваивает логические адреса вручную или динамически. Логические адреса сете-
вого уровня (Network layer logical addresses) рассматриваются более подробно в гла-
вах 4—6.

Для маршрутизации данных по самому оптимальному маршруту на сетевом уровне
используются специальные устройства — маршрутизаторы (routers), которые выполня-
ют маршрутизацию данных посредством комму гании пакетов (packet switching). Марш-
рутизатор принимает поток данных через один интерфейс, определяет сетевой адрес
хоста-получателя и отправляет полученный трафик но этому адресу через другой ин-
терфейс.

Сетевой уровень обслуживают следующие протоколы:

•	RARP, ARP, ВООТР и DHCP — протоколы, выполняющие разрешение адре-
сов (address resolution) и их конфигурирование

•	ICMP — диагностический и управляющий протокол.

•	RIP, IGRP, E1GRP, OSPF и BGP — протоколы маршрутизации.
Канальный уровень

Основные обязанности канальною уровня — это передача и прием кадров, а так-
же физическая адресация. Перед началом процесса передачи данных на канальном
уровне к каждому пересылаемому пакету данных присоединяется как заголовок (к
началу пакета), так и заключительная часть (trailer) единой четыре байта (в конец
пакета). Таким образом, вокруг пакета данных образуется своеобразная рамка, или
кадр (frame) — отсюда и название передаваемого на канальном уровне пакета дан-
ных. Термин "кадрирование пакета" (packet framing) обозначает процесс формиро-
вания кадра. Заключительная часть кадра присоединяется к пакету данных только на
канальном уровне.

Канальный уровень имеет следующие характеристики и выполняет следующие фун-
кции:

•	Управление доступом к физическому носителю данных (controls access to the
medium).

•	Включение в состав пакета данных аппаратных адресов источника и назначения
(source and destination hardware addresses).

•	Подготовка данных к дальнейшему продвижению посредством преобразования
пакетов данных в кадры (converting data packets to frames).

•	Выполнение процедуры передачи и приема данных по физическому носителю
(sending and receiving data over the wire).

•	Вычисление алгоритма CRC или FCS.

•	Объединение локальных сетей посредством мостов (bridges) и использование
коммутаторов (switches) для передачи кадров в порты получателей.

Адресация на канальном уровне

Производители встраивают адреса канального уровня (МАС-адреса) в каждый сете-
вой адаптер. Соответствующая каждому такому адресу последовательность цифр уста-
навливается в момент производства платы. Как предписано стандартами IEEE (Institute
of Electrical and Electronics Engineers, Институт инженеров no электронике и электро-
технике), каждый адрес имеет длину шесть байтов. Первых три байта определяют про-
изводителя сетевого адаптера, а оставшиеся три байта содержат в себе присвоенный
производителем порядковый номер адаптера. Устройства, функционирующие на каналь-
ном уровне, должны иметь возможность идентифицировать эти адреса.

На канальном уровне в заголовке кадра устанавливаются МАС-адреса источника
и назначения с целью идентификации адреса сетевой интерфейсной платы (NIC.
Network Interface Card) — устройства, отправившего данный кадр, а также , устрой-
ства, которое должно принять кадр. Каждый МАС-адрес должен быть уникальным.
Оба устройства, обслуживающие канальный уровень, используют физический адрес
пункта назначения для дальнейшего продвижения данных по этому адресу.

Перед передачей данных по сети устройства-отравители данных должны выпол-
нить вычисление алгоритма CRC (Cyclic Redundancy Check. Алгоритм проверки при
помощи избыточною циклического кода) или FCS (Frame Check Sequence, Алгоритм
проверки при помощи контрольной последовательности кадров). В сфере сетевых тех-
нологий оба термина — и CRC, и FCS — используются как равнозначные. На каналь-
ном уровне результат вычислений CRC или FCS присоединяется в конец кадра в ка-
честве его заключительной части данных, полученных от сетевого уровня. Заголовок
и заключительная часть передаваемого пакета как будто образуют рамку (кадр) вок-
рут пакета данных. Именно поэтому пакеты данных канального уровня называются
кадрами. Выполнение алгоритма CRC или FCS не гарантирует доставку данных, а
только позволяет определить соответствие отправленных источником битов инфор-
мации тем битам, которые принимает хост-получатель. Хост-получатель, в свою очередь,
также выполняет алгоритм CRC иди FCS для определения целостности поступившего
в его адрес кадра. Если результаты вычислений CRC или FCS хостом-отправителем и
хостом-получателем не совпадают, хост-получатель просто отбрасывает кадр без пе-
редачи соответствующего уведомления в адрес станции-отправителя. Рабочие станнин
никогда не передают испорченные данные на верхний уровень. Обязанность повтор-
ной передачи поврежденных кадров возлагается на хост-отправитель.

Физический уровень

Физический уровень имеет дело с нолями и единицами — другими словами, с бига-
ми, которые и входят в состав кадра. Биты кодируются при помощи электрических или
световых импульсов (electrical or light pulses). Физический уровень регулирует также
электрические и механические характеристики, кодирование сигналов и уровень напря-
жения. Словом, физический уровень оперирует некими осязаемыми объектами, т.е.
физическими объектами, к которым можно прикоснуться, такими как кабели (cables) и
повторители (repeaters).

Физический уровень отвечает за реализацию следующих функциональных возмож-
ностей:

•	Конфигурирование электрических и механических характеристик физической
среды (electrical and mechanical characteristics).

•	Кодирование сигналов (signal encoding).

•	Передача собственно битов данных в виде нолей и единиц.

•	Определение спецификаций физических соединителей (physical connector
specifications).

Архитектура канального уровня и различные
сетевые топологии

Термин application (приложение) обозначает прикладные программы, выполнение
которых обеспечивается стандартами сетевой архитеюуры, а также спецификациями
основных сетевых топологий. Эти стандарты описывают следующие сетевые техноло-
1 ни:

•	Ethernet

•	Fast Ethernet

•	Gigabit Ethernet

•	Token-Ring
•	FDDI

Стандарты IEEE и ANSI специфицируют также типы передаваемых на канальном
уровне кадров (frame types) и методы доступа к каналам (channel access methods). В
последующих разделах данной главы с целью краткого ознакомления читателя с ука-
занными выше технологиями представлено их общее описание.

Ethernet и IEEE 802.3

Рассмотрение различных сетевых технологий целесообразно начинать с наиболее рас-
пространенной сетевой архитектуры — технологии Ethernet, спецификации которой
представлены в принятом институтом IEEE стандарте 802.3. Как правило, корпорация
Xerox получает кредиты на разработку локальных сетей типа Ethernet, однако исходная
технология (извест ная в то время под названием Aloha Net) была приобретена в 70-х гг.
у Гавайского университета. Впоследствии корпорация Xerox объединила свои усилия с
компаниями DEC и Intel с целью усовершенствования самого первого стандарта Ethernet
(Ethernet I), выпущенного в 1980 г. Результатом совместной работы этих трех компаний
стал выпуск в 1982 г. последующей версии Ethernet — версии 2 (Ethernet II).

В середине 80-х гг. комитет IEEE 802 принял Ethernet в качестве стандарта 802.3 для
организации локальных сетей. Все текущие и будущие разработки, касающиеся техно-
логий Ethernet, по-вилимому, будут базироваться именно на этом стандарте. С самого
начала своего существования технология Ethernet стала наиболее широко используемым
во всем мире стандартом организации локальных вычислительных сетей.

Важно отметить, что Ethernet — это не совсем то же самое, что реализации стандар-
та IEEE 802.3, и эти два термина не следует использовать как равнозначные (хотя в
некоторых случаях они действительно обозначают одну и ту же технологию организа-
ции локальных сетей). Тогда как компании Xerox, DEC и Intel разработали Ethernet 1 и
Ethernet И с достаточно сходным набором характеристик, комитет IEEE прибавил не-
сколько расширенных возможное!ей, которых не было в предшествующих версиях. В
таблице 1.1 представлена сравнительная характеристика различных технологий органи-
зации ЛВС.

Таблица 1,1 Ethernet версии 1, версии 2 и IEEE 802.3

Версия I	Версия 2	IEEE 802.3

Архитектура	Включает кадр Ethernet II,	Вводит в состав сети
канального уровня	позволяющий обнаружить и заблокировать повреждение данных (Ethernet II ~ стандартный кадр, функция которого — перенос IP-трафика по сетям Ethernet)	приемоле редатч и ки, обязанность которых состоит в контроле над передачей поврежденных кадров

Доставляет данные со скоростью  10 Мбит/с на основе шинной топологии	Доставляет данные со скоростью 10 Мбит/с на основе шинной топологии	Поддерживает также звездообразные топологии
Используются только толстые коаксиальные кабели	Используются только толстые коаксиальные кабели	Используются также кабели следующих типов: тонкий коаксиальный, волоконно- оптический, витая пара

2 Зак 768
Версия 1	Версия 2	IEEE 802.3
Применяется несбалансированная передача сигналов относительно точки “земля” (чувствительная к радиопомехам и электромагнитному излучению)	Используется сбалансированная передача сигналов	Улучшения, внесенные в Ethernet в 1995 г., обеспечивают скорость передачи данных 100 Мбит/с (602.Зи)
Не поддерживается тестирование качества сигнала (SQE — Signal Qualiti Error)*, что затрудняет процесс обнаружения конфликтов	Поддерживается SQE	Поддерживается SOE (только внешними приемопередатчиками)
Несовместимость с версией 2	Несовместимость с версией 1	Несовместимость с версией 1

'Процедура, выполняемая приемопередатчиком (transceiver) сразу после того, как подсоединенный к нему компьютер
начинает передавить оанные в ЛИС. Приемопередатчик периодически посыпает тестирующий сигнал по кабелю AU!
и возвращает его в компьютер, если капал работоспособен. Эта периодическая проверка качества канала часто на-
зывается "сердцебиением"(heartbeat).(прим, редактора)

Спецификация Ethernet версии 1 предполагает использование присутствия или от-
сутствия напряжения на выходе приемопередатчика для представления данных; подоб-
ная операция известна под названием "несбалансированная передача сигналов
(unbalanced signaling). Применение подобного метода передачи сигналов делает процесс
пересылки данных чрезвычайно чувствительным к внешним помехам. На рис. 1.5 пред-
ставлен пример несбалансированной передачи сигналов.

РИСУНОК 15
Несбалансированная
передача сигналов,
необходимая для
представления данных,
предполагает изменение
напряжения от 0 (уровень
"земля") до 5 вольт

Ethernet версии 1

В Ethernet версии 2 используется усовершенствованный метод передачи сигналов —
сбалансированная передача сигналов (balanced signaling). Этот метод позволяет пред-
ставлять данные посредством преобразования напряжения с положительного на от-
рицательное относительно нулевого уровня напряжения — точки "земля" (см. рис. 1.6).
Такой подход позволяет снизить уровень воздействия помех на передачу данных, что,
в свою очередь, повышает качество сигнала.

Стандарт IEEE 802.3 специфицирует основные принципы действия, компоненты
и ограничения по дальности сети Ethernet, а именно:
РИСУНОК 16

Сбалансированная переда ча
сигналов улучшает
качество сигнала
посредством применения
положительного и
отрицательного уровня
напряжения относительно
единиц отправной точки —
уровня "земля".

•	IEEE 802.3 определяет все компоненты (components), функции (functions), ме-
юды доступа к среде передачи (channel access methods) и действия (operations)
канального и физического уровней.

•	IEEE 802.3 обеспечивает производителей нормативами реализации или разработ-
ки Л ВС-техиологий серии Ethernet 802 3.

•	IEEE 802.3 базируется на и «вестном под названием 10Base5 стандарте IEEE, ко-
торый с незначительными изменениями применяется во всех стандартах 802.3.

Стандарт IEEE 802.3 специфицирует, базирующуюся на рассылке широковещатель-
ных сообщений (broadcasts), линейную сетевую архитектуру (linear network architecture)
с пропускной способностью 10 Мбит/с. В данной сетевой архитектуре используется метод
доступа к каналам, известный под названием CSMA/CD (Carrier Sense Multiple Access
with Collision Detection, Множественный доступ с контролем несущей и обнаружением
копфчикгов), который рассматривается в следующем разделе.

Метод доступа к среде передачи

В настоящее время существует множество разнообразных методов доступа к середе
передачи данных; конкретная реализация зависит от сетевой архитектуры. Ethernet ис-
пользует метод доступа с установлением соединения (contention-based channel access
method). Методы доступа к каналам характеризуют используемые различными устройства-
ми правила, которые предписывают:

•	Способ получения доступа к среде передачи.

•	Формат передаваемых кадров.

•	Освобождение каналов для их использования другими устройствами.

Устройства, использующие метод доступа к среде CSMA/CD, выполняют следующие
действия:

•	Конкурируют с другими устройствами за право на передачу данных по данно-
му каналу.

•	Выполняю! успешную передачу данных по одному кадру за один раз.

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

Одновременная передача сигналов разными устройствами по одному и тому же ка-
налу может привести к разрушению кадров. Избежать этого позволяет метод доступа
к среде с установлением соединения (contention-based access), имеющий название
"Множественный доступ с контролем несущей и обнаружением конфликтов" (CSMA/
CD, Carrier Sense Multiple Access with Collision Detection). Поскольку Ethernet исполь-
зует паузу (silence) как сигнал к передаче данных, устройства используют контроль
несущей (carrier sense) для обнаружения этой паузы. Если частота сигнала на данном
канале равна нулю, устройства moi у г получать доступ к каналу, а непосредственно
после получения доступа начинать передачу данных. После выполнения передачи
данных устройства освобождают канал и ожидают минимум 9.6 микросекунд, перед
тем как снова предпринять попытку получения доступа к тому же каналу. Эго предо-
ставляет другим приемопередатчикам возможность выполнить передачу своих кадров

Конфликты

Конфликт (collision) возникает в случае одновременной передачи по одному каналу
нескольких сигналов. В сети с передачей немодулированных сигналов (baseband network)
один канал может Быть занят одновременной передачей нс более чем одного сигнала.
Результатом параллельного прохождения по физическому носителю более чем одного
сигнала является конфликт, который препятствует успешному выполнению передачи
данных. В процессе прохождения сигнала приемопередатчик выполняв! кодирование
сигнала для передачи по данному носителю и прослушивает среду передачи на возник-
новение конфликтов. Н случае если конфликт имеет место, внутренняя схема обнару-
жения конфликтов приемопередатчика (transceiver's internal collision detection circuitry)
уведомляет об этом плату сетевого адаптера посредством передачи на эту плату сш на-
ла, который вызывает преждевременное прекращение адаптером процесса передачи дан-
ных (transmission abort). Обнаружение и повторная передача кадров в случае возникно-
вения конфликтов входит в обязанности передающего устройства.

Возникновение конфликтов — это реальность Ethernet. Н то же время избыточность
конфликтов (excessive collisions) и поздние конфликты (late collisions) могут создать оп-
ределенные проблемы. Перегрузка сегмента слишком большим количеством устройств
приводит к возникновению избыточного числа конфликтов. Когда к одному и тому же
сегменту сети подключено слишком мною устройств, каждое из которых претендует на
использование одного канала, вероятпост ь возникновения конфликтов возрастает до чрез-
вычайно высокого уровня.

Поздние конфликты определяются стандартом 802.3 как конфликты, возникающие
после перечачи 64 байтов данных текущего кадра. Возникновение поздних конфликтов
может вызвать превышение О!раннчений по дальности при передаче сигнала по физи-
ческому носителю (известное, как задержка на распространение — propagation delay) или
аппаратный отказ —(hardware failure).

Кадры Ethernet

В среде стандартов Ethernet выделяется четыре различных типа кадров, каждый из
которых формируется тем или иным объектом с конкретной целью. Существует следую-
щих четыре типа кадров Ethernet:

•	Ethernet! 1 (DIX)

•	Ethemet_802.3 (собственность Novell)

•	IEEE 802.3
• IEEE 802.3 SNAP (SubNetv/огк Access Protocol, Протокол доступа к подсетям)

Специалистами компаний DEC, Intel и Xerox был разработан исходный каар Ethe.nct,
имеющий название Ethernet !I (или DIX). В компании Novell был разработан свой соб-
ственный тип кадра (Ethernct_802.3) исключительно для трафика, tоперируемого про-
токолом межсетевого обмена пакетами (IPX, Internetwork Packet Exchange) и протоко-
лом упорядоченного обмена пакетами (SPX, Sequenced Packet Exchange). Организацией
IEEE были разработаны и названы дна последних типа пакетов. Несмотря на го, что
разработавшие различные типы пакетов компании присвоили им свои имена, в сфере
информационных технологий и в IEEE приняты другие названия. Различие имен свя-
зано с использованием разных типов кадров отдельными компаниями (а не IEEE) в своих
архитектурах и языках. Например, в компании Cisco принято называть кадры Ethernet II
именем aRPA. В таблице 1.2 предсгавчсны все четыре типа кадров, а также соглашения
по именованию этих кадров в информационной индустрии и в IEEE; в таблице 1.3 со-
держится информация о каждом из типов гаеров Ethernet.

Таблица 1.2 Имена кадров Ethernet

IEEE	Промышленные		
Нет	Ethemetll (DIX)		
Нет	Ethemet 802.3		
802.3	Ethernet Ю2.2		
802.3 SNAP	Ethernet_SNAP		
Таблица 1.3 Типы кадров Ethernet			
Ethernet II (DIX)	Ethernet 802.3	Ethemet_8O2.2	Ethernet SNAP
Разработан для переноса IP- трафика	Разработан .для переноса IP/SPX- трафика	Содержит заголовки LLC, ь которых используются адреса DSAP и SSAP для идентификации протоколов верхнего УООВНЯ	Содержит заголовки LLC, в которых используются адреса DSAP и SSAP для идентификации протоколов верхнего уровня
Устанавливает в поле Ethertype (2 байта) зареги- стрированные значения для идет ификации протоколов; например, 0800 =	Возможности ограничены переносом только IPX-трафика  IP	Использует зарегистрированные SAP-адреса;  например, EO “iPX	Специфи цирует отдельные SAP- адреса АА для указания на то, что за заголовком SNAP следует поле Ethertype длиной 2 байта
	Наиболее распростра- ненный тип кадра: фактически применялся в качестве типа IPX еще до появления Ethernet 802.2		Присоединяет 5- байтовый заголовок SNAP после заголовка LLC для идентификации сетевого протокола

Все четыре типа кадров могут сосуществовать в рамках одной сети, однако они не
являются совместимыми между собой. Когда рабочие станции, сконфигурированные
с разными типами инкапсуляции (encapsulation), предпринимают попытки обмена ин-
формацией, они должны осуществлять передачу данных через маршрутизатор, под-
держивающий оба типа. Этот маршрутизатор выполняет преобразование разнотипных
кадрез при передаче данных между хостами. Подобное преобразование влечет за со-
бой рост непроизводительных затрат и задержку при передаче данных по сети, поэтому
целесообразно использовать в рамках одной сети кадры одного и того же типа. В таб-
лице 1.4 представлены основные и дополнительные характеристики кадров Ethernet.

Таблица 14 Сравнительная характеристика кадров Ethernet различных типов

Основные характеристики	Дополнительные характеристики
Перед передачей сообщения присоединяет 14-байтовый заголовок.	Первые 12 байт состоят из МАС- адреса получателя (6 байтов) и МАС- адреса отправителя (6 байтов); за этими адресами следует 2-байтовое поле, в котором устанавливается либо длина цейтаграммы, либо тип протокола
Присоединяет 4-байтовую заключительную .асть (CRC или FCS) перед передачей.	Заключительная часть присоединяется отправителем и сверяется получателем для обеспечения целостности кадра.
Отправляет преамбулу (64 бита) перед передачей каждого кадра с 1 ;елью обеспечения синхронизации.	Преамбула состоит из 7 байтов чередующихся единиц и нолей; последние 2 бита восьмого байта указывают на то, что далее следуют собственно данные.
Минимальный допустимый размер кадра 64 байта (кадры, размер которых менее 64 байтов. дол: :ны быть выровнены до этого размера); максимальный допустимый размер - 1518 байтов.	Кадр состоит из заголовка канального уровня (14 байтоь), заключительной части заголовка (4 байта), служебной информации протоколов верхних уровней (до 15 байтов) и собственно данных.

Рисунки 1.7—1.10 иллюстрируют каждый тип кадров Ethernet. Читатель имеет воз-
можность сравнить изображение кадров Ethernet, сформированное с функциональ-
ной точки зрения, и реальное представление этих кадров. Следует обратить внима-
ние на то, что все типы кадров Ethernet имеют одни и те же базовые характеристики:
кадры всех типов начинаются с МАС-адреса получателя (6 байтов), за которым сле-
дует МАС-адрес отправителя (6 байтов). Кроме того, кадры всех типов заканчиваются
полем длиной 4 байта, в котором указывается результат вычисления алгоритма CRC
(заключительная часть кадра, trailer).

РИСУНОК 1.7

Кадр Ethernetll — это
единственные тип кадра, в
заголовок которого
включено поле типа
протокола (Ethertype)
длиной 2 сайта, следующее
за полем адреса
отправителя кадра (Source
Address). Это поле
используется для
идентификации протокола
с помощью которого должен
передаваться кадр.

Ethemei II

Поле преамбулы	DA	SA	ЕГуре	Поле данных протоколов верхних уровней (не более 1500 байтов)	CRC

6 6	2	'-------»--------'	4

<1500

CRC Результат вычислений алгоритма CRC (4 байта)

Преамбула - 64 бита для синхронизации;

7 байтов = 1011)1010, 6-й байт - 10101011

DA = Адрес получателя

SA = Адрес отправителя

Туре = I |рисвоыное протоколу верхнего уроаня значение .2 байта); например,
0800 = IP

Data = Данные протоколов верхних уровней и дополняющие байты

CRC = PCS, контрольная последовательность кадра
Ethernet_8O2.3

Preamble	DA	SA	Length	FFFF (Upper Layer Protocols)	CRC

6 6	2 Null	4

Checksum

Preamble - Поле преамбулы

DA - Поле адреса получателя (6 байтов)

SA - Поле адреса отправиталя (6 байтов)
Length - Поло длины данных (2 байта)
FFFF (Upper Layer Protocols) Поле контрольной
суммы (в составе данных протокола верхнего
уровня)

СПС - Результат вычисления CRC (4 байта)

Preamble 64 бита для синхронизации

DA = Дарес получателя

SA - Адрес отправителя

Length - Обьем данных, содержащихся в текущем кадре =<1506 или 05DC

(шестнадцатеричное)

FFFF - Нулевая контрольная сумма; заголовок IPX

Data = Данные протоколов верхних уровней и дополняющие байты

CRC = FCS, контрольная последовательность кадра

РИСУНОК 1.8 Кадры Ethernet_802.3 позволяют включать за позем длины (Length) заголовок IPX, первые
два байта которого содержат нулевую контрольную сумму FFFF.

Ethernet 802.2

Preamble - Поле преамбулы

DA - Поле адреса получателя (6 бантов)
SA - Поле адреса отправителя (6 байтов)
Length Поле длины данных (2 байта)
DSAP - Поле доступа к службе получателя
(1 байт)

SSAP - Поле доступа к службе
отправителя (1 байт)

Control Служебное поле управляющей
информации (1 или 2 байта)

Upper Protocols -Поле данных протоколов
верхних уровней

CRC Результат вычисления CRC

(4 байта)

Ethernel_802.2 - Подкадр Ethernet В02 2

LLC 802.2 header - Заголовок LLC
кадра 802.2

I LLC - 802.2 ;	Header					
Preamble	DA SA	Length	DSAP	SSAP Control	Lipper Protocols CRC
6 8	2 j i	i	V2					4

Preamble = 8 байтов для синхронизации: преамбула - 7 байтов, начальный
ограничитель кадра (SFD, Start of Frame Delimiter) - 1 байт

DA = Адрес получателя

SA = Адрес отправителя

(Length = Объем данных, содержащихся в текущем кадре =<1500 или O5DC (шестнад-
цатеричное)

DSAP = Точка доступа к службе получателя

SSAP = Точка доступа к службе отправителя

Control = Значение, соответствующее ориентированному или не ориентированному на
соединение протоколу LLC

Data = Данные протоколов верхних уровней и дополняющие байты

CRC = FCS, контрольная последовательность кадра

РИСУНОК 1.9 Кадр IEEE 802.3, известный в сфере сетевых информационных технологий под названием
Ethernet_802.2, состоит из подзаголовка 802 2, включающего поля доступа к службе получателя

DSAP (Destination Service Access Point, Точка доступа к службе получателя) и поля доступа к службе
отправителя SSAP (Source Service Access Point, Точка доступа к службе отправителя). В этих полях
указываются адреса точек доступа к службе для идентификации протоколов.

На рис. 1.11 в виде упрощенной схемы представлена сравнительная характеристи-
ка всех рассмотренных выше типов кадров Ethernet.

Slow Ethernet

Стандарт Slow Ethernet ("медленный" Ethernet), передающий cut налы co скорос-
тью 10 Мбит/с, был главной опорой локальный вычислительных сетей с самого нача-
ла своего возникновения в середине 80-х гг. На первоначальном этапе процесс объе-
динения компьютеров в сети носил неупорядоченный характер; производимые
программные продукты для обеспечения работы сетей и правила управления ими были
строго ориентированы на нужды отдельных компаний и являлись их собственностью.
В этом смысле очень интересно проследить развитие сетей от такой собственничес-
кой начальной сталии до организации сетей на основе официальных сетевых стандар-
тов и их самых последних усовершенствований. Несмотря на появление документов,
определяющих стандартные правила реализации сетевых технологий (таких как стан-
дарт 802.3), стремление выйти за рамки предписываемых такими документами огра-
ничений стимулирует работающих в сфере информационных гехнолотй специалис-
тов ш норировать многие из этих правил.

Preamble - Поле преамбулы

ЗА Поле адреса получателя [3
байтов}

SA - Поле адреса отправителя (б
байтов)

Length - Поле дга-ны данных (2 байта)

DSAP - Попе доступа г службе
получателя (1 байт)

SSAP - Поле доступа к службе
urnpaai геля (1 байт)

Control - Служебное поле управляющей
информация (I или 2 байта)

Vendor Code Поле хода поставщика

Туре — Поле типа протокола

Ethemet_SNAP

LLC	SNAP

										
Preamble	DA	SA	Len	DSAP AA	SSAP AA	Ctrl	Vendor  Code	Type	Upper Protocols	CRC
	6	6	2	1	1	1/2	3	2		4

Preamble = 8 байтов для синхронизации: преамбула - 7 байтов, начальный
ограничитель кадра (SFD, Start of Frame Delimiter) - I байт

DA - Адрес >|0луча1еля

SA - Адре отправителя

Объем данных, содержащихся в текущем кадре -<1500 или 05DC (шестнадцатерич-
ное)

DSAP - Точка доступа к службе получателя

(SSAP - Точка доступа к службе отравителя

Control = Значение, соответствую цее ориентированному или не ориет гированпому на
соединение протоколу LLC

SNAP - Подзаголовок SNAP, содержащий код поставщика (3 байта) и тил протокола
(2 байга)

Data - Данные протоколов верхних уровней и дополняющие байты

CRC - FCS, контрольная гьспедовател! гость кадра

РИСУНОК 1.10 Кадр IEEF 802.3 SNAP, известный в сфере инфоррационных технологий под названием
Ethemet_SNAP, отличается от к здра 802.2 только допа шительным подзаголовком длиной 5 байтов.

В состав этого подзаголовка входит поле кода поставщика (Vendor Code) длиной 3 байта, за
которым следует поле типа протокола (Туре) длиной 2 байта, идентифицирующее соответствующий
протокол.

Frame Туре О1 tick Reference

DA - Поле адреса получателя

SA - Поле адре-а отправителя

Etype - Поле типа протокола Ethertype

Length - Поле длины данных

FFFF - Поле FFFF

DSAP Поле доступа к службе получателя
SSAP - Поле доступа к службе отправителя
CTHI - Служебное попе управляющей
информации LLC '

Кадр EthemeUI

DA	SA	EType

Кадр Ethernet_802.3

DA	SA	Length	FFFF

Кадр Ethernet 802 2

DA	SA	Length	DSAP	SSAP	CTL

Кадр Ethemet_SNAF

DA	SA	Length	DSAP	SSAP	CTL	SNAP

РИСУНОК 1.11 ha данном рисунке представлено схематическое изображение структуры всех питов
кадров Ethernet, иллюстрирующее отличия между кадрами различных типов.

Существуют следующие спецификации стандарта Slow Ethernet:

•	!0Base5 — Передача данных по толстому коаксиальному кабелю (thick coaxial
cable) на базе шинной iohojioihh со скоростью 10 Мбит/с.

•	10Base2 — Передача данных по гонкому коаксиальному кабелю (thin coaxial cable)
на базе шинной топологии со скоростью 10 Мбит/с.

•	lORaseT — Передача данных по кабелю из ннтых нар (twisted pairs) на основе
звездообразной физической конфи!урацни (physical star configuration).
Fast Ethernet

Набор рекомендаций Fast Ethernet (" быстрый” Ethernet) определяет практически
те же стандартные спецификации, что и Slow Ethernet. Отличия заключаются только в
состоящем из 10 статей приложении, выпушенном в 1995 г. рабочей группой IEEE
802.3u. В этом приложении представлены стандартные спецификации трех различных
реализаций Ethernet, передающих данные со скоростью 100 Мбит/с и имеющих об-
щее название lOOBaseX. В таблице 1.5 представлен сравнительный анализ различных
конфигураций Slow Ethernet и Fast Ethernet.

Таблица 1.5 Сравнительная характеристика Fast Ethernet и Slow Ethernet

	East Ethernet	Slow Ethernet
Метод доступа к среде CSMA/CD	X	X
Одинаковый минимальный/максимальный размер кадра	X	X
Поддержка одних и тех же типов кадров	X	X
Поддержка третьей, четвертой и пятой категорий витой пары	X	X
Поддержка передачи данных по волоконно-оптическому кабелю	X	X
Поддержка звездообразной физической конфигурации	X	X
Полнодуплексный/полудуплексный режим передачи данных	X	X
Поддержка шинной топологии с использованием коаксиального кабеля		X
Манчестерское кодирование сигналов		X
Требуется оборудование WBaseX	X	
Изменения состава компонентов и способа синхронизации	X	

Стандарты серии lOOBaseX

Все три стандарта серии lOOBaseX определяют спецификации моноканальной пере-
дачи данных на базе витой пары или волоконно-оптического кабеля со скоростью
100 Мбит/с. Ограничейия по расстоянию, на которое может передаваться сигнал, от-
личаются в зависимости от соответствующих каждому стандарту характеристик физи-
ческою уровня. Существует три типа спецификаций lOOBaseX.

•	lOOBaseTX — Передача данных со скоростью 100 Мбит/с по кабелю из неэкра-
нированных витых нар (UTP, unshielded twisted pair) пятой категории. Стандарт,
базирующийся на тех же двух витых парах, что п Slow Ethernet.

•	lOOBaseFX — Передача данных со скоростью 100 Мбит/с но волоконно-оптичес-
кому кабелю.

•	100BaseT4 — Передача данных осуществляется с использованием четырех не-
экранированных витых пар: три пары для передачи и приема данных, одна пара
— для обнаружения конфликтов.

Gigabit Ethernet

Стандарт Gigabit Ethernet (GE, "сверхскоростной Ethernet”) позволяет передавать
данные со скоростью до 1000 Мбит/с по кабелям из неэкранированных витых пар
(UTP) пятой категории. В спецификациях данного стандарта, разработанных рабочей
группой IEEE 802.3/, используется формат кадров Ethernet 802.3 и метол доступа к
среде CSMA/CD. Следует обратить внимание на то, что использование стандарта 802.3
обеспечивает обратную совместимость Gigabit Ethernet с технологиями lOOBascT и
lOBaseT.

Token-Ring and IEEE 802.5

Родоначальником технологии ЛВС Token-Ring принято считать компанию IBM,
однако в действительности эта технология была запатентована еще в 1967 г. в Шве-
ции доктором Олафом Солдерблумом (Olaf Solderblum). Компания приобрела права
на эту технологию и с помощью фирмы Texas Instruments разработала соответствую-
щий набор микросхем и основные принципы функционирования сетей на базе тех-
нологии Token-Ring. Позднее компания IBM передала права на эту технологию орга-
низации IEEE, одна из рабочих групп которой в 1985 г. разработала и выпустила
спецификацию под номером 802.5, регламентирующую методы доступа к среде и спо-
собы передачи сигналов технологии Token-Ring со скоростью передачи данных 4
Мбит/с. Стандарт IEEE 802.5 определяет спецификации двух подуровней модели IEEE,
на которые подразделен канальный уровень модели OSI: уровень управления досту-
пом к среде (MAC layer. Media Access Control layer) в уровень управления логичес-
ким каналом (LLC layer, Logical Link Control layer); спецификация IEEE 802.5 опре-
деляет также спецификацию физического уровня. В 1989 г. институт IEEE выпустил
усовершенствованную спецификацию стандарта 802.5, обеспечивающую пропускную
способность 16 Мбит/с при передаче данных по сетям Token Ring.

В технологии Token Ring используется однонаправленный режим передачи дан-
ных (unidirectional transmission), который предполагает передачу данных между вхо-
дящими в состав сети устройствами последовательно от одного устройства к другому
(по кольцу). В сетях Token-Ring используется кольцевая топология с эстафетным до-
ступом (token-passing ring topology), а это значит, что только одно устройство может
выполнять передачу данных в один момент времени. Тем самым обеспечивается та-
кой процесс передачи кадров, при котором возникновение конфликтов невозможно
в принципе. С другой стороны, любое входящее в архитектуру Token-Ring устройство
имеет возможность получать доступ к среде передачи и выполнять передачу данных в
тот момент, когда это устройство получает в свое распоряжение свободный маркер
(free token). Маркер — эго кадр длиной три байга, передаваемый последовательно or
устройства к устройству по кольцу.

Технология Token-Ring обладает следующими важными свойствами

•	Все ycTpoiici ва, входящие в архитектуру Token-Ring, соединяются между собой пос-
ледовательно, передавая при этом сигнал в одном направлении

•	Передающая пара (transmit pair) каждою устройства соединяется с принимаю-
щей парой (receive pair) соседнего устройства.

•	Передача сигнала выполняется в одном направлении

•	Каждое устройство подключено к сети на основе физической звездообразной
топологии (a physical star formation) через центральный концентратор (central
hub), известный также под названием "Модуль множественною доступа"
(MSAU, Multi-Station Access Unit — см. рис.1.12). Назначение модуля MSAU —
создание физическом звездообразной топологии, которая служит основой пос-
ледовательной передачи сигнала по логическому кольцу. Кроме того, модуль
MSAL' позволяет поддерживать кольцо в рабочем состоянии посредством обхода
нерабочего устройства или порта и передачи сигнала но соединению в случае
отключения или повреждения конечных устройств.

РИСУНОК 1.12

Принцип действия
технологии Token-Ring.

Сеть Token-Ring

•	В архитектуре Token-Ring сетевой адаптер каждого компьютера действует в ка-
честве полнофункционального однонаправленного повторителя (fully functional
unidirectional repeater), который в полном объеме восстанавливает сигнал и та-
ким образом выполняет функцию повторения битов, передавая их следующему
устройству.

•	Технология позволяет передавать данные только с одной из скоростей — либо
4Мбит/с, либо 16Мбит/с, а именно — с той скоростью, которая определена кон-
кретной конфигурацией сетевой платы компьютера.

•	Все устройства, входящие в состав функционирующей на базе технологии Token-
Ring сети, должны договориться об используемой ими в пределах данного кольца
скорости передачи данных.

^ПОВТОРЕНИЕ БИТОВ

Термин "повторение битов" (beat repeating) используется для обозначения процесса уси-
ления (amplification) и восстановления (regeneration) принятого сигнала, который подлежит
передаче на интерфейсы других устройств.

Метод доступа к среде

Доступ устройств Token Ring к среде передачи данных осуществляется посредством
реализации метода эстафетной передачи маркера (token-passing method). Согласно это-
му методу устройство, в распоряжении которого имеется подлежащая передаче инфор-
мация, ожидает получения свободного маркера (кадра размером 3 байта, проходяще-
го по кольцу и предоставляющего право доступа к среде передачи). При получении
маркера устройство имеет возможность присоединить к нему полезную информацию,
преобразуя таким образом маркер в обычный кадр. Входящие в состав сети Token Ring
станции передают свои кадры по кольцу, надеясь на то, что в итоге они достигнут хоста
назначения. Каждое входящее в состав кольца устройство проверяет указанный в кадре
адрес получателя, чтобы определить, не предназначен ли этот кадр именно ему Пос-
ле этого устройство передает полученные данные дальше по кольцу. Ответственность
за удаление полезных данных из кадра и, соответственно, за освобождение маркера,
возлагается на хост-отправитель (прием кадра отправителем означает успешную пе-
редачу содержимого кадра в адрес получателя).

Структура кадров Token Ring

Существует два типа кадров Token Ring: кадр маркера (token frame) и кадр дан-
ных/кадр управления (data/command frame). На рис. 1.13 представлена структура кадра
маркера. Согласно этому рисунку, рабочие станции идентифицируют передаваемый
сигнал как свободный маркер по значению бита маркера (token bit), установленного
в поле управления доступом (AC. Access Control). Если шачение этого бита равно О,
передаваемый кадо идентифицируется как кадр маркера. Значения, устанавливаемые
в полях начального ограничителя (SD, Starting Delimiter) и конечного ограничителя
(ED, Ending Delimiter), просто обозначают начало и конец кадра На рис 1.14 пока-
зан формат кадра Token Ring, используемого для передачи данных и управляющих ко-
манд. Следует обратить внимание, что поле MAC/LLC, которое следует за полем ад-
реса отправителя (SA. Source Address), указывает на то, является ли данный кадр
кадром управления MAC (command frame, МАС) или кадром данных LLC (data frame,
LLC).

РИСУНОК 1.13

Кадр маркера длиной 3
байта перемещается но
кольцу. предоставляя
подключенным к этому
кольцу устройствам доступ
к среде передача.

SD Поле начального ограничителя
АС - Поле управления доступом
FC - Поле управления кадром
DA - Поле адреса получателя
SA - Поле адреса отправителя

MAC or LLC - Поле данных МАС или LLC
RIF - Поле маршрутной информации
Upper Layer Data - Данные протокола
верхнего уровня

FCS - Поле результата вычисления CRC
ED - Поле конечного ограничителя
FS - Поле статуса кадра

Кадр маркера

Поле начального	Поле управления	Поле конечного
ограничителя (SD)	доступом (АС)	ограничителя (ED)

SD = Начальным ограничитель кадра

АС = По установленным в битах поля управления доступом
значениям можно определить, является ли данный кадр
кадром маркера или кадром данных/кадром управления
ED = Конечный ограничитель

Кадр Token Ring

SD	АС	FC	DA	SA	МАС ог  LLC	RIF	Upper Layer Data	FCS	ED	FS

SD = Начальный ограничитель кадра

АС = Ло установленным в битах поля управления доступом значениям можно
определить, является ли данный кадр кадром маркера или кадром данных/кадром
управления

FC - Значение, установленное в поле управления кадром, определяет тип кадра:
кадр данных (LLC) или кадр управления (МАС)

DA = Адрес получателя

SA = Адрес отправителя

MAC or LLC = В случае кадров МАС в этом поле содержатся данные уроиня МАС. в
случая кадров LLC кадр содержит заголовок кадра 802.2 для идентификации
протоколов других уровней, для которых предназначается содержимое кадра
RIF = Поле маршрутной информации, существует только в случае использования
маршрутизация от источника с использованием мостов в качестве устройств
сопряжения (Source Route Bridging)

Upper Layer Data - Заголовки протоколов верхних уровней и собственно данные
пользователя

FCS = Результат вычисления CRC

ED = Конечный ограничитель кадра

FD = Поле статуса кадра - используется для определения факта распознавания и
копирования получателем передаваемого кадра

РИСУНОК 1.14 Структура кадра Token Ring и описание его полей.
FDDI и ANSI ХЗТ9.5

Технология FDDI (Fiber Distributed Data Interface, Распределенный интерфейс пе-
редачи данных по волоконно-оптическим каналам) — это одна из самых эффектив-
ных технологий локальных сетей, предоставляющая доступ к среде путем передачи
маркера. Технология FDDI стандартизирована Национальным институтом стандар-
тизации США (ANSI, American National Standards Institute) в спецификации X3T9.5.
Несмотря на то, что в FDDI используется та же схема М АС-адресации, что и в других
технологиях, технология FDDI существенно отличается от технологий Ethernet и Token
Ring. Основное отличие состоит в том, что FDD1 использует для ссылки на МАС-ад-
реса 4-ра.зрядиые символы (вместо использования 6-байговых МАС-адресов, как в
других технологиях). FDDI выполняет процедуру передачи маркера на базе стандар-
тной физической топологии "двойное кольцо" (dual-ring), которая обладает способ-
ностью к самовосстановлению (selfhealing redundancy) той части сети, в которой про-
изошел сбой. В случае возникновения какой-либо проблемы в первичном кольце
(primary ring) вторичное кольцо (secondary ring) используется в качестве резервного.
Если происходит сбой в работе какой-либо части первичного кольца, FDDI автома-
тически перенаправляет данные из первичного кольца во вторичное по одному или
двум адресам. Подобная процедура называется заворачиванием кольца (ring wrap). В
прежние времена технология FDDI была самым предпочтительным стандартом для
формирования сетевых магистралей, поскольку эта технология обеспечивает скорость
передачи данных до 100 Мбит/с; кроме того, в отличие от использующих медные про-
водники технологий, FDDI обеспечивает высокий уровень защищенности от элект-
ромагнитных помех (EMI, ElectroMagnetic Interference) и радиопомех (RFI. Radio
Frequency Interference). В сущности, передача сигналов по волоконно-оптическим
кабелям имеет ряд преимуществ перед передачей по общепринятым медным кабелям.
Среди этих преимуществ можно назвать, в частности, следующие:

•	Более высокая скорость передачи данных

•	Передача сигнала на |ребуемос расстояние практически без искажений

•	Болес высокий уровень помехоустойчивости как от EMI, так и от RFI

•	Способность к самовосстановлению, обеспечиваемая передачей данных по двум
кольцам в противоположных направлениях

^ПРИМЕЧАНИЕ

Как было отмечено выше, в прошлом технология FDDI была наиболее широко используе-
мым стандартом для формирования сетевых магистралей; однако в настоящее время в
большинстве случаев эту технологию вытеснили менее дорогостоящие технологии — Fast
Ethernet или Gigabit Ethernet.

Метод доступа к среде

Для передачи пакетов по сети в гехнолонш FDDI используется эстафетный доступ
к среде передачи. Партеры по коммуникации в сети FDDI получают доступ к физи-
ческой среде передачи (к кольцу) посредством маркера, который перемещается по
кольцу. Когда какой-либо узел предпринимает попытку передачи данных, он просто
захватывает маркер, передает свои данные и освобождает маркер. Следует обратить
внимание на то, что в отличие от технологии Token Ring, которая предполагает на-
личие только одного маркера в кольце в определенный момент времени. FDDI до-
пускает передвижение в рамках кольца нескольких маркеров одновременно.

^ПРИМЕЧАНИЕ

Несмотря на то, что в технологии Token Ring также был реализован некий механизм "ран-
него освобождения маркера" (early token release), призванный сделать возможной пере-
дачу данных несколькими устройствами одновременно, в действительности согласно этой
технологии к перемещению по кольцу допускается только один маркер.

Технологии организации глобальных сетей
(WAN)

В технологиях организации глобальных вычислительных сетей (WAN, Wide Area
Network) для передачи данных на большие расстояния используется то оборудование,
которое предоставляется коммерческими организациями-владельцами сетей связи (та-
кими как провайдеры сетевых услуг или телефонные компании). Технологии глобаль-
ных сетей функционируют на двух нижних уровнях модели OS1, а именно — на физичес-
ком и канальном уровнях (см, рис. 1.15).*

РбСУНС.<1.15

Отображение протоколов,
обеспечивающих работу
технологии организации
глоба 1Ы1ЫХ сетей, на
соответствующие им
уровни модели OSI,

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

Различные типы соединений, используемые для передачи данных в рамках глобаль-
ной сети, позволяют компаниям устанавливать соединение с географически удален-
ными хостами с целью расширения своих корпоративных сетей. Большинство компа-
ний, удаленные хосты которых расположены на больших расстояниях друг от друга,
нуждаются в обеспечении передачи данных между этими хостами в рамках глобаль-
ной сети по линии связи определенного типа. Выбор соединения того или иного типа
зависит от конкретных нужд компании. Для передачи данных через сеть провайдера
сетевых услуг Moiyr быть использованы три типа глобальных соединений:

•	Арендуемая (выделенная) линия. Арендуемая линия (leased line), известная так-
же иод названием "линия связи типа точка-точка” (point-to-point line), или выде-
ленная линия (dedicated line), используется для передачи данных с установле-
нием синхронного последовательного соединения (synchronous serial connection)
между взаимодействующими хостами через провайдера соответствующих услуг.

•	Соединение с коммутацией каналов. Коммутация каналов (circuit-switching)
обеспечивает передачу данных по выделенному каналу с установлением асин-

' Здесь автор не точен. Как правило. глоба шные сети охватывают три нижних уровня (физический, канальный и
сетевой), т к. основная задача сетевого уровня — маршрутизация — является прерогативой елооильных сетей —
прим. ред.
хронного последовательного соединения (asynchronous serial connection) через
телефонную компанию.

•	Соединение с коммутацией пакетов. Коммутация пакетов (packet switching)
обеспечивает передачу данных в адрес удаленного хоста с установлением пос-
ледовательного синхронного соединения (synchronous serial connection) с этим
хостом через провайдера сетевых услуг.

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

Таблица 1.6 Типы глобальных соединений, уровень 1

Тип соединения	Описание
Арендуемая линия (линия точка-точка, выделенная линия)	Обеспечивает единственный реально существующий глобальный канал связи между клиентом и удаленной сетью через сеть провайдера. Провайдеры сетевых услуг резервируют соединение и полосу пропускания для индивидуального использования клиентом. Гарантируется доступность полосы пропускания. Недостаток данного типа соединения: высокая стоимость, которая вытекает из необходимости сохранять соединение активным даже тогда, когда оно не используется. Арендуемая линия использует европейский стандарт для высокоскоростной передачи данных (45 Мбит/с). Данный тип соединения поддерживает инкапсуляцию данных на канальном уровне протоколами PPP, SLIP и HDLC.
Коммутация каналов	Выделенный канал формируется оперативно для каждого сеанса связи и обеспечивает соединение между отправителем и получателем только на время передачи данных. Коммутация каналов, как правило, используется для передачи данных в средах с минимальной необходимостью в передаче данных в адрес удаленного хоста в рамках глобальной сети.  Коммутация каналов используется для установления последовательных асинхронных соединений посредством стандартных телефонных линий или соединений ISDN. Коммутируемые каналы поддерживают инкапсуляцию данных протоколами PPP, SLIP и HDLC.
Коммутация пакетов	Коммутация пакетов — это один из способов коммутации, используемых для передачи данных в рамках глобальной сети. Согласно этому методу сетевые устройства совместно пользуются каналами связи типа точка- точка для доставки пакетов от хоста-отправителя в адрес хоста- получателя через сеть провайдера. Передача данных посредством коммутации пакетов предполагает установление временных виртуальных каналов (VC, Virtual Circuit) для обеспечения сквозного соединения между отправителем и получателем. Коммутаторы устанавливают виртуальный канал и используют мультиплексоры для предоставления клиентам возможности совместного доступа к этому каналу. Передача данных по сети с коммутацией пакетов — менее дорогостоящий способ, поскольку канал, по которому выполняется передача, не является выделенным. Коммутация пакетов предполагает установление последовательного соединения со скоростью передачи данных от 56 Кбит/с до стандартной скорости ЕЗ. Поддерживает инкапсуляцию Х.25, ATM и Frame Relay.

На рис. 1.16, 1.17 и 1.18 показаны различные типы глобальных соединений. Арен-
дуемая (выделенная) линия обеспечивает единственный реально существующий ка-
нал связи для передачи данных в рамках глобальной сети от клиента в адрес удален-
ной сети через сеть провайдера (см. рис. 1.16). На рис. 1.17 показан канал связи,
формируемый оперативно для передачи данных по глобальному соединению с ком-
мутацией каналов. На рис. 1.18 представлен пример передачи данных в рамках гло-
бальной сети с использованием коммутации пакетов.

PH7VHOK1.16

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

РИСУНОК 1.17

Передача данных по сетям с
коммутацией каналов
предполагает установление
и разрыв соединения для
каждого сеанса связи
между отправителем и
получите 1ем.

РИСУНОК 1.18

Пепедача данных по сетям с
коммутацией пакетов
предполагает такой
процесс пересылки пакетов
от одного узка к другому,
при котором капал связи
может быть занят mo.it,на
на время передачи.

Коммутация пакетов
В настоящее время провайдеры сетевых ycuiyi и телефонные компании moi у г пре-
доставить в распоряжение пользователя практически любой тип соединения для пе-
редачи данных по 1лобальной сети. Посредством маршрутизаторов можно получить
доступ к серверам, предоставляющим автоматическое соединение с коммутацией ка-
налов (circuit-switched dial-up connections) через стандартные аналоговые модемы.
Существует также возможность воспользоваться методом маршрутизации пакетов с ав-
томатическим установлением сеанса связи по требованию (DDR. dial-on-demand
routing) по аналоговым или цифровым (ISDN) линиям связи. С помощью модулей
обслуживания канала передачи данных (CSU/DSU) можно сконфигурировать выде-
ленные арендуемые линии, предназначенные для передачи стабильно больших объе-
мов информации по последовательным синхронным соединениям. Для установления
соединений с коммутацией пакетов, используемых в таких гсхполо1иях организации
глобальных сетей, как Х.25, ATM и Frame Relay, требуются устройства мулыиплекси-
ронания/демультиилексирования (Multiplexer/Dcmultiplexer, MUX/DEMUX), предо-
ставляющие совместный доступ к одному и тому же каналу. Любой из названных выше
методов применим для доставки данных через Провайдера сетевых услуг на рассре-
доточенные по всему миру удаленные хосты.

Протоколы инкапсуляции данных при передаче по
глобальной сети

Инкапсуляция данных при их пересылке в рамках глобальной сети (WAN
encapsulation) — это способ заключения пакета данных в такую оболочку, которая по-
зволила бы ему пересечь множество территориально рассредоточенных локальных се-
тей, объединенных в рамках одной глобальной сеги, на пути к пункту назначения. Фун-
кционирование всемирной сети Интернет базируется на использовании ряда
глобальных соединений различных типов, включая выделенные и временные линии
связи. Однако каким бы ли был тип соединения, данные локальной сети должны обя-
зательно быть инкапсулированы в кадры перед передачей по каналу связи глобаль-
ной сети. Для тою чтобы должным образом сконфшурировать приемлемый в той или
иной ситуации тип инкапсуляции на канальном уровне, необходимо правильно выб-
рать соответствующий протокол. Выбор протокола зависит от используемой гехноло-
гии организации глобальной сети; провайдер сетевых услуг должен предоставить в
распоряжение пользователя конкретную конфигурационную информацию, необхо-
димую для успешного подключения к сети провайдера и, соответственно, для получе-
ния доступа к каналам связи глобальной сети.

Интерфейс подключения к сети провайдера предоставляется протоколом HDLC
(High-Level Data Link Control, Высокоуровневый протокол управления каналом пе-
редачи данных). Протокол HDLC — зго наиболее широко используемый стандарт-
ный протокол модели OS1, который был разработан по образцу протокола SDLC
(Synchronous Data Link Control, Протокол синхронного управления передачей дан-
ных) компании IBM. Упомянутые протоколы обслуживают канальный уровень мо-
дели OSI. предоставляя приложениям верхних уровней ориентированные и не ори-
ентированные на установление соединения службы, необходимые для передачи
данных пользователя через глобальную сеть.
Большинство протоколов, обслуживающих передача данных по глобальной сети,
являются производными от протокола HDLC Поставщики сетевых услуг пользуются
рядом реализаций HDLC. не все из которых являются совместимыми. Например, ком-
пания Cisco имеет свою собственную реализацию HDLC, несовместимую с другими
реализациями. Протокол SDI.C компании IBM, предназначенный для использования
в среде SNA (Systems Network Architecture, Сетевая архитектура вычислительных си-
стем), по своим функциональным возможностям аналогичен HDLC и обеспечивает
ориентированную на соединение, надежную доставку данных между мини-компью-
терами и мэйнфреймами IBM, а также между их клиентами. Другие протоколы, та-
кие как протокол LAPB (Link Access Protocol Balanced, Протокол доступа к сбаланси-
рованному каналу связи) из серии протоколов Х.25, обслуживающий сеть ISDN
протока! LAPD (Link Access Protocol-D. Протокол доступа к цифровому каналу свя-
зи), и даже протокол LLC2 (Logical Link Control-2, Протокол управления логической
связью —2) — все эти протоколы представляю! собой сокращенные варианты прото-
кола HDLC. В таблице 1.7 представ юно описание основных протоколов инкапсуля-
ции при передаче данных в рамках глобальной сети.

Таблица 17 Осювные протоколы WAN-инкапсуляции

Тип протокола	Описание
Frame Relay  Два типа инкапсуляции:  •	Frame Relay  (инкапсуляция Cisco)  •	Frame Relay комитета	Устаназлиеает необходимое количество виртуальных логических каналов для передачи данных. Функционирует на канальном и физическом уровнях” Более эффективен, чем Х.25, поскольку не ориентирован на установление соединений и не реализует механизм обнаружения и исправления

IETF (тип инкапсуляции, ошибок. Технология Frame Relay поддерживает механизм

определенный в RFC 1490}	регулировки перегруженности канала передачи данных.
ISDN (Integrated Services Digital Network, Цифровая сеть связи с иетеграцией обслуживания)	Использует существующие телефонные линии для передачи данных различных типов звуковых, текстовых, цифровых, видео и др. Использует два типа каналов: D (data channel, информационный канал) и В (bearer channel, канал-носитель данных) По D-каналу передается служебная управляющая информация, по В-каналу — собственно данные пользователя. ISDN предоставляет два типа служб: BRI (Basic Rate Interface, Интерфейс передачи данных с номинал лей скоростью) — поддерживает скорость передачи данных до 144 Кбит/с: PRI (Primary Rate Interface, Интерфейс передачи данных с базовой скоростью) — поддерживает скорость 1,544 Мбит/с (в США, Канаде и Японии) и 2,04b Мбит/с (в странах Европы).
Х.25  I APB (Link Access Procedure Balanced, Протокол сбалансированного доступа к каналу связи) - обеспечивает инкапсуляцию данных для передачи по каналу управляющей информации	LAPB - это обслуживающий канальный уровень протокол входящий в состав стека протоколов X 25. Разработанный на основе HDLC, протокол LAPB представляет собой ориентированный на установление соединения протокол, который обеспечивает обнаружение и исправление ошибок на канальном уровне. Характеризуется высокой надежностью, но низким быстродействием. Это объясняется большим объемом непроизводительных затрат на поддержание соединений. Данный протокол целесообразно применять в случае, когда канал связи глобальной сети подвержен частому возникновению ошибок В настоящее время протокол LAPB в основном вытеснен технологией Frame Relay и другими стандартами организации глобальных сетей.

** Frame Relay функционируют на трех нижних уровнях модели OS! (сетевой, канальный и физический) — прим. ред.
Тип протокола

Описание

HDLC (High-level Data

Link Control,
высокоуровневой
протокол управления
каналом передачи данных)

PPP (Point-to-Point,
Протокол двухточечной
связи "точка-точка")

SLIP (Serial Line Internet
Protocol. Межсетевой
протокол для
последовательного канала)

ATM (Asynchronous
Transfer Mode,
Асинхронный режим
передачи)

Ориентированный на установление соединения протокол
канального уровня разработанный ISO. Не поддерживает сжатие
данных и аутентификацию. В HDLC организации ISO не
предусмотрена возможность идентификации типа протоколов,
данные которых пересылаются в кадре HDLC. Из этого следует,
что в одном кадре HDLC может передаваться информация только
одного протокола. Применение той или иной реализации
протокола зависит от поставщика сетевых услуг.

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

Разработан раньше, чем РРР. Поддерживает установление
двухточечных последовательных соединений на основе стека
протоколов TCP/IP Вытеснен протоколом РРР.

Международный стандарт технологии передачи данных на базе
коммутации ячеек данных фиксированной длины и
мультиплексирования. Поддерживает передачу трафика
различных типов (звуковых сигналов, видео и цифровых данных) с
разбиением потока данных на ячейки длиной 53 байта.
Использование ячеек фиксированной длины сокращает объем
непроизводительных затрат на обработку данных и время
прохождения сигнала по сети. Поддерживает высокую скорость
передачи данных по линиям из медных проводников или по
волоконно-оптическим кабелям, обеспечивая пропускную
способность от 1,544 Мбит/с (по линии Т1) до 622 Мбит/с (ОС-12).

Запросы на комментарии (RFC)

Технологии передачи данных на базе стека протоколов TCP/IP не являются чьей-
либо собственностью. Следовательно, информацию о протоколах и стандартах, а также
о самой стратегии обработки данных в процессе передачи нельзя приобрести вместе с
аппаратным или программным обеспечением у поставщика. Тем не менее, инфор-
мацию подобного рода можно найти в Интернете бесплатно в форме документов, офи-
циально принятых в сфере информационных техноло! ий. — в форме так называе-
мых запросов па комментарии (RFC. Request For Comments). Несмотря на то, что
производители аппаратного и программного обеспечения все-таки издают докумен-
тацию по своим продуктам, RFC предоставляют в распоряжение пользователей и раз-
работчиков базовые стандарты, в которых представлено описание функций различ-
ных сетевых протоколов, а также правила и способы их реализации. Поставщики, в
свою очередь, интерпретируют эти стандарты с точки зрения конкретных реализаций.

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

Содержание документов RFC может варьироваться от техническом документации
по применению протоколов до предложений о внесении изменений и даже до проек-
тов новых протоколов. Стиль поедставленных в RFC документов может также суще-
ственно отличаться — от сухого академического изложения материала до представле-
ния тех или иных идей в шутливом тоне. В каждой главе данной книги содержатся
ссылки на соответствующие документы RFC. В книге представлен также список RFC
с классификацией документов по темам. Этол список можно найти в приложении А,
Доступ к любому RFC можно получить через Web-сайг http://www.faqs. org/rtcs/.

Интернет и интранет

В сфере информационных технологий существует два термина, которые очень по-
хожи по звучанию и обозначаю” в чем-то похожие понятия Интернет (Internet) и ин-
транет (intranet). Однако, несмотря на всю схожесть этих двух терминов по смыслу и
по форме, их содержание все-таки отличается. Ингернег (с прописной буквы) в оп-
ределенном смысле можно назвать интранетом (с маленькой буквы) С другой сто-
роны, интранет ни в коем случае нельзя отождествлять с Интернетом. Интранет —
это корпоративный сетевой комплекс, состоящий из нескольких взаимодействующих
между собой на базе единого управляющего объекта (алгоритма) сетей. Интернет —
это функционирующая без централизованного управления глобальная сеть, позволя-
ющая многочисленным пользователям (хостам) из рассредоточенных по всему миру
организаций общаться между собой (обмениваться данными), используя при этом стек
протоколов TCP/IP Проще говоря, отличие между сетями интранет и Интернет зак-
лючается в следующем: интранет связывает в сетевой комплекс компьютеры и сети
одной компании; Интернет объединяет рассредоточенные по всему миру локальные
сети и хост компьютеры в одну глобальную вычислительную сеть

Организации, отвечающие за разработку
Интернет-технологий

Информационная индустрия находится в состоянии постоянного развития; новые
протоколы и стандарты, образно выражаясь, просто "витают в воздухе". Однако су-
ществует несколько групп, в обязанности которых входит управление разработкой и
реализацией Интернет-техноло!ни:

•	ISOC (Internet Society. Общество сеги Интернет) — некоммерческая организа-
ция. отвечающая за техническое развитие Интернета и привлечение новых
пользователей. В подчинении ISOC находится совет 1АВ.

•	IAB (Internet Architecture Board, Совет по архитектуре сети Интернет) — неболь-
шая группа добровольцев из разных стран мира, разрабатывающих стратегию
развития сети Интернет с точки зрения качества стандартов Интернета (ТСР/
1Р). Подчиняется ISOC.

•	IETF (Internet Engineering Task Force. Рабочая группа инженеров сети Интер-
нет) — небольшая, ориентированная на разработку стандартов группа сиециа-
листов, работающих по конкретным направлениям TCP/IP в частости и гло-
бальной сеги Интернет в целом. Каждое направление разрабатывается опель-
ной рабочей группой во главе с менеджером группы.

• IRTF (Internel Research Task Force, Рабочая ipynna по исследованиям сети Ин-
тернет) — группа, занимающаяся исследовательскими проектами по TCP/IP и
сети Интернет.

Резюме

Эталонная модель OSI разработана с целью обеспечения успешного взаимодействия
как однородных, так и разнотипных систем в рамках сети. Для поставщиков сетевых уснут
и производителей аппаратного и программного обеспечения модель OSI представляет
собой структурную основу организации вычислительных сетей. Модель OSI состоит из
следующих семи уровней: прикладной уровень, уровень представления, сеансовый уро-
вень, транспортный уровень, сетевой уровень, канальный уровень и. наконец, фи-
зический уровень.

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

Вопросы для повторения

1.	Почему модель OSI играет столь важную роль в сфере информационных техно-
логий, и как она была создана?

2.	Какой уровень модели OSI управляет коммуникационным диалогом (полнодуп-
лексным или полудуплексным) между различными службами?

3.	На каком уровне выполняется обработка ошибок и управление информационным
потоком, а также гарантированная доставка данных в пункт назначения?

4.	На каком уровне модели OS1 выполняется процедура коммутации пакетов?

5.	На каком уровне модели OSI функционируют протоколы IP и ICMP?

6.	Назовите четыре уровня модели DoD.

7.	Каковы две функции подуровня МАС канальною уровня?

8.	Какой протокол транспортного уровня не ориентирован на установление соеди-
нения?
Глава 2

IP-адресация

В данной главе рассматриваются следующие темы:

•	Преобразование из двоичной системы счисления в десятичную (binary to
decimal conversion)

•	IP-адресация (IP addressing)

•	Формирование подсетей (subnetting)

•	Трансляция сетевых адресов (NAT, Network Address Translation)

Преобразование из двоичной системы
счисления в десятичную

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

Привычное для пользователей представление чисел с помощью десяти уникальных
цифр от 0 до 9 (0,1,2,3,4,5,6,7,8 и 9) называется десятичной системой счисления (decimal
numbering system). Компьютеры могут распознавать только информацию, представлен-
ную в двоичной системе счисления (binary numbering system), сотласно которой любую
информацию можно представить в виде нулей (0 — отсутствие потенциала) и единиц (1 —
наличие потенциала). В отличие oi десятичной системы, для представления информа-
ции в двоичной системе счисления используется только две цифры вместо десяти (см.
рис. 2.J).

РИСУНОК 2.1

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

Двоичная система счисления

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

•	0 и 1

8 битов = 1 байт, например,
Для того чтобы двоичные числа были доступны для понимания пользователем, не-
обходимо преобразовать их в десятичную систему счисления. Байт (или октет) — мини-
мальная адресуемая единица памяти состоит из 8 битов; наибольшее десятичное значе-
ние байта равно 255. Каждый двоичный разряд (бит) может принимать только одно из
двух значений — 0 или I. Как показано на рис.2.2, десятичное значение каждого оче-
редного разряда (оз крайнею правого до левого) эквивалентно числу 2"1, где п — это
порядковый номер разряда (т. е. значение каждого очередного разряда в два раза боль-
ше значения предыдущего, начиная с единицы). Соответственно крайний справа раз-
ряд равен I, крайний слева — 128. Чтобы преобразовать любое число из двоичного
представления в десятичное, необходимо указанным выше способом вычислить де-
сятичное значение каждого двоичного разряда со значением 1, а затем суммировать
полученные значения. Максимально возможное десятичное число, которое можно
представить в одном состоящем только из двоичных единиц байте, равно 255
(128+64+32+16+8+4+2+1 =255).

На рис.2.2 проиллюстрирован процесс преобразования двоичного числа 10101100 в
десятичное следующим образом: 128+32+8+4=172.

^ПРИМЕЧАНИЕ

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

Рассмотрим рис.2.3 в качестве иллюстрации процесса преобразования десятичного
числа (17е>) в двоичное. Поскольку число 176 меньше 255, но больше 128, старшему раз-
ряду (соответствующему числу 128) необходимо присвоить значение 1. Разность между
176 и 128 составляет 48, а это — число, которое меньше 64 (седьмому разряду присваи-
вается значение 0) и больше 32 (шестому разряду присваивается значение 1) Разность
между 48 и 32 равна 16, а это значение равно десятичному значению пятого разряда;
следовательно, пятому разряду присваивается значение 1, а оставшимся разрядам — 0.
В итоге получено двоичное число 10110000, соответствующее деся гичному числу 176.

Преобразование из двоичной системы
счисления в десятичную

27Ч------------------------20

123	64 32 16	8	4 2	1
X	XXX	X	X X	X
1	0	1	0	1	1 0	0
	128 + 32 +	8 + 4	= 172	

РИСУНОК 2.2 Присвоенное тому или иному
биту значение I означает, что данный
разряд переведен е положение "Включено"

Преобразование из десятичной в двоичную
систему счисления

176

27**				20					
128	64	32	16	8	4	2	1
X	X	X	X	X	X	X	X
1	0	1	1	0	0	0	0

РИСУНОК 2.3 Единицами представлены
те разряды, которые образуют двоичный
аналог десятичного числа.

IP-адресация

В главе I. посвященной основным моделям и стандартам сетевых технологий, был
рассмотрен механизм присвоения МЛС-адресов (физических адресов) на канальном
уровне, а также то, как эти адреса позволяют уникальным образом идентифицировать
входящие в состав сети устройства. В данной главе рассматривается следующий уровень
модели OS1 — сетевой уровень (Network layer). Как упоминалось выше, сетевой уровень
отвечает за маршрутизацию сетевого трафика, а также за принятие решений о выборе
того или иного маршрута для передачи данных в пункт назначения. Принятие решений
о выборе маршрутов основывается на информации, которая содержится в 32- разрядном
IP-адресе пункта назначения (destination IP address) Описание формата IP-адресов пред
ставлено в RFC 950. Согласно этому документу IP-адрес представляет собой двухуров-
невую иерархическую адресную структуру (2-level addressing hierarchy) длиной 32 бита,
разделенную на две части (одна часть предназначена зля сети, другая — для хоста). За-
мысел такого представления IP-адреса состоит втом. чтобы логически подразделить этот
адрес, по меньшей мере, на две части, идентифицирующие сеть и устройство (такое как
маршрутизатор, например). В 1Р адерсе может быть выделена также третья часть, иден-
тифицирующая входящую в состав данной сети подсеть Выделение адресов подсетей в
схеме IP-адресации рассматривается более подробно ниже в данной главе.

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

Например, если вас спросят, тде вы живете, вы могли бы ответить просто "Сан-Фран-
циско" без дальнейшей детализации. По названию "Сан-Франциско" любой желающий
может определить местонахождение города, а также путь, по которому можно к нему
добра! ься С другой стороны, одно название юрода не поможет найти вас в этом горо-
де, поскольку в нем есть тысячи улиц (подсетей) и еще больше домов (хостов). Следо-
вательно, чтобы иметь реальную возможность найти вас, необходимо иметь более точ-
ную информацию. Что касается IP-адресов, opiавизованных согласно представленной
выше иерархической структуре, то по этим адресам достаточно ле! ко найти искомый
пункт назначения. Маршрутизатор использует те фрагменты IP-адреса, которые соот-
ветствуют сети и подсети, чтобы найти "город и улицу", на которую необходимо пере-
дать трафик. Как только передаваемая дейтаграмма достигнет "улицы" (подсети), марш-
рутизатор легко определяет путь дальнейшего продвижения дейтаграммы, поскольку
каждый "дом" (хост) имеет на указанной улице" (в подсети) свой собственный адрес
(IP-адрес хоста назначения).

Классы адресов

При разработке специальными рабочими труппами сообщества сети Интернет схе-
мы IP-адесации все 32-разрядные IP-адреса были разделены на классы на базе анализа
прогнозируемого применения этих адресов. Классы адресов позволяют четко разграни-
чить применение I P-адресов в рамках зарезервированного адресного пространства Суще-
ствует пять основных классов сетевых адресов: классы А, В, С, D и Е. Получить зареги-
стрированные Интернет -адреса можно через Американское бюро регистрации адресов
сети Интернет США (ARIN, American Registry for Internet Numbers). Организация ARIN
выделяет адреса и присваивает их сети отдельной компании или сети провайдера услуг
Интернета в зависимости от размера сети и соответствующего сеги такого размера класса
адресов.

Как и было предусмотрено сообществом сети Интернет с самого начала существова-
ния иерархической схемы IP-адресации, вся совокупность IP-адресов разделена на клас-
сы согласно значениям старших битов этих адресов и диапазонам выделенных для того
или иного класса IP-адресов. В таблице 2.1 представлена информация о параметрах IP-
адресов классов А, В, С.

Таблица 2.1 Параметры адресов классов А, В и С*

Параметры	Класс А (/8)**	КлассВ (/16)	Класс С (/24)
Размер	Предназначен для выделения адресов относительно небольшому количеству больших сетей, таких как сети правительственных» военных и исследовательских организаций, в состав которых входит множество хостов.	Предназначен для выделения адресов большому количеству сетей, в состав которых входит достаточно много хостов (как, например, в сетях компаний среднего размера).	Предназначен для выделения адресов сетям маленьких компаний. Класс С содержит большое количество адресов сетей с минимальным количеством хостов в составе одной сети.
Значения битов	В первом бите адресов класса А установлено значение 0.	В первых 2 битах адресов класса В установлены значения 10	В первых 3 битах адресов класса С установлены значения 110.
Диапазон значений	1 — 126	128— 191	192 — 223
Длина адреса сети	1 байт	2 байта	3 байта
Длина адреса хоста	3 байта	2 байта	1 байт
Количество адресов сетей	126	16 384	2 097 152
Количествоадресов хостов	16 777 214	65 534	254

‘Адреса классов Du Е имеют специальное предназначение. Сетевой адрес класса А. начинающийся с числа 127,
зарезервирован в качестве адреса обратной связи (обычно применяется адрес 127.0,0,1) и используется. как пра-
вило. для обслуживания работы каста, совмещающего функции клиента и сервера.

**В обозначениях /8, /16. /32, и т.д. числа 8, 16, 32 определяют количество битов в маске подсети.

Рассмотрим более подробно функции битов и их значения. Первых семь битов пер-
вого байта адреса класса А (самому первому биту присвоено значение 0) представляют
собой адрес сети (или идентификатор сети, NetID). Оставшихся 24 бита (3 байта) мож-
но использовать для однозначной идентификации множества адресов подсетей и входя-
щих в состав этих подсетей хостов (в случае если данная сеть разбита на подсети). Если
в данной сети не выделены подсети, оставшиеся три байта адреса класса А используют-
ся только для идентификации отдельных хостов, входящих в состав сети.
Адреса класса В начинаются с двух битов первою байта адреса, которым присвоены
значения соответственно 1 и 0. Оставшиеся 14 битов первого и второго байтов соответ-
ствуют адресу сети (идентификатору сети, NetID) Последних два байта адресов класса
В можно использовать для идентификации дополнительных подсетей (если сеть подраз-
делена на подсети) и/или хостов. Аналогично в адресах класса С первых три бита име-
ют значения соответственно 1, 1 и 0, а оставшиеся биты первых трех байтов (21 бит)
представляют собой идентификатор сети . Последний байт адреса класса С использует-
ся для идентификации подсетей и входящих в их состав хостов. На рис.2.4 показана
общая структура адресов классов А, В, С, D и Е.

РИСУНОК 2.4

Только адреса классов А, В
и С доступны для всеобщего
использования.

Классы IP-адресов

Класс	Диапазон значений первого байта	Маска по умолчанию
Класс А	1 to 126	255.0.0.0
Класс В	128 to 191	255.255.0.0
Класс С	192 to 223	255.255.255.0
Класс D	224 to 239	Адреса класса D используются для рассылки многоадресных и широковещательных сообщений
Класс Е	240 to 254	Зарезервирован

Адрес 127.0.0.1 зарезервирован для использования
в качестве адреса тестирования обратной связи

На рис.2.5 показаны двоичные форматы представления адресов различных классов.
Следует обоатить внимание на то, что в JP-адресах класса А 7 битов выделено для сети.
24 бита — для хостив; в IP-адресах класса В 14 битое — для сети, 16 битов — для хостов;
в IP-адресах класса С 21 бит — для сети, 8 битов — для хостов.

Пять классов адресов

РИСУНОК 2.5

Количество хостов и
подсетей, которым могут
быть присвоены IP адреса
того или иного класса,
зависит от того, какой
именно класс адресов
используется в данной
сети: класс А, В или С.

Класс А |р[ се*ь(7битов) | хост (24 бита)	|

Класс В [io] сеть (14 битов) | хост (16 битов) |

Класс С [ 1 10 |	сеть (21 бита)	| хост (8 битов) |

Класс D

1 1 1 0 |зарезервировано для трупповых адресов

Класс Е |l 1 1 1 0 |зарезервировано для использования в опытных целях

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

Класс А

Сетям класса А, или /8 (8-ми битовый регистрированный адрес), присваиваются IP-
адреса, имеющие следующий формат. Первый байт, старшему биту которого присвоено
значение 0, а оставшиеся 7 битов выделены для номера сети, зарезервирован для адреса
сети той или иной компании. Три последующих байта (24 бита, имеющие переменные
значения и администрируемые в рамках данной сети) выделены для адресов локальных
хостов данной сети. В обозначении "/8" класса адресов А цифра 8 определяет количе-
ство битов в маске подсети, соответствующих идентификатору сети. Согласно RFC 950
для сетей класса А выделен диапазон номеров от 1 до 126. Максимальное количество
сетей, которым могут быть присвоены адреса данного класса, определяется по формуле
27-2. Согласно этой формуле из максимально возможного количества адресов вычита-
ются два адреса, поскольку установленные в первом байте адреса класса А значения 0
не разрешено использовать в качестве адреса сети; кроме того, значение 255 (в двоич-
ном формате — значение 1 в каждом бите) зарезервировано в качестве широковещатель-
ного адреса.

Количество 126 — это отнюдь не такое большое количество сетей, как может пока-
заться на первый взгляд. Однако сравнительно небольшое число сетей, которым могут
быть присвоены адреса класса А, компенсируется большим количеством локальных ад-
ресов, назначаемых хостам на основании значений последних грех байтов. Если гово-
рить более точно, то общее количество хостов с адресами класса А можно определить
по формуле 2м-2. что равно 16 777 214 хостам в рамках одной сети. Согласно указанной
формуле снова вычитаются два адреса, поскольку адрес, в котором все 24 бита имеют
значение 1, является адресом широковещательной рассылки по всем хостам сети, а ад-
рес с установленным во всех 24 битах значением 0 не разрешено использовать в каче-
стве адреса хоста. Следовательно, адреса хостов в сети класса А могут находиться в ди-
апазоне от I.xxx.xxx.xxx до 126.xxx.xxx.xxx.

К классу адресов А можно отнести также адрес, который начинается с цифры 127,
однако этот адрес зарезервирован в качестве адреса обратной связи и не может быть ис-
пользован как стандартный сетевой адрес. IP-адрес 127.0.0.1 используется для проверки
правильности функционирования всех обслуживающих работу протокола IP устройств
путем тестового опроса этих адресов. Как правило, для этого используется программа
PING (прим, научн. редактора). Этот адрес сугубо формально можно отнести к классу
А, однако регистрационная служба ARIN не выделяет его в качестве адреса сети, по-
скольку этот адрес имеет специальное предназначение.
Класс В

Сетям класса В, или /16, присваиваются адреса, сформированные по той же базовой
формуле, которая представлена выше. Огличие состоит только в том, что в качестве иден-
тификатора сети службой ARIN присваиваются 14 битов первых двух байтов всего ад-
ресного поля. В обозначении "/16" класса адресов В цифра 16 определяет количество
битов в маске подсети, соответствующих идентификатору сети. Тем самым оставшиеся
два байта выделяются для идентификаторов хостов. Первым двум старшим битам пер-
вого байга адреса класса В присвоены значения 1 и 0. Максимальное количество сетей,
которым можно присвоить адреса класса В, равно 2м, или 16384. На основании значе-
ний последних 16 битов, выделенных для идентификаторов хостов, локальным хостам
можно выделить следующее количество адресов класса В: 2'6 — 2, или 65 534. Следова-
тельно, адреса хостов в сети класса В могут находиться в диапазоне от 128.0.ххх.ххх до
191.255.xxx.xxx.

Класс С

Сетям класса С, или "/24", присваиваются адреса, в которых три старших бита пер-
вого байга имеют значения соответственно 1, 1 и 0. В обозначении ”/24" класса адресов
С цифра 24 определяет количество битов в маске подсети, соответствующих идентифи-
катору сеги. Следуя той же базовой формуле для определения количества сетей и хос-
тов с адресами класса С, что и в предыдущих случаях, можно вычислить количество сетей
класса С (221, или 2 097 152) и локальных хостов, входящих в состав сеги класса С (28 —
2, или 254). Идентифицировать адрес класса С достаточно легко: если значение первого
байта адреса попадает в диапазон от 192 до 223, этот адрес является адресом класса С.

Классы D и Е

Как упоминалось выше, адреса классов Г) и Е не являются общедоступными. Регис-
трационная служба AR1N резервирует адреса класса D для многоадресных рассылок и
не присваивает адреса этого класса отдельным хостам, входящим в состав той или иной
сети. Адреса класса D начинаются с номеров, попадающих в диапазон от 224 до 239.
Адреса класса Е зарезервированы службой AR1N для использования в будущем. Эти
адреса начинаются с номеров, попадающих в диапазон от 240 до 254.

Зарезервированные адреса

Зарезервированные адреса могут быть предназначены для применения в некоторых
особых случаях. В число таких специфических адресов и диапазонов адресов, которые
остаются зарезервированными и имеют ограниченное применение, входят следующие
адреса:

•	255.255.255.255 Если все биты адресною поля заполнены единицами, это зна-
чит, что сообщение должно быть разослано по всем узлам сети и по всем сетям,
входящим в сетевой комплекс. Этот адрес используется для рассылки широкове-
щательных сообщений.

•	0.0.0.0 Если все биты адресного поля заполнены нолями, то это значит, что со-
общение направлено в адрес сети или хоста, адрес которых неизвестен. Как пра-
вило, такой адрес используется в качестве адреса по умолчанию для шлюза, яв-
ляющегося последним на маршруте к локальной сети.
•	127.0.0.1 Этот специальный адрес класса А используется для внутреннего пет-
левого тестирования. Данный адрес является адресом локального узла, следова-
тельно, через такой адрес не передается сетевой трафик.

Хотя IP-адрес 255.255.255.255 считается адресом широковещательной рассылки, рас-
пространяемой методом лавинной адресации по всем хостам сети (network-wide flooded
broadcast), маршрутизаторы не продвигают по сети широковещательные сообщения та-
кого типа, а локализуют их в рамках подсетей. Для того чтобы разослать широковеща-
тельное сообщение по всем хостам подсети или сети, необходимо присвоить всем би-
там адресного поля, соответствующим идентификаторам хостов, значение 1. Например,
для передачи широковещательного сообщения в адрес всех хосгов, входящих в состав
сети 131.107.0.0 класса В со стандартной маской 255.255.0.0, необходимо в качестве ад-
реса пункта назначения указать адрес 131.107.255.255.

Зарезервированные адреса выделяются соответствующими регистрационными служ-
бами для сетей частных компаний. В RFC 1918 определены следующие подклассы адре-
сов частных сетей:

•	10.0.0.0-10.255.255.255

•	172.16.0.0-172.31 255.255

•	192.168.0.0-192.168.255.255.

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

Многие компании предпочитают использовать в своих частных сетях адреса форма-
та Ю.х.х.х, поскольку такие адреса обеспечивают гибкость внутрисетевой адресации хо-
стов и подсетей. В адресах формата Ю.х.х.х для идентификаторов хостов выделено три
байта, что позволяет удовлетворить практически любые нужды компании в смысле при-
своения IP-адресов хостам, входящим в состав частной сети компании. Поскольку за-
регистрированные IP-адреса выделяются частным сетям компаний все реже, более обыч-
ным явлением становится использование внутренних схем адресации хостов частной сети
(use inside private addressing schemes). Наряду с такими схемами адресации применяют-
ся различные методы трансляции адресов (address translation methods), позволяющие ис-
пользовать один или два зарегистрированных внешних по отношению к данной сети
адреса для получения доступа к сети Интернет.

Процедура преобразования внутренних частных адресов во внешние зарегистриро-
ванные адреса (и наоборот) называется трансляцией сетевых адресов (NAT, network
address translation). Как правило, за выполнение процедуры NAT отвечает шлюз (марш-
рутизатор) или брандмауэр, связывающий сеть компании с внешним сетевым комплек-
сом или с Интернетом, где не разрешено применение частных адресов. Процедура NAT
рассматривается более подробно ниже в данной главе.

Сеть и маска подсети

В процессе изучения стека протоколов TCP/IP перед читателем может возникнуть
вопрос: "Что такое маска подсети и для чего она нужна?”. Ответ на этот вопрос доста-
точно прост: маска подсети — это такой адресный индикатор, который позволяет ко-
нечным хостам и маршрутизаторам определять способ пересылки дейта! рамм в адрес хо-
ста-получателя. Одним из таких способов является рассылка по всем хостам данной
локальной сети широковещательного запроса (shouting) на преобразование IP-адреса
хоста назначения в его МАС-адрес, по которому необходимо доставить дейтаграмму.
Предположим, что конечному хосту-отправителю известно, что хост-получатель нахо-
дится в данной локальной сети. В таком случае хост-отправитель может направить в
широковещательной рассылке по адресу всех хостов сети запрос протокола \RP (Address
Resolution Protocol, Протокол разрешения адресов) на определение по логическому IP-
адресу хоста на сетевом уровне соответствующего этому хосту МАС-адреса. Альтерна-
тивный способ доставки дейтаграммы в пункт назначения состоит в пересылке дейтаг-
раммы в пункт назначения через маршрутизатор или шлюз (routing). Предположим,
хосту-отправителю известно, что хост-получатель дейтаграммы входит в состав удален-
ной подсети или сети. В таком случае отправитель вынужден выполнить передачу кадра
через локальный маршрутизатор с использованием шлюза. Д|я того чтобы принять окон-
чательное решение по поводу выбора одного из указанных выше способов пересылки
дейтаграммы в пункт назначения, хост-отправитель использует локальную маску. Раз-
решение адресов и протокол ARP рассматривается более подробно в главе 4.

Для каждой сети того или иного класса по умолчанию выделена соответствующая мас-
ка. Как упоминалось выше, для адресов класса А используется маска по умолчанию
255.0.0.0 (/8). Адресам класса В соответствует маска 255.255.0.0 (/16). В данном случае
следует обратить внимание на то, что маска выделена путем включения первых 16 би-
тов (другими словами, путем присвоения каждому из 8 битов первых двух байтов зна-
чений 1) Если сложить десятичные значения каждого из битов первого и второго бай-
тов, каждому байту будет соответствовать значение 255. Последних 16 битов остаются
неиспользованными (эти биты установлены в значение 0) и предназначены не для при-
своения в качестве адреса сети, а для присвоения адресов подсетям и хостам.

Для адресов класса С по умолчанию используется маска 255.255.255.0 (/24). В этом
случае первых три байта адресного поля составляют сетевую часть адреса. Последних 8
битов не входят в состав маски и могут использоваться для присвоения адресов подсе-
тям и хостам. Предположим, хост 166.3.22.1 (адрес класса В) предпринимает попытку
установить соединение с удаленным Telnet-сервером 151.10.5.2 (еще один адрес класса
В). Важным обстоятельством является то, что хост-отправитель не имеет ни малейшего
представления о том, где на самом деле находится хост-получатель. Другими словами,
только по IP-адресу хоста-получателя нельзя определить путь к данному хосту. Посред-
ством IP-адреса нельзя также определить, входит ли хост назначения в состав данной
локальной сети.

Чтобы определить принадлежность хоста назначения к той же локальной сети, от-
правитель сравнивает маску подсети (subnet mask) хоста-отправителя с IP-адресом хос-
та-получателя. Предположим, что в результате такой процедуры сравнения отравитель
определяет, что хосг назначения находится в той же локальной сети; в таком случае хост-
отправитель может обратиться непосредственно ко всем хостам сети, отправив в их ад-
рес локальный ARP-запрос на преобразование логического адреса хоста назначения в
его МАС-адрес.
Принадлежность хоста назначения той же локальной сети определяется хостом-от-
правителем посредством процедуры поразрядного применения операции "И" (&). Эта
процедура предполагает поразрядное сравнение IP-адреса хоста назначения с маской
подсети хоста-отправителя). До завершения процедуры поразрядного сравнения хост-
отправитель не имеет информации о том, является ли хост-получатель локальным или
удаленным. (Процедура поразрядного применения операции & рассматривается ниже в
данной главе). Если отправитель устанавливает, что искомый хост не входит в состав
данной локальной сети (т.е. он является удаленным по отношению к хосту-отправите-
лю), тем самым он определяет невозможность достичь удаленного хоста посредством
рассылки локального ARP-запроса. Из этого следует, что хост-отправитель должен мар-
шрутизировать передаваемый кадр посредством его Пересы тки через локальный шлю-
зовой маршрутизатор. Чтобы передать дейтаграмму на маршрутизатор для ее дальней-
шего продвижения к пункту назначения, хост-отправитель должен знать МАС-адрес
локального шлюза. Возможно, хост-о травитель уже использовал данный шлюз раньше
и имеет необходимую информацию об этом шлюзе в своем кэше. В противном случае
перед выполнением дальнейших действий по продвижению дейтаграммы хост-отправи-
тель должен разослать локальный ARP-запрос на трансляцию IP-адреса шлюза в соот-
ветствующий МАС-адрес (см. рис.2.6).

РИСУНОК 2.6

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

Могу ли я разослать локальный широковещательный
ARP-залрос на разрешение адреса хоста-получателя
по всем хостам данной сети?

Или мне необходимо направить локальный
ARP-запрос на разрешение IP-адреса шлюза?

IP-адрес хоста-отправителя:

IP-адрес хоста-получателя:

166.3.22.1

151 10.5.2

Масга подсети хоста-отправителя- 255.255.0.0

Важно отметить, что неправильно сконфшурированная маска подсети может выз-
вать выполнение конечным хостом процедуры рассылки локального широковещатель-
ного ARP-запроса на разрешение IP-адреса хоста назначения, в то время как на самом
деле ему следовало бы направить такой ARP-запрос только на разрешение IP-адреса
шлюза, или наоборот. Предположим, например, что хост А и хост В входят в состав
одного и того же физического сегмента локальной сети. Пользователь, работающий на
хосте А (1Р-адрес 155.10.1.1), намерен связаться судаленным сервером Telnet. Для этого
он вводит IP-адрес соответствующего хоста — хоста В (IP-адрес 155.10.2.2). Однако хост
А не имеет возможности определить, входит ли хост В в состав того же сегмента ло-
кальной сети до тех пор. пока не будет выполнено сравнение IP-адреса хоста А с мас-
кой подсети хоста А.

Оба хоста имеют адреса класса В, а это означает, что первых два байга всего адрес-
ного поля соответствуют сетевой части адресов хостов А и В (155.10.0.0). Следователь-
но, маска подсети должна выглядеть таким образом: 255.255.0.0. В то же время маска
хоста А была сконфигурирована неправильно: 255.255.255.0. Исходя из этого, хост А
расценивает первых три (а не два) байта как идентификатор сети. Выполнив сравнение
некорректно сконфигурированной маски подсети с IP-адресом хоста В, хост А делает
вывод о том, что хост В является удаленным, поскольку сетевая часть IP-адреса этого
хоста (согласно выполненному сравнению) выглядит так: 155 10.2.0. Такой вывод вы-
нуждает хост Л выполнить маршрутизацию передаваемых дейта! рамм (разослать локаль-
ный широковещательный ARP-запрос на разрешение IP-адреса шлюза), а затем выпол-
нить дальнейшее продвижение дейта! рамм через шлюз, предназначенный для пересылки
дейтаграмм на хост В. На самом деле хост А должен был бы разослать по всем хостам
данной сети локальный широковещательный ARP-запрос на разрешение IP-адреса хос-
та назначения, а затем направить дейта! раммы непосредственно на хост В.

Если бы маска подсети хоста А была сконфигурирована должным образом, хост А
смог бы определить принадлежности хоста В той же подсети, в состав которой входит
он сам. Соответственно хост А просто выполнил бы рассылку локального широковеща-
тельного ARP-запроса на преобразование IP-адреса хоста В в его МАС-адрес. Далее хост
А передал бы дейтаграммы непосредственно на хост В без помощи шлюза. Однако хост
А делает неправильный выбор на основании некорректно сконфигурированной маски
подсети и, следовательно, пересылает кадр, который должен был бы быть локальным,
через шлюз (см. рис.2.9).

Предположим, что шлюз сконфигурирован правильно. В таком случае шлюз также
выполняет сравнение IP-адреса хоста назначения с маской подсети и определяет на ос-
новании этого сравнения, что хост В входит в состав той же локальной подсети. В та-
ком случае шлюз выполняет передачу кадра через тот же интерфейс, через который этот
кадр был принят. Шлюз отправляет также в адрес хоста А сообщение протокола 1СМР
(Internet Control Message Protocol, Протокол управляющих сообщений Интернета), со-
держащее уведомление о том, что существует более оптимальный путь для пересылки
данного кадра. (Протокол 1СМР и его сообщения рассматриваются более подробно в
главе 3; протоколы ARP и RARP рассматриваются в главе 4). Однако это не решает
проблему неправильного конфигурирования маски подсети на хосте А. Лучший способ
устранить эту проблему — исправить некорректно сконфигурированную маску; в про-
тивном случае хост А будет и далее пересылать локальные кадры через шлюз, в то вре-
мя как их можно было бы передавать непосредственно на локальные хосты данного
сегмента сети.

Поразрядное выполнение операции &

Процедура поразрядного применения операции & позволяет сравнить IP-адрес хос-
та назначения (см. рис.2.7 и 2.8) с маской подсети хоста-отправителя. Эта процедура вы-
полняется согласно набору определенных правил. Перед началом выполнения подоб-
ной процедуры необходимо преобразовать IP-адрес хоста назначения и маску подсети в
двоичный формат для того, чтобы было удобнее разобраться в самом процессе сравне-
ния. Итак, процедура поразрядного выполнения операции & осуществляется согласно
следующим правилам;

•	Если значения обоих разрядов (IP-адреса хоста назначения и маски подсети) рав-
ны 1. результат выполнения операции & равен 1.

•	Если значение одного из разрядов равно 0, а значение другого разряда равно 1,
результат равен 0.
• Если значения обоих разрядов равны 0, результат равен 0.

РИСУНОК 2.7

Значение I можно получить
в результате поразрядного
применения операции &
только тогда, когда
значения обоих разрядов (и
IP-artpeca хоста
назначения, и маски
подсети) равны 1

IP-адрес хоста назначения: 151.10.5.2

Маска подсети хоста-отправителя: 255.255.0.0

10010111.00001010.  Маска 11111111.11111111	00000101 00000010  00000000 00000000
10010111.00001010.  Идентификатор сети  151.10.	00000000 00000000

Рассмотрим рис.2.7 в качестве примера. Чтобы определить принадлежность хоста на-
значения той же локальной подсети, что и хост-отправигель, необходимо выполнить сле-
дующие действия:

1.	Сравнить IP-адрес хоста назначения с маской подсети хоста-отправителя. IP-адрес
хоста назначения — 151.10.5.2; маска подсети — 255.255.0.0.

2.	Преобразовать IP-адрес и маску подсети в двоичную форму.

3.	Нарисовать вертикальную линию, отделяющую фрагмент маски подсети, который
соответствует адресу сети, от того фрагмента, который соответствует адрес}’ хоста.

4.	Значения всех битов IP-адреса хоста назначения, которые соответствуют левому
фрагменту маски подсети, соответствуют идентификатору сети. В данном примере адрес
сети — 151.10.0.0 (часть адресного поля, соответствующая идентификатору сеги —
151.10.).

5.	Значения всех бигов справа от вертикальной линии соответствуют адресу хоста (в
десятичном представлении значения двух последних байтов — 5.2). Следует помнить
о том, что для маршрутизации трафика в пункт назначения маршрутизаторам необ-
ходим только адрес сети или подсети.

Рассмотрим рис.2.8 в качестве примера. Чтобы определить принадлежность хоста-от-
правителя тон же локальной подсети, что и хоста назначения, необходимо выполнить
следующие действия:

1.	Сравнить IP-адрес хоста назначения с маской подсети хоста-отправителя.

2.	Преобразовать 1Р-адрес 166.3.22.1 и стандартную маску подсети 255.255.0.0 в двоич-
ное представление, чтобы определить, какая часть адресного поля соответствует
идентификатору сети или подсети.

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

4.	Значения всех битов IP-адреса хоста назначения, которые соответствуют левому
фрагменту маски подсети, соответствуют идентификатору сети. В данном примере
это та часть адресного поля, которая соответствует идентификатору сети — 166.3.

5.	Значения всех битов справа от вертикальной линии соответствуют адресу хоста (в
десятичном представлении значения двух последних байтов — 22.1).

3 Зак. 768
РИСУНОК 2.8

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

IP-адрес и маска хоста А.

IP-адрес	=	166	. 3	22 . 1

маска	=	255	.	255	. О . О

10100110.00000011.00010110.00000001

11111111.11111111 оооооооо оооооооо

10100110.00000011 оооооооо. оооооооо

Маска

166.3.

В данном примере следует обратить внимание на то, что хост 5.2 не входит в состав
той же подсети, что и хост 22.1 подсети 166.3. Следовательно, хост А передает кадр на
локальный шлюз вместо того, чтобы направить его непосредственно на хост В. Далее
маршрутизатор передает кадр на хост В через смежный с ним сегмент.

РИСУНОК 2.9

Хоста А был
сконфигурирован с
неправильной маской
подсети и должен был бы
вместо пересылки
дейтаграмм через
локальный шлюз
направлять их
непосредственно на хост В,
который является
локальным хостом по
отношению к хосту А.

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

Выделение подсетей (примеры)

Предположим, в вашем распоряжении имеется функционирующая на базе стека про-
токолов TCP/IP сеть, и либо регистрационная служба AR1N, либо ваш Интернет-про-
вайдер присвоили этой сети IP-адрес определенного класса и соответствующую этому
классу адресов маску класса адресов по умолчанию. Первый из четырех байтов адрес-
ного поля данного IP-адреса определяет класс, которому принадлежит этот адрес и, со-
ответственно. сеть. Если адрес сети — 130.57.0.0, а маска по умолчанию — 255.255.0.0,
тогда этот адрес принадлежит классу В, а сеть, которой этот адрес присвоен, способна
поддерживать работу 65 000 хостов. Возможно, вам не нужна сеть, в состав которой
входит такое количество хостов. Вместо этого вы можете предпочесть разбиение боль-
шой сети на более мелкие, легко управляемые фрагменты (подсети), связанные между
собой шлюзами.
Процесс формирования подсетей заключается в разбиении сетей более крупных раз-
меров на небольшие подсети. Для того чтобы разбить сеть на подсети, необходимо за-
имствовать определенное количество битов из той части адресного поля, которая соот-
ветствует идентификаторам хостов, и присоединить эти биты к сетевой части адресного
поля. Для выполнения правильного разбиения сети более крупного размера на подсети
необходимо принять во внимание следующие факторы:

•	Сколько подсетей требуется в настоящее время для обслуживания вашей органи-
зации?

•	Сколько дополнительных подсетей может понадобиться в будущем?

•	Какое количество хостов должно входить в состав самой крупной подсети?

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

В качестве иллюстрации процедуры разбиения сети на подсети рассмотрим разбие-
ние сети с IP-адресом 130.57.0.0 и маской по умолчанию 255.255.0.0. Для того чтобы вы-
делить подсеть в данной сети, необходимо присоединить определенное количество раз-
рядов той части адресного поля, которая соответствует идентификаторам хостов, к
сетевой части адресного поля. Предположим, вам необходимо иметь в составе сети 254
подсети. Для выделения такого количества подсетей вам потребуется позаимствовать 8
битов из правой части адресного поля и использовать их для присвоения идентифика-
торов подсетям, входящим в состав сети 130.57.х.О (здесь символом "х" обозначены те 8
битов, которые были позаимствованы из правой части адресного поля). Такое действие
преобразует маску 255.255.0.0 в маску подсети 255.255.255.0.

В приведенном на рис.2.10 примере сеть 130.57.0.0 была разбита на несколько под-
сетей посредством заимствования 8 битов третьего байта и наложения маски на эти биты.
Начиная с этого момента при передаче трафика на тот или иной хост данной сети необ
ходимо указывать идентификатор той подсети, в которой находится хост назначения
(например. 130.57.1). Теперь вместо одной сети в распоряжении организации или ком-
пании имеется 254 удобные в работе подсети. Можно продолжить процесс заимствова-
ния разрядов из правой части адресного поля, чтобы увеличить число подсетей и умень-
шить количество хостов, входящих в состав одной подсети. Несмотря на то, что в данном
примере выполнено выделение только двух подсетей, сеть 130.57.0.0 может поддержи-
вать 254 подсети, что обеспечивает возможность увеличения количества подсетей дан-
ной сети в будущем. Если в той части адресного поля, которая соответствует идентифи-
каторам хостов, останется всего 1 байт, каждая из выделенных подсетей сможет
поддерживать работу 254 хостов.

Маска подсети, сформированная посредством расширения маски сети по умолчанию
за рамки границы сетевой части адресного поля, принятой по умолчанию для данного
класса адресов, называется маской подсети переменной длины (VLSM, Variable Length
Subnet Mask). Некоторые протоколы маршрутизации не распознают маски VLSM; сле-
довательно, могут возникнуть определенные трудности при пересылке дейтаграмм че-
рез маршрутизаторы, обслуживаемые этими протоколами, в адрес не поддающихся об-
наружению подсетей. Процесс маршрутизации рассматривается более подробно в главе
5, а протоколы маршрутизации — в главе 6.
РИСУНОК 2.10

Выделение подсетей в сети
класса В.

Сеть класса В

130. 57. 1.0

255.255.255.0

130. 57. 2 .0
255.255.255. 0

Номер Номер Идентификаторы
сети подсети хостов

Номер номер Идентификаторы

сети подсети хостов

Для того чтобы вычислить, сколько битов необходимо потаимствовать в правой ча-
сти адресного поля, прежде всего потребуется определить, на сколько подсетей должна
быть разбита данная сеть Предположим, требуется выделить 13 дополнительных под-
сетей в сети с 1Р а фесом класса С 192.3.1.0 с маской по умолчанию 255.255.255.0. Что-
бы определить количество разрядов, подлежащих выделению из правой части адресно-
го поля с целью формирования конкретного количества подсетей, необходимо
воспользоваться изображенной на рис.2.11 таблицей и выполнить на основании этой
таблицы следующие действия:

Таблица определения структуре адресного
поля для IP-адресов

65536 .	32768	16384	«192	<096	2048	1024	512 256 . 128 64 32 16 8 4 2 1

X X X X X	X X	ХХХХХХХХХ

РИСУНОК 2.11 С помощью такой таблицы молено спреде unit количество битов адресного поля,
подлелсащих выделению для идентификаторов подсетей и идентификаторов хостов.

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

2.	Из полученного значения вычесть 2 (такое вычитание подразумевает исключение тех
адресов, которые состоят только из 1 или 0 и, соответственно, не разрешены для при-
менения в качестве адресов подсетей).

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

Рассмотрим конкретный пример. Предположим, вам необходимо выделить в сети 13
подсетей. Чтобы определить требуемое при этом количество битов адресного поля, не-
обходимо:
I.	Закрыть последовательно справа налево значения I, 2, 4.

2.	На следующей позиции находится значение 8.

3.	Результат вычитания 2 из 8 составляет 6; следовательно, заимствование 3 бигов из
правой части адресного поля не позволяет получить требуемое количество подсе-
тей.

4. Закрыть еще один бит (в сумме количество закрытых бигов составит 4).

5. Следующее значение равно 16 (это значение, по меньшей мере, на 2 больше 13 —
требуемого количества подсетей).

6. Результат вычитания 2 из 16 составляет 14.

7. Полученное значение достаточно для формирования 13 подсетей в данной сети (см

рис.2.12).	Сколько битов мне нужно позаимствовать, чтобы получить I4 подсетей?
РИСУНОК 2.12  В приведенном на данном рисунке примере необходимо позаимствовать 4 бита.	27<	2°  128 64 32 16 8 4 2 1  X ХХХХХХХ 1111

8 + 4 + 2+ 1 = 15

15 - 1 - 14 подсетей

Ту же таблицу и тот же метод можно использовать для определения размера гой ча-
сти адресного поля, которая соответствует идентификаторам хостов. Следует обратить
внимание на то, что избранный способ разбиения адресного поля на части (соответству-
ющие идентификаторам подсетей и идентификаторам хостов) предполагает использо-
вание битов по их прямому назначению. Например, если в вашем распоряжении име-
ется всего 16 битов, и вы заимствуете 7 из них для подсетей, остается только 9 битов
для хостов. Если вы заимствуете 12 битов для подсетей, остается только 4 бита для хо-
стов. Расчет здесь достаточно прост. Чтобы определить количество подсетей, которые
можно получить в результате заимствования того или иного количества разрядов, мож-
но воспользоваться приведенной таблицей, а также описанным выше методом вычис-
ления.

После того как было определено, что для выделения 13 дополнительных подсетей
требуется 4 бита, необходимо расширить маску сети таким образом, чтобы включить в
нее и подсети (другими словами, необходимо сформировать маску подсети). Известно,
что маска по умолчанию для сети с адресом 192.3.1.0 имеет длину 24 бита (255.255.255.0);
эти биты остаются неприкосновенными. Для формирования маски подсети необходимо
выполнить следующие действия;

1.	Начиная с крайнего левого бита последнего байта (25-й бит, и т д.), отсчитать слева
направо 4 разряда.

2.	Суммировать десятичные значения отсчитанных битов: 128+64+32+16=240 (см.
рис.2.13).

3.	Маска подсети для 14 подсетей имеет значение 240. Стандартная маска сети класса
С должна быть преобразована таким образом, чтобы в нее входила также маска под-
сети.
РИСУНОК 2.13

Для формирования маски
подсети необходимо путем
суммирования значений всех
выделенных под эту маску
разрядов вычислить
значение маски подсети.

Какова моя маска для последне-
го байта?

27<----------------2°

i 32 1б] 8 4 2 1

X ХХХХХХХ
1111

128 + 64 + 32 + 16 = 240

4-разрядная маска = 240

В результате такого преобразования будет сформирована новая маска сети и подсе-
ти 255.255.255.240. Теперь в состав сети входит 14 удобных в применении подсетей
с адресами, в каждом из которых 4 бита отведено для идентификаторов хостов дан-
ной подсети.

Необходимо также определить диапазон адресов подсетей, доступных в рамках мас-
ки подсети 240. Существует два способа определения такого диапазона. Один и этих спо-
собов заключается в составлении таблицы всех возможных комбинаций битов, включен-
ных в маску подсети Для этого необходимо выполнить следующие действия:

1.	Составить таблицу всех возможных комбинаций 4 битов, зарезервированных для ад-
ресов подсетей.

2.	Вычислить десятичное значение каждой комбинации и суммировать полученные
десятичные значения. При этом важно не забыть вычеркнуть из списка те комбинации,

в которых все биты имеют значения 1 или 0.

3 14 полученных номеров — 16, 32, 48, 64, 80, 96,
112, 128, 144, 160, 176, 192, 208 и 224 - это ад-
реса подсетей, входящих в состав данной сети.

Другой способ вычисления диапазона адресов
подсетей состоит в выполнении следующих дей-
ствий:

1,	Использовать самое нижнее значение диапазо-
на значений маски подсети (16, начальное зна-
чение диапазона) в качестве базового значения.
Диапазон адресов всех других подсетей также
можно вычислять с применением этого базово-
го значения.

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

3.	В конкретных числах рассмотренный выше про-
цесс выглядит следующим образом: 16 + 16 = 32;
16 + 32 — 48; 16 + 48 = 64, и т.д.

Каков диапазон адресов подсетей?

ЕК]

128 64 32 16	8 4 2 1

ХХХХ ХХХХ

—6----9---6—9—6

16	0	0 0 1

32	0	0 1 0

48	0	0 1 1

64	0	1 0 0

80	0	1 0 1

96	0	1 1 0

112 0	111

128 1	0 0 0

144	1	0 0 1

160 1	0 10

176 1	0 11

192 1	10 0

208 1	1 0 1

224 1	1 1 0

-249--1---1--1—1-

РИСУНОК 2.14 На данном рисунке
изображен диапазон адресов подсетей,
входящих в состав сети. Следует
помнить о том. что все состоящие
только из 0 или 1 адреса не разрешены
Оля использования в качестве адресов
подсетей.
Далее необходимо вычислить количество хостов, входящих в состав одной подсети.
На количество хостов влияет тип класса адресов, к которому принадлежит адрес дан-
ной сети, а также количество выделенных для маски подсети битов. Поскольку в при-
веденном выше примере для подсетей было выделено 4 из 8 битов последнего байта,
остается только 4 бита для присвоения IP-адресов хостам. Процедура вычисления диа-
пазона адресов для 4 битов уже известна — она такая же. как и процедура вычисления
диапазона адресов подсетей. Следовательно, чтобы определить количество входящих в
состав подсети хостов (или диапазон адресов хостов), необходимо выполнить следую-
щие действия:

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

2.	Определить следующее значение (это значение равно 16).

3.	Из полученного значения вычесть 2; в результате вычитания будет получено значе-
ние, соответствующее количеству хостов, которым можно присвоить адреса на ос-
новании оставшихся 4 битов. Результат этой операции такой же, как и в случае с
подсетями (16 — 2= 14 — в составе подсети может быть 14 хостов).

4.	Чтобы определить правильный диапазон идентификаторов хостов для каждой под-
сети, необходимо прибавить 1 к начальному значению диапазона адресов подсетей
(например, 16 +1) и вычесть 2 из следующего значения (например, 32 — 2).

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

6.	Результат выполнения всех указанных шагов — диапазоны адресов хостов для каж-
дой подсети: 17-30, 33-46, 49-62, 65-78, 81-94, 97-110, 113-126. 129-142, 145-
158, 161-174, 177-190, 193-206, 209-222 и 225-238 (см. рис.2.15).

Правильно рассчитанные адреса хостов и
широковещательных рассылок

240 |

128 64 32 16 X X X X	8	4 2 1  X	X X X		
	Диапазон адресов хостов  17	-	30  33	46  49	62  65	78  81	94  97	110  113	126  129	142  145	158  161	174  177	190  193	206  209	222  225	238		Широковеща- тельные адреса 31  47  63  79  95  111  127  143  159  175  191  207  223  239
“0	0	0 V  16 0	0 0 1  РИСУНОК 2.15	32	0	0	1	0  На данном рисунке	48	0	0	1	1  изображены корректно	64	0	1	0	0  сформированные диапазоны	80	0	1	0	1  идентификаторов хостов и	96	0	1	1	0  широковещательных	112	0	111  рассылок.	128	1	0	0	0  144	1	0 0 1  160	1	010  176	1	011  192	1	10 0  208	1	1 0 1  224	1	1 1 0			
			
			
Следует обратить особое внимание на то. что адрес рассылки широковещательных
сообщений для каждой подсети равен значению, на единицу меньшему очередного но-
мера подсети. Например, адрес широковещательной рассылки для подсети 16 был бы 32
(32 — I. поскольку 32 — это уже адрес следующей подсети).

Как упоминалось выше, количество разрядов, выделяемых для маски подсети и для
идентификаторов хостов, зависит от класса адресов, к которому принадлежит адрес дан-
ной сети. В отличие от этого, процедура вычисления диапазона адресов подсетей и ад-
ресов хостов не зависит ог класса адресов. Рассмотрим адреса класса В, которым соот-
ветствует стандартная 16-разрядная маска сети (255.255.0.0) с дополнительными
4 разрядами, выделенными под маску подсети. Из оставшейся части адресного поля
12 битов можно заимствовать для дальнейшего выделения подсетей. Coiaaciio выпол-
ненным ранее вычислениям, в результате выделения дополнительных 4 битов можно по-
лучить 14 подсетей или хостов, в зависимости оттого, для чего используются эти биты.

Эта информация позволяет определить, сколько разрядов необходимо выделить для
того, чтобы расширить маску класса В по умолчанию. Для включения маски подсети в
маску по умолчанию необходимо 4 дополнительных бита. Таким образом, стандартная
маска по умолчанию преобразуется в маску 255.255.240.0. Стандартная маска была рас-
ширена на 4 бита третьего байта адресного поля. Следовательно, остается еще 12 битов
третьего и четвертого байтов для присвоения адресов хостам. С помощью упомянутой
выше таблицы вычисления можно определить, сколько хостов может входить в состав
одной подсети, если осталось 12 битов в той части адресного поля, которая соответствует
адресам хостов. Для этого необходимо закрыть все 12 позиций таблицы; значение сле-
дующей позиции равно 4096. Из этого значения необходимо вычесть 2 (4096 — 2 = 4094);
результат вычитания соответствует количеству хостов в каждой подсети данной локаль-
ной сети (см. рис.2 16).

РИСУНОК 2.16

Сеть класса В с IP-адресом
130.100.0.0 разбита на
подсети посредством
выделении дополнительных
4 битов третьего байта
адресного поли под маску
подсети (240).

MASK 255

хххххххх

255

ХХХХХХХХ

130	100	X

12 битое для хостов

. XX X X ХХХХ . ХХХХХХХХ

4 бита
для
подсетей

4 бита для подсетей = 14 подсетей

12 бит для хостов=4096-2 = 4094 хостов для кахщой подсети

Согласно приведенным выше вычислениям диапазон адресов подсетей сети класса
С, при условии, что под маску подсети выделено дополнительных 4 бита, выглядит сле-
дующим образом: 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208 и 224. Эти 14
чисел представляют собой адреса подсетей, входящих в состав данной сети. Теперь можно
определить корректные идентификаторы хостов, а также адрес широковещательной рас-
сылки для каждой подсети. Здесь придется выполнить представленный ранее метод
вычисления для другого значения. Для адресов класса С только 8 разрядов были дос-
тупны для выделения под маску подсети. В случае адресов класса В количество таких
разрядов равно 16, соответственно все вычисления необходимо выполнить именно на
базе этого значения.

Для сети класса В, когда маска подсети переходит границу между третьим и четвер-
тым байтами, как в приведенном выше примере (сеть 130.100.0.0, маска 255.255.240.0 с
выделенными из третьего байта 4 битами), процесс вычисления диапазона адресов хос-
тов несколько более сложен. Самый простой способ найти решение данной проблемы —
это использовать в процессе вычисления двоичные значения. Чтобы вычислить диапа-
зон адресов хостов в сети класса В, необходимо выполнить следующие действия:

1.	Преобразовать адрес первой подсети, входящей в состав данной сети (подсеть с наи-
меньшим адресом, 16, сети 130.100.16.0) в двоичное представление.

2.	Первое правильное значение идентификатора хоста, входящего в состав подсети, со-
ответствует минимальному из всех возможных идентификаторов хостов, которые
можно присвоить на основании значений разрядов адресною поля, выделенных для
присвоения 1Р адресов хостам.

3.	Определить максимально возможное значение (которое соответствует адресу широ-
ковещательной рассылки для данной подсети). После выполнения этой операции до-
статочно легко определить максимальное значение диапазона адресов хостов, по-
скольку это значение всегда на единицу меньше адреса широковещательной рассылки
для данной подсети.

4.	При переходе границы байта, значения разрядов каждого байта суммируются отдель-
но. Следует помнить о том, что в рамках каждого байта суммируются десятичные
значения только тех разрядов, двоичные значения которых равны 1.

3-й байт	4-й байт

4-разрядная маска 240

128 64 32	16 | 8 4 2	1	.	128	64 32	16 8 4 2	1

0	0	0)	10000.0	0	000001

5.	Чтобы определить первый корректный адрес хоста в подсети 16, необходимо поме-
стить значения 0 под каждой позицией бита в части адресного поля, соответствую-
щей адресам хостов, за исключением крайнего правого бита, который должен иметь
значение 1 Таким образом формируется минимальное значение адреса хоста в дан-
ной подсети. Следует помнить о том, что все биты той части адресного поля, кото-
рая выделена для адресов хостов, не должны быть установлены в 0, поскольку это
будет означать формирование некорректного идентификатора хоста.

6.	В каждом байте в отдельности суммировать десятичные значения всех битов, имею-
щих двоичное значение 1. В третьем байте есть только один бит со значением 1,
которое соответствует десятичному значению 16. Таким образом, значение данного
байта равно 16.

7.	В четвертом байте только последний бит имеет значение 1. Следовательно, первый
корректный IP-адрес хоста, входящего в состав подсети 16 сети 130.100, выглядит
следующим образом: 130.100.16.1 (см. рис.2.17).
Какой первый

корректный дент.1фикатор хоста для каждой подсети?

2S

Идентификаторы 128			64	32	16	8	4	2	1	 128	64	32	16	в	4	2	1	Первый корректный
	подсетей	X	X	X	X	X	X	X	X	. X	X	X	X	X	X	X	X	идентификатор хоста
	16	0	0	0	1	0	0	и	0	0	0	0	0	0	0	0	1	16.1
РИСУНОК 2.17	32	0	0	1	0	0	0	0	0	0	0	0	0	0	0	0	1	32.1
На данном рисунке представлена	48	0	0	1	1	0	0	0	0	0	0	0	0	0	0	0	1	48.1
	64  80	0 0	1  1	0 0	0  1	0  0	0 0	0  0	0  0	0  0	0  0	0 0	0 0	0 0	0  0	0 0	1  1	64.1  80.1
процедура вычисления	96	0	1	1	0	0	0	0	0	0	0	0	0	0	0	0	1	96.1
первого корректного идентификатора	112  128	0 1	1 0	1  0	1 0	0 0	0 0	0 0	0 0	0 0	0 0	0  0	0  0	0 0	0 0	0  0	1  1	112.1  128.1
хоста для каждой	144	1	0	0	1	0	0	0	0	0	0	0	0	0	0	0	1	144.1
подсети.	160	1	0	1	0	0	0	0	0	0	0	0	0	0	0	0	1	160.1
	176	1	0	1	1	0	0	0	0	0	0	0	0	0	0	0	1	76.1
	192	1	1	0	0	0	0	0	0	0	0	0	0	0	0	0	1	192.1
	208	1	1	0	1	0	0	0	0	0	0	0	0	0	0	0	1	208.1
	224	1	1	1	0	0	0	0	0	0	0	0	0	0	0	0	1	224.1

Далее необходимо на основании противоположного предельного значения тех битов
адресного поля, которые выделены для идентификаторов хостов, вычислить адрес ши-
роковещательной рассылки. Для этого необходимо присвоить всем 12 битам этой части
адресного поля значение 1, а затем суммировать десятичные значения всех битов с дво-
ичным значением 1 отдельно в третьем и четвертом байтах (см. рис.2.18).

3-й байт	4-й байт

4-разрядная маска 240

128 64 32	16 | 8 4 2	1	.	128 64 32	16 8 4 2	1

ООО 1	|	1	1	1	1	.	1	1	1	1	1111

Какой адрас широковещательной рассылки для каждой подсети?

|_240j Идентификаторы 128 64 32 16 В 4 2 1  128 64 32 16 В 4 2 1 подсетей ХХХХ X XXX- ХХХХХХХХ 16 0 0 0 1	1111-11111111  РИСУНОК 2.18	32	0	0	1 0	1	1 1 1	1	1 1 1 1 1 1 1  Адрес	48 0 011 1 111.1 1111111  широковещательной	64	0	1	00	1	111-1	1111111  рассылки	80	0	1	0 1	1	1 1 1 - 1	1 1 1 1 1 1 1  д	9601101111- 11111111  представлен  112 0 1 1 1	1	1 1 1 . 1 1 1 1 1 1 1 1  значениями /,	128	1	0	0	0	1	1	1	1	-	1	1	1	1	1	1	1	1  установленными в	144	,	0	0	,	,	,	,	,	.	,	,	,	,	,	,	,	,  каждомразряде	,ю	,	„	,	0	,	,	,	,	.	,  соответствующей	т у 0	1111-111111)1  идентификаторам	,92	1	!	0	0	1111-11111111  хостов части	208	1	1	0	1	1 1 1 1 - 1 1 1 1 1 1 1 1  адресного поля.	224	1	1	1	0	1 1 1 1 - 1 1 1 1 1 1 1 1	Адреса широковещательных рассылок для каждой подсети 31.255  47.255  65.255  79.255  95.255  111.255  127.255 143 255 159.255  175.255  191.255  207.255  223.255  239.255
Адрес широковещательной рассылки — 130.100.31.255. Это значение вычисляется пу-
тем суммирования десятичных значений всех имеющих значение 1 битов третьего, за-
тем четвертого байта. Далее достаточно легко определить максимально возможное кор-
ректное значение идентификатора хоста, которое всегда на единицу меньше адреса
широковещательной рассылки для данной подсети. Чтобы определить это значение,
необходимо установить в крайнем правом разряде адресного поля значение 0, а затем
снова выполнить процедуру суммирования. Таким образом определяется значение вер-
хней границы диапазона корректных адресов хостов подсети — 130.100.31.254 (см.
рис.2.19).

3-й байт	4-й байт

4-разрядная маска 240

128	64	32	16 |	8	4	2	1	128	64	32	16 8 4 2	1
0	0	0	1 1	1	1 1 1	1	1	I	1111	0
		Какое	корректное	максимальное значение		идентификатора	хоста для	каждой подсети?	

| 240 |

Идентификаторы 12В	64 32 16	8	4	2 1	.128	64	32	16	8	4	2 1	Максимальный
подсетей х	XXX	X	X	X X	. X	X	X	X	X	X	X X	корректный адрес хоста
16 0	0 0 1	1	1	1 1	. 1	1	1	1	1	1	1 0	31.254
32 0	0 1 0	1	1	1 1	. 1	1	1	1	1	1	1 0	47.254
48 0	0 1 1	1	1	1 1	 1	1	1	1	1	1	1 0	65.254
64 0	1 0 0	1	1	1 1	. 1	1	1	1	1	1	1 0	79.254
80 0	1 0 1	1	1	1 1	- 1	1	1	1	1	1	1 0	95.254
96 0	1 1 0	1	1	1 1	. 1	1	1	1	1	1	1 0	111.254
112 0	1 1 1	1	1	1 1	- 1	1	1	1	1	1	1 0	127.254 •
128 1	0 0 0	1	1	1 1	• 1	1	1	1	1	1	1 0	143.254
144 1	0 0 1	1	1	1 1	. 1	1	1	1	1	1	1 0	159.254
160 1	0 1 0	1	1	1 1	. 1	1	1	1	1	1	1 0	175.254
176 1	0 1 1	1	1	1 1	. 1	1	1	1	1	1	1 0	191.254
192 1	1 0 0	1	1	1 1	. 1	1	1	1	1	1	1 0	207.254
208 1	1 0 1	1	1	1 1	. 1	1	1	1	1	1	1 0	223.254
224 1	1 1 0	1	1	1 1	• 1	1	1	1	1	1	1 0	239.254

РИСУНОК 2.19 Как можно видеть по данному рисунку, корректный максимальный идентификатор
хоста той или иной подсети всегда на единицу меньше адреса широковещательной рассылки для
данной подсети, который вычисляется на основании установления значения 0 в крайнем правом
разряде адресного поля.

Объединение сетей, суммирование, агрегирование и CIDR

В сфере сетевой индустрии терминами "объединение сетей в суперсети" (supemetting),
"формирование суммарных маршрутных адресов" (route summarization), "агрегирование
маршрутов" (route aggregation) и "бесклассовая междоменная маршрутизация" (CIDR,
class interdomain routing) принято пользоваться как терминами, обозначающими различ-
ные сетевые технологии. В то же время не стоит разграничивать технологии, обознача-
емые этими терминами. В действительности все они описывают метод сокращения объе-
ма трафика обновления и размера таблиц маршрутизации посредством объединения
смежных IP-адресов в одну группу и назначения суммарного адреса-представителя всей
группы адресов.
Какой бы термин не был избран, обозначаемая им технология позволяет маршрути-
заторам делать объявления не об отдельных маршрутах, а об их совокупности, сокра-
щая гем самым количество сообщений об обновлении маршрутов (route updates), а так-
же уменьшая размер таблиц маршрутизации (route tables). В данной книге предпочтение
отдается термину "формирование суммарных маршрутных адресов”, поэтому как в дан-
ном разделе, так и во всей книге чаще всего используется именно этот термин.

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

Посредством хорошо продуманной схемы адресации организация ARIN присваива-
ет сетям адреса классов А. В и С таким образом, чтобы один суммарный адрес сети
идентифицировал все подсети, входящие в состав данной сети Безусловно, можно было
бы объявить в сети Интернет все адреса подсетей, но это не рекомендуется делать по
двум причинам: во-первых, это небезопасно с точки зрения зашиты данных от несанк-
ционированного доступа во-вторых, в этом просто нет необходимости.

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

С целью сокращения объема трафика обновления и уменьшения размера таблиц мар-
шрутизации для сети компании можно было бы реализовать технологию формирования
суммарных маршрутных адресов и в рамках инфраструктуры этон сети. Как правило,
процедура суммирования выполняется на той совокупности маршрутов, которые соеди-
няют локальные хосты сети компании с ядром этой сети: именно в этом секторе локаль-
ной сети актуальна проблема перегрузки каналов связи (link congestion) и рационально-
го использования ширины полосы пропускания (bandwidth capacity). Суммирование
множества IP-адресов в один адрес перед передачей информации в адрес хоста, находя -
щегося в центральном сегменте сети компании, дозволяет сократить трафик обновле-
ния. сохраняя при этом столь драгоценную ширину полосы пропускания.

CIDR

В сфере сетевых технологий термин “бесклассовая междоменная маршрутизация”
(CIDR) используется преимущественно для обозначения процедуры формирования сум-
марных маршрутных адресов, выполняемой на совокупности смежных адресов класса
С. Такой тип суммирования реализуется Интернет провайдерами или провайдерами
сетевых услуг, которым соответствующей регистрационной служоои (ARIN) выделена
группа смежных адресов класса С. Провайдеры, в свою очередь, выделяют эти адреса
своим клиентам.

$ ИНТЕРНЕТ-ПРОВАЙДЕРЫ И ПРОВАЙДЕРЫ СЕТЕВЫХ УСЛУГ

В большинстве случаев термины "Интернет-провайдер" (ISP, Internet Service Provider) и
"провайдер сетевых услуг" (service provider) являются взаимозаменяемыми. Однако между
этими терминами существует небольшое отличие. Термин "Интернет-провайдер" обозна-
чает компанию, которая предоставляет только услуги сети Интернет (отсюда и само на-
звание — Интернет-провайдер). В то же время провайдер сетевых услуг предоставляет и
услуги сети Интернет, и другие службы, не входящие в состав служб сети Интернет, такие
как Frame Relay или установление глобальных соединений.

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

Суммирование адресов в одну i руппу можно выполнять только тогда, когда эти ад-
реса являются смежными; при этом суммирование выполняется в двоичной системе. Рас-
смотрим конкретный пример формирования суммарного адреса. Предположим, сети
вашей компании присвоен адрес 130.100.0.0 класса В (маска по умолчанию — 255.255 0.0);
в состав сети входит множество внутренних подсетей. Для простоты рассмотрим под-
множество этих подсетей. Предположим, имеется х смежных IP-адресов; вместо объяв-
ления каждою адреса в отдельности вам необходимо сгруппировать эти адреса в группу
и объявить суммированный маршрут к подсетям этой i руппы. Для формирования такой
। руппы адресов требуется выполнить следующие действия:

1.	Преобразовать интересующие вас адреса из десятичного представления в двоичное
(см. таблицу 2.2).

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

Таблица 2.2 Формирование суммарных маршрутных адресов		
/Р-адрес	Маска	Двоичное представление десятичных значений /28	64	32	/6	8	4	2	/

130.100.16.0	255.255.255.0	0	0	0	1	0	0	0	0
130 100.17.0	255.255.255.0	0	0	0	1	0	0	0	1
130.100.18.0	255.255.255.0	0	0	0	1	0	0	1	0
130.100.19.0	255.255.255.0	0	0	0	1	0	0	1	1
130.100.20.0	255.255.255.0	0	0	0	1	0	1	0	0
130.100.21.0	255.255.255.0	0	0	0	1	0	1	0	1
130.100.22.0	255.255.255.0	0	0	0	1	0	1	1	0
130.100.23.0	255.255.255.0	0	0	0	1	0	1	1	1
IP-адрес	Маска	Двоичное представление десятичных значений							
		128	64	32	16	8	4	2	1
130.100.24.0	255.255.255.0	0	0	0	1	1	0	0	0
130.100.25.0	255.255.255.0	0	0	0	1	1	0	0	1
130 100.26.0	255.255.255.0	0	0	0	1	1	0	1	0
130.100.27.0	255.255.255.0	0	0	0	1	1	0	1	1
130.100.28.0	255.255 255.0	0	0	0	1	1	1	0	0
130 100.29.0	255.255.255.0	0	0	0	1	1	1	0	1
130 100.30.0	255.255 255.0	0	0	0	1	1	1	1	0
130.100.31.0	255.255.255.0	0	0	0	1	1	1	1	1

В действительности нет необходимости в преобразовании адресов из десятичного
представления в двоичное в полном объеме, поскольку значения двух байтов этих адре
сов совпадают (130.100), и рассматривать нужно только третий байт. Проанализировав
двоичное представление третьего байта адресного поля, можно сделать вывод о том, что
в дополнение к 16 битам первого и второ, о байтов во все адреса подсетей включены еше
и 4 бита третьего байта Это означает, что ко всем подсетям данной сети можно полу-
чить доступ через один суммарный IP-адрес 130.100.16.0 с использованием 20-разряд-
ной маски (16 битов для идентификатора сети и 4 бита для идентификаторов подсетей),
которая выглядит следующим образом: 255.255.240.0 (или /20).

Следует помнить о том, что смысл процедуры формирования суммарных адресов со-
стоит в сокращении потока сообщений об обновлении маршрутов. Предположим, ока-
залось так, что во всех адресах данной группы еще содержатся совпадающие комбина-
ции битов. Однако суммирование можно выполнять только на полностью совпадающих
комбинациях битов, а суммарным адресом должен быть адрес с самой длинной комби-
нацией. Можно было бы группировать отдельно взятые подмножества совпадающих
комбинаций битов, однако это привело бы к необходимости объявления каждой из этих
групп. Поскольку все 16 упомянутых выше сетей имеют в составе своих [Р-адресов 4
совпадающих бита, все эти сети можно объединить под одним адресом. Формирование
суммарных адресов для отдельных подмножеств всей совокупности адресов менее эф-
фективно и, следовательно, в таком суммировании нет необходимости.

РЕАЛИЗАЦИЯ ПРОЦЕДУРЫ ФОРМИРОВАНИЯ СУММАРНЫХ МАРШРУТНЫХ АДРЕСОВ

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

Трансляция сетевых адресов (NAT)

Термин "трансляция сетевых адресов" обозначает процесс преобразования незареги-
стрированных (частных) IP-адресов (о которых упоминалось выше в данной главе) либо
в единый зарегистрированный IP-адрес, либо в диапазон адресов, подлежащих исполь-
зованию в процессе взаимодействия с хостами сети Интернет. Ответственность за при-
своение зарегистрированных, подлежащих применению в рамках сети Интернет 1Р-ац-
ресов, возложена на регистрационную службу ARIN. В то же время 32-разрядная схема
79

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

Для решения проблемы постоянно сокращающегося количества подлежащих присво-
ению в официальном порядке зарегистрированных IP-адресов при резком возрастании
количества хостов сети Интернет потребовались новые схемы IP-адресации. Некоторы-
ми специалистами в сфере сетевых технологий было предложено следующее решение
проблемы: изменить текущую схему IP-адресации, увеличив количество разрядов от 32
до 128, что позволило бы сформировать большее количество доступных IP-адресов. В
сетевой индустрии существует много дискуссий по поводу такой обновленной схемы IP-
адресации, которая известна под двумя названиями:

•	IPNG (NG означает "next generation" (следующее поколение) — это название мож-
но отнести к профессиональному жаргону).

•	IPv6 (1Р версии 6).

Текущая версия протокола IP — версия 4. Несмотря на то, что в сфере сетевых тех-
нологий проблема применения IPv6 дискутируется постоянно, эта версия протокола 1Р
используется крайне редко, поскольку это повлекло бы за собой необходимость в пере-
формировании схем адресации каждым участником сети Интернет. Кроме того, для эф-
фективной реализации новой схемы адресации пришлось бы внести соответствующие
изменения в текущие протоколы маршрутизации и т.д. В то же время появились новые
решения проблемы IP-адресации — решения, которые позволяют сохранить существу-
ющие адресные структуры, сформированные согласно протоколу IPv4. Одним из таких
решений является NAT, процедура трансляции сетевых адресов.

В обязанности сетевого администратора входит активизация службы NAT и конфи-
гурирование маршрутизатора соответствующим образом (эта специфическая конфигу-
рация находится вне круга вопросов, рассматриваемых в данной книге). Маршрутиза-
торы, поддерживающие NAT, выполняют преобразование внутренних частных адресов
(имеющих, например, формат Ю.х.х.х) в зарегистрированные внешние IP-адреса. Такая
процедура преобразования адресов выполняется маршрутизатором каждый раз, когда
входящий в состав частной сети хост предпринимает попытку взаимодействия с одним
из хостов сети Интернет. Существует три метода трансляции сетевых: адресов;

•	Статическая (static) трансляция сетевых адресов (см. рис.2.20)

•	Динамическая (dynamic) трансляция сетевых адресов (см. рис.2.21)

•	Смешанный способ — сочетание статической и динамической трансляции.

РИСУНОК 2.20

На данном рисунке
представлена процедура
статического (вводимого
вручную) отображения
внутреннего сетевого
адреса во внешний [р-адрес
по принципу "один-к-
одному"

Статическое отображение адресов

NAT-таблица	
Внутренний	Внешний
частный адрес	зарегистрированный адрес

10.1.1.2	36.1.2.3
10.1.1.3	36.1.2.4
РИСУНОК 2.21

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

Динамическое отображение адресов

Внутренний частный адрес	Внешний зарегистрированный адрес:	Клиентский порт
10.1.1.2	36.1.2.3	1004
10.1.1.3	36.1.2.3	6002

Статическая трансляция адресов

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

Динамическая трансляция адресов

Динамическое преобразование адресов выполняется по принципу "много адресов на
один" пли "много адресов на несколько": совокупность внутренних адресов отобража-
ется на один внешний адрес или небольшой пул адресов (pool of addresses). Как прави-
ло, выделение небольшого пула внешних зарегистрированных адресов, подлежащих при-
менению в процессе трансляции любого из внутренних IP-адресов данной сети, входит
в обязанности сетевых администраторов. Поскольку для преобразования всех внутрен-
них адресов используется один внешний IP-адрес или небольшой пул адресов, сетевой
администратор должен уникальным образом идентифицировать каждый хост, входящий
в состав данной локальной сети.

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

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

изображен процесс занесения отображения частных адресов на один и	Внутренний частный адрес	Внешний зарегистрированный адрес:	Порт
тот же внешний адрес в	10.1.1.2	36.1.2.3	1004
па мять маршрутизатора.	10.1.1.3	36.1.2.3	6002

Непосредственно после выполнения отображения внутреннего адреса на внешний ад-
рес маршрутизатор использует этот адрес в заголовке IP в качестве IP-адреса хоста-от-
правителя или хоста-получателя. Хосту назначения неизвестно, что IP-адрсс хоста-от-
правителя — это на самом деле не его исходный адрес, а адрес, полученный в резулыаге
выполнения процедуры NAT. Однако для хоста-получателя это не имеет никакою зна-
чения. Когда хост-получатель отправляет свой ответ в адрес хоста-отправитечя. марш-
рутизатор выполняет обратное отображение внешнею адреса на внутренний адрес и вы-
полняет доставку ответа хоста-получателя в адрес исходною хоста. Поскольку процедура
трансляции адресов прозрачна для пользователя, существует прекрасная возможность,
с одной стороны, скрыть хосты и инфраструктуру той или иной сеги от внешнего мира,
а с другой стороны — обеспечить взаимодействие хостов локальной сети с удаленными
хостами.

Резюме

Базовая десятичная система счисления состоит из цифр 0, 1,2, 3. 4, 5. 6, 7, 8 и 9.
Компьютеры распознают только информацию, представленную в двоичной (базирую-
щейся на применении всего двух значений, 0 и 1) системе счисления. Для того чтобы
числа, представленные в двоичном формате, были доступны для понимания пользова-
телем, необходимо выполнить преобразование этих чисел из двоичной в десятичную
систему счисления.

На сетевом уровне осуществляется маршрутизация сетевого трафика. Решения о вы
боре маршрутов для передачи трафика принимаются на основании анализа 32-разряд-
ных IP-адресов. Сетевой адрес идентифицирует сеть или подсеть, входящую в состав ло-
кальной сеги. Адрес узла идентифицирует отдельное устройство, входящее в состав
данной сети.

Существует пять основных классов адресов: А, В. С, D и Е. Для широкого использо-
вания доступны только адреса классов А, В и С.
Маски подсетей помогают маршрути шторам и конечным хостам определять марш-
руты пересылки дейтаграмм. Если хост назначения входит в состав той же локальной
сети, что и хост-отправитель, МАС-адрес этого хоста определяется в результате рассыл-
ки по всем локальным хостам сети широковещательного ARP-запроса на разрешение IP-
адреса хоста назначения на сетевом уровне. Если хост назначения является уделенным
по отношению к хосту-отправителю, дейтаграмма направляется в адрес локального мар-
шрутизатора на базе шлюза.

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

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

Вопросы для повторения

1.	Назовите различные классы IP-адресов и диапазоны их значений.

2.	С какой целью используются маски подсетей?

3.	Чем отличается адрес сеги от адреса хоста?

4.	Какие IP-адреса запрещено присваивать в общем порядке? Для чего используются
эти адреса?

5.	Сколько разрядов в IP-адресе класса С используется для обозначения идентифика-
тора сеги9

6.	Сколько подсетей можно выделить в сети 193.1.1.0 с маской подсети 255.255.255.240
и сколько хостов может входить в состав каждой подсети?

7.	Определите маску подсети, если имеется IP-адрес 193.1.1.32 и адрес подсети /28.

8.	Назовите количество подсетей, которые можно выделить в локальной сети, а также
количество входящих в состав каждой подсети хостов, если маска подсети —
255.255.254.0.

9.	Сколько битов потребовалось бы позаимствовать в той части адресного поля сети
класса С, которая выделена для идентификаторов хостов, если вам необходимо иметь
в составе сети 19 хостов?

10.	Сколько битов потребовалось бы позаимствовать в той части адресного поля сети
класса В, которая выделена для идентификаторов хостов, если вам необходимо иметь
в составе сети 1000 хостов?

11.	Каков деся гичный эквивалент двоичного числа 10110111?

12.	Каков двоичный эквивалент десятичного значения маски подсети 201?
Глава 3

Протоколы сетевого уровня/
Протоколы Интернета

Данная глава охватывает следующие темы:

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

•	Фрагментация и сборка дейтаграмм

•	Сообщения протокола ICMP и их значения

Протокол Интернета (IP протокол)

Протокол Интернета (IP, Internet Protocol) выполняет большую часть работы в стеке
протоколов TCP/IP. Все протоколы и приложения, входящие в состав TCP/IP, выполня-
ют свои функции на базе протокола IP (в оригинале — "run on top of IP") и используют
его для логической адресации на сетевом уровне (logical network layer addressing), а так-
же для пересылки дейтаграмм между хостами Интернета. Протокол IP функционирует
на уровне Интернета (Internet Layer) коммуникационной модели Министерства оборо-
ны США (DoD, US Department of Defense) и на сетевом уровне (Network Layer) эталон-
ной модели взаимодействия открытых систем (OSI, Open System Interconnection). Про-
токол ICMP (Internet Control Message Protocol, Протокол управляющих сообщений
Интернета) является неотъемлемой частью протокола 1Р и использует дейтаграммы 1Р
в качестве средства доставки своих сообщений. Протокол ICMP будет рассмотрен ниже
в данной главе. На рис. 3.1 показано, к каким уровням относится протокол 1Р в эталон-
ных моделях обмена данными DoD и OSL

$ "КАК КУПИТЬ БИЛЕТ НА ПОЕЗД 1Р?"

Утверждение "Все протоколы и приложения TCP/IP функционируют на базе протокола
IP" (в оригинале — "run on top of IP") можно было бы образно интерпретировать так:
приложение или протокол "покупает" билет для поездки на поезде IP. Выражение "run on
top of" относится к профессиональному сленгу, и его действие распространяется не только
на протокол IP. В действительности его используют применительно к работе приложения
или протокола одного из верхних уровней модели OSI, который, в свою очередь, функ-
ционирует на базе протокола одного из нижних уровней (в данном случае протокола IP
на сетевом уровне).

JP — это не ориентированный на установление соединения протокол, следователь-
но, его возможности по обеспечению надежности доставки дейтаграмм весьма ограни-
чены. Это значит, что IP не гарантирует доставку дейтаграммы в пункт назначения, а
скорее предпринимает попытку успешной доставки (best effort delivery), а именно —
отсылает дейтаграмму адресату без дальнейших действий по обеспечению надежности
доставки с надеждой на то, что она достигнет пункта назначения. Протокол IP просто
формирует логические IP-адреса хостов отправителя и получателя на сетевом уровне и
выполняет отправку дейтаграммы, оставляя при этом обеспечение надежности достав-
ки в пункт назначения протоколам других уровней. Если возникает проблема с достав-
кой, то подключается протокол ICMP для формирования сообщений, которые отсыла-
ются отправителю дейтаграммы, указывая на саму проблему и обстоятельно объясняя
причины ее возникновения. Когда протокол IP обнаруживает ошибку в процессе дос-
тавки, он попросту отбрасывает дейтаграмму (удаляет ее из сети). Факт отбрасывания
дейтаграммы протоколом IP является для ICMP основанием направить по адресу хос-
та-отправителя сообщение с указанием того, какая именно проблема возникла при пе-
ресылке дейтаграммы и по какой причине. Как уже было отмечено, решение вопроса
обеспечения надежности доставки данных протокол 1Р оставляет за протоколами верх-
них уровней — например, за протоколом TCP, который более подробно рассматривает-
ся в главе 8.

РИСУНОК 3.1

Протокол IP обеспечивает
для всех протоколов
семейства TCP/IP
логическую адресацию, а
также не ориентированную
на установление соединения
доставку дейтаграмм.

Модель DoD

Модель OSI

Основной функцией протокола IP является лошческая адресация хостов на сетевом
уровне (logical network layer addressing) и передача данных в форме дейтаграмм между
хостами (более подробные сведения об IP-адресации изложены в главе 2). Протокол IP
выполняет также и другие, но не менее важные функции, такие как фрагментация
(fragmentation) и сборка (reassembly) дейтаграмм. Необходимость в реализации этих фун-
кций IP возникает в случае, когда хост-отправитель пытается переслать дейтаграмму
слишком большого размера и ее нужно разбить на 6oj.ee мелкие фрагменты. Поскольку
IP — это не ориентированный на соединение протокол, он не требует установления со-
единения между хостами. Этот протокол не упорядочивает передаваемых сегментов
данных, не генерирует подтверждений получения и не управляет потоком данных меж-
ду хостами. Протокол 1Р обращается с каждой дейтаграммой как с отдельно взятым
объектом; он просто присоединяет к дейтаграмме IP-адреса и отсылает ее с надеждой
на то, что она достигнет пункта назначения. Протокол IР получает поток данных от LD?
или TCP, разбивает полученные данные на части, адресует и пакетирует каждую отдель-
ную часть в форме дейтаграммы, которую можно пересылать далее по сети по адресу
хоста-получателя. Маршрутизаторы (routers) и протоколы маршрутизации (routing
protocols) определяют оптимальный путь (path) между конечными хост-компьютерами
1более подробно вопрос маршрутизации рассматривается в главах 5 и 6).
$ RFC 791

RFC 791 определяет протокол IP его поля и функциональные возможности. В данной главе
анализируется заголовок IP (IP header) и его поля (fields), а также рассматриваются другие
протоколы уровня Интернета. Вопросы маршрутизации в IP рассматриваются в главах 5 и 6.

Заголовок дейтаграммы IP

На рис. 3.2 представлен заголовок дейта!раммы IP в формате, который специфици-
рован документом RFC 791. Минимальная длина заюловка дейтаграммы IP (IP header)
составляет 20 байт, если не используются дополнительные параметры (options). На рис.
3.3 показано, как анализатор протоколов Sniffer (Sniffer protocol analyzer) интерпрети-
рует заголовок IP. Каждое поле заголовка дейтаграммы описано более подробно ниже.

РИСУНОК 3.2

Заголовок дейтаграммы IP
обеспечивает
идентификацию логических
адресов отправителя и
по гучателя на сетевом
уровне.

1 II Версия	Длина заголовка	III 1 Til  Тип сервиса	1 1 1 1 1 1 1 1 1 1 1 1 1 1 1  Длине дейтаграммы		
!“1 Iй"	1 1 1    ।	“Ь'Т 1 1 "F“l"t  Тдентификация ।		।  а 1.1	1	1  Флаги II	Т I 1	1	1	1	1	1 I 1	1	1  Смещение фрагмента -J—1	1 _1—1—I—Д _1	В	я—|			
—।—।—।—।—।——।—  Время жизни .11	 i i...i	।		Протокол 1 а 	  t 1		1	।		Контрольная сумма заголовка  1 а а 1 а а—t i i——a a.	
I	।	।—  >	1 		"1 "1* • 1 'Т 11  IP-адрес отп  	 « 	1—1	а а	равителя  * * а—1—1—1			i 1 1 t f 1 1 t
1 '! 1  । 	।	। I	।	।	।	•	।	।	»	।	।	।	।  IP-адрес получателя  	। i	।	।		1			j	।	1	।	1			1	1	1	I  f.	f	|	|. _|	1 1 1 1 1 1 I  1 1 11—II J
“т-Т“г=1  1 1 1	Дополнительные параметры  । 1 1 1 1 1 1 1 1 1 1 I t 1			1111	Заполнение  1 1 J_ 1 1 I 1..

РИСУНОК 3.3 Следует обратить внимание на то, что в поле Etertype в заголовке протокола управления
канальным уровнем DLC ( Data Link Control header) установлено значение 0x0800 (IP), а это означает,
что в качестве протоко ia для дальнейшей передачи данного кадра по сети избран протокол !Р.
Рассмотрим более подробно заголовок IP, изображенный на рис. 3.3. В первом поле
(Version) должна быть указана версия протокола IP; в настоящее время используется вер-
сия 4, являющаяся официальным стандартом. Далее следует поле длины заголовка (1HL,
Internet Header Length), в котором указана минимальная допустимая длина заголовка IP,
равная 20 байтам. В поле типа сервиса (ToS, Type of Service) чаще всего указывается
значение 0 (как в данном примере), поскольку это поле в настоящее время применяет-
ся редко. Однако наблюдается тенденция к изменению подобной ситуации, поскольку
производители все чаще успешно реализуют возможности поля ToS в своих продуктах.
Появляются новые приложения, способные использовать биты поля типа сервиса для
того, чтобы выбрать оптимальный способ обработки маршрутизатором пересылаемых в
сети дейтаграмм. Эта возможность позволяет подобным приложениям запросить от мар-
шрутизатора определенного уровня типа сервиса ToS для передаваемых данных.

На рис. 3.3 суммарная длина дейтаграммы, указанная в поле длины дейтаграммы
(Total Length), составляет 40 байт. В это значение включается длина заголовка IP и бло-
ка данных, пересылаемого в пределах данного кадра. Поле идентификатора дейтаграм-
мы (ID, Identification) в данном примере имеет значение 25276. Следует обратить вни-
мание на то, что согласно значениям битов 1 и 2, установленным в поле флагов (Flags),
дейтаграмму можно при необходимости фрагментировать (бит 1:0 = May fragment), и в
данном примере это — последний фрагмент дейтаграммы (бит 2: 0 = Last fragment).
Поскольку в поле смещения фрагмента (Fragment Offset) установлено значение 0, мож-
но сделать вывод, что это — первый, последний и единственный фрагмент дейтаграм-
мы в пределах данного потока.

Текущее значение поля времени жизни (TTL, Time То Live) в данном примере рав-
но 59 секундам. Это значение ограничивает время присутствия дейтаграммы в сети.
Согласно значению, установленному в поле типа протокола, (Protocol) следующим про-
токолом, использующим данный кадр для дальнейшей пересылки данных, является про-
токол TCP. IP использует значение, установленное в поле контрольной суммы (Header
Checksum) для обнаружения повреждения кадра. В качестве логического IP-адреса хос-
та-отправителя указано значение 36.56.0.152, а в качестве логического IP-адреса хоста-
получателя — значение 36.53.O.2O3.

Поле версии протокола IP

Значение поля версии IP (Version), имеющего длину 4 бита, определяет реализуемую
в данном процессе передачи данных версию протокола IP. Это значение в большинстве
случаев равно 4, поскольку версия 4 протокола IP является самой распространенной на
данный момент.

Поле длины заголовка IP

Поле длины заголовка IP (IHL, Internet Header Length), длина которого равна 4 би-
там, определяет размер заголовка дейтаграммы IP в 32-разрядных словах. Все заголов-
ки IP должны иметь длину минимум 20 байт (пять 32-х разрядных слов —прим, ред.),
если в поле дополнительных параметров (Options) не реализуется ни одна из дополни-
тельных возможностей. Более подробно поле дополнительных параметров рассматри-
вается ниже в данной главе.
Поле типа сервиса

Поле типа сервиса (Type of Service, ToS) заголовка IP (8 битов) может повлиять на
выбор пути, по которому маршрутизаторы пересылают дейтаграммы между двумя ко-
нечными системами. Биты, содержащиеся в поле ToS, позволяют приложениям и про-
цессам верхних уровней запросить от маршрутизатора определенного уровня качества
обслуживания информации. От типа предоставляемого протоколом IP сервиса зависит
способ обработки дейтаграмм. До недавнего времени поле ToS полностью игнорирова-
лось. Однако сейчас многие компании реализуют возможности, предоставляемые этим
полем, для обеспечения более интеллектуального выбора пути пересылки дейтаграмм.
Если поле типа сервиса не используется, ему присваивается значение 0. Поскольку при-
менение поля ToS — явление редкое, "О" является наиболее вероятным значением би-
тов этого поля. Документы RFC 1340 и RFC 1349 предоставляют подробное описание
целевого применения и функций различных битов поля типа сервиса. Ниже в данном
разделе представлено краткое описание этих битов.

Биты 0 — 2: биты приоритета

Биты 0 — 2, другими словами биты приоритета (Precedence Bits), устанавливаемые в
указанные ниже значения, определяют различные уровни приоритета. Как правило, толь-
ко правительственные организации применяют значения битов приоритета для опреде-
ления важности передаваемой дейтаграммы. Активизация этих битов влечет за собой при-
менение поля дополнительных параметров заголовка IP (рассматриваемого ниже в
данной главе) для дальнейшего определения требуемого уровня приоритета. Как пра-
вило, значения битов приоритета определяют уровень безопасности (security level) со-
гласно требованиям разведывательного управления Министерства обороны США
(Defense Intelligence Agency). В таблице 3.1 дано описание набора различных битов при-
оритета.

Таблица 3.1 Биты 0 — 2: биты приоритета

Значение	Описание
ООО	Обычно (Routine information)
001	Приоритетно (Priority information)
010	Срочно (Immediate delivery)
011	Немедленно(Е1аб11)
100	MrHOBeHHO(Flash override)
101	Критические данные (CRITIC/ECP) (Critical information)
110	Межсетевое управление (Internetwork control)
111	Сетевое управление (Network control)

До недавнего времени большинством приложений биты приоритета не поддержива-
лись или не использовались. Однако эти биты применяются в реализациях сетей прави-
тельственных организаций, для которых требуется обеспечение многоуровневой систе-
мы безопасности. Более подробную информацию по вопросам приоритетности можно
получить в главе 8. Организация, которая принимает решение воспользоваться возмож-
ностями битов приоритета при пересылке данных, должна точно определить специфи-
кации этих битов, а именно — их значения и область их применения.
Следующих три бита поля типа сервиса — это биты, наиболее часто используемые
для воздействия на характеристики прохождения трафика данных по сети.

Бит 3

Бит 3 может иметь одно из следующих двух значений:

•	0 = нормальная задержка (Normal delay)

•	1 = Минимальная задержка (Low delay)

Эти значения устанавливаются в зависимости от величины задержки сквозного рас-
пространения (продвижения) данных между конечными хост-компьютерами (end-to-end
propagation delay)- Если в сети существует множество путей передачи данных адресату,
приложение может ориентировать маршрутизаторы на передачу данных по пути с ми-
нимальной задержкой, т.е. по наиболее быстрому маршруту.

Бит 4

Бит 4 может принимать одно из следующих значений:

•	0 = Нормальная пропускная способность (Normal throughput)

•	1 = Максимальная пропускная способность (High throughput)

Если для передачи данных приложению нужен канал с высокой пропускной способ-
ностью, значение данного бита устанавливается в 1. В этом случае маршрутизаторы на-
правляют трафик по маршрутам, которые обеспечивают максимально высокую скорость
передачи данных, исходя из значения производительности полосы пропускания
(bandwidth capacity) канала связи между конечными системами.

Бит 5

Бит 5 может иметь одно из следующих значений:

•	0 = Нормальная надежность (Normal reliability)

•	I = Максимальная надежность (High reliability)

Маршрутизаторы измеряют надежность канала связи количеством встречающихся
ошибок, а также количеством утерянных при пересылке по тому или иному интерфей-
су дейтаграмм. Если существуют несколько путей с различными характеристиками на-
дежности передачи данных по сети, то маршрутизатор перенаправляет трафик прило-
жений по пути с максимальной надежностью, устанавливая значения бита 5 равным 1.
Такой тип обслуживания может потребоваться для выполнения критических приложе-
ний, не допускающих возможность потери данных.

Биты 6 и 7 (зарезервированные)

Биты 6 и 7 зарезервированы для использования в будущем.

Приложения или процессы верхних уровней могут обратиться к маршрутизаторам с
запросом на доставку своих данных по маршрутам, отвечающим определенным требо-
ваниям к типу сервиса. Для того чтобы выполнить доставку данных согласно требова-
ниям, заданным в поле ToS, все маршрутизаторы и протоколы маршрутизации в пути
между двумя конечными хост-компьютерами должны быть сконфигурированы таким об-
разом. чтобы они могли распознавать биты поля ToS и пересылать дейтаграммы соглас-
но присвоенным им значениям. Не все протоколы маршрутизации распознают биты, ука-
занные в поле типа сервиса. К протоколам, способным распознавать значения битов ToS,
можно отнести следующие протоколы маршрутизации

•	OSPF (Open Shortest Path First) — Протокол с алгоритмом поиска наикратчайше-
го пути.

•	EIGRP (Enhanced Interior Gateway Routing Protocol) — Улучшенный протокол мар-
шрутизации внутреннего шлюза ).

•	IGRP ( Interior Gateway Routing Protocol) — Протокол маршрутизации внутрен-
него шлюза.

•	BGP (Border Gateway Protocol) — Протокол граничного шлюза.

Следующие протоколы маршрутизации не распознают ToS:

•	RIP, версия 1

•	RIP, версия 2 (Routing Information Protocol, Протокол Маршрутной информации).

Хотя протокол маршрутизации сам по себе может иметь возможность распознавать
биты поля ToS и влиять на присваивание им определенных значений, этот протокол
нужно все же соответствующим образом сконфигурировать. Если маршрутизатор не скон-
фигурирован для поддержки ToS, он попросту проигнорирует информацию этого поля
и перешлет дейтаграмму наилучшим доступным ему способом. Рассмотрим пример ра-
боты поля типа сервиса. Когда приложение выдает запрос на пересылку дейтаграммы
по пути с минимальной задержкой, биту 3 присваивается значение 1. Маршрутизаторы
данного пути предпринимают попытку пересылки дейтаграммы по каналам связи, обес-
печивающим самую быструю передачу данных. К примеру, по каналам связи локаль-
ной сети Ethernet можно передавать кадры, со скоростью 100 Мб/с данных; по сравне-
нию с ними каналы связи глобальных сетей (WAN, Wide Area Network) обеспечивают
более медленную передачу информации. Следует помнить о том, что в данном случае
время задержки эквивалентно задержке продвижения данных с одного конца в другой
конец и обратно (round-trip propagation delay). Из изложенного выше можно сделать
вывод, что предпочтение следовало бы отдать каналу связи, обеспечивающему мини-
мальную задержку при прохождении данных.

Высокая пропускная способность (High throughput) обеспечивается высокопроизво-
дительными каналами связи (high-capacity links), способными переносить большие объе-
мы данных за более короткое время. Эта возможность очень полезна при передаче боль-
ших файлов. Производительность канала связи зависит от ширины полосы пропускания
(bandwidth) и равняется скорости передачи данных (transfer rate), измеряемой в едини-
цах переданной по конкретному интерфейсу информации за единицу времени (т.е. в
битах в секунду). Например, технология локальной вычислительной сети Ethernet обес-
печивает передачу данных со скоростью 100 Мбит/сек. (100 млн. битов в секунду) Эта
скорость, безусловно, выше скорости 10 Мбит/сек. (10 млн. битов в секунду), обеспечи-
ваемой другими интерфейсами физического уровня.

Иногда при передаче данных предъявляются высокие требования к надежности. Так
бывает в случае с приложением, выполняющим критические процессы или требующим
обеспечения определенного уровня безопасности. Приложение такого типа может по-
требовать предоставления более надежного маршрута передачи данных, присвоив биту 5
значение 1. Таким приложением, например, может быть ориентированное на обработ-
ку транзакций приложение (transaction-based processing application), для работы которо-
го требуется доступ к отказоустойчивой базовой сети, обеспечивающей надежную пере-
дачу данных.

Крайне важно понять, что посредством присвоения определенных значений пере-
численным выше битам можно изменить путь, по которому маршрутизаторы направля-
ют трафик. Не имея достаточно полного представления о типах протоколов, о работе
приложений, о формировании потоков данных и о таймерах протоколов сети, нецеле-
сообразно менять биты поля типа сервиса, поскольку это может привести к катастро-
фическим последствиям. Настоятельно рекомендуется самым тщательным образом раз-
работать базовую структуру сети перед реализацией битов ToS. В то же время правильное
применение этих битов может существенно повысить производительность (performance)
самой сети и приложений, работающих в ней.

Поле длины дейтаграммы

Поле общей длины дейтаграммы (Total Length) в заголовке IP, имеющее размер 2 бай-
та, определяет суммарный размер всей дейтаграммы в байтах. В это значение включа-
ется длина заголовка IP и объем данных, подлежащих передаче в рамках данной дей-
таграммы.

Поле идентификации

Перед началом сеанса передачи данных хост-отправитель присваивает каждой дей-
таграмме значение, которое указывается в поле идентификации (Identification) длиной
2 байта. Это значение является идентификатором дейтаграммы, обеспечивающим уни-
кальность дейтаграммы или потока дейтаграмм. Хост-получатель использует этот иден-
тификатор для сборки полученных дейтаграмм. Когда хост-отправитель получает от UDP
или TCP для пакетирования непрерывный поток данных, размер которого слишком велик
для пересылки поданной передающей среде (transmission medium), протокол IP разби-
вает этот поток на фрагменты. Этот процесс называется фрагментацией дейтаграммы
или потока дейтаграмм (fragmentation). Передача дейтаграмм между конечными хост-
компьютерами может происходить по разным маршрутам с очень сильно отличающи-
мися характеристиками. Это может привести к получению дейтаграмм (фрагментов дей-
таграммы) в произвольном порядке. Хост-получатель использует идет ификатор
дейтаграммы (потока дейтаграмм) для того, чтобы определить принадлежность получен-
ных фрагментов одной дейтаграмме или дейтаграмм одному и тому же потоку. Далее
выполняется сборка дейтаграмм (фрагментов дейтаграммы) в нужном порядке на осно-
ве значения, указанного в поле смещения фрагмента (fragment offset value). Более под-
робно поле смещения фрагмента рассматривается ниже в данном разделе.

Поле флагов

Бит 0 ноля флагов (Flags) зарезервирован и должен иметь значение 0.

Бит 1 может иметь одно из следующих значений;

•	0 = Флаг MF, Можно фрагментировать (May Fragment)

•	1 = Флаг DF, Не фрагментировать (Don't Fragment)

Поле управляющих флагов заголовка IP. содержащее 3 бита, используется хостами и
шлюзами для фрагментации пересылаемых данных. Если хост или шлюз поддерживает
фрагментацию, он может разбить поток данных на более мелкие части перед пересыл-
кой. В том случае, когда поддержка фрагментации не предусмотрена (установлен флаг
DF — Don’t Fragment, Не фрагментировать), хост или шлюз не может фрагментировать
поток. Как правило, хост-отправитель поддерживает фрагментацию (т.е. установлен флаг
MF — May Fragment, Можно фра<ментировать). Хост-получатель выполняет сборку
потока дейтаграмм в исходном порядке перед передачей этого потока одному из прото-
колов верхнего уровня (TCP или UDP) для дальнейшей обработки. Однако не всегда
ситуация может сложиться именно так.

Когда хост-отправитель передает слишком большую дейтаграмму, размер которой
превышает размер MTU (Maximum Transmission Unit, Максимальный модуль передачи)
данного участка, шлюз выполняет фрагментацию дейтаграммы путем ее разделения на
единицы меньшего (приемлемого для передачи поданной среде) размера. При наличии
промежуточных шлюзов выполнение фрагментации дейтаграмм в процессе их пересыл-
ки нецелесообразно Маршрутизаторы, призванные выполнить эту функцию, нуждают-
ся в дополнительных ресурсах, что увеличивает непроизводительные затраты (overhead)
и время ожидания (latency) во время доставки той или иной дейтаграммы адресату.
Поскольку различные топологии базовых сетей поддерживают передачу данных кадра-
ми различных размеров, необходимо, прежде всего, выяснить самое нижнее значение
MTU для конкретной сети и сконфигурировать хосты и шлюзы этой сети таким обра-
зом, чтобы они могли обеспечить обработку дейтаграмм с общим размером не менее,
чем MTU интерфейса, по которому они поступают. Например, максимальный размер
кадра Ethernet составляез 1518 байт, в то время как размер кадров Token-Ring может
варьировать от 4,5 тысяч байт до 17,8 тысяч байт.

Флаг DF (Don't fragment, Не фрагментировать), т.е. бит 1 со значением 1, запреща-
ющим фрагментацию, имеет еше одно применение. Некоторые реализации используют
этот флаг с целью динамического определения размера MTU для различных участков
сети при передаче данных по сквозному соединению. Когда конечный хост предприни-
мает попытку переслать дейтаграмму, размер которой больше размера MTU следующе-
го участка пути, промежуточные маршрутизаторы анализируют заголовок дейтаграммы
IP и определяют, активизирован ли этот бит. Если бит 1 поля флагов оказывается уста-
новленным в значение 1 (установлен флаг DF), маршрутизатор не пересылает кадр.
Вместо этого он отбрасывает дейтаграмму с передачей хосту-отправителю ICMP сооб-
щения о том, что данная дейтаграмма имеет слишком большой размер, превышающий
размер MTU следующего участка. Далее хост-отправитель может воспользоваться полу-
ченной информацией для того, чтобы изменить размер следующей дейтаграммы. Этот
процесс продолжается до тех нор, пока хост-отправитель не определит подходящий раз-
мер передаваемой дейтаграммы. Это, в свою очередь, позволяет промежуточным марш-
рутизаторам легко избежать фрагментации дейтаграмм при их пересылке адресату.

Третий бит (бит 2) может иметь одно из следующих значений:

•	0 = Флаг Last, Последний фрагмент (Last Fragment)

•	1 = Флаг More, Есть еще фрагменты (More Fragments)

Флаги Last и More, устанавливаемые в поле этого бита, указывают на отсутствие или
наличие других дейтаграмм в данном потоке. Если пересылается только одна дейтаграм-
ма, устанавливается фла1 Last (Последний фрагмент), а это свидетельствует о том, что
данная дейта! рамма является первой, последней и, следовательно, единственной. Ког-
да хост назначения получает дейтаграмму, он отмечает значение ее идентификатора, а
также проверяет, какой флаг установлен в поле бита 2. Этот флаг показывает, является
ли данная дейтаграмма последней или же есть еще дейта! раммы. Если ожидается по-
ступление других дейта! рамм (установлен флаг More, Есть еще фрагменты), хост-полу-
чатель сохраняет уже поступившие дейтаграммы в памяти до тех пор, пока не поступят
другие дейтаграммы, имеющие аналогичный идентификатор. Далее хост собирает из
полученных дейтаграмм поток, расположив их в правильном порядке, и передает этот
поток дальше для обработки соответствующим протоколом верхнего уровня. Сравнение
идентификаторов дейтаграмм и выяснение соответствующей информации по флагам Last
и More бита 2 позволяют хосту-получателю определить момент, когда следует прекра-
тить ожидание следующих дейтаграмм и начать сборку уже поступивших.

Поле смещения фрагмента

Поле смешения фрагмента (Fragment Offset), имеющее длину 13 битов, позволяет
идентифицировать местоположение данной дейта! раммы в передаваемом потоке. Хост-
получатель использует значение, указанное в этом поле, для определения очередности
сборки совпадающих по полям идентификации дейта! рамм. Хост-отправитель всегда
присваивает полю смещения фрагмента первой дейтаграммы значение 0. Каждая из
последующих дейтаграмм имеет в поле смещения фрагмента значение, присваиваемое
на основе размера MTU данною участка. По этим значениям хост-получатель собирает
дейтаграммы в определенной последовательности по мере их поступления; эти же зна-
чения позволяют обнаружить отсутствие одной из дейтаграмм.

В приведенном ниже примере рассматривается процесс передачи хостом-отправите-
лем трех дейта!рамм, принадлежащих одному и тому же потоку. При этом хост-отпра-
витель выполняет следующие действия:

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

2.	Устанавливает флаг More Fragments в 1 (Есть еще фрагменты) в первых двух jetrrai-
раммах, чтобы указать, что в данном потоке есть другие дейтаграммы.

3.	Устанавливает флаг Last Fragments (Последний фрагмент) в третей дейтаграмме, что-
бы указать, что данная дейта!рамма является последней в потоке данных.

4.	В поле смешения фрагмента каждой из дейтаграмм устанавливает значение, опре-
деляющее местоположение данной дейтаграммы в передаваемом потоке.

На рис. 3.4 изображено, как хост -отправитель и хост-получатель применяют значе-
ние поля смещения фрагмента для определения очередности сборки дейта! рамм. Как
показано на этом рисунке, станция А имеет намерение передал данные на станцию Б
и отсылает по линии связи единственную дейтаграмму, содержащую 1500 байтов инфор-
мации. Следует обратить внимание на то, что размер максимального модуля передачи
(MTU) участка локальной сети, на котором расположен хост А. раьен 1518 байтам. Сле-
довательно, данный участок позволяет выполнить пересылку кадра, содержащего дей-
таграмму размером 1500 байтов. Дейта:рамма поступает в маршрутизатор 1, который пе-
ресылает ее маршрутизатору 2 в первоначальном виде, поскольку MTU участка сети
между этими маршрутизаторами также имеет размер 1518 байтов. Согласно изображе-
нию на рис. 3.4, участок глобальной сети между маршрутизаторами 2 и 3 не примет сег-
мент данных, размер которого больше 512 байтов. Из этого следует, что маршрутизатор
2 должен разбить исходную дейта! рамму, отправленную хостом А, на более мелкие ча-
сти, приспособив ее таким образом к пересылке по данной линии связи. Эта процедура
разбиения исходной дейтаграммы на части и называется фрагментацией (fragmentation).
Теперь имеется три фрагмента дейтаграммы, каждый из которых передается на марш-
рутизатор 3, и в конечном счете — на хост Б, т.е. в пункт назначения. Как только все
фрагменты исходной дейтаграммы достигают хоста Б, этот хост выполняет сборку дей-
таграммы перед тем как передать их для дальнейшей обработки на верхний уровень. Хост
Б (хост-получатель) использует значения, указанные в поле идентификации, поле фла-
гов и поле смещения фрагмента, для сборки дейтаграммы в ее первоначальном виде.

РИСУНОК 3.4

На этом рисунке хост А
(хост-отправитель)
отправляет дейтаграмму,
имеющую слишком большой
размер для пересылки по
глобальной сети.

Маршрутизатор 2
разбивает дейтаграмму на
более мелкие части
(фрагментирует ее) и
отсылает каждый
фрагмент в отдельности
дальше. Хост-получатель
отвечает за сборку
дейтаграммы в ее
первоначальном виде.

Фрагментация и сборка дейтаграмм

Согласно примеру, приведенному на рис. 3.4, хост-получатель рассчитывает полу-
чить фрагменты дейтаграммы и собрать их в следующем порядке:

1.	Первым фрагментом передаваемого потока является фрагмент, значение поля сме-
щения которого равно 0.

2.	Второй фрагмент имеет поле смещения со значением 512.

3.	Третий фрагмент имеет поле смещения со значением 1024.

Хост-получатель хранит дейтаграммы в своем буфере в ожидании сообщений, посту-
пающих вместе с потоком данных. При этом дейтаграммы могут поступать на хост-получа-
тель в произвольном порядке. Если в указанном выше примере первым поступит второй
фра! мент, имеющий поле смещения со значением 512, хост-получатель знает, что ему
следует ожидать поступления других фрагментов, поскольку:

•	Хост-отправитель пометил данный фрагмент как "More, Есть еще фрагменты".

•	Данный фрагмент не является последним, поскольку он не помечен как "Last, Пос-
ледний фрагмент".

•	Хост-получатель еще не принял фрагмент дейтаграммы, значение поля смещения
которого равно 0, а это означает, что еще не получен первый фрагмент.
Хост назначения уже получил фрагмент дейтаграммы с установленным флагом More
(Есть еще фрагменты), и еще не получил фрагмент, помеченный флагом Last (После-
дний фрагмент). Из этого можно сделать вывод, что ожидается дальнейшее поступле-
ние других дейтаграмм. Как только хост-получатель примет все фрагменты данного по-
тока. он может собрать их в правильной последовательности и передать на верхний
уровень для дальнейшей обработки соответствующим приложением.

На рис. 3.5, 3.6 и 3.7 показано, как анализатор протоколов Sniffer интерпретирует
процессы фрагментации и сборки дейтаграмм. На рис. 3.5, 3.6 и 3 7 представлен под-
робный анализ соответственно первой, второй и последней дейтаграммы потока. На рис.
3.5 следует обратить внимание на то, что значение идентификатора кадра 1 (выделен-
ного в окне детализации -detail рапе) равно 2052; такое же значение указано для всех
остальных кадров (2—5), что отмечено в строке "continuation of ident. (идентификатор
продолжения) =2052" для каждого из передаваемых кадров. Это означает, что кадры 1—5
принадлежат одному потоку 2052.

Согласно примеру, показанному на рис. 3.5, хост-отправитель установил флаг More
(Есть еще фрагменты), что указывает на наличие других дейтаграмм в данном потоке:
другими словами, данная дейтаграмма не является последней. Кроме того, в поле сме-
щения фрагмента указано значение 0, а это значит, что данная дейтаграмма является
первой в серии фрагментов с номером 2052.

РИСУНОК 3.5 В поле флагов данной дейтаграммы установлен флаг More (Есть еще фрагменты), что
указывает на наличие других дейтаграмм в данном потоке. По значению 0 поля смещения фрагмента
можно определить, что данная дейтаграмма является первой дейтаграммой потока.
На рис. 3.6 изображен второй фрагмент потока 2052. В поле флагов дейтаграммы
установлен флаг More (Есть еще фрагменты), что указывает на наличие других дейтаг-
рамм в данном потоке. В поле смещения фрагмента установлено значение 1480, а это
значит, что данная дейтаграмма не является первой дейтаграммой потока, так как зна-
чение поля смещения не равно 0. Поскольку флаг Last (Последний фрагмент) не уста-
новлен, можно сделать вывод, что данная дейтаграмма не является последней, а нахо-
дится где-то посередине передаваемого потока (в данном случае эта дейтаграмма является
второй). Хост-получатель использует эту информацию для сборки дейтаграмм в правиль-
ной последовательности после получения всех фра! ментов данного потока.

РИСУНОК 3.6 Хост-получатель использует поле смещения фрагмента для сборки дейтаграмм.

На рис. 3.7 пропущен третий и четвертый и показан последний фрагмент. Этот фраг-
мент также принадлежит потоку, поскольку он имеет такой же, как и у других фраг-
ментов, идентификатор — 2052. Известно, что это — последний фрагмент, поскольку'
он помечен как "Последний фрагмент". Значение поля смещения данного фрагмента
(7400) — выше, чем значения полей смещения предыдущих фрагментов, поэтому хост-
получатель при сборке фрагментов размещает последний фрагмент со смещением на
7400 байтов.

Поле времени жизни

Значение поля времени жизни (TTL, Time То Live), имеет длину 1 байт, и каждое
устройство, обрабатывающее дейта! рамму, уменьшает (обычно на единицу) измеряемое
в секундах значение ноля времени жизни. Установка определенного значения TTL имеет
своей целью:

РИСУНОК 3.7 В no te флагов данной дейтаграммы установлен флаг Last (Последний фрагмент), а это
позволяет хосту-получателю сделать вывод, что данная дейтаграмма является последней
дейтаграммой потока.

•	Определить максимальное время присутствия дейтаграммы в Интернете перед ее
отбрасыванием.

•	Обеспечить отбрасывание дейтаграмм, которые по какой-либо причине не могут
быть доставлены адресату'.

До появления в Интернете маршрутизаторов, для окончательного удаления из сети
потерявшейся дейтаграммы необходимо было иметь возможность определять и ограни-
чивать время ее пребывания в этой сети. Для этого применялся таймер TTL. Он суще-
ствует н сейчас и используется для решения самых разнообразных задач, в том числе
для трассировки маршрута к хосту или сети назначения. Более подробно этот вопрос
рассматривается ниже в данной главе. По существу, любое обрабатывающее дейтаграм-
му устройшво (например, шлюз) должно уменьшить значение поля времени жизни, по
крайней мере, на единицу перед тем как отсылать ее дальше. Единицей измерения TTL
является секунда, а это — больше чем маршрутизатору требуется для обработки дейтаг-
раммы. На практике значение поля жизни приравнивается к числу транзитов (проле-
тов) (hop count) дейтаграммы через маршрутизаторы; это число позволяет также опре-
делить, через какое количество маршрутизаторов проходила дейтаграмма в данной мо-
мент и соответственно насколько единиц уменьшается максимальное время жизни дей-
таграммы в сети.

Сетевой администратор может задать стартовое значение TTL, но это значение не
должно превышать 255 (секунд). Общепринятым правилом является также то. что уст-
ройство, обрабатывающее 'дейтаграмму, не может пересылать ее дальше по сети, если
время жизни данной дейтаграммы не больше 1. Если дейтаграмма находилась в сети на
протяжении 255 секунд и не достигла удаленного пункта назначения, эта дейтаграмма
должна быть из сети удалена. При таких обстоятельствах устройство (маршрутизатор),
при попадании в которое дейтаграмма исчерпала свое значение TTL, отсылает отправи-
телю сообщение ICMP о том, что данная дейтаграмма превысила максимально допус-
тимое время своего пребывания в сети. Более подробно сообщения ICMP рассматрива-
ются ниже в данной главе.

Поле типа протокола

В поле типа протокола (Protocol), имеющем длину 1 байт, указывается значение, оп-
ределяющее тип следующего (верхнего) протокола, который предполагается использо-
вать для дальнейшей пересылки данной дейтаграммы. Поле типа протокола может при-
нимать одно из следующих значений:

•	06 (TCP, Transmission Control Protocol, Протокол управления передачей)

•	17 (UDP, User Datagram Protocol, Протокол доставки дейтаграмм пользователя)

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

Ноле контрольной суммы заголовка IP

Поскольку IP — не ориентированный на соединение протокол, в нем не реализован
ни один из механизмов исправления ошибок (error correction mechanism), таких как упо-
рядочивание передаваемых сегментов данных (sequencing) и выдача подтверждений их
получения (acknowledgment). Протокол IP просто адресует дейта! раммы и отсылает их
с надеждой на то, что они достигнут адресата. Поэтому IP применяет простое вычисле-
ние контрольной суммы (checksum), указанной в данном поле длиной 2 байта, для про
верки целостности заголовка дейтаграммы IP и содержащихся в этой дейтаграмме дан-
ных. Пересчет контрольной суммы позволяет убедиться, что ни один из битов не был
поврежден во время пересылки между двумя конечными хост-компьютерами. Проме-
жуточные ушройства должны пересчитывать и проверять значение поля контрольной
суммы в каждом пункте обработки дейтаграммы, поскольку некоторые поля заголовка
IP изменяются во время перемещения дейтаграммы по сети (например, значение поля
времени жизни). Если в какой-то момент времени устройство расценивает значение
контрольной суммы как неправильное ио причине повреждения одного из битов, оно
отбрасывает дейтаграмму без отправления хосту -отправителю соответствующего сооб-
щения. Ответственность за обнаружение потери дейтаграммы и ее восстановление пу
тем повторной передачи протокол 1Р возлагает на протоколы верхних уровней.
Поле адреса отправителя

Хост-отправитель устанавливает свой логический адрес сетевого уровня, т.е. IP-ад-
рес (logical Network layer address, IP-address) в поле адреса отправителя (Source Address).
Это поле имеет длину 4 байта; указанное в нем значение однозначно идентифицирует
отправителя дейтаграммы.

Поле адреса получателя

В поле адреса получателя (Destination Address), имеющем длину 4 байта, указывает-
ся логический адрес хоста-получателя на сетевом уровне (logical Network layer address,
IP- address). Этот логический 32-разрадный IP-адрес идентифицирует хост назначения
и сеть, в которой он находится.

Поле дополнительных параметров

Хосты или шлюзы могут реализовать в заголовке IP необходимые им дополнитель-
ные параметры. Установить их можно в поле дополнительных параметров (Options),
которое может иметь переменную длину. Наличие поля дополнительных параметров в
заголовке дейтаграммы IP носит необязательный характер, однако, если это поле акти-
визировано — все хосты и шлюзы, обрабатывающие дейтаграмму, должны быть в со-
стоянии распознавать и поддерживать его. В поле дополнительных параметров может
быть указан параметр уровня безопасности (secuiity option), если активизирован один
из битов приоритета поля ToS.

Поле заполнение

Протокол IP использует это поле переменной длины, когда заголовок IP не закан-
чивается на 32-разрялной границе. Поле заполнения (Padding) предназначено для того,
чтобы выровнять заголовок IP (путем заполнения служебным двоичным кодом) по 32-
разрядной границе, поскольку длина заголовка IP исчисляется в 32-разрядных словах.

Протокол управляющих сообщений Интернета
(ICMP)

Конечные хост-компьютеры и шлюзы (маршрутизаторы) используют протокол 1СМР
(Internet Control Message Protocol, Протокол управляющих сообщений Интернета) в ка-
честве управляющего, диагностического и формирующего управляющие сообщения про-
токола. Протокол ICMP функционирует на сетевом уровне модели OSI и на уровне Ин-
тернета модели DoD (На рис. 3.1 показано, к каким уровням относится протокол ICMP
в эталонных моделях обмена данными DoD и OSI.) Подробное описание протокола
ICMP можно найти в RFC 792. Несмотря на то, что ICMP обслуживает сетевой уровень
наравне с IP, он является неотъемлемой частью протокола IP. По существу, протокол
ICMP использует сервисы 1Р для доставки своих сообщений. На рис 3.8 показано эхо-
сообщение (echo message) ICMP, инкапсулированное в дейтаграмму IP.

Существует много типов ICMP- сообщений; наиболее распространенным среди них
является эхо-запрос ICMP (echo-request). Эхо-запросом можно пользоваться как диаг-
ностическим средством для тестирования соединения между конечными хост-компью-
терами. Следует обратить внимание на то, что в приведенном примере поле типа про-
токола в заголовке 1Р имеет значение 1 (соответствующее протоколу ICMP).

ЭХО-ЗАПРОС И ЭХО-ОТВЕТ

Термины "эхо-запрос, эхо-ответ" (echo-request, echo-reply) характеризуют сообщения, ко-
торые можно использовать для проверки сетевого соединения. Это можно сделать с помо-
щью утилиты Ping (Packet Internetwork Groper, утилита контроля доступности хостов сети).
Программы Ping использует ICMP-сообщения типа "эхо-запрос, эхо-ответ". Эхо-запрос можно
образно интерпретировать как фразу: "Привет, там есть кто-нибудь?" Полученный ответ,
будь то ответ положительный или отрицательный (есть соединение или нет соединения), —
это и есть эхо-ответ. Так же, как и в случае обычного эха, эхо-ответ формируется всегда.

РИСУНОК 3.8 Эхо-сообщение ICMP используется для проверки связи между конечными хост-
компьютерами на сетевом уровне.

Хосты-получатели и шлюзы должны при возникновении необходимости проинфор-
мировать хост-отправитель о связанных с доставкой данных проблемах, а также прове-
рить наличие соединения сданным хостом, выдать запрос на снижение скорости пере-
дачи данных, и т.д. Всего для информирования хоста-отправителя о возникших
проблемах применяется 15 различных типов сообщений 1СМР; тип сообщения указы-
вается в поле Туре (Тип) заголовка ICMP-пакета. Эти сообщения предоставляют хосту-
отправителю возможность узнать о некоторых (но не всех) возникших проблемах, а также
устранить ошибки. Однако ICMP не гарантирует решения проблем, хотя и информиру-
ет хост-отправигель об их наличии. Аналогично 1Р, протокол ICMP — не ориентиро-
ванный на установления соединения протокол. Хосты или шлюзы способны доброволь-
ны отсылать управляющие или диагностичес! ие сообщения. Протокол ICMP использу-
ет разные типы сообщений для различных целей.

Упомянутая выше утилита Ping (типы ICMP-сообщений 0 и 8) применяется в ежед-
невной работе сетевого администратора. Эта утилита позволяет отправить напоминаю-
щее сигнал акустического локатора сообщение для проверки соединения между двумя
конечными хост-компьютерами. Чтобы выполнить эту задачу, Ping использует предос-
тавляемые ICMP-сообщениями услуги. Когда пользователь вводит команду Ping с ука-
занием имени или адреса удаленного хоста, этот хост получает серию ICMP-сообще-
ний, известных как эхо-запросы. Хост-получатель, в свою очередь, реагирует на каждое
из этих сообщений соответствующим эхо-ответом (тип ICMP-сообщения — 0). Более
подробно сообщения утилиты Ping, так же как и другие типы ICMP-сообщений, рас-
сматриваются ниже в данной главе.

Заголовок и формат ICMP сообщений

Протокол IP указывает на присутствие сообщений ICMP в дейтаграмме 1Р значени-
ем 1 в поле типа протокола (Protocol). На рис. 3.8 показан общий формат эхо-сообще-
ния ICMP. Первых 4 байта (поле типа (Туре) — 1 байт, код (Code) — 1 байт, поле кон-
трольной суммы заголовка ICMP (Checksum) — 2 байта) имеют одинаковый формат для
всех типов ICM P-сообщений. Все другие поля и данные, содержащиеся в заголовке ICMP,
отличаются в йвисимосги от типа отправляемого сообщения. Различные типы 1СМР-сооб-
шений, их коды и контрольная сумма рассматриваются ниже в данной главе.

Хосты и шлюзы используют протокол ICMP в качестве управляющего, диагности-
ческого и формирующего сообщения протокола для того, чтобы предупредить хост о воз-
никших во время пересылки данных проблемах При этом в поле типа протокола заго-
ловка IF устанавливается значение 1, что указывает на наличие в данной дейтаграмме
IP сообщения ICMP. Для того чтобы определить тип ICMP-сообщения, необходимо по-
смотреть, какое значение установлено в поле типа (Туре) заголовка ICMP. Для даль-
нейшей идентификации смысла данного сообщения можно воспользоваться полем кода
(Code). Поле типа определяет конкретные типы ICMP-сообщений. Для некоторых сообще-
ний указываются различные значения в поле кода, обеспечивающее более подробное опи-
сание ошибок. Величина контрольной суммы вычисляется для всего сообщения ICMP.

Поле кодов

Более подробное описание ошибки обеспечивается полем кодов и указанным в нем
значением. Согласно кодам, указанным в этом поле, ICMP-сообщения можно отнести
к двум разным категориям:

•	Запрос (Query)

•	Ошибка (Error)

Запросы не содержат никаких дополнительных сведений, поскольку они просто вы-
ражают просьбу о предоставлении той или инои информации; при этом в поле кодов
указывается значение 0 Протокол ICMP работает со следующими запросами:
РИСУНОК 3.9 Сообщения ICMP имеют зарегистрированное значение 1 в поле типа протокола
заголовка IP. Поле типа в заголовке ICMP идентифицирует тип передаваемого ICMP-сообщения

•	Тип 0 - Эхо-ответ (Echo Reply)

•	Тип 8 = Эхо-запрос (Echo Request)

•	Тип 9 = Извещение от маршрутизатора (о регистрации) (Router Advertisement)

•	Тип 10 = Запрос маршрутизатора (о регистрации) (Router Solicitation)

•	Тип 13 = Запрос о временной метке (Timestamp Request)

•	Тип 14 = Ответ о временной метке (Timestamp Reply)

•	Тип 15 = Информационный запрос (Information Request), (вышедший из употреб-
ления тип)

•	Тип 16 = Информационный ответ (Information Reply), (вышедший из употребле-
ния тип)

•	Тип 17 = Запрос о маске адреса (Address Mask Request)

•	Тип 18 = Ответ на запрос о маске адреса (Address Mask Reply)

Сообщения об ошибках (error messages) предоставляют конкретную информацию об
ошибках и имеют различные значения, характеризующие причины их возникновения.
В сообщение об ошибке всегда включается заголовок IP проблемной дейтаграммы, а
также до 8 байтов данных, ошибка в которых привела к отправке шлюзом или хостом дан-
ного сообщения. Хост отправитель пользуется этой информацией для идентификации со-
общения. Протокол ICMP использует в своей работе следующие сообщения об ошибках:

•	Тип 3 = Недостижимый пункт назначения (Destination Unreachable)

•	Тип 4 = Подавление источника (Source Quench)

•	Тип 5 = Перенаправление (Redirect)

•	Тип 11 = Время превышено (Time Exceeded)

•	Тип 12 = Проблемы с параметрами (Parameter Problems)

Коды ошибок и различные типы сообщений 1СМР, относящихся к этим ошибкам,
рассматриваются ниже в данной главе.

Поле контрольной суммы

С помощью контрольной суммы (Checksum) проверяется правильность заголовка
1СМР. Хост-отправитель выполняет начальное вычисление контрольной суммы и раз-
мещает результат вычисления в поле контрольной суммы. Хост-получатель также вы-
числяет значение контрольной суммы, чтобы убедиться, что данные не были поврежде-
ны во время пересылки. Если полученные значения контрольной суммы не совпадают,
хост-получатель отбрасывает дейтаграмму.

Поле идентификатора

Пользователь, работающий с хостом-отправителем, может установить необязатель-
ное значение в поле идентификатора (Identifier) для сравнения эхо-запросов с получен-
ными эхо-ответами.

Поле порядкового номера

Пользователь, работающий с хостом-отправителем, может установить необязатель-
ное значение в поле порядкового номера (Sequence Number) для сравнения эхо-запро-
сов с полученными эхо-ответами.

Типы сообщений ICMP

Поле типа (Туре) идентифицирует тип сообщения, отправленного хостом или шлю-
зом. В полях типа многих ICMP-сообщений содержится более подробное описание ошиб-
ки, возникшей при передаче данных. В таблице 3.1 перечислены типы сообщений ICMP.

Таблица 3.1 Типы сообщений ICMP___________________________________________

Тип Описание типов ICMP-сообщений_________________________________________

О Эхо-ответ (Echo Reply): Ping-ответ (Ping Reply), применяется с типом 8, Ping- запрос
________(Ping Request)____________________________________________________

3_____Недостижимый пункт назначения (Destination Unreachable)_____________

4	Подавление источника (Source Quench)

5__________Перенаправление (Redirect)_____________________________________

8	Эхо-запрос (Echo Request): Ping-запрос (Ping Request), применяется с типом 0, Ping-
ответ (Ping Reply)
Тип Описание типов ICMP-сообщений_____________________________________________

9	Информация от маршрутизатора (о регистрации) (Router Advertisement), применяется
	с типом 10____________________________________________________________

10	Запрос маршрутизатора (о регистрации )(Router Solicitation), применяется с типом 9

11	Время превыше!ю (Time Exceeded)_______________________________________

12	Проблема с параметрами (Parameter Problem)____________________________

13	Запрос о временной метке (Timestamp Request), применяется с типом 14__

14	Ответ о временной метке (Timestamp Reply), применяется с типом 13_____

15	Информационный запрос (Information Request), применяется с типом 16; вышедший

________из употребления тип________________________________________

16	Информационный ответ (Information Reply), применяется с типом 15; вышедший из
употребления тип___________________________________________________

17	Запрос о маске адреса (Address Mask Request), применяется с типом 18__

18	Ответ о маске адреса (Address Mask Reply), применяется с типом 17

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

Ping: эхо-запрос и эхо-ответ (типы 8 и 0)

Эхо-запрос ICMP (тип 8) и эхо-ответ ICMP (тип 0) рассматриваются вместе, посколь-
ку протокол ICMP применяет эти сообщения в тесном взаимодействии друг с другом.
Удаленные хосты используют эти два типа сообщений для тестирования сетевого соеди-
нения. Как упоминалось выше, пользователь выполняет утилиту Ping, инициируя тем
самым формирование эхо-запроса ICMP, и ожидает передачи хостом-получателем со-
ответствующего эхо-ответа. При успешном получении эхо-ответов на эхо-запросы хост-
отправитель:

•	Индицирует успешное завершение теста на наличие сетевого соединения.

•	Делают вывод о том, что существует правильный коммуникационный путь меж-
ду хостами.

•	Предполагает, что конечный хост-компьютер функционирует на сетевом уровне.

На рис. 3.8 показан пример эхо-запроса; рис. 3.9 демонстрирует пример эхо-ответа.
В кадре 1 хост с адресом 36.53.0.202 отправляет эхо-запрос на проверку соединения с
хостом 36.28.0.1. Следует обратить внимание на то, что, как видно в окне детализации,
в поле типа установлен код типа 8, фиксирующий данное сообщение как эхо-запрос.
Значение идентификатора 47623 и порядкового номера 5643 включены в качестве нео-
бязательных параметров для обеспечения корректного сравнения с эхо-ответом. В кад-
ре 2 хост 36.28.0.1 возвращает эхо-ответ хосту 36.53.0.202. Код типа 0 регистрирует дан-
ное сообщение как ответ; отмечается также, что значения идентификатора и порядковою
номера совпадают.
Недостижимый пункт назначения (тип 3)

ICMP-сообшение "Недостижимый пункт назначения" (Destination Unreachable, тип
3) предупреждает хост-отправитель о проблемах, возникших при попытке установить со-
единение с хостом-получателем. Следует обратить внимание на то, что хост-получатель
выдает только сообщения об ошибках, имеющих коды 2 и 3; маршрутизатор может от-
правлять сообщения об ошибках с любыми кодами. Типы кодов, указывающих на раз-
личные проблемы, описаны ниже

О = Сеть недостижима

Сообщение "Сеть недостижима" (Network Unreachable) указывает на тот факт, что
маршрутизатор не в состоянии найти сеть назначения (такая сеть не существует или по-
вреждена), либо на тот факт, что нет маршрута к данной сети. Другими словами, марш-
рутизатор не может доставить дейтаграмму в сеть назначения или переправить ее по
другому пути. Такая ситуация может сложиться в результате того, что сеть находится
вне досягаемости используемою протокола маршрутизации и, следовательно, считается
недостижимой (другими словами, эта сеть расположена слишком далеко). Когда клиент
предпринимает попытку связаться с недостижимым хостом или сетью, шлюз выдает
подобное сообщение, чтобы предупредить хост-отправитель о данной проблеме. Подоб-
ное сообщение можно образно интерпретировать так: "Нужная вам улица не найдена",
или "До этой улицы трудно добраться'

1	= Хост недостижим

Сообщение "Хост недостижим" (Host Unreachable) предупреждает хост-отправитель
о том, что требуемый хост-получатель не может быть найден. Подобная ситуация мо-
жет сложиться из-за тою, что хост отключен, или его вообще не существует. Данное
сообщение шлюза можно интерпретировать следующим образом: "Я нашел нужную ули-
цу, но на ней нет дома, который вы ищете".

2	= Протокол недостижим

Сообщение "Протокол недостижим" (Protocol unreachable) означает, что протокол
транспортного уровня (UDP или TCP) не поддерживается адресатом. Это сообщение
может передать хост-получатель или промежуточный шлюз. В данном сообщении ут-
верждается: "Протокол транспортного уровня, которым вы пытаетесь воспользоваться,
не поддерживается данным хостом".

3	= Порт недостижим

Сообщение "Порт недостижим” (Port unreachable) указывает на то, что процесс или
приложение, с которым хост-отправитель предпринимает попытку установить соедине-
ние, не активизирован на хосте-получателе. Как правило, сообщение такого типа от-
правляется хосг-получателем или промежуточным шлюзом в том случае, когда прило-
жение на данном хосте не активизировано или произошел отказ в его работе. Подобное
сообщение можно интерпретировать таким образом: "Процесс или приложение, с кото-
рым вы пытаетесь связаться, не активизировано в данном хосте", или "Я нашел улицу,
я нашел дом, в нем включено освещение, но дома никого нет".
На рис. 3.10 показан запрос, отправленный ВООТР-клиентом, осуществляющим по-
иск ВООТР-сервера. На рис. 3.11 показан пример сообщения "Порт недостижим", не-
обходимость в выдаче которого возникла из-за того, что маршрутизатор или шлюз не
смог обнаружить ВООТР-сервер, или же сервер был недоступен. Более подробно протокол
ВООТР (Bootstrap Protocol, Загрузочный протокол) рассматривается в главах 4 и 9.

На рис. 3.11 следует обратить внимание на то, что шлюз присоединил к заголовку
ICMP из кадра 1 копию заголовка 1Р проблемной дейтаграммы, вызвавшей ошибку. Хост-
отправитель может воспользоваться информацией, содержащейся в копии заголовка IP
проблемной дейтаграммы, для устранения ошибки, приведшей к появлению передавае-
мого ICMP-сообщения.

РИСУНОК 3.10 В кадре 1 выделенном в итоговой панели и показанной в в окне детализации, можно
видеть ВООТР-клиента, "VDP порт = 68". рассылающего широковещательное сообщение на все
хосты, использующие UDP-nopm 67; лпо сообщение идентифицирует выполняемый ВООТР-Сервер
процесс, запрашивающий 1Р-адрес.

4	= Необходима фрагментация, но установлен флаг "Не фрагментировать”

Маршрутизатор отправляет данное сообщение (Fragmentation is needed, but don’t-
Iragment bit set), когда он получает дейтаграмму, для дальнейшего продвижения кото-
рой по сети нужна фрагментация, но установлен флаг DF (Don't-fragment, Не фрагмен-
тировать) Как известно, именно хост-отправитель в большинстве случаев несет
ответственность за фрагментацию, а хост-получатель отвечает за сборку дейтаграммы.
Однако иногда маршрутизатор не в состоянии передать дейтаграмму на следующий уча-
сток из-за того, что ее размер превышает максимально допустимый. Если же на марш-
рутизатор поступает дейтаграмма, в IP-заголовке которой установлен флаг DF Ше фраг-
ментировать), то он не сможет выполнить фрагментацию и отбросит дейтаграмму. При
этом маршрутизатор отправит соответствующее сообщение (тип 3, код 4), предупреж-
дающее хост-отправитель об отбрасывании дейтаграммы. Таким образом, с помощью
флага DF бита фрагментации можно определить максимальный размер передаваемого
между конечными хостами пакета данных, или MTU (Maximum transmission unit, Мак-
симальный модуль пересылки).

Хосты могут применять ICMP-сообщения для того, чтобы изменять размер дейтаг-
рамм, динамически приспосабливая их таким образом к нуждам данной сети. Это по-
зволяет каждому хосту-отправигелю определить по значениям MTU кратчайший путь
до пункта назначения.

РИСУНОК 3.11 Во втором каоре, выделенном на итоговой панели и показанном в окне детализации,
можно видеть отправляемое шлюзом (36.53.0.204) сообщение ICMP, в котором утверждается, что
предыдущий запрос оказался безрезультатным, поскольку требуемый порт (68) не активизирован и,
следовательно, является недоступным. Как видно на рисунке, непосредственно за заголовком ICMP
следует заголовок IP.

5	= Неверен маршрут к источнику

Маршрутизатор отправляет сообщение "Неверен маршрут к источнику" (Source Route
Failed), если он сталкивается с тем, что следующий участок транзита в маршруте к ис-
точнику не принадлежит непосредственно подключенной к данному маршрутизатору
сети.

6	= Неизвестна сеть назначения

Маршрутизатор отправляет сообщение "Неизвестна сеть назначения" (Destination
Network Unknown), когда он не может доставить или переслать полученную им дейтаг-
рамму IP в ту или иную сеть, поскольку эта сеть неизвестна.

7	= Неизвестен хост назначения

Маршрутизатор отправляет сообщение "Неизвестен хост назначения" (Destination Host
Unknown), когда он не может доставить или переслать полученную им дейтаграмму IP
в тот или иной хост, поскольку этот хост неизвестен.

8	= Хост источника изолирован (вышедший из употребления тнн)

9	= Административно запрещены коммуникации с сетью назначения

Маршрутизатор отправляет подобное сообщение (Destination Network Administratively
Prohibited), когда он не может доставить или переслать полученную им дейтаграмму IP
в ту или иную сеть, поскольку доступ к этой сети запрещен сетевым администратором.

10	= Административно запрещены коммуникации с хостом назначения

Маршрутизатор отправляет данное сообщение (Destination Host Administratively
Prohibited), когда он не может доставить или переслать полученную им дейтаграмму IP
в тот или иной хост, поскольку доступ к этому хосту запрещен сетевым администрато-
ром.

11	= Сеть недостижима для заданного типа сервиса

Маршрутизатор отправляет подобное сообщение (Network Unreachable for ToS), когда
он не может доставить или переслать полученную им дейтаграмму IP в ту или иную сеть,
поскольку эта сеть не может обеспечить запрашиваемый в IP-заголовке данной дейтаг-
раммы тип сервиса.

12	= Хост недостижим для заданного типа сервиса

Маршрутизатор отправляет подобное сообщение ( Host Unreachable for ToS), когда
он не может доставить или переслать полученную им дейтаграмму IP в тот или иной
хост, поскольку этот хост не может обеспечить запрашиваемый в IP-заголовке данной
дейтаграммы тип сервиса.

13	= Коммуникации административно запрещены фильтрацией

Маршрутизатор отправляет данное сообщение (Communication Administratively
Prohibited by Filtering), когда он не может доставить или переслать полученную им дей-
таграмму IP в тот или иной хост, поскольку доступ к выполняемому на этом хосте про-
цессу или приложению запрещен сконфи!урированным в административном порядке
фильтром.

14	= Нарушение приоритетности хоста

Маршрутизатор отправляет данное сообщение (Host Precedence Violation), когда он
не может доставить или переслать полученную им дейтаграмму IP в тот или иной хост,
поскольку запрашиваемый уровень приоритетности не подходит, не принимается или
неверен. Эта ситуация может возникнуть в случае, когда хост-отправитель предпримет
попытку получить доступ к хосту с высоким уровнем обеспечения безопасности, не имея
при этом соответствующей категории допуска (security clearance).

15	= Приоритетность заблокирована

Маршрутизаторы пользуются данным сообщением (Precedence CutolTin Effect) ред-
ко. Тем не менее, хост-отправитель может получить это сообщение, если его пакет дан-
ных отбрасывается из-за действия функции блокировки приоритетности.

^УПРАВЛЕНИЕ ПРИОРИТЕТНОСТЬЮ В МАРШРУТ!.ЗАТОРАХ

Маршрутизаторы должны принимать и назначать путь входящему трафику всех уровней
приоритета в обычном режиме, если только он не сконфигурирован по-другому. Более
подробная информация о приоритетности и сообщениях ’’Недостижимый пункт назначе-
ния” (тип 14 и 15) изложена в RFC 1812, 5.3.3.3, "Управление приоритетностью в марш-
рутизаторах".

Подавление источника (тип 4)

Хост-получатель выдает сообщение "Подавление источника" (Source Quench), когда
он не в состоянии обработать дейта! рамму с требуемой скоростью из-за недостаточного
объема памяти или внутренних ресурсов.-Это сообщение служит в качестве простого ме-
ханизма управления потоком (flow control mechaiiis.n), которым хост -получатель может
воспользоваться для уведомления хоста-отправи геля о необходимости снизить скорость
передачи данных. Кстда хост-отправитель получает подобное сообщение, он должен пе-
редать полученную информацию одному из процессов верхнего уровня, такому как TCP,
в обязанности которого, в свою очередь, входит управление интенсивностью потока дан-
ных того или иного приложения. Маршрутизатор выдает это сообщение, когда в про-
цессе пересылки дейтаграмм произошла перегрузка буферов, и при этом нет возможно-
сти поставить дейтаграмму в очередь на доставку.

Перенаправление (тип 5)

Маршрутизатор отправляет хосту-отправителю дейтаграммы IP сообщение о пере-
направлении (Redirect), когда этот хост должен был направить дейтаграмму по другому
пути или непосредственно хосту-получателю (если конечный хост — локальный). Дан-
ное сообщение помогает хосту-отправителю переадресовать дейтаграмму, отправленную
по ошибочному пути, в другой шлюз или хост. Такое предупреждение само по себе не
гарантирует доставки дейтаграммы по подходящему маршруту; именно хост-отправи-
тель должен устранить возникшую проблему, если это возможно.

Следует отметить, что только шлюзы могут выдавать сообщения о перенаправлении
(redirect messages) для информирования хостов-отправителей о пересылке дейтаграммы
по неверному маршруту. Необходимо также обратить внимание на то, что шлюз, при-
нимающий неправильно адресованный кадр, не отбрасывает проблемную дейтаграмму,
если он может переслать ее на следующий участок. В таком случае шлюз передает катр
дальше, отсылает хосту-отправителю предупрех даюшее сообщение о необходимости пе-
ренаправления данного кадра с надеждой на то, что хост-отправитель будет надлежа-
щим образом адресовать следующие кадры, направляя их в указанный в сообщении шлюз
или хост. 1СМР-сообшение о перенаправлении уведомляет хост-отправитель о непра-
вильной адресации и о необходимости повторной пересылки дейтаграммы. Ниже пере-
числены четыре кода данного типа сообщений:

1.0= Перенаправление дейтаграммы в сеть (Redirect for Network)

2.	1 = Перенаправление дейтаграммы в хост (Redirect for Host)

3.	2 = Перенаправление дейтаграммы в сеть на основе значения из поля ToS (Redirect
for Type-of-Service and Network)

4.	3 = Перенаправление дейтаграммы в хост на основе значения из поля ToS (Redirect
for Type-of-Service and Host)

На рис. 3.12 показан пример ICMP-сообщения о перенаправлении. В этом примере
шлюз (36.53.0.1) предупреждает хост (36.53.0.174) о том, что ему следует отправлять сле-
дующие дейтаграммы по другому сетевому адресу шлюза (36.53.2.2). В это предупреж-
дающее сообщение включена также копия IP-заголовка проблемной дейтаграммы для
ее проверки хостом-отправителем.

РИСУНОК 3.12 ICMP-сообщения о перенаправлении отправляются шлюзами по адресам хостов-
отправителей с предупреждением о том. что пересылаемые дейтаграммы были неправильно
адресованы.
Запрос маршрутизатора (о регистрации) и информация
от маршрутизатора (о регистрации) (типы 9 и 10)

Метод обнаружения маршрутов посредством ICMP-сообщений "запрос маршрутиза-
тора (о регистрации)" и "информация от маршрутизатора (о регистрации)" (Router
Advertisement and Solicitation) более предпочтителен, чем инициализация таблицы мар-
шрутизации с фиксированными маршрутами, специфицированными в конфигурацион-
ных файлах. После загрузки хост может посредством широковешательной (broadcast) или
многоадресной (multicast) рассылки отправить сообщение с просьбой о регистрации мар-
шрутизаторами их присутствия. В ответ на такой запрос (Router Solicitation) маршрути-
затор или маршрутизаторы отвечают сообщением "информация от маршрутизатора о
регистрации" (Router Advertisement). Это предоставляет взаимодействующим хостам воз-
можность динамически обнаруживать доступные маршруты и обновлять таблицы мар-
шрутизации. Более подробно маршрутизация рассматривается в главах 5 и 6.

Время превышено (тип 11)

Маршрутизатор отправляет сообщение "Время превышено" (Time Exceeded) при по-
лучении дейтаграммы, TTL (Time То Live, Время жизни) которой уменьшилось до 0 или
1. Протокол IP использует поле TTL для того, чтобы предотвратить бесконечное блуж-
дание дейтаграммы по круговому маршруту. Маршрутизатор не может передать на сле-
дующий участок дейтаграмму, значение поля TTL которой равно 0 или I. Вместо этого
он отбрасывает дейтаграмму и отправляет сообщение об истечении времени жизни (Time
Exceeded). Ниже перечислены коды сообщений об ошибках, отражающие причину вы-
дачи сообщения "Время превышено":

1.	0= дейтаграмма исчерпала лимит времени при пересылке. (Time-To-Live Equals 0
During Transit)

2.	1 = произошел сброс таймера при сборке фрагментов дейтаграммы до того, как все
фрагменты прибыли (Time-To-Live Equals 0 During Reassembly)

Следует обратить внимание на то, что маршрутизатор не может передать дейтаграм-
му на следующий участок, если значение поля TTL уменьшилось до 0 или 1 как при пе-
ресылке дейтаграммы по сети, так и при ее сборке.

Как упоминалось в посвященном протоколу 1Р разделе данной главы, значение TTL
измеряется в секундах. Таймер TTL первоначально (еще до существования маршрути-
заторов) использовался для того, чтобы исключить бесконечное блуждание дейтаграм-
мы по Интернету. Каждый шлюз, обрабатывающий ту или иную дейтаграмму, сокраща-
ет значение TTL, по крайней мере, на единицу, если у него уходит больше одной секунды
на обработку дейтаграммы и передачу ее на следующий участок. Когда значение TTL
исчерпывается, шлюз отбрасывает дейтаграмму и отправляет хосту-отправителю сооб-
щение, информирующее его о сложившейся ситуации.

Утилита Traceroute также использует значение поля TTL для обнаружения пути или
маршрута к хосту или сети назначения. После выполнения команды traceroute отправ-
ляется исходное сообшение ICMP со значением 1 или 0, установленным в поле TTL
заголовка IP. Программой Traceroute можно воспользоваться для того, чтобы опреде-
лить или, скорее, проследить путь к адресату следующим образом. Утилита Traceroute
отправляет последовательность дейтаграмм со значением TTL, равным 1, 2 и т.д. Далее
эта программа использует ICMP-сообшения "Время превышено" в качестве следа из
меток, позволяющих обнаружить встретившиеся на данном пути маршрутизаторы. При-
мер такой процедуры приведен ниже в данном разделе.

Как было отмечено ранее в данной главе, когда на маршрутизатор поступает дейтаг-
рамма, значение TTL которой равно 0, он отбрасывает эту дейтаграмму и отправляет
хосту-отправителю ICMP-сообщение об истечении времени. Это сообщение позволяет
хосту-отправителю обнаружить первый маршрутизатор на пути дейтаграммы к пункту
назначения.

На рис. 3.13 показан пример ICMP-сообщения, отправленного в результате умень-
шения значения поля TTL до 0. Как видно на этом рисунке, ICMP-сообщение (тип 11)
предупреждает хост-отправитель об истечении времени жизни передаваемой им дейтаг-
раммы. Код 0 отражает причину сложившейся ситуации: значение поля TTL уменьши-
лось до 0 во время пересылки дейтаграммы. Для того чтобы помочь хосту-отправителю
в решении возникшей проблемы, в это сообщение включена также копия IP-заголовка
дейтаграммы, вызвавшей данную ошибку. В данном заголовке можно увидеть следую-
щую строку: "TTL value — 0 seconds/hops" (Значение TTL = 0 секунд/транзитов). Имен-
но эта строка и является причиной отбрасывания дейтаграммы.

РИСУНОК 3.13 Маршрутизатор отправляет сообщение о превышении времени жизни (Time exceeded),
когда истекает значение таймера TTL.
Далее хост-отправитель пересылает еще одну отслеживающую дейтаграмму с полем
TTL, установленным в 2, что позволяет первому встретившемуся на пути маршрутиза-
тору передать эту дейтаграмму на следующий участок. При этом первый маршрутиза-
тор уменьшает значение TTL на единицу, следовательно, дейтаграмма поступает на сле-
дующий маршрутизатор данного пути со значением TTL, равным 1. Этот маршрутизатор,
в свою очередь, обязан отбросить данную дейтаграмму и отослать хосту-источнику ICMP-
сообщение "Время превышено''. Эта процедура продолжается до тех пор, пока не будет
полностью обнаружен путь к пункту назначения или же пока не будет сделан вывод о
недостижимости этого пути. Очевидно, что утилита Traceroute представляет собой еще
один полезный инструмент поиска и локализации неисправностей, который обычно ис-
пользуется вместе с другими утилитами (например, с утилитой Ping) для тестирования
соединения между двумя конечными хостами.

^СОВЕТ

Как утилита Ping, так и утилита Traceroute могут оказать существенную помощь в поиске
и локализации неисправностей.

Проблема с параметрами (тип 12)

Сообщение "Проблема с параметрами" (Parameter Problem) указывает на то, что хост
или шлюз получил, но не смог распознать неверный или непонятный параметр. Это же
сообщение отправляется хостом или шлюзом также и в том случае, когда нет возмож-
ности использовать какое-либо другое ICMP-сообщение для предупреждения хоста-от-
правителя о возникшей проблеме. В этом отношении сообщение данного типа можно
рассматривать как сообщение широкого спектра действия (catchall message), отправляе-
мое по поводу возникновения различных проблем, не специфицированных в кодах дру-
гих сообщений. В большинстве случаев сообщение "Проблема с параметрами” указыва-
ет на наличие какой-либо ошибки в реализации, возможно, по причине несовместимости
продуктов разных поставщиков. Хост или шлюз отправляет сообщение о проблеме с па-
раметрами только в случае отбрасывания дейтаграммы, имеющей ошибку в параметрах.

Существует два сообщения об ошибках, детализирующие сообщение "Проблема с па-
раметрами"; ниже перечислены их коды:

I 0 = Неправильный параметр в одном из полей заголовка IP (IP Header Bad), сооб-
щение широкого спектра действия

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

2. 1 = Отсутствует требуемый дополнительный параметр (Required Option Missing)
Хост или шлюз ожидал наличия конкретного параметра в поле дополнительных па-
раметров (Options), но этот параметр не был установлен отправителем.

Запрос и ответ о временной метке (тип 13 и 14)

Сообщения, содержащие запрос и ответ о временной метке (Timestamp request and
reply), работают в тесном взаимодействии друг с другом. Предположим, что параметр
использования временных меток активизирован. Выдача запроса о временной метке
(timestamp request) позволяет системе выяснить у другой системы текущее время. Зап-
рашивающая система ожидает получить в ответ значение времени, соответствующее ко-
личеству прошедших с полуночи миллисекунд, т.е. согласованное универсальное время
(Coordinated Universal Time). Разрешение времени в миллисекундах считается более по-
лезной характеристикой по сравнению с разрешением времени в секундах. Процедура
разрешения времени выглядит следующим образом:

1.	Запрашивающая сторона отмечает время формирования сообщения (originate time)
и отправляет запрос.

2.	Отвечающая система отмечает время получения сообщения (receive time), когда по-
лучает запрос.

3	Отвечающая сторона отмечает время пересылки ответа на сообщение (transmit time),
когда отправляет ответ на запрос.

Таким образом две системы сравнивают три перечисленные временные метки и ис-
пользуют время полного обхода RTT (Round-Trip Time) для того, чтобы сверить время
хоста-отправителя и хоста-получателя. (Указанные в этих полях значения ненадежны,
и точно измерить время прохождения пакета невозможно. Кроме того, большинство се-
тевых компьютеров устанавливают одинаковое значение для принятых и переданных вре-
менных меток.)

Информационный запрос и ответ (тип 15 и 16)

ICMP-сообщения, содержащие информационные запросы и ответы (Information
Request and Reply), теоретически можно рассматривать как потенциально применимый
тип сообщений. Однако на практике этот тип сообщений используется крайне редко, по-
этому он считается вышедшим из употребления. Тем не менее, хост может выдать какой-
либо запрос информационного характера (например, к какой сети он подсоединен).

Запрос и ответ о маске адреса (тип 17 и 18)

ICMP-сообшения, содержащие запрос на определение маски адреса и ответ на него
(Address Mask Request and Reply), функционируют в тесном взаимодействии друг с дру-
гом. Хотя в настоящее время данный тип сообщений используется редко, первоначаль-
ный замысел заключался в том, что такие сообщения должны поддерживать функцию
динамического определения маски подсети (subnet mask). Хосты могут воспользоваться
ICMP-сообщением, содержащим запрос на определение маски подсети, для получения
масок подсетей во время загрузки с удаленного хоста. Однако при использовании ICMP
для определения маски могут возникнуть проблемы, если тот или иной хост предостав-
ляет некорректную маску адреса внешнего источника. Если внешний источник не дает
ответа на запрос, хост-отправитель должен принять общую маску всей сети (classful mask);
при этом подразумевается, что сеть не разбита на подсети.

Резюме

Протокол IP — это "рабочая лошадка" сетевого уровня в семействе протоколов ТСР/
IP. Все протоколы и приложения используют протокол IP для логической адресации на
сетевом уровне и для передачи дейтаграмм между хостами Интернета. IP предоставляет
ненадежную, не ориентированную на соединение службу доставки дейтаграмм, а также
использует протокол ICMP для формирования сообщений в случае возникновения оши-
бок. Конечные хосты и маршрутизаторы имеют возможность применять ICMP в каче-
стве управляющею, формирующего управляющие сообщения протокола и диагности-
ческого инструмента. Протокол 1СМР считается неотъемлемой частью протокола IP и
использует его для доставки своих сообщений. Сообщения ICMP предупреждают хост о
возникновении тех или иных проблем. Несмотря на то, что протокол ICMP не распола-
гает средствами решения этих проблем, он может предоставить хосту-отправителю до-
статочно информации для устранения некоторых ошибок, которые могут возникнуть во
время работы в Интернете. Наиболее популярный тип ICMP-сообщений — это эхо-зап-
росы и эхо-огветы. Используя утилиты Ping, такие сообщения предоставляют возмож-
ность протестировать соединение между двумя конечными хостами.

Вопросы для повторения

1.	Какой протокол сетевого уровня отвечает за фрагментацию и сборку дейтаграмм?

2.	Пользователь желает проверить наличие связи между двумя удаленными хостами;
для этого он запускает утилиту Ping. Каких два типа ICMP-сообшений используют-
ся для работы этой утилиты?

3	Какие действия предпринимает протокол IP, когда получает данные от протоколов
UDP или TCP?

4.	Какова минимальная длина заголовка дейтаграммы IP9 Назовите поля заголовка IP.

5.	Для чего используются биты поля ToS. входящего в заголовок IP9

6.	Значения каких двух полей заголовка IP использует хост-получатель для обеспече-
ния сборки дейтаграммы в правильной последовательности?

7.	Назовите тип ICMP-сообщения "Недостижимый хост назначения". Каков смысл этого
сообщения?

8.	Объясните смысл сообщения об ошибке, имеющего код 0 и относящегося типу 3 со-
общений 1СМР ("Недостижимый хост назначения").

9.	Объясните смысл сообщения об ошибке, имеющего код 4 и относящегося типу 3 со-
общений ICMP ("Недостижимый хост назначения").

10.	Назовите тип ICMP-сообщения "Время превышено". Каков смысл этого сообщения9
Глава 4

Разрешение адресов

В данной главе рассматриваются следующие протоколы:

•	Протокол разрешения адресов (ARP)

•	Протокол обратного разрешения адресов (RARP)

•	Загрузочный протокол (ВООТР)

•	Протокол динамического конфигурирования хостов (DHCP)

Обмен данными между конечными хост-компьютерами осуществляется посред-
ством коммуникационных моделей, состоящих из различных уровней. Каждо-
му из этих уровней свойственна своя собственная схема адресации конечных хостов и
промежуточных устройств, обрабатывающих пересылаемые данные. Сложность органи-
зации такого процесса обмена данными вызвала необходимость в существовании како-
го-либо способа решения проблемы различия между разными схемами компьютерной
адресации. Задачу согласования работы отличающихся друг от друга схем адресации вы-
полняет метод разрешения адресов (address resolution). Этот метод предоставляет конеч-
ным устройствам возможность динамически транслировать логические адреса удален-
ных хостов (logical addresses) в их локальные аппаратные адреса (local hardware addresses)
и наоборот, а также получать в свое распоряжение логические IP-адреса и конфигура-
ционные параметры, необходимые для функционирования этих устройств в сети. Без
существования подобного метода трансляции адресов удаленные хосты (remote hosts) не
могли бы взаимодействовать. Если речь идет об IP-адресации на сетевом уровне (Network
Layer), то разрешение адресов предполагает преобразование адреса, присваиваемого
протоколом 1Р, в соответствующий физический адрес (например, преобразование IP-
адреса в Ethernet-адрес), или наоборот. Существует четыре способа разрешения адре-
сов, которые обеспечиваются соответственно следующими протоколами:

•	ARP (Address Resolution Protocol, Протокол разрешения адресов)

•	RARP (Reverse Address Resolution Protocol, Протокол обратного разрешения ад-
ресов)

•	ВООТР (Bootstrap Protocol, Загрузочный протокол)

•	DHCP (Dynamic Host Configuration Protocol, Протокол динамического конфигу-
рирования хостов)
На рис. 4.1 показано соответствие протоколов разрешения адресов уровням комму-
никационной модели Министерства обороны США (DoD, Department of Defense) и эта-
лонной модели взаимодействия открытых систем (OSI, Open System Interconnection).

Среди всех перечисленных выше протоколов, выполняющих разрешение адресов,
только протокол ARP преобразует адреса сетевого уровня в аппаратные адреса. Прото-
колы RARP, ВООТР и DHCP предоставляют конечным устройствам возможность ди-
намически транслировать свои аппаратные адреса в логические адреса сетевого уровня.
На рис. 4.2 показан пример разрешения адресов посредством протокола ARP. На рис.
4.3 представлен пример разрешения алресов с помощью протоколов RARP, ВООТР и
DHCP. Эти протоколы рассматриваются более подробно ниже в данной главе.

Модель DoD

РИСУНОК 4.1

Протоколы ARP и RARP
взаимодействуют с
протоколом IP на сетевом
уровне; протоколы DHCP и
ВООТР функционируют на
базе протокола UDP
транспортного уровня.

Модель 0SI

Процесс/
Приложен! е

Межхоь голый
урттень

Интерне!

Доступ к сети

RARP, ВООТР и DHCP

РИСУНОК 4.3 Протоколы
RARP, ВООТР и DHCP
транслируют аппаратный
адрес конечного устройства
в логический сетевой адрес.
Эти протоколы выполняют
функцию,
противоположную по
отношению к функции
протокола ARP.

ARP

РИСУНОК 4.2
Протокол ARP
транслирует
логические адреса
сетевого уровня в
локальные
аппаратные адреса.

Логичес-'й адрес

100.1.5.2

Дрпаратнь/ адрес

00c0.00df.1135

Логический адрес

1001.5.2

Аппаратный адрес
00c0.00df.1135

Протокол ARP

Когда предпринимается попытка инициировать сеанс связи с приложением, выпол-
няемым на удаленном хосте, то используется либо имя удаленного хоста, либо его ло-
гический сетевой адрес. Например, если пользователь запрашивает установление сеан-
са связи с сервером Telnet, он вводит имя удаленного Telnet-сервера (TelnetServ). Это
имя необходимо преобразовать сначала в IP-адрес (логический адрес сетевого уровня,
logical Network layer address), а затем — в физический адрес канального уровня (Data
Link layer hardware address). Когда же предпринимается попытка установления сеанса
связи с использованием лошческого сетевого адреса, то в этом случае нет необходимо-
сти выполнять отображение имени в сетевой адрес. Однако удаленному хосту все же
необходимо транслировать свой сетевой IP-адрес в аппаратный адрес, чтобы обеспечить
доставку данных адресату. Протокол ARP (Address Resolution Protocol, Протокол разре-
шения адресов), подробное описание которого представлено в RFC 826, выполняет та-
кое разрешение адресов динамически.

Первоначальный вариант протокола ARP поддерживал трансляцию логических ад-
ресов сетевого уровня в 48-разрядные физические Ethernet-адреса. Последующие вер-
сии ARP усовершенствованы настолько, что могут поддерживать также и разрешение
адресов для других типов локальных вычислительных сетей. Изменения, которым под-
вергается протокол ARP в процессе его совершенствования, фиксируются в документе
RFC 826.

Приложения и процессы верхних уровней нуждаются в услугах протокола ARP по
обеспечению динамической трансляции адресов сетевого уровня для обеспечения кор-
ректной доставки данных в пункт назначения. Без этого динамического протокола при-
шлось бы вручную выполнять разрешение адресов посредством создания на каждом хосте
статической таблицы, отображающей соответствие между логическими IP-адресами всех
Интернег-хостов и физическими адресами этих хостов или локальных шлюзов. Реали-
зация этого метода привела бы к возникновению массы неудобств, поскольку существует
много различных типов логических адресов на сетевом уровне, и все эти адреса суще-
ственно отличаются по своим размерам. Например, это могут быть 32-разрядные IP-
адреса или 8-разрядные адреса Xerox Вместо идентификации этих адресов и их транс-
ляции в 48-разрядные физические адреса нижнего уровня вручную, ARP выполняет эту
процедуру автоматически. Несмотря на то, что протокол ARP способен выполнять транс-
ляцию различных типов логических сетевых адресов в аппаратные адреса, в данной главе
основное внимание сосредотачивается на разрешении IP-адресов.

Действие протокола ARP

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

Для того чтобы определить нужный локальный физический адрес, хост-отправитель
в первую очередь просматривает адреса, ранее внесенные в локальную таблицу ARP (local
ARP cache table). В оперативной памяти каждого хоста хранится локальная ARP-табли-
ца, содержащая статические (вводимые в таблицу вручную) или динамически опреде-
ляемые адресные данные. Хост может получить в свое распоряжение адресную инфор-
мацию следующими способами:

•	Статическим способом, т.е. через сетевого администратора, выполняющего ото-
бражение логических сетевых адресов в физические адреса в ARP-таблице.

•	Динамическим способом посредством протокола ARP.
Каким бы ни был способ определения адресных данных, хост хранит эти данные в
своей локальной таблице ARP. Если в этой таблице присутствует искомая адресная пара
(сетевой адрес — физический адрес), тогда хост-отправитель может просто воспользо-
ваться этой информацией, не обращаясь к протоколу ARP за помощью в разрешении
данного адреса. В случае если искомой адресной пары в таблице нет, хост-отправитель
использует протокол ARP для трансляции сетевого адреса хоста-получателя в его локаль-
ный физический адрес. Это может произойти в том случае, если ARP-таблица только
что инициализирована на хосте и участок памяти, выделенный под эту таблицу, еще не
заполнен. Как только хост-огправитель определяет локальный физический адрес по
сетевому адресу, он размещает новую адресную пару в своей ARP-таблице с целью даль-
нейшего использования. Хранение полученных таким образом адресных данных в опе-
ративной памяти позволяет хосту ликвидировать (по крайней мере, на ближайшее бу-
дущее) необходимость разрешения адресов в процессе взаимодействия с одним и тем
же хостом.

Протокол ARP обеспечивает разрешение адресов на основе широковещательных рас-
сылок. Это означает, что когда у хоста-отправителя возникает необходимость в опреде-
лении сетевого адреса удаленного хоста, он отправляет широковещательную рассылку
(broadcast) по всем хостам данного локального участка сети. Маршрутизаторы не под-
держивают передачу широковещательных сообщений; следовательно, широковещатель-
ные ARP-запросы остаются локализованными в пределах участка сети, на котором на-
ходится хост-отправизель. Следует обратить внимание на то, что маршрутизаторы все
же могут передавать широковещательные сообщения, если сконфигурированы вспомо-
гательные адреса посредников (как в случае с протоколами ВООТР и DHCP), либо ког-
да разрешена направленная по IP-адресам широковещательная рассылка ARP-заироса;
в любом случае следует помнить о том, что маршрутизаторам несвойственна функция
передачи широковещательных сообщений.

Как было отмечено в предыдущей главе, хост-отправитель определяет принадлеж-
ность хоста-получателя к тому же локальному участку сети, на котором находится и сам
хост-отправитель, сравнивая IP-адрес хоста назначения с маской своей локальной под-
сети. Если посредством такого сравнения хосг-отправитель выясняет, что хост-получа-
тель находится в той же подсети, он может выполнить процедуру "shouting” ("аукать"),
т.е. обратиться к адресату непосредственно (разослать локальный широковещательный
ARP-запрос на определение физического адреса хоста назначения). В то же время, если
хост-отправитель обнаруживает, что адресат находится за пределами данной подсети,
он должен выполнить процедуру "routing" (выбор маршрута, трассировка), т.е. опреде-
лить маршрут к хосту-получателю (разослать локальное широковещательное сообщение
с целью преобразования IP-адреса шлюза в его физический адрес для дальнейшего про-
движения дейтаграммы). Как только хост-отправитель определится с тем, каким обра-
зом он должен получить в свое распоряжение физический адрес хоста-получателя, он
рассылает локальный запрос (local query) на трансляцию IP-адреса хоста назначения или
локального шлюза в физический адрес. Хост-отправитель как будто спрашивает в своем
широковещательном ARP-запросе: "Кто-нибудь узнает сетевой адрес х.х.х.х ?" (симво-
лы "х“ в данном случае представляют 32-разрядный IP-адрес хоста назначения или ло-
кального шлюза). Далее хосг-отправитель ожидает одного из следующих действий:
•	Хост назначения отвечает на запрос.

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

На рис. 4.4 показано, как хост-отправи гель рассылает свой широковещательный ARP-
запрос на определение физического адреса локального хоста-получателя. В данном при-
мере хост А намеревается связаться с хостом В, который находится на том же локаль-
ном участке сети. Для этого хост А просто отправляет свой широковещательный
ARP-запрос на хосты локального участка сети, спрашивая в запросе, узнает ли какой-
либо из хостов адрес 100.0.0.2. Хост В отвечает на этот запрос утвердительно, передавая
при этом свой локальный физический адрес. Другими словами, если хост-отправигель
обнаруживает, что адресат находится в той же подсети, он попросту отправляет свой ши-
роковещательный ARP-запрос с целью определения физического адреса хоста назначе-
ния.

В случае если хост-отправитель обнаруживает, что адресат находится за пределами
данной подсети, он рассылает свой широковещательный ARP-запрос с целью определе-
ния физического адреса локального шлюза, который пересылает дейтаграмму на уда-
ленный хост. На рис. 4.5 показан пример того, как хост-отправитель рассылает широ-
ковещательный ARP-запрос для определения по IP-адресу локального шлюза его
физического адреса, необходимого для доставки дейтаграммы на удаленный хост. На этом
рисунке хост А намеревается связаться с хостом В, который находится за пределами дан-
ной локальной сети. Хост А рассылает по локальному участку сети широковещательный
ARP-запрос на определение физического адреса локального шлюза по его IP-адресу. В
состав конфигурационных параметров конечных хостов должен входить IP-адрес локаль-
ного шлюза. Это позволяет хостам устанавливать соединение с другими хостами, нахо-
дящимися вне их локального участка сети.

ARP-запрос на разрешение адреса локального хоста

Кто-нибудь

узнает адрес

100.0.0.2?

РИСУНОК 4.4

На данном рисунке
показана процедура
“shouting" Другими
словами, хост А
обращается
непосредственно к хостам
данного локального участка
сети, рассылая
широковещательный
ARP-запрос.

Широковещательная рассылка ARP-запроса станции А

Я узнаю этот адрес1

100.0.0.2
ARP-запрос на разрешение адреса локального шлюза

РИСУНОК 4.5

На данном рисунке
представлена процедура
"routing" Другими словами,
хост А определяет
маршрут к удаленному
пункту назначения, т.е.
рассылает
широковещательный ARP-
запрос на разрешение
адреса локального шлюза,
передающего дейтаграммы
удаленным хостам.

На полученный ARP-запрос хост-получатель или локальный шлюз, как правило, от-
вечает таким образом: "Я узнаю этот адрес; вот мой физический адрес". В таком случае
хост-отправитель получает достаточно информации для того, чтобы отправить дейтаг-
рамму на конечный хост или на шлюз, передающий дейтаграмму далее по сети по на-
правлению к удаленному хосту-получателю. Имея в своем распоряжении полученные
адресные данные, хост-отправитель может правильно адресовать дейтаграмму, отобра-
жая в этой адресации логический сетевой адрес удаленного хоста назначения, а также
физический адрес локального хоста или шлюза, ответственного за доставку дейтаграм-
мы.

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

1.	Если хост назначения находится на том же локальном участ ке сети, что и сам шлюз,
данный шлюз для получения искомого аппаратного адреса просматривает ранее вне-
сенные в локальную ARP- таблицу записи.

2.	Если в ARP-таблице нет записи, соответствующей адресу хоста назначения, марш-
рутизатор отправляет ARP-запрос всем устройствам данного участка сети с целью
определения физического адреса, необходимого для доставки дейтаграммы в пункт
назначения.

3.	Если хост назначения расположен за пределами того локального участка сети, на ко-
тором находится шлюз, шлюз прибегает к услугам протокола ARP для определения
физического адреса следующего шлюза, который можно использовать для передачи
дейтаграммы адресату.

4.	Указанное в предыдущем пункте действие выполняется в процессе доставки дейтаг-
раммы по всему пути до пункта назначения до тех пор, пока передаваемый кадр не
достигнет шлюза, подключенного к той же подсети, что и хост назначения. Этот шлюз
либо использует внесенный ранее в ARP-таблицу физический адрес для доставки дей-
таграммы непосредственно адресату, либо выполняет локальную процедуру опре-
деления физического адреса хоста-получателя по его адресу сетевого уровня посред-
ством протокола ARP.

Механизм внесения изменений в таблицу ARP

В зависимости от конкретной реализации хосты могут применять один или более ме-
ханизмов контроля над удалением устаревших или некорректных записей из таблицы
ARP. Подобные механизмы гарантируют наличие в ARP-таблице только корректных
записей. Например, если локальный хост меняет свой Ethemet-адрес (такое случается,
когда происходит замена платы сетевого адаптера), то необходимо обновить соответству-
ющую запись в его ARP-таблице. Различные механизмы контроля над обновлением таб-
лиц ARP рассматриваются в следующих разделах данной главы.

Тайм-аут

Каждый хост имеет в своем распоряжении конфигурируемый в оперативной памяти
таймер ARP (ARP cache timer), контролирующий период времени, по истечении кото-
рого следует заменить запись об определенных динамическим способом адресных дан-
ных. Конфигурационные параметры подобных таймеров отличаются в зависимости от
используемой в каждом конкретном случае операционной системы. Значение таймера
устанавливается в тот момент, когда хост вносит запись в таблицу ARP. По истечении
периода времени (тайм-аута, timeout), установленного в таймере, запись считается ус-
таревшей и удаляется из памяти.

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

Односторонний опрос

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

Уведомление канального или верхнего уровней

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

Прокси ARP (Proxy ARP) — агент (посредник) протокола ARP, позволяет другому
устройству, такому как шлюз или маршрутизатор, отвечать на ARP-запросы от имени
удаленного хоста, чтобы выполнить разрешение адресов. Маршрутизатор (шлюз), фун-
кционирующий в качестве прокси ARP, действует как реальный хост-получатель. На
самом деле требуемый адресат находится в другой сети, по другую сторону от посред-
ника ARP. Функционирование шлюза (маршрутизатора) в качестве прокси ARP позво-
ляет передавать дейтаграммы хоста-отправителя другим хостам в прозрачном режиме
(transparently). Необходимость в активизации прокси ARP возникает достаточно часто.
Подобная ситуация может сложиться, например, когда сетевой администратор непра-
вильно сконфигурировал хосты сети либо когда он посчитал необходимым подключить
многочисленные участки через один маршрутизатор, имитируя тем самым одну подсеть.
Администратор имеет возможность сконфигурировать прокси ARP на хостах и шлюзах (там,
где это необходимо) посредством соответствующих конфигурационных параметров.

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

Действие прокси ARP

Лучший способ понять, как работает прокси ARP — это рассмотреть его действие на
конкретном примере Как показано на рис. 4.6, хост-отправитель и хост-получатель на-
ходятся в разных подсетях (хост А принадлежит подсети 172.15.1.0, а хост В — подсети
172.15.2.0). Следует обратить внимание на то, что шлюз, находящийся между этими хо-
стами, сконфигурирован как прокси ARP. Следовательно, этот шлюз имеет возможность
отвечать на локальные ARP-запросы от имени удаленных хостов. Когда шлюз, функци-
онирующий в качестве прокси ARP. действует таким образом, он указывает в ответе на
ARP-запрос свой собственный физический адрес. ХостА с неправильно сконфигуриро-
ванным адресом маски подсети (255.255.0.0) полагает, что хост В находится в той же
подсети, что и он сам. По этой причине хост А считает возможным обратиться непос-
редственно к хосту В (разослать локальный широковещательный ARP-запрос на опре-
деление физического адреса хоста В по его локальному IP-адресу). На самом деле хосту
А следовало бы определить маршрут к хосту В (разослать локальный широковещатель-
ный ARP-запрос на определение необходимого для дальнейшей передачи данных фи-
зического адреса шлюза по его I Р-адресу).

Ниже перечислены действия, выполняемые в процессе обмена данными между дву-
мя конечными хостами через промежуточный маршрутизатор, поддерживающий про-
кси ARP:

1.	Хост А (172.15.1.2), находящийся в сети 172.15.1.0, и хост В (172.15.2.2), находящий-
ся в удаленной сети, имеют намерение связаться друг с другом. Маршрутизатор, вы-
полняющий функции прокси ARP, находится между хостом А и хостом В.
РИСУНОК 4.6
Функционирование в
качестве прокси ARP
позволяет шлюзу отвечать
на ARP-запросы от имени
хоста, находящегося в
другой сети.

Прокси ARP

2.	Хост А сконфигурирован администратором с маской адреса подсети стандартного
класса В (255.255.0.0). Этот адрес некорректен, поскольку данная сеть имеет еще
большую вложенность и должна иметь маску адреса стандартного класса С
(255.255.255.0). Хост А предпринимает попытку определить свои дальнейшие дей-
ствия, а именно: отослать ли свой локальный ARP-запрос непосредственно на стан-
цию В или же определить путь к хосту В через маршрутизатор. Хост А пытается
сделать выбор на основании сравнения IP-адреса хоста назначения с маской адреса
своей подсети.

3.	Поскольку значения первых двух байтов масок адресов хоста А и хоста В совпада-
ют, хост А делает ошибочный вывод, что хост В находится в той же сети 172.15.0.0
На этом основании хост А принимает решение разослать локальный широковеща-
тельный ARP-запрос на хосты данного участка сети, чтобы определить аппаратный
адрес хоста В по его сетевому адресу.

4.	Поскольку хост В на самом деле находится вне данного участка сети, он не получа-
ет отправленный хостом А широковещательный ARP-запрос и поэтому не реагиру-
ет на него. При обычных обстоятельствах подобный ARP-запрос остался бы без от-
вета. Однако этого не случится, если локальный маршрутизатор сконфигурирован в
качестве посредника ARP.

5.	Маршрутизатор, функционирующий в качестве прокси ARP, принимает такой ARP-
запрос и реагирует на него от имени хоста В, выдавая в качестве ответа свой соб-
ственный физический адрес. Это позволяет хосту А взаимодействовать с хостом В в
прозрачном режиме, даже если хост В неправильно сконфигурирован.

Заголовок ARP

Заголовок ARP (ARP header) содержит 28 байтов информации. На рис. 4.7 представ-
лен формат заголовка ARP. Рис. 4.8 знакомит с полями заголовка ARP с помощью окна
анализатора протоколов Sniffer На рис. 4.9 показан ARP-запрос и ARP-ответ, исполь-
зуемые для трансляции IP-адреса в физический Ethernet-адрес. Описание каждого из
полей заголовка ARP представлено ниже.

На рис. 4.8 следует обратить внимание на то, что в поле Etertype заголовка протоко-
ла управления канальным уровнем DLC (DataLink Control header) установлено значе-
ние 0806, соответствующее протоколу ARP. Физический адрес хост-получателя состо-
ит из символов "F", а это означает, что данный запрос передается в широковещатель-
ной рассылке по адресам всех устройств данного участка сети. Значение 1, установлен-
ное в поле кода сообщения (Opcode), показывает, что это — ARP-запрос (в отличие от
ARP-ответа, имеющего значение 2 в поле кода сообщения). Хост-отправитель, иденти-
фицируемый физическим адресом Sun061787 и IP-адресом 129.84.25.26, запрашивает
трансляцию 4-байтового IP-адреса получателя 129.84.25.1 (поле Ethertype равен 0x0800)
в 6-байтовый аппаратный Ethernet-адрес. Следует обратить внимание на то, что аппа-
ратный адрес получателя состоит из нулей, а это значит, что он пока неизвестен.

РИСУНОК 4.7

Следует обратить
внимание на то, что
заголовки протоколов ARP
и RARP имеют идентичный
формат.

Тип (локальной) сети		Тип протокола верхнего уровня
Длина аппаратного Длина адреса верхнего адреса	уровня (1Р-адреса)		Код сообщения
Аппаратный адрес отправителя (октеты 0-3)		
Аппаратный адрес отправителя (октеты 4-5)	Адрес верхнего уровня (1Р-адрес) отправителя (октеты 0-1)	
IP-адрес отправителя (октеты 2-3)	Аппаратный адрес получателя (октеты 0-1)	
Аппаратный адрес получателя (октеты 2-5)		
Аппаратный адрес получателя (октеты 0-3)		

Тип рабочего протокола (ARP)

Аппаратный адрес получателя

Ио Lo«ri/DLil4Jp	- |Snrf1 : 1/2 ЕЛ’-гмЧ Ншм!“ИГУ КЗ

Код сообщения-
Аппаратный адрес
отправителя

отправителя

Аппаратный адрес-
получателя

IP-адрес получателя

РИСУНОК 4.8 В данном примере широковещательный ARP-запрос рассылается по локальному

участку сети.
В кадре I видно, что хост-отправитель Sun061787 отправляет ко всем хостам локаль-
ного участка сети широковещательную рассылку, содержащую вопрос о том, распозна-
ют ли эти хосты адрес верхнего уровня (РА,Protocol Address) 129.84.25.1 как IP-адрес. В
кадре 2 хост 129.84.25.1 отсылает ARP-ответ, содержащий его аппаратный адрес
АТ&Т030001.

Поле типа (локальной) сети

Поле типа локальной сети (Hardware Туре), имеющее длину 2 байта, идентифициру-
ет одну из базовых локальных сетей, таких как Ethernet, Token-Ring или какой-либо
другой тип сети. Протокол ARP применяет данное поле вместе с полем типа протокола
(Protocol Туре) во время рассылки ARP-запросов и ARP-ответов для того, чтобы ука-
зать, преобразование какого именно адреса верхнего уровня выполняется и в какой
аппаратный адрес.

Кадр 1

Кадр 2

РИСУНОК 4.9 ARP-ответ (кадр 2) на широковещательный ARP-запрос, разосланный в кадре I.

Поле типа протокола

Значение, указанное в поле типа протокола (Protocol Туре) длиной 2 байта, иденти-
фицирует тип протокола сетевого уровня. Это значение позволяет протоколу ARP вы-
полнять процедуру разрешения адресов сетевого уровня (Network layer protocol addresses)
для различных протоколов. Например, общеизвестное зарегистрированное шестнадца-
теричное значение типа протокола 0x0800 соответствует протоколу 1Р; значение типа
протокола 0x8137 соответствует протоколу IPX (Internetwork Packet eXchange, Обмен
межсетевыми пакетами для NetWare).

Поле длины аппаратного адреса

Поле длины аппаратного адреса (Hien, Length of Hardware Address), имеющее длину
1 байт, задает размер аппаратного адреса (в байтах), который протокол ARP рассчиты-
вает получить в качестве ответа на свой запрос. Значение этого поля меняется в зависи-
мости от типа локальной сети. Например, если в поле типа локальной сети (Hardware
type) указано значение 1, соответствующее сети Ethernet, реализующей 48-разрядныс (6
байтов) физические адреса, то в поле длины аппаратного адреса (Hlen) будет указано
значение 6.

Поле длины адреса верхнего уровня

В поле длины адреса верхнего уровня (Plen, Length of Protocol Address) указывается
значение, соответствующее размеру сетевого адреса одного из протоколов верхнего уров-
ня. В этом поле, имеющем размер 1 байт, задается длина (в байтах) адреса протокола
сетевого уровня, подвергающегося на данном этапе процедуре трансляции в соответству-
ющий физический адрес. Поскольку протокол ARP способен выполнять разрешение ло-
гических адресов различных протоколов сетевого уровня, для задания длины адреса
верхнего уровня (Plen) необходимо уточнить значение типа протокола. Например, если
в поле типа протокола (Protocol type) задан протокол IP (0x0800), то в поле длины адре-
са верхнего уровня (Plen) следует указать значение 4. что соответствует 32-разрядному
адресу.

Поле кода сообщения

Поле кода сообщения (operation code), имеющее длину 2 байта, специфицирует тип
выполняемого протоколом ARP или RARP действия:

1.	ARP-запрос (значение 1)

2.	ARP-ответ (значение 2)

3.	RARP-запрос (значение 3)

4.	RARP-ответ (значение 4)

В поле кода сообщения (Opcode) указаны значения, соответствующие как ARP, так
и RARP, поскольку оба протокола пользуются для оформления передаваемых ими со-
общений заголовками идентичного формата. Следовательно, кадры обоих протоколов
выглядят одинаково, но указывать в поле кода сообщения (Opcode, необходимо то зна-
чение, которое соответствует используемому на данном этапе протоколу. Значение, ус-
тановленное в поле кода сообщения (Opcode), идентифицирует предназначение каждо-
го конкретного кадра. По оформлению кадра четко видно, является ли данное сообщение
ARP-запросом (ARP-ответом) или RARP-запросом (RARP-ответом). Отличить кадр ARP
от кадра RARP можно также по значению поля Ethertype в заголовке DLC. Протоколу
ARP соответствует значение 0806, в то время как протоколу RARP — значение 8035.
Протокол RARP рассматривается более подробно ниже в данной главе.
Поле аппаратного адреса отправителя

Хост-отправитель размещает свой физический адрес в поле аппаратного адреса от-
правителя (Sender's Hardware Address) с целью идентификации Длина данного поля равна
6 байтам.

Поле адреса верхнего уровня (1Р-адреса)

отправителя

Хост-отправитель размещает свой логический адрес сетевого уровня (IP-адрес) в поле
адреса верхнего уровня отправителя (Sender's Protocol Address) с целью идентификации.
Длина данного поля равна 4 байтам.

Поле аппаратного адреса получателя

Значение, указанное в поле аппаратного адреса получателя (Target Hardware Address),
идентифицирует физический адрес хоста-получателя (если он известен). Когда хост пред-
принимает попытку транслировать логический адрес сетевого уровня в аппаратный ад-
рес, указание нолей в данном поле значит, что данный адрес неизвестен.

Поле адреса верхнего уровня (IP-адреса) получателя

Значение, указанное в данном поле (Target Protocol Address), имеющем длину 4 бай-
та, идентифицирует адрес сетевого уровня (IP-адрес) хоста-получателя. Когда хост от-
сылает свой ARP-запрос, в этом поле указывается логический адрес хоста-получателя,
подвергающийся на данном этапе процедуре разрешения.

Протокол RARP

Функции протокола RARP (Reverse Address Resolution Protocol, Протокол обратного
разрешения адресов), разработанного для динамической трансляции аппаратного адре-
са хоста в его логический сетевой адрес, определены в документе RFC 903. RARP вы-
полняет задачи, противоположные по отношению к функциям описанного выше в дан-
ной главе протокола ARP. Протоколы ARP и RARP имеют заголовки идентичного
формата с одними и теми же полями. Поскольку в заголовках обоих протоколов приме-
няются одни и те же поля, они не будут детально обсуждаться в данном разделе. Если
нужна более подробная информация, можно обратиться к описанию заголовка ARP.
Отличить протокол ARP от протокола RARP можно по значению, указанному в поле
типа протокола. Значение 8035 в поле типа Elhertype заголовка DLC соответствует про-
токолу RARP, а значение 0806 — протоколу ARP.

Первоначально протокол RARP был разработан для того, чтобы предоставить без-
дисковым клиентам возможность динамически отыскивать свой собственный логичес-
кий адрес через удаленный хост. Поскольку бездисковые клиенты не имеют постоянно-
го места для хранения подобной информации, им нужен удаленный сервер RARP для
хранения своего аппаратного адреса и соответствующего ему лог ического сетевого ад-
реса; содержащая эти адреса запись отображается в статической таблице отображения
адресов (static mapping table). Сетевой администратор должен создать такую статичес-
кую таблицу соответствия между физическими и логическими адресами на сервере RARP
для каждого клиента, находящегося в пределах данной подсети; он также должен об-
новлять эту таблицу каждый раз, когда изменяется аппаратный адрес хоста или его ло-
гический адрес сетевого уровня.

Подобно протоколу ARP, протокол RARP функционирует на основе широковеща-
тельных рассылок. Из этого факта следует , что дейтаграммы этих протоколов не могут
передаваться межсетевыми шлюзами (маршрутизаторами). Из-за подобного ограниче-
ния в каждой локальной подсети необходимо поместить, по крайней мере, один сервер
RARP для обслуживания запросов клиентов RARP. Наличие многочисленных серверов
RARP в пределах одной подсети предусматривает такую избыточность, которая исклю-
чает малейшую возможность неудачного исхода при определении логического адреса
хоста по его аппаратному адресу. Однако необходимость в наличии не менее одного
сервера RARP на каждом участке сети означает присутствие в сети большого количе-
ства серверов RARP для обслуживания бездисковых хостов или любого другого хоста,
нуждающегося в динамическом присвоении ему логического адреса. Кроме того, сете-
вой администратор обязательно должен регулярно обновлять и обслуживать статичес-
кую таблицу, что. в свою очередь, привносит в работу сети массу непроизводительных
административных затрат.

Действие протокола RARP

Перед началом взаимодействия хоста с другими хостами той или иной сети необхо-
димо предоставить протоколу RARP определенную конфигурационную информацию об
этом хосте. Бездисковый хост или любой другой хост, не имеющий подобной информа-
ции, должен иметь возможность каким-либо образом ее получить. Подобная ситуация
может возникнуть, если хост ранее не был сконфи1урирован сданной информацией или
у него не нашлось места для ее хранения. В таком случае при инициализации такой хост
может выдать запрос на присвоение ему логического адреса на сетевом уровне. Подоб-
ный запрос должен быть направлен на удаленный хост, обслуживающий протокол RARP.
Про|раммный код. необходимый протоколу RARP для того, чтобы он мог инициализи-
ровать и завершить процедуру загрузки для клиента, записывается в ППЗУ, (PROM.
Programmable Read Only Memory — программируемое постоянное запоминающее уст-
ройство) локального хоста.

В процессе получения хостом своего логического адреса верхнего уровня выполня-
ются следующие действия:

1.	Хост-отправитель рассылает RARP-запрос в локальной широковещательной рассылке.

2.	Данный хост указывает свой известный аппаратный адрес и запрашивает присвое-
ние ему логического адреса верхнего уровня любым сервером RARP, получившим
этот запрос.

3.	Серверы RARP, находящиеся на данном локальном участке сети, получают запрос
и просматривают свою базу данных па наличие записи, содержащей аппаратный
адрес данною хоста-отправителя и соответствующий ему логический адрес верхне-
го уровня.

4	Если такая адресная пара в таблице имеется, сервер RARP передает направленную
непосредственно па хост-получатель дейтаграмму (oriented datagram), содержащую
требуемые адресные данные.
5.	Если нужной адресной пары не существует (это может произойти в случае, когда в
таблице нет указанного хостом-отправителем аппаратного адреса), сервер не отве-
чает на запрос.

6.	Если клиент не получает ответа от сервера RARP, он прекращает попытки получе-
ния необходимых ему адресных данных; при этом хосту не удается успешно иници-
ализироваться в качестве участника процесса коммуникации в пределах данной сети.

7.	В случае успешного завершения процесса разрешения аппаратного адреса хоста и
определения его логического адреса верхнего уровня полученная информация по-
мешается в памяти локального хоста и хранится в ней до следующей загрузки

Сравнительная характеристика протоколов ARP и
RARP

Как было отмечено выше при обсуждении действия протокола ARP, отправляемый
хостом ARP-запрос можно интерпретировать так: "Кто-нибудь узнает сетевой адрес
х.х.х.х ?" (символы "х" в данном случае представляют собой 32-разрядный IP-адрес хо-
ста назначения). Примеры ARP-запросов показаны на рис. 4.8 и 4.9.

В то же время, отправляемый протоколом RARP запрос можно интерпретировать сле-
дующим образом: 'Я знаю свой аппаратный адрес: вот он. Можете ли вы сообщить мне
мой алрес сетевого уровня (х.х.х.х)?" На рис. 4.10 и 4.11 показаны примеры запроса и
ответа RARP.



Хосг-о. правитель	Поле Ethertype заголовка ОсС Кадр I

DLC Heeder

Frame 1 arrived at 09:31:01

- ад DLC:
ijDLC:
Ddlc*
У DLC:
J DLC;

3DLC:

J DLC:
-Г ARE1:

J ARP:
ijARP:

£3 ARP;
_JARF:

Lest iiiation
Source
Ethertype

9022; Frame size is 60 (003C hex J bytes.

BROADCAST FFFF FFFFFFF, Broadcast
Station SunOll E8
B0 35 (RARP)--

Hardware type - 1 (10Mb Ethernet)

Protocol type - 0800 (IP)

Length of hardware addrese - 6 bytes

Length of protocol addrese = 4 ЬуТа=-

LjARP: Opcode 3 (RARP request)-

^JARP: Sender's hardware address - SunO115E$
43 ARP: Sender's protocol address - [0.0.0.0]
i_)ARP: Target hardware address - SunO115E8

, cjARP: Target protocol address.	- [O.D.D.O],

ijAR₽:

.Поле кода
сообщения

.Аппаратный

адрес отправителя

Логический

адоес получателя



Fo:	were F1

ж.

JSSiUfa.



РИСУНОК 4.10 В кадре первом, выделенном на итоговой панели и показанном в окне детализации
анализатора протоколов Sniffer, представлены различные поля заголовка RARP. Следует обратить
внимание на то, что л поле Ethertype заголовка DL С указано значение S035, соответствующее
протоколу RARP.

5 Зак 768
На рис. 4.10 хост с аппаратным адресом SunOl 15Е8 рассылает свой широковещатель-
ный RARP-запрос. То, что данное сообщение является запросом, а не ответом, видно
по значению 3, указанному в поле кода сообщения (Opcode). Хосту-отправителю изве-
стен его аппаратный адрес, но неизвестен логический адрес сетевого уровня; поэтому
хост-отправитель заполняет соответствующее поле нолями (0.0.0.0). Хосту-отправителю
неизвестен аппаратный или IP-адрес сервера RARP, но ему на самом деле и не нужно его
знать, поскольку он рассылает данный кадр в широковещательной рассылке на канальном
уровне, и любой сервер RARP данного участка сети может принять этот запрос.

Задача данного кадра — трансляция аппаратного адреса хоста в его логический ад-
рес верхнего уровня. Следовательно, хост-отправитель RARP-запроса является в то же
время получателем RARP-от вета, содержащего логический адрес данного хоста. Поэто-
му аппаратный адрес получателя (target hardware address), указанный в заготовке RARP
в качестве объекта процедуры разрешения адресов — это и есть аппаратный адрес само-
го хоста-отправителя, а поле адреса верхнего уровня получателя (target protocol address)
заполнено нолями, поскольку этот адрес неизвестен. На рис. 4.11 следует обратить вни-
мание на то, что в кадре, содержащем ответ RARP, значение поля кода сообщения
(Opcode) равно 4, а это значит, что данное сообщение является ответом, а не запросом.
Еще один важный момент, на который следует обратить внимание: данный кадр не
передается в широковещательной рассылке, а содержит в себе ориентированную дей-
таграмму, направленную сервером RARP SunO14B7F (192.29.43.51) непосредственно на
хост SunO115E8 с присвоением ему IP-адреса 192.29.43.64.

РИСУНОК 4.11 Протокол RARPвыполняет функции, противоположные по отношению к функциям
протокола ARP, RARP обеспечивает определение IP-адреса хоста по его аппаратному адресу
Недостатки протокола RARP

Протокол RARP, имеющий существенные недостатки, был вытеснен другими, более
надежными протоколами, такими как ВООТР и DHCP. Эти протоколы рассматривают-
ся ниже в данной главе. Основные недостатки протокола RARP заключаются в следую-
щем:

•	Маршрутизаторы не могут пересылать по сети запросы и ответы протокола RARP.

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

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

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

Заголовок RARP

Заголовок RARP практически идентичен заголовку ARP. Единственное отличие зак-
лючается в том, что в поле типа кадра заголовка RARP-пакета указывается значение
0x8035, соответствующее протоколу RARP. Кроме того, в поле кода сообщения (Opcode)
устанавливается значение 3 для запроса RARP и значение 4 для ответа RARP. Так же,
как и заголовок ARP, заголовок RARP имеет длину 28 байтов. Ниже приведено описа-
ние полей заголовка RARP (формат заголовка ARP или RARP показан на рис. 4.7).

Поле типа (локальной) сети

Поле типа локальной сети (Hardware Туре), имеющее длину 2 байта, идентифициру-
ет одну из базовых локальных сетей, таких как Ethernet. Token-Ring или какой-либо
другой тип локальной сети. Протокол RARP применяет данное поле вместе с полем типа
протокола (Protocol Туре) во время пересылки RARP-запросов и RARP-ответов для того,
чтобы определи!ь адрес верхнего уровня хоста по его аппаратному адресу. Если прото-
кол RARP выполняет разрешение аппаратных адресов Ethernet, в этом поле должно быть
установлено значение 1.

Поле типа протокола

Значение, указанное в поле типа протокола (Protocol Туре) длиной 2 байта, иденти-
фицирует тип протокола сетевого уровня. Это значение позволяет протоколу RARP вы-
полнять процедуру разрешения различных аппаратных адресов в адреса сетевого уров-
ня (Network layer protocol addresses) Например, если протокол RARP выполняет разре-
шение IP-адресов, в этом поле должно быть установлено общеизвестное значение типа
протокола 0x0800, соответствующее протоколу 1Р.

Поле длины аппаратного адреса

Поле длины аппаратного адреса (HLen, Length of Hardware Address), имеющее длину
1 байт, задает размер аппаратного адреса (в байтах), разрешение которою выполняет про-
токол RARP. Значение этого поля меняется в зависимости от типа локальной сети. На-
пример, если в поле Ethertype заголовка DLC указано значение 1, соответствующее сети
Ethernet, реализующей 48-разрядные (6 байтов) физические адреса, то в поле длины ап
парадного адреса (Hlen) должно быть указано значение 6.

Поле длины адреса верхнего уровня

В поле длины адреса верхнего уровня (Plen, Length of Protocol Address) указывается
значение, соответствующее размеру адреса сетевого уровня, который протокол RARP
рассчитывает получить в результате выполнения процедуры разрешения аппаратного
адреса хоста. Необходимость указания того или иного значения в этом поле существует
из-за того, что протокол RARP может преобразовать аппаратный адрес в различные
логические адреса сетевого уровня, предназначенные для разных протоколов. Напри
мер, если в поле типа протокола (Protocol Туре) указано значение 0x0800, соответству-
ющее протоколу 1Р, в поле длины адреса верхнего уровня (Plen) должно быть установ-
лено значение 4, что соответствует размеру 4 байта (32 бита).

Поле кода сообщения

Поле кода сообщения (Opcode, operation code), имеющее длину 2 байта, специфици-
рует тип выполняемого протоколом ARP или RARP действия:

1.	ARP-запрос (значение 1)

2.	ARP-ответ (значение 2)

3.	RARP-запрос (значение 3)

4.	RARP-ответ (значение 4)

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

Поле аппаратного адреса отправителя

Хост-отправитель размещает свой физический адрес в поле аппаратного адреса от-
правителя (Sender's Hardware Address) с целью идентификации. Длина данного ноля равна
6 байтам.

Поле адреса верхнего уровня (1Р-адреса)

отправителя

Хост-отправитель помещает свой логический адрес сетевого уровня (IP-адрес) в поле
адреса верхнего уровня отправителя (Sender's Protocol Address) с целью идентификации
Длина данного поля равна 4 байтам. Если указанный в данном поле адрес состоит из
нолей, то это значит, что клиент RARP отправил начальный запрос в широковещатель-
ной рассылке по всем серверам RARP. Заполнение поля адреса верхнего уровня отпра-
вителя (Sender's Protocol Address) нолями указывает на то, что хосту неизвестен этот адрес.

Поле аппаратного адреса получателя

Значение, указанное в поле аппаратного адреса получателя (Target Hardware Address),
идентифицирует физический адрес хоста получателя. В запросе RARP это значение на
самом деле соответствует аппаратному адресу хоста-отправителя, который в данном
случае выступает в роли получателя ответа на RARP-занрос. В ответе RARP это значе-
ние соответствует аппаратному адресу клиента RARP.

Поле адреса верхнего уровня (IP-адреса) получателя

Значение, указанное в данном поле (Targel Protocol Address), имеющем длину 4 бай-
та, идентифицирует адрес сетевого уровня (IP-адрес) хоста-получателя (места назначе-
ния 01 вега RARP). Когда хост отсылает свой RARP-запрос, в этом поле указывается ло-
гический адрес хоста, состоящий из нолей (т.е. адрес неизвестен) Посылая такого рода
запрос, протокол RARP предпринимает попытку узнать этот адрес. В ответе RARP в дан-
ном поле (Target Protocol Address) указывается логический адрес, присвоенный клиенту
RARP сервером RARP.

Протокол ВООТР

Выше в данной главе изложены причины, по которым возникла необходимость в ре-
ализации метода разрешении адресов; в этой же главе рассмотрены протоколы ARP и
RARP, выполняющие разрешение адресов, а также поля и функции этих протоколов.
Как было отмечено выше, оба протокола функционируют на основе широковещатель-
ных рассылок и используются для выполнения процедуры разрешения адресов для хо-
стов. Протокол ARP осуществляет трансляцию логического адреса хоста в его аппарат-
ный адрес; протокол RARP по аппаратному адресу определяет логический адрес хоста.
Следует помнить о том, что дейтаграммы, содержащие запросы и ответы протоколов ARP
и RARP, отравляются в широковещательной рассылке, а это значит, чго они не пере-
даются маршрутизаторами.

Первоначально протокол ВООТР (Bootstrap Protocol, Загрузочный протокол) разра-
батывался в качестве преемника имеющего определенные недостатки протокола RARP.
Первая версия протокола ВООТР, специфицированная в RFC 951, предназначалась (как
и протокол RARP) для клиентов, не имеющих жестких дисков, с целью получения от
удаленного сервера загрузки данных об IP-адресе хоста. Кроме получения адресных дан-
ных бездисковый хост мог выдать запрос на получение удаленного конфигурационного
файла, необходимого для начальной загрузки, от сервера TFTP (Trivial File Transfer
Protocol, Простейший протокол передачи данных) или какого-либо другого удаленного
сервера загрузки.

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

В отличие от протоколов ARP и RARP, функционирующих на сетевом уровне и ис-
пользующих службы протокола 1Р для доставки своих запросов и ответов, протокол
ВООТР пользуется для доставки своих сообщений сервисами, предоставляемыми про-
токолами TCP и UDP. Номер 68 идентифицирует порт UDP клиента, а номер 67 — порт
UDP сервера (порты TCP и UDP подробно рассматриваются в главах 7 и 8 соответствен-
но). Еще одно отличие протокола ВООТР от ARP и RARP заключается в том, что мар-
шрутизаторы могут передавать запросы и ответы ВООТР. Это позволяет располагать сер-
веры ВООТР в пределах сетевого комплекса оптимальным способом; при этом не
требуется наличие сервера ВООТР на каждом участке сети.

Существует три варианта конфигурирования сервера ВООТР:

•	Конфигурирование маршрутизаторов (шлюзов) таким образом, чтобы они были
в состоянии передавать запросы и ответы клиентов и серверов ВООТР посред-
ством активизации портов UDP 67 и 68.

•	Конфигурирование шлюза или локального хоста в качестве сервера ВООТР по-
средством активизации на этом шлюзе или хосте процесса ВООТР и создания до
кальной статической таблицы отображения адресов.

•	Конфигурирование какого-либо устройства (локального хоста или маршрутиза-
тора) в качестве промежуточного агента ВООТР (ВООГР proxy agent) на данном
локальном участке сети.

Первый вариант не представляет особого интереса, поскольку в случае простого от-
крытия портов TCP или UDP на данном маршрутизаторе через него смогут проходить
кадры, содержащие широковещательные запросы и ответы ВООТР. Это противоречит
основному назначению маршрутизатора — сводить к минимуму такой тип информаци-
онного потока.

Во втором варианте не существует необходимости в пересылке запросов ВООТР за
пределы локального шлюза. Однако в этом случае значительно возрастает нагрузка на
шлюз, который, возможно, уже и так перегружен. Данный вариант следует применять
для конфигурирования в качестве сервера ВООТР только локального хоста, освобождая
при этом от излишней нагрузки шлюз, который следует использовать исключительно для
пересылки ориентированных дейтаграмм.

Третий вариант позволяет локальному хосту или шлюзу прослушивать локальные ши-
роковещательные сообщения ВООТР и перекомпоновывать их в формат ориентирован-
ных дагаграмм, пересылая их при этом непосредственно на сервер или серверы ВООТР,
расположенные на другом участке сети. От имени хоста, отправляющего ВООТР-зап-
рос, агент отправляет этот запрос либо в форме направленной по одному адресу дейтаг-
раммы (unicast datagram), либо в форме направленной по адресам хостов подсети широ-
ковещательной рассылки (subnet broadcast). Это позволяет сетевому администратору
контролировать поток широковещательных рассылок в объединенной сети и при этом
обеспечивать хосты удаленной конфигурационной информацией об IP-адресах.
Заголовок ВООТР

Заголовки протоколов ВООТР и DHCP имеют идентичный формат. На рис. 4.12 пред-
ставлен формат заголовка ВООТР; на рис. 4.13 показан заголовок ВООТР в том виде, в
каком он показан в окне сетевого анализатора протоколов Sniffer. Следует обратить вни-
мание на то, что Sniffer иначе интерпретирует некоторые поля заголовка ВООТР. На
поте кода сообщения (Opcode field) анализатор протоколов ссылается как на "Поле тина
загрузочной записи — Boot record type", полю счетчика секунд (Seconds) соответствует
"Поле счетчика времени, использованного на ожидание загрузки — Elapsed bool time";
неиспользуемое поле (Unused field) рассматривается как "Поле флагов — Flags"; поле
IP-адреса клиента (Client IP address) — как "Поле IP-адреса, присвоенного себе клиен-
том — Client self-assigned IP address); полю адреса, присваиваемого клиенту сервером
(Your IP address) соответствует "Поле IP-адреса клиента — client IP address". Кроме того,
в окне анализатора протоколов Sniffer отображается неиспользуемое поле — "Поле фла-
гов", которое всегда заполнено нолями (0000). Значение, установленное в данном поле,
равносильно утверждению "Нет широковещательных рассылок — no broadcast", что не
соответствует истине. Это следует просто проигнорировать.

Код сообщения Тио локальной сета Длина аппаратного адреса Счетчих транзитов

Идентификатор транзакции

Счетчик секунд от момента отправки клиентом первого запроса Неиспользуемое поле

IP-адрас клиента

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

РИС. 4.12

Длина заголовки ВООТР —
300 байтов. Заголовки
протоколов ВООТР и
DHC P имеют один и тот
же формат.

IP-алрес сервера

IP-адрес шлюза

Аппаратный адрес кшлнта (16 октетов)

Имя хоста сервера (64 октета)

Имя хоста сервера (64 one га)

Область для производителен (64 октета)

Поле кода сообщения

Поле кода сообщения (Op, Operation Code), имеющее длину I байт, специфицирует
тип сообщения, пересылаемого в дейтаграмме ВООТР. Существует два значения кодов,
соответствующие различным типам сообщений ВООТР:

•	Значение I соответствует запросу ВООТР (ВООТР Request), отправляемому кли-
ентом.

•	Значение 2 соответствует ответу ВООТР (ВООТР Reply), отправляемому серве-
ром.
25	С-ч^йл» •SjJjij

«Ж* ..| JMWgJ ±d

ti.:

- Lft DDL
fj UDP.
JJbdp
Q UDP
Xjudp
Q DDB

Source port	= Б В (Btrotpc/DHCP)

Destination port -67 (Bootps^LHCF)

Length	- 308

Ho diGckeui»

[300 byte(s) at date]

ВООТР

3 ВООТР

=и#

Поле кода сообщения Поле счетчика секунд

 "	~	...J^nrilMy

”255’Z5&'25S ВООТР' J г^иг:

----- ВООТР Beader -----

1,4 воотр
рВООТР
Пвоотр-

1 П воотр

ВООТР
$ В°ОТР:
73 ВООТР
□ ВООТР

ВООТР
П ВООТР
Ji ВООТР

Л когр
- 3 ВООТР
£3 BOOTF
а) воотр
3 ЕООТР
VJВООТР 

Boot record type

Message type

Hardware address type

Hardware address Length

Eops

Transaction id

Elapsed boot time

Flags

0

Client self-assigned IP

Gateway IP address

Client hardware address

= 1 (Request) —

" 0 Unknown

	1 (10Mb Ethernet)

	6 bytes

-	A3AOOODF

= 16 seconds

- 0000---------------

	Но broadcast

address ” (О U 0.0]

- [D 0.0 0]
* NiThOOODF

< Decode	Hui fctjj ДЛ<.,«хчЙ1^, ,/>, !^>ы*Ьц» 3 -

эь^-, е g е1й1,у.-.- дм* £_ .-

Bost

Beat

•t Р.о - Ька£Ф& I df <

. 2'

j	rS^T>t

Поле IP-адреса шлюза

Поле IP-адреса, клиента

Неиспользуемое
поле









РИСУНОК 4.13 Протоколы ВООТР и DHCP используют заголовки идентичного формата.

Поле типа (локальной) сети

Поле типа локальной сети (Htype, Hardware Туре), имеющее длину 1 байт, иденти-
фицирует одну из базовых локальных сетей, таких как Ethernet, Token-Ring или какой-
либо другой гин сеги. Например, локальной сети Ethernet соответствует значение 1, ус-
тановленное в поле гипа локальной сети (Htype), соответственно в гаком случае протокол
ВООТР рассчитывает на получение аппаратного адреса длиной 6 байтов (48 бит).

Поле длины аппаратного адреса

Поле длины аппаратного адреса (Hlen. Hardware Length), имеющее длину 1 байт, за-
дает размер аппаратного адреса (в байтах), который Протокол ВООТР ожидает получить
в результате выполнения процедуры разрешения адресов Значение этого поля меняет-
ся в зависимости от типа локальной сети.

Поле счетчика транзитов

Необязательное поле счетчика транзитов (Hops), имеющее длину 1 байт, иллюстри-
рует процесс поиска клиентом удаленных конфигурационных сведений через маршру-
тизатор или маршрутизаторы. В этом поле указывается значение соответствующее ко-
личеству транзитных участков каналов передачи данных, через которые прошла данная
дейтаграмма. Начальное значение, устанавливаемое клиентом в поле счетчика транзи-
тов (Hops), равно 0. Шлюзы увеличивают это значение на единицу каждый раз, когда
они передают запрос ВООТР на следующий участок объединенной сети.

Поле идентификатора транзакции

Поле идентификатора транзакции (Transaction ID), имеющее длину 4 байта, реали-
зуется в заголовке ВООТР несмотря на то, что ВООТР — это не ориентированный на
соединение протокол. Данное поле позволяет клиенту установить соответствие между
своим запросом и ответом сервера (в этом поле устанавливается одинаковое значение
для запросов и ответов). Другими словами, данное поле позволяет определить, являют-
ся ли запрос и ответ ВООТР участниками одного и того же сеанса связи. Значение идеи
тификагора транзакции (transaction ID value) клиент выбирает произвольно.

Поле счетчика секунд

Каждый клиент ВООТР устанавливает значение счетчика секунд (Seconds) сразу же
после начальной загрузки системы. В этом таймере указывается время отправки клиен-
том первого запроса и отсчитывается период времени, прошедшего с момента загрузки
клиента в ожидании получения им конфигурационной информации от сервера ВООТР.
Если клиент ВООТР не получает ответа за определенный период времени, он предпри-
нимает попытку повторной передачи запроса в надежде на то, что он все-таки получит
ответ от сервера ВООТР. В выполняемом каждым клиентом ВООТР процессе реализу-
ется какой-либо механизм измерения времени, позволяющий контролировать период
ожидания клиентом ответа на свой запрос, а также тайм-аут, по истечении которого
клиент может передать свой запрос повторно. Значение, устанавливаемое в поле счет-
чика секунд (Seconds), меняется в зависимости от конкретной реализации. Когда зна-
чение таймера истекает, завершается и максимальный период времени, в течение кото-
рого может произойти инициализация данною устройства, следовательно, на данном
этапе эго устройство нс может быть инициализировано в качестве участника процесса
коммуникации в пределах данной сети.

Неиспользуемое поле

Неиспользуемое поле (Unused) имеет длину 2 байта; оно не используется в работе
протокола ВООТР.

Поле IP-адреса клиента

После начальной загрузки клиента поле IP-адреса клиента (Client IP Address) запол-
няется нолями. Если клиент не имеет жестко!о диска, в этом поле всегда будет установ-
лено именно такое значение, поскольку у клиента нет места для хранения использован-
ных ранее конфшурационных параметров. Если клиент обеспечен жестким диском и
сохранил назначенную ему ранее адресную информацию, в поле IP-адреса клиента
(Client IP Address) указывается исходный, присвоенный сервером ВООТР и сохранен-
ный IP-адрес, который клиент хотел бы использовать повторно.

Поле IP-адреса, предоставляемого клиенту сервером ВООТР

При заполнении данного поля (Your IP Address) во время отправки клиентом запро-
са ВООТР может сложиться одна из следующих ситуаций:
•	Если предыдущее поле (IP-адрес клиента, client IP address) было заполнено но-
лями, данное поле вообще не будет активизировано. Этот факт указывает па то,
что клиент никогда не получал IP-адреса от сервера ВООТР.

•	Если клиент знает свой I P-адрес и хотел бы продолжить его использование, в этом
поле (Your IP Address) будет указан тот же IP-адрес (первоначальный адрес, при-
своенный клиенту сервером ВООТР).

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

Поле IP-адреса сервера

Если клиент не знает IP-адреса сервера, данное иоле (Server IP Address) заполняегся
нолями и не отображается в окне анализатора протоколов Sniffer. Заполненное налами
поле отображается в окне анализатора протоколов тогда, когда клиент инициализиру-
ется в сети впервые, либо когда это — бездисковый клиент, не имеющий места для хра-
нения конфигурационных параметров. В случае если клиент сохранил информацию, по-
лученную во время предыдущей загрузки, в данном поле (Server IP Address) указывается
IP-адрес сервера ВООТР, которому адресовано передаваемое сообщение. В ответе
ВООТР в пояс IP-адреса сервера указывается адрес сервера ВООТР, ответившего на этот
запрос.

Поле IP-адреса шлюза

Когда новый хост отправляет свой первоначальный запрос, поле IP-адреса шлюза
(Gateway IP Address) должно быть заполнено нолями. Если клиенту ВООТР известно,
что он должен передать свой запрос через локальный шлюз (local gateway), и он знает
адрес этого шлюза или промежуточного агента (relay agent), этот адрес следует указать в
поле JP-адреса шлюза (Gateway IP Address). Если клиенту такие сведения неизвестны
(подобная ситуация може! возникнуть при первой загрузке), он отправляет свой запрос
в широковещательной рассылке. При этом шлюз или промежуточный агент, передаю-
щий такую дейтаграмму, включает в нее свой IP-адрес. Если клиент ВООТР ранее по-
лучил данные конфигурационные параметры от удаленного сервера ВООТР и сохранил
полученную информацию, в поле IP-адреса шлюза (Gateway IP Address) указывается уже
известный IP-адрес шлюза или промежуточного агента.

Поле аппаратного адреса клиента

Данное поле (Client Hardware Address) идентифицирует аппаратный адрес клиента
ВООТР. Например, если клиент ВООТР имеет аппаратный адрес, соответствующий ад-
ресу сетевого адаптера Ethernet, в поле аппаратного адреса клиента (Client Hardware
Address) должен быть указан уникальный 48-разрядный адрес, встроенный производи-
телем в сетевую интерфейсную плату (Network Interface Card, NIC). Длина данного поля
может достигать 16 байтов.

Поле имени хоста сервера

Необязательное поле имени хоста сервера (Server Host Name) идентифицирует сер-
вер ВООТР по его имени. Расположение в данном ноле имени хоста указывает на то,
что сервер ВООТР с таким именем должен ответить на запрос клиента ВООТР. Если
поле имени хоста сервера (Server Host Name) остается незаполненным, любой сервер
может ответить на запрос ВООТР. Длина данного поля может достигать 64 байтов.

Поле имени конфигурационного файла

Необязательное поле имени конфигурационного файла (Boot File Name) идентифи-
цирует имя файла, который может быть затребован клиентом ВООТР для получения кон-
фигурационной информации о необходимых хосту установочных параметрах. В ответе
ВООТР сервер указывает полный путь к конфигурационному файлу (boot file). Если
клиент оставляет данное папе незаполненным, сервер предпринимает попытку загруз-
ки по каналу связи конфигурационного файла по умолчанию (default boot file). Если
загрузка конфигурационного файла по умолчанию не предусмотрена, а поле имени файла
остается незаполненным, сервер ВООТР указывает в своем ответе на запрос клиента
только базовые конфигурационные параметры, такие как IP-адрес самого клиента и IP-
адрес шлюза; при этом загрузка конфигурационного файла не выполняется. Длина поля
имени конфигурационного файла (Boot File Name) может достигать 128 байтов.

Поле "Область для разработчиков"

В поле "Область для разработчиков" (Vendor Specific Area) содержится перечень осо-
бых параметров, запрашиваемых клиентом или присваиваемых ему. Состав таких пара-
метров специфичен для каждой конкретной реализации.

Запрос и ответ ВООТР

Рассмотрим пример обмена сообщениями между клиентом и сервером ВООТР. На
рис. 4.14 показан запрос ВООТР-клиента (ВООТР request), отправленный в широкове-
щательной рассылке всем серверам ВООТР, находящимся на данном локальном участ-
ке сетевого комплекса. Следует обратить внимание на io, что порт UDP сервера ВООТР
имеет номер 67, а номер порта UDP клиента ВООТР — 68. Как видно на итоговой па-
нели анализатора пакетов Sniffer, клиент не знает своего IP-адреса (указанный в окне
адрес — 0.0.0.0) и отправляет свой широковещательный запрос по адресу широковеща-
тельной рассылки (255.255.255.255) всем хостам. В окне легализации указан единствен-
ный известный хосту адрес — его аппаратный адрес (NATA000DF).

Протокол DHCP (протокол динамического
конфигурирования хостов)

Как следует из самого названия протокола, DHCP (Dynamic Host Configuration
Protocol) — это протокол, который автоматически предоставляет таким устройствам, как
хосты или шлюзы, набор конфигурационных параметров 1Р. В число таких параметров
входит логический IP-адрес, адрес шлюза, адреса DNS и многие другие. Протокол DHCP,
специфицированный в RFC 2131, заменил своих предшественников — протоколы RARP
и ВООТР, и является в настоящее время официальным стандартом в информационной
индустрии.

В предыдущем разделе данной главы, посвященном протоколу RARP. было отмече-
но, что именно RARP был первым в стеке протоколов TCP/IP протоколом, предостав-
ляющим тс же услуги, что и протокол DHCP. Однако в DHCP исключены три суще-
ственных недостатка, свойственные протоколу RARP:
, |	.......... ,| ,1 ||

Й Fife Мапйчй:	f^tspky Teals	j^-Jp	_|g[ X|

сз|ы| * *М-Шйа!£'||<|»1^!41£й M e>l ©|.

Ng. jSltfu: |Soi^ccAt»JjesK = HteftAdstfe, jUw jSjuP>SfiWu	., *	*•

Г1 Ok [0 0 0 0)	25SPOOTP'	/	4

.__________________	___________I __	,	____________________V

~ UDP. Source pert * 60 (Eootpcz-DHCp)

j' i UDP: Destination port * 6? (Boatps DHCP)

Q UDP- length	- ЗОЯ

£1 UDP; Ho checksum

Q UDP: [300 byte(s) of data]
D ПОР’

---- ВООТР Header ----

Boot record type	 1 (R&qrj&st )

Mi-'ssage type	= 0 Unknovn

Hardware address type • 1 (10Mb Ethernet)

Hardware address length “ 6 bytes

Hops	• 0	|

Transaction id	- A3AO0DDF

Elapsed boot time	-16 seconds

Flaggs	= [1000

€	. ..." No broadcast

Clisnt self—assigned IP address =[0000]
Gateway IP address	» [0.0.0 0]

Client hardware address	= HATAOODDF

Host natit - ""	I

EuCiX file naie = ‘ "	—1

C [teccfle ЛмдМх A Hnfct Jribte Д Protocol DksL Astetfsfics / -

PwHit^pi&SSH	££ Jj.

IО SS Sa S3 ф |Д№й? J ffi?^>ootrtiv?ad-cho|xj SSrtft«PIc-L«aH1».J .. ПИ SWPH

РИСУНОК 4.14 Как запрос, так и ответ ВООТР используют заголовок идентичного формата.

Отличить запрос от ответа можно по значению, указанному в поле кода сообщения (Opcode):
значение I соответствует запросу ВООТР (ВООТР request), значение 2 соответствует ответу
ВООТР (ВООТР reply). Кроме того, в ответе ВООТР сервер отправляет клиенту присвоенный ему
IP адрес.

£) всотр
У B00TF
£Jboot? 
Г) BuOTt
11 всотр
JjFOOTF
iL) воете'
E5 воотр
□ ВООТР
1 1 ВООТР
U воотр
,1-1 ВООТР
Q ВООТР
13 воотр-
„) ВООТР.
. воотр-
□ ВООТР
еЭ воотр-

• RARP использует в своей работе статическую таблицу адресов. Из этого следует,
что сетевой администратор должен вручную создавать и обслуживать таблицы ото-
бражения адресов, что существенно увеличивает объем администрирования.

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

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

В протоколе ВООТР, заменившем RARP, также реализуется механизм трансляции
адресов МАС (аппаратных адресов) в логические адреса сетевого уровня с помощью ста-
тической таблицы отображения адресов. В то же время маршрутизаторы могут переда-
вать запросы ВООТР. и, в отличие or RARP. посредством маршрутизаторов можно пе-
ресылать ответы ВООТР на удаленные ВООТР-серверы. Следовательно, не требуется
наличия серверов ВООТР на каждом учащие объединенной сеги.

Протокол DHCP, будучи фактически расширением ВООТР, использует в своей ра-
боте те же, что и ВООТР, порты UDP (порт 67 соответствует серверу DHCP, порт 68 —
клиенту DHCP). Кроме того, для пересылки своих запросов и ответов протокол DHCP
применяет заголовок, имеющий формат, идентичный с заголовком ВООТР. Единствен-
ным отличием является наличие в заголовке DHCP поля "Дополнительные параметры"
(Options), имеющего переменную длину и заменившего поле "Область для разработчи-
ков" (Vendor Specific Area) заголовка ВООТР.

Как и в случае ВООТР, маршрутизаторы могут передавать сообщения DHCP. Меж-
ду протоколами DHCP и ВООТР существует одно существенное отличие: DHCP не ог-
раничивает свои возможности применением таблицы отображения адресов. Это значит,
что функционирование протокола DHCP имеет динамический характер, позволяющий
автоматически конфигурировать хосты в сети. В то же время протокол DHCP позволя-
ет выполнять также и статическую трансляцию аппаратных адресов в логические IP-
адреса. Как правило, так происходит в случае, когда хосту или шлюзу нужен собствен
ный постоянный 1Р-адрес.

С другой стороны, в огличие от протокола RARP или ВООТР, протокол DHCP мо-
жет поддерживать пул (г. е. диапазон или класс) IP-адресов (pool of IP addresses), дос-
тупных для динамического присваивания хостам или шлюзам. Это дает хостам возмож-
ность передвигаться по сети и получать необходимые для инициализации на данном
участке сети IP-адреса и другие конфигурационные параметры. Любой хостили шлюз
может при необходимости функционировать в качестве сервера DHCP, поддерживаю-
щего пул IP-адресов и других конфигурационных параметров. Сетевой администратор
в таком случае должен определить правильный диапазон I P-адресов, а также указать срок
аренды каждого адреса тем или иным хостом или шлюзом. В обязанности администра-
тора входит также создание набора дополнительных конфигурационных параметров, пре-
доставляемых конечным устройствам по их требованию. В число таких параметров вхо-
дят следующие параметры:

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

•	IP-адрса для серверов DNS.

•	IP-адреса для серверов WINS.

Предоставление хостам конфигурационной
информации

Работа протокола DHCP построена на модели взаимодействия клиент сервер. Кли-
енты DHCP отправляют свои запросы, а серверы DHCP передают в ответ необходимые
конфигурационные параметры. Протокол DHCP поддерживает три способа назначения
IP-адресов и распределения конфигурационной информации:

•	Автоматическое назначение (Automatic allocation). Механизм назначения адресов,
присваивающий хосту клиента постоянный IP-адрес для работы в сети.

•	Динамическое назначение (Dynamic allocation). Механизм, позволяющий серве-
ру DHCP предоставить клиенту конфигурационные параметры для использова-
ния на протяжении ограниченного периода времени. Этот период времени, как
правило, определяется сроком аренды (lease value). Динамическое назначение —
наиболее распространенный способ назначения адресов и других конфи!ураци-
онных параметров. Механизм динамического назначения адресов обеспечивает-
ся возвратом не используемых хостами адресов и их переназначением (по мере
возникновения необходимости) новым хостам. Такой способ позволяет более эф-
фективно использовать пул адресов.

•	Ручное назначение (Manual allocation). Механизм назначения адресов, который
(как видно по самому названию) состоит в том, что сетевой администратор вруч-
ную назначает IP-адрес тому или иному устройству.

Для обеспечения успешной работы сети можно выбрать либо комбинацию автома-
тического, динамического и ручного способов назначения адресов, либо один из этих
способов. Целесообразность выбора того или иного механизма назначения адресов за-
висит от конкретной реализации В некоторых сетях реализуется один их способов, в
других — комбинация разных способов назначения адресов и предоставления других кон-
фигурационных параметров.

Сообщения DHCP

Клиенты и серверы DHCP обмениваются сообщениями следующих типов:

Discover	—	сообщение о поиске

Offer	—	сообщение-предложение

Request	—	сообщение-запрос

АСК	—	сообщение-подтверждение

NAK	—	сообщение-отказ

Decline	—	сообщение-отмена

Release —	сообщение об освобождении адреса

Inform	—	информационное сообщение

В таблице 4.1 приведено описание различных типов сообщений клиентов и серверов
DHCP.

Таблица 4.1 Типы сообщений клиентов и серверов DHCP____________________________

Тип сообщения	Описание
Discover	После завершения начальной загрузки клиенты DHCP отсылают широковещательное сообщение о поиске серверов DHCP (DHCP Discover)
Offer	В ответ на сообщение клиента о поиске (DHCP Discover) серверы DHCP отправляют сообщение о предложении клиенту DHCP IP-адреса (DHCP Offer). В это сообщение включается также набор конфигурационных параметров, предлагаемый сервером DHCP, который передает данное сообщение
Request	Клиент отправляет свой запрос (DHCP Request) в следующих случаях: • Для подтверждения приема клиентом полученного от сервера DHCP предложения (DHCP Offer). Если клиент получает несколько предложений от различных серверов DHCP, факт приема клиентом одного из предложений автоматически влечет за собой отклонение предложений других серверов  •	Для возобновления использования конфигурационных параметров, которые были назначены ранее и продолжают применяться данным устройством в настоящем.  •	Для продления аренды назначенного ранее IP-адреса.
АСК	Сервер отвечает на запрос клиента (DHCP Request) подтверждением (DHCP (Acknowledgment) АСК, Acknowledgment). В сообщение DHCP АСК включается также предоставляемый клиенту IP-адрес и другие конфигурационные параметры.
Тип сообщения	Описание
NAK (Negative acknowledgement)	Сервер DHCP отправляет сообщение DHCP NAK об отказе в подтверждении запроса клиента (DHCP Request), если затребованные ранее клиентом DHCP конфигурационные параметры некорректны или неприемлемы.
Decline	Клиент DHCP отправляет сообщение об отмене (DHCP Decline) принятых от сервера DHCP конфигурационных параметров, уведомляя сервер о том, что другой хост или шлюз уже используется для назначения клиенту IP- адреса.
Release	Клиент DHCP отправляет серверу DHCP сообщение об освобождении IP- адреса (DHCP Release), с уведомлением о том, что этому клиенту больше не нужен предоставленный ему ранее IP-адрес и конфигурационные параметры. Это позволяет серверу DHCP переназначать освобожденную конфигурационную информацию другому хосту или шлюзу, запрашивающему предоставление ему конфигурационных параметров.
Inform	Клиент DHCP отправляет информационное сообщение (DHCP Inform) в том случае, если IP-адрес присвоен ему вручную, но ему нужен набор дополнительных конфигурационных параметров, которые хранятся на сервере DHCP.

Обмен сообщениями между клиентами и серверами
DHCP

Процесс конфигурирования в сети нового клиента выполняется, как правило, по-
средством следующего четырехэтапного обмена сообщениями между клиентами и сер-
верами DHCP:

•	Клиент DHCP рассылает широковещательное сообщение о поиске серверов
(DHCP Discover), чтобы обнаружить серверы DHCP. Все серверы DHCP, полу-
чившие это широковещательное сообщение и имеющие возможность ответить на
него, отсылают в ответ свое сообщение (DHCP Offer) с предложением о предос-
тавлении клиенту IP-адреса и других конфигурационных параметров.

•	Клиент DHCP выбирает один из серверов и отсылает серверу DHCP свое сооб-
щение (DHCP Request), содержащее запрос на предоставление ему конфигура-
ционной информации. Клиент может включить в свой запрос (DHCP Request)
список требуемых параметров, которые он хотел бы получить в свое распоряже-
ние. Запрос DHCP (DHCP Request) отправляется по IP-адресу одного из серве-
ров DHCP, предлагающих клиенту свои услуги. Принятие клиентом предложе-
ния конкретного сервера DHCP влечет за собой автоматическое отклонение
предложений других серверов. В своем сообщении (DHCP Request) клиент DHCP
может запросить предоставление ему каких-либо особых конфигурационных па-
раметров, которые он хотел бы иметь в своем распоряжении.

•	Выбранный сервер DHCP отвечает подтверждением (DHCP АСК, Acknow-
ledgement) запроса клиента DHCP на предоставление ему конфигурационной ин-
формации. В эго сообщение (DHCP АСК) включается запрашиваемая клиентом
конфигурационная информация. Сервер DHCP должен предоставить клиенту
DHCP все требуемые параметры или их неполный набор, включив эти парамет-
ры в свое сообщение (DHCP АСК). IP-адрес, назначенный клиенту DHCP, дол-
жен быть корректным для той подсети, в которой находится хост клиента. Если
сервер DHCP либо нс в состоянии исполнить запрос клиента на предоставле-
ние ему отдельных параметров, либо когда запрашиваемые клиентом парамет-
ры некорректны, сервер отвечает отказом DHCP (DHCP NAK, Negative
acknowledgement) в подтверждении запроса клиента DHCP.

• Как только клиент DHCP получает необходимую ему конфигурационную инфор-
мацию, он 'должен выполнить еще одно важное заключительное действие. Эго дей-
ствие состоит в том, что клиент DHCP, только что получивший новый IP-адрес,
проверяет, не используется ли этот адрес в данный момент каким-либо другим
хостом сети. Подобная проверка выполняется посредством формирования кли-
ентом DHCP запроса ARP с данным IP адресом в качестве адреса получателя. При
этом клиент рассчитывает, что его ARP-запрос останется без ответа, из чего можно
будет сделать вывод, что ни один из хостов сети не распознает данный IP-адрес и
не предъявляет на него своих прав. Если один из хостов распознает объявленный
IP-адрес, из этого следует, что данный адрес уже используется и его нельзя на-
значать хосту клиента DHCP. В гаком случае клиент отправляет серверу DHCP
сообщение об отмене назначенного ему IP-адреса (DHCP Decline) и заново на-
чинает процесс конфигурирования в сети. Когда ARP-запрос остается без ответа
(а это значит, что данный ]Р-адрес не используется каким-либо другим хостом),
клиент DHCP сохраняет этот IP-адрес для себя. На этом этапе процесс инициа-
лизации нового клиента можно считать завершенным. Теперь клиент имеет дос-
таточно конфигурационной информации .для того, чтобы начать работу в данной
сети.

На рис. 4.15, 4.16, 4.17, 4.18 и 14.9 проиллюстрирован четырехэтапный обмен сооб-
щениями между клиентом и сервером DHCP. На рис. 4.15 можно видеть кадр 1, содер-
жащий широковещательное (255.255.255.255) сообщение (DHCP Discover) клиента с IP-
адресом 0.0.0.0 о поиске сервера DHCP, имеющего возможность назначить IP-адрес этому
клиенту. Кадр 2 содержит широковещательный ответ-предложен не (DHCP Offer) сер-
вера DHCP, имеющего IP-адрес 161.69.97.200. В кадре 3 клиент DHCP принимает пре-
дыдущее предложение и передает свой широковещательный запрос (DHCP Request) на
предоставление ему IP-адреса и других конфигурационных параметров. Кадр 4 (после-
дний) содержит отправленное в широковещательной рассылке подтверждение (DHC.P
АСК) сервером DHCP запроса клиента, а также назначаемые клиенту конфигурацион-
ные параметры.

Как видно по рисунку, все кадры разосланы в широковещательной, а нс в одноад-
ресной рассылке. Так происходит по той причине, что у данного клиента еще нет сво-
его IP-адреса, и, следовательно, он не может принять дейта! рамму другого типа. Как
только клиент получит необходимые ему конфигурационные параметры, все сообще-
ния в дальнейшем будут передаваться в одноадресной рассылке.

На рис. 4 16 показано сообщение клиента о поиске сервера DHCP (DHCP Discover).
Как видно по рисунку, клиент DHCP имеет 48-разрядный Ethernet-адрес. Ни один из
шлюзов или промежуточных агентов нс пересылал данную дейтаграмму, следователь-
но, число транзитов равно 0. Клиент использует идентификатор транзакций (87C6AI31)
для того, чтобы идентифицировать запрос клиента DHCP и ответ сервера на этот зап-
рос в качестве действий одного и того же сеанса связи. Клиент выполнил начальную
загрузку 768 секунд назад. В ноле флагов (Flags) отмечено, что данный запрос отправ-

лен в широковещательной рассылке. Следует обратить внимание на то, что все логи-
ческие адреса (IP-адреса клиента, сервера, шлюза или промежуточного агента) запол-
нены нолями, поскольку клиенту еще неизвестны эти адресные данные. В то же время
клиент знает свой аппаратный адрес и сообщает его (NwkGnl093F5E), предпринимая
попытку транслировать этот адрес в логический адрес сетевого уровня.

Кадр I Кадр 2 Кадр 3 Кадр 4

РИСУНОК 4.15 Данный пример иллюстрирует четырехэтапный обмен сообщениями между клиентом
и сервером DHCP, который осуществляется при включении в работу сети нового клиента.

В данном примере клиент DHCP не указал имени сервера и имени конфит у рацион-
ною файла. В то же время клиент указал дополнительные параметры, которые он хотел
бы получить в свое распоряжение, в поле дополнительных параметров, которое интер-
претируется анализатором протоколов Sniffer как поле ’"Vendor information tag". Далее
клиент DHCP перечисляет значения запрашиваемых дополнительных параметров. Пе-
речень этих значений представляет собой список требуемых конфигурационных пара-
метров, которые клиент хотел бы получить от сервера DHCP. Чтобы узнать, какие па-
раметры соответствуют указанным значениям, следует обратиться к документу RFC,
представляющему описание параметров протокола DHCP.

На рис. 4.17 следует обратить внимание на то, что значение идентификатора тран-
закции (Transaction ID) совпадаете соответствующим значением на рис. 4.16. 1Р-адрес,
предложенный сервером DHCP клиенту — 161.69.97.201. В поле дополнительных пара-
метров, ниже поля, имеющего в окне анализатора протоколов Sniffer название "Vendor
information tag”, находится список параметров, предлагаемых данному хосту. Сервер
DHCP предоставил клиенту маску подсети 255.255.255.0. Клиент получил также в свое
распоряжение два таймера: TJ (60 секунд, или половина срока аренды) и Т2 (105 секунд),
используемые для продления аренды клиентом данного IP-адреса. Собственно срок
аренды (lease value) равен 120 секундам. Как видно поданному рисунку, сервер DHCP
указал также, и свой [Р-адрес (IЬ1.69.97.200), который в дальнейшем будет использоваться
клиентом DIICP в запросах на продление аренды.

И fy . Montor. poptre

igfej	J

т хе i-'кср ~ ~ гост ви 5й?~ 

□ DITCP
,1л DHCP.
J DHCP

1 DHCP
J DHCP
1Л DHCP

DHCP-
□ D,!CP
3DH^F:
-Э shop
5 dbc?’
4$ DHCP.
3 DHCP

Boot record type

Message type

Hardware address type

Hardware address length

Reps

Transaction id
Elapsed bcot tine
Flags

Client seif-oseigned
Ci lent IP address

ip

(Roquets I)

DHCP Discover —
(LOKb Ethernet)
by I os

Код сообщения

-Тип сообщения

- 0 -----------

- 07061131-----

 766 second© 

- B00O——
• Broadcast IP

hddrass

-8Й DICP Ketft Server to use in boots trap
DHCP. Relay Agent

^DHCP'

-J DHCP'
DHCP
DHCP

HC?

- [C

-- co

- [0

- [0

Hop count

Transition ID

Seconds

-------Flags

dntagrars

D 0 0]'
0 0 0]-
0 0 OJ-
ll 0 DJ.

Your IP address

= NvkGnl093FSE

Gateway IP address

Client IP itjdresa

Server IP address

Тип аппаратного
peca клиента

(тип локальной
сети)

Client hftrdwate address

Heat name
Scrat fil₽- пали

Г-'ЛЙ	/

Имя сервера

J dhcp
. DHCP
J DHCP

1 DHCP
Л DHCP

(Dei тсс" /мэсйгДrtrt Trtte X₽/
F«SJ

Vendor Infcjnr.fition tag
Kessage Type
’lient identifier
nneter Request List
guest option code
eat option code
option code

63 82S 363 --------------

“ 1 (DH£P Discover)
- 0IOUD06S093FSb

j jy Mkr&^RWj^hap. |<	525FM

Имя wHtpiii урационллге ф=ила

Аппаратный
адрес клиента

.Информация
разработчиков

Параметры



 e

3

г

РИСУНОК 4.16 На данном рисунке показано сообщение /стента DHCP о поиске сервера DHCP
(DHCP Discover). Значение ноля кода сообщения (Opcode) равно /. В окне анализатора протоколов
Sniffer это поле представлено как поле типа загрузочной записи ("Boot record tvpe"). Значение 1 этого
поля указывает на то. что данное сообщение является запросом DHCP, а тип этого запроса  -
"DHCP Discover", сообщение о поиске сервера DHCP,

На рис. 4.18 в пол₽ кода сообщения (Opcode) указано значение 1; значение типа со-
общения (Message type) равно 3. Совокупность этих двух значений идентифицирует
данное сообщение как запрос DHCP (DHCP Request) Клиент DHCP принял получен-
ное ранее сообщение с предложением сервера DHCP (DHCP ОГГсг) и принимает пред
ложенные ему конфшурационные параметры. Следует обратить внимание, что значе-
ние идентификатора транзакций (Transaction ID) совпадает со значениями, указанными
в соответствующих полях дейшграмм с сообщением клиента DHCP о поиске (DHCP
D'scover) и предложением сервера DHCP (DHCP ОПег) Это значит, что данное сооб-
щение является частью одного и того же чегырехэтапного процесса обмена сообщения-
ми между клиентом и сервером DHCP

На рис. 4.19 в поле кода сообщения (Opcode) указано значение 2; значение типа со-
общения (Message type) равно 5. Совокупность этих двух значений идентифицирует
данное сообщение как подтверждение DHCP (DHCP АСК) сервером DHCP запроса
клиента. Отправляя aiv дейтаграмму, сервер DHCP завершает чегырехэтапный обмен
сообщениями с клиен гом DHCP. В сообщении, пересылаемом в этой дейтаграмме, сер-
вер DHCP подтверждает принятие клиентом DHCP его предложения.
РИСУНОК 4.17 На данном рисунке представлен ответ сервера DHCP. В поле кода сообщения (Opcode)
указана значение 2: значение типа сообщения (Message type) равно 2. Совокупность этих двух
значении идентифицирует данное сообщение как предложение сервера DHCP (DHCP Offer).

РИСУНОК 4.18 Данный рисунок иллюстрирует запрос клиента DHCP (DHCP Request).
S -Эе <»::£Шиге. Ecpiib' 1«)Ц	Нр	~|Sf X;

gljgj &J fefelo! ь>|д|а|1Д-£) Г, 

К	— DHCP Header - --^

SDBCP

DHCP' Boot record type
b'j DECP Message type
A DHCP Hardware address type
?j| DHCP. Hardware address length
; Л DECP.

p DHCP Hops

P DECP Transaction id
г_Д DHCP Elapsed boot tine
□ DHCP Flags

J DHCP 0

J DHCP
J DHCP
A DHCP.
ZjDHCP

DHCP

I) DECP
J DRCP
□ DHCP;

Client self-assigned IP address
Client IP address

Hext Server to use in bootstrap

Relay Agent

Client hardware address

Host нале  ""

Boot file name a

-	2 (R-ply)

« 5 DECP Ack

-	1 (10Kb Ethernet)

-	6 bytes

= 0

-	87СБА131

-	0 seconds

	000D

n No broadcast

-	[0 0 0 0]

= [161.69 97 201]

-	[0 0 0.0]

-	[0 0.0.0]

» NvkGnlO93F5E

i_) DHCP •
A DHCP
A DHCP
A DHCP

3 MCF’

A DHCP
A dhcp
J3 DHCP

Vendor InforRctiDii tag = 63B2S363

Message Type	• 5 (DHCP Ack)

Addre&s Renevel interval - £0 (seconds)

Address Rebinding interval ® 10S (seconds)

Request IP address lease tin* - 120 (seconds)

Server IP address	= [161.69 97 2DO]

Subnet mask • [25S 255.255 0]

\C<eeode~/(Mtilrh	Toibb^iRsissttoS/

Per Help, press F1

:«sk..i|	V 'Д'*

| IffMeiowiMWixd-shap--|	SZ6PM

РИСУНОК 4.19 Данный рисунок иллюстрирует подтверждение DHCP (DHCP АСК).

На данном рисунке представлено подтверждение сервера DHCP (DHCP АСК,
Acknowledgement). Состав предоставляемых сервером DHCP конфигурационных пара-
метров зависит от конкретной реализации. Если клиент бездисковый, сервер DHCP вы-
полняет данную процедуру при каждой загрузке клиента. Если в распоряжении клиен-
та есть жесткий диск, загрузка конфигурационных параметров происходит либо после
начальной за1рузки клиента, либо когда истек срок аренты клиентом данного IP-адре-
са. Клиент, имеющий в своем распоряжении жесткий диск, сохраняет предоставленные
ему после завершения чегырехэтапного обмена сообщениями с сервером DHCP конфи-
гурационные параметры. Если срок аренды клиентом назначенного ему IP-адреса по-
чти истекает, после каждой загрузки происходит следующий двухэгаиный обмен сооб-
щениями между клиентом и сервером DHCP:

1.	Клиент отправляет запрос DHCP (DHCP Request) исходному серверу, предоставив-
шему ему конфигурационную информацию. В этом сообщении клиент DHCP пред-
принимает попытку продлить использование предоставленных ему ранее парамет-
ров.

2.	Сервер DHCP отправляет свой ответ, содержащий подтверждение (DHCP АСК) зап-
роса клиента и разрешение на продление аренды. Если сервер не отвечает вовремя
или если он недоступен, а срок аренды истекает, клиент освобождает предоставлен-
ный ему IP-адрес и другие конфигурационные параметры и немедленно прекраща-
ет свою работу в сети.

На рис. 4.20, 4.21 и 4.22 показан двухэгаиный процесс обмена сообщениями между
клиентом и сервером DHCP по поводу продления срока аренды клиентом иредосзав-
ленного ему IP-адреса. На рис. 4.20 клиент DHCP 161.69.97.201 отравляет серверу DHCP
161.69.97.200 сообщение-запрос (DHCP Request) с просьбой о продлении аренды ранее
назначенного ему IP-адреса и других конфигурационных параметров. Следует обратить
внимание на то, что передаваемые в данном случае сообщения не являются широкове-
щательными. поскольку клиент уже имеет IP-адрес и, следовательно, имеет возможность
передавать и принимать ориентированные дейтаграммы.

1>*те$ frame 1}

Д f-.ee Mixiiit»' Caplute Josfe W’ndw

РИСУНОК 4.20 В ответном кадре сервер DHCP пересылает свое сообщение DHCP АСК
(Подтверждение, Acknowledgement), продлевая тем самым срок аренды клиентом DHCP
предоставленного ему IP адреса и других конфигурационных параметров.

На рис. 4.21 в поле кода сообщения (Opcode) указано значение 3; значение типа со-
общения (Message type) равно 5. Совокупность этих двух значений идентифицирует
данное сообщение как запрос DHCP (DHCP Request). На первом этапе обмена сообще-
ниями клиент DHCP отправляет серверу DHCP свое сообщение-запрос (DHCP Request)
с просьбой о продлении аренды.

На рис. 4.22 в поле кода сообщения (Opcode) указано значение 2; значение типа со-
общения (Message type) равно 5. Совокупность этих двух значений идентифицирует
данное сообщение как подтверждение DHCP (DHCP АСК). На втором (и заключи гель-
ном) этапе обмена сообщениями сервер DHCP отравляет в огвет на запрос клиента
свое сообщение DHCP АСК. подтверждающее продление аренды клиентом DHCP на-
значенного ему 1Р-адреса.

В случае если клиенту больше не нужен присвоенный ему ранее DHCP-сервером IP-
адрес, он отправляет этому серверу сообщение об освобождении данною 1Р-алреса
(DHCP Release). В этом сообщении клиент DHCP ставит сервер в известность о том,
что данный адрес может быть возвращен в соответствующий пул IP-адресов. Такой об-
мен сообщениями между клиентом и сервером DHCP делает IP-адрес доступным для
использования другими клиентами.


2 Efe Honrtfii	ф'^Ч .Ititf- A'md^ [jet'		-xlsj.24
O|- ••'!	d $L. 1		

ЧЕ

----- DHcP Header -----

U DHCP
В DHCP 
jj DHCP'
В DHCP
й DHCP'
В DHCP 

DHCP
QdHCF.
В DHCP:
MDfirp
SDHCF
В DHCF
Q DHCP.
В DHCP
В DKCP’
В DHCP-
В DHCP:
В DHCP.
В DHCP
В мер
В DHCP
BDHCP
В DHCP
В DHCP
В DHCP
В DHCP
ВDKCP.

Boot record type

Message type

Harduere address type

Hardware address length

Heps

Transaction id
Elapsed boot time
Flags

6

Client self-assigned
Client IP address

IF

- 3

6

(Request)

DKCP Request
(10Kb Ethernet)
bytes

- 0

* 7FC7A131

= 76tf seconds

- GOOD

 Ho broadcast

address

Hext Server to use in bootstrap

Relay Agent

Client hardware address

Host name

Boot £il₽ name

Vender Infoxidation tag - 6302S363

Message Type

Client identifier

Request specific IP address

Paxanetcr Request Lis!

Request option code
Request option code

3

b entries

3

' оесоа* / MetrtxTaue ^FfelecolD^ Xstatwcs /
For Help, ptow F1

да-*и]идя j~<*w

[161

[0 0

[0 0

[0 0

69.97 201]

0 0)

0.0)

0 C]

- HwkGxilD93F5E

(DHCP Request)

010D0D65Q4JF5E
[161 69 97 201]

r-r

J ЗУМюояЛ Wr -J cl	I j5fr Snn-‘ у Ft g L^cdMJiaJ ।	£д. 5' 30 PM

РИСУНОК 4.21 На данном рисунке следует обратить внимание на то. что клиент DHCP видает
серверу запрос на продление аренды.

РИСУНОК 4.22 Подтверждение сервером DHCP запроса клиента.
В процессе взаимодействия клиента и сервера DHCP может возникнуть также сле-
дующая ситуация. Возможно, сетевой администратор уже назначил IP-адрес клиенту.
Однако для успешного функционирования в данной подсети у клиента может возник-
нуть необходимость в предоставлении ему сервером DHCP особых параметров. В та-
ком случае клиент DHCP отправляет находящимся на данном локальном участке сети
серверам DHCP информационное сообщение (DHCP Inform), содержащее запрос на пре-
доставление ему дополнительных конфигурационных параметров. Серверы DHCP, име-
ющие в своем распоряжении корректную для данного хоста конфигурационную инфор-
мацию, отвечают клиенту подтверждением (сообщением DHCP АСК). Требуемые
параметры включаются в это сообщение Когда клиент получает ответ, он принимает
предоставленные ему конфигурационные параметры. На этом процесс инициализации
клиента в сети можно считать завершенным.

Продолжительность аренды

Сетевой администратор может указать в наборе конфигурационных параметров сер-
вера DHCP срок аренды (lease duration), измеряемый в секундах. Продолжительность
аренды клиентом IP-адреса и других конфигурационных параметров зависит от конк-
ретной реализации. При статическом отображении адресов в таблицах, хранящихся в опе-
ративной памяти сервера DHCP, величина срока аренды не ограничена, поскольку пре-
образование аппаратных адресов в IP-адреса жестко закодировано и соответствие между
этими адресами не изменяется до тех пор, пока не будут вручную внесены какие либо
изменения. Подобная процедура позволяет зарезервировать для клиента постоянный ин-
дивидуальный адрес.

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

Процесс истечения срока аренды и его продления контролируется с помощью двух
таймеров, сконфитурированных на серверах DHCP, а именно — Т1 и Т2. Значение тай-
мера TI обычно равняется половине всего срока аренды; это значение предписывает,
когда клиенту следует предпринять попытку установления связи с DHCP-сервером для
продления аренды. Если значение Т1 устанавливается по умолчанию, то это значит, что
клиент начинает свои попытки по истечению половины срока аренды. В этом случае
клиент отправляет свой запрос па продление аренды. При этом клиент рассчитывает на
то, что сервер DHCP ответит и повторно назначит ему данный IP-адрес. Если же зап-
рос клиента на продление аренды остается без ответа, а срок аренды достигает значе-
ния таймера Т2 (срок аренды исчерпан на 87.5%), то далее предпринимаются следую-
щие действия. Чтобы сохранить свое функционирование в данной сети, клиент начинает
отправлять широковещательные запросы DHCP на продление аренды, рассчитывая на
то. что хотя бы какой-либо из серверов DHCP продлш его аренду данного 1Р-адреса.
Значение таймера Т2, как правило, составляет 0.875 общею срока аренды. Безусловно,
сетевой администратор может изменить каждое из упомянутых выше значений.

Заголовок DHCP

Заголовок DHCP выглядит и функционирует почти таким же образом, что и заголо-
вок ВООТР. Главное отличие между заголовком DHCP и заголовком ВООТР сосгоиг в
переименовании поля "Область для разработчиков" ("Vendor Specific Area") заголовка
ВООТР в поле "Дополнительные параметры" ("Options") заголовка DHCP, имеющее пе-
ременную длину. На рис. 4.23 представлен формат заголовка DHCP.

Поле кода сообщения — 1 байт

Поле кода сообщения (Op, Operation Code) задает тип передаваемой дейтаграммы
DHCP. Существует два кода сообщений:

•	Opcode 1 = DHCP Request (запрос DHCP, отправляемый клиентами)

•	Opcode 2 = DHCP Reply (огвет DHCP, отправляемый серверами)

Код сообщения Тип (локальной) сети Длина аппаратного адреса Счетчик транзитов

Идентификатор транзакции

Счетчик секунд от момента отправки
клиентом первого запроса

Флаги (неиспользуемое поле)

IP-адрес клиента

РИСУНОК 4.23

Заголовки DHCP и ВОО7 Р
имеют идентичный
формат.

IP-адрес, предоставляемый клиенту сервером (Your IP address)

IP-адрес сервера

IP-адрес шлюза

Аппаратный адрес клиента (16 октетов)

Имя хоста сервера (64 октета)

Имя конфигурационного файла (128 октетов)

Дополнительные параметры (переменная длина)

Поле типа (локальной) сети — 1 байт

Поле типа локальной сети (Htype, Hardware Туре) идентифицирует одну из базовых
локальных сетей, таких как Ethernet. Token-Ring или какой-либо другой тип сети На-
пример, локальной сети Ethernet соответствует значение 1, устанавливаемое в поле типа
локальной сети (Htype), соответственно протокол DHCP рассчитывает на получение ап-
паратного адреса длиной 6 байтов (48 битов).

Попе длины аппаратного адреса — 1 байт

Поле длины аппаратного адреса (Hlen, Hardware Length) задает размер аппаратного
адреса (в байтах), который протокол DHCP ожидает получить в результате выполнения
процедуры разрешения адресов. Значение этого поля меняется в зависимости от значе-
ния, указанного в поле типа локальной сети (Htype).
Поле счетчика транзитов - 1 байт

Необязательное поле счетчика транзитов (Hops) иллюстрирует процесс поиска кли-
ентом удаленных конфигурационных данных через маршрутизатор или маршрутизато-
ры. В этом иоле указывается значение, соответствующее количеству транзитных участ-
ков канала передачи данных, через которые прошла данная дейтаграмма. Исходное
значение, устанавливаемое клиентом в данном поле, равно 0. Шлюзы увеличивают это
значение на единицу каждый раз, когда они передают запрос DHCP на следующий уча-
сток объединенной сети

Поле идентификатора транзакции — 4 байта

Поле идентификатора транзакции (Transaction ID) реализуется в заголовке DHCP,
несмотря на то, что DHCP — эго не ориентированный на соединение протокол. Дан-
ное поле позволяет клиенту DHCP установить соответствие между своим запросом и
ответом сервера (в этом поле устанавливается одинаковое значение для запросов и от-
ветов). Другими словами, данное поле позволяет определить, являются ли запрос и от-
вет DHCP участниками одного и того же сеанса связи. Клиент произвольно выбирает
значение идентификатора транзакции (transaction ID value).

Поле счетчика секунд — 2 байта

Каждый клиент DHCP устанавливает значение счетчика секунд (Seconds) сразу же
после начальной загрузки системы. В этом таймере указывается время отправки клиен-
том первого запроса и отсчитывается период времени, прошедшего с момента загрузки
клиента в ожидании получения им конфигурационной информации от сервера DHCP.
Если клиент DHCP не получает ответа за определенный период времени, он предпри-
нимает попытку повторной передачи запроса в надежде на то, что он все-таки получит
ответ от сервера DHCP. В выполняемом каждым клиентом DHCP процессе реализует-
ся какой-либо механизм измерения времени, позволяющий контролировать период
ожидания клиентом ответа на свой запрос, а также тайм-аут, по истечении которого
клиент может передать свой запрос повторно. Значение, устанавливаемое в поле счет-
чика секунд (Seconds), меняется в зависимости от конкретной реализации. Когда зна-
чение таймера истекает, завершается и максимальный период времени, в течение кото-
рого может произойти инициализация данного устройства, следовательно, на данном
этапе это устройство не может быть инициализировано в качестве участника процесса
коммуникации в пределах данной сети.

Поле флагов — 2 байта

В поле флагов (Flags) должно быть указано значение, определяющее, отправляется
ли данная дейта!рамма в широковещательном или одноадресном кадре.

Поле IP-адреса клиента — 4 байта

После начальной загрузки клиента поле IP-адреса клиента (Client IP Address) запол-
няется нолями Если клиент не имеет жесткого диска, в этом поле всегда будет установ-
лено именно такое значение, поскольку у клиента нет места для хранения использован-
ных ранее конфигурационных параметров. Если клиент обеспечен жестким диском и
сохранил полученные ранее параметры, в поле IP-адреса клиента (Client IP Address) ука-
зывается исходный, присвоенный сервером DHCP IP-адрес, который клиент сохранил
и хотел бы использовать повторно.

Поле IP-адреса, предоставляемого клиенту сервером DHCP, — 4 байта

При -заполнении данного поля (Your IP Address) во время отправки клиентом запро-
са DHCP может сложиться одна из следующих ситуаций:

•	Если предыдущее поле (IP-адрес клиента, client IP address) было заполнено но-
лями, в данном ноле также будут установлены значения 0.

•	Если клиент знает свой IP-адрес и хотел бы продолжить использовать его, в этом
поле (Your IP Address) будет указан тот же IP-адрес (первоначальный адрес, при-
своенный клиенту сервером DHCP).

В ответе DHCP в данном поле указывается IP-адрес, назначенный клиенту серве-
ром DHCP.

IP-адрес сервера — 4 байта

Если клиент не знает IP-адреса сервера, данное поле (Server IP Address) заполняется
нолями и не отображается в окне анализатора протоколов Sniffer. Поле, заполненное
нолями, отображается в окне анализатора протоколов либо тогда, koi да клиент иници-
ализируется в сети впервые, либо когда это — бездисковый клиент, не имеющий места
для хранения конфигурационных параметров. В случае если клиент сохранил инфор-
мацию, полученную во время предыдущей загрузки, в данном поле (Server IP Address)
указывается IP-адрес сервера DHCP, которому адресовано передаваемое сообщение. В
ответе DHCP в поле IP-адреса сервера указывается адрес сервера DHCP, ответившего
на этот запрос.

Поле IP-адреса шлюза — 4 байта

Когда новый хост отправляет свой первоначальный запрос, поле IP-адреса шлюза
(Gateway IP Address) должно быть заполнено нолями. Когда клиенту DHCP необходи-
мо передать свой запрос удаленному DHCP-серверу через локальный шлюз (local gateway)
или посредством промежуточного агента (relay agent), этот шлюз или агент указывает
свой адрес в поле IP-адреса шлюза (Gateway IP Address). Если клиент DHCP ранее по-
лучил от удаленного сервера и сохранил конфигурационную информацию, в поле IP-
адреса шлюза (Gateway IP Address) должен быть указан использованный ранее IP-адрес
шлюза или промежуточного агента.

Аппаратный адрес клиента - до 16 байтов

Поле аппаратного адреса клиента (Client Hardware Address) идентифицирует аппа-
ратный адрес клиента DHCP. Например, если клиент DHCP имеет аппаратный Ethemet-
адрес, в поле аппаратного адреса клиента (Client Hardware Address) должен быть указан
уникальный 48-разрядный адрес, встроенный производителем в сетевую интерфейсную
плату (Network Interface Card, NIC).

Поле имени хоста сервера — до 64 байтов

Необязательное поле имени хоста сервера (Server Host Name) идентифицирует сер-
вер DHCP по его имени. Указание в данном поле имени хоста означает, что сервер DHCP
с таким именем должен ответить на запрос клиента DHCP. Если поле имени хоста сер-
вера (Server Host Name) остается незаполненным, любой сервер может ответить на зап-
рос DHCP.

Поле имени конфигурационного файла — до 128 байтов

Необязательное поле имени конфигурационного файла (Boot File Name) идентифи-
цирует имя конфигурационного файла, который может быть затребован клиентом DHCP
для получения конфигурационной информации о необходимых хосту параметрах. В
ответе DHCP сервер указывает полный путь к конфшурационному файлу (boot file). Если
клиент оставляет данное поле незаполненным, сервер предпринимает попытку загруз-
ки по каналу связи конфи1урационного файла по умолчанию (default boot file). Если заг-
рузка конфигурационного файла по умолчанию не предусмотрена, а поле имени файла
остается незаполненным, сервер DHCP в своем ответе на запрос клиента указывает толь-
ко базовые конфтурационные параметры, такие как IP-адрес самого клиента и IP-ад-
рес шлюза; при этом сам конфигурационный файл в ответе сервера отсутствует.

Поле дополнительных параметров — переменная длина

В поле дополнительных параметров (Options) содержится перечень особых парамет-
ров, запрашиваемых клиентом DHCP и предоставляемых ему сервером DHCP.

Резюме

Для реализации процедуры разрешения адресов используется четыре протокола: ARP,
RARP, ВООТР и DHCP. Протокол ARP выполняет динамическую трансляцию ло1 ичес-
кого сетевого IP адреса удаленного хоста в aniiapaiный адрес этого хоста с целью обес-
печения доставки дейтаграммы. Протокол ARP необходим приложениям и процессам
верхних уровней для динамического разрешения логических адресов сетевого уровня,
которые нужны, в свою очередь, для обеспечения доставки данных адресату.

Протокол RARP выполняет динамическую трансляцию аппаратного адреса хоста в
логический адрес сетевого уровня. Протокол RARP выполняет функцию, противополож-
ную по отношению к функции протокола ARP, хотя оба протокола работают на основе
широковещательных рассылок и используют для доставки своих дейтаграмм заголовки
идентичного формата. Протоколу RARP свойственны два основных недостатка: марш-
рутизаторы не могут передавать запросы и ответы RARP; сетевой администратор дол-
жен создавать и регулярно обновлять статическую таблицу отображения адресов. Как
протокол ARP, так и протокол RARP используют протокол IP Д'гя доставки своих зап-
росов и ответов. Протокол ВООТР, разработанный в качестве преемника протокола
RARP. обеспечивает тот же тип разрешения адресов с использованием UDP (а не 1Р)
для доставки запросов и ответов ВООТР. Маршру гизаторы могут передавать запросы и
ответы ВООТР, что позволяе! оптимальным способом размещать серверы ВООТР в сети.
При этом нег необходимости конфигурировать ВООТР-серверы на каждом участке сети.
Однако при использовании протокола ВООТР сетевой администратор все же должен
вручную обновлять таблицы отображения адресов.

Протокол DHCP, являющийся преемником протокола ВООТР, признан в информа-
ционной индустрии официальным стандартом. В протоколе DHCP полностью исклю-
чены недостатки, свойственные сто предшественникам — протоколам RARP и ВООТР.
Это стало возможным благодаря применению в работе протокола DHCP пула адресов,
известного также под названиями "диапазон, класс адресов". В таком нуле (накопителе)
адресов содержатся адреса, доступные для динамического присваивания хостам или
шлюзам. Для доставки своих сообщений протокол DHCP использует дейтаграммы с
заголовком, практически идентичным заголовку ВООТР, а также порты UDP 67 и 68.

Вопросы для повторения

I Какой тип разрешения адресов выполняет протокол ARP и каким образом он осу-
ществляет эту процедуру?

2.	Какой тип разрешения адресов выполняет протокол RARP и каким образом он осу-
ществляет эту процедуру?

3.	Преемником какого протокола стал протокол ВООТР и каковы различия между эти-
ми протоколами?

4.	Назовите основные различия между DHCP и ВООТР.

5.	Каковы различные механизмы внесения изменений в ARP-таблицы?

6.	Что такое прокси ARP?

7.	Что специфицирует значение, устанавливаемое в ноле кода сообщения (Opcode) за-
головка ARP или RARP?

8.	Какая разница между процедурами ’'shouting” и 'Touting”? Объясните смысл этих про-
цедур.

9.	Перечислите различные типы сообщений DHCP.

10.	Назовите типы сообщений клиента и сервера DHCP, применяющиеся для выпол-
нения чегырехэтапного процесса конфигурирования клиента в сети
Глава 5

IP-маршрутизация

В данной главе рассматриваются следующие темы:

•	Основные принципы маршрутизации.

•	Статическая маршрутизация.

•	Маршрутизация по умолчанию.

•	Динамическая маршрутизация.

•	Дистанционно-векторные протоколы маршрутизации.

•	Протоколы маршрутизации по состоянию каналов связи

Основы 1Р-маршрутизации

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

На начальной стадии процесса маршру1изации каждый локальный хост выясняет при-
надлежность хоста, которому он намерен передать данные, к той же локальной сети, в
состав которой входит он сам. Локальный хост выполняет это посредством сравнения
IP-адреса хоста назначения с локальной маской хоста-отправителя. Если хост назначе-
ния оказывается удаленным (находящимся в другой локальной сети), то хост-отправи-
тель направляет дейтаграмму локальному шлюзу для дальнейшей передачи по сети.

Обеспечение надежной доставки дейтаграммы хоста-отправителя адресату зависит от
функционирования ряда шлюзов, находящихся между данным хостом и удаленным пун-
ктом назначения. Если существует множество путей доставки данных хосту-получате-
лю, наиболее целесообразно передавать дейтаграмму по кратчайшему пути с максималь-
ным быстродействием. Именно на этом этапе активизируются различные процедуры
маршрутизации (routing methods), базируясь на которых, маршрутизаторы формируют
для дейтаграмм маршрут (route) между отправителем и пунктом назначения. Как пра-
вило, для построения таблицы маршрутизации (route table) маршрутизаторы применя-
ют сочетание следующих способов маршрутизации:
•	Непосредственное сопряжение маршрутизатора с сегыо назначения через сетевой
интерфейс (Directly connected interface)

•	Статическая маршрутизация (Static routing).

•	Маршрутизация по умолчанию (Delault routing).

•	Динамическая маршрутизация (Dynamic routing).

Непосредственное сопряжение маршрутизатора с

сетью назначения

Суть механизма непосредственного сопряжения маршрутизатора с сетью назначения
через сетевой интерфейс заключается в наличии маршрутов, являющихся локальными
по отношению к данному маршрутизатору. Другими словами, маршрутизатор имеет ин-
терфейс, непосредственно соединяющий его с сетью назначения, в которую должна быть
отправлена дейтаграмма. Непосредственно соединенные с сетью назначения маршруты
(directly connected routes) — это самый надежный способ маршрутизации, поскольку мар-
шрут передачи той или иной дейтаграммы известен маршрутизатору "из первых рук”.
При этом маршрутизатор не прибыает к другим средствам определения маршрута, та-
ким как статические и динамические протоколы маршрутизации (static or dynamic routing
protocols).

Статическая маршрутизация

Статические маршруты (static routes) — это маршруты, вручную сконфигурирован-
ные сетевым администратором в таблице маршрутизации. Статические маршруты пред-
писывают использование конкретного шлюза или интерфейса для передачи трафика в
тот или иной пункт назначения. Поскольку маршру гы такою типа имеют статический
характер, они не могут приспосаиливатося к происходящим в сети изменениям. Если
оговоренный статическим маршрутом шлюз или интерфейс выходит из строя или ста-
новится недоступным, этот маршрут к нужному пункту назначения разрушается

Существенным преимуществом статической маршрутизации является то, при реали-
зации этого способа маршрутизации не генерируется трафик обновления — информа-
ционный поток, связанный с обновлением маршрутов (routing updates). Применение ста-
тической маршрутизации целесообразно либо там, где соединение является
промежуточным, либо когда актуальной становится проблема пропускной способности
канала связи. Таким образом, реализация статической маршрутизации целесо збразна в
коммутируемых сетях (dial up networks) или на линиях связи типа "точка-точка" в гло-
бальных сетях (point-to-point WAN lintes). Статической маршрутизацией можно допол-
нять другие способы маршрутизации с целью формирования маршрутов через автома-
тически устанавливаемые резервные соединения (dial backup links) в случае разрушения
основных каналов связи (primary links), работающих на основе динамических протоко-
лов маршрутизации. Реализация статической маршрутизации предпошительна также
тогда, когда в сети практически не происходит никаких изменений топологии (topology
changes) либо когда удаленный узел (remote site) имеет только один выход из сети.
$ПРИМЕЧАНИЕ

Следует помнить о том, что в случае статической маршрутизации необходимо вручную
конфигурировать каждый маршрут в таблице маршрутизации. То же самое выполняется
при любых изменений топологии сети.

При разработке архи 1екчуры новой сети следует учитывать, что нецелесообразно стро-
ить работу всей сети только на основе статической маршрутизации, поскольку каждый
маршрут пришлось бы конфигурировать в таблице маршрутизации вручную, что явля-
ется достаточно трудоемкой работой. Кроме того, если происходит сбой в работе одно-
го из каналов связи ичи одного из маршрутизаторов, возникает необходимость ввода
нового маршрута в таблицу маршрутизации В это время (пока выполняется конфигу-
рирование новою маршрута) маршрутизаторы не имеют возможности передавать тра-
фик в нужный пункт назначения, поскольку первоначальный маршрут прекратил свое
существование. Статическая маршрутизация может привести к существенному росту
непроизводительных затрат из за увеличения объема администрирования, связанного с
организацией работы сети и поддержанием ее на должном уровне.

Статические маршруты более эффективно функционируют в средних и небольших
сетях с общим количеством каналов связи, не превышающим 10 — 15 каналов. Однако
даже в таком случае динамические маршруты демонстрируют намного более высокую
гибкость в применении.

ПРИМЕЧАНИЕ

В сетях крупных компаний существует тенденция к использованию на каждом удаленном
узле статических маршрутов для выхода из подсети (иногда компания может иметь до 20
тысяч таких удаленных узлов). Как правило, работа сетей таких компаний построена на
модели "доступа в распределенной среде" (core-distripufion-access model). В этой модели
на уровне смежных участков маршрутизацию обеспечивают протоколы OSPF и BGP, а на
уровне доступа к удаленным узлам работают все существующие статические маршруты.
Основная причина использования именно такого сочетания различных способов маршру-
тизации заключается в том, что удаленные узлы имеют только один выход из подсети и,
следовательно, нет необходимости в использовании динамического протокола маршрути-
зации на уровне доступа к этим узлам. Однако такая сеть компании становится уязвимой
в смысле маршрутизации, если возникает необходимость в изменении ее топологии.

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

•	Преимущество статической маршрутизации заключается в возможности устране-
ния рабочей нагрузки, связанной с обновлением маршрутной информации.

•	Статическая маршрутизация безупречна для реализации на линиях связи тина точ-
ка-точка в глобальных сетях (point-to-point WAN links) или в коммутируемых се-
тях (dial-up networks).

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

•	Нецелесообразно строить работу всей сети исключительно на основе статической
маршрутизации.

•	Недостаток статической маршрутизации заключается в большом объеме непро-
изводительных административных затрат.
•	Для реали 1ации статической маршрутизации больше всею подходят небольшие
сеги.

Маршрутизация по умолчанию

Для успешною функционирования каждого IP-хоста необходимо наличие в его рас-
поряжении маршрута по умолчанию (default route), будь то вручную сконфигурирован-
ный или определенный динамическим способом маршрут. Маршрутизация по умолча-
нию (default routing) обеспечивает конечные хосты выходом из локальной подсети, а
также предоставляет шлюзам последнее средство обеспечения передачи данных в том
случае, если в таблице маршрутизации данного шлюза нет других маршрутов, кроме
маршрута по умолчанию

Конечные хосты, как правило, не поддерживают своих собственных таблиц марш-
рутизации. хотя и имеют такую возможность. Эти хоегы используют локальные шлюзы
для передачи трафика на удаленные хосты. Для того чтобы конечный хост мог взаимо-
действовать с другими находящимися вне данной локальной сети хостами, сетевой ад-
министратор как минимум должен сконфигурировать этот хост с IP-адресом шлюза (зто
и еегь шлюз по умолчанию). В зависимости от конкретной реализации существует так-
же возможность сконфигурировать конечные хосты таким образом, чтобы они имели
возможность передавать дейтаграммы через запасной шлюз (alternate gateway), если пер-
вый шлюз в списке шлюзов но умолчанию становится недоступным. Если конечный хост
не имеет в составе своих параметров IP-адреса шлюза по умолчанию, это ограничивает
возможности данного хоста взаимодействием только с хостами своей локальной сети.

Маршрутизаторы по' ьзуюгся маршрутизацией по умолчанию как последним сред-
ством обнаружения пути к пункту назначения. Шлюз просматривает полученную дей-
таграмму на наличие логического адреса удаленного пункта назначения на сетевом уров-
не (logical Network layer address) Если в таблице маршрутизации данного шлюза
существует статический или динамический маршрут к удаленному пункту назначения с
этим адресом, шлюз передает дейтаграмму дальше

Если пункт назначения остается неизвестным (это значит, что реализация всей со-
вокупности процедур маршрутизации не завершилась формированием маршрута к дан-
ному пункту назначения), это вынуждай шлюз воспользоваться сконфигурированным
по умолчанию маршрутом. Как правило, сетевые администраторы реализуют маршруты
по умолчанию на соединениях типа точка-точка (point-to-point connections) или на ком-
мутируемых соединениях (dial-up connections) для связи сети компании с внешними от-
носительно их сетями.

Реализация динамической или статической маршрутизации в сети компании облег-
чает процесс обнаружения маршрутной информации (route information) о локальном
канате связи. Для того чтобы направить весь трафик за пределы сети, независимо от того,
для какого адресата эта информация предназначена, можно использовать маршрут по
умолчанию. Этот способ весьма эффективен, поскольку в Интернете существует около
105 тысяч маршрутов, следовательно, изучение маршрутной информации и обслужива-
ние шлюзами всех этих маршрутов привело бы к их перегрузке. Пои использовании
маршрута по умолчанию шлюз просто направляет весь трафик неизвестным ди,ресагам
вдоль конфигурируемого по умолчанию пути, который, как правило, обслуживается
Интернет-провайдером
Динамическая маршрутизация

Существует несколько типов протоколов динамической IP-маршрутизации (dynamic
IP routing protocols):

•	Дистанционно-векторные протоколы (RIP версия 1, RIP версия 2 и IGRP).

•	Протоколы маршрутизации по состоянию каналов связи (OSPF).

•	Протоколы смешанного типа (EIGRP).

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

•	Прогоколы категории IGP (Interior Gateway Protocols, Протоколы внутреннего
шлюза).

•	Протоколы категории EGP (Exterior Gateway Protocols, Протоколы внешнего шлю-
за).

Протоколы IGP обеспечивают выбор оптимального маршрута и обмен маршрутной
информацией в пределах одной автономной системы (AS, Autonomous System). Прото-
колы EGP предоставляют маршрутизатору одной автономной системы возможность
сообщить маршрутизатору другой автономной системы информацию о путях доступа к
сети этой системы.

Протоколы внутреннего шлюза (протоколы IGP)

Протоколы категории IGP, разработанные для реализации в инфраструктуре авто-
номной системы (Autonomous System infrastructure) той или иной компании, позволяют
собирать и обрабатывать маршрутную информацию, относящуюся к локальным сетям и
подсетям. Ниже рассматриваются следующие протоколы IGP:

•	RIP, версия I и RIP, версия 2 (Routing Information Protocol, Протокол маршрут-
ной информации).

•	IGRP (Interior Gateway Routing Protocol, Протокол маршрутизации внутреннего
шлюза).

•	EIGRP (Enhanced Intenor Gateway Routing Protocol, Улучшенный протокол мар-
шрутизации внутреннего шлюза — собственность компании Cisco).

•	OSPF (Open Shortest Path First, Протокол с алгоритмом поиска кратчайшего пути).

В сетевом комплексе одной компании могут функционировать различные протоко-
лы категории IGP. Наиболее оптимальным является использование протоколов такого
типа в работе средних и небольших сетей, хотя некоторые из них могут быть задейство-
ваны и в больших сетях. Каждый из протоколов категории IGP более подробно рассмат-
ривается в главе 6.

б Зак. 768
Протоколы внешнем шлюза (протоколы EGP)

Протоколы маршрутизации катеюрпи EGP (например, протокол BGP — Border
Gateway Protocol, Протокол граничного шлюза) разработаны для формирования марш-
рутов передачи данных между автономными системами. Следовательно, такие прото-
колы позволяют объе шшггь в единый сетевой комплекс сети разных компаний. Как
правило, протоколы EGP не имеют никакого отношения к функционирующим внутри
той или иной автономной системы пргточслам IGP. Протоколы EGP воспринимают всю
автономную систему как единое целое. Весьма производительный протокол BGP вы-
полняет большую часть работы по маршрутизации потоков данных в Интернете, обра-
батывая при этом множество маршрутов, соединяющих тысячи автономных систем между
собой. Более подробно протокол BG? рассматривается в главе 6.

Протоколы маршрутизации и выбор

наилучшего пути

Независимо or того, какой тип протокола маршрутизации используется, обнаружен-
ный маршрутизатором оптимальный маршрут к пункту назначения незамедлительно ре-
гистрируется в таблице маршрутизации данного маршрутизатора с целью дальнейшей
пересылки дейтаграмм по этому маршруту. Когда маршрутизатор получает дейтаграм-
му, он исследует указанный в заголовке дейтаграммы 1Р адрес хоста-получателя, чтобы
определить, куда направляется данная дейтаграмма Далее маршрутизатор проверяет свою
локальную таблицу маршрутизации на наличие маршрута к нужному пункту назначе-
ния. Если такой маршрут существует, маршрутизатор выбирает локальный интерфейс,
который будет использован для передачи дейта! раммы в пункт назначения. Маршрути-
затор также идентифицирует IP-адрес шлюза следующего трантитного участка пути,
который имеет путь к сети назначения.

Если маршрутизатор не имеет в своей таблице маршрутизации никакого маршрута к
нужному пункту назначения, он использует маршрут по умолчанию. Если маршрут по
умолчанию не сконфигурирован, маршрутизатор отбрасывает дейтаграмму и отсылает
по адресу хоста-отправителя lCMP-сообшение "Недостижим пункт назначения"
(Destination Unreachable), уведомляющее хосг-отправитель о тем, что требуемый хост или
сеть назначения является недостижимым.

Дистанционно-векторные протоколы маршрутизации

Дистанционно-векторные протоколы маршрутизации (distance vector routing
protocols), такие как RIP (версии 1 и 2) и 1GRP, оценивают наилучший путь к пункту
назначения по стоимости этого пути, измеряемому в количестве транзитов (hops). В
основу работы этих протоколов положен дистанционно-векторный алгоритм (distance
vector algorithm). Как правило, протоколы данной категории используют в своей работе
только широковещательные рассылки, хотя протокол RIP версии 2 ноддержизает также
и многоадресные рассылки.

Широковещательные сообщения рассылаются дистанционно-векторными протоко-
лами периодически с интервалом, зависящим от установленного в соответствующем тай-
мере значения. Когда маршрутизатор, определяющие маршрут к гаданному пункту на-
значения на основе дистанционно-векторного алгоритма, начинает работу в режиме
онлайн (оперативном режиме), он отправляет всем другим маршрутизаторам данного
локального сегмента сети запрос на передачу их таблиц маршрутизации. После этого
каждый маршрутизатор по истечении периода времени, указанного в таймере обновле-
ния (update timer), передает в широковещательной рассылке всю свою таблицу маршру-
тизации независимо от того, были в нее внесены какие-либо изменения или нет. При
этом в сети образуется избыточный трафик, не несущий никакой новой информации.

Когда маршрутизатор получает информацию об обновлении (update information), он
прибавляет единицу к стоимости объявленного ранее маршрута и обновляет свою ло-
кальную таблицу маршрутизации. Далее он ожидает, когда истечет период времени, ука-
занный в таймере обновления (update timer), и передает свою обновленную таблицу мар-
шрутизации всем другим маршрутизаторам и сетевым интерфейсам за исключением того,
от которого эти сведения были получены. В данном случае распространение маршрут-
ной информации контролируется таймерами, а не инициируется автоматически каким-
либо событием (например, выходом из строя одного из каналов связи). Следовательно,
у маршрутзаторов уходит определенный период времени на то, чтобы выяснить, какие
изменения произошли в сети, а также внести эти изменения в таблицу маршрутизации
и обновить маршруты в соответствии с ними. Этот процесс известен как процесс сходи-
мости (конвергенции, convergence), другими словами соглашения между маршрутиза-
торами по поводу оптимальных маршрутов.

Дистанционно-векторным протоколам свойственны следующие характеристики:

•	Работа дистанционно-векторных протоколов построена на основе рассылки ши-
роковещательных сообщений (broadcasts).

•	Дистанционно-векторные протоколы (за исключением протокола RIP версии 2)
выполняют маршрутизацию по всему классу IP-адресов (classful routing): при рас-
сылке маршрутизатором сообщений об изменениях не учитывается маска подсе-
ти, а это значит, что такие сообщения рассылаются по всем IP-адресам данного
класса.

•	Процесс обновления таблиц маршрутизации (update) контролируют специально
сконфигурированные таймеры.

•	Таблица маршрутизации отсылается полностью независимо от того, внесены в нее
изменения или нет.

•	Процессу маршрутизации посредством дистанционно-векторных протоколов свой-
ственно образование петель маршрутизации (routing loops),

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

•	Максимальное расстояние, на которое можно отправить дейтаграмму по сформи-
рованным дистанционно-векторными протоколами маршрутам, определяет диа-
метр сети (the diameter of the network).

•	В качестве единственного параметра, по которому вычисляется оптимальный мар-
шрут дистаннионно-векгорные протоколы используют количество транзитов
(шлюзов или маршрутизаторов, которые необходимо преодолеть на пути к адре-
сату'). Сумма всех транзитов данного пути составляет метрику маршрута (metric).
Когда маршрутизатор обнаруживает, что тот или иной канал связи недоступен, наи-
более вероятно, что он не станет немедленно информировать об этом своих соседей, а
будет удерживать эту информацию до тех пор, пока не истечет значение таймера. Такая
особенность дистанционно-векторных протоколов маршрутизации открывает возмож-
ность образования петель маршрутизации, а также задерживает обнаружение и устра-
нение неисправностей. По этой причине в реализациях дистанционно-векторных про-
токолов должны быть предусмотрены различные механизмы предотвращения
зацикливания трафика по круговому маршруту (loop avoiaance mechanisms). Такие ме-
ханизмы предотвращения петель маршрутизации позволяют свести к минимуму их ко-
личество, а также уменьшить их отрицательное воздействие как на сам процесс марш-
рутизации, так и, в конечном итоге, — на доставку данных в пункз назначения.

Зацикливание трафика по круговому маршруту возможно в гом случае, когда акти-
визированы несколько путей к пункту назначения. Если в сети имеются неправильно
сконфизурированные маршру гизаторы, такие маршрута |аторы могут разослать своим со-
седям некорректную маршрутную информацию, побуждая при этом принимающих та-
кую информацию маршрутизаторов восстановить испорченные (нерабочие) маршруты.

Кроме указанного выше недостатка дистанционно-векторных протоколов, существует
еще один. Ко>да маршрутизатор узнает о том, что гоз или иной маршрут удален из таб-
лицы маршрутизации, он готов оповестить соседей о произошедших изменениях. Одна-
ко маршрутизатор может отправить соответствующие корректировки только по истече-
нии периода обновления, задаваемого соо!ветствующим таймером. По этой причине
дру1ОЙ маршрутизатор может получить от своего соседа сообщение об обновлении, в
котором утверждается, что данный маршрут юдигся для передачи дейтаграммы в пункт
назначения. В свою очередь, этот маршрутизатор доверяет полученной информации и
восстанавливает данный маршрут в своей таблице

Оба задействованные в данном процессе маршрутизатора могут и не знать, что они
определяют маршрут друт через друга (именно это и приводи г к образованию петель мар-
шрутизации). Подобная ситуация складывается из-за тою что при обьявлении дистан-
ционно-векторными протоколами маршрутной информации указывается только 1Р-ад-
рес хоста или сети назначения и расстояние до него (выраженное в количестве транзитов)
от маршрутизатора, объявившего маршрутную информацию. В отправленные маршру-
тизатором сообщения об обновлении маршрутной информации (корректировки) не вхо-
дит маска подсети (кроме сообщений протокола RiP версии 2), а также IP-адрес шлюза
или путь, по которому маршрутизатор направляет трафик в эту сеть. Существует несколь-
ко способов предотвращения зацикливания дейтаграмм по круговому маршруту. Болес
подробно эти способы рассматриваются ниже в данной главе

Ограничение поля видимости

Принцип ограничения поля видимости (spin horizon) заключается в том, что шлюз
не должен отправлять через тот или иной сетевой интерфейс сообщения, содержащие
полученную от того же интерфейса маршрутную информацию. Шлюз может объявлять
маршруты, обнаруженные по какому-либо направлению, через все возможные интер-
фейсы, за исключением того интерфейса, от которого данная маршрутная информация
получена. Такое ограничение ноля видимости шлюза или маршрутизатора предотвра-
щает распространение некорректных маршрутных данных и исключает появление мар-
шрутных петель.
Механизм ограничения поля видимости (шлюза или маршрутизатора) можно интер-
претировать как известную всем игру в "испорченный телефон”, в которой один игрок
сообщает другому какую-либо тайну, другой игрок передает этот секрет следующему и
так далее. Игрок, услышавший секретное сообщение, не станет сообщать его тому, от
кого он это сообщение получил, поскольку эта тайна данному игроку уже известна. То
же самое происходит и со шлюзом. При использовании механизма ограничения поля
видимости (другими словами — ограничения диапазона рассылки корректировок) шлюз
не станет направлять дейтаграммы на тот же интерфейс, от которою поступило соот-
ветствующее сообщение. Шлюз может разослать полученную маршрутную информацию
только тем интерфейсам, которым эта информация еще не известна.

Неприменимость обратного маршрута

Механизм неприменимости обратного маршрута (poison reverse) по существу позво-
ляет маршрутизатору нарушать принцип ограничения поля видимости и отправлять со-
держащие маршрутную информацию сообщения через интерфейс, от которого эта ин-
формация получена. Однако в таких сообщениях должно быть указано количество
транзитов, на одну единицу превышающее максимально допустимое, или предельное
значение (infinity value). Для протокола R1P предельное количество транзитов равно 16,
для протокола 1GRP это значение равно 256. Маршрутизаторы, имеющие в своем рас-
поряжении маршруты с более подходящими метриками, просто игнорируют такой об-
ратный маршрут с предельным значением метрики. При этом данный маршрут к сети
назначения не исключается из таблицы маршрутизации, а сохраняется в ней, но его
нельзя использовать, поскольку этому маршруту присвоен статус недостижимого: мет-
рика маршрута равна 16 (RIP) или 256 (IGRP).

Подсчет транзитов до предельного значения и подавление изменений

Дистанционно векторные протоколы вычисляют оптимальный путь на основании
расстояния до каждого пункта назначения. В каждом протоколе специфицируется мак-
симальное расстояние до пункта назначения, поддерживаемое данным протоколом. Ди-
станционно-векторные протоколы измеряют расстояние в количестве транзитов; это
расстояние называют метрикой маршрута (metric). В частности, для протокола RIP мак-
симально допустимое расстояние равно 15 транзитным участкам, для протокола IGRP
это значение равно 255. Маршрутизаторы рассматривают как недостижимые те марш-
руты, значение метрик которых больше максимально допустимого расстояния, и не
передают дейтаграммы но таким маршрутам.

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

Для иллюстрации механизма подсчета транзи тов до предельного значения можно ис-
пользовать протокол R1P. Когда маршрутная информация передается от одного марш-
рутизатора к другому, каждый маршрутизатор увеличивает счетчик транзитов на еди-
ницу до тех пор, пока какой-либо из маршрутизаторов не получит сообщение со
значением метрики, равным 15 Увеличение этого значения еще на одну единицу озна-
чает, что будет превышено максимально допустимое расстояние до пункта назначения.
Из этого следует, что данный пункт назначения становится недостижимым на маршру-
те с количеством транзитов, равным 16 или более. Далее маршрутизатор должен объя-
вить этот маршрут как недостижимый, указав ь < воем следующем сообщении предель-
ное количество транзитов, превысившее значение максимально допустимого расстояния
до пункта назначения

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

Маршрутизатор начинает подсчет транзитов в тот момент когда он получает от со-
седнего маршрутизатора объявление о каком либо маршруте ло пункта назначения. Рас-
смотрим пример, в котором таршрутизатору А известно, что маршрут к пункту назна-
чения является нерабочим. В тот момент, когда маршрутизатор А готовится объявить об
этом своим соседям, он получает объявление о маршруте от дру того маршрут изатора
(маршрутизатора В), и в этом объявлении утверждается, что этот маршрутизатор нахо-
дится в 4 транзитах от сеги назначения.

С другой стороны, пу гь маршрутизатора А к сети назначения (являющейся недости-
жимой) проходит через маршрутизатор В Маршрутизатор А не знает о том, что марш-
рутизатор В считает возможным передавать график в данную сеть через маршрута штор
А (может быть, не был активизирован механизм ограничения поля видимости). Прини-
мающему маршрутную информацию маршре гизатору (в данном случае — маршрутиза-
тору А) неизвестно, какой путь маршрутизатор В намерен использовать, чтобы достичь
необходимой сети. Маршрутизатор А знает только то, что отправитель маршрутной
информации (маршрутизатор В) считает возможным достичь сети назначения. Един-
ственно возможный выход из сложившейся ситуации для маршрутизатора А - это счи-
тать полученные маршрутные данные достоверными и внести данный маршрут в свою
таблицу маршрутизации, увеличив на единицу счетчик транзитов данного маршрута.

Предположим, что эти два маошрутиз-агора были некорректно сконфигурированы.
В результате маршрутизатор А снова отправляет маршрутизатору В сообщение о том,
что он находится в 5 трин „игах от пункта назначения. Маршрутизатор В, отправивший
исходное объявление о данном маршруте, принимает это сооошенче и делает предпо-
ложение, что если отправивший дачное сообщение маршрутизатор находится в 5 тран-
зитах от сети назначения, то он (маршрутизатор В) находится от него в 6 транзитах (счет-
чик транзитов увеличивается при этом на I). Э-от процесс продолжается в каждом
маршрутизаторе по всему маршруту, и каждый обновляющий маршрутную информацию
маршрутизатор увеличивает на единицу счетчик транзитов до тех пор, пока значение
счетчика не достигнет максимально допустимого значения. Как только максимально
допустимое количество транзитов будет превышено, данный маршрут удаляется из таб-
лиц маршрутизации.

Между тем дейтаграммы, направляемые маршрутизаторами в сеть назначения (ко-
торая на самом деле является недостижимой для этих дейтаграмм) передаются по кру-
говому маршруту между указанными маршрутизаторами до тех пор, пока не будет пре-
вышено максимальное количество транзитов. Когда же это значение будет превышено,
один из маршрутизаторов отбросит циркулирующие по круговому маршруту дейтаграммы
и отправит в адрес хоста-отправителя дейтаграмм 1СМР-сообшение "Destination
unreachable" (Недостижим пункт назначения).

Протоколы маршрутизации по состоянию каналов

связи

В отличие от дистанционно-векторных протоколов, оценивающих оптимальный путь
на основании расстояния до пункта назначения, протоколы маршрутизации но состоя-
нию каналов связи (Link State Routing Protocols) могут принимать более интеллектуаль-
ные решения при выборе маршрутов. При этом протоколы маршрутизации по состоя-
нию каналов связи используют для оценки того или иного маршрута либо один из
описывающих состояние канала связи параметров, либо совокупность этих параметров.
В число таких параметров входят следующие:

•	Производительность полосы пропускания (bandwidth)

•	Задержка (delay)

•	Надежность (reliability)

•	Нагрузка (load)

•	MTU, максимальный модуль пересылки (maximum transmission unit)

Протокол OSPF (Open Shortest Path First, Протокол поиска кратчайшего пути), от-
носящийся к категории протоколов маршрутизации по состоянию каналов связи, имеет
возможность обеспечить принятие решений о выборе маршрута на основании всех ука-
занных выше параметров. Однако, несмотря на это, по умолчанию реализуется только
один из параметров, а именно — производительность полосы пропускания.

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

Протоколам маршрутизации по состоянию каналов связи свойственны следующие ха-
рактеристики:

•	Работа протоколов маршрутизации по состоянию каналов связи построена на ос-
нове рассылки многоадресных сообщений (multicasts).

•	Триггерное обновление (triggered updates) инициируется автоматически каким-
либо событием и только в том случае, когда в сети происходят реальные измене-
ния; в сообщениях о триггерном обновлении маршрутной информации содержатся
только коррекшровки маршрутов.

•	Протоколы маршрутизации по состоянию каналов связи обеспечивают бесклас-
совую маршрутизацию (classless routing): в < ообщения об обновлении включена
маска подсети.

•	Для обеспечения заданного в заголовке IP сипа сервиса (ToS. Type of service) и
качества сервиса (QoS, Quality of service) протоколы маршрутизации по состоя-
нию каналов связи рассчитывают оптимальные маршруты на основании таких па-
раметров, как производительность полосы пропускания, задержка, надежность,
нагрузка и MTU.

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

•	Протоколы маршрутизации данной категории требуют большого объема време-
ни, памяти и других ресурсов, расходуемых центральным процессором для сбора
и обработки маршрутной информации.

В работе протоколов маршрутизации по состоянию каналов связи не применяется
регулярная рассылка сообщений об обновлении. Во время инициализации маршрутиза-
торов после первоначального обмена маршрутной информацией эти маршрутизаторы от-
правляют только сообщения о триггерном обновлении маршрутной информации (дру-
гими словами, сообщения о корректировках, выполняемых авгоматически в случае
изменения топологии сети в результате какою-либо события) В сообщениях о триггер-
ном обновлении маршрутизатор отправляет то."ько информацию об изменениях, сокра-
щая тем самым рабочую нагрузку в сети. Маршрутизаторы рассылают сообщения об
обновлении такого типа в многоадресной (а не в широковещательной) рассылке, тем
самым сокращаются за!раты хостов того или иного локального сегмента сеги на обра-
ботку данных. Только устройства, входящие в группу многоадресной рассылки, в пол-
ном объеме обрабатывают дейта! рамму, содержащую сообщение о триггерном обновле-
нии.

Протоколы маршрутизации по состоянию каналов связи поддерживают бесклассо-
вую маршрутизацию (classless routing) с использованием маски подсети (VLSM, Variable
Length Subnet Mask, Маска подсети переменной длины) посредством включения маски
подсети в объявление о маршруте. Наличие маски подсети позволяет получателям со-
общений об обновлении определить, является ли IP-адрес пункта назначения адресом
подсети или адресом сети.

В дистанционно-векторных протоколах, выполняющих маршрутизацию по классу ад-
ресов (протокол R1P версии 1 и протокол 1GRP) не предусмотрено включение маски
подсети (VLSM) в объявление о маршруте. На основании значения, указанного в пер-
вом байте IP адреса, протоколы такого типа могут определить только го. к какому клас-
су адресов относится данный IP-адрес — к классу А, В или С. Другой информации,
которой можно было бы руководствоваться при поиске маршрута к пункту назначения,
эти протоколы в своем распоряжении не имеют. Протоколы маршрутизации по классу
адресов не включают в свои обы вления маску подсети Из этого следует, чго получате-
лям сообщений 'тих протоколов неизвестно, является ли IP-адрес пункта назначения
адресом сети или адресом подсети. Поэтому протоколы такого типа применяют маску
подсети по умолчанию для того, чтобы установить ту часть IP-адреса пункта назначе-
ния, которая идентифицирует сеть.

Протоколы маршрутизации смешанного типа

Компания Cisco Systems разработала свой собственный лицензионный протокол мар-
шрутизации, известный под названием EIGRP (Enhanced Intenoi Gateway Routing
Protocol, Улучшенный протокол маршрутизации внутреннего шлюза). Протокол EIGRP
был разработан на основе дистанционно-векторного протокола IGRP путем расшире-
ния его возможностей через включение различных параметров состояния канала связи
в состав его характеристик Именно по этой причине протокол E1GRP можно класси-
фицировать как протокол смешанного типа. В отличие от дистанционно-векторных
протоколов, EIGRP имеет в своем распоряжении средства принятия более интеллекту-
альных решений при выборе маршрута.

Для вычисления оптимального маршрута к пункту назначения протокол EIGRP ис-
пользует те же параметры, что и протоколы маршрутизации по состоянию каналов свя-
зи (может применяться один из параметров или их совокупность):

•	Производительность полосы пропускания (Bandwidth)

•	Задержка (Delay)

•	Надежность (Reliability)

•	Нагрузка (Load)

•	MTU, максимальный модуль пересылки (Maximum transmission unit)

Протокол EIGRP имеет возможность обеспечить требуемый уровень типа и качества
сервиса (ToS и QoS) посредством определения оптимального маршрута на основании
всех перечисленных выше параметров, в то же время по умолчанию реализуется только
производительность полосы пропускания и шдержка. Для выбора среди множества пу-
тей маршрута с наименьшей стоимостью протокол EIGRP использует данные о полосе
пропускания и о задержке (времени на достижение пункта назначения при отсутствии
нагрузки в сети). Протоколу LIGRP свойственны несколько характеристик, сходных с
характеристиками протоколов маршрутизации по состоянию каналов связи

•	Работа протокола EIGRP построена на основе рассылки многоадресных сообще-
ний (multicasts).

•	Триггерное обновление (triggered updates) инициируется автоматически каким-
либо событием и только в том случае, когда в сеги происходят реальные измене-
ния; в сообщениях о триперном обновлении содержатся только корректировки
маршрутов.

•	Протокол EIGRP обеспечивает бесклассовую маршрутизацию (classless routing):
в сообщения об изменениях включена маска подсети.

•	Протокол EIGRP обеспечивает требуемый уровень типа и качества обстукива-
ния (ToS и QoS)

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

•	Протокол E1GPP поддерживает различные протоколы IP, IPX, и AppleTalk
Единственная отличительная характеристика протокола EIGRP заключается в том,
что этот протокол может обрабатывать маршр) гную информацию для трех разных сте-
ков протоколов: IP. IPX, и AppleTalk. Все другие протоколы, упомянутые в данной гла-
ве, предоставляют маршрутную информацию только для одного из укатанных выше сте-
ков протоколов

Для обслуживания сети какой-либо ком.тании, как правило, привлекаются несколь-
ко стеков протоколов. В таком случае обеспечение процесса маршрутизации в этой сети
требует реализации совокупности различных протоколов маршрутизации. Если в сети
компании функционируют такие стеки протоколов, как IP, IPX, и AppleTalk, это по-
требует вовлечения в процесс маршрута задай трех различных протоколов маршрутиза-
ции. Каждый из протоколов маршрутизации 1енерирует в таком случае информацион-
ный поток, связанный с обновлением маршрутных сведений, что значительно
увеличивает объем непроизводительных затрат. Эта проблема решается посредством
реализации единого протокола маршрутизации, а именно — протокола EIGRP, позво-
ляющего отслеживать все без исключения маршруты При формировании маршрута до
пункта назначения протокол E1GRF использует механизм триггерного обновления мар-
шрутной информации, обеспечивающий последовательное автоматическое распростра-
нение только обновленных маршрутных данных, что существенно сокращает рабочую
нагрузку в сети.

Протокол E1GRP, подобно протоколам маршрутизации по состоянию каналов свя-
зи, не использует в своей работе таймеры для регулярной рассылки сообщений об об-
новлении: он отсылает только сообщения о триггерном обновлении маршрутной инфор-
мации, вызванном каким-либо событием Более того, даже в этом случае EIGRP
отправляет только сообщения о реальных изменениях маршрутной информации, сокра-
щая при этом объем потока корректировок. Для передачи своих сообщений об обнов-
лении маршрутной информации протокол EIGRP использует мноюадресные (а не ши-
роковещательные) рассылки, а также поддерживает бесклассовую маршрутизацию.

Резюме

Процедура маршрутизации позволяет передавать пользовательские дейтаграммы в
пункт назначения, находящийся за пределами локальной сети. Когда хосты находятся в
разных локальных сетях, в процесс пересылки дейтаграмм между этими хостами вовле-
каются маршрутизаторы. Существуют различные способы маршрутизации, а именно: не-
посредственное сопряжение с сет»ю назначения через сетевые интерфейсы, статичес-
кая маршрутизация, динамическая маршрутизация и маршрутизация по умолчанию. Для
построения таблиц маршрутизации маршрутизаторы применяют либо один из этих спо-
собов, либо их совокупность.

Непосредственное сопряжение с сетью назначения через сетевой интерфейс счита-
ется самым падежным способом маршрутизации, поскольку при реализации этого спо-
соба маршрутизатору известна маршрутная информация непосредственно "из первых
рук”, без вовлечения в процесс маршрутизации других устройств и других способов мар-
шрутизации. Статическая маршрутизация требует ручного конфигурирования и обслу-
живания сети администратором. Маршрутизация по умолчанию предполагает наличие
у каждого IP-хоста маршрута по умолчанию. Маршруты, конфигурируемые по умолча-
нию, обеспечивают конечные хосты выходом из локальной подсети, а шлюзы — соеди-
пением с последним на пути к пункту назначения шлюзом. Динамическая маршрутиза-
ция позволяет автоматически обнаружить изменения топологии сети и сократить пери-
од времени, необходимый для конфигурирования и обслуживания сети.

Протоколы динамической маршрутизации можно отнести к одной из следующих ка-
тегорий: протоколы категории IGP (Interior Gateway Protocols, Протоколы внутреннего
шлюза) и категории EGP (Exterior Gateway Protocols, Протоколы внешнего шлюза). В
число протоколов категории IGP входят протоколы RIP версии 1 и 2, IGRP, EIGRP и
OSPF. Категория протоколов EGP представлена протоколом BGP. Протоколы катего-
рии IGP обеспечивают распространение маршрутной информации в пределах одной
автономной системы; протоколы EGP поддерживают обмен маршрутной информацией
с другой автономной системой (сетью другой компании).

Дистанционно-векторные протоколы используют только один параметр для вычис-
ления оптимального маршрута, а именно — расстояние до пункта назначения, измеря-
емое в количестве транзитов, которые должна пересечь дейтаграмма на пути к адресату.
Работа дистанционно-векторных протоколов может сопровождаться образованием пе-
тель маршрутизации. Для предотвращения зацикливания дейтаграмм по круговому мар-
шруту применяются следующие процедуры:

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

•	Неприменимость обратного маршрута (запрещение передачи сообщений об из-
менениях тому маршрутизатору, от которого они получены).

•	Подсчет транзитов до предельного значения (отбрасывание дейтаграммы при пре-
вышении максимально допустимою количества транзитов).

•	Подавление изменений (сохранение маршрута в таблице маршрутизации на про-
тяжении определенного периода, даже если этот маршрут объявлен недостижи-
мым).

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

Вопросы для повторения

1.	Какие способы маршрутизации применяю! маршрутизаторы для построения своих
таблиц маршрутизации?

2.	Каковы свойства статической маршрутизации?

3.	Каковы свойства динамической маршрутизации?

4.	В каких случаях целесообразно применять статическую и динамическую маршрути-
зацию?

5.	Какие действия предусматривает маршрутизация по умолчанию?

6.	Назовите две категории, к которым можно от нести каждый из протоколов динами-
ческой маршрутизации. Чем отличаются протоколы этих двух категорий?

7.	Назовите пять протоколов, которые относятся к категории IGP.
8.	Каковы характеристики дистанционно-векторных протоколов?

9.	Какой параметр используется дистанционно-векторными протоколами для вычис-
ления оптимального маршрута? Как изменяется значение этого параметра в зависи-
мости от того, в каком протоколе он применяется?

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

11.	Как работает механизм О1раничеиия поля видимости маршрутизатора (шлюза) в слу-
чае его активизации?

12.	Какими пятью параметрами руководствуются протоколы маршрутизации по состо-
янию каналов связи при вычислении оптимального маршрута?

13.	Назовите основные характеристики протоколов маршрутизации по состоянию ка-
налов связи.
Глава 6

Протоколы маршрутизации

В данной главе рассматриваются следующие протоколы:

•	Протоколы маршрутной информации (RIP)

•	Протокол поиска кратчайшего пути (OSPF)

•	Протокол граничного шлюза (BGP)

•	Протокол маршрутизации внутреннего шлюза (IGRP)

•	Усовершенствованный протокол маршрутизации внутреннего шлюза
(EIGRP)

Общая характеристика протоколов
маршрутизации

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

Задача каждою протокола маршрутизации, независимо or его типа, одна и та же:
передача дейтаграмм в пункт назначения. Когда маршрутизатор получает дейтаграмму,
он идентифицирует сеть или хост назначения по се IP-адресу, указанному в заголовке
IP. Далее он использует полученные адресные данные для поиска в своей локальной
таблице маршрутизации сформированного ранее пути к пункту назначения. Этот путь в
таблице маршрутизации идентифицирует локальный исходящий интерфейс (local
outbound interface), а также адрес маршрутизатора следующего транзитного участка (next-
hop router address). Эти данные маршрутизатор использует для дальнейшей пересылки
дейтаграммы в пункт назначения.

В главе 5 были рассмотрены механизмы статической и динамической маршрутиза-
ции. Данная глава посвящена различным протоколам динамической маршрутизации и
принципам их работы. Протоколы динамической маршрутизации позволяют обслужи-
вающим уровень 3 (сетевой уровень) модели OSI устройствам, таким как шлюзы или
маршрутизаторы, динамически осуществлять интеллектуальный выбор маршрутов к тому
или иному пункту назначения. В текущей главе представлены все протоколы динами-
ческой маршрутизации, начиная от протоколов категории IGP (Interior Gateway Protocols,
Протоколы внутреннего шлюза), используемых для маршрутизации в рамках одной ав-
тономной системы какой-либо компании, и заканчивая протоколом BGP (Border Gateway
Protocol, Протокол граничною шлюза). Протокол BGP относится к категории протоко-
лов EGP (Exterior Gateway Protocols, Протоколы внешнего шлюза) и управляет процес-
сом маршрутизации между автономными системами различных компаний.

Протоколы RIP

В настоящее время существует две версии протокола RIP (Routing Information Protocol,
Протокол маршрутной информации): версия 1 и версия 2. Обе версии протокола RIP
первоначально были разработаны в качестве протоколов маршрутизации стека прото-
колов XNS компании Xerox (Xerox Network Systems. Сетевая система компании Xerox).
Позднее одна из реализаций протокола R1P (программа Routed) была интегрирована в
операционную систему Unix, разработанную Калифорнийским университетом в Берк-
ли.

ПРИМЕЧАНИЕ

Протокол RIP специфицирован в двух документах RFC (Requests for Comments, Запрос на
комментарии): в RFC 1058 определен протокол RIP (версия 1), в RFC 2453 — протокол
RFC (версия 2).

Протокол RIP может выполняться либо на конечных хостах, либо на шлюзах Не-
смотря на то, что RIP функционирует на основе протокола UDP (User Datagram Protocol,
Протокол передачи пользовательских дейтаграмм) и протокола IP (Internet Protocol,
Протокол Интернета), используя при этом порт UDP 520, он и сам является протоко-
лом сетевого уровня. RIP принадлежит к категории протоколов IGP и обеспечивает
обнаружение маршрута передачи данных в пределах одной автономной системы. Среди
характеристик протокола R1P (подробное их описание изложено ниже в данной главе)
имеются характеристики, ограничивающие сферу применения данного протокола. На-
личие таких ограничений предполагает, что наиболее целесообразно использовать RIP
для маршрутизации трафика только в сетях средних размеров.

ПРИМЕЧАНИЕ

Автономная система (AS, Autonomous System) — это совокупность сетей, совместно ис-
пользующих единый протокол маршрутизации под единым управлением.

Протокочу маршрутной информации (RIP) свойственны следующие характеристи-
ки:

•	Протокол RIP функционирует на основе широковещательных рассылок.

•	Протокол R1P принадлежит к категории протоколов IGP.

•	Применение протокола RIP наиболее эффективно для маршрутизации в средних
сетях.

•	Протокол RIP — это дистанционно-векторный протокол маршрутизации.
Протокол RIP принадлежит к классу дистанционно-векторных протоколов маршру-
тизации; работа этого протокола основана на реализации алгоритма Беллмана-Форда
(Bellman-Ford), который известен также под названием "алгоритм Форда-Фулкерсона
(Ford-Fulkerson)”. Посредством этою алгоритма протокол RIP вычисляет оптимальный
маршрут на основании кратчайшего расстояния к пункту назначения, измеряемого в
количестве транзитов (hops) между хостом-отправителем и адресатом. В настоящее время
существует ряд протоколов, осуществляющих более интеллектуальный и эффективный
выбор маршрута, однако протокол RIP версии 1 остается одним из наиболее широко
распространенных (после протокола OSPF) протоколов.

Как упоминалось выше, существует две версии протокола RIP: RIP версии 1 и RIP
версии 2 (в дальнейшем они именуются соответственно RIPvl и RIPv2). В данной главе
рассматривается протокол RIPvJ, а затем анализируются различия между двумя верси-
ями RIP. Блаюдаря своей простоте протокол RIP получил в мире самое широкое рас-
пространение. Прежде всего, преимущество этого протокола заключается в том, что он
доступен для понимания и удобен в эксплуатации. Несмотря на го, что обе версии про-
токола RIP имеют сходные характеристики, в протокол RIPv2 включены дополнитель-
ные элементы, позволяющие компенсировать недостатки RIPvl. Версия 2 протокола RIP
также рассматривается в данной главе.

Протокол RIPvl

Протокол RIP реализуется на конечных хостах или на шлюзах как средство отсле-
живания маршрутов к пунктам назначения, таким как хосты, сети, подсети, либо как
средство передачи трафика вдоль устанавливаемых по умолчанию маршрутов (если не-
известен адрес пункта назначения). Конечные хосты или шлюзы получают информацию
о маршрутах к пунктам назначения из сообщений об обновлении маршрутов (route
updates). Передающие маршрутную информацию устройства обмениваются такими со-
общениями (корректировками) динамически через широковещательные рассылки в пре-
делах локального сегмента сетевого комплекса.

Все устройства, на которых активизирован протокол RIP (RJP-устройства), прини-
мают и передают сообщения через UDP-порт 520. В сетях с широковещательной рас-
сылкой сообщений, таких как Ethernet или Token-Ring, все без исключения устройства
принимают сообщения об обновлении, но только устройства, принимающие сообщения
через порт UDP 520, могут обрабатывать полученные дейтаграммы. Каналы связи гло-
бальной сети (WAN, Wide area network), такие как каналы связи типа "точка-точка" (point-
to-point links), не поддерживают широковещательных сообщений. Следовательно, если
передача маршрутной информации выполняется пи таким каналам, необходимо специ-
ально идентифицировать и сконфигурировать в сети соседние устройства (шлюзы или
маршрутизаторы) таким образом, чтобы они имели в своем распоряжении IP адреса друг
друга. Это делает возможным обмен сообщениями между устройствами, передающими
маршрутную информацию.

Устройства, обслуживающие протокол RIP, поддерживают локальные базы данных
маршрутной информации (известные также как таблицы маршрутизации, routing tables).
В этих базах данных содержится перечень всех соединенных локальными каналами связи
сетей, а также тех сетей, информация о которых получена статическим или динамичес-
ким способом от соседей (других устройств, обслуживающих R1P). На начальной ста-
дни в этот перечень входят записи, содержащие информацию только о локальных сетях
или сетях, непосредственно соединенных с данной локальной сетью Однако после об-
мена сообщениями об обновлении маршрутной информации с соседями маршрутиза-
тор изменяет содержимое таблицы маршрутизации, включив в ее состав полученные от
соседей маршруты. В таблицу маршрутизации могут быть включены следующие данные:

•	IP-адрес хоста, сети или подсети назначения, либо (если такой адрес неизвестен)
— маршрут по умолчанию (0.0.0.0).

•	I P-адрес маршрутизатора следующего транзитного участка маршрута к пункту на-
значения.

•	Значение метрики (metric), или стоимость пути, измеряемую в количестве тран-
зитов (перемещений дейтаграммы через маршрутизаторы на пути к пункту назна-
чения) и выраженную целым числом от 1 до 15. Стоимость пути определяет рас-
стояние отданного устройства до сети назначения.

•	Локальный сетевой интерфейс, используемый хостом для передачи дейтаграммы
следующему на пути к пункту назначения маршрутизатору. В таблицу маршрути-
зации могут также быть включены (в зависимости от реализации) другие данные.

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

Каждые 30 секунд шлюзы рассылают свои широковещательные сообщения, содер-
жащие полную таблицу маршрутизации. Регулярную рассылку корректировок контро-
лирует механизм синхронизации (clocking mechanism), сконфигурированный на каждом
шлюзе. Шлюз включает в свои сообщения об обновлении все известные ему маршруты
вместе с соответствующим каждому маршруту расстоянием (в количестве транзитов) до
пункта назначения. В каждое сообщение об изменениях маршрутной информации шлюз
может включить до 25 пунктов (строк таблицы маршрутизации). Если таблица содер-
жит более 25 строк, остаток информации шлюз должен передать в последующих сооб-
щениях.

^ПРИМЕЧАНИЕ

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

Широковещательный характер протокола RIP, а также тот факт, что одною сооб-
щения об обновлении может быть недостаточно для объявления всех имеющихся в таб-
лице маршрутов, приводит к увеличению рабочей нагрузки в сети и, соответственно, к
росту объема непроизводительных затрат. Кроме того, шлюзы периодически рассылают
свои широковещательные сообщения с интервалом 30 секунд независимо от того, изме-
нилась ли маршрутная информация или нет. После получения подобной корректиров-
ки шлюз предпринимает следующие действия:

I.	Фиксирует все неизвестные ему маршруты в своей таблице маршрутизации и уве-
личивает значение счетчика транзитов на единицу.
2.	Заменяет (там, где это возможно) предыдущие маршруты маршрутами с более низ-
кими значениями метрик.

3.	Удаляе! из своей таблицы маршрутизации вышедшие из строя или недостижимые
маршруты.

4.	Готовится к тому, чтобы объявить обновленную маршрутную информацию соседям,
находящимся в смежных сегментах сети.

Рассылка шлюзом сообщений об обновлении своим соседям напоминает ситуацию,
когда вы сообщаете своим друзьям по сотовому телефону о движении транспорта на
дороге: по какой улице можно проехать и на какое расстояние. Таким же образом мар-
шрутизатор объявляет все доступные маршруты к пункту назначения. Когда ш поз объяв-
ляет тот или иной маршрут, он указывает IP-адрес пункта назначения и расстояние до
него в количестве транзитов. Получатели маршрутной информации прослушивают объяв-
ления о маршрутах, итвлекают из них требуемую информацию и включают ее в своп
локальные таблицы маршрутизации. Когда шлюз вводит тот или иной маршру! в свою
таблицу маршрутизации, он все1да увеличивает расстояние (т.е. значение счетчика тран-
зитов) на единицу, отмечая тем самым факт, что пункт назначения находится отданно-
го шлюза на один транзит дальше, чем шлюз, от которого маршрут получен. После вклю-
чения маршрута в таблицу маршрутизации шлюз рассылает всем своим соседям,
находящимся в локальных сегментах сети или подключенным к локальной сети через
каналы связи типа "точка-точка", объявление обо всех известных этому шлюзу маршру-
тах.

Выбор маршрута

Протокол R1P использует расстояние до пункта назначения в качестве основного
параметра для вычисления оптимального маршрута: чем меньше расстояние, тем лучше
маршрут. Когда существует несколько маршрутов к пункту назначения, обслуживающий
протокол RiP маршрутизатор выбирает в качестве оптимального маршрут с наимень-
шим расстоянием (измеряемым в количестве транзитов) до адресата. Маршрутизатор ре-
гистрирует выбранный маршрут в своей таблице маршрутизации, а затем использует
полученную информацию для передачи дейтаграмм в пункт назначения Упрощенный
подход протокола RiP к определению оптимального пути не всегда приводит к выбору
самого лучшего маршрута к пункту назначения. Предположим, существует два маршру-
та к тому или иному адресату:

•	Расстояние по одному из маршрутов до пункта назначения равно четырем тран-
зитам; этот маршрут состоит из трех каналов связи сеги Ethernet со скоростью
100 Мбайт/сек и одного канала связи TI глобальной сети.

•	Расстояние до пункта назначения по другому маршруту равно трем транзитам; этот
маршрут состоит из двух каналов связи сети Ethernet со скоростью 100 Мбайт/
сек и канала глобальной сеги со скоростью 19.2 Кбайт/сек (см. рис. 6.1)

Поскольку протокол RIP неукоснительно использует только расстояние для вычис-
ления оптимального маршрута, он выберет путь с расстоянием в три транзита. Однако
на самом деле оптимальным является другой путь — маршрут, расстояние по которому
до пункта назначения равно четырем транзитам. Общая скорость передачи данных между
конечными точками на данном маршруте выше, чем па маршруте, выбранном протоко-
лом RIP. Если бы расстояние до пункта назначения по каждому из маршрутов было
равным трем транзитам, протокол RIP принял бы во внимание только тот факт, что оба
маршрута имеют одинаковое значение счетчика транзитов. В этом случае R1P предпри-
нял бы попытку просто уравновесить два имеющихся в его распоряжении маршрута,
отправив дейтаграммы по обоим маршрутам одновременно. В сложившейся ситуации
из-за неодинаковой скорости передачи данных на разных участках маршрутов передача
дейтаграмм по каналу связи со скоростью 19.2 Кбайт/сек замедлит процесс прохожде-
ния трафика между удаленными хостами. Подобная ситуация может также вызвать бло-
кировку соединений по времени и разрушение маршрута.

РИСУНОК 6.1

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

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

• Какой маршрут более предпочтителен
для передачи данных?

В отличие от протоколов маршрутизации по состоянию каналов связи (Link-state
routing protocols), протокол RIP при вычислении оптимального пути к пункту назначе-
ния не принимает во внимание другие важные факторы, которые могут повлиять на
выбор пути, а именно:	t

•	Производительность полосы пропускания каната связи (bandwidth capacity of а
link).

•	Надежность (reliability).

•	Нагрузка (load).

•	Задержка (delay).

•	MTU, Максимальный модуль пересылки (maximum transmission unit).

Протокол RIP принимает решение о выборе маршрута на основании весьма ограни-
ченного набора данных, а именно — только на основании расстояния до пункта назна-
чения. Это может привести к возникновению серьезной проблемы при передаче инфор-
мации. Предположим, вы совершаете поездку на работу в город из пригорода. Вы можете
выбрать более короткий путь (в смысле расстояния) по проселочным дорогам с плохим
покрытием. С другой стороны, можно отправиться по более длинному пути — по авто-
магистрали, и добраться до пункта назначения быстрее (автомагистраль можно интер-
претировать как полосу пропускания с высокой производительностью). Однако на ско-
ростной автостраде с большей вероятностью можно попасть в аварию, и тогда путь до
места назначения займет в четыре раза больше времени. Не желая рисковать надежно-
стью передачи данных, протокол RIP не привлекает к процессу вычисления оптималь-
ного пути никаких других данных, кроме расстояния до пункта назначения.

В обеих версиях RIP максимальное расстояние до пункта назначения ограничивает-
ся 15 транзитами, что равно максимальному количеству ш позов, через которые дейтаг-
рамма может Пройти на пути к адресату. Протокол RIP рассматривает расстояние в 16
транзитов слишком большим, то есть недостижимым (unreachable) расстоянием. Если
дейтаграмма проходит 15 шлюзов, шестнадцатый шлюз отбрасывает дейтаграмму и от-
сылает в адрес хоста-отправителя этой дейтаграммы ICMP-сообщение "Недостижим
пункт назначения" (Destination unreachable). Для получения более подробных сведений
о сообщениях 1СМР следует обратиться к главе 3.

Формат и поля заголовка протокола RIPvl

Для выполнения поставленных перед протоколом RIP задач этот протокол исполь-
зует два разных типа сообщений:

•	Сообщения, содержащие маршрутную информацию (routing information messages).

•	Сообщения, содержащие запросы на предоставление информации (request
messages).

Оба типа сообщений передаются в дейтаграммах с заголовками общего формата. В
этом заголовке имеется фиксированная (неизменяемая) часть, за которой следует та часть
заголовка, которая может меняться ь зависимости от обстоятельств В изменяемой час-
ти заголовка RIP представлен список гак называемых дистанционно-адресных пар
(network distance pairs), или пар "сетевой (IP) адрес — расстояние до пункта назначения
(ме!рика)". Общая длина заголовка R1P зависит от количества дистанционно-адресных
(маршрутных) пар, помещенных в данную дейтаграмму. С другой стороны, длина дей-
таграмм R1P не может превышать 512 байтов, что соответствует 25 строкам таблицы мар-
шрутизации. В этот максимальный размер (512 байтов) не входит длина за оловка ка-
нальною уровня, заголовка IP и за! оловка UDP На рис. 6.2 представлен формат
сообщения протокола RIPvl.

Может
повторяться
25раз

РИСУНОК 6.2 В сообщении протокола RIPvl после общей наста заголовка (длина этой части —
32 бита) следует серия дистанционно-адресных пар В каждой такой паре указан сетевой IP-adpec
пункта назначения и целое число, соответ твующее расстоянию до него в количестве транзитов.

Поля, в которых указана информация о маршруте и расстояние до пункта назначе-
ния, дублируются ровно столько раз, сколько объявляется маршрутов Например, если
шлюз объявляет пять маршрутов, два неиспользуемых поля (Unused) и поле метрики
(Metric) повторяются пять раз: по одному для каждого объявленного маршрута. Каждая
дейтаграмма протокола RIP может содержать в себе до 25 пунктов (строк таблицы мар-
шрутизации).

Поля заголовка RIPv2 рассм;н ри каются ниже в данной 1лаве.

Поле команды

Поле команды (Command), имеющее длину I байт, идентифицирует предполагаемое
назначение кадра (например, RIP-запрос или RlP-отвег). В этом поле в зависимости от
типа отправляемого протоколом RIP сообщения может быть указана одна из восьми су-
ществующих команд. В таблице 6.1 представлены все команды, а также значение каж-
дой из них.

Таблица 6.1 Команды RIP

Команда	Значение
1	Запрос, который хост или шлюз отправляет после инициализации (или после очистки локальной таблицы маршрутизации), обращаясь ко всем соседям с просьбой отправить в ответ свою маршрутную информацию.
2	Ответ, содержащий маршрутную информацию и отправляемый хостом или шлюзом в качестве ответа на RIP-запрос. Это может быть также регулярное (отправляемое периодически каждые 30 секунд) сообщение об обновлении маршрутной информации, содержащее в себе направленное соседям объявление об имеющихся в рвспоряжении хоста или шлюза маршрутах.
3	Вышедшая из употребления команда, активизирующая режим отслеживания
4	Вышедшая из употребления команда, отключающая режим отслеживания.
5	Команда, зарезервированная для внутреннего пользования компании Sun Microsystems.
9	Запрос на обновление маршрутной информации, используемый на выделяемых по требованию каналах связи.
10	Ответ об обновлении маршрутной информации, используемый на выделяемых по требованию каналах связи.
11	Подтверждение обновления маршрутной информации, используемое на выделяемых по требованию каналах связи.

Поле версии

В поле версии (Version), имеющем длину 1 байт, указывается версия протокола RIP —
версия I или версия 2. Поддерживающие протокол RIP хосты и шлюзы должны согла-
совать между собой вопрос о том, какую версию протокола RIP они будут использо-
вать.

Устройства, обслуживающие протокол RIPvl, не поддерживают реализованных в
протоколе RIPv2 расширений. В число таких расширений входит маска адреса подсети
переменной длины (VLSM, Variable Length Subnet Mask), а также аутентификация
(authentication) и многоадресная рассылка сообщений (multicasting). Следовательно, если
в сети функционируют обе версии протокола RIP —RIPvl и RIPv2, могут возникнуть
проблемы, связанные с взаимодействием этих протоколов.

С другой стороны хосты или шлюзы, обслуживающие RIPv2, поддерживают специ-
фикации протокола RIPvl; для обмена маршрутной информацией в смешанной среде
(когда наряду с RlPv2 используется также и RIPvl) эти хосты или шлюзы применяют
поля заголовка RIP и их значения, распознаваемые протоколом RIPvl. В данной ситу-
ации RIPvl является "общим знаменателем", который представляет собой те общие ха-
рактеристики, которые свойственны как RIPvl, так и RJPv2.

Разрешить проблему совместимости обслуживающих RIPvl и RlPv2 устройств мож-
но посредством конфигурирования RJРу2-маршрутизаторов таким образом, чюбы они
поддерживали как RIPvl, так и RIPv2. Для этого к Е1Ру2-маршрутизатору можно под-
ключить по одному интерфейсу для каждого из протоколов. В случае подсоединения
одного из интерфейсов к сегменту сети, на устройствах которого активизированы обе
версии — как RIPvl, гак и RIPv2, необходимо сконфшурировать этот интерфейс таким
образом, чтобы он поддерживал версию RIPvl. Когда другой интерфейс подключается
к сегменту, на котором функционируют только поддерживающие RIPv2 устройства,
необходимо сконфигурировать его как поддерживающий RIPv2 интерфейс.

Несмотря на то, что характеристики протоколов RIPvl и RIPv2 практически иден-
тичны, в версии RIPv2 реализованы такие дополнительные возможности (отсутствую-
щие в RIPvl), которые делают эти две версии протокола RIP несовместимыми.

Неиспользуемое поле

В заголовке RIPvl есть несколько неиспользуемых полей (Unused), имеющих длину
2 байта. Протокоч RIPvl не использует эти поля, следовательно, они всегда заполнены
нолями. Неиспользуемое поле дублируется столько раз, сколько маршрутов передается
в данной дейтаграмме.

Поле идентификатора семейства адресов

Несмотря на то, что с формальной точки зрения протокол RIP может поддерживать
различные протоколы сетевого уровня, в поле идентификатора семейства адресов
(Address Family Identifier) в большинстве случаев указывается значение 2, соответству-
ющее семейству адресов протокола 1Р. Длина поля — 2 байта.

Поле IP-адреса

Значение, указанное в имеющем длину 4 байта поле IP-адреса (IP address), иденти-
фицирует IP-адрес хоста, сеги или подсети назначения, либо объявленный маршрути-
затором адрес но умолчанию.

Поле метрики

Значение, указываемое в поле метрики (Metric) длиной 4 байта, идентифицирует
стоимость нуги до пункта назначения, другими словами, расстояние, измеряемое в ко-
личестве транзитов, оч хоста или шлюза, объявляющего данный маршрут, до сечи на-
значения. В этом поле должно быть указано значение от I до 15. Если в поле указано
значение 16, протокол RIP рассматривает объявленный маршрут как недостижимый из-
за повреждения канала связи или шлюза.

На рис. 6.3 показан пример объявления о маршруте протокола RIP, отправленною
шлюзом.

Недостатки протокола RIPvl

Несмотря на то, что протокол RIP является в настоящее время одним из наиболее
широко используемых протоколов маршрутизации, ему все же свойственны существен-
ные недостатки, а именно:
РИСУНОК 6.3

За полем
идентификатора
семейства адресов
(Address Family
Identifier) следует
фрагмент
сообщения, в
котором
содержится серия
маршрутных паи
(пар "IP-адрес —
расстояние')

IP. Protocol	- IZ <’W)

IP Header EJiecksun • A3 AC (correct)

IF. Source address	- [126 104 170.17]

IF Destination address • [126 1114 0 €i)

IP: No options

_ IF

.-J UDP-------UDP Header -------

П UDP

В L’DP- Source port • K20 (Rnute)

Э UDP Destination port » Б20 (Route)

D UDF Length	- 32

Tj UDP‘ СЬвскииж	“ CE4F (correct)

у UDP- [24 byte(s) ot date]

D №F

& RIP---------- RIP HcadCiF ——

JJRIP

.J RIP	Coiinand		2	(Response)

RIF	Version	••	J

_3 RIF	Unused	=	0

rjRIP

RIP	Routing	data (гаме	1

^3 RIP Address taniLy identifier - 2 (IP)

4JRIP	IF Address • [126 104 0 0]

□ RIP	Kotrie	- 1

UR**3

•	Работа протокола RIP построена на основе широковещательных рассылок, что
приводит к генерированию избыточно; о трафика в сети.

•	В процессе обновления маршрутной информации протокол RIP отправляет всю
таблицу маршрутизации, даже если в нее не внесены никакие изменения.

•	Поскольку обновление маршрутной информации контролируется специальными
таймерами синхронизации, протокол R1P обеспечивает медленную сходимость
(процесс соглашения между маршрутизаторами по поводу оптимального марш-
рута).

•	Протокол R1P предусматривает ограничение максимального расстояния до пун-
кта назначения 15 транзитами.

•	В процессе маршрутизации трафика под управлением протокола R1P существует
большая вероя!ность образования маршрутных петель.

•	Проюкол RIP относи 1ся к категории протоколов маршрутизации по классу ад-
ресов (Classfui routing proiocol); следовательно, RIPvl не поддерживает VLSM
(маски адресов переменной длины).

Поскольку протокол RIPv1 функционирует на основе широковещательных рассылок,
каждый шлюз периодически (с интервалом 30 секунд) отправляет в широковещатель-
ной рассылке всю таблицу маршрутизации даже при отсутствии каких-либо изменений
или новой значащей информации. Результатом такого подхода является появление в сети
избыточного трафика. Протоколы маршрутизации другого типа, такие как протоколы
маршрутизации по состоянию каналов связи, работают на основе многоадресной рас-
сылки объявлений о маршрутах. При этом сообщения об изменении маршрутной ин-
формации отправляются только тогда, когда в сети прои юшли реальные изменения, В
случае использования протокола RIP управление обновлением маршрутной информа-
ции в соответствии с временной синхронизацией (т.е. с помошыо таймеров) замедляет
процесс сходимости и процесс реагирования на возникновение определенных проблем,
таких как образование маршрутных петель.

Когда маршрутизатор получает информацию об изменениях в сети, например, о
подк почении нового канала связи или объявлении одного из каналов связи нерабочим,
он выполняет следующие действия:
I.	Принимающий объявление о маршруте шлюз регистрирует новые данные в своей
таблице маршрутизации и увеличивает значение счетчика транзитов на единицу (см.
рис. 6.4). Это действие указывает на то, что данный шлюз находится на один тран-
зит дальше от пункта назначения, чем шлюз, от которого получено обьявление о мар-
шруте.

2.	Если шлюз получает информацию о том, что тот или иной маршрут находится в не-
рабочем состоянии, он вводит в свою таблицу маршрут изации новую строку со зна-
чением счетчика транзитов, равным 16, и готовится к удалению этого маршрута из
таблицы.

3.	По истечении времени, задаваемого таймером периодического обновления, шчюз
отправляет очередное регулярное сообщение об обновлении маршрутной информа-
ции. В приведенном примере (когда значение счетчика транзитов равно 16) отправ-
ляется объявление об удалении маршрута из таблицы маршрутизации.

Если сеть состоит из множества сегментов и в ней функционирует ряд шлюзов, тре-
буется определенный период времени для того, чтобы информация об обновлении дос-
тигла каждого шлюза сети. Тем временем шлюзы работают с устаревшей и некоррект-
ной информацией. Кроме того, согласно протоколу RIP максимальное расстояние между
двумя взаимодействующими устройствами сетевою комплекса равно 15 транзитам, что
ограничивает диаметр сети и делает протокол RIP неприемлемым для реализации в сред-
них и больших сетях. Маршрутизаторы не могут передавать далее по сети дейтаграммы,
которые уже прошли через 15 шлюзов. Когда маршрутизатор получает дейтаграмму, зна-
чение счетчика транзитов которой больше 15, он передает в адрес хоста-отправителя этой
дейтаграммы предупреждающее ICMP-сообщение "Недостижим пункт назначения"
(Destination unreachable)

Как отмечалось в главе 5. в процессе маршрутизации под управлением протокола RIP
возникает большая вероятность образования маршрутных петель. В различных реализа-
циях RIP используются различные механизмы, позволяющие предотвратить беспрерыв-
ное движение трафика по круговому маршруту'. В число таких механизмов входят сле-
дующие:

•	Подсчет транзитов до предельного значения (Counl to infinity). Дистанционно-
векторные протоколы О1раничивают расстояние (измеряемое в транзитах), кото-
рое может преодолеть дейтаграмма. Если в процессе маршрутизации образовалась
маршрутная петля, маршрутизатор автоматически отбрасывает дейтаграмму при
превышении максимально допустимого количества транзитов (maximum hop count —
в данном случае это значение рано 15) и тем самым прекращает подсчет транзи-
тов до бесконечности.

•	Временное подавление изменений (Holddown). Механизм временного подавления
изменений позволяет удерживать маршрут в таблице маршрутизации, даже если
он обозначен как недостижимый или потенциально нерабочий. Когда сеть функ-
ционирует в режиме временного подавления изменений, никакие корректиров-
ки маршрутной информации не принимаются во внимание. Как только статус
маршрута определен окончательно, маршрутизатор либо исключает этот маршрут
из таблицы маршрутизации, либо восстанавливает его.
•	Ограничение поля видимости (Split horizon). Как отмечалось в главе 5, механизм
щраничения поля видимости передающего маршрутную информацию устройства
предписывает шлюзу или хосту (с активизированным на нем протоколом R1P) не
отправлять объявления о маршрутной информации на тот же интерфейс, от ко-
торого эта информация получена (см. рис. 6.5).

•	Неприменимый обратный маршрут (Poison reverse). Механизм объявления обрат-
ного маршрута неприменимым позволяет шлюзу нарушить принцип ограничения
поля видимости (split-horizon rule). При активизации механизма неприменимос-
ти обратного маршрута шлюз имеет возможность отправлять сообщения об изме-
нениях маршрутной информации на тог же интерфейс, от которого эта инфор-
мация получена. Однако он обьявляет передаваемые в этом направлении
маршруты как маршруты, имеющие предельное значение счетчика транзитов
(infinity hop value). Предельное количество транзитов указывает на недостижи-
мость маршрута, что, в свою очередь, влечет за собой невозможность передачи
трафика по данному маршруту. Маршрутизаторы, имеющие в своем распоряже-
нии маршрут с более подходящей метрикой (т.е. с меньшим значением счетчика
транзитов), игнорируют маршрут, отмеченный как недостижимый (см. рис. 6.6).

Реализация перечисленных выше механизмов предотвращения образования маршрут-
ных петель зависит от задаваемых поставщиками спецификаций и конкретного конфи-
гурирования протокола RIP в сети.

РИСУНОК 6.4

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

Подтает транзитов до предельного значения

* Кеадый раз, когда пакет проходит через маршрутизатор,
значение счетчика транзитов увеличивается

Маршрутизатор Маршрутизатор Маршрутизатор

Транзит 1 |р^Транзит2
—>
Пакет

 Максимальное количество транзитов
(для протокола RIP —15 тоавзитоа}

РИСУНОК 6.5

Маршрутизатор в центре получает
информацию о сетях 12.0.0.0 и
14.0.0.0 от интерфейса,
расположенного справа, передавать
эту информацию маршрутизатор
может только па находящийся с
противоположной стороны
интерфейс. Информацию о сетях
11.0.0.0и 15.0.0.0 данный
маршрутизатор получает от
интерфейса, находящегося слева, и
может передать ее только в
противоположном направлении.

Ограничение поля видимости

 Маршрутная информация, полученная от интерфейса, никогда
не передается на тот же интерфейс, от которого она получена.
РИСУНОК 6.6

Механизм объявления
обратного маршрута
неприменимым позволяет
маршрутизатору нарушить
принцип ограничения поля
видимости.

Неприменимый обратный маршрут

• Маршрутизаторы присваивают значение 16 метрикам
всех маршрутов, полученных от данного интерфейса.

• Находящийся в центре маршрутизатор отправит на
интерфейс 1 сообща ив, в котором поло метрики сети
12.0.0.0 и сети 14.0.0.0 имеет значение 16.

Поскольку протокол RJPvl относится к категории протоколов маршрутизации по
классу адресов, он различает только IP-адреса классов А. В и С. Так как маска подсети
не включается в объявление о маршруте к пункту' назначения, RIPvl не может опреде-
лить, является ли тот или иной IP-адрес адресом сети или адресом подсети. Единствен-
ное, что могут предпринять принимающие маршрутную информацию шлюзы, — это вос-
пользоваться маской подсети, присваиваемой по умолчанию на основании объявленного
класса адресов. Например, на рис. 6.7 маршрутизаторы А и В — это маршрутизаторы,
обслуживающие протокол RIPvl. Маршрутизатор А отправляет маршрутизатору В объяв-
ление о маршруте к сети назначения без указания маски подсети. Не имея в своем рас-
поряжении информации о маске подсети, маршрутизатор В (который не подсоединен
непосредст венно к удаленным подсетям, входящим в состав объявленной сети назначе-
ния) на основании имеющихся данных может только предположить, что объявленный
маршрут является маршрутом к сети назначения класса В с маской по умолчанию
255.255.0.0. Следовательно, маршрутизатор В делает вывод, что сеть назначения не имеет
в своем составе подсетей. Этот вывод является ошибочным, однако, не имея в своем
распоряжении правильной маски подсети, маршрутизатор В другого вывода сделать не
может.

Маршрутизация по классу адресов

РИСУНОК 6.7

Протоколы
маршрутизации по классу
адресов, такие как
протокол RIPvl, не
распознают разбиение сети
на подсети. Причина этого
заключается в том, что
маршрутизация трафика
по адресу подсети требует
использования в объявлениях
о маршруте маски подсети
(VLSM).

• На данном рисунке изображена се-ь с адресом класса В,
обслуживаемая протоколами RIPvl и IGRP.

• Маршрутизатор А отправляет свое сообщение об обновлении маршрутной
информации по адресу сети без включения в это сообщение маски адреса подсети.

• Маршрутизатор В не имеет в своем распоряжении сведений о
существовании в данной сети входящих в ее состав подсетей.
Таймеры, обслуживающие протокол RIP

Для обеспечения временной синхронизации при обновлении маршрутной информа-
ции протокол RIP использует три таймера: таймер периодического обновления (periodic
update timer), таймер обнаружения нерабочих маршрутов (invalid timer) и таймер вре-
менного подавления изменений (holddown timer).

Протокол RIP периодически (с интервалом 30) секунд рассылает регулярные сооб-
щения об обновлении маршрутной информации. В этих сообщениях содержится вся
таблица маршрутизации независимо от того, имели место какие-либо изменения в сети
или нет.

Таймер обнаружения нерабочих маршрутов работает с интервалом 180 секунд. Если
за этот период времени шлюз не получает объявления о маршруте, он рассматривает этот
маршрут как нерабочий и соответственно его маркирует.

Таймер временного подавления изменений также активизируется протоколом R1P
каждые 180 секунд. После того как маршрутизатор регистрирует маршрут как нерабо-
чий из-за неисправности канала связи или отсутствия сообщений об обновлении этого
маршрута, шлюз запускает таймер временного подавления изменений. Это приводит к
временному прекращению приема корректировок, относящихся к данному маршруту,
до тех пор, пока не истечет задаваемый текущим таймером период времени. Когда шлюз
функционирует в режиме подавления изменений, он не принимает от других шлюзов
никаких объявлений об обновлении .маршрутной информации, которые привели бы к
восстановлению маршрута. Ко1да же период времени истекает, шлюз либо исключает
маршрут из таблицы маршрутизации, либо восстанавливает его. В случае если шлюз не
получает от другого шлюза объявления о том, чго данный маршрут годен к использова-
нию, маршрут исключается из таблицы маршрутизации. В противном случае (если по-
ступает объявление о корректности маршрута) шлюз восстанавливает маршрут.

Регулирование трафика обновления маршрутной информации

Некоторые реализации протокола R1P предоставляют в распоряжение сетевого ад-
министратора определенные средства регулирования трафика обновления маршрутной
информации, генерируемого в сети во время выполнения процедуры маршрутизации.
Разные реализации R1P отличаются между собой, поэтому следует навести справки у
поставщика по поводу специфичных для гой или иной реализации прикладных и кон-
фигурационных параметров. Существуют следующие способы регулирования трафика
обновления маршрутной информации:

• Настройка таймеров RIP (adjusting RIP timers). Существует возможность допол-
нительной настройки таймеров на RIP-устройствах Например, можно изменить
установленный в таймере периодического обновления интервал (30 секунд) на
более длительный период. Увеличение интервала между внесением корректиро-
вок сокращает количество широковещательных сообщений в сети, но при этом
замедляет процесс сходимости. При уменьшении периода рассылки сообщений
об обновлении поток широковещательных сообщений возрастает, а период вре-
мени. расходуемого на процесс сходимости, сокращается
ПРИМЕЧАНИЕ

Чрезвычайно важно помнить о том, что все хосты и шлюзы, на которых активизирован
протокол RIP, должны синхронизировать свою работу, другими словами, они должны со-
гласовать между собой значения таймеров RIP с тем, чтобы сходимость была возможной
(т.е. чтобы соглашение между этими устройствами по поводу оптимального маршрута
состоялось). В сетях, не поддерживающих широковещательную рассылку сообщений, та-
ких как глобальные сети с двухпунктовыми или многопунктовыми каналами связи, каж-
дый шлюз должен иметь в своем распоряжении IP-адреса всех шлюзов, с которыми он
будет обмениваться RIP-сообщениями об обновлении маршрутной информации.

•	Конфигурирование шлюзов с указанием спецификаций соседних устройств
(neighbor statements) в сети, функционирующей на базе широковещательных рас-
сылок. Данный способ (хоть он и применяется редко) позволяет сконфигуриро-
вать шлюзы в поддерживающей широковещательные рассылки сети (например,
Ethernet или Token-Ring) таким образом, что в их распоряжении имеются дан-
ные о соседях. Эго позволяет шлюзам отправлять свои корректировки не в ши-
роковещательной рассылке, а с помощью ориентированных дейтаграмм.

•	Конфигурирование на RIP-устройствах фильтров обновления маршрутной инфор-
мации (route update filters). Этот способ, по всей вероятности, является наиболее
употребительным и эффективным способом минимизации потока сообщений об
обновлении. Конфигурирование фильтров обновления маршрутной информации
на RIP-усгройствах позволяет выполнять на интерфейсе фильтрацию входящих
и исходящих корректировок (inbound, outbound updates). Такие фильтры, как пра-
вило, состоят из разрешающих или отклоняющих операторов (permit, deny
statements), которые разрешают или запрещают прием или передачу маршрутной
информации. Поскольку в каждую дейтаграмму RIP может быть включено не
более 25 маршрутов, шлюз, которому нужно объявить 27 маршрутов, должен от-
править два широковещательных сообщения RIP. Если бы можно было отфильт-
ровать 2 из существующих 27 маршрутов, то количество отправляемых в данном
случае широковещательных сообщений сократилось бы ровно наполовину. Кон-
кретная реализация таких программных фильтров зависит от поставщика продук-
ции.

Протокол RIP и каналы связи, выделяемые по
требованию

Протокол RIP использует выделяемые по требованию каналы связи (demand circuits),
или каналы связи глобальных сетей (такие как каналы сетей ISDN и Х.25) для того, чтобы
обеспечить необходимую ширину полосы пропускания для прохождения трафика в сети.
Эта задача решается посредством подключения канала связи между удаленными узлами
сети в случае возникновения необходимости в передаче данных и отключения этого
канала в случае, когда такая необходимость отпадает. Применение выделяемых по тре-
бованию каналов связи наиболее целесообразно, если происходит передача небольшого
объема данных между удаленными узлами, либо такая передача данных выполняется от
случая к случаю. Выделяемые по требованию каналы связи можно .также использовать
в качестве резервных каналов в случае отказа основного канала.
Специальные выделенные каналы связи активизируются только в случае необходи-
мости и прекращают свою работу, когда такая необходимость отпадает Следовательно,
применение этих каналов сохраняет сетевые ресурсы и сокращает затраты на поддер-
жание сети в рабочем состоянии. Однако временный характер каналов связи, выделяе-
мых по требованию, не позволяет использовать их с протоколами динамической марш-
рутизации. Когда функционирование выделенного канала связи приостанавливается,
шлюзы не имеют возможности обмениваться маршрутной информацией и эта инфор-
мация может быть утеряна. Не имея в своем распоряжении маршрутных данных, марш-
рутизаторы не в состоянии осуществить обмен данными между узлами сети.

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

Модификации протокола RIР (доработка его дополнительных возможностей) позво-
ляют использовать динамические протоколы маршрутизации для маршрутизации тра-
фика на выделяемых по требованию каналах связи. В RFC 2091 представлено описание
одной из таких доработок — механизма триггерных операций обновления (triggered
updates), который предоставляет протоколу RIP возможность поддерживать динамичес-
кую маршрутизацию на выделяемых по требованию каналах связи. Триггерное обнов-
ление — эго обновление маршрутной информации, вызванное каким-либо событием, а
не инициированное таймером периодического обновления.

Шлюзы также применяют в своей работе механизм триггерного обновления марш-
рутной информации. Как упоминалось ранее в данной главе, использование конфигу-
рационных параметров соседних маршрутизаторов на каждом шлюзе, подключенном к
данному каналу' связи, позволяет обеспечить обмен сообщениями об обновлении мар-
шрутной информации. Поскольку шлюз имеет в своем распоряжении спецификации
каждого своею соседа, он может с помощью протокола RIP отправлять сообщения о
корректировке маршрутов, направленные непосредственно находящемуся на другом
конце линии связи шлюзу. При этом нет необходимости в использовании широковеща-
тельных рассылок. Применительно к выделяемым по требованию каналам связи триг-
герное обновление может быть вызвано следующими событиями:

•	При инициализации шлюза запрашивается информация об обновлении маршру
тов. В этом случае полностью транслируется вся таблица маршрутизации.

•	В сети происходит какое-либо изменение. В этом случае передается только каса-
ющаяся происшедших изменений информация.

•	Переход канала связи из активного в пассивное состояние и наоборот. Такие из-
менения состояния канала связи возможны при включении или отключении (по
необходимости) питания шлюза.

Некоторые реализации предполагают также наличие механизмов, позволяющих уда-
ленным шлюзам, подключенным к выделенным каналам связи, хранить на постоянной
или полупостоянной основе маршрутную информацию, полученную в тот момент, ког-
да данный канал связи был активизирован. Например, компания Cisco реализует в сво-
их сетях процедуру маршрутизации с использованием копий таблиц маршрутизации
(Snapshot .'outing). Как видно по самому названию ("snapshot" — мгновенный снимок,
кадр. — Прим, иереи.), подключенные к каналу связи шлюзы делают мпзовенный сни-
мок таблицы маршрутизации после обмена маршрутной информацией. Затем шлюзы
используют эти снимки для дальнейшей маршрутизации трафика, обраба гывая получен-
ную информацию статически в то время, когда канал связи находится в заблокирован-
ном состоянии. Такой метод позволяет маршрутизаторам получить сведения об удален-
ных сетях и маршрутах к ним. Копии таблиц маршрутизации позволяют маршрутизаторам
хранить информацию и использовать ее даже в тот момент, когда каналы связи недо-
ступны.

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

Передача маршрутной информации по выделенным каналам связи в процессе трш-
герного обновления требует особого формата передаваемых пакетов данных, Существу-
ет три дополнительных типа пакетов данных для передачи RtP-сообшений; сообщения
этих трех типов передаются в кадре с расширенным на 4 байта заголовком. Обе версии
протокола R.JР — как RIPvl, так и RIPv2, поддерживают гри дополнительных типа па-
кетов данных и расширенный формат заголовка RIP.

На рис. 6.8 показан формат сообщений RIP грех дополнительных типов об имею-
щем место на выделяемых по требованию каналах связи три! терном обновлении марш-
рутной информации. В таблице 6.2 представлено описание дополнительных типов па-
кетов данных.

РИСУНОК 6.8

Передачи пакетов данных
тоех дополнительных
типов по выделенным
каначам связи требует
расширения заголовка RIP
на 4 байта.

Команда	Версия	Ноли
	Заголовок сообщения об ъбнтырниг	
Адрес семейства адресов		| Ноли (RIP) или Тег маршрута (RIPvZ)

Строки RIP-таблицы

Версия |	Ноли

Версия | Выравнивание | Порядковый номер

Таблица 6.2 Типы RIP-сообщений, передаваемых по выделенным каналам связи

Тип пакета	Описание
9 (запрос)	Отправляется шлюзами с целью получения данных об обновлении маршрутов
10 (ответ)	Отпра тяется в ответ на запрос В это сообщение включается либо вся таблица маршрутизации, либо голько измененные маршруты, в зависимости от того, какой был исходный запрос.
11 (подтверждение)	Отправляется с целью подтверждения о получении обновленной маршрутной информации, содержащейся в ответной дейтаграмме.
В отличие от нс ориентированных на соединение локальных широковещательных
рассылок, процедуры упорядочивания (sequencing) и подтверждения получения данных
(acknowledgement) содействуют отслеживанию обмена маршрутными данными на выде-
ляемых по требованию каналах. Во всех RIP-ответах (тип пакета данных — 10) содер-
жатся порядковые номера. Каждый очередной RlP-ответ имеет порядковый номер, на
единицу больший предыдущего. Шлюзы, получающие эти ответы, должны подтвердить
получение передаваемой в указанных сообщениях маршрутной информации. В подтвер-
ждении должен быть указан соответствующий порядковый номер принятого RlP-отве-
та. Дейтаграммы, получение которых не засвидетельствовано соответствующим подтвер-
ждением получения, рассматриваются шлюзами как утерянные; при этом предполатается,
что отправитель таких дейтаграмм должен передать их повторно.

Протокол RIPv2

RFC 2453 определяет протокол RlPv2 как расширение исходной версии — RIPvl
(описанной и RFC 1058) Версия RlPv2 протокола R1P функционирует аналогично вер-
сии RIPvl, но имеет существенные дополнения.

Версия RlPv2 была разработана для того, чтобы восполнить некоторые недостатки
версии RIPvl. По этой причине в RIPv2 включены такие усовершенствованные харак-
теристики, как аутентификация (authentication) и поддержка разбиения сети на подсети
(subnetting). Некоторые компании не применяют протокол RI Pv2 для обслуживания
своих сетей; в го же время другие компании начали использовать именно версию RlPv2
в случаях, когда нужен протокол R1P (например, для обеспечения работы РГХ-бранд-
мауэра (Р1Х firewall), аппаратно-протраммных средств межсетевой защиты, реализован-
ных в блоке расширения параллельного интерфейса). Эти компании используют прото-
кол RlPv2 также и в случае, когда им нужен протокол, распознающий маски подсетей
(VLSM). Другие протоколы маршрутизации, такие как протоколы маршрутизации по
состоянию каналов связи, также были разработаны с целью компенсации недостатков
RIPvl. Эти протоколы предлагают намного более подходящие критерии выбора марш-
рута, а также более эффективное использование полосы пропускания и более высокую
скорость сходимости, чем протокол RIPv2.

Сравнительная характеристика протоколов RIPvl и RIPv2

Сравнительная характеристика протоколов RIPvl и RIPv2 представлена в таблице 6.3.

Таблица 6.3 RIPvl в сравнении с RIPv2_______________________________________________

RIPvl	RlPv2
Только широковещательные рассылки	Широковещательные или многоадресные рассылки
Нет аутентификации	Аутентификация
Маршрутизация по классам адресов	Бесклассовая маршрутизация
Принадлежность к категории дистанционно-векторных протоколов	Принадлежность к категории ди стан ционно-веигорных протоколов
Использование количества транзитов в качестве параметра выбора оптимального маршрута	Использование количества транзитов в качестве параметра выбора оптимального маршрута
RIPvl	RlPv2
Максимально допустимое расстояние до пункта назначения — 15 транзитов	Максимально допустимое расстояние до пункта назначения — 15 транзитов
Принадлежность к классу протоколов IGP	Принадлежность к классу протоколов IGP

На рис. 6.9 показан формат заголовка RlPv2.

РИСУНОК 6.9

В заголовок RIPv2 входит
поле маски подсети (Subnet
Mask) и поле следующего
транзита (Next Нир): в
заголовке RJPvI эти поля
заполнены нолями.

Может
повторяться
до 25 раз

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

Протокол RIPvl не поддерживает аутентификацию, другими словами, он не имеет
средств идентификации партнера по коммуникации. В отличие от RIPvl, в протоколе
RlPv2 предусматривается использование произвольно выбранных текстовых паролей для
обеспечения защиты (низкого уровня) от несанкционированного доступа во время об-
мена информацией между шлюзами

На рис. 6.10 представлен формат пакета данных RlPv2, в заголовок которого вклю-
чено поле аутентификации (Authentication). В случае включения поля аутентификации
в заголовок RIPv2 максимальное количество строк RIP-таблицы сокращается до 24.
Следует обратить внимание на то, что при этом в .поле идентификатора семейства адре-
сов (Address Family Identifier) указывается значение FFFFH, а поле тега маршрута (Route
Tag) идентифицирует тип аутентификации.

РИСУНОК 6.10

Протокол RIPv2 поддерживает
аутентификацию, протокол
RIPvl не предоставляет
никаких средств защиты
данных от
несанкционированного доступа.

Команда | Версия	Ноли
FFFFH	Тип аутентификации
Информация об аутентификации (16 октетов)	

Строки RIP-таблицы (максимум 24)

Включение данных о маске подсети в объявления о маршрутах делает возможной
бесклассовую маршрутизацию. Когда протокол RlPv2 объявляет свою маршрутную ин-
формацию соседям, он включает в сообщение не только адреса известных ему сетей, но
и маски подсетей каждой сети. Имея в своем распоряжении такую информацию, при-
нимающий объявление о маршруте шлюз может определить, входят ли подсети в состав
сети назначения.

Возможности протокола RlPv2 не ограничены распознаванием только классов адре-
сов. Поддержка VLSM позволяет достаточно просто определить, является ли тот или иной
адрес адресом сети или адресом подсети, и объявить эту информацию соседним устрой-
ствам.

Совместимость RIPv2 и RIPvl

Протокол RiPv2 считается обратно совместимым с RIPvl, а это значит, что RIPv2
может выполняться на шлюзах, обслуживающих RIPvl. Однако для того, чтобы шлюзы
RIPvl и шлюзы RIPv2 могли обмениваться информацией, они должны использовать
"наименьший обший знаменатель" — те общие характеристики, которые свойственны
обеим версиям протокола RIP: только широковещательные рассылки сообщений, отсут-
ствие аутентификации и маршрутизация по классам адресов. Безусловно, это не позво-
ляв! в полной мере использовать преимущества RIPv2.

Если в одной и той же подсети реализованы оба протокола — RIPvl и RIPv2, обслу-
живающие RIPv2 устройства в своей работе должны стоою соответствовать ста1 аартам
и ограничениям RIPvl. Когда же одно из поддерживающих RIPv2 устройств подключа-
ется через другой интерфейс к равноправному RlPv2-ycrpoiicTBy подсети, то для обме-
на маршрутной информацией используется протокол RlPv2. Конфигурирование RIPvl
и RlPv2 зависит от конкретной реализации и технических условий, задаваемых постав-
щиками, но, как правило, это конфигурирование выполняете?} на поиптерфеисной ос-
нове. т.е. по одному интерфейсу на каждый протокол.

Протокол OSPF

Как было отмечено в главе 5, работа протокола OSPF (Open Shortest Path First, Про-
токол поиска кратчайшего пути! построена на использовании алгоритма определения
оптимального маршрута по состоянию каналов связи (LSA, Link-state Algorithm). Из этого
следует, что протокол OSPF осуществляет более интеллектуальный выбор маршрута, чем
дистанционно-векторные протоколы маршрутизации (Distance-vector routing protocols).
Принятие решения о выборе маршрута протокол OSPF, аналогично другим протоколам
маршрутизации по состоянию каналов связи (1 ink-state routing protocols), основывает на
сл еду ю ш иг. хара к г ери сти ках:

•	Производительность полосы пропускания капала связи (bandwidth capacity of а
link)

•	Задержка (delay)

•	Надежность (reliability)

•	Нагрузка (load)

•	МТ U, Максимальный модуль пересылки (maximum transmission unit)

ПРИМЕЧАНИЕ

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

В дополнение к сказанному выше следует отметить, что протокол OSPE обеспечива -
ет ряд преимуществ над дистанционно-векторными протоколами маршрутизации. В
число этих преимуществ входят следующие характеристики протокола OSPT.
•	Протокол OSPF имеет в своем распоряжении средства конфигурирования иерар-
хических маршрутных доменов (hierarchical routing domains), в отличие от неструк-
турированных доменов (как в других протоколах), посредством разбиения авто-
номной системы на организованные но иерархическому принципу области. Это
позволяет локализовать происходящие в сеги изменения, маршрутизировать по-
ток сообщений об обновлении маршрутной информации в различные сегменты
сети, а также сократить непроизводительные затраты, связанные с многократным
вычислением маршрутов и внесением корректировок в таблицы маршрутизации.

•	Протокол OSPF имеет возможность быстро адаптироваться к происходящим во
время межсетевого обмена маршрутной информацией изменениям, вызванным
процедурой триггерного обновления.

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

•	Протокол OSPF поддерживает большие сеги.

•	Протокол OSPF поддерживает выравнивание нагрузки (load balancing), или раз-
деление трафика по резервным маршрутам с эквивалентной и неэквивалентной
стоимостью с целью увеличения оошей производительности

	Протокол OSPF обеспечивает аутентификацию (authentication) обмена маршрут-
ной информацией.

•	Протокол OSPF поддерживает маски подсети (VLSM, Variable Length Subnet Mask —
маска подсети переменной длины)

•	Протокол OSPF строит свою работу преимущественно на основе многоадресных
(а не широковещательных) рассылок сообщений об обновлении маршрутной ин-
формации.

OSPF принадлежит к категории протоколов внутренней маршрутизации (IGP, Interior
Gateway Protocol). Следовательно, он может обслуживать работу сетей разных размеров
(от средних до больших сетей), входящих в состав одной автономной системы. В Дан-
ном контексте управляемая протоколом OSPF автономная система — это организован-
ная по иерархическому принципу сеть какой-либо ор1анкзации, которая состоит из одной
или нескольких областей OSPF и маршрутизаторов, осуществляющих маршрутизацию
графика в этих областях и между ними.

Протокол OSPF был разработан комитетом IETF (Internet Engineering Task Force,
Рабочая группа разработки стандартов Интернета) Первая версия OSPF описана в RFC
1247; подробную информацию о доработанной версии протокола OSPF можно найти в
RFC 1 583. Сообщения OSPF передаются непосредственно в дейтаграммах IP с указани-
ем в поле типа протокола (Protocol Туре) заголовка IP значения 89, соответствующего
протоколу OSPF.

Маршрутизация пакетов данных протоколом OSPF осуществляется на основании
логического адреса пункта назначения на сетевом уровне (logical Network layer address),
а также на основании значений битов, установленных в поле типа обслуживания (ToS,
Type of Service) заголовка IP. Это позволяет протоколу OSPF обеспечить уровень каче-
ства маршрутизации (QoS, Quality of Service), соответствующий требованиям приложе-
ний и сервисов верхних уровней. Маршрутизаторы OSPF оперативно обнаруживают
вышедшие из строя маршруты и адаптируются к происшедшим в сети изменениям. Когда
маршрутизатор обнаруживает повреждение канала связи, он активизирует механизм
триггерного обновления, охватывающего все маршрутизаторы в пределах данной обла-
сти OSPF, с целью их оповещения об имевшем место повреждении. В отличие от про-
токола OSPF, дистанционно-векторные протоколы маршрутизации отправляют свои
сообщения об обновлении маршрутной информации только после истечения периода
времени, предписанного таймером обновления. При возникновении той или иной про-
блемы протокол OSPF незамедлительно формирует многоадресное объявление и рас-
сылает его по всем OSPF-портам, информируя все маршрутизаторы данной области OSPF
о вышедшем из строя канале связи. Все маршрутизаторы вычисляют новые маршруты в
соответствии с произошедшими изменениями параллельно, что существенно ускоряет
период сходимости (convergence), или согласования маршрутизаторами содержимого
своих баз данных.

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

Характеристики протокола OSPF

Протоколу OSPF свойственны следующие характеристики:

•	Многоадресная рассылка сообщений (multicast). Протокол OSPF поддерживает
многоадресную рассылку сообщений об обновлении: по адресу 224.0.0.5 для всех
маршрутизаторов OSPF; по адресу 224.0.0.6 для управляющего маршрутизатора
(DR, designated router) и резервного назначенного маршрутизатора (BDR, backup
designated router).

•	Быстрая сходимость (fast convergence). Протокол OSPF обеспечивает быстрое
согласование маршрутной информации посредством немедленной потоковой рас-
сылки сообщений об обновлении (flood updates) сразу же после того, как в сети
произошло какое-либо изменение. Протокол OSPF поддерживает также парал-
лельное вычисление маршрутизаторами оптимального пути к пункту назначения.

•	Триггерное обновление маршрутной информации (triggered updates). Поддержи-
ваемый протоколом OSPF механизм триггерного обновления позволяет маршру-
тизаторам рассылать корректировки сразу же после того, как в сети происходит
какое-либо событие.

•	Бесклассовая маршрутизация (classless routing). Протокол OSPF поддерживает
маски подсети переменной длины (VLSM) и, следовательно, обеспечивает бесклас-
совую маршрутизацию данных.

•	Тип сервиса (ToS) или качество сервиса (QoS). Протокол OSPF предоставляет
маршрутизаторам возможность выполнять пересылку данных в пункт назначения
на основании требований, предъявляемых приложениями к уровню сервиса.

•	Аутентификация (authentication). Протокол OSPF поддерживает простейший уро-
вень зашиты данных от несанкционированного доступа, обеспечивая маршрути-
заторы возможностью применять защиту с помощью паролей (password protection).
Аутентификация позволяет маршрутизаторам OSPF обмениваться маршрутной ин-
формацией только с теми маршрутизаторами, которые имеют санкционирован-
ный доступ к ней.

•	Эквивалентные и неэквивалентные по стоимости маршруты (equal- and unequal-
cost routes). Маршрутизаторы OSPF имеют возможность направлять дейтаграм-
мы по резервным эквивалентным (имеющим одинаковую стоимость) и неэкви-
валентным (имеющим неодинаковую стоимость) маршрутам к пункту назначения
для того, чтобы распределить трафик по нескольким маршрутам с целью увели-
чения производительности.

•	Области (areas). Протокол OSPF может функционировать как в сети, состоящей
из единой области, так и в автономной системе со сложной иерархической струк-
турой, разделенной на множество областей. Разбиение автономной системы на
области OSPF сокращает объем трафика обновления. База данных маршрутиза-
ции для хранения сведений о состоянии каналов связи (Link-stale database) и расчет
маршрута на основании алгоритма поиска кратчайшего пути (SPF, Shortest Path
First) рассматриваются более подробно ниже в данной главе.

Протокол OSPF поддерживает механизм распознавания масок подсети переменной
длины (VLSM) посредством включения масок подсети в сообщения OSPF об обновле-
нии маршрутной информации. В отправляемые маршрутизаторами OSPF объявления
включаются не только данные о сети или хосте назначения, но и маска подсети, позво-
ляющая получателю сообщения определить, является ли полученный им адрес IP-адре-
сом хосга, сети или подсети.

Поскольку протокол OSPF распознает биты поля типа обслуживания (ToS, Type of
Service) заголовка IP, он может обеспечить требуемый согласно значениям этих битов
тип сервиса. При этом маршрутизаторы OSPF направляют дейтаграммы в пункт назна-
чения по маршрутам, рассчитанным на основании запрашиваемого приложением уров-
ня или качества сервиса Поддержка протоколом OSPF специфицируемого в поле ToS
заголовка IP типа сервиса зависит от конкретной реализации.

В большинстве случаев протокол OSPF осуществляет выбор кратчайшего маршрута
к пункту назначения на основании следующих показателей:

•	Полоса пропускания канала (bandwidth)

•	Задержка (delay)

•	Надежность (reliability)

•	1 lai рузка (load)

•	Максимальный модуль пересылки (MTL, Maximum transmission unit)

Маршрутизаторы OSPF могут выполнять вычисление маршрутов с использованием
всех этих показателей, но по умолчанию (до тех нор, пока маршрутизатор не будет спе-
циально сконфшурирован соответствующим образом) маршрутизаторы принимают ре-
шение о выборе маршрута на основании полосы пропускания канала. Протокол OSPF
предоставляет возможность выбора тою или иного показателя в качестве основы для
принятия решения о выборе маршрута. По значению соответствующей метрики можно
определить оптимальный маршрут: чем меньше стоимость пути, тем лучше сам марш-
196 Глава в

рут Сетевой администратор может сконфи!урировать различные показатели оценки
стоимости пути на разных интерфейсах одного и гою же маршрутизатора. Если к пун-
кту назначения существует несколько путей с различными метриками, маршруты с наи-
меньшей стоимостью размещаются в таблице маршрутизации в качестве предпочтитель-
ных маршрутов к адресату. Когда необходимо выполнить маршрутизацию данных
согласно различным типам IP-сервиса, маршрутизаторы включают в таблицу маршру-
тизации несколько путей к пункту назначения: чо одному маршруту на каждый тип сер-
виса (ToS). Когда к пункту назначения существует множество путей с одинаковой сто-
имостью, маршрутизаторы могут распределить передачу дейтаграмм по этим маршрутам
(эта процедура называется выравниванием рабочей нагрузки, load balancing).

Базы данных протокола OSFF

Для обеспечения успешной маршрутизации данных каждый маршрутизатор OSPF
создает и обслуживает три независимых базы данных:

•	База данных для хранения сведений о смежных маршрутизаторах (Adjacency
database) другими словами, таблица сведений о соседях (neighbor table).

•	База данных для хранения сведений о состоянии каналов связи (Link-state database)
— другими словами, карта топологии области OSPF (topology map).

•	База данных для хранения маршрутной информации о передаче данных в пункт
назначения (Forwarding database) — друшми словами, таблица маршрутизации
(routing table).

База данных для хранения сведений о смежных маршрутизаторах

Перед началом сбора информации о маршрутах и обмена полученными маршрутны-
ми данными с другими устройствами маршрутизатор OSPF в первую очередь должен
установить отношения смежности (adjacency) с сопредельными маршрутизаторами, вхо-
дящими в состав гою же локальною сегмента сети. Следует отметить, что смежными
являются не все пары маршру гизаторов. а только те, которые согласуют содержимое
своих баз данных. При отсутствии отношений смежности маршрутизатора с соседними
устройствами этот маршрутизатор не может принимать участие в прсцессе OSPF-мар-
шру гизации.

Для формирования отношений смежности во время инициализации OSPF- маршру-
тизатора выполняются следующие действия:

1.	OSPF-маршруги затор отправляет в локальной многоадресной рассылке приветствен-
ные пакеты (Hello packets), направленные всем соседним устройствам для того, чтобы
проинформировать их о своем существовании. В состав Hello-пакета входит соб-
ственно приветственное сообщение и ряд дополнительных параметров: маска под
сети, период отправки сообщения Hello и другие параметры.

2.	OSPF-маршрутизаторы, принимающие Hello-пакет, включают новый маршрут в свои
Ьазы данных для хранения сведений о смежных маршрутизаторах. Далее маршрути-
заторы отвечают на полученное приветствие своим собственным Hello-пакетом для
того, чтобы можно было установить отношения соседства.
Все соседние устройства должны иметь информацию друг о друге; они также долж-
ны сформировать отношения соседства между собой. Подобный процесс формирования
взаимосвязей между маршрутизаторами достаточно прост, поскольку он заключается
всею лишь в согласовании входящих в состав Hello-пакетов ключевых параметров между
маршрутизаторами данной области OSPF. Если же такого согласования нет, отношения
смежности между соседними маршрутизаторами не устанаДтваются. Приветственный
пакет, а также другие типы пакетов рассматриваются ниже в данной главе.

База данных для хранения сведений о состоянии каналов связи

Маршрутизаторы OSPF могут начинать создание базы данных для хранения сведе-
ний о состоянии каналов связи (Link-state database) в тот момент, когда они получают
информацию о партнерах по процессу обмена маршрутной информацией. Такая база
данных представляет собой детальную карту межсетевой топологии области OSPF, ко-
торая идентифицирует каждую сеть и каждую подсеть этой области, а также маршрут к
каждой их них. На основе такой базы данных каждый маршрутизатор создает дерево
кратчайших путей —древовидную структуру, корнем которой (соединенным с каждым
пунктом назначения самым коротким маршрутом) является он сам.

База данных для хранения маршрутной информации

База данных для хранения маршрутной ин&ормации (Forwarding database), другими
словами таблица маршрутизации, строится на основе базы данных для хранения сведе-
ний о состоянии каналов связи (Link-state database). Когда каждый маршрутизатор по-
лучает в свое распоряжение подробную шарту топологии области, он может начать вы-
числение оптимального пути к каждому пункту назначения на основе алгоритма поиска
кратчайшего пути (SPF, Shortest Path First). Далее обнаруженные маршруты размеща-
ются в локальной таблице маршрутизации с целью дальнейшей передачи пакетов дан-
ных в пункты назначения.

Действие протокола OSPF

Протокол OSPF может поддерживать сети, с различной архитектурой на канальном
уровне, а именно — на основании соединений локальных или глобальных сетей То, как
происходит процесс формирования отношений смежности между маршрутизаторами и
обмен сведениями, содержащимися в их базах данных, зависит от архитектуры сети, в
которой выполняется протокол OSPF. Данный раздел текущей главы посвящен функ-
ционированию протокола OSPF в сетях с базирующейся на архитектуре широковеща-
тельных локальных сетей.

Сети со сложной иерархической архитектурой рассматриваются ниже в данной гла-
ве.

Рассмотрим действие протокола OSPF в рамках единой (нс разделенной на сос рав-
ные части) области. Когда в наличии имеется всего одна область, термины "автономная
система OSPF" и "область OSPF" имеют одно и го же значение. Все маршрутизаторы
такой области OSPF работают с одним экземпляром базы данных для хранения сведе-
ний о состоянии каналов связи (см. рис.6.11) Когда в состав автономной системы вхо-
дит несколько областей OSPF, маршрутизаторы каждой из областей поддерживают от
дельные базы данных для каждой из них.
РИСУНОК 6.11

При реализации протокола
OSPF = автономной
системе, состоящей из
одной неделимой области,
входящие в эту область
маршрутизаторы
поддерживают три базы
данных: карту топологии
области (topology тар),
таблицу сведений о соседях
(neighbor table) и таблицу
маршрутизации (routing
table).

Действие протокола OSPF в одной
неделимой области

Существует шесть типов генерируемых протоколом OSPF объявлений о состоянии
каналов связи (LSA, Link-state advertisements). Эти объявления можно разделить на три
категории:

•	Внутриобластные объявления (Intra-area advertisements)

•	Межобластные объявления (Inter-area advertisements)

•	Внешние (по отношению к данной автономной системе) объявления (External
advertisements)

Каждая из этих категорий характеризует тип объявления и сферу его распростране-
ния. В таблице 6.4 представлено описание шести различных типов объявлений OSPF о
состоянии каналов связи (LSA).

Таблица 6.4 Типы объявлений протокола OSPF о состоянии каналов связи

Тип объявления о состоянии канала	Название (тип) объявления	Описание
1	Объявление о связях маршрутизатора — внутриобластное (Router link advertisement — intra-area)	Содержит сведения о состоянии каналов маршрутизатора, связывающих его с другими входящими в состав той же сети устройствами, а также сведения о состоянии всех интерфейсов маршрутизатора
2	Объявление о сетевых связях — внутриобластное (Network link advertisement rnKa-area)	Содержит список всех маршрутизаторов, подключенных к конкретной локальной сети
3	Итоговое объявление о связях — межобластное (Summary link advertisement — inter-area)	Содержит список маршрутов из подобласти маршрутизатора в сеть, находящуюся вне дтн.юй области, но в пределах автономной системы
4	Итоговое объявление о связях — межобластное (Summary link advertisement — inter -area)	Содержит список маршрутов к внешним по отношению к данной автономной системе сетям, функционирующим не под управлением протокола OSPF, т.е. список маршрутов к границе данной автономной системы
Тип объявления о состоянии канала	Название (тип) объявления	Описание
5	Объявление о внешних связях	Содержит список маршрутов к пунктам  автономной системы — внешнее назначения, находящимся в другой (Autonomous system external link автономной системе advertisement — external)
7	Объявление о внешних связях	Содержит маршрутную информацию о  автономной системы — внешнее тупиковой сети (Autonomous system external link advertisement — external)

Внутриобластные объявления

Маршрутизаторы рассылают внутриобластные объявления (inlra-area advertisements)
в пределах одной области OSPF. Объявления такого типа распространяются только в той
области, в которой они были сформированы, и содержат сведения о локальных связях
маршрутизатора, а также информацию о сетях, входящих в состав данной области OSPF.
Маршрутизаторы выполняют потоковую рассылку объявлений типа 1 (объявления та-
кого типа могут быть сформированы любым маршрутизатором) и объявлений типа 2
(такие объявления могут генерировать только управляющие маршрутизаторы. DR).

Существует два типа внутриобластных объявлений:

•	Тип I (объявление о связях маршрутизатора, Router link advertisement)

•	Тип 2 (объявление о сетевых связях. Network link advertisement)

Маршрутизаторы отправляют объявления типа 1 по групповому адресу назначения
224.0.0.5 (т.е. по групповому адресу управляющих маршрутизаторов — DR, Designated
routers и резервных управляющих маршрутизаторов — BDR, Border designated routers).
В сообщениях типа 1 содержатся сведения о непосредственно соединенных с маршру-
тизаторами сетях, а также данные о состоянии интерфейсов, подключенных к этим се-
тям.

В локальных сетях (сетях с широковещательной адресацией) управляющий маршру-
тизатор рассылает объявления о состоянии каналов связи (LSA) типа 2 по адресу назна-
чения 224.0.0.6, т.е. по групповому адресу всех маршрутизаторов OSPF. Объявления типа
2 идентифицируют все маршрутизаторы, входящие в состав локальной сети.

На рис. 6.12 показан пример внутриобластного объявления LSA типа 1; на рис. 6.13
представлен пример внутриобластного объявления LSA типа 2.

Объявления о состоянии каналов связи, тип 1

РИСУНОК 6.12

Все маршрутизаторы
отправляют
внутриобластные
объявления LSA типи 1 по
групповому адресу
назначения 224.0.0.5.

Объявление о связях маршрутизатора "О* (OSPF)
 Отправляются всеми маршрутизаторами по адресу 224.С.0.5
РИСУНОК 6.13
Внутриобластные
объявления LSA типа 2
отправляются только
управляющим
маршрутизатором (DR)
всем маршрутизаторам
одного и того оке сегмента
сети.

Объявления о состоянии каналов связи, тип 2

Объявления о сетевых связях. nO' (OSPF)

* Отправляются только управляющими маршрутизаторами
(DR) по адресу 224.0.0.6

Межобластные объявления

Маршрутизаторы грани области (ABR, Area border routers) осуществляют передачу
межобластных объявлений (inter-area advertisements) между сопредельными областями
OSPF. В большинстве случаев маршрутизаторы грани (ABR) соединяют подобласти с
магистралью OSPF (областью 0), которая является основной транзитной областью для
передачи всего межобластного графика. В объявлениях такого типа содержится список
маршрутов, входящих в подобласть OSPF. Маршрутизаторы грани отправляют подоб-
ные объявления в область 0, где другие маршрутизаторы получают эту межобластную
информацию и передаю! ее в свои области.

Существует два типа межобластных объявлений:

•	Тип 3 (список маршрутов к пунктам назначения, находящимся вне области, но в
пределах данной автономной системы, Summary link advertisement — type 3)

•	Тип 4 (список маршрутов к пунктам назначения, находящимся вне данной авто-
номной системы. Summary link advertisement — type 4)

Маршрутизаторы 1рани (ABR) используют итоговые объявления для того, чтобы со-
единить свои подобласти с областью 0 (магистралью OSPF) кратчайшими маршрутами,
содержащимися в данном объявлении. Кроме того, маршрутизаторы грани используют
объявления LSA указанных выше типов для регистрации в своих базах данных обнару-
женные через область 0 маршруты из других подобластей в свою подобласть.

Маршрутизаторы !рани области (ABR) отправляют объявления LSA типа 4 с целью
идентификации маршрутизаторов границы автономной системы (ASBR, Autonomous
system boundary routers), которые обеспечивают доступ к работающим не под управле-
нием протокола OSPF сетям за пределами данной автономной системы.

На рис. 6.14 представлены примеры межобластных объявлений тина 3 и типа 4.

Внешние объявления

Внешние по отношению к данной автономной системе объявления (external
advertisements) могут быть сгенерированы только маршрутизаторами границы автоном-
ной области (ASBR). Объявления такого типа распространяются по всей автономной
системе, функционирующей под управлением протокола OSPF, за исключением тупи-
ковых областей (stub areas). Процедура маршрутизации в тупиковых областях рассмат-
ривается ниже в данной главе. В объявления LSA данного типа содержится информа-
ция о внешних по отношению к данной автономной системе маршрутах, обслуживаемых
не протоколом OSPF. Эти маршруты внедряются в среду OSPF для того, чтобы можно
было проинформировать все маршрутизаторы автономной системы о существовании
внешних но отношению к ней маршрутов и тем самым обеспечить связь с другими ав-
тономными системами. Поскольку внешние маршруты обслуживаются протоколом RJP,
протокол OSPF рассматривает информацию об этих маршрутах как внешнюю и соот-
ветственно объявляет внешней. Использование внешних маршрутов протоколом OSPF
находится вне рассмотрения данной книги, а конфигурирование этих маршрутов зави-
сит от конкретной реализации. В настоящей книге есть только ссылки на внешние мар-
шруты как на любые другие маршруты, вычислить которые своими средствами прото-
кол OSPF не имеет возможности.

РИСУНОК Ь.14

Маршрутизаторы грани
области (АВИ) используют
в своей работе
межобластные итоговые
объявления LSA типи 3 и 4.

Итоговые объявления LSA: "IA” — lnlcr-Лгэа, ыежобласгные объявления
 Объявления типа 3: направляются маршрутизаторами грани области в
область 0 с итоговой сводкой (списком) всех маршрутов потальной по
отношению к этим маршрутизаторам области

 Объявления типа 4: используются для обнаружения маршрутов к
маршрутизаторам границы автономной системы (ASBR)

(ABR) - ABR, Маршрутизатор грани области

(ASBR) - ASBR, Маршрутизатор границы автономной системы

Существуе г два шва внешних обьявлений о состоянии каналов связи:

•	Тип 5 (внешнее объявление, содержащее сведения о внешних по отношению к
данной автономной системе связях. Autonomous system external link — type 5)

•	Тип 7 (внешнее объявление, позволяющее передавать информацию по тупиковой
области, Autonomous system external link — type 5)

Объявления LSA типа 5 могут передаваться только маршрутизаторами границы
автономной системы (ASBR), которые поддерживают более одного протокола ма шру-
тизацни, а именно — протоколы OSFF, RIP, IGRP, EIGRP, а также протоколы 'готи-
ческой маршрутизации. Сетевой администратор может сконфигурировать OSPF-марш-
рутизагоры ASBR таким образом, чтобы можно было внедрять не управляемые
протоколом OSPF маршруты в среду OSPF. Объявления LSA типа 5 позволяют проин-
формировать все области и маршрутизаторы OSPF той или иной автономной системы о
существовании внешних по отношению к этой АС маршрутов.

Обьявления LSA типа 7 могут передаваться только маршрутизаторами границы ав-
тономной области (ASBR), соединенными непосредственно с 1ак называемой "не совсем
тупиковой" областью (NSSA, "not so stubby area"), которая рассматривается более под-
робно ниже в данной главе. Эти маршрутизаторы должны также поддерживать более од-
ного протокола маршрутизации, а именно — OSPF, RIP, IGRP, E1GRP, протоколы ста-
тической маршрутизации и т.д. Можно сконфигурировать OSPF-маршрутизаторы ASBR
таким образом, чтобы они имели возможность принимать не обслуживаемые протоко-
лом OSPF маршруты и внедрять их в среду OSPF, относящуюся к области NSSA посред-
ством объявлений LSA тина 7, специально разработанным для передачи информации
через тупиковые области. Маршрутизатор 1рани области (ABR), соединенный с облас-
тью 0, выполняет преобразование обьявлсния LSA типа 7 в объявление LSA типа 5 пе-
ред передачей информации в магистральную область.

На рис. 6.15 показан пример внешнего объявления LSA типа 5: на рис. 6.16 пред-
ставлен пример внешнего объявления LSA типа 7.

РИСУНОК 6.15

Маршрутизаторы границы
автономной системы
(ASBR) отправляют
сообщения LSA типа 5 с
целью объявления внешних
по отношению к данной
автономной системе
маршрутов, не
обслуживаемых протоколом
OSPF.

РИСУНОК 6.16
Как и в случае с
объявлениями LSA типа 5.
маршрутизаторы границы
автономной системы
(ASBR) используют
объявления LSA типа 7 для
передачи сообщений об
обновлении сформированных
не протоколом OSPF
внешних маршрутов через
область NSSA в базовую
область.

Заголовок LSA

Объявления о состоянии каналов связи, тип 5

Внешние по отношению к данной автономной снегомо объявлении Е1 и Е2

• Отправляются маршрутизатором ASBR, используются для идентификации
маршрутов к сетям, находящимся во внешних автономных системах

ABR - ABR, Маршрутизатор грани области

ASBR - ASBR, Маршрутизатор границы автономной области

Объявления о состоянии каналов связи, тип 7

Внешние по отношению к данной автономной системе объявления

• Передаются только маршрутизатором ASBR через область NSSA с
целью объявления внешних по отношению к данной автономной области маршрутов

ABR - ABR, Маршрутизатор грани области

ASBR - ASBR, Маршрутизатор границы автономной области

Пакет, содержащий описание баз данных (Database Description packet), может вклю-
чать в себя одно или более объявлений о состоянии каналов связи (LSA). Каждый заго-
ловок LSA, имеющий длину 20 байтов, имеет один и тот же формат. Формат заголовка
дейтаграммы OSPF, содержащей объявление LSA (сокращенно - заголовка LSA), пред-
ставлен на рис. 6 17.

РИСУНОК 6.17

Заголовок LSA протокола
OSPF содержит 2D байтов
информации.

Возраст LSA | Дополнительные параметры | Тил LSA	
Идентификатор передающего LSA устройства	
Маршру-изатор-источник LSA	
Порядковый номер LSA	
Контрольная сумма LSA	Длина ISA
Поля заголовка LSA рассматриваются в последующих разделах текущей главы.

Поле возраста LSA

В поле возраста объявления LSA (LS age) содержится значение, измеряемое в секун-
дах, которое показывает период времени, прошедший с того момента, когда источник
сообщения отправил LSA.

Поле дополнительных параметров

В поле дополнительных параметров (Options) устанавливаются те же значения, ко-
торые содержатся в приветственном пакете. Hello-пакеты рассматриваю гея ниже в дан-
ной главе.

Поле типа LSA

Поле типа LSA (LS type) задает тип передаваемого объявления о состоянии каналов
связи: внутриобластное объявление (тип 1 и 2), межобластное объявление (тип 3 и 4)
или внешнее объявление (тип 5 и 7).

Поле идентификатора передающего LSA устройства

Значение, устанавливаемое в поле идентификатора передающего LSA устройства
(Link-slate ID), идентифицирует либо IP-адрес отправителя LSA (в случае передачи LSA
типа 1 и 4), либо IP-адрес сети, сведения о которой содержатся в LSA (в случае переда-
чи LSA типа 2, 3, 5 или 7). Какую конкретно информацию идентифицирует значение
данного поля, зависит от типа LSA. В таблице 6.5 представлено описание всех существу-
ющих идентификаторов передающих LSA устройств.

Таблица 6.5 Идентификаторы передающего ISA____________________________________

Значение

идентификатора Описание_______________________________________________________

1	Идентификатор подчиненного маршрутизатора (Slave router ID)__

2	Идентификатор управляющего маршрутизатора (DR)	 

3	IP-адрес сети назначения, сведения о которой содержатся в текущем

_________________объявлении LSA	
4 Идентификатор маршрутизатора границы автономной	системы (ASBR)

5	IP-адрес сети назначения, сведения о которой содержатся в текущем

объявлении 1SA  	 

Поле маршрутизатора-источника LSA

Поле маршрутизатора-источника (Advertising Router) идентифицирует маршрутиза-
тор, который является отправителем объявления о состоянии каналов связи.

Поле порядкового номера LSA

Использование в заголовке LSA поля порядкового номера объявления LSA (LS
Sequence Number) гарантирует доставку и получение пакетов, содержащих описание баз
данных OSPF. Каждый раз, когда OSPF-маршрутизатор передает объявление, отправи-
тель объявления включает в свою базу данных порядковый номер этого объявления,
идентифицирующий его. Пакеты с описанием содержимого баз данных рассматривают-
ся более подробно ниже в данной главе.
Поле контрольной суммы LSA

Поле контрольной суммы LSA (LS Checksum) позволяет проверить, не был ли по-
врежден во время передачи пакет с описанием содержимого баз данных.

Поле длины LSA

В поле длины 1 SA (Length) указывается длина (г байтах) дейта!раммы OSPF, в ко-
торой передается объявление о состоянии каналов связи.

Состояния маршрутизаторов OSPF

Как было упомянуто выше в данной главе, перед началом собственно процесса мар-
шрутизации каждый принимающий участие в пересылке данных маршрутизатор OSPF
в первую очередь должен сформировать отношения смежности (adjacency) с другими
маршрутизаторами (иначе говоря, установить соседские отношения с ними). Далее мар-
шрутизатор OSPF должен пройти еще несколько этапов подготовки к участию в про-
цессе маршрутизации. На каждой стадии такой подготовки маршрутизаторы находятся
в одном из следующих состояний:

1.	Пассивное состояние (Down state)

2.	Состояние инициализации |1пЯ state)

3.	Состояние двусторонней связи (Two-Way state)

4.	Предстгртавое состояние (Exstart state)

5.	Состояние обмена (Exchange state)

6	Состояние загрузки (Loading state)

7.	Состояние готовности (Full state)

Сущность событий, происходящих с маршрутизатором в тот момент, когда он нахо-
дится в первом или последнем состоянии подготовки к работе, достаточно проста и
понятна. Когда маршрутизатор находится в пассивном состоянии (Down state), это оз-
начает, что на данном маршрута шторе не активизирован протокол OSPF, или что про-
изошла перенастройка интерфейса этого маршрутизатора. Другими словами, маршру-
тизатор или вообще не имеет возможности активно участвовать в процессе обмена
маршрутной информацией, или он не активизирован только в текущий момент време-
ни по каким-либо причинам. Когда маршрутизатор оказывается в состоянии полной го-
товности (Full state), его таблица маршрутизации уже полностью согласована с другими
устройствами и он может начинать активную маршрутизацию дейтаграмм в пункты на-
значения. Ниже представлено подробное описание каждого из состояний OSPF-марш-
рутазаторов.

Состояние инициализации

Идентификация OSPF-маршрутизатора всеми соседними устройствами происходит
в момент активизации на нем протокола OSPF. Маршрутизатор OSPF сообщает свои
спецификации соседям с помощью многоадресной рассылки приветственной дейта!рам-
мы. На данной стадии отношения смежности между соседями еще нс установлены. На
рис. 6.18 показан пример состояния инициализации (Init state) маршрутизатора OSPF.
РИСУНОК 6.18

Когда маршрутизатор
находится я состоянии
инициализации (Init state),
он устанавливает
отношения смежности с
соседними устройствами.

Состояние инициализации: еще не выбран управляющий
маршрутизатор (DR, designated router)

Маршрутизаторы отправляют приветственные сообщения
с целые формирования отношении смежности с соседями.

Маршрутизатор, который находится в состоянии инициализации, не может взять на
себя функции управляющего маршрутизатора (DR, designated router) или резервного
управляющего маршрутизатора (BDR, backup designated router), поскольку еще не вы-
полнялась процедура выбора маршрутизаторов DR и BUR. Маршрутизатор переходит в
состояние инициализации тогда, когда администратор осуществляет начальную активи-
зацию протокола OSPF или перенастройку интерфейса. Именно в состоянии инициа-
лизации маршрутизаторы передают Hello сообщения, объявляя о своем присутствии всем
соседним устройствам данной сети. Каждый маршрутизатор отравляет подобное объяв-
ление всем маршрутизаторам, находящимся в гом же сегменте сеги. Подключенные к
той же подсети маршрутизаторы получают такое Hello-сообшение и таким образом уз-
нают о появлении нового соседа, они также могут включить информацию о нем в свои
базы данных для хранения сведений о смежных маршрутизаторах (Adjacency databases).

Состояние двусторонней связи

После того как маршрут изатор получает ответные Hello-пакеты от других локальных
маршрутизаторов (в этот момент маршрутизатор переходит в состояние двусторонней
связи, Two-Way state), начинается процесс формирования отношений смежности Каж-
дый маршрутизатор получает информацию о своих соседях и включает эту информа-
цию в соответствующую базу данных. Отношения смежности между маршрутизаторами
moiут быть установлены голькс^тогда, когда совпадают значения следующих полей при-
вете) венных пакетов:

•	Поля идентификатора области OSPF (Area ID)

•	Поля таймера рассылки приветственных сообщений iHellointcrvai) и таймера раз-
рыва отношений смежности (Deadinterval)

•	Поля аутентификации (Authentication)

•	Поля идетифи кагора тупиковой области (Stub ID)

Если хотя бы одно из этих значений не совпадет, соседние маршрутизаторы не смо-
гут установить отношения смежности и, следовательно, не смогут обмениваться марш-
рутом информацией. (В представленном выше списке указаны только некоторые ноля;
более подробно все поля Hello-пакетов рассматриваются ниже в данной главе). На рис.
6.19 показано, как OSPr-маршрутизаторы используют Hello-сообщения в процессе фор-
мирования базы данных для хранения сведений о смежных маршрутизаторах.
В состоянии двусторонней связи (Two-Way state) каждому маршрутизатору локаль-
ного сегмента сети уже известна информация о соседях, и с ними установлена двунап-
равленная (двусторонняя) связь (см. рис.6.20). Пребывание маршрутизаторов в состоя-
нии двусторонней связи с соседями (Two-Way state) предполагает, что эти
маршрутизаторы обменялись Hell о-па кетам и с соседними устройствами и включили
сведения о них в соответствующие базы данных. Маршрутизаторы OSPF передают HeDo-
сообщения каждые 10 секунд с целью поддержания отношений соседства с локальными
маршрутизаторам и.

Hello-сообщения протокола OSPF

РИСУНОК 6.19
Маршрутизаторы
используют
приветственн ые
сообщения OSPF с
£{р iw построения баз
данных для хранения
сведений о смежных
маршрутизаторах
(Adjacency database}.

Примечание: Если присвоен защитный пара
это значение также должно быть согласова

Значения этих попей
Halb-сообщений
смежных маршрутизаторов
должны совпадать

Идентификатор маршрутизатора
Идентификатор области OSPF
Идентификаторы соседей
Идентификатор приоритета
маршрутизатора
IP-адрес управляющего
маршрутизатора (DR)
Значения таймеров рассылки
приветственных сообщений и
разрыва отношений смежности
Пароль OSPF

Идентификатор тупиковой области

РИСУНОК 6.20

Когда маршрутизаторы
находятся в состоянии
двусторонней связи (Two-
Way state},, это означает,
что между ними
установлены
двунаправленн ые
отношения.

Маршрутизатор 2

Маршрутизатор 3

Маршрутизатор 1

Маршрутизатор 3

Состояние двусторонней связи:
еще не назначен управляющий маршрутизатор (DR)

Маршрутизатор 1

Маршрутизатор 2

• Каждый маршрутизатор включает сведения о других
маршрутизаторах в свою базу данных.

Маршрутизатор 2 |

Предстартовое состояние

После того, как маршрутизаторы проходят стадию инициализации и установления
двусторонних соседских отношений, все маршрутизаторы данною сегмента обладают
достаточным количеством информации для того, чтобы выбрать управляющий маршру-
тизатор {DR, designated router) и резервный управляющий маршрутизатор (BDR, backup
designated router) Процедура назначения DR и BDR выполняется на стадии прел аис-
тового состояния маршрутизатора (Exstart state). Управляющий маршрутизаюр и резер-
вный маршрутизатор назначаются в каждом сегменте сети, поддерживающей широко-
вещательную рассылку сообщений (локальной вычислительной сети). Маршрутизаторы
используют два устанавливаемых в соответствующих полях Не11о-сооощений парамет-
ра, а именно — идентификатор приоритета маршрутизатора (priority ID) и идентифика-
тор маршрутизатора (router ID), для выбора DR и BDR.

При назначении того или иного маршрутизатора управляющим сначала рассматри-
вается идентификатор приоритета, а затем — идентификатор маршрутизатора. Марш-
рутизаторы выбирают устройство с наивысшим значением уровня приоритета в каче-
стве управляющего маршрутизатора (DR). Устройство со значением, непосредственно
следующим за максимальным уровнем приоритета, назначается резервным управляю
шим маршрутизатором (BDR). Если все маршрутизаторы имеют одинаковый уровень
приоритетности, далее осуществляется выбор DR и BDR по идентификатору маршру-
тизатора: маршрутизатор с наивысшим значением идентификатора назначается управ-
ляющим маршрутизатором (DR), маршрутизатор со следующим значением идентифи-
катора назначается резервным управляющим маршрутизатором (BDR). Оба параметра
можно модифицировать, чтобы иметь возможность регулировать процесс выбора DR и
BDR.

После завершения процесса назначения управляющего маршрутизатора и его "заме-
стителя" (DR и BDR) эти маршрутизаторы становятся центральными маршрутизатора-
ми данного сегмента. В обязанности маршрутизаторов DR и BDR входят следующие дей-
ствия:

•	Получение от локальных маршрутизаторов объявлений о маршрутах.

•	Построение базы данных для хранения сведений о состоянии каналов связи.

•	Распространение полученной маршрутной информации среди всех маршрутиза-
торов того же сегмента (это действие выполняет только управляющий маршрути-
затор; резервный маршрутизатор, остающийся в состоянии ожидания, выполняет
данное действие в случае выхода из строя маршрутизатора DR).

Все оставшиеся после назначения DR и BDR маршрутизаторы становятся подчинен-
ными (slaves) по отношению к управляющему и резервному маршрутизаторам, которые
являются ведущими маршрутизаторами (masters). DR и BDR становятся получателями
объявлений всех подчиненных маршрутизаторов. Оба ведущих маршрутизатора — DR и
BDR — принадлежат к одной и гой же группе многоадресной рассылки сообщений
224.0.0.6 (по этому адресу все подчиненные маршрутизаторы отправляют свои сообще-
ния). Когда маршрутизаторы DR и BDR избраны, они оба принимают и обрабатывают
объявления типа 1 находящихся в том же сегменте сети маршрутизаторов. Однако толь-
ко управляющий маршрутизатор (DR) отвечает за распределение полученной информа-
ции между локальными маршрутизаторами, адресуя при этом свои сообщения по груп-
повому адресу 224.0.0.5. Резервный управляющий маршрутизатор (BDR) остается в
режиме ожидания до тех пор, пока DR не потеряет по какой-либо причине способность
распространять полученную маршрутную информацию. Если такое происходит, резер-
вный управляющий маршрутизатор становится управляющим маршрутизатором. В слу-
чае выхода DR из строя BDR занимает его место. Когда управляющий маршрутизатор
возвращается в рабочее состояние, он не вытесняет маршрутизатор, выполняющий в
текущий момент времени функции DR.

Назначение управляющего маршрутизатора в каждом сегменте сокращает количество
отношений смежности, которые необходимо установить в пределах всего сетевого ком-
плекса. При этом ограничиваются заграгы на выполняемую каждым маршрутизатором
обработку трафика многоадресных сообщений (см. рис.6.21).

РИСУНОК 6.21

Предстартовое состояние
маршрутизаторов (Ex-start
state) — это состояние.

через которое

маршрутизаторы Должны
пройти перед началом
обмена маршрутной
информацией.

Предстартовое состояние

• Ви маршрутизаторы отправляют свои объявления о состоянии каналов
связи (LSA) маршрутизаторам DR и ВОЛ "О групповому адресу 224.0.0.6.

Состояние обмена

Когда подчиненные маршрутизаторы находятся в состоянии обмена информацией
(Exchange state), они осуществляют обмен маршрутными данными с управляющим мар-
шрутизатором (DR) и резервным управляющим маршрутизатором (BDR). Все подчинен-
ные маршрутизаторы отправляют маршрутную информацию маршрутизаторам DR и BDR
в многоадресной рассылке по групповому адресу 224.0.0.6. Изменения в базах данных
принимает как DR, так и BDR. Однако только управляющий маршрутизатор (DR) кон-
тролирует процесс синхронизации и распространения такой информации. Маршрути-
затор DR (ведущий) передает полученные маршрутные данные всем подчиненным мар-
шрутизаторам сегмента в многоадресной рассылке по групповому адресу 224.0.0.5 (см.
рис.6.22).

РИСУНОК 6.22

Маршрутизаторы могут
осуществлять обмен
маршрутной информацией,
когда они находятся в
состоянии обмена
(Exchange stare).

В случае неудачного исхода хотя бы одного из рассмотренных выше этапов подго-
товки маршрутизатора к передаче пакетов данных создание карты топологии сети не-
возможно. При первом вхождении маршрутизатора в состояние обмена (Exchange state)
его база данных для хранения сведений о состоянии каналов связи (Link-state database)
еще не заполнена; при этом маршрутизатор получает всю необходимую информацию
для создания такой базы данных. После создания базы данных маршрутизатор отправ-
ляет только сообщения об обновлении маршрутной информации с целью информиро-
вания соседей об изменениях топологии сеги. С другой стороны, маршрутизаторы OSPF
отправляюг маршрутную информацию каждые 30 секунд для того, чтобы обеспечить
текущее обновление топологических баз данных всех соседних устройств.
Состояние загрузки

Маршрутизатор входит в состояние загрузки (Loading slate) только тогда, когда он
на стадии обмена информацией получает сведения, противоречащие сведениям управ-
ляющего маршрутизатора (DR). Если полученная информация отличается от данных
текущей карты топологии сеги, маршрутизатор может войти в состояние загрузки, что-
бы отправить запрос о состоянии каналов связи (Link-state request) на получение допол-
нительной маршрутной информации, позволяющей завершить построение карты топо-
логии сети. Если никаких противоречий нет, маршрутизатор выходит из состояния
загрузки дополнительной информации.

Состояние готовности

Маршрутизатор может достичь состояния полной готовности к выполнению марш-
рутизации пакетов данных (Full state) только после того, как он пройдет все предыду-
щие этапы. На данной завершающей стадии маршрутизатор создает таблицу маршрути-
зации на основании карты топологии сети (топологической базы данных).
Маршрутизатор выбирает оптимальные маршруты и вносит их в базу данных для хра-
нения маршрутной информации (forwarding database). Выбор наилучших маршрутов осу-
ществляется посредством алгоритма поиска кратчайшего пути (SPF, Shortest Path First),
который выполняется на всех маршрутизаторах, идентифицированных в тополо! ичес-
кой базе данных.

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

•	Состояние обмена (Exchange slate)

•	Состояние загрузки (Load slate)

•	Состояние готовности (Full state)

Если в сети происходят какие-либо изменения, маршрутизатор генерирует триггер-
ное обновление, и начинается обмен сообщениями об обновлении маршрутной инфор-
мацией. После получения маршрутизатором противоречивой информации он входит в
состояние загрузки. Находясь в состоянии загрузки, маршрутизатор запрашивает у уп-
равляющего маршрутизатора (DR) дополнительные сведения. После получения требуе-
мой информации маршрутизатор выполняет алгоритм SPF для вычисления оптималь-
ных маршрутов на основании базы данных для хранения сведений о состоянии каналов
связи. При выполнении алгоритма SPF происходит со1ласование маршрутизаторами
содержимого баз данных, и начинается собственно процесс маршрутизации.

Типы маршрутизаторов OSPF

Протокол OSPF предписывает маршрутизатору выполнение тех или иных функций
в зависимости от того, какое место в архитектуре автономной системы занимает этот
маршрутизатор. Как упоминалось ранее, автономная система представляет собой груп-
пу маршрутизаторов, которые выполняют обмен маршрутной информацией под управ-
пением о&шего протокола маршрутизации (в данном случае — OSPF). Маршрутизатор
может брать на себя выполнение нескольких функций одновременно. Существует че-
тыре типа OSPF маршрутизаторов (см. рис 6.23):

•	Внутренний маршрутизатор (internal router): маршрутизатор, все интерфейсы ко-
торого функционирую! в одной и той же области. Маршрутизаторы такого типа
обслуживают только один протокол маршрутизации.

•	Маршрутизатор магистральной области (backbone router): маршрутизатор, кото-
рый имеет хотя бы один интерфейс, подсоединенный к области 0. Маршрутиза-
тор, все интерфейсы которою подсоединены к магистральной области, функци-
онирует в качестве внутреннею маршрутизатора базовой области (internal backbone
router).

•	Маршрутизатор грани области (ABR, area border router): маршрутизатор, который
находится на грани между двумя областями OSPF. Маршрутизаторы такого типа
осуществляют маршру гизацию между разными областями, как правило, между по-
добластью и областью 0. Маршрутизаторы, передающие пакеты данных в область
0, функционируют также и в качестве маршрутизаторов магистральной области.
Маршрутизаторы ABR поддерживают несколько баз данных для хранения сведе-
ний о состоянии каналов связи (Link-state databases), по одной базе данных на
каждую область, к которой маршрутизатор ABR подсоединен.

•	Маршрутизатор (раницы автономной системы (ASBR, Autonomous system boundary
router) находится на границе между двумя автономными системами, которые фун-
кционируют под управлением протокола OSPF и еше одного из протоколов
маршрутизации (напрчмер, протокола RIP). Маршрутизаторы ASBR можно скон-
фигурировать таким образом, чтобы они имели возможность объявлять сформи-
рованные не протоколом OSPF маршруты устронств-ам автономной системы OSPF.
Такая конфщурация маршрутизаторов ASBR позволяет передавать маршрутную
информацию, внешнюю по отношению к данной автономной системе, во все
области этой АС.

РИСУНОК 6.23

Тип маршрутизатора
определяет w его
местоположением е сети,
функционирующее под
управлением протокола
OSPF.

ABR - Маршрутизатор грани области
Функционирование OSPF в сетях с различной
архитектурой

Как упоминалось ранее, протокол OSPF обслуживает маршрутизацию данных в се-
тях различных типов. Однако набор функциональных возможностей протокола OSPF
зависит ог типа сети, в которой он выполняется. Протокол OSPF поддерживает как
широковещательные сети (broadcast networks), так и сети на основе соединений типа
"точка-точка" (point-to-point networks), а также не поддерживающие широковещатель-
ную рассылку сообщений сети с множественным доступом (NBMA, Nonbroadcast
multiaccess networks).

Действие OSPF в широковещательных сетях

Локальные сети с широковещательной адресацией (такие как Ethernet, Token-Ring и
FDDI) поддерживают передачу трафика широковещательных и многоадресных сообще-
ний, тем самым делая возможным динамическое обнаружение соседних устройств, на-
значение управляющего маршрутизатора (DR) и резервного управляющего маршрути-
затора (BDR), а также обмен маршрутной информацией (см. рис.6.24).

РИСУНОК 6.24

В каждой широковещательной сети с
множественны.» доступом (broadcast
multiaccess network) есть по одному
маршрутизатору DR и ВГ>В Поскольку
такие сети поддерживают передачу
трафика широковещательных и
многоадресных сообщений по умолчанию,
отношения соседства формируются
автоматически, и маршрутизаторы DR и
BDR также назначаются автоматически.

Действие OSPF в сетях с соединениями типа "точка-точка"

Соединение типа "точка-точка" (point-to-point connection), или выделенная арендуе-
мая линия (dedicated leased-hne), формируется двумя маршрутизаторами, подсоединен-
ными к каждому концу одного и того же канала связи. В такой передающей среде сете-
вой администратор должен вручную сконфигурировать маршрутизатор с IP-адресом
соседнего устройства. Это облегчает формирование отношений смежности по данному
каналу связи, а также обмен маршрутной информацией. Поскольку существует только
два маршрутизатора, нет необходимости назначать управляющий маршрутизатор (DR)
и резервный управляющий маршрутизатор (В1Ж)для управления процессом хранения
и синхронизации базы данных для состояний каналов связи (см. рис.6.25).

Действие OSPF в сетях NBMA

Сети с множественным доступом, не поддерживающие широковещательных рассы-
лок (NBMA, Nonbroadcast multiaccess), состоя г из двух или более маршрутизаторов, вза-
имодействующих между собой на основании базовых сетей с не широковещательной
топологией, таких как сети X 25 или Frame Relay. Поскольку сеть NBMA не поддержи-
вает широковещательную адресацию, необходимо вручную конфи!урировать каждый
маршрутизатор с IP-адресом всех остальных маршрутизаторов данной сети с целью
формирования отношений смежности между ними. После ручного включения в конфи-
гурацию маршрутизаторов такой информации они имеют возможность назначать управ-
ляющего маршрутизатора (DR) и реэервного /правляющего маршрутизатора (BDR), а
далее — обмениваться маршрутной информацией без использования широковещатель-
ной рассылки сообщений

РИСУНОК 6.25

Каналы свят типа “точка-точка" глобальных
сетей не требуют наличия управляющего
маршрутизатора (DR) и резервного
управляющего маршрутизатора (BDR),
поскольку выделенную арендуемую линию связи
обслуживают только два маршрутизатора по
одному на каждом конце канала

Отношения соседства на последовательных
соединениях типа "точка- очка"

Нет “'.обходимое, и j назначении DR или BDR. поскольку
на данном канале связи функционирует только два устройства.

В случае если базовая сеть поддерживает широковещательную рассылку сообщений,
необходимо вручную сконфигурировать на маршрутизаторах информацию о соседях. В
таком случае все действия, касающиеся обнаружения соседей, назначения DR и BDR, а
также обмена маршрутной информацией, выполняются автоматически (см. рис.6.26).

РИСУНОК 6.26

Сети NBMA не
поддерживают
широковещ.ат&1 ьную
рассылку сообщений

Отношения спседс1ва в не широковещательных сетях с
множественным доступом (SO) - переключение маршрутов

Действие OSPF в сетях со сложной иерархической структурой

Достаточно часто протокол OSPF обслуживает состоящие из одной неделимой обла-
сти сеги среднего или небольшого размера. В то же время в большинстве работающих
под управлением протокола OSPF сетевых комплексов среднего размера автономные
системы подразделяются на более мелкие подобласти, в которых орьзнизовагь процесс
маршрутизации гораздо проще.

Реализация протокола OSPF в сетевом комплексе, состоящем из одной неделимой
области, имеет существенные недостатки. По мере увеличения количества сетей и мар-
шрутизаторов возрастает также и размер базы данных для хранения сведений о состоя-
нии каналов связи (Link-state database) Увеличение размера этой базы данных требует
от маршрутизаторов данной неделимой области отслеживания любых изменении состо-
яния маршрутизатора или сети, происходящих в пределах данной области. Хранение и
обслуживание большой базы данных требует от центральною процессора большого рас-
хода памяти и времени для поддержания работы всех маршрутизаторов, вовлеченных в
процесс маршрутизации в данной области. Как только канал связи изменяет свое со-
стояние (становится доступным или недоступным), вес входящие в состав области мар-
шрутизаторы должны выполнить перерасчет всех маршрутов, содержащихся в базе дан-
ных, согласно алгоритму поиска кратчайшего пути (SPF).

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

Разбиение автономной системы на подобласти носит произвольный характер, но, как
правило, модель такой системы разрабатывается но территориальному принципу; при
этом каждому физическому расположению локального сегмента сети соответствует одна
подобласть. В модели, предполагающей разбиение АС на несколько областей, в нали-
чии обязательно должна быть область 0 (т.е. магистральная область) как главная тран-
зитная область для передачи всего межобластного графика (см. рис.6.27). Точно гак же,
как "все дороги ведут в Рим", все маршруты должны проходить через область 0.

РИСУНОК 6.27
Когда протокол OSPF
реализуется в сети,
состоящей из совокупности
областей со сложной
иерархической структурой,
весе такой маршрутный
домен OSPF
рассматривается как
автономная система
OSPF. Все подобласти
должны быть связаны с
основной транзитной
областью, известной как
область 0 (магистраль).

Маршрутизаторы одной области могут обмениваться информацией только с марш-
рутизаторами гой же области. На рис. 6.27 показан пример, в котором авгономная сис-
тема состоит из трех подобластей — 1, 2 и 3, и все они имеют физическое соединение с
областью 0 через маршрутизаторы грани области (ABR). Маршрутизаторы ABR переда-
ют информацию о маршрутах в магистральную область, маршрутизаторы которой, в свою
очередь, распределяют эту маршрутную информацию по другим областям.
Типы областей

В автономной системе, состоящей из множества организованных но иерархическо-
му принципу областей, тип каждой области определяет тип принимаемых этой облас-
тью объявлений о состоянии каналов связи (LSA, Link State Advertisement), а также тип
генерирующих эти объявления маршрутизаторов. Протокол OSPF работает в областях
следующих трех основных типов:

•	Магистральная область, или область 0 (backbone area, area 0)

•	Стандартная область (standard area)

•	Две тупиковых области: стандартная тупиковая область (stub area) и NSSA, "не
совсем тупиковая область" (NSSA, "not so stubby area").

Виртуальные каналы связи не образуют область; в тоже время виртуальные каналы
связи обеспечивают логическую связь между двумя областями через третью.

Область 0

Магистральная область (backbone area) является связующим звеном между всеми
остальными областями автономной системы. Кроме всех внутриобластных объявлений,
распространяемых в самой магистральной области, все межобластные итоговые объяв-
ления (отправляемые маршрутизаторами грани области, ABR), и объявления внешней
автономной системы (отправляемые маршрутизаторами границы AC, ASBR.) пересека-
ют область 0 на пути к подобластям. Магистральная область может принимать объявле-
ния LSА типов 1—5.

Стандартная область

Стандартная область (standard area) функционирует в качестве области, подчинен-
ной области 0. Стандартная область принимает от других подобластей внутриобластные
объявления LSA тина 1 и 2. а также внутриобластные итоговые объявления типа 3 и 4,
отравленные маршрутизатором ABR, который соединяет данную область с областью 0.
Кроме того, стандартная область принимает объявления LSA типа 5 — маршруты внеш-
ней автономной системы, объявленные соединенным с этой АС маршрутизатором ASBR.
Стандартные области могут быть физически связаны с областью 0 через ряд шлюзов с
целью формирования резервных маршрутов к центральной области и через нее.

Тупиковая область

Тупиковая область имеет только один вход и один выход, другими словами — толь-
ко одно соединение с областью 0. Как правило, не возникает необходимости в передаче
сообщений протокола OSPF об обновлении маршрутной информации по этому каналу
связи, особенно если это — низкоскоростной канал глобальной сети (WAN link) или
коммутируемое соединение (dial-up connection). В подобной ситуации наиболее пред-
почтительным было бы использование маршрута по умолчанию (default route) для опре-
деления пути к сетям, находящимся вне тупиковой области. Конфигурирование марш-
рута по умолчанию, или статического маршрута, исключаег прохождение по данному
каналу связи графика обновления, сохраняя при этом дорогостоящую ширину полосы
пропускания. В RFC 1583 определены два типа тупиковых областей:
•	Стандартная тупиковая область (standard stub area)

•	"Не совсем тупиковая" область (NSSA, "not so stubby area")

Компания Cisco имеет также свою собственную тупиковую область, известную под
названием "полностью тупиковая" область ("totally stubby"). (Эта область в данной кни-
ге не рассматривается.)

На тупиковые области наложены следующие ограничения:

•	Область 0 и маршрутизаторы границы автономной системы (ASBR) не могут вхо-
дить в состав тупиковой области.

•	Сетевой администратор должен сконфигурировать все маршрутизаторы, входящие
в состав стандартной тупиковой области или NSSA, а также соединенные с эти-
ми областями маршрутизаторы, как маршрутизаторы тупиковой области (stub
routers).

Стандартная тупиковая область

Несмотря на то, что наличие маршрута по умолчанию сокращает количество пере-
даваемых в тупиковую область объявлений OSPF, стандартная тупиковая область
(standard stub area) принимает внутри- и межобластные маршруты (LSAinna 1, 2, 3 и 4).
Эта область не принимает никаких внешних отправляемых маршрутизаторами ASBR
объявлений (LSA типа 5 или 7).

Область NSSA

Тупиковые области типа NSSA принимают только внутриобластные объявления (LSA
типа I и 2), поскольку без объявлений такого типа невозможно было бы обнаружить
маршрут даже в самой области и, следовательно, не было бы смысла активизировать
протокол маршрутизации в данной области. NSSA не принимает объявлений о внешних
маршрутах (LSATiina 5), отправляемых маршрутизаторами ASBR. В то же время назва-
ние "не совсем тупиковая" область свидетельствует о том, что в эту область все-таки до-
пускаются кое-какие внешние объявления, а именно — по этой области можно переда-
вать (с помощью LSA типа 7) генерируемые маршрутизаторами ASBR объявления о
внешних маршрутах, ведущих к области 0.

Маршрутизаторы ABR преобразуют объявления типа 7 о внешних маршрутах в объяв-
ления типа 5 перед тем, как передать их в магистральную область (см. рис.6.28).

РИСУНОК 6.28
Существует
возможность передачи
объявлений о внешних
маршрутах через
тупиковые области
типа NSSA в
область О.

NSSA, "не совсем тупиковая область"

Remote
Site

Центральный
офис или
поставщик услуг
Интернета

ABR транслирует
1_ЗАтипа7в
LSA типа 5

Маршрутизатор ASBR
передает сведения о
RIP-маршрутах или
ElGRP-маршрутах
посредством ISA типа 7
На рис. 6.28 область NSSA (область 1) непосредственно соединена с областью 0 че-
лез маршрутизатор ABR, а также с другим маршрутным доменом, и ли автономной сис-
темой (обслуживаемой не протоколом OSPF) через маршрутизатор ASBR Маршрутиза-
тор ASBR, соединенный с другим маршрутным доменом, обслуживает протоколы RIP,
EIGRP и OSPF. На маршрутизаторе ASBR необходимо выполнить передачу маршрут-
ной информации, сформированной не протоколом OSPF, в обслуживаемую OSPF сеть.
Это побуждает маршрутизатор сгенерировать объявление LSA типа 7 и направить его в
NSSA. Когда такие внешние LSA попадают на маршрутизатор ABR, соединяющий NSSA
с областью 0, эти объявления преобразуются но внешние объявления LSAmna 5 и рас-
пространяются по другим областям автономной системы OSPF.

Виртуальные каналы

Виртуальные каналы передачи данных (virtual links) обеспечивают логический мар-
шрут к области 0 через подчиненную ей область. Виртуальные каналы соединяют либо
новую подобласть с магистральной областью в случае 0|каза физического соединения,
либо в случае, когда существует несколько областей 0, но они физически разделены
(например, при слиянии двух компаний с уже существующей реализацией OSPF). В лю-
бом случае, виртуальные каналы связи используют стандартную об гасть в качестве тран-
зитного пути, соединяющего подобласть с областью 0 или две магистральные области.

На рис. 6.29 показан пример того, как в состав автономной системы добавлена но-
вая область OSPF, но нет ни одного способа соединения этой области с областью 0. На
рис. 6.30 представлен пример слияния автономных систем двух ведомств с уже суще-
ствующими реализациями OSPF. Обе базовые области OSPF необходимо соединить вирту-
альным саналом связи через транзитную область, в данном случае — через область 51.

РИСУНОК 6.29

Виртуальные копию
передачи данных (virtual
links) — это пролегающие
по ппдооластям югические
маршруты, соединяющие
какую-либо область с
областью 0 через другую
область.

РИСУНОК 6.30

Область О — это
магистральная область
автономной системы,
состоящей из множества
организованных по
иерархическому принципу
областей.

Виртуальный канал передачи данных—пример 1

Виртуальны.* ка ian

ггь

Область 1

Нови* ...и гь.

на соединенная

с областью О

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

(Утаен 3

СЯпаотьО

Виртуальный канал передачи данных — пример 2

 Виртуальный канал устанавливает связь между двумя
магистральными областями после слияния двух сетей
ПРИМЕЧАНИЕ

Виртуальные каналы передачи данных необходимо вручную конфигурировать на маршру-
тизаторах грани области. Такое конфигурирование зависит от конкретной реализации и
не рассматривается в данной книге.

Стандартные поля протокола OSPF

Все пять типов пакетов OSPF (которые рассматриваются ниже в данной главе) пере-
даются в дейтаграммах с заголовками OSPF (длиной 24 октета), поля которых идентич-
ны (см. рис.6.31). Поля заголовка OSPF рассматриваются в последующих разделах теку-
щей главы.

РИСУНОК 6.31

Пакеты OSPF всех
пяти типов имеют
один и тот же
стандартный
заголовок.

Версия I Тип пакета	Длина пакета
Идентификатор маршрутизатора	
Идентификатор области	
Контрольная сумма	Тип аутентификации
—	Данные аутентификации	—	
Заголовок Hello-пакета, пакета с описанием базы данных, запроса о состоянии канала, пакета обновления состояния канала и подтверждения приема корректировок	

Заголовок пакета

OSPF

Различные типы пакетов OSPF и их заголовки рассматриваются ниже в данной па-
ве.

Поле номера версии

Поле номера версии (Version) длиной 8 битов идентифицирует номер версии прото-
кола OSPF. В настоящее время используется вторая версия протокола OSPF,

Поле типа пакета

Поле типа пакета (Packet Туре) длиной 8 битов идентифицирует тип пакета прото-
кола OSPF. В таблице 6.6 перечислены все пять типов пакетов OSPF, а также представ-

лено описание их функций.

Таблица 6.6 Типы пакетов OSPF

Номер пакета	Тип пакета	Описание
1	Приветственный пакет (Hello packet)	Устанавливает и поддерживает отношения смежности между соседями
2	Описание базы данных (Database description packet)	Содержит описание баз данных OSPF
3	Запрос о состоянии канала связи (link-state request)	Служит для запроса на предоставление дополнительной маршрутной информации или на полное обновление топологической базы данных
Номер пакета	Тип пакета	Описание
4	Обновление состояния канала связи (Link-state update)	Передает маршрутную информацию в ответ на запрос о состоянии канала связи (другими словами, обновляет базу данных)
5	Подтверждение получения короектировок (Link-state acknowledgement)	Подтверждает прием маршрутной информации

Ниже следует дальнейшее описание полей заголовка OSPF.

Поле длины пакета

Поле длины пакета (Packet Length), размер которого 16 битов, идентифицирует дли-
ну (в байтах) дейтаграммы OSPF, включая заголовок дейта!раммы и ее содержимое.

Поле идентификатора маршрутизатора

В поле идентификатора маршрутизатора (Router ID) длиной 32 бига содержится уни-
кальное значение, которое идентифицирует маршрутизатор, отправивший данный па-
кет OSPF. Протокол OSPF использует это значение для выбора управляющего маршру-
тизатора (DR) и резервного управляющего маршрутизатора (BDR). Идентификатор
маршрутизатора может быть сконфигурирован либо динамическим способом, либо вруч-
ную сетевым администратором.

Поле идентификатора области

Поле идентификатора области (Агеа 1 D>. имеющее длину 32 бита, идентифицирует
область, из которой поступила дейтаграмма. Область 0 всегда имеет идентификатор
0.0.0.0. Значение данного поля меняется в зависимости от области, а администратор
может вручную сконфигурировать это значение таким образом, чтобы оно было логи-
чески связано с номером подсети

Поле контрольной суялмы пакета

Посредством значения, установленного в поле контрольной суммы пакета
(Checksum), имеющего длину 16 битов, протокол OSPF проверяет, не был ли повреж-
ден пакет OSPF во время передачи. При проверке целостности содержимого пакета OSPF
из заголовка дейтаграммы OSPF исключается значение, установленное в поле данных
аутентификации (Authentication).

Поле типа аутентификации и данных аутентификации

Одной из необязательных функций маршрутизаторов OSPF является аутентифика-
ция (защита данных от несанкционированного доступа) с помощью пароля. Когда мар-
шрутизаторы сконфигурированы таким образом, что они поддерживают аутентифика-
цию, они устанавливают отношения смежности только с теми маршрутизаторами,
которые имеют тог же защитный пароль. Поля типа аутентификации (Authentication Туре)
и собственно данных аутентификации (Authentication) взятые в совокупности, подтвер-
ждают достоверность пакета. Поле типа аутентификации (Authentication Type) имеет дли-
ну 16 битов, поле данных аутентификации (Authentication) — 32 бита.
Дополнительные заголовки

В состав каждого заголовка OSPF входит дополнительный заголовок, содержащий
особую маршрутную информацию об одном из пяти типов пакетов OSPF. Этот допол-
нительный заголовок находится сразу же после общих полей заголовка OSPF и может
быть заголовком одною из следующих пяти пакетов OSPF:

•	Приветственный пакет (Hello packet, тип 1)

•	Пакет, содержащий описание содержимого базы данных (Database Description
packet, тип 2)

•	Пакет, содержащий запрос о состоянии канала связи (Link-state Request packet,
тип 3)

•	Пакет, содержащий корректировки состояния канала связи (Link-state Update
packet, тип 4)

•	Пакет, содержащий подтверждение приема (Link-state Acknowledgement packet,
тип 5)

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

Приветственные пакеты

Приветственные дейтаграммы представляют собой пакеты типа 1 протокола OSPF.
Hello-пакеты устанавливают и поддерживают отношения смежности с соседними уст-
ройствами. На рис 6.32 представлен базовый формат Hello-пакега. На рис. 6.33 показан
заголовок Hello-пакета, отображенный в окне анализатора протоколов Sniffer.

Версия | Тип пакета  t

Длина пакета

Идентификатор маршрутизатора

Идентификатор области

Контрольная сумма

Тип аутентификации

Заголовок
лакота
OSPF

Данные аутентификации

Маска сети

Интервал рассылки Hello-пакетов

Дополнительные
параметры

Интервал разрыва отношений смежности
Управляющий маршрутизатор

Резервный управляющий маршрутизатор

Приоритет
маршрутизатора

Сведения о соседях

РИСУНОК 6.32 Помимо стандартных полей, в заголовок НеНо-пакета протокола OSPFвходит
следующие поля: Маска сети (Network Mask), Интервал рассылки Hello-пакетов (Hello Interval),
Дополнительные параметры (Options), Приоритет маршрутизатора (Routing Priority), Интервал
разрыва отношений смежности с соседом (Dead Interval), Управляющий маршрутизатор (Designated
Router). Резервный управляющий маршрутизатор (Backup Designated Router), а также поле сведений о
соседях (Neighbor).
Идентификатор маршрутизатора

аутентификации

Приветственное сообщение OSPF

Необязательные характеристики Установлен бит внешней маршрутизации

РИСУНОК 6.33 Только те шлюзы OSPF, у которых совпадают идентификаторы области, пароли,
конфигурации тупиковой области, а также интервалы рассылки Hello-пакетов и разрыва отношений
смежности, могут сформировать отношения смежности между собой и обрабатывать передаваемую
информацию.

На рис. 6.33 маршрутизатор 150.3.233.25 уникальным образом идентифицирован зна-
чением, установленным в поле идентификатора маршрутизатора (Router ID). Эю зна-
чение используется при выборе управляющего маршрутизатора (DR) и резервного мар-
шрутизатора (BDR). Следует помнить о том, что маршрутизатор с наивысшим значением
приоритета (поле Rtr Pri) или идентификатора (поле Router ID) назначается маршрути-
затором DR, а маршрутизатор со следующим значением приоритета и идентификатора
избирается в качестве маршрутизатора BDR. Значение поля идентификатора области
(Area ID) идентифицирует ту область, из которой было отправлено объявление. Если в
конкретной реализации OSPF предусмотрена аутентификация (эта возможность явля-
ется необязательной), только шлюзы, совместно использующие один и тот же пароль,
могут сформировать отношения смежности.

На рис. 6.33 показано также, что в заголовке указана предназначенная для шлюза
маска подсети (255.255.255.0), а также перечислены дополнительные возможности, под-
держиваемые данным заголовком. Значение 1, установленное в разделе необязательных
возможностей заголовка (Optional Capabilities) указывает на то, что заголовок предус-
матривает поддержку этой конкретной возможности. В данном примере, как видно по
заголовку, маршрутизатор сконфигурирован таким образом, чтобы он имел возможность
поддерживать внешнюю маршрутизацию (External Routing Capability). Эго означает, что
данный шлюз поддерживает сформированные не протоколом OSPF объявления. Это оз-
начает также, что один из маршрутизаторов границы автономной системы (ASBR) или
один из внутренних маршрутизаторов области поддерживает передачу внешних марш-
рутов через эту' область. Кроме того, маршрутизатор 150.3.233.25 идентифицирует IP-
адрес маршрутизатора DR (150.3.233.249) и объявляет себя маршрутизатором BDR. И,
наконец, в заголовке OSPF перечислены все соседи, известные маршрутизатору (в дан-
ном случае есть только один сосед — 1.0.0.5).

Поля заголовка Не11о-пакега рассматриваются более подробно в последующих раз-
делах.

Поле маски сети

Поле маски сети (Network Mask) идентифицирует маску подсети локального интер-
фейса.

Поле дополнительных параметров

В поле дополнительных параметров (Options) специфицируются возможности про-
токола OSPF, поддерживаемые данным маршрутизатором. Все маршрутизаторы не мо-
гут поддерживать дополнительные возможности, заданные в этом поле (Options). Если
дополнительные возможности не поддерживаются маршрутизатором, он подавляет или
игнорирует данное поле. В поле дополнительных параметров (Options) может быть ус-
тановлен один из следующих битов

•	Бит Т (Т bit): маршрутизатор OSPF, на котором установлен данный бит, спосо-
бен поддерживать маршрутизацию согласно требуемому уровню типа и качества
обслуживания (ToS/QoS routing). Уровень типа обслуживания определяется уста-
новкой отличающегося от 0 значения этого бига. Если бит Т установлен в значе-
ние ноль, это означает, что данный маршрутизатор не имеет возможности выпол-
нять маршрутизацию согласно требуемому уровню типа обслуживания (ToS).
Каждый маршрутизатор, поддерживающий ToS, создает деревья кратчайших мар-
шрутов (shortest-palh trees), корнем которых является он сам: одно дерево — для
маршрутов, сформированных согласно требованиям ToS (в этом дереве нет мар-
шрутов другого типа); другое дерево — для обычных (сформированных без учета
требований ToS) маршрутов (см. рис. 6.33).

•	Биг Е (Е bit): маршрутизаторы, на которых установлен этот бит, могут обрабаты-
вать информацию о внешних маршрутах, сформированных не протоколом OSPF
Маршрутизаторы тупиковой области не поддерживают обновлений внешних мар-
шрутов и, следовательно, не устанавливают этот бит и нс распознают его. На
маршрутизаторах ASBR бит Е всегда находится в активизированном состоянии (см.
рис. 6.33).

В таблице 6.7 представлено более подробное описание этих двух битов. В будущем
разрабтчики могут реализовать и другие биты, устанавливаемые в поле дополни тель-
ных параметров (Options).
Лоле интервала отправки Hello-пакетов

Поле интервала отправки Hello-пакетов (Hello interval) регулирует частоту рассылки
дейтаграмм, содержащих приветственные сообщения. Значение данного поля меняется
в зависимости or топологии сети на канальном уровне, в которой выполняется прото-
кол OSPF. В широковещательной сети маршрутизаторы отправляют Hello-пакеты каж-
дые 10 секунд. В сетях, не поддерживающих широковещательную рассылку сообщений,
маршрутизаторы по умолчанию рассылают Hello-пакеты каждые 30 секунд.

Поле приоритета маршрутизатора

Маршрутизаторы OSPF используют поле приоритета маршрутизатора (Router Priority)
исключительно для выбора управляющего маршрутизатора (DR) и резервного управля-
ющего маршрутизатора (BDR) в каждом сегменте сети. Маршрутизатор с наивысшим
значением приоритета назначается маршрутизатором DR. Управляющий маршрутиза-
тор (DR) контролирует сбор, синхронизацию и распространение маршрутной инфор-
мации в пределах данного сегмента.

Маршрутизатор со следующим значением приоритета назначается резервным управ-
ляющим маршрутизатором (BDR). Маршрутизатор BDR только собирает маршрутную
информацию и создает базу данных для хранения сведений о состоянии каналов связи
(Link-state database). Этот маршрутизатор остается в режиме ожидания до тех пор, пока
не произойдет отказ в работе маршрутизатора DR. В таком случае BDR автоматически
выдвигает себя на роль управляющего маршрутизатора данного сегмента, а маршрути-
затор OSPF избирает новый резервный управляющий маршрутизатор (BDR).

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

Если все маршрутизаторы имеют одно и то же значение приоритета (т.е. сетевой
администратор не сконфигурировал один из маршрутизаторов с более высоким значе-
нием приоритета, чем у других маршрутизаторов), выбор маршрутизаторов DR и BDR
осуществляется на основании идентификатора маршрутизатора, установленного в соот-
ветствующем поле.

Поле интервала разрыва отношений смежности

Поле интервала разрыва отношений смежности (Dead Interval) позволяет обнаружить
вышедшее из строя соседнее устройство. По умолчанию маршрутизатор считает сосед-
нее устройство заблокированным ио той или иной причине, когда он на протяжении
периода времени, равного четырем интервалам рассылки Hello-пакетов, не получает
никаких известий от соседа (т.е. этот маршрутизатор не получает за этот период ни од-
ного Hello-пакета от соседа).

Значение, устанавливаемое в поле разрыва отношений смежности г Dead interval) в
четыре раза больше значения, указанного в поле интервала отправки Hello-пакетов (Hello
interval). Это значение (измеряемое в секундах) меняется в зависимости от топологии
сеги на канальном уровне, в которой выполняется протокол OSPF. В широковещатель-
ной сети маршрутизаторы отправляют Hello-пакеты каждые 10 секунд, что делает ин-
тервал разрыва отношений смежности равным 40 секундам. В сети, не поддерживаю-
щей широковещательную адресацию, маршрутизаторы по умолчанию отправляют
Hello-пакеты каждые 30 секунд, что делает интервал разрыва отношений смежности
равным 120 секундам.

Поле управляющего маршрутизатора

В поле управляющего маршрутизатора (Designated Router) указывается IP-адрес мар-
шрутизатора DR, если он известен маршрутизатору. Если маршрутизатору этот адрес
неизвестен, в данном ноле устанавливается значение 0.0.0.0.

Поле резервного управляющего маршрутизатора

В поле резервного управляющего маршрутизатора указывается IP-адрес маршрути-
затора BDR, если он известен маршрутизатору. Если этот адрес неизвестен, в данном
поле устанавливается значение О.О.О.О.

Поле сведений о соседних устройствах

В поле сведений о соседях (Neighbor) содержится список идентификаторов всех со-
седних маршрутизаторов, которые стали известны данному маршрутизатору после рас-
сылки локальных Hello-пакетов.

Пакеты OSPF, содержащие описание баз данных

В пакетах с описанием содержимого баз данных (Database Description packets, тип 2)
передаются сведения, необходимые для инициализации топологических баз данных
смежных устройств. На рис. 6.34 представлен формат пакета с описанием базы данных.

РИСУНОК 6.34

Помимо стандартных
полей, в заголовок пакета
OSPF с описанием балы
данных (Database
Description packet) входят
следующие поля: поле MTV
интерфейса (Interface
MTV), поле
дополнительных
параметров (Options), поле
порядкового номера
(Sequence Number), а
также поле заголовка LSA
(LSA header).

Версия | Тил пакета-2 |

Длина пакета

Идентификатор маршрутизатора

Идентификатор области

Контрольная сумма

Тип аутентификации

Данные аутентификации

MTU интерфейса [ Дополнительные параметры |o|ojo|o|o| I |М,М1

Порядковый номер

Заголовок LSA

Заголовок
лакота
OSPF

Поле дополнительных параметров

В поле дополнительных параметров (Options) специфицируются дополнигельные
возможности протокола OSPF, поддерживаемые тем или иным маршрутизатором. Дан-
ное поле присутствует в заголовках всех типов пакетов OSPF, тем не менее, устанавли-
ваемые в нем значения битов отличаются в зависимости от типа пакета. В поле допол-
нительных параметров устанавливаются 3 бига (см. табл. 6.7).
Таблица 6.7 Поле дополнительных параметров пакета OSPF, содержащего описание базы
данных

Опция	Описание

1 (Init)	Установка в поле дополнительных параметров (Options) бита 1 (Init, Начальный пакет) указыгает на то. что данный пакет является первым
	пакетом, передаваемым протоколом OSPF
М (More)	Установка в поле дополнительных параметров (Options) бита М (More, Есть еще пакеты) указывает на то. что за данным пакетом OSPF, содержащим описание базы данных последуют другие пакеты Установка бита М в значение 0 указывает на то, что данный пакет является последним.
MS (Master/Slave)	Значение бита MS (M-iMer/Slave. Ведущий/Подчинечный маршрутизатор) определяет статус маршрутизатора, т.е. указывает, является ли nef едающий данный пакет OSPF маршрутизатор ведущим (DR) или под1 мненным (все flpvrne маршрутизаторы):  •	MS - 1 (ведущий маршрутизатор)  •	MS = 0 (подчиненный маршрутиэ=т >р)

Поле порядкового номера

Отправитель упорядочиваем вес пакеты содержащие описание баз данных, посред-
ством присвоения этим пакетам порядковых померив; получатель, и свою очередь, под-
тверждает получение каждого пакета. Начальное значение, устанавливаемое в поле по-
рядкового номера пакета (Sequence Number), задается однозначно при первой отправке
пакета с описанием базы данных (при этом бит I установлен в значение I. НачяяыдыЙ
и ткет), далее это значение последовательно увеличивается.

Поле заголовка LSA

Маршрутизатор может включить одно или более объявлений о состоянии каналов
связи (ISA) в передаваемый OSPF-пакет с описанием базы данных. Следовательно, в
заголовок пакета OSPF включается поле соответствующего заголовка LSA 'Link-state
Advertisement Header). Описание особых полей заголовка пакета OSP) представлено
ранее в данном равделе.

Запросы OSPF о состоянии каналов связи

Пакеты OSPF, содержащие запросы о состоянии каналов связи (Link state Request
раскеь, тип 3). осуществляют загрузку предоставляемой отдельным соседним устрой
стном маршрутной информации или содержимого базы данных. На рис. 6.35 представ-
лен формат пакета типа 3.

РИСУНОК 6.35

Помимо стандартных
полей, в заголовок пакета
OSPF, содержащего запрос
о состоянии к ан ала сан ш,
входят с н’дукнцие поля:
поле типа объявления LSA
(Link-stale Туре), ноле
идентификатора LSA
(Link-slate ID), а также
поле маршрутизатора-
источника LSA (Ad\enismg
Router)

Вереиг	I Тип пакета -3 I	Длина пакета		
Идентификатор маршрутизатора			
ддетифинтар «шали			Заголовок
Контрольная сумма	|	Тил аутентификации			lidtv'lTd  OSPF
—	Данные аутентификации		
Тип LSA			
Идентификатор LSA			
Маршру гиза |ии-‘с>очник ISA			
---			
Поле типа ISA

Iloie типа объявления о состоянии канала связи (Link-slate Туре) идентифицирует
тип передаваемою маршрутизатором OSPF объявлении LSA

Поле идентификатора LSA

В поле идентификатора объявления о состоянии канала связи (Link state ID) пред-
ставлено дальнейшее описание передаваемою объявления LSA, )то иоле присваивает
объявлению LSA уникальным идентификатор, который в дальнейшем используется дру-
।ими маршрутизаторами.

Лоле маршрутизатора — источника LSA

Поте маршрутизатора — источника LSA (Advertising Router) идентифицирует марш-
рутизатор, ко юры и первым отправил данное объявление LSA.

Пакеты OSPF, содержащие корректировки состояния каналов

В пакетах OSPF, содержащих сведения об обновлении состояния каналов связи (Link-
slate Update Packets, тип 4), передается маршрутная информация, отправленная в ответ
на запрос о состоянии канала связи (Link Stale Request). Другими словами, в пакетах
OSPI типа 3 передается база данных, содержащая в себе корректировки состояния ка-
налов связи. В пакетах данного типа заключена информация о состоянии различных
каналов связи той или иной сети. В один пакет обновления может быть включено не-
сколько объявлении LSA (описание различных типов LSA можно найти выше в данном
разделе). На рис. 6.36 представлен формат пакета OSPF, содержащего корректировки
состояния каналов связи.

РИСУНОК 6.36

Помимо стандартных
попей, в заголовок пакета
OSPF. содержащего
яорректирояни состояния
капало» связи, входят
с зедующие пиля поле
количества обгмпении
(A 'umber о) Advertisements)
и сими обняв юная о
состоянии канапе связи
(Link-state advertisements)

Версия | Тип пакета - 4| Длина пакета

Идентификатор маршрутизатора
Идентификатор области

Контрольная сумма	Тип аутентификации

Заголовок
пакета
OSPF

Данные аутентификации

Количество объявлений LSA

Объявления о состоянии каналов связи, LSA

Поле количества объявлении LSA

Поле ко тичества LSA (Number ot Advertisements) идентифицирует количество объяв-
лении LSA, включенных в пакет OSPF, содержащий сведения об обновлении состояния
каналов связи.

Поле объявлений LSA

Поле объявтении о состоянии каналов святи (I ink-stale advertisement) сошавтяет
большую часть всею пакета обновления (Link-state update packet). В зтом поле содер-
жится список объявлении LSA В каждое поте объявлений LSA (I ink-slate advertisement)

Я Зи 768
входит один и тот же заголовок, за которым следует собственно объявление LSA одного
из шести типов. Описание всех ihiiob объявлений LSA. а также описание полей заго-
ловка LSA представлено выше в длиной главе.

Пакет OSPF, содержащий подтверждение приема

Пакет OSPF. содержащий подтверждение приема информации об обновлении (Link-
state Acknowledgement Packet), подтверждает получение маршрутной информации. Фор-
мат этого пакета идентичен формату пакета с описанием балы данных; в пакет подтвер-
ждения приема включены также заголовки LSA На рис. 6.37 представлен формат пакета
OSPF. содержащею подтверждение приема информации об обновлении.

РИСУНОК 6.37

Пакет OSPF типи 5

(Link-state

Acknowledgement
packet), подтверждает
поучение
содержащейся в базах
данных протокоза
OSPF информации

Заголовок
пакета
OSPF

Протокол IGRP

Дистанционно-векторный протокол IGRP (Interior Gateway Routing Protocol, Про-
токол маршрутизации внутреннего шлюза) предоставляет шлюзам возможность строить
свои таблицы маршрутизации посре тством обмена информацией со смежными шлюза-
ми (соседями). Во время такого обмена информацией шлюзы получают оперативные
маршрутные данные от других устройств сети, что способствует принятию протоколом
IGRP правильною решения о выборе оптимальною пути к пункту назначения. В отли-
чие от протокола RIP. делающею выбор наилучшею маршрута только на основе коли-
чества транзитов зо пункта назначения, протокол IGRP (несмотря на то, что он при-
надлежит к классу дистанционно-векторных протоке юв) в процессе определения
кратчайшею маршрута может воспользоваться совокупностью различных показателей.
Для того чтобы удовлетворить требования к маршрутизации трафика в конкретной сети,
протокоз IGRP предусматривает возможность использования при вычислении оптималь-
ного маршрута значении нескольких показателей, в число которых входят следующие:

•	Задержка (delay). С помошыо этою показателя измеряется быстродействие кана-
ла передачи данных (speed of the link) в десятках микросекунд.

•	Полоса пропускания канала связи (bandwidth). Этот показатель отображает диа-
пазон скорости передачи данных (data transfer rale) по тому или иному канолу: от
1200 баит/сек до 10 Гбайг/сек
•	Надежность (reliability) Значение данною показателя эквинадентно части пришед-
ших без повреждения дейта>рамм, и исчисляется в процентах от 255 (число 255
соответствует ЮО-пропснтному отсутствию повреждений).

•	Нагрузка (load). Данный показатель представляет собой насыщенность канала,
другими словами долю (or числа 255) полосы пропускания, которая занята под
передачу данных по заданному маршруту (значение 0 соответствует отсутствию
нагрузки, значение 255 соответствует полной нагрузке канала по всей ширине
полосы пропускания)

•	Счетчик транзитов (hop count). Этот показатель определяет количество транзи-
тов па пути к пункту назначения; максимальное значение этого показателя — 255.

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

вычис гения стоимости маршрута к пункту назначения.

Таблица 6.8 Показатели, по которым протокол IGRP вычисляет метрику пути

Показатель	Функция
Время задержки	(Delay Time) Представляет собой количество времени, необходимого для прохождения сигнала между двумя конечными точками при отсутствии нагрузки в сети Значение данного показателя увеличивается пропорционально увеличению занятости канала и, соответственно, увеличению нагрузки в сети.
Полоса пропускания (Bandwidth).	Минимальное значение данного показателя соответствует быстродействию (измеряемому в килобайтах в секунду) самого медленнодействующего канала по данному маршруту
Нагрузка (Load)	Значение данного показателя соответствует занятости канала и показывает, какая часть полосы пропускания используется в текущий момент времени
Надежность (Reliability)	Значение данного показателя отображает коэффициент ошибок, возникших в процессе передачи данных на текущий момент Измеряется в процентах, количество которых соответствует доли пакетов, прибывших к пункту назначения без повреждений.

Возможность применения совокупности различных показателей при принятии реше-
ния о выборе оптимального маршрута обеспечивает протокол IGRP рядом дополнитель-
ных (по сравнению с протоколом RIP) характеристик:

•	Протокол IGRP поддерживает маршрутизацию в сетях большего размера, чем
протокол RIP, поскольку максимальное значение счетчика транзитов в случае
IGRP равно 255.

•	Протокол IGRP имеет возможность выполнить выравнивание нагрузки (load
balancing) при передаче трафика по сети в случае, когда существует несколько па-
раллельных маршрутов к пункту назначения

•	Протокол IGRP поддерживает использование многофакторных мшрик (complex
metrics) в процессе обнаружения оптимальных маршрутов.

Протокол IGRP вычисляет единую комплексную метрику (single composite metric) для
того или иного пут к пункту назначения на основании совокупности различных пока
гателей. Комплексная метрика объединяет установленные значения различных показа-
телей в одно число, которое и представляет собой стоимость (cost) оптимальною пути к
пункту назначения
В число xapaKiepiicuiK протокола IGRP входи iaic>{te его способность отслеживаю
информацию, касающуюся счетчика транзитов (hop count) и максимального модуля
пересылки, MTU (т.е. максимальною размера пакета, который может передаваться по
всему маршруту без фрагментации). Однако протокол IGRP не используе' эту инфор-
мацию при вычислении стоимости пути Протокол IGRF1 может также осуществлять
передачу информации по маршрутам, стоимост ь которых вычислена на основании со-
вокупности различных показателей, но но умолчанию используется значения только
таких параметров, как полоса пропускания и задержка

Котла возникает необходимость особым образом воздействовать на выбор пути, для
вычисления стоимости пути можно произвольно избрать любой из показателей а также
изменить виачения лих показателей. Полоса пропускания имеет наивысший прпори
тег среди всех показателей; маршрутизаторы обращаются именно к лому параметру при
вычислении пути по алгоритмам маршрутизации. В то же время значение этого показа-
теля не оказывает' непосредственного влияния пд обьсм данных, передачу косорото может
поддерживать отдельный канат. С другой стороны, лот показатель не влияет непосред-
ственно и на выбор пути Счедоватс тьно, при задании полосы пропускания в качестве
основного показателя при вычислении стоимости пути необходимо убедиться в том, что
заданное значение отображает фактическую скорость передачи данных по тому или
иному каналу. Если ширина полосы пропускания задана нет оррекгно, маршрутизаторы
могут выбрать неоптимальный маршрут для передачи данных в пункт назначения.

Сети, работающие под управлением протокола IGRP

Сеть, маршрутизация в которой выполняется на основании протокола IGRP, пред-
ставляет собой единый маршрутный домен (routine domain), идентифицируемый номе-
ром автономной системы (Autonomous System number). Как правило, одна компания
орзанизует и контролирует одну автономную систему, при этом каждая автономная
система считается изолированной от других.

После конфигурирования протокола IGRP на маршрутизаторах сети все эти марш-
рутизаторы используют для обмена маршрутной информацией один и тот же помер ав-
тономной системы (присвоенный системе сетевым администратором). В данном кон-
тексте термин "автономная система" описывает маршрутный домен 1GRP, а также все
принадлежащие этому домену маршрушзагоры. Несмотря на то, что для маршрутиза-
ции данных в автономной системе компании мо!утбьнь использованы и другие прото-
колы маршрушзации, номер этой АС определяет только маршрутный домен IGRP, вхо-
дящий в состав более крупной автономной системы.

Например, если сеть большого предприятия охватывает несколько континентов, и в
состав этой сети входит множество маршрутизаторов и каналов передачи данных, эту
сеть целесообразно было бы разбить на несколько автономных систем. Tai не cei менты
общей автономной системы осуществляют маршрутизацию (рафика обновления через
прозрачные домены; прозрачность домена означает, что изменения маршрутов в других
доменах не затрашвают маршруты данною домена. Маршрутизаторы, входящие в со
став одного домена, совмешно использую! сетовую информацию и приспосабливаются
к происходящим в данном домене изменениям по мере их возникновения. В то же вре-
мя изменения маршрутов в дру1 их доменах не оказывают никакого воздействия на мар-
шрутизаторы данного домена.
Установление iранни между иоменами докали туе i трафик обновления в рамках од
ною домена, что приводит к более эффективному использованию полосы пропускания
сети. Повышение производительпости всей АС достигается посредством удержания внут
ри точенных корректировок за пределами критических базовых сет ментон автономной
системы, а также за пределами имеющих низкое быстродействие каналов глобальной
сети. Разбиение обшей автономной системы на отдельные сегменты и установление
। ранни между ними позволяет также сделать прозрачным для друт их доменов отказ уда-
ленных устройств или маршрутов. Например повреждение находящегося в Японии
маршрута никак не повлияет на маршрутизаторы, которые территориально расположе-
ны в Сан Франциско.

Стабильность сети

В распоряжении протокола JGRP имеется ряд средств, позволяющих обеспечить ста-
бильность работы сети В состав этих средств, так же как и в случае использования про-
токола RIP. входит следующее периодическая рассылка сообщении об обновлении
(periodic broadcasts); триггерное обновление маршрутной информации (triggered update»
в сетях, не поддерживающих широковещательную рассылку; временное подавление из-
менений (holddown), ограничение поля видимости (split horizon); неприменимость об
ратною маршрута (poison reverse), а также подсчет трап зигов до предельною значения
(infinity count), которое в случае IGRP равно числу 256. Вес эти средства используются
для предотвращения образования маршрутных петель в процессе маршрутизации тра-
фика. Поскольку IGRP относится к категории маршрутных протоколов, осуществляю-
щих маршрутизацию по классу адресов, этот протокол не поддерживает разбиение сети
па подсети.

Помимо всею прочего, протокол IGRP использует многоканальную маршрутизацию
(multipath routing) для обеспечения стабильности cent. Многоканальная маршрутизация
обуславливает дополнительную гибкость (llexibiliiv). поскольку такой способ маршру-
тизации позволяет разделить трафик между резервными каналами со сходными или почти
сходными метриками, что, в свою очередь, обеспечивает выравнивание нагрузки. Мно-
тиканальная маршрутизация предусматривает также автоматическое переключение на
друюй канал передачи данных в случае выхода из строя исходного капала.

Таймеры протокола IGRP

Протоколом IGRP предусматривается использование в процессе маршрутизации
нескольких управляющих таймеров, которые определяют общий режим функциониро-
вания IGRP (см. табл. 6.9). Эти таймеры регулируют прохождение данных по опредс
ленному маршруту, а также контролируют истечение периодов времени, выделенных ня
какое-либо действие. Значения таймеров устанавливаются по умолчанию, но их можно
изменить, приспособив к конкретным нуждам.

Таблица 6.9 Таймеры IGRP______________________________________________________

Таймер	Функция/Значение по умолчанию 

Таймер обновления Определяет интервал между отправлением сообщений об обновлении
(Update timer) маршрутной информации По умолчанию этот интервал равен 90 секундам
Таймер	Функции Значение по умолчанию
Таймер обнаружения нерабочих маршрутов  (Invalid timer)	Задает период времени, в течение которого ма| шрутизатор должен ожидать получения сообщения об обновлении По истечении этого периода маршрутизатор должен пиъянить данный маршрут нерабочим. Значение этого периода времени по умолчанию равно 270 секундам (в три раза больше значения, установленного таймером обновления).
Таймер временного подавления изменений (Holddown timer)	Задает период времени, в течение которого подавляются любые изменения, касающиеся объявленного недостижимым пункта назначения. Маршрутизатор не принимает никаких корректировок м ipupyros к данному пункту назначения в течение периода времени, установленного таймером подавления изменений По умолчанию значение данного таймера равно 280 секундам (в три разе больше значения, установленного таймером ооновления. плюс 10 секунд)
Таймер исключения маршрута из таблицы маршрутизации (Flush)	Задает период времени, по истечении которого нерабочий маршрут удаляется из таблицы маршрутизации. Значение по умолчанию — 630 секунд (в семь раз больше значения, установленного таймером обновления)

Выравнивание и разделение нагрузки

Протокол IGRP имеет возможность направчять график по резервным маршрутам,
разделяя поток данных между эквивалентными и неэквивалентными по стоимости ка-
налами. Выполняемое при этом действие называется тыравниванием нагрузки (load
balancing). Выравнивание нагрузки позволяет извлечь максимальную пользу из полосы
пропускания на пути к пункту' назначения Если возможность разделения трафика между
неэквивалентными каналами не сконфигурирована, протокол IGRP выполняет вырав-
нивание на.рузки то 1ько между эквивалентными г „ршрутамн. В го же время протокол
IGRP не поддерживает использование в процессе передачи данных VLSM (Vanable Length
Subnet Mask, Маска подсети переменной длины), что существенно снижает >ффектив-
ность использования полосы пропускания.

Протокол EIGRP

Улучшенный протокол маршрутизации внутреннего шлюза (EIGRP, Enhanced Interior
Gateway Routing Protocol) яцдявтся собе i венност ью компании Cisco. Протокол EIGRP
считается сбалансированным протоколом смешанного типа (balanced hybrid protocol),
поскольку в нем объединены преимущества дистанционно-векторных протоколов мар-
шрутизации и протоколов маршрутизации по состоянию каналов связи.

Протоколу EIGRP свойственны следующие характеристики:

•	Протокол EIGRP обеспечивает бочее быструю по < равнению с другими протоко-
лами маршрутизации сходимость (convergence), поскольку он отправляет сообще-
ния о частичном обновлении маршрутной информации незамедлительно после
обнаружения изменении

•	Протокач EIGRP поддерживает VLSM и включает маску подсети в свои сообще-
ния об обновлении.

•	Протокол EIGRP поддерживает ря i протоколов включая IP IPX и протоколы
стгка проюколов AppleTalk
•	Протокол EIGRP хранит резервные маршруты в своей таблице маршрутизации.

•	Протокол E1GRP поддерживает маршрутизацию согласно требованиям уровня
обслуживания, заданным в поле ToS заголовка IP.

•	Протокол E1GRP. так же как и протокол IGRP, использует метрики, вычислен-
ные на основе стоимости маршрутов к пунктам назначения.

•	Протокол EIGRP поддерживает использование резервных путей при наличии
множества маршрутов к пункту назначения

•	Протокол EIGRP поддерживает как многоадресную, так и одпоадресн)ю рассылку
сообщений об обновлении маршрутной информации.

Действие протокола EIGRP

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

Протокол EIGRP решает проблемы, связанные с использованием в процессе марш-
рутизации только одного протокола, посредством поддержки функционирования сетей
под управлением совокупности протоколов маршрутизации Такая возможность прото-
кола EIGRP важна для компаний, нспользуюших различные протоколы, такие как IPX,
IP и стек протоколов AppleTalk В противном случае этим компаниям потребовалось бы
применять по одному отдельному протоколу маршрутизации на каждый из указанных
выше протоколов, что существенно увеличило бы объем трафика обновления, генери-
руемого в процессе обнаружения и эксплуатации маршрутов. Единственный недоста-
ток протокола EIGRP заключается в том, что для его реализации требуется использова-
ние только маршрутизаторов компании Cisco, та исключением случаев, когда
маршрутизаторы других сторонних производителей поддерживают протокол EIGRP.

Протокол EIGRP использует для маршрутизации трафика очень подробную каргу
топологии (т.е. тополот ическую базу данных), а также применяет алгоритм диффузион-
ного обновления (DUAL, Diffusing Update Algorithm) для расчета внесения изменении
в маршрутную информацию и предотвращения образования маршрутных петель. Про-
токол EIGRP обеспечивает отсутствие маршрутных петель, обращаясь за необходимой
маршрутной информацией к таблицам маршрутизации соседей, а также используя в
процессе маршрутизации подробную карт)' топологии сети.

Благодаря отсутствию маршрутных петель и использованию механизма триггерного
обновления маршрутной информации, процесс сходимости в сетях EIGRP происходи г
очень быстро. Кроме того, в каждой строке таблицы маршрутизации протокол EIGRP
передает маску подсети; способность протокола L1GRP поддерживать VLSM позволяет
отнести этот протокол к категории протоколов бесклассовой маршрутизации

Подобно протоколу IGRP, отличительным признаком маршрутного домена прото-
кола EIGRP (в который входят все EIGRP-маршрутизаторы и сеги данного домена)
служит номер автономной системы. Только маршрушзагоры EIGRP, совместно исполь-
зующие один и гот же номер автономной системы, могут обмениваться маршрутной
ипформакиси. поскольку только такие марырх imaiopw расе мп грн наклей как соыанныс
чачи отпою домена. Автономные шстсмьС функционирующие под управлением I- IGRP.
но имеющие различные номера АС. не мшут осуществлять обмен маршрутной инфор-
.laiutea. Сетевой администратор произвольно присваивает номер ав1ономнои системы
nocpei'.CTBOM активизации протокола EIGRP и его конфшурирования на первом марш-
рутизаторе данною домена. После присвоения номера автономной системы все истош-
ные маршрут за юры домена до1жны использовать один и тот же номер

Маршрутизаторы EIGRP. входящие в состав одной автономной системы, должны
прежде всею обнаружить близлежащие (соседние) маршрутизатору (друтими с ювами.
маршру гизаторы, непосредственно полсоелиненные к тому же, чю и данный маршру-
тизатор, юкальномс ceiMciiiy иди каналу г юбнлызой сети) В процессе Яентифнкниии
соседей маршру шзатор можез обнаружить недостижимые по причине выхода из строя
соседние Маршрутизаюры. Это нозво шет EIGRP-маршру|изаюрам быстро реагировать
на ожазы в работе сети, а также корректировать в связи с ним выбор маршрутов.

Обмен Hello пакетами управляет процессом обнархжения соседних устройств. Со-
седние маршру юза горы находят все остальные локальные маршругизаюры посредством
построения табдии, содержащих сведения о соседях маршрутидшни В этих таблицах
перечислены все обнаруженные данным маршрут и за тором соседние ус1роиства. После
сознания таких таблиц маршрутизаторы могут начинать обмен маршрутной информа-
цией со своими соседями

Несмотря на то, что нроюкол E1GRP эго не ориентированный на соединение
протокол, он все же предпринимает попытку обеспечения |арантироьанном доставки и
приема информации об обновлении посредством упорядочивания передаваемых данных
(sequencing). npenvCMoipemioro в заюловкс дешакраммы EIGRP. Получатель сообще-
ний LIGRP об обновлении должен ошравшь полверждение приема этих сообщений
^acknowledgement). Если получатель не отравляет подтверждение получения. отпрани
течь выпалпяе) новюрную передачу информации об обновлении маршре iob. По номе-
ру подтверждения отправите 1ь може1 определить, достигло ли адресата его сообщение
оо обновлении.

Преемник и потенциальный преемник

Протокол LIGRP может хранить в таблице маршру (извини несколько маршрутов к
одному пункта назначения Оптимальный маршрут (т.е. маршрут с самой низкой сто-
имостью, которая по умолчанию вычис юна на основе показа teieu полосы пропуска-
ния и задержки) определяеюя в качестве преемника (successor) Следующий по стоимо-
сти (резервный) маршрут обозначается к,.к потенциальный преемник (feasible successor i.

LlGRP-маршругизаюры ио iwiatoi сведения о маршрутах, которые являются преем-
ником н по1енциалы1ым преемником, посредством выполнения алгоритма DUAL па кар-
те ГОПОЛО1И11 построенной в процессе обнаружении сосе тих устройств Маршру гиза
торы EIGR1P в первую очередь выясняют данные о своих соседях, а затем осуществляют
обмен информацией об обновлении маршрутов с печью создания карил топологии. После
сознания карты доколоти сети LIGRP-маршру II. заторы активизируют выполнение ал-
горитма DUAL на всех маршрутах к пунктам назначения, которые ндетифицироБаны
этой картой Конечной целью производимых DUAL действий является посIроение ло-
кальной таблицы маршрутизации, н которой содержатся следующие данные:
•	Преемник и нотенпиалытыи преемник (successor, feasible successor)

•	Локальный интерфейс (local interface)

•	Адрес маршрутизатора следующего транзитною участка передачи трафика в пункт
назначения (next-hop router address).

Хранение резервного маршрута в таблице маршрут и запии позволяет EIGRP марш-
рутизаторам оперативно использовать потенциально!о преемника в качестве собствен-
но преемники, когда последний становится недоступным. Это позволяет маршрутиза-
торам продолжать маршрут и Тапию трафика к требуемому пункту назначения. Тем
временем маршрутизатор может осуществлять активный опрос соседей в поисках ттово-
ю потетшинльното преемника. Такая процедура поиска подходящих маршрутов позво-
ляет маршрутизаторам быстро обнаруживать нерабочие маршруты и приспосабливаться
к изменениям тополот ни сети.

Протокол EIGRP храпит отдельную копию каждой из упомяну гых выше таблиц для
каждого из протоколов или стеков протоколов, отя которых он выполняет маршрутиза-
цию пакетов данных, — а именно, для протоколов IP. IPX и стека протоколов AppleTalk.
Каждый отдельный экземпляр таблицы явтяется результатом выполнения отдельной
процедуры маршрутизации для каждою тн упомянутых выше протоколов. Таким обра-
том, если в сети функционируют все три указанных протокола (см. рис. 6.38), маршру-
тизаторы EIGRP создают три независимых таблицы смежности (таблицы сведении о
соседях) и три карты топологии сети в дополнение к своим собственным таблицам мар-
шрутизации В лом случае каждый мартпрх тттзатор поддерживает девять баз тайных (по
три экземпляра на каждый протокол) следующих типов база данных для хранения све-
дений о соседях, топо'ютическая база данных ц таблица маршрутизации Для по.хдер-
жания всех этих дополнительных карт и таблиц требуется большой обьем ресурсов и.
соответственно, непроизводительных затрат. Как правило, каждый маршругизатор се-
тевого комплекса обслуживает три разных протокола маршрутизации: IPX. RIP и вхо-
дящий в состав стека протоколов AppleTalk протокол RTMP (Routing Table Maintanance
Protocol, Протокол обслуживания таблиц маршрутизации). Маршрутизаторы отслежи-
вают маршрутную информацию для каждою из указанных и рот околов отдельно. Такая
организация процесса маршрутизации существенно увеличивает обьем трафика широ-
ковещательных и многоадресных сообщений для каждою реализуемого в данном сете-
вом комплексе протокола.

Типы пакетов EIGRP

Протоко т EIGRP имеет возможность тенерировагь пять типов сообщений, позволя-
ющих маршрутизаторам EIGRP информировать трут друга о состоянии своих автоном-
ных систем. Эти сообщения передаются в пакетах EIGRP пяти следующих типов:

• Приветственные паксгы/Пакеты-иолтверждения (Hello/ACK packets) — пакеты,
содержащие приветственные сообщения (Hello) или подтверждения приема ин-
формации (АСК) Пакеты такою типа отправляются в качестве мноюодрссных
обьявлеттий; маршрутизаторы EGRP используют Hello-пакеты для построения
таблицы отношений смежности (таблицы сведении о соседях). Некоторые Hcllo-
сообщения не содержат в себе никаких данных; такие сообщения представляют
собой подюерждения приема маршрутных сведении (АСК) и всегда отравляют-
ся в одноадресных деишрамм’х.

Таблицы EIGRP

РИСУНОК 6.38

Все чаршрутизаторь
EIGRP, я« едящие в состав
одной автономной
сштемы. должны
поддерживать по три
независимые базы данных
дм каждого протокою или
стека пре ’поко .ов, дм
которого выполняется
маршрутизация трафика.

•	Пикеты обновления (Update packets) — пакеты, содержащие сообщения об обнов-
лении маршрутной информации (Updates). Маршрутизаторы отправляют пакеты
обновления с целью обмена мпршрутноЙ информацией. Сведения, полученные в
результат такою обмена, маршрут шторы используют для построения карты то-
полсти сети. В сообщения об обновлении всегда включаются порядковые номе-
ра, упорядочивающие поток сообщений Маршрх гизатор отправляет пакет обнов-
ления в многоадресной или в одноадресной дейтаграмме.

•	Пакеты, содержащие обращения к соседям (Quep' packets, о предоставлении ими
маршрутных свечении. Пакеты такого типа отправляются всем соседним устрой
сгвам в том случае, кома марш[ утизагоры не имею! в своем распоряжении пре
емника или потенциальною преемника, либо когда возникаем необходимость в
выборе нового преемника. Маршрут изагеры отправляю! такие обращения к со-
седям в многоадресных и ш одноадресных дейтагрямйах. в зависимости от того,
направляется ни сообщение всем соседям (многоадресная дейтаграмма) или от-
дельно взятому соседу (одноадресная дейтаграмма).

•	Ответные пакеты (Reply packets) — пакеты, содержащие ответы (Replies) на по-
лученные обращения (Queries) о предоставлении маршрут ной информации. Мар
трети заторы отправляют ответные пакеты в качестве реакции на полученную ог
соседа просьбу о предоставлении маршрутных снедений. Сообщения-ответы все-
гда передаются в одноадресных дейтаграммах.

•	Пакеты, содержащие запросы (Request packets). Маршрутизатор может отравить
всем соседям пакет с запросом (Request) на этапе инициализации. В пакетах та-
кою типа маршрутизатор запрашивает предоставление исчерпывающего списка
всех маршрутов к пунктам назначения, необходимою win построения таблицы
маршрутизации. Пакет такою типа может бы и. также отправлен в случае, когда
маршрутизатору необходимо получить специфическую информацию от отдельно
взятого соседа. В зависимости от содержания запроса маршрутизатор может пе-
редавать такое сообщение в многоадресной или одноадресной дейтаграмме.

Протокол BGP

Протоколы, описание которых представлено выше (прогоколы категории IGP. Interior
Gateway Protocols — протоколы внутреннею шлюза), используют для передачи трафика
многократное обновление маршрутной информации и различные алгоритмы маршру-
тизации. Такой подход к ор|анизации процесса маршрутизации пакетов данных делает
протоколы категории IG Р неспособными обслуживать достаточно большие сетевые ком-
плексы. По этой причине протоколы IGP. как правило, применяются win обслужива-
ния одной автономной системы или сетевого комплекса компании Быстрое развитие
всемирной сети Интернет вызвало необходимость появления протоколов внешнего
шлюза (EGP, Exterior Gateway Protocol), которые обеспечивали бы исключающую обра-
зование маршрутных петель междоменную маршрушзаиию (loop-Ггее interdoniain routing).
Одним из протоколов категории EGP является протокол BGP (Border Gateway Protocol,
Протокол граничного шлюза) — надежный протокол, полностью соответствующий всем
требованиям к маршрутизации трафика. Он организует свою работу на выполнении
совокупности заданных правил.

RFC 1771 определяет текущую версию протокола BGP — версию 4 (BGPv4) как про-
токол маршрутизации между автономными системами (inter-aulonomous system routing
protocol) Интернет использует BGP в качестве основною протокола для организации
передачи трафика через большую информационную супермагистраль (superhighway). В
версии 4 протокота BGP реализованы некоторые расширения его возможностей, а имен-
но — VLSM (Variable Length Subnet Mask. Маска подсети переменной длины) и CIDR
(Classless InterDomain Routing, бесклассовая междоменная маршрутизация, или разбие-
ние сети на несколько подсетей одного кчасса) Эш расширения позволяют BGPv4 ус-
пешно функционировать в быстро развивающемся Интернете.

Мноите компании, подключающие свои сеги к всемирной сети Интернет, не имеют
необходимости в использовании протокола ВСРдля маршрутизации графика. В случае
если в состав сети оршнизации входит только очин шлюз (т.е. существует только один
выход из сети), соединяющий данный сетевой комплекс с внешним миром, самым про-
стым решением проблемы маршрутизации трафика за пределы сети является маршрут
по умолчанию. Такой установленный по умолчанию маршрут позволяет осуществить
передачу трафика, направленного в удаленные сети назначения, на шлюзы Интернет-
провайдера. Эти шлюзы находятся на более высокой ступени в иерархии процесса мар-
шрутизации в глобальной сети и выполняют дальнейшую передачу графика, получен-
ного от локальной сети компании, с использованием протокола BGP Реализация мар-
шрут по умолчанию иодразумепяет отсутствие непроизводительных затрат, связанных
с передачей трафика обновления локальных сетей по всему Интернету что. в свою оче-
редь, нозвочяег сократить обьем ресурсов шлюза, необходимых для хранения и обеду
живамня всех существующих в Интернете маршрутов.

Привлечение протокола BGP к  .притру ти мини трафика целесообразно в следующих
случаях:

•	Если в сети компании существует несколько выходов, соединяющих эту сеть с
одним Интернет-провайдером (как правило, полобная ситуация складывается в
случае необходимости распределения натрузки по нескольким каналам)

•	Если, с одной стороны, существует множество путей к ра тным Интернет-провай-
дерам, а. с другой стороны, вам необходимо самостоятельно регулировать пере-
дачу трафика по этим каналам.

•	1-ели политика или методы маршрутизации, реализуемые в сети компании, суще
огненно отличаются от весьма упрощенною подхода с использованием маршрута
по умолчанию. Другими словами, протокол BGP нелесообразно использон. гь,
кот ла существует* необходимость в более интеллекту алыюм выборе пути к пунк-
ту назначения на основе особых *.рнтериев.

•	Если инфраструктура гон иди иной сети используется в качестве транзитною
участка для передачи трафика друт их орган юза шт й.

Сравнительная характеристика протоколов категории
IGP и EGP

Маршрутизаторы протокола BGP (относящегося к катеюрии протоколов EGP) об-
наруживают и обрабатывают данные обо всех сетях назначения, которые находятся в
Интернете, а также информацию о маршруте, пролегающем через автономные системы
и позволяющем передать трафик в чв сети. Протоколы т.агетории IGP (такие как RIP.
IGRP, EIGRP и OSPF) продолжают контролировать процесс локальной маршруги тапни
в автономной системе даже после достижения трафиком удаленной сети назначения.

Будучи протоколом внешнею шлюза (EGP). протокол BGP соединяет независимые
автономные системы между собой Номера автономных систем, присвоенные ортани-
запией ARIN (American Regisln for Internet Numbers. Национальная служба регистре
ции адресов Интернет США), определяют маршру тные домены BGP. Номер автоном-
ной системы, присвоенный сети той н пт иной организации, идентифицирует базовый
транзитный участок Интернета. В каждой автономной системе motvi одновременно
функционировать несколькс про.околов 1(.>Р, однако количество и типы таких шна-
мичес .их нроюколов не имеют никакою опюшешзя к протоколу BGP и являются про-
зрачными для него. Несмотря на то. что протоке т BGP можно в какой-то мерс рассмат-
ривать и как протокол впу трепнею шлюза  IGP), использовать сю оолсс целесообразно
в качестве протокола внешнею шлюза (LGP).

В настоящее время Интернет состоит из множества транзитных участков. Различные
организации конгро; ируют маршрутизацию графика через эти участки, но ни отна opia-
низацпя не управляет всей их совокупностью. Громадные размеры всемирной сети
Интернет и О1сутствис централизованною управления вызвали необходимое) ь в суше-
сгвонвнии такого upoioKOia. как BGP падежного про юкола, полностью соогветстну-
louieio всем требованиям к маршрутизации трафика и opiанизуюнге!о свою работу на
выполнении совокупности заданных правил.

В настоящее время в Интернете существует более 105 тысяч маршрутов. Каждый
маршрутизатор BGP, существующим в Интернете, должен выяснять и обрабатывать
маршрутную информацию, а также осу шее i влить интеллектуальный выбор нуги с це-
лью обеспечения передачи дейтаграмм но всему Ин!ернсгу; при этом требуется опре-
деленный объем ресурсов (таких как память и быстродействие центральною процессо-
ра). необходимых juim обработки информации такою рола. Проюко ту BGP необходимо
иметь возможность обнаруживать и устранять проблемы (например, вышедшие изстроя
сети или маршрутные петли), которые возникают во всем лом межсетевом лабиринте,
состоящем из множества маршрутизаторов. траттштных участков и громадного количе-
ства маршру топ.

Ч? АДРЕСА. ПО КОТОРЫМ МОЖНО ВЫЯСНИТЬ ТЕКУЩУЮ ИНФОРМАЦИЮ О
МАРШРУТИЗАЦИИ В ИНТЕРНЕТЕ.

В настоящее время информацию о текущих таблицах маршрутизации в Интернете можно
найти по указанным ниже адресам:

•	http://antc.uorcgon. edu/route-viows/dynemics

•	http://www.nicvax.org/~jhina/routxng/bgp-hist html

•	http: //www.apnic net/stats/bgp/TOTAL/totalann html

Способность протокола BGP обнаруживать и устранять проблемы, возникшие в про-
цессе маршрутизации трафика, непосредственно связана с его способностью полною
устранения маршрутных петель из процесса маршрута затши данных в пункты назначе-
ния Реа 1изовлтъ версию 4 протокола BGP можно следующими двумя способами:

•	Полная пнгетрания (lull mesh) Tono циня септ на основе по тной интет рации (lull-
mesh topology) требует наличия соединений ГСР меж ту всеми маршру in за тора-
ми BGP. входящими в состав одной автономной системы, что позволяет шлю там
быстро обнаруживать маршрутные неиит и удалять их.

•	Частичная интетрання (parlial mesh). I ополот ия сети на основе частичной интс!
ранни (partial mesh topology) не требует or маршрутизаторов BGP поддерживать
логические соединения друг с другом Эю сокращает количество соединений TCP,
по открывает вероятность образования маршрмных пе1ель.

С целью увеличения надежности передачи данных протокол BGP обеспечен одной
характеристикой которой nei у гругих протоколов маршрутизации: BGP использует
протокол TCP (Transmission Control Protocol. Протокол управления передачей данных)
для обеспечения ориентированной на соединение, надежной транспортировки своею
графика обновления Все протоколы казеюртнт IGP являются не ориентированными на
создание соединении протоке тами. т.е. они не требуют наличия ло1ического соедине-
ния для передачи информации лрутим шлюзам. В большинстве случаен протоколы IGP
перелают свои сообщения об обнов leinni маршрутной информации в широковешатель-
нои или многоадресной рассылке, н только некоторые из них пользуются одноадрес-
ной рассылкой сообщен ни. Однако каким бы ни был способ рассылки сообщении об
обновлении, проюколы катсюрии IGP выполняю! эту рассылку с помощью протоко-
лов IP или UDP.

Протокол BGP гарантирует надежную доставку данных, выполняя эту доставку на
основании предоставляемою протоколом TCP логическою сетевого соединения, кото-
рое сопровождается упорядочиванием и подтверждением сеансов обмена маршрутной
информацией между равноправными маршрутизаторами BGP. Для взаимодействия с TCP
протокол BGP использует общеизвестный порт TCP с номером 179. В отличие от пре-
дыдущих версии BGP. протокот BGPv4 поддерживает бесклассовую маршрутизацию
посредством включения маски подсети в сообщения об обновлении. В таких сообщени-
ях передается описание пунктов назначения (другими словами, информация о дости-
жимости сети, network reachability information). В от шчие от других протоколов, прото-
кол BGPv4 поддерживает также резюмирование маршрутов (route summarization) или
объединение нескольких адресов водном обьявлении о маршруте (aggregation)

Маршрутизаторы BGP

Маршрутизаторы, размещенные в разных cei ментах обслуживаемой протоколом BGP
сети, имеют разные названия В сети, функционирующей пол управлением протокола
BGP, существует четыре типа маршрутизаторов:

•	Маршрутизаторы — спикеры BGP (BGP speaker routers) — собственно маршру-
тизаторы BGP.

•	Равноправные, или соседние маршрутизаторы (peer or neighbor routers) — марш-
рутизаторы. входящие в состав одного сегмента сеги

•	Внутренние равноправные маршрутизаторы (internal peer routers) — маршрутиза-
торы, имеющие одинаковый ранг в пределах одной автономной системы

•	Внешние равноправные маршрутизаторы (external peer routers) — маршрутизато-
ры. входящие в состав смежных автономных систем

Рассмотрим пример участия маршрутизаторов BGP различных типов в процессе мар-
шрутизации графика. Если в состав автономной системы 100 входят три шлюза, соеди-
ненных между собой ио принципу полной интеграции все BGP-маршрутизаторы этой
АС должны быть связаны между собой соединениями TCP. Эти маршрутизаторы фор-
мируют внутреннюю BGP-связъ (IBGP) со своими соседями по автономной системе.
Шлюз, соединяющий автономную систему 100 с другой АС. например, с автономной
системой 200, формирук>1 внешнюю BGP-связь (EBGP) со шлюзом друтои автономно!!
системы. Тин связи, сформированной между двумя равноправными устройствами. за-
лает правила на основании коюрых осуществляется обмен маршрутными данными
между ними (см. рис 6.39)

Все BGP-мвршрутизаторы формируют определенный тип связей с лрутими маршру-
тизаторами. Сам тин равноправных связей зависит оттого, в состав каков автономной
системы входят маршрутизаторы. Два маршрутиэатора. соединяющие две разные авто-
номные системы, являются внешними равноправными маршрутизаторами (external peers).
Маршрут изаторы. входящие в сошав одной автономной системы, являются внутренни-
ми равноправными маршру ги заторами (internal peers).
РИСУНОК 6.39

Правила обмена
маршрутной информацией
между маршрутизаторами
ВСР меняются в
зависимости от того, связь
какого типа установлена
между двумя
равноправными
маршрутизатора «и

Совокупность соединений BGP с одним Интернет-провайдером

Маршрутизаторы, входящие в состав одной и гои же автономной системы, называ-
ются lBGP-маршрутизаторами IBGP-ыпршрутнзаторы не имеют возможности объявлять
маршрутную информацию тем маршрутизаторам, которые не являются их локальными
соседями — локальными равноправными маршрутизаторами (internal peers).

Маршрутизаторы, входящие в состав разных автономных систем, называются EBGP-
маршрутизаторами. EBGР-маршрутизаторы могут передавать маршрутную информацию
всем другим соседним маршрутизаторам через все интерфейсы

Действие протокола BGP

Во время активизации протокола BGP на том или ином шлюзе этому шлюзу присва-
ивается номер автономной системы, соответствующий номеру АС, в состав которой он
входиI. Помимо этого, необходимо сконфигурировать действующий от имени BGP мар-
шрутизатор (BGP speaker, спикер BGP) с адресами всех равноправных с ним соседних
маршрутизаторов (peers). Когда спикер BGP начинает работу в оперативном режиме,
он должен установить соединения 1 СР со всеми равноправными маршрутизаторами (как
внутренними, так и внешними), чтобы обеспечить возможное и. обмена маршрутной ин-
формацией BGP между ними. Koi да равноправные BGP-маршрутизаторы устанавлива-
ют TCP-соединения, они могут начинать обмен марщругпой информацией о достижи-
мости соседнего устройства или сеги (reachability information». Результатом такого обмена
является построение таблиц маршрутизации BGP-маршрутигаторов. Протокол BGP
использует информацию, содержащуюся в сообщениях о достижимости сети или соседа
для построения карт тополог и и автономных систем, в которых полностью исключена
возможность образования маршрутных петель

После того как состоялся первоначальный обмен всем содержимым таблицы марш-
рутизации. равноправные маршрутизаторы обмениваются только информацией, отобра-
жающей реальные изменения в топологии сети. Протокол TCP отслеживает всю проце-
дуру обмена маршрутной информацией посредством упорядочивания передаваемых
дейтаграмм (sequencing) и выдачи подтверждений об их получении (acknowledging). TCP
использует сообщения о поддержании соединения активным (Kecpalives) для того, что-
бы поддерживать соединения между равноправными маршрутизаторами BGP даже тог-
да, когда не происходит активного обмена данными между ними. Протокол BGP гене-
рирует предупреждающее сообщение (Notification message) при обнаружении ошибки,
вызываюшеи разрыв ТСР-соединення между равноправными маршрутизаторами BGP
В случае отказа соединения TCP прекращает работу и сам протокол HGP.
Маршру и гаторы BGP не храня) маршрутную информацию в одной таблице марш
рутизации (как это происходит с маршрутами, обнаруженными протоколами катсюрии
IG Р> ВОР-маршру|изаторы. в зависимости от конкретной реализации, мшу гл ибо под-
держивать до грех дополнительных таблиц маршрутизации. либо объединить их в одну
таблицу. В ю же время, независимо от кочичесгна поддерживаемых маршрутизаторами
BGP таблиц, каждый маршрутизатор — спикер BGP (BGP speaker) — должен иметь
возможность дифференцировать полученную информацию последующим категориям;

•	Полученная информация об обновлении маршрутов (i.e, корректировки)

•	Маршру шая информация, подлежащая передаче друг им маршру шза юрам

•	Локальная габмина маршрутизации протокола BGP.

Спикеры BGP (speakers) информирую) равноправные маршру г и за юры (peers) об
изменениях маршруюн к пунктам назначения посрсдсгвом обмена сообщениями об
обновлении (Updates). В случае если какой щбо маршрут становнтвя недоступным,
спикер BGP объявляет в своем сообщении об обновлении, отравленном соседям, что
он HJiaHitpyei изъять эго) маршрут из обращения (изолировать его), следовательно, со-
седние устроиова также юлжны удалить его из своих габлиц млршрупвании.

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

В отличие ог всех протоколов категории TGP, протокол BGP при выборе нуги к пун-
кту назначения не руководствуется такими (показателями, как количество транзитов,
задержка, полоса пропускания, надежность, нагрузка или MTU. Более предпочтитсль
ным для BGP является испольгование а)рибутов нут но иерархическому принципу для
обеспечения выбора оптимальною пути к пункту назначения. (Атрибуты BGP рассмат-
ривакнея ниже в данной i лаве).

Заголовок RGP и его поля

Первой частью всех дейта) рамм BriP является обшии для всех питов сообщений BGP
заголовок, имеющий длину |й байшв. На рис 6.4)1 представлен общин формат заголов-
ка BGP

Маркер

РИСУНОК 6.4С

Все Мтигриммы BGP
имеют заголовок
ид< нтичиаго tfutpjudma

Длине	Тип со даяния = 1

Первичное сообщение Оообщи не об обновлении,
Тведг «ленив об ошибке или С’собщвм? о г „ддержаяии с единения ективкини
Поле маркера

Поле маркера (Marker) имеет длину до 16 байтов. Это поле идентифицирует обмен
первичными запросами (Open requests) между равноправными маршрутизаторами BGP,
а ыкжетип реализуемой в BGP аутентификации данных.

Поле длины дейтаграммы BGP

Поте длины дейтаграммы BGP (Length), имеюшее размер 2 байта, идентифицирует
длину (в байтах) дейта1раммы BGP, включая заюлоиок BGP.

Поле типа сообщения BGP

Поле шил сообщения BGP (Туре) длиной 1 байт идентифицирует тип передаваемо
то протоколом BGP сообщения Маршрутизаторы BGP могут передавать четыре различ-
ные tuna сообщений:

•	Первичное сообщение (Open message)

•	Сообщение об обновлении (Update message)

•	Сообщение, содержащее уведомление об ошибке (Notification message)

•	Сообщение о поддержании соединения активным (Keepalive message)

Oi значения, указанною в поле типа сообщения (Туре), зависит формат оставшейся
части заголовка дейтаграммы BGP. В последующих разделах текущей 1лавы представ-
лено описание формата заюловка BGP, соответствующего определенному типу сооб-
щения.

Первичные сообщения

Маршру tn заторы BGP отравляют первичные сообщения (Open messages), тип I,
сразу же после установления соединения равноправного маршрутизатора с ТСР-портом
179. Первичное сообщение BGP инициирует формирование равноправных отношении
между внутренними и внешними равноправными маршрутизаторами. На рис. 6 41 пред
ставлен формат заголовка дейтаграммы BGP, передающей первичное сообщение (Open
message).

Загонок*
домгаграммы BGfM.
содержащей
сообщение BGP

Маркер	
Длине дейтаграммы BGP	Тип сообщения »1 | Версия
Номер ввтономной системы отравителя	Тайм-аут передни сообщений
Идентификатор спикера BGP	
Длина поля диполнитепьных параметре:! | ДопопиитепьнВ« г драметрь	

РИСУНОК 6.41 Загоювок дейтаграммы ВОР. передающей первичное сообщение (Open message)
нк иочает шесть дополните 1Ы1Ы.х полей- пом версии (Version), поле номера автономной системы
отправители (Му Autonomous System), поле тайм аута передачи сообщений (Hold Time), note
идентификатора спикера ВНР (BGP Identifier), поле длины поля дополнительных параметров
(Optional Parameters Length), поле допо тительных параметров (Optional Parameters).
При передаче первичного сообщения (Open message) к заюловку BGP присоединя-
ется шесть дополнительных полей. Описание этих полей представлено в таблице 6.10.

Таблица 6.10 Дополнительные поля заголовка дейтаграммы BGP. передающей первичное
сообщение (Open message)______________________________________________________

Поле	Размер (в битах.)	Описание
Версия (Version)	8	Отображает используемую версию  BGP (в настоящее время используется версия 4)
Номер автономной системы (Му Autonomous System)	16	Отображает номер автономной системы отправителя
Тайм-аут передачи сообщений  (Hold Time)	16	Регулирует период времени между отправкой сообщений о поддержании соединения активным (Keepalives) и сообщений об обновлении {Update messages)
Идентификатор спикера BGP (BGP Identifier)	32	Однозначно идентифицирует маршрутизатор — спикер BGP (т.е. идентифицирует отправителя).
Длина поля дополнительных параметров (Optional Parameters Length)	8	Идентифицирует длину поля любых возможных дополнительных параметров, таких как данные аутентификации. Если нет никаких дополнительных параметров, а этом поле устанавливается значение 0. Если дополнительные параметры есть, данное поле идентифицирует предполагаемый размер (в байтах) поля дополнительных параметров, которое следует за данным полем
Поле дополнительных параметров (Optional Parameters)	переменная длина	Представляет описание реализуемых протоколом BGP дополнительных параметров, таких как аутентификация

Сообщения об обновлении

В сообщениях об обновлении (Update messages), тип 2, содержится информация о
маршрутах к достижимым пункты нашачення в сети. Равноправные маршрутизаторы
обмениваются между собой сообщениями об обновлении с целью обнаружения и даль-
нейшей эксплуатации маршрутов На рис. 6.42 представлен формат заголовка дейтаграм-
мы BGР, передающей сообщение об обновлении (Update message).

Сообщение об обновлении (Update message) присоединяет к заголовку BGP шесть
дополнительных полей. Описание этих полей представлено в таблице 6 11.

Таблица 6.11 Дополнительные поля заголовка дейтаграммы BGP, передающей сообщение об
обновлении (Update message)______________________________________________________

Поле	Длина (в битах)	Описание
Длина поля неприменимых маршрутов (Unfeasible Routers Length)	16	Специфицирует изолированные маршруты. Если таких маршрутов нет, в этом поле устанавливается значение 0. Если маршруты изымаются из обращения, в этом поле указывается длина (в байтах) поля изолированных маршрутов.
Поле	Длина (в битах) Описание
Изолированные маршруты (Withdrawn Routes)	переменная	Содержит список всех  длина	маршрутов, изъятых из  обращения.
Общая длина поля атрибутов пути (Total Path Attribute Length)	16	Идентифицирует общую длину (в байтах) поля  атрибутов пути, включенного в данное сообщение
Атрибуты пути (Path Attributes)	переменная	Определяет объявленные атрибуты пути. В это  длина	поле могут быть включены две основные  категории атрибутов общеизвестные и необязательные атрибуты. Атрибуты пути рассматриваются более подробно ниже.
Данные о достижимых пунктах назначения (Network Layer Reachability Information)	переменная	Содержит список всех объявленных  длина	маршрутизатором пунктов назначения.

Заголовок
дейтаграммы BGPv-T
содержащей
сообщение BGP

Мьрыр		
Длина дейтаграммы BGP		Тип сообщения = 21 Длина поля...
... неприменимых маршрутов	Изолированные маршруты	
Общая длина тюля атрибутов пути		Атрибуты пути
Данные о достижим ых пунктах назначен».		

РИСУНОК 6.42 Заголовок дейтаграммы В6Р, передающей сообщение об обновлении (Update message),
включает пить допо иште 1ьиых полей: note длины поля неприменимых маршрутов (Unfeasible Routes
Length), поле илолирлванных маршрутов (Withdrawn Routes), note общей длины поля атрибутов пути
(Total Path Attributes), поле атрибутов пути t Path Attributes), поле данных о достижимых пунктах
назначений (Network I jeer Reachability Information)

Уведомление об ошибке

Сообщения BGP, содержащие уведомления об ошибках (Notification messages), тип
3, генерируются маршрутизаторами BGP в случае возникновения ошибок в процессе
маршру ГИЗ.П1ИИ. Когда маршрутизатор отправляет уведомление об ошибке (Notification
message), протокол BGP прекращает работу, а равноправные маршрутизаторы разрыва-
ют установленные ими npvi с другом соединения TCP. На рис. 6.43 представлен формат
заголовка дейтаграммы BGP. передающей сообщение с уведомлением об ошибке
(Notification message).

Сообщение BGP. содержащее уведомление об ошибке (Notification message), присо-
единят к заюловку BGP гри юиол ни тельных ноля. Описание этих полей представле-
но в таблице 6 12
Заголовок
дейтаграммы BGfM.
содержащей
сообщение BGP

Мяр.тф		
Длине дейта граммы BGP	I Тип сообщения = 31	Кед ошибки	
Подкод ошибки	Информация об ошибке

РИСУНОК 6.43 Заголовок дейтаграммы BGP. передающей уведомление об ошибке (Notification
message). включает три пошипите юных пп >я; поле кода ошибки (Error Code), поле подхода ошибки
(Error Subcode), поле информации об ошибке (Data).

Таблица 6.12 Поля заголовка дейтаграммы BGP, передающей уведомление об ошибке

(Notification message)_______________________________________________________________

Поле	Длина (в битах)	Описание
Код ошибки (Error Code)	в	Отображает тип (типы) ошибки (ошибок), возникшей в процессе маршрутизации
Подкод ошибки (Error Subcode)	8	Представляет более подробные сведения о тиле возникшей ошибки
Информация об ошибке (Data)	переменная длина	Диагностирует причину, которая привела к отправке предупреждения об ошибке. Значение данного поля зависит от значений, установленных в двух предыдущих полях (поле кода ошибки и подкода ошибки). Подробное описание значений, устанавливаемых в данных полях, можно найти в RFC 1771

Сообщения о поддержании соединения активным

В ответ на первичное сообщение (Open message) проюкол BGP отправляет сообще-
ния типа 4 — сообщения о поддержании соединения активным (Keepalive messages),
подтверждающие установление соединений между равноправными маршрутизаторами
(внутренними или внешними). После установления между маршрутизаторами BGP рав-
ноправных отношений соседи продолжают обмен сообщениями о поддержании соеди-
нения активным (Keepalive messages) для тою, чтобы гарантировать соединение и удо-
стовериться в достижимости равноправных маршрутизаторов. На рис. 6.44 представлен
форма! заголовка дейтаграммы BGP, передающей сообщения о поддержании соедине-
ния активным (Keepalive message).

Заготовок
сообщения

BGP-4

РИСУНОК 6.44 Сообщении о поддержании соединения активным (keepalive messages) передаются в
дейтаграмме BGP, заголовок которой состоит из общих для всех типов сообщении полей; в этом
заголовке отсутствует допа знительная информация Сообщения данного типа поддерживают
соединение междуравноправными маршрутизаторами BGP даже тогда, когда между ними не
происходит активного обмена информацией
Атрибуты путей

Маршрутизаторы BGP используют атрибуты путей (path attributes) для описания ха-
рактеристик маршрутов к достижимым пунктам назначения, а также для обнаружения
oiiiiiMiuibHoio пути. Спикеры BGP тщательно анализируют и надлежащим образом клас-
сифицируют эти атрибуты, располагая их в порядке возрастания их значений. Значения
атрибутов пути можно peiv тировать, что и обеспечивает свойственную протоколу BGP
тттбкость. Все атрибуты пути протокола BGP подразделяются на четыре катетории, опи-
сание которых представлено в таблице 6.13.

Таблица 6,13 Категории атрибутов пути

Категории	Описание
Общеизвестный обязательный (Well-known mandatory)	Все реализации протокола BGP должны распознавать общеизвестные атрибуты. Эти атрибуты должны быть включены во асе сообщения об обновлении. Спикер BGP должен полностью обрабатывать атрибуты данной категории.
Общеизвестный необязательный (Well-known discretionary)	Атрибуты данной категории могут присутствовать или не присутствовать в сообщении об обновлении. Если они входят в состав сообщения, все реализации BGP должны распознавать эти атрибуты, а в обязанности спикеров входит их полная обработка
Дополнительный транзитивный (Optional transitive)	Спикер BGP. получив этот атрибут, передает его другому маршрутизатору Распознавание данного дополнительного атрибута не входит в обязанности получателя.
Дополнительный нетранзитивный (Optional nontransitive)	Получателю нет необходимости распознавать или обрабатывать этот дополнительный атрибут. Спикер BGP не передает данный атрибут своим соседям.

Сообщения об обновлении протокола BGP (Update messages) объявляют атрибуты
пути указанием в иоле атрибутов пути (Path Attributes) зато'товка BGР соотнетствутоще-
го кода типа атрибута. Эти коды, а также сами атрибуты, определены в RFC 1771. В
таблице 6.14 представлено описание атрибутов пути протокола BGP

Таблица 6.14 Атрибуты пути протокола BGP___________________________________________

And типа	Атрибут/	Описание	

1 Источник	Общеизвестный	Идентифицирует источник информации о

(Origin)	обязательный	маршруте (т.е.	происхождение маршрута.

(Well-known mandatory) обнаруженного	и помещенного в таблицу

маршрутизации тем маршрутизатором, который
передает описание маршрута). Источники
информации о пути могут быть следующими:
• IGP исходной автономной системы
(информация и маршруте получена через
достижимые пункты назначения, являющиеся
внутренними по отношению к автономной системе, в
состав которой входит передавший исходное
сообщение маршрутизатор).

•	EGP (информация о маршруте получена
посредством протокола EGP).

•	Неизвестный источник (нет исчерпывающей
информации о маршруте) 
Лог) типа	Атрибут	Ошиание
2 —Путь через AC (AS path)	Общеизвестный обязательный (Well-known mandatory)	Содержит список автономных систем, представляющий собой обозначенный номерами АС путь к определенному пункту назначения. Например, пункт назначения с адресом 192.15.2.0 может находиться на пути, пролегающем через автономные системы с номерами 100, 300 и 800: это означает, что достичь необходимой сети можно еа три пег входа через автономные системы. Кеда происходит передача маршрутной информации между внешними равноправными маршрутизаторами DGP (EBGP-маршрутизаторами), маршр,гизатор, который передает сообщение об обновлении в новую АС, присоединяет номер своей АС к двнной цепочке АС. Это позволяет спикерам BGP идентифициропать автономные системы, которые маршрут пеоесек во время прохождения по Интернету.
3 - Следующий транзит (Next Нор)	Общеизвестный обязательный (Well-known mandatory)	Идентифицирует IP-адрес маршрутизатора следующего транзитного участка пути, или маршрутизатор грани, используемый для того, чтобы достичь пункта назначений
4 - Селектор выходов (Muitl-Exit-Disc), см. рис. 6.45	Доги лнительный нетранэитивный (Optional nontransitive)	Позволяет маршрутизаторам автономной системы оказывать влияние на решения о выборе маршрутов, принимаемые маршрутизаторами другой автономной системы Когда существует несколько точек о хода для соединения двух автономных систем, маршрутизаторы одной из них имеют возможность передать внешнему соседнему маршрутизатору объявления, содержащие различные значения атрибута "Селектор выходов" (Multi Exit Discriminator. MED) На основе этих значений маршрутизатор — получа"ель подобной информации принимает решение о выборе маршр) га1 чем меньше значение MED, тем лучше путь. Объявляя один из me ршрутов с меньшим значением MED, маршрутизаторы отдают этому маршруту предпочтение перед другими маршрутами Данный атрибут является единственным атрибутом, поддерживающим такую функцию.
5 - Локальное предпочтение (Local Ргеге елее) (см рис. 6 46}	Общеизвестный необязательный (Well-known discretu nary)	Этот атрибут применяется только маршрут повторами входящими в состав здной автономной системы, и не передается в другие автонимные системы. Если существует несколько путей для передачи трафика за пределы данной автономной системы, входящие в ее состав маршрутизаторы могут установить для одного из путей значение атрибут ! локального предпочтения, оолее высокое по сравнению со значениями других путей, указывая тем самым на предпочтительный маршрут. Внутренние маршрутизаторы осуществляют дальнейшую передачу трафика на основе этой информации, а именно — посредством выбора пути с наивысшим значением атрибута локального предпочтения.
Код типе	Атрибут	Описание
6 - Объединение нескольких маршрутов в один элемент таблицы маршрутизации (Atomic aggregate)	Общеизвестный необязательный (Well-known discretionary)	Это значение атрибута устанавливается только после конфигурирования на маршрутизаторах функции резюмирования маршрутов. Когда системный администратор конфигурирует такую функцию, маршрутизатор — источник объединенного маршрута устанавливает данное значение атрибута пути. Далее этот атрибут включается во все объявления о маршруте, информирующие другие маршрутизаторы BGP о том, что объявленный маршрут представляет собой совокупность других маршрутов, не обозначенных в сообщении об обновлении.
7 - Объединитель (Aggregator)	Дополнительный  транзитивный	Данное значение атрибута устанавливается только в случае, когда установлен атрибут объединения маршрутов в один элемент таблицы маршрутизации (Atomic Aggregate) Это значение идентифицирует объект (автономную систему и маршрутизатор), выполнивший первоначальное объединение нескольких маршрутов в один.

РИСУНОК 6.45

Атрибет "Се ыктор выходов" (MED. Multi
Exit Discriminator) оказывает влияние на
выбор маршрутов между автономными
системами Например, если Интернет-
провайдер использует для связи с
обслуживаемой им автономной системой не
один путь, а совокупность путей, он
wu мест сконфигурировать
маршрутизаторы с разными точениями
ampiivvma MED. Это. в свою очередь,
позволит провайдеру воздействовать на
выбор пути, который используется
находящимся ниже в сетевой иерархии
маршрутизатором для передачи трафика в
требуемый пункт назначения.

MED, Селектор выходов

Сравнительная характеристика протоколов BGPv3 и

BGPv4

Протоколы BGP\3 (RFC 1267) и BGPv4 являются несовместимыми и не могут об-
служивать один и тог же процесс маршрутизации В то же время су шествует возмож-
ность обеспечить функционирование этих двух версии протокола BGP в смешанной
среде посредством конфи i у ри рован ня маршрут заторов на поннтерфейсной основе (т.е.
но одному интерфейсу на каждый протокол). В таблице 6.15 представлено кражое опи-
сание различии между UGPv3 и BGPv4.
Покальное предпочтение

РИСУНОК 6.46 Действие атриб/та Локальное предпочтение" (Loco! Pre'erence) распространяется
только на маршруты к 'Лнктам назначения, которые находятся в преде шт одной автономной
системы Этим атрибутом обозначается самый предпочтите и>ный не ршрут из всего множества
существуют1/*' маршрутов к пунь ту намачения. В данном примере автономная система 300 имеет
несколько исходящих маршретос к автономным системам 100 и 200 Маршрутизатор /ыоириет путь
с максима зы/ым значением атрибута локального предпочтения в качестве своего исходчшего
маршрута В данном случае маршрутизатор выбирает путь через крайний зевый маршрутизатор
который имеет более высокое значение (200) атрибута /ока /ьнол предпочтении.

Таблица 6.15 Сравнительная характеристика протоколов BGPv3 и BGPv4

Хорактерист ика	BGPvJ	BGPv4
Поддерживает VLSM (т.е. бесклассовую маршрутизацию), включает маску подсети в сообщение об обновлении.	нет	Да
Поддерживает объединение нескольких маршрутов в один.	нет	да
Полная или частичная	полная	оба
интеграция	интеграция	варианта
Поддерживает следующие атрибуты: локальное	нет	да

предпочтение, объединение нескольких маршрутов в
один элямс -it таблицы маршрутизациии, объединитель

Резюме

Протоколы маршрутизации предоставляют маршрутизаторам возможность тинами-
чески обнаруживать маршруты к пунктам назначения, а также приспосабливался к из-
менениям тополог ни сети Назначение любого проюкола маршрутизации, будь то про-
токол BGP или протокт RIP, одно: передача дейтаграмм в требуемый пункт назначения.

Протокол RIP относится к категории дистанционно-векторных прлтокочов. Соот-
ветственно. протокол RIP. аналогично другим цистанпионно-векгорным протоколам,
использует расстояние до пункта назначения (измеряемое в количестве транзитов) для
выбора оптимального маршрута. Протокол RIP имеет следующие характеристики: RIP
строит свою работ  на основе широковешатетьнозз рассылки сообщений; RIP приши-
лежит к категории протоколов маршрутизации внутреннего шлюза <IGP); применение
протокола R1P наиболее целесообразно в небольших сетях; RIP использует днетанци-
онно-векгорный алгоритм для вычисления оптимальных маршр\тов. Существует две
версии протокола RIP: RIPvl и RIPv2.

Протокол OSPF использует алгоритм вычисления оптимальною маршрута на осно-
ве состояния каналов связи для принятия более инте ллектуальных, по сравнению с про-
токолом RIP. решений относительно выбора пути к пункту назначения Протокол OSPF,
подобно другим протокотам маршрутизации по состоянию каналов связи, учитывает при
выборе оптимального маршрута либо один из следующих показателей, либо их сочета-
ние: производительность канала связи (полоса пропускания), задержка, надежность,
нагрузка и максимальный модуль пересытки (МТС). Протокол OSPF демонстрирует ряд
преимуществ ттад дистанционно-векторными протоколами; в то же время протокол RIP
до сих пор остается самым широко используемым протоколом маршрутизации, главным
образом благодаря своей простоте.

Дистанционно-векторный протокол IGRP, подобно протоколу OSPF. предоставляет
маршрутизаторам возможность строить свои таблицы маршрутизации посредством об-
мена маршрутной информацией со смежными шлюзами (те. соседями). В отличие от
протокола RIP. который также относится к категории дистанционно-векторных прото
колов, протокол IGRP использует ряд показателей для обеспечения выбора оптималь-
ного пути к пункту назначения. Метрика, вычисляемая на основе такого ряда показате-
лей, называется комплексной метрикой. При вычислении оптимальною маршрута
протокол IGRP учитывает такие показатели: полоса пропускания, задержка, надежность
и нагрузка Подобный подход к организации процесса маршрутизации позволяет про-
токолу IGRP обслуживать большие сеги, а также контролировать выравнивание нагрузки
(распределение трафика по нескольким маршрутам).

Протокол EIGRP, рассматриваемым как смешанный протокол, объединяет преиму-
щества протоколов марщрутизапии по состоянию каналов связи и дистанционно-век-
торных протоколов. Все упомянутые выше протоколы — RIP. OSPF. IGRP и EIGRP —
относятся к категории протоколов внутреннего шлюза (IGP).

Быстрое развитие всемирно» сети Интернет вызвало необходимость в существова-
нии надежного прогоколн, полностью соответствующего всем требованиям к маршру
тизании трафика и организующею свою работу на выполнении совокупности заданных
правит Такой протокол должен был обладать гибкостью, которая позволила бы ему
успешно функционировать в постоянно меняющемся Интернете Именно таким прото-
колом, отвечающим всем упомянутым выше требованиям, оказался протокол гранич-
ного шлюза (BGP). Протокол BGP, принадлежащий к категории протоколов внешнего
шлюза (EGP), основывает свои выбор маршрута к пункту назначения на значениях ат-
рибутов пути. Расширения возможностей BGP (по.гдержка VLSM, объединение марш-
рутов и C1DR, бесклассовая междоменная маршрутизация) позволили протоколу BGP
стать основным протоколом маршрутизации трафика в Интернете.

В таблице 6.16 представлены краткие итоговые снедения о характеристиках, свой-
ственных каждому из рассмотренных н текущей главе протоколов маршрутизации.
Характеристика	RIPvl	RIPv2	OSPF	IGRP	IGRP	BGP
Классификация	дистанционно- векторный	дистанционно- векторный	по состоянию каналов связи	дистанционно- векторный	смешанный	селективный
Количество транзитов	15	15	отсутствует	ЮО-255	отсутствует	отсутствует
Количество секунд между периодичес- кими сообщениями об обновлении	30	30	триггерное обновление	90	триггерное обновление	отсутствует
Широковещательная да рассылка сообщений		Да	многоадресная	да	многоадресная	нет
Передается вся таблица	да	ла	только изменения	да	только изменения	только изменения
VLSM	по классу адресов	бесклассовая	бесклассовая	по классу адресов	бесклассовая	бесклассовая
Основной показатель метрики	транзиты	транзиты	полоса пропускания	полоса пропускания и задержка	полоса пропускания и задержка	атрибут пути
ToS/QoS	нет	нет	да	да	да	да
Тип соединения	UDP	UPP	UDP	UDP	UDP	TCP

250 Глава 6
Вопросы для повторения

I.	К какой категории относится протокол RIP?

2.	Перечислите характеристики протокола RIP

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

5.	Сколько записей таблицы маршрутизации может передавать протокол RIP в своем
широковешазельном сообщении?

6	Какое максимальное количество транзитов, согласно протоколу RIPvl, может пе-
ресечь дейтаграмма в случае, если пункт назначения считается недостижимым?

7.	Назовите три характеристики, свойственные протоколу RIPv2, и не свойственные
протоколу RIPvl.

8.	Почему протокол RlPv2 фактически вышел из употребления?

9.	Назовите недостатки протокола RIPvl.

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

11.	Какие таймеры регулируют маршрутизацию трафика под управлением протокола
R1P?

12.	К какой категории относится протокол OSPF?

13.	На основании каких показателей протокол OSPF принимает решение о выборе мар-
шрута?

14.	Каковы преимущества протокола OSPF по сравнению с протоколом R1P?

15.	Перечислите характеристики протокола OSPF.

16.	Какие три базы данных создают и используют в своей работе маршрутизаторы OSPF?

17.	Что представляет собой база данных OSPF для хранения сведений о смежных мар-
шрутизаторах?

18.	Что представляет собой база данных OSPF для хранения сведений о состоянии ка-
налов связи?

19.	Что представляет собой база данных OSPF для хранения маршрутной информации?

20.	Что такое LSA протокола OS PF0

21.	Чем О1личается межобластное объявление OSPF от внутриобластного объявления?

22.	Назовите шесть состояний маршрутизаторов OSPF.

23.	Назовите четыре пни маршрут изаюров OSPF

24.	Что представляет собой базовая область OSPF?

25.	Перечислите пять типов пакетов OSPF

26.	Какое назначение прившшвенного пакета протокола OSPF?

27.	Какое назначение пакета OSPF, содержащего описание базы данных?

28.	Назовите показатели, на основании которых протокол 1GRP принимает решения о
выборе маршрутов.
29.	Какое максимальное шипение счетчика попадании уста на или пае ten протоколом
IGRP?

30.	На юните различные таймеры протокола IGRP и объясните их функции

31.	Перечислигс характеристики протокола L IGRP

32.	К какой категории относится протокол LIGRP?

33.	Какие преимущества и недостатки являются следствием того, что EIGRP обеспечи-
вает поддержк\ ряда протоколов?

34.	Чем отличаются преемник и потенциальный преемник EIGRP?

35.	Назовите пять типов пакетов E1GRP. Данте краткое описание эги\ пакетов

36.	Чем отличаются протоколы категории IGP от протоколов категории EGP?

37.	Какие расширения возможностей BGPv4 сделали лот протокол основным прото-
колом. используемым в Инюрнете?

38.	В каких случаях целесообразно реализовать протокол BGP?

39.	Чем отличается топология BGP на основе полной и на основе частичной интегра-
ции?

40.	Перечислите четыре типа маршрутизаторов BGP

41.	Какую информацию должен дифференцировать каждый спикер BGP, независимо
от того, с какой таблицей он раоотает9

42	На базе какого протокола функционирует протокол BGP?

43.	Назовите четыре типа сообщений BGP.

44	В каких случаях отправляется первичное сообщение BGP и каг ос ею назначение?

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

46.	Каков показатель используется протоколом BGP для определения оптимальною пути
к пункту назначения9

47.	На какие чегыре категории поцразделяются атрибуты пути BGP’

48.	Ооьясните смысл атрибута локального предпочтения BG1

49	Чем отличаются версии BGPv3 и BGPv4?
Глава 7

Т ранспортнь (й/межхостовый
уровень

Данная глава охватывает следующие темы:

•	Протоколы, ориентированные на соединение (Connection-oriented Protocols)

•	Протоколы, не ориентированные на соединение (Connectionless Protocols)

Протоколы транспортного уровня

В системах связи для обработки всех задач, связанных с передачей данных, недоста-
точно только одного протокола. Выполнение большинства таких задач требует реализа-
ции ряда протоколов, функционирующих в тесном взаимодействии в пределах стека (се-
мейства) протоколов (protocol suite). Трансиортный/межхостоныи уровень (Transport/
Host-to-Host layer) обеспечивает надежный поток данных между двумя процессами, вы-
полняемыми на удаленных хостах. Протоколы, обслуживающие передачу данных на этом
уровне, принимают сообщения (потоки данных, data streams) от приложений и процес-
сов верхнего уровня, обрабатывают и разбивают их на сегменты (segments) для отправ-
ки на сетевой (Network layer) или межсетевой уровень (уровень Интернета. Internet layer)
с целью формирования дейтаграмм (datagrams).

Два протокола транспортною уровня стека протоколов TCP/IP, а именно UDP (User
Datagram Protocol, Протокол (доставки) дейтаграмм пользователя) и TCP (Transmission
Control Protocol, Протокол управления передачей), будут подробно рассмотрены в гла-
вах 8 и 9 Каждый протокол может быть отнесен к одной из таких категорий: ориенти-
рованный на соединение или не ориентированный на соединение Текущая глава огра-
ничивается рассмо(рением функционального назначения протоколов транспортного/
межхостового уровня, а также сервисов, предоставляемых этими протоколами. Тип служ-
бы доставки данных зависит от того, какой из протоколов транспортного уровня будет
избран. Протокол UDP (не ориен1ированный на соединение) обеспечивает быструю, но
ненадежную передачу сегментов данных между процессами, выполняемыми на удален-
ных хостах. Протокол TCP (ориентированный на соединение) обеспечивает надежную
доставку упорядоченных данных (sequencing of data) от одного хоста к другому.

Для обеспечения эффекшвной работы приложений верхнего уровня необходимо ре-
шить, с каким протоколом — UDP или TCP — будут работать эти приложения. Если
важна скорость передачи данных — предпочтение следует ощагь UDP, поскольку этот
протокол предлагает быструю доставку дейтаграмм по принципу «попытка успешной до-
ставки- (best effort delivery of datagrams)» Когда скорость передачи данных менее
важна, чем надежность, — реализуется протокол TCP. поскольку он обеспечивает более
медленную, но гарантированную дос танку Проше говоря, нопрос сводится к выбору
между скоростью и надежностью передачи данных. На рис. 7.1 показано, как представ-
лен стек протоколов TCP/IP в коммуникационной модели Министерства Обороны СШ-Х
(DoD, US Department of Defense) и эталонной мидели взаимодействия открытых систем
OSI (Open System Interconnection).

Протокол UDP предлагает быструю, но ненадежную передача сообщении между при-
ложениями, выполняемыми на удаленных хостах. Поскольку UDP — это простои про-
токол, он обеспечивает быструю службу доставки простой отправкой пакетов от одною
хоста к другому, возлагая при этом обеспечение надежности доставки на протоколы
верхних уровней или на протоколы самих приложений. Однако протокол UDP имеет
существенный недостаток: получение адресатом отправленных ем. дейтаграмм не га-
рантируется.

Модель DoD
(Мич1сте/лва Обороны США)

Модель OSI
(взаимодействия отх[ э.ьо сгстем)

Прикиде -ой урезиьо

Процеа
.Тиитохвние

Уровень представления

Уровень сеансов

РИСУНОК 7.1

Сле.ия опережения
протоколос TCP и UDP ни
транспортном уровне
модели OS1 и на
межхостовом уровне
Modem l>oD.

Мчж»о_иьый
ур еень

ТОР или JDP

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

Уровень

Интерне га

Сетевой ур< снь

Уровень досту: ,з
к сети

Кы^лный уровень

'Уровень сьгзи данных)

Физический уровень

Протокол TCP предлагает более медленную, но гарантированную доставку данных.
Данная услуга обеспечивается посредством управления потоком отправляемых дата|рамм
и их размером (flow control) таким ооразом, чтобы можно бы то продолжить передачу
данных на сетевом или межсетевом уровне. Кроме тою. гарантия доставки сегментов
на хост-получатель обеспечивается процедурог упорядочивания перад (васмых ceiмен-
тов данных (sequencing), а также отправкой хостом-получателем подтверждении
(acknowledgement АСК) о получении каждого сегмента. Из-за того, что TCP подвергает
тщательной мноюкратнои проверке процедуру доставки сегментов адресату. этот про-
юкол может обеспечить надежную, но более медленную передачу данных При этом про
юколы прикладного уровня не имею) шкакого отношении к обеспечению надежности
доставки, в отличие от того случая, когаа используется протокол UDP.
На транспортном (или на межхостовом) уровне выполняются счедуюшие действия:

•	Управление сквозной передачей данных <cnd-lo-end communication) между двумя
процессами, выполняемыми на различных хостах-компьютерах.

•	Предоставление верхним уровням ориентированных или не ориентированных на
создание соединения сервисов

•	Идентификация процессов, выполняемых на хост-компьютере, по IP-адресам и
номерам портов сервера и клиента.

•	Разбиение данных на ceiменты для обработки их приложениями верхнего уров-
ня

Протоколы, ориентированные на соединение

TCP — это единственный ориентированный на соединение протокол, который вхо-
дит в состав стека протоколов TCP/IP на транспорт next уровне. Решение об использо-
вании приложениями протокола TCP в качестве протокола транспортного уровня при-
нимается в зависимости от того, сеть ли необходимость в функциях, предоставляемых
данным протоколом. Где бы ни находились ориентированные на соединение протоко-
лы, — на транспортном или любом другом уровне. — им всегда свойственны шесть ос-
новных характеристик:

•	Установление сеанса связи (session setup) — создание виртуального канала связи
между двумя коммуникационными процессами (процессами передачи данных),
выполняемыми конечными хост-компьютерами (см. рис. 7.2).

•	Формирование подтверждении (acknowledgements, АСК) — уведомлений хоста-
отправителя о том, что переданные им данные получены.

•	Упорядочивание сегментов данных (sequencing) — присвоение порядкового но-
мера каждому передаваемому сегменту для упорядочивания передаваемых датаг-
рамм.

•	Управление потоком (flow control) — управление скоростью передачи данных.
Конечные хосты могут обмениваться друг с другом запросами на увеличение или
уменьшении скорости передачи данных.

•	Формирование сообщений о поддержании соединения (keepalives) — поддержа-
ние соединения активным в го время, когда не происходит передача данных.

•	Завершение сеанса связи (session teardown) —выполняется, когда любая из конеч-
ных систем инициирует разрыв виртуального соединения (см рис.7.3).

Установление ориентированного на создание соединения сеанса связи всегда начи-
нается на нижних уровнях и достшает верхних уровней модели OSI. TCP — это основ-
ной ориентированный на соединение протокол, входящий в состав стека протоколов
TCP/IP При любом обращении приложения к TCP этот протокол создает виртуальное
соединение еше до того, как начнется процесс передачи какой бы то ни было значащей
информации. Как только нижние уровни установят связь с верхними уровнями, через
это соединение можно начина! ь пересылку данных между приложениями. TCP исполь-
зует трехшаговый обмен сообщениями дня установчения сеанса связи. Эта процедура
рассматривается более подробно в главе Я.
Установление сеанса связи

РИСУНОК 7.2

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

Сообщение SYN/ACK протокола TCP сервер Второе
содержал. ;е сет^нт г' кюгйзадит "й cotв
подтверждение АСК

Третье
соосщение

Сообщение АСК проток ~т СР клиента

Завершение сеанса связи

РИСУНОК 7.3

Выход w* при ссжения
вызывает завершение
работы протомма TCP.

« ольэователь

отключается от	Порт сервере

гарта TCP	TCP

Сииищсппе ли 1кгч.пельныи uumu.ii inner oeyineni — hit;

to :

Сооищение TCP клиента FIN/АСК Второе

4 содержащее ACK в сегменте RN сообщение

Третье
сообщение

Сообщение АСК протокола TCP клиента

Чтобы обеспечить сохранность данных во время передачи, ориентированные на со-
единение протоколы обмениваются порядковыми номерами (sequence numbers), присво-
енными каждому сегменту, а также номерами подтверждений (acknowledgement numbers)
доставки передаваемых сегментов. У каждого протокола существует свои способ при-
своения порядковых номеров Некоторые .троюкоды присваивают так«е номера каж-
дому кадр) (frame), друтие — присваивают их каждому байту в пределах кадра. Однако
каким бы ни бы । сам метод, — задача остается одной и той же: обнарежить потерянные
данные или кадры и, ес 1И есть такие. — восстановить их посредством повторной пере-
твчи данных.

Когда хосты белденствуют (не обмениваются данными), необходимость в поддержа-
нии виртуального соединения по-прежнему существует. Эта функция реализуется через
применение сообщений о поддержании соединения активным (keepalives) — кратких со-
общений, которыми два хоста обмениваются для подтверждения необходимости в про-
должении сеанса связи. Подобные сообщения гарантируют поддержание виртуального
соединения в то время, когда процесс, выполняемы.; на хосте, временно приостанов-
лен Сообщения такого типа не используются для передачи данных приложениями вер-
iHero уровня; хосты отсылают такие сообщения только для того, чтобы обеспечить под-
держание соединения.

Иногда хост-отправитель перечаег слишком большой отъем данных за один сеанс свя-
зи, вследствие чет о буферы хоста-получателя могут оказаться переполненны ми. Хост-
получатель, работающий сориентированным на соединение протоколом, может восполь-
зоваться для решения этой проблемы механизмом управления потоком (Dow control
mechanism). С помощью этого механизма хост-получатель может выдать хосту-отпра-
вителю запрос на увеличение или уменьшение объема передаваемых данных, что по-
зьолит отрегулировать информационную нагружу (график, traffic). Каждый протокол
имеет свой способ управления потоком данных.

TCP осуществляет управление потоком данных посредством механизма скользящих
окон (sliding window mechanism). Этот механизм дает протоколу TCP возможность ди-
намически регулировать размер окна, когда нужно уведомить хост-отправитель о псоб 
ходимости замедлить передачу данных или совсем ее превратить Верхние уровни раз-
рывают виртуальное соединение, когда какая-либо из сторон рыдает запрос на
завершение сеанса связи более подробное описание всех шести характеристик прото-
кола TCP изложено в тлаве 8.

Протоколы, не ориентированные на соединение

Независимо оттого, на каком уровне находятся не ориентированные на соединение
протоколы, они передают данные, но не проверяют, деист вительно ли хост-получатель
эти данные получает. Протоколы, не ориентированные на соединение, воътагают на
друт ие протоколы как задачу i аранжирован нои доставки данных на хост получатель, так
и задачу восстановления утерянных данных. Такие протокоты не обладают ной надеж-
ностью. которая свойственна их ориентированным на соединение аналогам. Однако они
обеспечивают такие возможности, которых нс могут предложить ориентированны^ на
соединение протоколы, а именно — скорость и минимальные непроизводительные зат-
раты Более подробно протокол UDP рассматривается в главе 9.

Сравнение ориентированных и не ориентире“энных
на соединение протоколов

Перед применением того или иного протокола возникает очень старый, свойствен-
ный теме организации компьютерных сетей, вопрос: что предпочесть. — скорость или
надежность, которой сопутствуют непроп 1водителы1ые загрпы? Протоколы, не ориен-
тированные на соединение, более эффемивны, поскольку их функционирование нс
влечет за собой непроизводительных затрат, связанных с присвоением порядковых но-
меров каждому кадру или байту, а также связанных с необходимостью выдачи подтвер-
ждений об их получении (как эго происходит, например, при установлении ориентиро-
ванного на соединение сеанса связи). Кроме тою, не ориентированным на соединение
протоколам не приходится поддерживать бездействующие соединения посредством спе-
циальных сообщении о поддержании соединения активным, формирование которых, в
свою очередь, приводит к увеличению непроизводительных затрат.

Если есть необходимость в быстрой доставке данных, целесообразно выбрать прото-
колы, не ориентированные на соединение, когда потребность в надежности превосхо-
дит потребность в скорости передачи данных. — предпочтение следует отдать ориенти-
рованным на соединение протоколам. Например, для выполнения прикладной
программы печати необходимо использовать ориентированный на соединение протокол;
пользователям нужна уверенность в том, что их задания на печать будут выполнены.

В таблице 7.1 приведены сравнительные характеристики двух типов протоколов.

Таблица 7.1 Ориентированные и не ориентированные на соединение протоколы._________

Протокол	Описание

Не ориентированный на соединение	Нет установления сеанса связи

Нет завершения сеанса связи

Нет подтверждений доставки

Нет упорядочивания сегментов

Нет управления потоком

Нет сообщений о поддержании соединения

Доставка по методу попытки успешной передачи
Быстрая доставка данных

Небольшие непроизводительные затраты

Нет восстановления или повторной передачи

Ориентированный на соединение	Установление сеанса связи

Завершение сеанса связи

Формирование подтверждений доставки
Упорядочивание сегментов
Управление потоком

Сообщения о поддержании соединения

Надежная, гарантированная доставка

Более медленная доставка данных

Масса непроизводительных затрат
Восстановление утерянных данных
Повторная передача данных

Порты и сокеты

Для доставки данных нужному приложению протоколы транспортного уровня, будь
то ориентированный на соединение (TCP) или не ориентированный на соединение
(LJDP) протокол, используют IP-адреса отправителя (source address) и получателя
(destination address) в сочетании с номерами портов соответствующих приложении. 1Р-
адреса указываются в заголовке IP. номера портов — в заголивке ГСР или UDP. Ком-
бинация IP-алреса и номера порта образует так называемый сокет (socket), однозначно
идентифицирующим процесс, выполняемый на том или ином хосте. Посредством ис-
пользования сокегов (т.е. IP-адресов и номеров портов TCP или UDP) клиенты и сер-
веры получают всю информацию, необходимую для идентификации партнера по ком-
муникации

Как упоминаюсь выше, транспортный уровень отвечает за сегментирование данных,
переданных ему для дальнейшей обработки приложениями верхнею уровня. Для того,
чтобы управлять потоком данных, формировать сегменты данных и отслеживать их пе-
редачу, на транспортном уровне используются номера портов (port numbers) для каждо-
го приложения Необходимо помнить о том. что на данном уровне могут быть реализо-
ваны либо ориентированные, либо не ориентированные на соединение протоколы. Это
значит, что в зависимое!!! от выбранною протокола доставка данных может быть га-
рантированной или нет. Это приводит некоторых пользователей в замешательство, по-
скольку они уверены в том, что транспортный уровень обеснечиваег надежную достав-
ку данных Заинтересованным в гарантированной доставке данных пользователям следует
просто помнить о том, что такую службу доставки обеспечивает только протокол TCP.

Например, если пользователь желает установить соединение Teinet-клисига с уда-
ленным Telnel-сервером, при обработке запроса на это соединение открывается порт с
уникальным номером, который является изменяемым (variable), другими словами — на-
значаемым oiiepajiiBiio каждый раз при запуске приложения клиента. Соединение ис-
пользует этот порт для тою, чтобы установить связь с Telnel-сервером Порты для при-
ложении клиентов выбираются произвольно. то!да как порты для приложении серверов
имеют присвоенные им номера, которые нс меняются; такие порты, как правило, на-
зываются "общеизвестными" (well known) портами. Koi да устанавливается связь с хос-
том или сервером, подключение обычно происходит через общеизвестный порт, в слу-
чае с Telnet — через порт с номером 23 (см. рис. 7.4). В таблице 7.2 показаны отличия
между различными категориями портов.

РИСУНОК 7 4

В приведенном выше
примере Telnet всегда
использует порт 23.

Порты клиента и сервера

Диапазон порте в клиентов: 1024-65,536

Диапазон портов серверов: 1-1023
Таблица 7.2 Категории портов	
Категория порта	Диапазон номеров и описание
Общеизвестные порты	0 255
серверов	Относятся к известным промышленным программам.  являются официальным стандартом адресации таких программ.
Менее известные	256 1023
порты серверов	Зарезервированные порты, которые могут быть реализованы по мере возникновения необходимости
Порты для приложений	1024 65536
клиентов	Изменяемые порты, номера которым назначаются оперативно каждый раз. когда начинает выполняться приложение клиента и открывается новый порт

На рисунке 7.4 показано, как IP-ддрес клиента и порт 4001, или порт с динамически
назначаемым номером, а также IP-адрес хоста-получателя вместе с известным портом
Tclnei-cepaepa с номером 23, составляю! пару сокетов (socket pair). Такая пара сокетов
образует сквозное соединение между двумя хостами (от правителем и получателем), в ко-
тором задействованы соответствующие IP-адрсса и порты. Порты для приложений кли-
ентов и серверов однозначно идентифицируют процесс, вступающий во взаимодействие
с каждой стороны Посредством установления связи хост-адреса и порта отправителя с
хост-адресом и портом получателя протоколы TCP и UDP имеют возможность органи-
зовать передачу данных между л ими хостами и процессами, выполняемыми на них, а
также отличать данное соединение от других виртуальных соединений с этими же хос-
тами.

$ ПРИМЕЧАНИЕ

Необходимо помнить о том, что транспортный уровень оперирует в своей работе соке-
тами, ипи IP-адресами и номерами портов. Объединение сокетов в пары (socket pairing)
обеспечивает сквозное соединение между двумя хостами — отправителем и получате-
лем, и это соединение задействует IP-адреса и порты обоих хостов.

В семействе прогоко юн TCP/IP порты протоколов TCP и UDP идентифицирую г про-
цесс или программ), выполняемую в пределах отдельного хоста. Соответственно TCP.
ориен1ированный на соединение протокол поддерживает ориентированный па соеди-
нение процесс. Применение протокола UDP не ориентированного на соединение, при
водит к ненадежной передаче данных, и остается только надеяться, что эти данные до-
стигнут пункта назначения, а также полагаться на то, что протоколы верхних уровнен
под держат соединение

Резюме

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

Ориентированные на соединение протоколы обеспечивают гарантированную досто-
верную доставку данных между двумя конечными системами Не ориентированные на
соединение протоколы предлагают быстрый, но ненадежный обмен сообщениями меж-
ду приложениями, выполняемыми на удаленных хостах. Всем ориентированным на со-
единение протоколам свойственны следующие характеристики: установление сеанса
связи формирование подтверждений, упорядочивание сегментов данных, управление
потоком, поддержание соединения активным и, наконец, завершение сеанса связи.

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

Вопросы для повторения

1.	Какие четыре сервиса предоставляет транспорт ный/межхостовый уровень?

2.	Какие характеристики свойственны всем ориентированным на соединение прото-
колам"’

3.	Что такое "общеизвестные порты" и каков диапазон их номеров1

4.	Что такое "менее известные порты" и каков диапазон их номеров?

5.	Что такое «порты для приложении клиентов» и каков диапазон их номеров?

6.	Опишите, из каких составных частей образуется пара сокетов.

7.	Представьте сравнительную характеристику двух протоколов транспортною уров-
ня, входящих в стек протоколов TCP/IP.

8.	Что такое управление потоком?

9.	Перед какой дилеммой стоят поставщики сетевых услуг при реализации того или
иного протокола транспортною уровня?

10.	Какой протокол применяет процедуру формирования подтверждении доставки и про-
цедуру упорядочивания сегментов; какие функции выполняют ли процедуры?
Глава 8

Протокол управления
передачей (TCP)

Данная глава охватывает следующие темы:

•	Заголовок дейтаграммы TCP и его поля.

•	Действие протокола TCP.

•	Установление и закрытие соединения.

•	Упорядочивание передаваемых дейтаграмм и подтверждение их получе-
ния.

Краткая характеристика TCP

Первоначально Винтон Серф (Vihion Cerf) и Роберт Кан (Robert Kahn) разработали
протокол TCP (Transmission Control Protocol, Протокол управления передачеи денных)
для обеспечения надежной передачи данных (reliable data transmission) между удален
ными хостами, взаимодействующими между собой в сети с коммутацией пакетов (packet-
switched network). До создания протокола TCP передача данных по информационным
инфраструктурам с коммутацией пакетов на практике часто оказываласг ненадежной
Процессу доставки данных были свойственны такие отрицательные характеристики, как
низкое качество службы доставки (отсутствие надежности) и различия в характеристи-
ках каждого типа передавшей среды. Существовали также потенциальные возможнос-
ти для перегрузки каналов связи, затрудняющей доставку данных в пункты назначения.
Все эти отрицательные стороны процесса передачи данных обусловили необходимость
создания ориентированною на соединение протокола (connection-oriented protocol),
способного обеспечить надежный скво.*ной режим обсл уживания доставки данных (end-
to-end reliable services) для процессов и приложений, осуществляющих взаимодействие
посредством удаленных хостов. Таким протоколом стал протокол TCP. который был
избран Министерством обороны США (DoD, Department of Defense) в качестве основ-
ного протокола, обеспечивающего надежную цостзвку данных в сети ARFA (Advanced
Research Progects Agency Neywork, Сеть агентства перспективных исследовательских
проектов). Cpaiy же после создания этот протокол стал стандартным протоколом Ин-
тернета, обеспечивающим гараншрованную доставку данных между хостами.

Протокол TCP обслуживает передачу данных на межхостовом уровне (Host-to-Host
layer) коммуникационной модели Министерства Обороны США (DoD US Department
of Defense) и на транспортном уровне (Transport Javer) эталонной модели взаимодей-
ствия открытых систем OSI (Open System Interconnection, Указанные уровни обслужи-
ваются только протокола 1ЦМ TCP и UDP. В зависимости or поставленных целей постав-
щики сетевых услуг могу! реализовать один из протоколов (TCP и ли UDP): в случае
необходимости 1арантрованной доставки данных необходимо выбрать TCP. е<_ли ско-
рость передачи данных важнее надежности — предпочтение следует отдать UDP. Н рис.
8.1 показано, как представлен протокол TCP в эталонных коммуникационных моделях
OS1 и DoD.

РИСУНОК 8.1

Протокол TCP
гарантирует доставку
донных в пункт назначения
на межхостовом уровне
(модель DoD) или
траспортном уровне
(модель OSI).

Модель DoD

(Министерства Обороны США)

Модель OSI

(вмимодейстмя открытых систем)

Уровень
доступа к сети

Процесс/
Приложение

Уровень

Цмгернета

Мсжхосговыи
уровень

Заголовок TCP

Основные функции и общие принципы реализации ориентированного на соедине-
ние протокола TCP изложены в предыдущей главе и в начальном разделе тек^цеи гла-
вы. В последующих разделах данной 1лавы анализируются поля заголовка TCP (TCP
header) На риг 8.2 пре (ставлен специфицированный в RFC 793 формат заголовк t 1 СР
На рис. 8.3 показан пример фактической реализации заголовка TCP в том виде, в каком
его интерпретирует анализатор протоколов Sniffer. В заголовке TCP указывается порт
отправителя (source port) и порт получателя (dcsimation port), значения порядковых но-
меров (sequence numbers) и померон подтверждении (acknowledgement numbers), а так-
же флаги TCP (TCP flags), используемые тостами для задания способа передачи дан
них Описание каждого поля заголовка TCP следует за рисунками.

РИСУНОК 8.2

На данном рисунке представ юн
формат 1агоюяг.а TCP Лак
правило, заголовок TCP
с<к)ермит 20 байтов
информации если не
<« по тлеется поле
доптнителызых пар гмезнрол
(Options) Сictiyem обратить
внимание на те, что зага ювок
TCP может и не иметь в своем
составе нинакил

Ллю.-ните .ьиь« парзызет/ он и
никаких данных.

Горт отправителя	Порт получателя
Пфядо.зи ноиар	
Ниыр .^ТвврЖД.41.Я	
Смещение Зарезервирован) Флага	Окно
Контрольная сумма	Указатель срочности
Дополнительные параметры ♦ Заполне _.	
Данные	
Порт получателя

Номер подтверждения

Порт отправителя

Порядковый номер

Смещение данных

Управляющие
флаги

Окно

Контрольная сумма

Дополнительные
параметры TCP

РИСУНОК 8.3 Сtedyem обратить внимание на то что в приведенном примере конкретного заголовка

TCP не используются дополните 1Ы<ые параметры (Options), а также отсутствуют
зарезервированное пиле (Reserved) и поле указателя срочности (Urgent Pointer).

Поле порта отправителя

Поде порта отправителя (Source Pori) длиной 2 байта идентифицирует выполняемый
хостом-отправителем коммуникационный процесс (так называемый сокет, socket) В дан-
ном поле может быт ь установлен номер порта TCP клиента в диапазоне от 1024 до 65635.
а также номер порта TCP сервера в диапазоне от 0 до 1023. Передача данных посред-
ством TCP — это двусторонний коммуникационный процесс: протокол TCP должен быть
реализован на каждом конечном хост-компьютере. Поэюму устанавливаемое в поле
номера порта значение зависит от того, в каком направлении выполняется процесс ком-
муникации. Если запрос инициируется клиенюм, передающий этот запрос порт TCP
функционирует в качестве порта клиента (client port) Когда сервер отвечает на полу-
ченный запрос клиента. этот ответ передается через порт TCP. функционирующий в
качестве порта сервера (server port).

Поле порта получателя

Поле порта получателя (Destination Pon) длиной 2 байта идентифицирует выполни
емый хостом-получателем коммуникационный процесс (так называемый сокет, socket).
Устанавливаемое в данном поле значение зависит от тою, в каком направлении выпот-
няегся процесс коммуникации (клиент — сервер или сервер — клиент)
$ПРИМЕЧАНИЕ

Необходимо помнить о том, что каждый сегмент данных TCP обеспечен номером порта
отправителя и получателя. Эти номера портов идентифицируют устройства, отправляю-
щие и получающие передаваемые протоколом TCP сегменты данных. Номер порта от-
правителя (source number) и номер порта получателя (destination number) вместе с IP-
адресом отправителя (source address) и IP-адресом получателя (destination address),
указанными в соответствующих полях заголовка IP, образуют пару сокетов (socket pair).
Пара сокетов задает два конечных пункта, между которыми выполняется передача дан-
ных, и таким образом однозначно идентифицирует каждое устанавливаемое в сетевом
комплексе ТСР-соединение.

Поле порядкового номера

Протокол TCP выполняет упорядочивание передаваемых сегментов данных
(sequencing) для отслеживания прохождения каждого байта этих данных по соединению
TCP Начальное значение порядкового номера, устанавливаемое в поле порядкового
номера (Sequence Number) длиной 4 байга, вычисляется с помощью одного из алгорит-
мов и включается в кадр синхронизации (synchronization frame) во время установления
сеанса связи. Этот порядковый номер идентифицирует первый байт каждой передавае-
мой дейтаграммы Интерпретировать присвоение начального порядкового номера мож-
но гак: "Я начинаю передачу сегментов данных, начиная с номера...” Если получатель
не отправляет подтверждения (acknowledgement, АСК) приема отправленного ему сег-
мента данных, отравитель делает предположение о том, что этот сегмент потерян, и
выполняет повторную пересылку потерянного сегмента.

ПРИМЕЧАНИЕ

Следует обратить внимание на то, что протокол TCP не присваивает порядковый номер
каждому байту данных, но при этом гарантирует доставку каждого байта данных в пункт
назначения посредством упорядочивания каждого сегмента передаваемых данных. Гарантия
доставки данных в пункт назначения обеспечивается простым подтверждением (АСК.)
получения каждого имеющего порядковый номер пакета данных. Протокол TCP исполь-
зует также оконную организацию передачи данных (windowing) для регулирования пото-
ка передаваемых дейтаграмм. Подтверждение приема данных и оконный механизм пере-
дачи данных рассматриваются ниже в данной главе.

Поле номера подтверждения

В поле номера подтверждения (Acknowledgemenl Number) длиной 4 банта содержит-
ся значение, идентифицирующее значение порядкового номера следующею пакета дан-
ных хоста-отправигеля, который ожидает получить хост-получатель Номер подтверж-
дения должен равня1ься порядковому номеру ранее полученного от отправителя пакета
данных плюс длина этого пакета. Такое значение номера подтверждения подразумева-
ет, что получатель принял все отправленные данные до сегмента данных с указанным в
подтверждении номером Такой способ подтверждения приема передаваемых данных
называется неявным (подразумеваемым) подтверждением (implied acknowledgement).
Получатель имеет возможность подтверждать прием множества кадров посредством
одного подтверждения (АСК). Это более производительный способ, чем подтверждение
получения каждою кадра, а икже каждого несущего полезную нагрузку байга
В процессе организации передачи данных с помощью протокова TCP следует помнить
о том чго задаваемый в заготовке ТС Р размер окна (window size) определяет объем не
редаваемых хостом-отправителем данных. Хост-о травитель может передать несколько
кадров, если приемное от но (receive window) получателя имеет гостаточныи размер для
того, чтобы эти кадры принять Когда окно заполняется данными, отправитель прекра-
щает их передачу и о» идает подтверждения получателем приема отправленных ему кад-
ров (другими словами, отправитель ожидает разрешения на продолжение передачи дан-
ных). Для того чтобы вычислить номер подтверждения, необходимо прибаьигь
порядковый номер первого кадра к общей длине всех передаваемых в данном потоке
кадров. Рассмотрим следующий пример:

•	Хост-отправитель передает 5 кадров.

•	Порядковый номер первого кадра тайного потока равен 10.

•	Каждый кадр содержит 10 байтов данных.

Хост-получатель подтверждает прием данного потока кадров порядковым номером
со значением 60 (начальный порядковый номер плюс 50; 5 кадров общей длиной 5x10=50
бантов) Таким образом, хост-получатель подтверждает получение всех 50 байтов дан-
ных и ожидает отправки хостом-отправителем следующего кадра с порядковым номе-
ром. равным 60. Выдачу хостом -получателем подтверждения приема данных можно ин-
терпретировать так: "Следующим я ожидаю получить кадр с порядковым номером...”.

На рис. 8.4 представлено окно анализатора протоколов Sniffer, по которому можно
проследить процесс передачи файлов между хостами, а также схему вычисления поряд-
кового номера. В этом окне можно найти начальный порядковый номер (starling sequence
number), количество передаваемых кадров (number of frames), объем данных в каждом
кадре (amount of data) и значение порядкового номера подтвержденного кадра
(acknowledged value). Чтобы вычислигь значение номера подтверждения, необходимо
сложить начальный порядковый номер и количество кд трон, умноженное на их длину в
байтах.

На итоговой панели анализатора протоколов Sniffer отображен первый кадр, в кото-
ром указаны IР-адрет а двух хостов, обменивающихся файлами посрекггвом протокола
FTP (File Transfer protocol. Протокол передачи фанлов) клиент 192.42.252.20. FTP-порт
2918, и FTP-сервер 192.42.252 1, порт 20. Между этими хостами уже установлено соеди-
нение TCP. По данному кадру можно увидеть, что в текущий момент сервер ожидаш
отправления клиентом данных, начиная с указанного н поле АСК порядковою номера
46348289.

Следует обратить внимание на то. что четыре отправленных клиентом кадра содер-
жат данные протоко ia FT Р. По содержимому панели детальных сведении можно уви-
деть, что, как и ожидалось. начальный порядковый номер равен 46348289, а общий объем
передаваемых ь четырех кадрах танных (как видно по последнему полю заголовка TCP)
составляет 1024 байтов.

Далее для вычисления номера подтверждения необходимо применить упомянутую
выше формулу (начальный порядковый номер пчюс количество отправленных кадров,
умноженное на объем данных в каждом кадре) и проверить полученное значение Если
начальный порядковый номер равен 46348289 (кадр 2). а клиент отправляет четыре кадра
длиной 1024 байта (кадры 2-5). сервер ожидает получить следующий кадр с чорядко-
вым номером 46352385 Проверить правильность применения формулы можно, сверив
результат ее применения с номером подтверждения, отправленным сервером. Этот номер
(46352385) представлен в поле АСК последнею отправленного клиентом кадра (кадра 6).

Значение порядкового номера подтвержденного

Количество отправленных кедров

Начальный порядковый номер

Объем данных
каждом кай

РИСУНОК 8.4 На данном рисунке представлено окно анализатора протоколов Sniffer, отображающее
подробные сведения о выделенном на итоговой пакет втором кадре

Поле смещения данных

Поле величины смешения данных относительно начала пакета TCP (Data Offset) оп-
ределяет начало расположения данных протокола или приложения верхнего уровня после
заголовка TCP Необходимость в задании величины смещения данных вытекает из того
факта, что заголовок TCP. в который может быть включено или не включено поле допол-
нительных параметров (Options), имеет переменную длину. Протокол TCP использует поле
смещения данных (Data Offset), имеющее длину 4 байта, для прогнозирования точного ме-
сторасположения первого байта данных верхнего уровня в рамках данного кадра.

Зарезервированное поле

Зарезервированное поле (Reserved), имеющее длину 6 битов, зарезервировано для ис-
пользования в будущем. Это поле всегда заполнено нолями.

Поле управляющих флагов (6 битов)

По значению, установленному в поле управляющих флагов (Control Flags), получа-
тель может определить целевое назначение кадра. На рис. 8.5 представлено поля шссги
управляющих флагов, соответствующих каждому флагу в отдельности.
РИСУНОК 8.5 Протокол TCP ucnotnwrn управляющие флаги Агя того, чтобы указать получателю
ни способ обработки передаваемых данных.

Ниже следует описание функций каждого из шести почей управляющих флагов (раз-
мер каждого поля ранен I биту1

•	URG (Urgent) — фча! срочности. Устанавливается хосгом-отравителем с целью
присвоения передаваемой в данном кадре информации наивысшего уровня при-
оритета. Когда хост-отправитель устанавливает этот флаг в заголовке ГСР акти-
визируется также поле указателя срочности (Urgent Pointer) Указатель срочнос-
ти идентифицирует первый следующий за срочными данными байт в кадре
(другими словами, указывает на тог байт кадра, за которым Начинаются данные с
обычным уровнем срочности).

•	АСК (Acknowledgement) — флаг пакета, содержащего подтверждение получения
данных, флат АСК. установленный хостом-о травителем в поле управляющих
флагов (Control Flags) заголовка TCP, служит признаком того, что в cocr ib дан-
ного кадра входит подтверждение приема полученных ранее данных.

•	PSH (Push) — флаг форсированной передачи кадров. Каждый сеанс связи TCP
управляет процедурой передачи полученных данных приложениям верхнего уров-
ня для дальнейшей обработки. В с |учае установки хостом отправителем флага PSH
хост-получатель должен немедленно поместить полученные кадры в стек данных
процесса верхнего уровня. Посредством установки данного бита хост-отправитель
TCP стимулирует хост-иолу гагель TCP без промедления передать полученные дан-
ные процессу верхнего уровня.
•	RST (Reset) — флаг переустановки соединения. Устанавливается для указания на
необходимость переустановки соединения. Такая необходимость может возник-
нуть либо в случае преждевременного прерывания пользователем сеанса связи,
либо в случае возникновения ошибки в процессе установления соединения.

•	SYN (Synchronization) — флаг синхронизации порядковых номеров. Устанавливает
соединение между портами/сокетами посредством синхронизации порядковых но-
меров.

•	FIN (Finish) — флаг завершения передачи данных со стороны отправителя. За-
вершает установленный ранее сеанс связи и отмечает тот факт, что отправитель
завершил процесс передачи данных

Поле окна

Объем данных, которые хост-нолучателъ способен принять, зависит от ресурсов этого
хоста и от количества сеансов передачи данных, в которых хост принимает участие в
данный момент. В поле окна (Window), имеющем длину 2 байта, указывается максималь-
ный объем данных (в байтах), которые хост TCP в состоянии принять в текущий мо-
мент. Данное поле используется в качестве средства управления потоком данных (flow
control). Когда размер приемною окна равен 0, этот факт служит признаком того, что
хост в текущий момент времени совсем не может принимать данных. Подобная ситуа-
ция складывается, как правило, в случае перегруженности каналов связи (congestion),
либо в случае дефицита ресурсов хоста (lack of resources).

Поле контрольной суммы (2 байта)

Поле контрольной суммы (Checksum), имеющее длину 2 байта, используется для об-
наружения повреждения данных (damaged data), которое могло произойти в процессе
передачи данных в пункт назначения. С помощью кошрольной суммы проверяется це-
лост ность битов заголовка TCP, псевдозаюловка IP и собственно данных, передаваемых
протоколами или приложениями верхних уровней. Контрольная сумма вычисляется
хостом-отправителем, а результат сравнивается со значением контрольной суммы, вы-
численной хостом-получателем. Совпадение этих двух значений подтверждает достовер-
ность передаваемых данных. Если же значения контро гьной суммы не совпадают, хост-
получатель отбрасывает кадр и отправляет в адрес xocia-отправителя сообщение об
ошибке. Хост-отправитель, в свою очередь, берет па себя ответственность за выявления
потерянною кадра, а также выполняет ею повторную передачу. Протокол TCP отсле-
живав! информацию, содержащуюся в заголовке IP (такую, как IP-адреса получателя и
отправителя), чтобы иметь возможность оказать протоколу 1Р содействие в выявлении
таких проблем, как неправильная маршрутизация кадров.

Поле указателя срочности

Поле указателя срочности (Urgent Pointer), имеющее длину 2 байта, активизируется
только в случае установки флага срочности URG в поле управляющих флагов (Control
Flags). Когда бит срочности устанавливается хостом-отправителем, указатель срочнос-
ти (Urgent Pointer) идентифицирует ют бант кадра, который следует сразу же за сроч-
ними данными и, таким образом, однозначно указывает на начало данных с обычным
уровнем приоритетности.

Дополнительные параметры TCP (переменная длина)

Поле дополнительных параметров TCP (Options) имеет переменную длину в зависи-
мости от того, какой дополнительные параметр избран хостом-отправителем. Напри-
мер, в качестве такою параметра хост-отпрлвитс ть мог бы выбрать максимальный раз-
мер сегмента (MSS, maximum segment size). В таком случае указанное в данном поле
значение определяет размер самого большого ceiмента, который хосг может принять.
Если в поле дополнительных параметров не указано значение MSS, хост можс-т принять
сегмент любого размера Максимальный размер сегмента (MSS) — наиболее часто ис-
пользуемый дополншельный параметр Полное описание поля дополнительных пара-
метров (Options) выхотит за рамки данной книга.

Псевдозаголовок TCP

Поле длины TCP-пакета (Lensth), значение которого является величиной перемен-
ной. идентифицирует общую длину заголовка TCP и следующих за ним данных, за ис-
ключением информации, содержащейся в псевдозаголовке TCP (TCP pseudo header).
Поскольку размер самого заюлонка TCP и объем передаваемых данных меняется в за-
висимости от обстоягельсIB. устанавливаемое в данном поле значение также является
переменной величиной. Следуег отметить, что хотя протокол ТС Р вк 1ючает поле дли-
ны сегмента TCP (Length) в заголовок TCP. в действительности это поле не отобража-
ется в окне анализатора протоколов Sniffer.

Псевдозаюловок TCP (TCP pseudo header) обеспечивает контроль над возникнове-
нием и исправлением ошибок в заголовке IP. а также устанавливает факт неправиль-
ной маршрутизации ка 1ров Псевчозаголовок TCP гарантирует доставку передаваемой
хостом-огправителем пентаграммы в требуемый пункт назначения Протокол TCP не
включает в TCP-паке- информацию содержащуюся в псевдозаголовке. TCP хранит эту
информацию в буфере запоминающею устройства, имеющем название "Блок управле-
ния передачей данных” (ТСВ, transmission control block) На рис. 8 6 показан пример
псевдозаюловка TCP

РИСУНОК 8 6 ПссвРгиаго гонок
ICP nojenixem протоколу TCP
выполнить двойной контроль над
прибытием оеипюграммы в
требуемый пункт на точения

Основные механизмы протокола TCP

Для обеспечения надежной доставки данных в пункт назначения протокол TCP пре-
дусматривает наличие двунаправленною к нала передачи данных (bidirectional
communication р'рс) между у аллейными процессами. Такой двунаправленный канал иден-
тифицируется cooTBCiCTByioimiMH номерами портов TCP на конечных хостах. Кэк у.тзерж-
дается в RFC 793, протокол TCP регулирует процесс взаимодеипвия между удаленны-
ми процессами с помощью следующих имеющихся нею распоряжении возможностей

IP-адрес отправителя		
IP-адрес получателя		
Ноли	IP протокол	ДпюлТСР-пивтв
•	Установление соединения (connection setup)

•	Закрытие соединения (connection teardown)

•	Мультиплексирование (multiplexing)

•	Передача данных (data transfer)

•	Управление потоком (flow control)

•	Надежность (reliability)

•	Приоритет (precedence) и зашита данных (security)

Протокол TCP выполняет гарантированную доставку данных в пункт назначения, и.
безусловно он делает это намного быстрее, чем доставка корреспонденций no Fed-EX
(Fed-EX — Federal Express, Федеральная служба доставки почты). С другой стороны,
протокол TCP выполняет передачу данных медленнее, чем протокол UDP, который, в
свою очередь, совсем не обеспечивает надежности доставки данных.

Достижение протоколом TCP свойственного ему высокого уровня надежности дос-
тавки данных в пункт назначения влечет за собой рост непроизводительных затрат, свя-
занных с установлением, поддержанием и завершением сеансов связи между хостами.
В отличие от не ориентированных на соединение проколов, TCP не возлагает ответствен-
ность за прокладывание пути для прохождения данных на протоколы верхних уровней.
Протокол TCP не ограничивается одной лишь идентификацией выполняемых на хосте-
отправителе и хосте-получателе процессов, только помешан данные в канал связи с на-
деждой на то, что эти данные достигнут пункта назначения без дальнейшего вмешатель-
ства TCP. Для обеспечения гарантированной доставки TCP пакетов в пункт назначения
протокол TCP использует такие процедуры, как упорядочивание передаваемых cet мен-
тов данных (sequencing) и выдача подтверждений об их получении (acknowledgements).

В отличие от протокола UDP. выполняющего сходные с TCP функции, протокол TCP
при получении потока данных (сообщений) разбивает этот поток на сегменты (сегмен-
тирует его) и присваивает порядковый номер (sequence number) каждому передаваемо-
му сегменту данных перед доставкой данных в пункт назначения в дейтаграмме IP. Для
обеспечения гарантированной доставки каждого отправленного хостом-отправи гелем сег-
мента протокол TCP предусматривает выдачу подтверждения приема каждого сегмента
дейтатраммы, имеющего порядковый номер. Протокол TCP хранит копии всех переда-
ваемых сегментов данных в буфере ЗУ хоста-отправителя, известном под названием
“Блок управления передачей данных" (ТСВ, transmission control block). Если TCP не по-
лучает подтверждения приема данных, он делает предположение, что дейта(рамма по-
теряна. и выполняет ее повторную пересылку Более подробно процедура упорядочива-
ния сегментов данных и выдачи подтверждений об их получении рассматривается ниже
в данной главе.

Установление и закрытие соединения

Обязательным условием гарантированной доставки данных между удаленными про-
цессами является установление протоколом TCP соединения между хостами (connection
setup) еше до начала обмена значащими данными между приложениями верхнего уров-
ня. Для выполнения этой задачи протокол TCP прежде всего устанавливает между пор-
тами удаленных хостов так называемое "логическое соединение — logical circuit". Такое
соединение связывает порш иди процессы, выполняющиеся на каждом из двух конеч-
ных хостов. TCP поддерживает это соединение на протяжении всего сеанса связи и зак-
рывает сто (connection teardown), ктда отпадает необходимость в дальнейшем поддер-
жании соединения.

Протокол TCP устанавливает сеанс связи между удаленными хостами сразу же пос-
ле выяснения протоколом IР ло! ического адреса хоста назначения. Установленный про-
токолом TCP сеанс связи является для протоколов верхнего уровня надежной базой для
обеспечения 1арантированной доставки данных в пункт назначения. Протокол TCP за-
вершает сеанс связи, козда пользователь или один из хостов инициирует завершение
этого сеанса связи. Процедура установления (session setup) и завершения (session
teardown) сеансов связи, а также процедура обмена данными (exchange) рассматривает-
ся более подробно ниже в текущей главе.

Мультиплексирование

Возможность мультиплексной передачи данных (multiplexing) позволяет протоколу
TCP устанавливать и поддерживать одновременно несколько коммуникационных путей
между двумя хостами. Мультиплексирование позволяет также одному хосту дифферен-
цировать и поддерживать сеансы связи с несколькими хостами в одно и то же время.
Возможность мультиплексной передачи данных чрезвычайно важна для хостов, посколь-
ку на них. как правило, выполняется несколько приложении или служб, таких как Telnet,
FTP или друг ие службы. Протокол TCP должен иметь возможность отличить один про-
цесс от другою, а также координировать и обслуживать коммуникационный процесс для
каждого из этих процессов.

Для выполнения упомянутой выше задачи протокол TCP использует порты, позво-
ляющие дифференцировать коммуникации между различными процессами и координи-
ровать их (более подробную информацию о мультиплексоре обслуживания ТСР-портов
TCPMUX можно найти в RFC 1078). Как упоминалось в главе 6. существует два основ-
ных типа портов: порты серверов (server ports) и порты клиентов (client ports) Порты
серверов идентифицируют основные приложения и службы (например, Telnet — порт
23, SMTP — nopi 25, FTP — порты 20, 21). Порты клиентов не присваиваются на посто-
янной основе; они выбираются оперативно и применяются динамически Номера пор-
тов клиентов находятся в диапазоне от 1024 до 65535.

Каждый раз, Koiaa хост активизирует выполнение какого-либо процесса, это вызы-
вает открытие одного из портов, а также выделение этому процессу определенных ре-
сурсов. Кода у процесса отпадает необходимость в использовании порта, он закрывает
этот порт и освобождает выделенные ему через эгоз порт ресурсы для их перераспреде-
ления между другими процессами. Протокол TCP использует порты для идентифика-
ции пары процессов, выполняемых хостом-отправителем и хостом-получателем. Выде-
ленный тому или иному хосту порг вместе с логическим IP-адресом сетевою уровня (в
коммуникационной модели организации сетевого комплекса DoD) образует так назы-
ваемый сокет (socket), который, в свою очередь, однозначно идентифицирует выполня-
емый на хосте процесс. После установления TCP-соединения между двумя удаленными
хостами соответствующие згим хостам сокеты образуют пару сокетов (socket pair), ко-
торая н формирует соединение между локальными процессами, выполняемыми на ко-
нечных хостах (см. рис. 8.7) Образование пар сокетов позволяет хосту дифференниро-
вать соединения, связывающие данным хост с различными процессами одного и тою
же хосга, иди с разными хостами.

РИСУНОК 87

IP-адрес клиента и порт
клиента, а также /Р-адрес
сервера и порт сервера
образуют так называемую
пару сокетов.

Передача данных

Протокол TCP получает данные от приложений верхних уровнен, сегментирует их и
передает на нижний уровень для формирования из полученных сегментов данных IP-
дейтатрамм. а также их адресации, пакетирования и доставки в пункт назначения про-
токолом IP на сетевом уровне. Когда протокол IP получает дейтаграммы от удаленного
хоста, он исследует указанный в заголовке IP адрес верхнего уровня для того, чтобы оп-
ределить. через какой протокол (TCP или UDP) он должен передать полученную дей-
таграмму для ее дальнейшей обработки. На рис. 8.8 представлен заголовок IP, в кото-
ром присутствует ссылка на протокол TCP как на протокол верхнего уровня.

Протокол TCP функционирует на базе протокола Интернета (IP), который обеспе-
чивает адресацию дейтаграмм на сетевом уровне, а также доставку дейтаграмм между
конечными хостами без создания соединения. Значение 06. указанное в поле типа про-
токола (Proiocol) заголовка IP, идентифицирует протокол TCP, Значение 17. указанное
в том же поле заголовка 1Р, соответствует протоколу LIDP.

Когда TCP получает от протокола IP дейтаграммы, содержащие сегменты данных,
он выполняет их повторную сборку (reassembly) в упорядоченные потоки данных (со-
общения), определяет принимающий порт клиента или сервера и передает эти потоки
данных соответствующему приложению (верхнего уровня) для дальнейшей обработки
Между приложениями верхнего уровня и протоколом Интернета нижнею уровня уста-
навливается двунаправленное взаимодействие, направление которого зависит от того,
куда передвигается поток данных Протокол TCP предоставляет одни и те же услуги всем
протоколам верхнею уровня. В тскушем разделе данной главы представлено весьма
упрошенное описание действия протокола TCP. Более подробное описание механизмов
функционирования TCP следует ниже в данной главе.
РИСУНОК 8.8 Протокол TCP передает сегменты данных на нижний (сетевой) уровень — протоколу
IP — дли прео*"азованиг. эти.г сегментов данных в дейтаграммы.

Управление потоком

Для обеспечения доставки данных в пункт назначения протоколу TCP необходимо
иметь в своем распоряжении какой -либо способ регулирования входящею потока дан-
ных Применение механизма управления потоком (flow control) гарантирует отсутствие
переполнения принимающего буфера хоста-получателя. Управление потоком также пре-
доставляет хосту-получателю возможность соотьщствуюшим образом обрабатывать по-
лученные данные и отвечать на запросы хоста-отправителя. Функция регулирования
потока данных поддерживается с помощью оконного механизма передачи данных
(window mechanism), идентифицированного в соответствующем поле заголовка TCP.
Управление потоком данных и заголовок TCP рассматриваются Зопее подробно ниже в
данной главе.

Каждый конечный хост обслуживает свое собственное окно и информирует другую
сторону о состоянии этого окна. Когда окно заполняется, хост сокращает размер окна и
сообщает об этом партнеру по коммуникации. Тем самым хост, в сущности, отправляет
в адрес противоположной стороны запрос на снижение скорости перечачи данных.

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

Надежность

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

Хост-получатель не отправляет АСК в случае потери дейтаграммы в процессе пере-
дачи Задача обнаружения потерянных или отсутствующих кадров, а также задача по-
вторной их пересылки в случае необходимости возлагается на хост — источник данных
(хост-отправитель). Если отправитель данных не получает подтверждения о получении
на протяжении определенного периода времени, он постанавливает эти данные с по-
мощью хранящейся в буфере ТСВ копии и выполняет повторную пересылку потерян-
ных cei ментов данных. Период времени, выделяемого на обнаружение потерянного кадра
и его повторную пересылку, задается специально сконфигурированным на хосте-отпра-
вителе таймером. Устанавливаемое в таком таймере значение вычисляется на основе
задержки, равной времени полного обхода (round-trip delay) И если время в таймере
истекает до получения подтверждения, то хост-отправитель считает, чго дейтаграмма
потеряна, и повторяет, передачу этой дейтаграммы.

Протокол TCP решает вопрос обнаружения поврежденных кадров посредством со-
держащегося в заголовке TCP поля CRC (Cyclic Redundancy Check, Проверка целостно-
сти данных при помощи избыточного циклического кола). Перед передачей данных хост-
отправитель выполняет вычисление контрольной суммы на основе алгоритма CRC. После
получения данных хост-получатель посредством того же алгоритма также вычисляет кон-
трольную сумму Совпадение или несовпадение этих двух значений позволяет опреде-
лить, была ли дейтаграмма повреждена во время пересылки. Если хост-получатель фик-
сирует повреждение дейтаграммы, он просто отбрасывает кадр, не прелупрежлая об этом
хост-отправитель. По прошествии определенного периода времени хост-отправитель об-
наруживает возникновение проблемы с передачей кадра, поскольку от хосга-получате-
ля не поступило соответствующего подтверждения. Именно на данном этапе истекает
значение таймера TCP, что побуждает хост-отправитель выполнить повторную переда-
чу данных.

Приоритет и защита данных

Обязательным требованием, предъявляемым Министерством Обороны США к реа-
лизации в его сетях какого бы то ни было протокола, является поддержка этим прото-
колом многоуровневой модели зашиты данных от несанкционированного доступа
(multilevel security model), а также поддержка передачи данных согласно различным
уровням приоритета (precedence levels). Протокол TCP имеет возможность использовать
значения, устанавливаемые в поле типа обслуживания (Type of Service) заголовка IP.
для обеспечения требуемого при юлением верхнею уровня типа обслуживания и спо-
соба запнгты данных На рис 8.9 иредставлетты опции, входящие в состав поля типа
сервиса (Туре of Service) заголовка IP. Соошегственно этим опциям протокол TCP обес-
печивает процесс передачи данных тля приложений верхних уровней согласно следую-
щим .характеристикам:

•	Приоритет (precedence)

•	Задержка (delay)

•	Прон шолителытоегь (throughput)

•	Надежность (reliability)

°ИСУНОК 8 9 Питы ия 7<>Л окачивают  lumiue на способ передачи дейтаграммы в пункт
шпночеиия

II с.р типы в п< те типа обсчуживания (Type oTService) заюловка IP ука-
тки на ким otip.1 »м tyei выпо.тнягь передачу дейтаграммы В случае реа-

• и v.  тм.(вливаемых в поле типа сервиса параметров (приоритет, задержка, нро-
н 1  питслыю.ть и надежность» ни параметры оказывают влияние на выбор маршрута
для доставки деитатрамм в пункт назначения. Например, если приложению необходи-
ма доставка дешатраммы по самому быстродействующему каналу, в случае наличия
нескольких ну ген к пункту назначения это приложение может по требовать от маршру-
тизатором перт пять соответствующий кадр по пули с минимальной задержкой.

П нус навлитк -мыи в поле типа обслуживания (ToS) параметр, известный как
и,	।  .с. <|ч . dence). указывает на то. какую информацию со-
держит дейтаграмма: с обычным или высоким уровнем приоритета От уровня приори-
тета зависит и уровень защиты данных (security level): чем выше приоригег, тем выше
уровень зашиты Хост с некорректно установленным или более низким уровнем при-
оритета (уровнем зашиты данных) не может установить соединение с другим хостом,
имеющим более высокий уровень приоритета. В связи со сложившимся несовпадением
уровней приоритета хост отклоняет запрос другого хоста ня установление соединения,
основывая свое решение на требованиях многоуровневой системы защиты данных.

В отличие от протокола 1Р, также содержащего параметры типа сервиса в поле ToS
заголовка IP, протокол TCP может активизировать эти функции при каждом установ-
лении соединения посредством двунаправленного процесса коммуникации между дву-
мя конечными хостами. TCP имеет возможность хранить значения типов сервиса в со-
ответствующем буфере ЗУ с целью обеспечения усиленной зашиты данных от
несанкционированного доступа, а также для обеспечения более результативной достав-
ки данных между приложениями.

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

Как было отмечено в главе 6, все протоколы, входящие в состав стека протоколов
TCP/IP. можно разделить на две категории: ориентированные на соединение и нс ори-
ентированные на соединение протоколы. Поскольку TCP принадлежит к категории ори-
ентированных на соединение протоколов, в нем реализованы следующие шесть базо-
вые средства обеспечения гарантированной доставки данных в пункт назначения:

•	Установление сеанса связи {session setup)

•	Завершение сеанса связи (session reardown)

•	Упорядочивание передаваемых данных (sequencing)

•	Выдача подтверждении о получении (acknowledgements)

•	Поддержание соединения активным (keepalives)

•	Управление потоком данных (flow control)

Более подробное рассмотрение действия всех этих базовых характеристик протоко-
ла TCP представлено в последующих разделах текущей главы.

Установление сеанса связи

Для обеспечения гарантированной досгавки данных между удаленными процессами
или приложениями необходимо установить надежное, ориентированное на установле-
ние соединения логическое соединение (reliable connection-onented logical circuit) меж-
ду этими процессами или приложениями. Такое лог ическое соединение должно быть ус-
тановлено еще до начала передачи данных. Процедура установления сеанса связи (session
setup) остается неизменном независимо от того, какой процесс этот сеанс связи должен
обслуживать. В распоряжении протокола TCP имеется средство, позволяющее уникаль-
ным образом идентифицировать все процессы и приложения верхнего уровня: исполь-
зование адреса портов (ports) или сокетов (sockets) Каждому процессу, который выпол-
няется на том гиги ином хосте, соответствует отдельный порт. Следовательно, по номерам
портов протокол TCP имеет возможность отличать выполняемые на одном и том же хосте
процессы друг от друга. Такая дифференциация процессов по номерам их портов обес-
печивает гарантированную доставку данных между удаленными процессами и их обра-
ботку надлежащим образом.

Например, когда пользователь инициирует установление сеанса связи клиента Telnel
с удаленным сервером Telnet, активизируется локальный процесс инициализации Telnet-
клиента. В процессе инициализации локальный хост открывает соответствующий порт
клиента Telnet, номер которого находится в диапазоне от 1024 до 65535. Для обеспече-
ния успешного взаимодействия между клиентом и сервером Telnet протокол TCP ис-
пользует выбранный для Telnet-клиента порт источника в сочетании с портом назначе-
ния (для Telnet — общеизвестный порт 23), который однозначно идентифицирует
предполагаемого получателя текущего сообщения. Применение в процессе передачи со-
общения пары "порт отправителя — порт получателя" позволяет TCP поддерживать вза-
имодействие между двумя отдельными процессами, а также дифференцировать сеансы
связи между различными парами процессов, выполняемыми на удаленных хостах.

Если пользователь инициирует сеанс связи с удаленным хостом, используя при этом
имя хоста вместо его IP-адреса, необходимо выполнить преобразование указанного име-
ни хоста назначения в его IP-адрес с помощью одного из протоколов разрешения адре-
сов. Разрешение адресов (address resolution) позволит определить по имени хоста либо
сетевой адрес этого удаленного пункта назначения (если он входит в состав той же под-
сети), либо сетевой адрес шлюза. После определения IP-адреса хоста назначения на
сетевом уровне протокол ARP выполняет трансляцию этого адреса в адрес МАС (физи-
ческий адрес) для осуществления доставки данных на уровне локального сегмента сети.

Образование пар сокетов

После завершения процедуры разрешения адресов в распоряжении протокола TCP
имеется достаточно информации для того, чтобы начать процедуру установления сеан-
са связи. Сокет источника (его адрес на сетевом уровне и порт клиента), а также сокет
назначения (его адрес на сетевом уровне и порт сервера) образуют так называемую пару
сокетов (socket pair). Один клиент или совокупность клиентов могут затребовать уста-
новления соединений с одним и тем же удаленным сервером. Образование пар сокетов
позволяет разграничить различные запросы на установление соединения, поскольку
такой способ позволяет TCP уникальным образом идентифицировать и правильно орга-
низовать процесс взаимодействия между парами удаленных процессов. Для успешного
функционирования протокола TCP. в обязанности которого входит обслуживание мно-
жества всевозможных соединений, образование пар сокетов (socket pairing) имеет ре-
шающее значение.

Установление сеанса связи (session setup) начинается с установки клиентом TCP бита
синхронизации (SYN) в поле управляющих флагов (Control Flags) заголовка TCP Флаг
SYN указывает на то, что клиентский TCP-процесс запрашивает синхронизацию своих
действий с серверным TCP-процессом (процессом, выполняемым на хосте назначения).
TCP хоста-получателя должен отправить подтверждение (АСК) о получении начально-
го сегмента синхронизации (SYN) и передать свои запрос на синхронизацию, содержа-
щий сегмент синхронизации (SYN). Получатель этого запроса также должен подтвер-
дить его получение.
На рис 8.10, 8 11 и 8 12 представлен пример установления сеанса связи На июго-
вой панели анализатора протоколов Sniffer показаны два хоста (192.42 252.20 и
192.42.252.1), принимающие участие в процессе установления соединения TCP. Как
можно увидеть по первому кадру, хост 192.42.252.20. использующий порт клиента с но-
мером 2921. запрашивает установление соединения посредством отправки начального
сегмента синхронизации SYN в адрес сервера Telnet, идентифицируемого портом 23 и
IP-адресом 192.42.252.1.	„	,

пДДР I

I

РИСУНОК 8.10 Первый зтап установления сеанса связи между выполняемыми на конечных хост-
компьютерах процессами TCP заключается в пересылке клиентским ТСРпроцессом сегмента
синхронизации в адрес серверного TCP процесса. Следует обратить внимание ни то, что кадр,
передающий начальный запрос на синхронизацию, не содержит подтверждения (АСК), поскольку ни
со стороны клиента, ни со стороны сервера еще не выполнялась передача данных. поззчение которых
нужно бы to бы подтверждать.

Сервер Telnet отправляет следующий кадр, содержавши подтверждение (АСК) при-
ема отправленного ранее клиентом cei мента синхронизации (SYN), а также новый зап-
рос на синхронизацию (SYN) самого сервера Telnet. Следует обратить внимание на то,
что в этом кадре присутствует поле АСК, подтверждающее получение отправленного
клиентом начальною сегмента синхронизации (SYN). Протокол TCP может функцио-
нировать в полнодуп 1ексном режиме (Tull duplex mode); другими словами. 1СР может
совместить передачу данных партнеру по коммуникации с подтверждением приема дан-
ных от партнера в одном и том же кадре (вместо распределения этих двух сообщении
по разным кадрам). Следовательно, данный хост (в текущем примере — сервер Telnet)
может включить свой запрос на синхронизацию (SYN) в тот же кадр, в котором он пе-
редает подтверждение (АСК) о получении начального ceiмента SYN. Такая возможность
позволяет протоколу TCP функционировать более эффективно
Кадр 2

РИСУНОК 8 11 Второй этап vt танов гения сеанса связи TCP состоит в выдаче сервером
подтверждения (-1СА/ « получении пт к тента нача гымго сегмента синхронизации (SYJV) и передачи
сер ром п адр< к тента своего собственного сегмента синхронизации (SYN).

Кадр 3

«I ________ _________________________________________1_______________________________________•_

^•мЛкеДМю Д Нг» ’ем /***«« Сям
к <»	__________ St Ji

Я'1*н| О <5	/’У Дм........ -tj - ||<^srillm -	|	Jg -

РИСУНОК 8 12 Третий ннан хстаноилсния и-анси связи ТСР заключается в выдаче клиентом
• ' ' • • ерждения приема ( 1СА; сегмента синхронизации сервера (SYN)
Клиент отправляет третий кадр, в котором содержится подтверждение (ЛСК) о по-
лучении отправленного ранее Telnet-сервером запроса на синхронизацию (SYN). На лом
этапе установление сеанса связи TCP между двумя хостами мол но считать завершен
ным; далее эти хосты могут начинать передачу данных службы Telnet. Следует отметить,
что рассмотренный выше процесс зрехэтапного обмена кадрами (three-frame exchange)
верен для любой службы, запрашиваемой тем или иным приложением (Telnet. SMTP,
FTP и т.д.).

Процесс обмена кадрами, содержащими запросы и подтверждения, называется трех-
ходовым квитированием (three-way handshake). Поскольку протокол TCP поддерживает
полнодуплексный режим взаимодействия между хостами, ему нужны только три кадра
вместо четырех для завершения данного процесса После получения от хоста-отправи-
теля первого запроса, содержащего сегмент синхронизации (SYN), хост назначения от-
правляет ответ на этот запрос, содержащий как подтверждение приема (АСК) началь-
ного сегмента синхронизации (SYN), так и се!мент синхронизации (SYN) самою
хоста-получателя.

Для завершения транзакции хост-отправитель передает свое под1верждение (АСК) о
получении отправленного хостом назначения сегмента синхронизации tSYN) Кздр, в
котором передается подтверждение отправителя, является последним кадром процеду-
ры трехходового квитирования. На рис. 8.13, 8.14 и 8.15 представлена подробная схема
этой процедуры. Как видно по заголовку TCP, хост усыновил в поле флагов (Flags) бит
синхронизации (SYN) со значением 1 Кроме того, в заголовке TCP указаны некоторые
другие начальные параметры, такие как начальный порядковый номер — 1545216000
(ISN. initial sequence number), размер приемного окна (window sjfce'j — 4096 байт, и мак-
симальный размер сегмента (MSS, maximum segment size) — 1024 баш Соо1ветствую-
шие поля заголовка TCP и устанавливаемые в них значения рассматриваются более
подробно ниже в данной главе.

На рис.8 14 представлен пример кадра, содержащею отпет I Jnel-серверi (IP адрес
192.42.252.1, порт источника 23). В этот oi set сервер включает свое нодтверх I нис (АСК)
о получении начального запроса клиента (содержащего порядковый номер 1545216000».
Отправленный в подтверждении сервера порядковый номер соответствует порядковому
номеру сегмента, который сервер ожидает получить oi клиента еле июшнм (154^21 Ь001)
Тем самым подразумевается, что сервер получил все сегменты с порядковыми номера-
ми вплоть до указанною номера (не включая его). В заголовке TCP укмзан ><хжжс на
чальный порядковый номер (ISN) сервера Telnet (49856000). Сервер усынови i ь ноле
флагов (Flags) бит синхронизации (SYN), указывая тем самым на свое намер син-
хронизировать с клиентом такие значения, как размер окна (window size) - 4096 байт,
и максимальный размер сегмента (MSS) — 1024 бант

Клиент отравляет последний кадр процедуры трехходового квитирования с целью
подтверждения приема отправленного сервером сегмента синхронизации (SYN). Это под-
тверждение приема отправленного ранее Telnet-сервером порядкового номера, собствен-
но, закл ючается в том, что клиент указывает в своем сообщении порядковый номер сег-
мента, который он ожидает получить от сервера следующим (49856061) После
завершения данного этапа процедуры трехходовою квитирования оба хоста (клиент и
сервер) имеют в своем распоряжении начальные параметры друг друга, согласованные
по времени.
282 Глава 8

РИСУНОК 8.13 Передача клиентом начального сегмента синхронизации (SYN) представляет собой
первый этап процедуры трехходового квитирования

МгВПВВКИВЖПЖ8Ш=ЕЕ

2 Е*а hJcrto £<tw k -5»w I«t* t '-Jew

^|И| ai^j sltfaltoWalgjvgl й! e|

J IF; fie ad er checkeuia - 13D4 i Correct)
JIP: Source address • [192-42.25?,!]
О IP: Destination address • [19-.42.2ВД.20]
J IP: No options

_JLP:

HTTP: -
□ TCP:
D TCP:
О TCP;

31CP:
QTCP:

О TCP:
DTCP:
□ TCP:
DTCP;
DTCP:
QTCP:
DTCP:
£}TCP:
DTCP:
DTCPi
Dtcps
OTCFi
О TCP:
О TCP:

TCP header

Source port	-	23 (Telnet)

Destination port	-	2921

Initic1 sequence number - 48056ГЛО

Acknowledgment numb*г • 1545216001

Deta offset	-	24 bytes

Flagi	-	12

.0.	. - (No urgent pointer)

...1 .... • Acknowledgment

.... 0.. . - (No push)

.0. • (No reset)

..1 - SYN

...0 - (No FIN)

Window	-	4096

ChcckEum	-	CGCA (correct)

Options follow

Maximum  «greent size - 1024

(«о* Дме/ ti /, Hai 1 «> йлвдя м X Stet -wt«- /

О Игр, preu* П	(gfe

gafrav ДИмЛм I ajtxto, | ysnll«ft I i^E«tetro I

РИСУНОК 8.14 На данном рисунке в окне анализатора протоколов Sniffer можно увидеть

подтверждение ( (ГА? и сегмент синхронизации (S)N). отпрошенные сервером на втором этапе

процедуры трехходового квитирстпшн



7Т»; П ' <<зрм
РИСУНОК 8.15 Клиент отправляет свое подтверждение АСК на втором этапе процедуры
трехходового квитирования

Протокол TCP включает начальные параметры, которые должны быть согласованы
между конечными хостами для успешной синхронизации сеансов связи между ними, в
кадры, с помощью которых передаются запросы на синхронизацию (SYN). В число па-
раметров, подлежащих согласованию, входят следующие: размер приемного буфера
(receive buffer size) — этот параметр является адаптируемым; начальный порядковый
номер (initial sequence number) — этот номер используется, когда начинается передача
данных, максимальный размер сегмента, который может принять хост TCP (maximum
segment size) — этот параметр является необязательным. После завершения процедуры
трехходовою квитирования начинается процесс передачи значащих данных между
пользователями. Упомянутые выше параметры рассматриваются более подробно ниже
в данной мане.

Завершение сеанса связи

Запрос на завершение сеанса связи (session teardown) может исходить либо от самого
пользователя, либо от протокола TCP. Если пользователь больше не нуждается в услу-
гах удаленного приложения, он может выйти из локального приложения, инициируя тем
самым выдачу запроса на завершение сеанса связи (session teardown request). Процедура
завершения сеанса связи аналогична процедуре установления сеанса. Протокол TCP ис-
пользует для закрытия сеанса связи такой же трехэтапный обмен кадрами (three-frame
exchange). Инициировать завершение сеанса связи может любая из взаимодействующих
сторон. Хост 192.42.252.) (порядковый номер 49856607) отправляет начальный запрос на
завершение сеанса связи, содержащий заключительный сегмент (FIN), в первом кадре.
Рис. 8.16 8.17 и 8.18 иллюстрируют пример запроса на завершение сеанса связи.

кадр 1

I

РИСУНОК 16 Первым этапом завершения сеанса связи является передача заключительного
сегмента (FIN)

Кадр 2

РИСУНОК 8 17 На втором этапе завершения сеанса связи хост птправ зяет подтверждение АСК а
так же свой запрос на ,мершение сеанса (FIN)
Кадр 3

РИСУНОК 8.18 На третьем (зак почитемном) этапе завершения сеанса связи хост отправляет
подтверждение (АСИ) о получении запроса на завершение сеанса (FIN) другого хоста.

Получатель отправляет свое подтверждение (ЛСК) о приеме запроса, содержащего
заключительный се!мент (FIN), с указанием порядкового номера се1мента. который он
ожидает получить следующим (49856608). Кроме тою. хост-получатель отправляет свои
собственный запрос на завершение сеанса (FIN), а также порядковый номер (1545216061).
Хост — инициатор завершения сеанса связи отравляет последний кадр, подтверждаю-
щий получение предыдущего запроса FIN Это действие закрыв i соединение, после
чего хосты не могут обмениваться информацией при южений bi рхннх уровней до тех
пор, пока нс будет установлен новы и сеанс связи TCP

Протокол TCP также отправляет но юбный тапрос на завершение сеанса связи в слу-
чае обнаружения ошибки или отказа в доступе во время установления сеанса связи TCP.
Возникновение одной из этих проблем стимулирует либо клиентский, либо серверный
ТСР-пронесс выдать запрос на закрытие соединения. Каков бы ни была причина, за-
вершение сеанса связи веет да выполняется посредством процедуры трехходового кви-
тирования. Так же, как и н случае установления сеанса святи, во время завершения се-
анса используется трехэтапный обмен кадрами.

Хост, запрашивающий закрытие сеанса, устанавливает биг завершения передачи (FIN)
в поле флагов (Flags) заголовка TCP, указывая тем самым на то, что данное сообщение
содержит запрос на завершение сеанса связи. Далее выполняется передача заключитель-
ного сегмента (FIN) партнеру по коммуникации. Получатель должен, в свою очередь.
подтвердить прием (АСК) начального запроса FIN. а также отправить свои собствен-
ный запрос на завершение сеанса (F1N ). Получение этого запроса также дочжно бьггь
подтверждено хостом, инициировавшим завершение сеанса связи. На данном этапе оба
хоста освобождают выделенные им ресурсы, делая их доступными для других пронес
сов.

Упорядочивание и подтверждение кадров

Максимальная надежность передачи данных между хостами — это задача первосте-
пенной важности для предоставляемых протоколом TCP служб Чтооы обеспечить га-
рантированную доставку данных в г* нкт назначения. TCP присваивает порядковый
номер каждому передаваемому им сегменту данных (эта процедура называется упоря-
дочиванием — sequencing» С одной стороны, такой подход к передаче данных может
показаться избыточным. поскольку многие протоколы присваивают порядковый номер
каждой дейта! рамме независимо от того, какой объем данных в ней псретдется Одна-
ко, с другой стороны, этот подход позволяет проконтролировать пере гачу каждого от-
правленного байта данных в пункт назначения Отслеживание всех отправленных дан-
ных (tracking) позволяет обнаружить и устранить проблемы, связанные с потерей данных
(lost data), с дублированием данных (duplicate data) или с доставкой данных не в том по-
рядке, в котором они были отправлены (data delivered out of order).

Каждый раз, когда хост отправляет данные в адрес партнера по коммуникации, про-
токол TCF присваивает порядковый номер (sequence number) каждому отправленному
сегменту данных. Далее TCP на протяжении определенного периода времени ожидает
положительного подтверждения (АСК) о получении байтов данных с присвоенными им
порядковыми номерами (упомянутый выше период времени вычисляется с помощью ал-
горитма. который рассматривается ниже в данной главе). Ес m получатель не отвечает
подтверждением о получении (АСК) в течение заданного периода времени, хост-отпра-
витель выполняет повторную пересылку (retransmission) iex данных, получение кото-
рых не было подтвер» депо соответствующим сообщением АСК,

Получатель также использует порядковые номера для подтверждения приема данных.
Задача процедуры подтверждения анало!ична: обнаружение отсу 1Сгвуюших, получен-
ных не в том порядке или дублированных данных отправленных партнером по комму-
никации. Как только получатель принимав! все сегменты данных с присвоенными им
порядковыми номерами, он может перекомпоновав эш cei мен гы, сформировав из них
потоки данных (data streams), или сообщения, предназначенные для передачи процес-
сам и приложениям верхнего уровня с целью дальнейшей обработки данных Перед
передачей подученной информации приложению верхнего уровня хосг-получатечь по-
мешает поступающие сегменты 1СР в буфер и использует порядковые номера с целью
проверки порядка поступления занных.

Поскольку леиг.праммы могут передаваться адресатам по маршрутам с весьма отли-
чающимися характеристиками, некогорые сегменты данных могут прибывать в пункты
назначения со значительной задержкой. Хосч^получагель подтверждает прием отправ-
енных в его адрес данных в последовательном порядке. Например, если хост-отправи-
тель передает сегменты с порядковыми номерами I. 2. 3 и 4, а хост назначения получа-
С! только сегменты с номерами 1, 2 и 4, получатель! юдтверждает прием только сегментов
1 и 2 посредством передачи подтверждения АСК=3.
Получатель хранит в своем буфере сегмент 4 в надежде на то, что сегмент 3 в ско-
ром времени появится Если сегмент 3 так и не поступает в пункт назначения, хост-от-
правитель должен выполнить повторную пересылку данных. При более благоприятном
исходе сет мент 3 все-таки достигает пункта назначения, а хост-получатель располагает
полученные сегменты в должном порядке, подтверждает прием сегментов 3 и 4 и пере-
дает полученную информацию на верхний уровень для дальнейшей обработки

В процессе установления сеанса связи протокол TCP каждого из двух конечных хо-
стов использует один из алгоритмов для вычисления начального порядкового номера
(starling sequence value), необходимого для инициализации процесса обмена данными
между выполняемыми на конечных хостах процессами Каждый из двух взаимодействую-
щих хостов объявляет свой начальный порядковый номер (initial sequence number) в исход-
ном кадре синхронизации (SYN). На рис. 8.19 представлен пример установления сеанса связи
TCP с указанием начального порядкового номера в соответствующем поле (Sequence
Number) заюловка TCP и установкой в поле флагов (Flags) бига синхронизации SYN.

РИСУНОК 8.19 В процессе обмена запросами на синхронизацию (SYN) с партнером по комчуникации
хост обгммяет свои качам>ный порядковый номер — 1545216000.

Каждый партнер но коммуникации может отправить свое подтверждение в той же
дейтаграмме, в которой передается порядковый номер. Такая возможность обеспечива-
ется наличием в составе заголовка дейтаграммы поля порядкового номера (Sequence
Number) и поля номера подтверждения (Acknowledgement Number). В поле порядкового
номера (Sequence Number) устанавливается значение начального порядкового номера
первого байта передаваемой в данной дейтаграмме информации. Устанавливаемое в поле
номера подтверждения (Acknowledgement Number) значение указывает на получение от
другой стороны сегментов данных с порядковыми номерами до указанного, но не вклю-
чая ею. Указанное в поле АСК значение соответствует порядковому номеру сегмента,
который хост-получагель ожидаез принять следующим.

Непосредственно посте установления сеанса связи между двумя конечными хоста-
ми отправитель присваивает каждому байту передаваемой информации порядковый
номер, а получатель отправляет подтверждения приема каждого полученного им байта
В состав заголовка TCP входит поле длины дейтаграммы (Length), в котором указыва-
ется объем пересылаемых в этой дейтаграмме данных (в байтах). Хост назначения при-
бавляет это значение к отправленному источником дейтаграммы начальному порядко-
вому номеру, чтобы определить номер подтверждения, подлежащего отправке в качестве
ответа на получение дейтаграммы.

Например, если хрет-отнравитель передает порядковый номер 100. и отправляет 100
байтов данных (число 100 представляет длину деи1а1 раммы в байтах) В таком случае
хост-получатель отправил бы в ответном кадре подтверждение (АСК), значение кото-
рого равно 200. Это значение соответствует порядковому номеру cei мента данных, ожи-
даемого первым в следующей дейтаграмме. Значение номера подтверждения вычисля-
ется по следующей формуле: начальный порядковый номер (в данном случае он равен
100) плюс длина отправленных данных в байтах (в данном случае 100) равняется номе-
ру подтвержден ня (200). Рассмотрим применение этой формулы для вычисления значе-
ния АСК при пересылке кадров, изображенных на рис. 8.20 и 8.21. Служба Telnet явля-
ется прекрасной иллюстрацией процедуры подтверждения приема данных, поскольку в
случае Telnet данные пересылаются по одному байту, что делает механизм упорядочи-
вания данных и подтверждения их получения вполне прозрачным

РИСУНОК 8.20 Протокол TCP присваивает порядковый номер каждому сегменту данных.
РИСУНОХ 8.21 ’Цвонюкол TCP подтверждает отучение каждого сегменту данных.

В первом кадре (рис.8.20) показано, что хост 192.42.252 20 отправил один байт обра-
батываемых службой Telnet данных. Это можно увидеть по символу 1. указанному в
одном из полей заголовка Telnet. В поле длины дейтаграммы (Length), находящемся в
заключительной части заголовка TCP, в скобках указано, что пересылается 1 байт дан-
ных Порядковый номер текущего кадра равен 1545216045. Применив приведенную выше
формулу, можно вычислить номер подтверждения (АСК), который должен быть отправ-
лен получате'1ем в качестве ответа порядковый номер (15452I6U45) плюс длина (I) рав-
няется 154521604b Во втором кадре (рис.8.21) показан ответ хоста назначения на полу-
чение первого кадра. Telnet-сервер подтверждает получение первою кклра посредством
отправки АСК, значение которого равно 1545216046. Это именно го значение, которое
было вычислено по формуле.

Повторная передача

Необходимость в повторной передаче данных (retransmission) определяет хосi-отпра-
вите чь. Поскольку дейтаграммы часто перелаются в пункт назначения по разным мар-
шрутам, существует бол! шая вероятность потери некоторых из них. Хост-отправитель
хранит копии передаваемых данных н t случай, если понадобится повторная передача
потерянных дейтаграмм в адрес хоста назначения Хост отправитель ра>мешает копии
отправленных сегментов данных в очередь на повторную передачу (retransmission queue)
на случай возникновения необходимости в повторной пересылке и запускает таймер.
Если хост от правитель получает соответствующее подтверждение в ответ на отправлен-
ные ранее данные, он удаляет копию подтвержденного сегмента данных из очереди. Если
же хост-отправитель не получает ответа с подтверждением о получении отправленных
им данных, или когда истекает значение таймера, он делает предположение, что дей-
та!рамма потеряна во время пересылки, и выполняет ее повторную передачу, восполь-
зовавшись находящейся в очереди копией потерянной дейтаграммы.

Таймеры

Значение, устанавливаемое в таймере повторной передачи (retransmission timer), вы-
числяется одним из алгоритмов на основании количества времени, прошедшего от мо-
мента отправки дейтаграммы до получения соответствующего подтверждения. Этот ал-
горитм динамически вычисляет значение периода повторной передачи (retransmission
time), оценивая время между пересылкой дейтаграммы и получением последующего
подтверждения. Далее этот результат используется алгоритмом для вычисления значе-
ния усредненною времени полного обхода (SRTT. smooth round trip time). На основе
значения SRTT и сконфигурированного на хосте базового значения таймера (base value)
вычисляется тайм-аут повторной передачи (RTO. retransmit timeout), используемый хо-
стом в процессе передачи данных. Сетевой администратор может изменить базовое зна-
чение таймера, чтобы иметь возможность модифицировать значение RTO, функциони-
рующею под управлением TCP хоста. Конфигурирование данного параметра с тем или
иным значением зависит от того, какая операционная система обслуживает хост.

Пользователю нет необходимости знать, какой именно алгоритм используется хос-
том для вычисления тайм-аута повторной передачи. Важно только то, что это значение
регулирует период ожидания протоколом TCP подтверждения о получении лей гаграм-
мы, но истечении которого TCP делает предположение о том. что дейга!рамма потеря-
на. и выполняет ее повторную передачу. На рис. 8.22 представлен пример повторной
передачи потерянных данных по истечении тайм-аута. На этом рисунке хост А отправ-
ляет кадры с порядковыми номерами II и 12 хосту В Хост В подтверждает прием этих
кадров посредством АСК=12 и АСК=13. Выдача подтверждения АСК-13 означает, что
хост В ожидает получить следующим от хоста А кадр с порядковым номером 13. Хост А
отправляет кадр с таким порядковым номером, но где-то на пути продвижения данного
кадра к пункту назначения возникает ошибка, в результате которой происходит потеря
кадра. Поскольку xoci А не получает от хоста В подтверждения о получении кадра с
порядковым номером 13, он считает этот кадр потерянным во время пересылки и вы-
полняет его повторную передачу по истечении тайм-аута.

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

Если значение таймера повторной передачи является слишком низким, хост может
повторять передачу дейтшраммы слишком часто. В таком случае хост назначения от-
правляет подтверждение о приеме полученного им ранее кадра, но еще до получения
хостом-отправителем этого подтверждения значение таймера повторной передачи ис-
текает. Хост-отправитель делает предположение, что хост назначения не получил отирав-
ленный ему ранее кадр, и пересылает еше одну копию этого кадра Такое развитие со-
бытий приводит к дублированию лейтагрпмм, что, в свою очередь, увеличивает трафик
и приводит к перегруженности каналов сети бесполезным информационным п'током.
Избыточный график такого происхождения яв!яе!ся особенно проблематичным для
низкоскоростных канатов передачи данных глобальной сети, поскольку при передаче
данных по каналам такою типа очень высоко ценятся такие ресурсы, как полоса про-
пускания и быстродействие.

Тайм-аут и
жтарг» передача

Хост В

РИСУНОК 8.22

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

В случае, когда возникает противоположная ситуация (базовое значение таймера яв-
ляется слишком высоким), процесс повторной передачи потерянных данных дсйствуе!
так медленно, что это может привести к разрыву соединений Если хост-отправитель не
имеет возможности своевременно обнаруживать и повторно перссычагь потерянные дсй-
rai раммы, приложения могут прекратить попытки обмена данными и закрыть соедине-
ние.

Поддержание соединения активным

Каждый ориентированны!- на установление соединения проюко.т нуждается в нали-
чии какого-либо способа сохранения лотчсско) о соединения между двумя взаимодействую-
щими процессами даже в го время, коиа между этими процессами не происходит ак-
1ИВНОЮ обмена данными. Р этом смысле проюкол TCP не являеюя исключением Для
сохранения готическою соединения в рабочем состоянии TCP оправляет дейтаграмму,
содержащую йообшение о поддержании соединения активным (keepalive) В такои деп-
шграмме пет данных приложений верхнего уровня. Проюкол 1СР использует дейтаг-
раммы такого типа исключительно для поддержания сеанса связи в активном состоя-
нии; отсюда происходит и само название: "сообщения о поддерж шии соединения
активным (keepalives)". Поскольку передающий сообщения акого типа ка tp не содер-
жит никаких значащих данных, в поте длины кадра (Length) установлено значение О,
из чего следует, что передача данною кадря не требует Подтверждения о получении
Перегрузка

Протокол TCP использует сообщении о поддержании соединения активным в каче-
стве обычною средства обеспечения активности сеанса связи. В го же время, примене-
ние сообщений такого типа приводит к увеличению непроизводительных затрат, свя-
занных с наличием в сети избыточного трафика. В зависимости от количества имеющихся
в сети TCP-соединений, сообщения о поддержании этих соединений активными могут
вызвать критическую перегрузку (congestion) каналов передачи данных. Необходимо
помнить о том, что когда соединения с удаленными хостами не используются, их сле-
дует освободить (закрыть) и открывать только в случае необходимости

Одна и та же сеть может обслуживать целую совокупность пользователей. Представьте
себе отображенные на рабочем столе в виде ярлыков (shortcuts) управляющие связи (drive
connections), указывающие на соединение локальною компьютера с тем или иным уда-
ленным хостом. Эти ярлыки и соответствующие им управляющие связи предоставляют
пользователям возможность быстро и iei ко установить связь с удаленными хостами, не
прилагая к этому особых усилий. Однако для успешного функционирования всех этих
быстродействующих ссылок необходимо установление и поддержание протоколом TCP
всех существующих соединении с удаленными хостами, даже если эти соединения не
используются в данный момент. С целью сокращения избыточного трафика и связан-
ных с этим непроизводительных затрат необходимо огключигь бездействующие соеди-
нения, а также убрать с рабочего стола те управляющие связи, которые не используют-
ся в данный момент времени Необходимо также строго ограничивать количество
имеющихся в распоряжении пользователя соединений, активизируемых с помощью
имеющихся на рабочем столе ярлыков. Эго позволит существенно сократить массу бес-
полезною TCP-трафика, а также освободить такой дефицитный ресурс, как полоса про-
пускания, что особенно важно при передаче данных по низкоскоростным каналам гло-
бальной сеги.

Управление потоком

Управление потоком (flow control) — это функция имеющегося в распоряжении TCP
оконною механизма передачи данных (window mechanism). Протокол TCP использует
управление потоком с целью ограничения объема данных, поступающих в буфер полу-
чателя и, следовательно, для предотвращения псрепо тения буфера. Если хост-отпра-
вигель передает данные быстрее, чем хост-получатель может их принять, получатепь
направляет в адрес отправителя запрос на снижение скорости передачи данных и на
сокращение объема данных до тех пор. пока нс освободится его буфер.

В некоторых случаях хост-получатель принимает слишком большой объем данных,
переполняющий буфер. При возникновении такой ситуации получатель отсылает бло-
кирующий пакет (choke packet), предписывающий отправителю полностью прекратить
передачу данных. Если сизуаиия достигает критического уровня, это даже может стать
причиной завершения сеанса связи.

В состав зато <овка TCP, формат которого можно увидеть на рис. 8.2 и 8.3, входит
поле под названием "Окно" (Window). При каждом обмене кадрами, включая установ-
ление сеанса связи (обмен кадрами синхронизации SYN). каждый партнер по комму-
никации сообщает другой стороне текущий размер своею приемною буфера. На рис. 8.23
представлен пример объявления размера окна (w indow size).
РИСУНОК ' 23 Оба хоста сообщают о том, что размер окна каждого из них составляет 4046 байт
(И N=4096).

Рассмотрим пример работы механизма управления потоком Один из взаимодейству
юших хостов объявляет в своем начальном кадре синхронизации (SYN), что он может
принять 4096 бант данных (в заголовке TCP это утверждение выражена строкой
WIN=409b) Из этого следует, что другой хост, функционирующий на равных правах с
указанным хостом, не может пересылать в его адрес больше чем 40чо байт данных. Раз-
мер окна отправки (send window) одного из хостов, принимающих участие в процессе
коммуникации на равных правах, автоматически становится эквивалентным размеру
приемного окна (receive wndow) партнера по коммуникации. Это означает, что отпра-
витель не может переслать большим объем данных, чем получатель может принять. После
начальной синхронизации в каждом передаваем! ьм кадре указывается текущий размер
(в байтах) приемною окна хоста.

Взаимодействующие между собой хосты имеют возможность регулировать размер
окна, указывая в последующих кадрах меньший размер буфера (в случае его перегруз-
ки) или большим размер буфера (в случае уменьшения нагрузки). Например, если хост
предпринимает попытку поддерживать сеансы связи с несколькими клиентами, он мо-
жет быстро исчерпать свои ресурсы. В гаком случае возникает необходимость управле-
ния потоком данных посредством уменьшения размера части окон TCP. через которые
выполняется обмен данными по соединениям с некоторыми клиентами Управление
потоком данных позволяет хосту своевременно выполнять корректную и эффективную
обраоотку данных, которые он получает от всех других взаимодействующих с ним хос-

тов.
В случае отсутствия в составе возможностей протокола TCP какого-либо механизма
контроля над перетру жой приемною буфера некоторые сеансы связи могли бы цели-
ком захватить ресурсы того или иного хоста Такое развитие событий, в свою очередь,
привело бы к закрытию сеансов связи других клиентов по истечении лайм-ау ia. Окон-
ный механизм передачи данных позволяет протоколу TCP регулировать поступление
трафика от сеанса связи TCP (функции оконного механизма в данном контексте очень
похожи на функции полицейского, рейдирующего уличное движение). С помощ! ю »того
механизма протокол TCP с величивает размер окна при наличии достаточного количе-
ства ресурсов для обработки запросов (входящему трафику "дается зеленный свет").
Аналогично размер окна уменьшается когда происходит переполнение буфера; гем са-
мым хост-получатель направляет в адрес хоста-отправителя запрос на уменьшение ско-
рости передачи данных (входящему трафику "дается желтый свет ) Поступление тра-
фика прекращается полностью в случае критической перегрузки буфера; при этом в
блокирующем пакете размер окна объявляется оавным 0 (хосту-отправителю "дается
красный свет", предписывающий ему полностью прекратить передачу данных).

На рис. 8 24 представлены различные этапы передачи данных с помощью окон. На
начальном этапе хост В дает хосту А зеленый свет, сообщая о том, что он может при-
нять 4096 байтов данных через свое приемное окно. Хост А отвечает, отправляя четыре
кадра <ю 1024 байтов каждый. Хост В. буфер которого теперь перегружен, объявляет
размер окна равным 1024 байтов, предписывая тем самым хосту А снизить скорость пе-
рс-дачи ланных (желтый свет). В качестве ответа хост А отправляет сегмент данных, объем
которою равен текущему максимальному размеру окна 1024 байтов. Хост В, буфер ко-
торого оказался переполненным в результате получения отправленных ему данных,
объявляет в своем ответа размер окна равным 0. Установка значения 0 в поле окна
(Window=U) заголовка TCP равносильно для хоста А красному свету, предписывающе-
му этому хосту прекратить передачу данных до тех пор, пока хост В (хост-получатель)
снова не сможет принимать данные.

Unak

flfScnm меганита «пьгшев «он

РИСУНОК 8.24

Хост получатель может
ре ч шровать входящий
поток данных, предписывая
хосту отправителю
I ченыишпь либо увеличить
скоро* ть передачи, чибг
полностью прекратить
передачу кадров

<----------------------------------Сию - <096 бейта

Отправитель использует окно отправки (send window) для указания объема данных
который он может отправить еще до разрешения по тачатеш (с помощью соответствую-
щего АСК) на перекачу следующего сегмента данных. Если размер приемного окна по-
лучателя остается равным 0 на протяжении длительною периода времени, и при этом
не поступает объяатений о положительном размере окна, хост-отправитель в конечном
итоге инициирует закрытие соединения. Следует обратить внимание на то. что если даже
размер приемною окна хоста равен 0. этот хост все же поддерживает передачх данных.
Однако в таком случае он может принимать только критические кадры, а именно кад-
ры, содержащие подтверждения (ЛСК), и кадры с установленными в поле флагов (Flags)
битами RST (флаг переустановки соединения) или URG (флаг срочности)

На рис. 8.25 показан пример состояния передачи данных в случае, если размер окна
равен 0. Когда хост объявляет размер приемного окна равным 0, тем самым он предпи-
сывает хосту-отравителю прекратить передачу данных до тех пор, пока не будет объяв-
лено положительное значение размера приемною окна. Объявление размера окна рав-
ным 0 как правило, означает, что хост либо исчерпал свои ресурсы, либо занят
обслуживанием других хостов, и его буфер может быть переполнен.

РИСУНОК 8.25 (ост-naiy чате гь имеет возможность прекратить передаче донных со стороны
xoima отправите т. направив в его адрес плакирующий пакет.

Равенство размера окна 0 не представляет собой проблемы до тех пор, пока подоб-
ное не происходит слишком часто. Когда хост неизменно объявляет размер окна ран-
ным 0, как правило, это является признаком того, что хосту нужен больший объем па-
мяти. центральный процессор с большей производительностью, либо этот хост
необходимо ралрузить от излишней нагрузки, передав обработку части приложений
другим хостам. Если размер окна равен 0 на протяжении длительною периода времени,
эго может вызвать закрытие соединения.

Порты TCP

Для установления отношений клиент-сервер протокол TCP использует обшеизвест
пые порты (well-known ports) Эти порты используются протоколом TCP на транспорт-
ном уровне с целью идентификации процессов верхних уровней. которые передаю!
потоки данных или должны их принял ь. В габл. 8.1 перечислены номера некоторых об-
щеизвестных портов TCP.

Таблица 8.1 Общеизвестные порты TCP и их померз			
Номер	Название порта	Протокол службы	Описание службы
20	Данные FTP-Data	TCP	Протокол передачи файлов (Данные)
21	FTP	TCP	Протокол передачи данных (Управление)
23	Telnol	TCP	Telnet, служба удаленного доступа
25	SMTP	TCP	Простой протокол пересылки почты
49	LOGIN	TCP	Протокол регистрации хостов
53	DNS	TCP/UDP	Служба именования доменов
63	VIA-FTP	TCP	VIA (Virtual Interlace Architecture-архитектура с виртуальным интерфейсам) — система через FTP
70	Gopher	TCP	Служба передачи файлов Gopher
80	WWW	TCP	Службы всемирное! сети WWW

Резюме

Подробное описание протокола TCP представлено в RFC 793. После разработки про-
токола TCP пот протокол стал стандартным протоколом, используемым в Интернете
для обеспечения гарантироьаннои доставки данных между хостами. Протокол TCP обес-
печивает двунаправленный коммуникационный канал передачи данных между удален-
ными процессами. Такой канал идентифицируется портами TCP. Протокол TCP управ-
ляет взаимодействием между удаленными процессами с помощью механизмов
установления и закрытия соединений мультиплексирования, пересылки данных, управ-
ления потоком, а также посредством обеспечения надежности доставки данных и об-
служивания процесса передачи данных соыасно требованиям приоритета и защиты от
несан киион ирона н ною юст у па

Протокол TCP обеспечивает гарантированную доставку данных в пункт назначения.
Такая доставка данных требует упорядочивания потока данных посредством присвое-
ния порядкового номера каждому передаваемому eei менту данных, а также соответству-
ющего подтверждения партнером но коммуникации получения кажлого сегмента дан-
ных. Такой механизм упорядочивания и погпвсрждения пересылки данных между
удаленными хостами реализуется с помощью процедуры трехходового квитирования

Для регулирования потока данных, поступающего в бтфер хоста-почучателя, прото-
коч TCP использует механизм управления потоком. С помощью оконного механизма
передачи данных, реализуемого через поле окна (Window) заголовка TCP, получатель
может отправить в адрес отправителя запрос на снижение или увеличение скорости
передачи данных, либо на полное преграшение передачи. Характер запрашиваемых
получатечем действий зависит от того, какой объем данных буфер хоста получателя
может принять ь текущий моменг времени. Такой механизм регулирования передачи дан-
ных называется механизмом скользящих окон, или оконным механизмом
Вопросы для повторения

1	Какие шесть базовых функций использует протокол TCP для управления взаимо-
действием между процессами, выполняемыми на удаленных хостах?

2.	Какие действия должен выполнить протокол TCP еще до начала обмена значащими
данными между приложениями верхнею уровня?

3,	Какая характеристика обеспечивает протокол TCP возможностью одновременно ус-
танавливать и поддерживать множество коммуникационных каналов между двумя
удаленными хостами?

4.	Протокол TCP получает от приложений верхних уровней и раз-
бивает их на для передачи на сетевой уровень с целью форми-

рования -

5.	Какой механизм протокола TCP регулирует входящий ноток данных?

6.	Каким образом протокол TCP обеспечивает надежную доставку пакетов в пункт на-
значения?

7.	Назовите шесть основных характеристик ориентированных на соединение протоко-
лов.

8.	Данте описание процесса формирования пар сокетов.

9.	Котда происходит повторная передача данных?

10.	Назовите поля, входящие в состав заголовка TCP
Глава 9

Протокол передачи
пользовательских дейтаграмм
(UDP)

В данной главе рассматриваются следующие темы:

•	Действие протокола UDP

•	Порты UDP

•	Заголовок UDP

Согласно представленной в RFC 768 характеристике протоке i UDP (User Datagram
Protocol, Протокол передачи пользовательских дейта! рамм) предлагает быструю,
ненадежн}! т доставку сообщен ин между приложениями, выполняющимися на удален-
ных хостах. Протокол UDP обслуживает передачу данных на транспортном уровне
(Transport layer) эталонной модели взаимодействия открытых систем OSI 'Open S*stem
Interconnection) и на межхостовом уровне (Ном to-Host layer) коммуникационной мо-
де nt Министерства Обороны США (DoD, US Department of Defense). Протокол UDP
представляет собой альтернативный вариант по сравнению с медленным. но надежным
протокотом TCP. На рис. 9.1 показано, как представлен протокол UDP в эг (лонных ком-
муникационных моделях OS1 и DoD

Модель DoD

Процеоу

П|л1Л'женис

РИСУНОК 9.1

Схема отображения
нратпко i a UD Р на с etnetto и
уровне (моде 1ъ OSI) и но
мсжкоспювыи уровне
(модель DoD)

Межкутг шй

хвень
Ингернеч!

Уровень
доступа к сети
Действие протокола UDP

Так же, как и в случае TCP, протокол UDP получает потоки данных (data streams) от
приложений или процессов верхнего уровня, идентифицируемых по номерам портов.
На транспортном уровне протокол UDP разбивает эти потоки данных на сегменты и
передает их функционирующему на сетевом уровне протоколу IP, который, в свою оче-
редь, пакетирует полученные сегменты в дейтаграммы с целью доставки данных по се-
тевому комплексу в пункт назначения. Значение 17, указанное в поле типа протокола
(Protocol type) заголовка IP, соответствует протоколу UDP. На рис. 9.2 показано, каким
образом идентифицируется UDP в заголовке 1Р.

РИСУНОК 9.2 Значение 17, указанное в поле типа протокола (Protocol type) заголовка IP.
идентифицирует протокол UDP.

В отличие от TCP, в протоколе UDP не предусмотрено установление сеансов связи.
Будучи не ориентированным на соединение протоколом (connectionless protocol). UDP
не упорядочивает передаваемых сегментов данных и не генерирует подтверждений об
их получении. Предполагается также, что не IJDP, а какой-либо другой протокол (как
правило, протокол верхнего уровня) должен отслеживать прибытие отправленной дей-
таграммы в пункт назначения. Кроме того, если данные не достигли адресата, протокол
VDP делегирует протоколу верхнего уровня задачу установления самого факта неудачи
с доставкой и задачу повторной передачи данных в пункт назначения. Поскольку про-
токол UDP не устанавливает соединение, нет необходимости в установке логического
канала связи перед началом передачи данных. Отсутствие логического соединения между
двумя конечными хостами влечет за собой и отсутствие организационных обязанностей
протокола UDP по поддержанию соединения.

Протокол UDP не фрагментирует передаваемые потоки данных, он только иденти-
фицирует порт отправителя (source port) и порт получателя (destination port). В отличие
от протокола TCP, который разбивает информационные потоки приложений верхнего
уровня на сегменты, U DP просто предоставляет двунаправленный коммуникационный
канал (bidirectional communication pipe) между взаимодействующими устройствами. За-
дачу фрагментирования (Fragmentation) и сборки (reassemoly) передаваемых потоков
данных UDP делегирует протоколу 1Р.

Действие протокола UDP основано на очень простом принципе: на принципе по-
пытки наилучшей доставки дейтаграммы в пункт назначения (best effort delivery) В то
время как TCP гарантирует доставку дейтаграмм посредством упорядочивания (sequent tug)
каждого байта отправленных данных и подтверждения приема (acknowledging) каждого
байга полученных данных, протокол UDP предлагает только напряженную попытку
доставки дейтаграмм адресату. При этом задача обнаружения и восстановления поте-
рянных или отсутствующих дейтаграмм делегируется на другие уровни. В то же время
протокол UDP, несмотря на свою неспособность гарантировать доставку пакетов адре-
сату, имеет одно существенное преимущество над протоколом TCP: скорость. Упрощен-
ная сущность протокола UDP позволяет значительно сократить связанные с передачей
данных непроизводительные затрат ы, что делает этот протокол намного более быстрых,
хотя и ненадежным протоколом, представляющим альтернативу протоколу TCP.

Использование UDP приложениями верхнего уровня

Разработчики приложений могут реализовать либо TCP, либо UDP в зависимости от
типа сервиса, запрашиваемого приложением. Например, большая часть прикладных про-
грамм печати выполняется на осноае протокола TCP, поскольку большинство пользо-
вателей заинтересованы в гарантированном результате выполнения заданий на печать,
а не в том, чтобы эти задания были выполнены с какой то степенью вероя гносги. Два
протокола верхних уровней, протокол FTP (File Transfer Protocol, Протокол передачи
файлов) и TFTP (Trivial File Transfer Protocol, Простейший протокол передачи данных)
предоставляют сходные функции, но реализуют различные сервисы транспортного уров-
ня. Оба протокола — как FT Р, так и TFTP — обеспечивают передачу файлов между
хостами. При этом протокол FTP использует службы TCP на транспортном уровне для
того, чтобы гарантировать успешное завершение каждого сеанса пеоесылки файлов, об-
наруживая и восстанавливая потерянные (lost), недостающие (missing) или дублирован-
ные (duplicated; дейтаграммы. Как правило, протокол FTP используется для пересылки
критической к потерям информации (critical information).

Протокол TFTP предоставляет такие же службы пересылки файлов, что и FTP, за
исключением того, что для более быстрой доставки данных и сокращения непроизво-
дительных затрат TFTP использует протокол UDP на транспортном уровне. Существен-
ный недостаток такого способа доставки заключается в том, что доставка данных с по-
мощью UDP менее надежна. Однако протокол TFTP, как следует из самого названия
(Простейший протокол передачи файлов), создан именно для быстрой пересылки не-
больших файлов между хостами. Следовательно, выбор одного из протоколов гранспор-
гного уровня — TCP или UDP — зависит от того, какая из характеристик типа обслу-
живания является более важной для приложения: скорость или надежность. Выбор про-
токола TFTP (и соответственно, протокола UDP на транспортном уровне) для передачи
файлов предполагает, что передающей среде должны быть свойственны следующие ха-
рактеристики:

•	Стабильность сетевой инфраструктуры

•	Вероятность появления только самых простых ошибок в процессе передачи дан-
ных.

Протокол FTP рассматривается более подробно в главе 12, протокол TFTP — в гла-
ве 16.

Порты UDP

Протокол UDP относится к категории протоколов, не ориентированных на созда-
ние соединения. Следовательно, этот протокол не предусматривает упорядочивания
данных и подтверждения их приема. UDP просто идентифицирует порт отправителя
(sending, source port) и порт получателя (receiving, destination port) в соответствующих
полях заголовка UDP и делегирует пакетирование и доставку информации в пункт на-
значения протоколу 1Р. В таблице 9.1 представлен список общепринятых портов UDP
(более полный перечень портов UDP можно найти в Приложении С).

Таблица 9.1 Порты UDP

Номер	Название службы	Протокол	Описание службы
53	DNS	TCP/UDP	Служба именования доменов
67	BootPS	UDP	Сервер загрузочного протокола
68	BootPC	UDP	Клиент загрузочного протокола
69	TFTP	UDP	Простейший протокол передачи файлов
80	SNMP	UDP	Простой протокол управления сетью

Заголовок UDP

В главе 8 были рассмотрены поля заголовка TCP и их функции. Заголовки TCP раз-
ных дейтаграмм имеют переменную длину в зависимости оттого, какое значение уста-
новлено в поле дополнительных параметров (Options), но минимальная длина заголов-
ка TCP всегда составляет 20 байтов. В то же время протокол UDP (не ориентированный
на соединение протокол) в своем заголовке хранит минимальный объем информации.

По сравнению с заголовком TCP заголовок UDP имеет меньшую длину: 8 байтов.
На рис. 9.3 представлен пример заголовка UDP в формате, специфицированном в RFC
768. На рис. 9.4 показан пример конкретной реализации заголовка UDP в том виде, в
котором он отображается в окне анализатора протоколов Sniffer.

^ПРИМЕЧАНИЕ

Аналогично протоколу TCP, протокол UDP должен идентифицировать порты отправителя
и получателя. В отличие от протокола TCP, протокол UDP не упорядочивает передавав-
РИСУНОК 9.3

На данном рисунке
представлен формат
заголовка UDP,
содержащего 8 байтов
данных.

мые дейтаграммы и не выдает подтверждений об их получении. Поле контрольной сум-
мы (Checksum) заголовка UDP используется только для обнаружения кадров, поврежден-
ных в процессе пересылки.

Порт отправители	Порт получателя
Длина дейтаграммы UDP	Контрольная сумма
Данные	

РИСУНОК 9.4 Как можно видеть по отображению заголовка UDP в окне анализатора протоколов
Sniffer, этот заголовок не содержит много информации.

Поле порта отправителя

Первое поле заголовка UDP, поле порта отправителя (Source Port) идентифицирует
порт источника информации. Это поле, имеющее длину 2 байта, аналогично полю пор-
та отправителя заголовка TCP. идентифицирует процесс ичи приложение верхнего уров-
ня, выполняемое хостом-отправителем. Значение (номер порта), устанавливаемое в дан-
ном поле, зависит от того, является ли хост-отправитель клиентом или сервером. Если
хостом-отправителем выполняется клиентский процесс, номер порта должен находить-
ся в диапазоне от 1024 до 65535. В случае выполнения серверного процесса, такого как
общеизвестное приложение, отправляющее запрос или отвечающее на запрос клиента,
номер порта находится в диапазоне от I до 1023.
Поле порта получателя

Второе поле заголовка UDP, поле порта получателя (Destination Port), имеет длину 2
байта. Аналогично полю порта получателя заголовка TCP данное поле идентифицирует
процесс или приложение верхнего уровня, выполняемое хостом-получателем. Значение
(номер порта), устанавливаемое в поле порта получателя (Destination Port), зависит от
того, является хост-получагель клиентом или сервером. Если хостом-получателем вы-
полняется клиентский процесс, номер порта должен находиться в диапазоне от 1024 до
65535. В случае выполнения серверного процесса, такого как общеизвестное приложе-
ние, номер порта находится в диапазоне от 1 до 1023.

Поле длины дейтаграммы

В поле длины (Length), третьем поле заголовка UDP, указывается, какой объем дан-
ных (в байтах) передается в текущей дейтаграмме. В это значение включается как дли-
на заголовка UDP, так и последующие данные (в том числе длина заголовков протоко-
лов верхних уровней и собственно объем передаваемой информации). Минимальное
значение, устанавливаемое в поле длины (Length), составляет 8 байтов, что эквивален-
тно общей длине полей заголовка UDP при отсутствии каких-либо данных протоколов
верхних уровней и при отсутствии информации, подлежащей передаче в пункт назна-
чения.

Поле контрольной суммы

Протокол UDP, будучи не ориентированным на соединение протоколом, не имеет в
своем распоряжении средств обнаружения и восстановления потерянных, недостающих
и дублированных кадров. С другой стороны, в состав возможностей протокола UDP
входит простой способ обнаружения поврежденных кадров. Этот способ реализуется
через поле контрольной суммы (Checksum), имеющее длину 2 байта. Поле контрольной
суммы гарантирует доставку адресату только неповрежденных в процессе пересылки
битов информации. Использование контрольной суммы не позволяет восстанавливать
поврежденные кадры, а позволяет только обнаруживать и отбрасывать их.

UDP-процесс хоста-отправителя выполняет первоначальное вычисление кон трольной
суммы на основе алгоритма CRC (Cyclic Redundancy Check, Алгоритм обнаружения оши-
бок при помощи избыточного циклического хода). Значение, полученное в результате
вычисления, помещается в поле контрольной суммы (Checksum) заголовка UDP. С дру-
гой стороны, UDP-процесс хоста-получателя выполняет такое же вычисление конт-
рольной суммы с целью проверки содержимого заголовка UDP. Если результаты вычис-
лений контрольной суммы на основе алгоритма CRC не совпадают, хост-получатель
делает предположение о возникновении ошибки в процессе передачи данных и отбра-
сывает дейтаграмму.

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

•	Данных, содержащихся в заголовке UDP

•	Данных протоколов верхних уровней

•	Информацию, содержащуюся в псевдозаголовке UDP
В псевдозаголовок LDP (LDP pseudo header) входит 12 байтов данных, предназна-
ченных для использования в процессе вычисления контрольной суммы дейтаграммы
UDP. Следует обратить внимание на то, что в состав полей нсевдозаголовка UDP вхо-
дят некоторые поля заголовка IP. В то же время псевдозаголовок UDP фактически не
включается в заголовок UDP. Протокол UDP использует псевдозаголовок для того, чтобы
гарантировать передачу дейтаграммы в требуемый пункт назначения. На рис. 9.5 пред-
ставлен пример нсевдозаголовка UDP.

IP адрес отправителя		
IP-адрес получателя		
Ноли	Тип протокола: IP	Длина дейтаграммы UOP

РИСУНОК 9.5 Псевдозаголовок UDP предоставляет протоколу UDP возможность убедиться в
правильности доставки или получения дейтаграммы протоколом ! Р нужному адресату, будь то хост
или протокол (приложение) верхнего уровня

Псевдозаголовок UDP содержит следующую информацию:

•	Логический адрес хоста-отправителя

•	Адрес хоста-получателя на сетевом уровне

•	Код типа протокола транспортного уровня

•	Длина дейтаграммы UDP

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

Резюме

Подробное описание протокола UDP представлено в RFC 768. Протокол UDP пред-
лагает быструю, ненадежную доставку сообщений между приложениями, выполняющи-
мися на удаленных хостах. Протокол UDP получает потоки данных (сообщения) от при-
ложений или процессов верхнего уровня. Протокол UDP, функционирующий на
транспортном уровне, разбивает эти потоки данных на сегменты и передает их на сете-
вой уровень протоколу 1Р, который, в свою очередь, пакетирует эти сегменты в дейтаг-
раммы, подлежащие доставке по сетевому комплексу в пункт назначения.

Протокол UDP относится к категории не ориентированных на соединение протоко-
лов. Следовательно, этот протокол не упорядочивает отправленных данных и не выдает
подтверждений о приеме полученных данных. Протокол UDP делегирует другим про-
токолам обязанность отслеживать поступление отправленных данных в пункт назначе-
ния. Поскольку протокол UDP не устанавливает логического соединения между двумя
конечными хостами, это влечет за собой отсутствие организационных обязанностей UDP
по поддержанию соединения. Протокол UDP выполняет передачу данных на основе наи-
лучшей попытки доставки дейтаграммы в пункт назначения. Несмотря на то, что UDP
не гарантирует доставку пакетов адресату, упрощенная сущность этого протокола по-
зволяет значительно сократить связанные с передачей данных непроизводительные зат-
раты, делая UDP альтернативным вариантом по отношению к более медленному про-
токолу TCP. Разработчики приложений могут реализовать либо TCP, либо LDP в
зависимости от типа сервиса, запрашиваемого приложением.

Вопросы для повторения

1.	В каком RFC представлено подробное описание протокола LDP?

2.	Какой тип доставки данных предоставляет протокол UDP выполняющимся на уда-
ленных хостах приложениям?

3.	Какой тип протокола идентифицирует протокол UDP в заголовке IP?

4.	Используются ли протоколом UDP процедуры упорядочивания передаваемых дан-
ных и подтверждения приема полученных данных?

5.	Наличие каких характеристик сети предполагается при использовании протокола
UDP для передачи данных по этой сети?

6.	Каковы организационные обязанности протокола UDP по отношению к поддержа-
нию соединения?

7.	Какие возможности, не свойственные протоколу TCP, предлагает UDP?

8.	Какой механизм использует протокол UDP для проверки кадров на наличие повреж-
дений?

9-	Правильность каких блоков данных позволяет проверить процедура вычисления кон-
трольной суммы?

10.	Какая информация включена в псевдозаголовок UDP?
Глава 10

Протоколы верхнего уровня

В дгнной главе рассматриваются следующие темы:

•	Лри1ладной уровень (Application Layer)

•	Уровень представления (Presentation Layer)

•	Сеансовый уровень (Session Layer)

•	Протоколы верхних уровней (Upper-layer Protocols)

Краткая характеристика протоколов верхних
уровней

Уровень "Процесс/приложение" (Process/Application layer) коммуникационной модели
DoD соответствуем трем верхним уровням модели 0S1: прикладному уровню (Application
Layer), уровню представления (PresentaLon Layer) и сеансовому уровню (Session Layer).
На уровне "Процесс/приложение" взаимодействие с тем или иным хостом предполагает
выполнение следующих функций:

•	Передача файлов (протокол FTP или TF ГР)

•	Организация файловой системы типа клиент/сервер посредством NFS (Network
File System) — сетевой файловой системы корпорации Sun Microsystems

•	Удаленный доступ (Telnet, Служба сетевого взаимодействия с терминалами)

•	Электронная почта (SMTP — Simple Mail Transfer Protocol, Упрощенный прото-
кол электронной почты)

•	сетевое администрирование (SNMP — Simple Network Management Protocol, Уп-
рощенный протокол управления сетью)

•	Разрешение имен (DNS — Domain Name System, Система именования доменов)

Все упомянутые выше протоколы имеют свои собственные характеристики и обслу
живают разные уровни модели 0S1; в то же время все эти протоколы функционируют
на одном и том же уровне модели DoD — уровне "Процесс/приложение". В данной гла-
ве рассматривается каждый уровень модели OSI, дается описание его функций, а также
краткое описание всех протоколов верхних уровней (ULPs, Upper-layer Protocols). На ри-
сунке 10.1 представлена схема отображения различных протоколов на уровне "Процесс/
приложение” модели DoD, а также соотношение этого уровня модели DoD с соответ-
ствующими уровнями модели OSI.
Уровень коммуникационной модели ARPA	Protocol Implementation	Уровень модели ОЯ

Промесс/ приложение	Передача гипертекста	Передача файлов	Электронная  почта		Эмуляция терминалов	Имена доменов		Передача файлов		Клиент/ сервер	Сетевое администрирование	Прикладной уровень
	ИПР.  Протокол передачи гипертекста  RFC 2068	ЯР, Протокол передачи файлов  MIL-STO 1780 RFC 958	SMTP, Упрощенный протокол электронной по«ы MIL-STO 1781  RFC 821		Протокол Telnet  MIL-STO 1782  RFC 854	DNS, Система именования доменов RFC 1034.1035		TFTP, Простейший протокол передачи файлов RFC 783		NFS, Протоколы обслужи вайя сетевой файловой системы корпорации Sun Microsystems; RFCs 1014,1057, 1094	SNMP, Упрощенный протокол управления сетью версия 1: RFC 1157 версия 2: RFC1901-10 версия 3: RCF 2271-75	Уровень представления
												СйНООЯЫЙ уровень
Мвжхостоеый уровень	TCP, Протокол управления передачей данных  MIL-5TD 1778  RFC 733						UDP, Протокол передачи пользовательских дейтаграмм RFC 768					Транспортный уровень
Уровень  Интернета	Разрешение адресов:  ARP - RFC 826  RARP - RFC 903			IP  Протокол Интернета MIL-STD 1777  RFC 731					ICMP, Протокол управляющих сообщений Интернета RFC 792			Транспортный уровень
Сетевой интерфейс	Сетевые интерфейсные платы: Ethernet, Token Ring, ARCNET, MAN, WAN RFC 894, RFC 1042, RFC 1201 и да											Канальный уровень
	Среда передачи  Витая пара, коаксиальный кабель, волоконно-оптический кабель, физическая среда для беспроводной передачи											Физический  уровень

РИСУНОК 10.1 В модели OSf три разных уровня (прикладной уровень, уровень представление и сеансовый уровень) соответствуют одному верхнему
уровню (уровню "Процесс/приложение") модели DoD.

Протоколы верхнего уровня
В отличие от других уровней моделей OSI и DoD, верхние уровни не являются про-
зрачными для конечного пользователя. Пошзователи получают доступ к верхнему уров-
ню непосредственно через операционную систему хоста. Протоколы верхних уровней
служат для конечных пользователей средством выполнения таких задач, как передача
файлов (file transfer), сетевое администрирование (network management), электронная
почта (e-mail) и т.д.

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

Необходимо различать прикладной уровень (application layer) и собственно прило-
жения, такие как Word, Excel, PowerPoint и др. Прикладной уровень можно интерпре-
тировать как открытое окно, позволяющее получить доступ к модели OSI: этот уровень
предоставляет приложениям возможность передавать данные по сети, открывая доступ
к нижним уровням, другими словами — "открывает окно" в модель OSI.

Например, при использовании электронной почты необходимо, прежде всего, выде-
лить пересылаемые данные. На прикладном уровне к этим данным присоединяется за-
головок и управляющая информация, предназначенная для использования на одноимен-
ном уровне другой системы перед тем, как данные будут в конечном итоге переданы на
следующий уровень для отправки по сети. Прикладной уровень обеспечивает доступ к
службе псресылпн файлов и службе печати (file and print services). В качестве примера
предоставляемых прикладным уровнем сервисов можно привести такие программы, как
клиентский редиректор (client redirector) и серверный от ветчик (server responder) Эти
npoi раммы, разработанные корпорацией Microsotl и функционирующие на базе прото-
кола SMB (Server Message Block. Блок серверных сообщений), реализуются в качестве
системных драйверов RDR sys и SRV.sys соответственно.

В случае использования Windows NT клиентский редиректор (программа, эмулиру-
ющая доступ приложении к удаленной файловой системе как к локальной) выполняет
функции протокола прикладного уровня. Когда запрос на пре гоставление сервисов пе-
редачи файлов и печати формируется на удаленном устройстве, функционирующем под
управлением операционной системы Windows NT, редиректор выполняет подготовку ин-
формации для следующего уровня. На смежном уровне происходит подготовка инфор-
мации для передачи ее по сети. При пересылке на удаленный хост данные принимают-
ся прикладным уровнем принимающей системы. Этот уровень на удаленном хосте, в
свою очередь, управляет службой, предоставляемой сервером. Таким образом, часть
программного обеспечения Windows NT, отвечающего за формирование запросов на
сетевые услуги и ответов на них, обеспечивает выдачу запросов и ответов от имени
приложения (рассматриваемого в качестве одного из сервисов прикладного уровня).

Следует помнить о том. что именно прикладной уровень обеспечивает еоогветсгву
ющий интерфейс для взаимодействия со стеком протоколов, используемый в том или
ином процессе обработки данных. В число сервисов, предоставляемых на прикладном
уровне, входят следующие сервисы:

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

•	Службы печати и пересылки файлов

•	Электронная почта
•	Доступ к WWW и передача гипертекста с помощью протокола HTTP

•	Telnet-доступ к удаленному хосту

•	Передача файлов посредством протоколов FTP и TFTP

Всемирная "паутина" (World Wide Web — WWW) и
протокол передачи гипертекста HTTP

О существовании всемирной сети WWW знают практически все, но мало кому изве-
стно, что именно протокол HTTP (Hypertext Transfer Protocol, Протокол передачи ги-
пертекста) предоставляет пользователям доступ к Web. Протокол HTTP является основ-
ным средством общения во всемирной сети WWW; следовательно, этот протокол
позволяет выполнять передачу документов Web между сервером и Web-броузером по-
средством протокола TCP и на основе базовой архитектуры типа клиент/сервер (basic
client/server architecture). Web-страницы (Web pages) состоят из гипермедийных докумен-
тов (hypermedia documents). В названии "гипермедийный документ" префикс "гипер"
(hyper) означает, что в состав документа могут входить ссылки (links) на другие доку-
менты (связи, устанавливающие соотношение с другими документами), — например,
ссылки на Web-странины, содержащие информацию о Пикассо. Вторая часть термина
"гипермедийный документ" — "media" — характеризует доку мент Web как состоящий не
только из собственно текста, но и из объектов других типов, таких как звуковые файлы
и видео-файлы (т.н. мультимедийные образы, multimedia images).

Для получения доступа к какой-либо Web-странице необходимо ввести соответству-
ющий URL (Uniform Resource Locator, Унифицированный указатель ресурсов). URL
идентифицирует конкретную Web-страницу, при этом каждой Web-странице присваи-
вается уникальное имя. Когда вводится запрос на поиск той или иной Web-странииы,
или URL, это действие активизирует поиск клиентским Web-браузером (Web browser)
соответствующего сервера с целью получения доступа к требуемой Web-странице. Про-
токол HTTP обеспечивает взаимодействие между браузером Web и Web-сервером или
промежуточными устройствами, такими как шлюзы (gateways) и брандмауэры (firewalls).
Протокол HTTP рассматривается более подробно в главе 15.

Электронная почта и упрощенный протокол
электронной почты (SMTP)

Электронная почта (e-mail) позволяет пересылать сообщения по Интернету на осно-
ве стандартной базовой архитектуры типа клиент/сервер. Такая модель предоставляет вза-
имодействующим сторонам возможность отправлять, хранить и принимать сообщения.
Протокол SMTP (Simple Mail Transfer Protocol, Упрощенный протокол электронной по-
чты) определяет стандарт обмена электронной почтой между удаленными компьютера-
ми.

Дзя доставки сообщений с помощью электронной почты используется так называе-
мая технология спулинга (подкачки, spooling). При пересылке сообщения адресату сис-
тема сохраняет это сообщение, а также адрес пункта назначения (почтовый, или элек-
тронный адрес — mailbox, e-mail address), имя отправителя, имя получателя и время
отправки сообщения в отдельной области памяти, называемой спулом (spool), предназ-
наченной для временного хранения сообщений. Далее система пересылает сообщение
удаленному компьютеру, причем такая пересылка выполняется в фоновом режиме
(background transfer). Это позволяет отправителю продолжать работу на своем компью-
тере после отправки сообщения, не ожидая получения сообщения получателем.

Удаленный компьютер-клиент использует систему именования доменов (DNS,
Domain Name System) для определения IP-адреса получателя и установления ТСР-со-
единения с почтовым сервером (mail server). При успешном исходе выполненных дей-
ствий копия сообщения пересылается на почтовый сервер, который хранит это сообще-
ние в своей памяти, в специально отведенной области, называемой спудом. Получатель
может принять сообщение, обратившись к этому участку памяти с соответствующими
запросом. Протокол SMTP рассматривается более подробно в главе 13.

Telnet (Служба взаимодействия с удаленными
терминалами)

Достаточно часто возникает экстренная необходимость в том, чтобы проконтроли-
ровать работу удаленного компьютера, находясь территориально далеко от него. Такую
возможность предоставляет протокол Telnet (Протокол сетевого взаимодействия с тер-
миналами). Telnet позволяет пользователю (клиенту) получить доступ со своего терми-
нала к удаленному хосту (серверу). Используя протокол TCP для установления соеди-
нения, Telnet предоставляет пользователю возможность работать на удаленном
компьютере непосредственно через свою клавиатуру. Данные перемещаются по марш-
руту от клавиатуры пользователя в операционную систему компьютера-клиента, а да-
лее по TCP-соединению в удаленную операционную систему (ОС сервера).

Для того чтобы обеспечить каноническое (стандартное) представление данных
(canonical, standard representation of data), служба Telnet использует такое средство, как
сетевой виртуальный терминал (NVT, network virtual terminal). В Telnet предусмотрена
также возможность согласования параметров клиента и сервера (client and server option
negotiation). Кроме того, Telnet обеспечивает симметричность синтаксической структу-
ры согласований (negotiation syntax). Такая симметричность позволяет партнерам по ком-
муникации (как клиенту, так и серверу) запрашивать согласование использования того
или иного параметра обеими сторонами. Служба Telnet рассматривается более подроб-
но в главе 11.

Передача файлов

На прикладном уровне передачу файлов обслуживают два протокола: FTP (File
Transfer Protocol, Протокол передачи файлов) и TFTP (Trivial File Transfer Protocol,
Простейший протокол передачи файлов). Протокол FTP используется чаще, чем прото-
кол TFTP; именно на FTP приходится большая часть обработки трафика (по сравнении
с TFTP), генерируемого в процессе функционировании стека протоколов TCP/IP. Оба
протокола (FTP и TFTP) позволяют осуществлять передачу файлов (т.е. выполнять их
чтение или запись) между компьютером пользователя и удаленным компьютером. Не-
которые компании предпочитают иметь свой собственный файловый сервер (file server)
вместо локальных компьютеров с более дорогостоящими локальными дисковыми запо-
минающими устройствами (local disk storage). Какой бы протокол ни привлекался к
процессу передачи файлов, он обеспечивает возможность пересылки файлов между кли-
ентской и серверной системами, а также координирует этот процесс.

Протокол FTP использует для передачи файлов два TCP-соединения: одно для соб-
ственно данных (data), одно — для управляющей информации (control). Такой способ
пересылки файлов гарантирует успешный исход этой пересылки, поделает процесс пе-
ремещения файлов более медленным. Протокол TFTP использует для передачи файлов
транспортный протокол UDP, что не гарантирует успешной пересылки файлов, но обес-
печивает быструю передачу файлов между компьютерами. Более подробно протоколы
FTP и TFTP рассматриваются в главах 12 и 16 соответственно.

Уровень представления

Уровень представления (Presentation layer) — это шестой уровень модели OSI, сле-
дующий непосредственно за прикладным уровнем (Application layer). На уровне пред-
ставления данные организуются в сообщения, имеющие приемлемый для передачи на
сеансовый уровень (Session layer) формат. Основной функцией рассматриваемого уров-
ня является представление данных в едином для различных платформ формате. Други-
ми словами, на уровне представления выполняется преобразование информации при-
кладною уровня на язык, доступный для восприятия всеми остальными уровнями.
Уровень представления несет ответственность за выполнение следующих задач:

•	Преобразование данных (data conversion) и трансляция данных из одного пред-
ставления в другое (data translation).

•	Сжатие данных (compression) и их восстановление (decompression).

•	Кодирование — шифрование (encryption) и декодирование — дешифрирование
данных (decryption).

•	Представление данных с помощью мультимедийных средств (multimedia) и звука
(sound).

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

Таблица 10.1 Протоколы, наиболее часто используемые на уровне представления		
Тип протокола	Протокол	Описание
Протоколы представления информации и других данных	ASCII	Amarican Standard Code for Information: текстовой Американский стандартный код для обмена информацией
	EBCDIC	Extended Binary-coded Decimal Interchange Coda: Расширенный двоично-десятичный код для обмена информацией
	Encryption/ decryption:	Протоколы шифрованиа/дешифрирование
Протоколы представления графической информации и изображений	TIFF	Tagged Image File Format: формат TIFF теговый формат представления изображений
Мультимедийные протоколы	JPEG	Joint Photography Experts Group: формат JPEG — разработанные объединенной группой экспертов метод для сжатия изображений и соответствующий графический формат
Тип протокола	Протокол	Описание
	PICT	(PICTure) стандартный формат растровой и векторной графики разработанной для Apple Macintosh
	GIF	Grap.ilcs Interchange Format: формат обмена графической nt формацией
Мультимедийные протоколы	MIDI	Musical Instrument Digital Interface: цифровой интерфейс музыкальных инструментов
	MPEG	Motion Pictures Expert; Group: алгоритм MPEG сжатия движущихся изображений и звука, разработанный экспертной группой по вопросам движущегося изображения
	QuickTime	мультимедийная архитектура (система) для хранения, редактирования, анимации и воспроизведения грэфичес.;ой звуковой, видео— и музыкальной информации в реальном времени.

Существует ряд протоколов, которые были разработаны еще до внедрения модели
OSI как эталонной модели передачи данных, однако испотьзованце этих протоколов в
рамках современной коммуникационной модели OSI продолжается до сих пор. Из это-
го следует, что существует всего несколько протоколов, которые можно отнести к соб-
ственно протоколам уровня представления. Из упомянутого выше факта также следует,
что большинство протоколов верхних уровней не вполне соответствуют структуре мо-
дели OSI. В большинстве случаев реализуются протоколы, действие которых охватыва-
ет все три верхних уровня, при этом некоторые уровни пропускаются или, наоборот,
выполняются функции всех трех уровней. Поставщики сетевых услуг должны самосто-
ятельно принимать решение о том, какой из протоколов верхних уровней и на каком
именно уровне следует применять. Таким образом, некоторые протоколы могут выпол-
нять функции протоколов уровня представления, но в то же время выполнять также и
функции протоколов других уровней. Другими словами, определить истинную принад-
лежность того или иного протокола к прспоколам уровня представления достаточно
трудно.

Однако существует один проюкол, действительно относящийся именно к уровню
представления- протокол XDR (external Data Representation, Протокол внешнего пред-
ставления данных). Корпорация Sun Microsystems использует протокол XDR в реализа-
циях своей сетевой файловой системы (NFS, Network File System), основанных на базо-
вой архитектуре типа клиент/сервер. В NFS данный протокол объединен с программным
кодом с целью обеспечения платформенной независимости (platfcm independence). Про-
токол XDR и сетевая файловая система NFS рассматриваю гея более подробно в главе 18.

Сеансовый уровень

Сеансовый уровень (Session layer) соответствует пятому уровню модели OSI и сле-
дует непосредственно за уровнем представления (Presentation layer). На сеансовом уровне
данные по-прежнему имеют вид сообщений, представленных в пригодном для переда-
чи на транспортный уровень (Transport layer) формате. Это последний уровень, на ко-
тором данные пользователя остаются в формате сообщений перед разбиением этих дан-
ных на сегменты на транспортном уровне.

Сеансовый уровень можно рассматривать в качестве координатора действий различ-
ных приложений. Этот уровень координирует диалог между двумя приложениями ( как
на верхних, так и в нижних уровнях). Из этого следует, что сеансовый уровень управ-
ляет процессом установления связи с каждой стороны, осуществляет текущий контроль
над процессом взаимодействия между партнерами по коммуникации, а также в случае
необходимости выполняет завершение сеанса связи.

От выполняемых на сеансовом уровне действий зависит также тип и эффективность
взаимодействия между двумя приложениями. Приложения могут осуществлять процесс
коммуникации в полнодуплексном (full-duplex) или полудуплексном (half-duplex) режи-
ме. Полудуплексный режим коммуникации позволяет только одному устройству осуще-
ствлять передачу данных за один сеанс связи (другими словами, происходит односто-
роннее взаимодействие между приложениями). Полнодуплексный режим позволяет
каждой взаимодействующей стороне передавать данные одновременно.

Сеансовый уровень обслуживают следующие протоколы:

•	NetBIOS (Network Basic Output System, Сетевая базовая система ввода-вывода)

•	SQL (Structured Query Language, Язык структурированных запросов)

•	X Windows (Набор протоколов взаимодействия с приложениями, выполняющи-
мися на различных компьютерах)

•	RPC (Remote Procedure call, Протокол удаленного вызова процедуры)

NetBIOS (Сетевая базовая система ввода —
вывода)

Разработанная компаниями IBM и Sytek, сетевая базовая система ввода-вывода
NetBIOS позволяет приложениям получить доступ к сетевым устройствам. NetBIOS
предоставляет в распоряжение пользователя четыре следующих основных сервиса: сер-
вис разрешения имен (name service), сервис поддержания сеанса связи между логичес-
кими соединениями (session service), сервис передачи дейтаграмм NetBIOS для навига-
ции в сети (datagram service), а также смешанные услуги (miscellaneous function). В данной
книге рассматривается только сервис разрешения имен (другими словами, обеспечение
доступа к удаленным ресурсам по их имени) с помощью NetBIOS.

Сетевая базовая система ввода вывода NetBIOS предоставляет пользователям про-
стой способ получения доступа к удаленным ресурсам и сервисам, используя при этом
имя, а не адрес. NetBIOS выполняет разрешение имен посредством рассылки по сети
широковещательных запросов на определение адреса требуемого ресурса или сервиса по
его имени. Усовершенствования, внесенные в NetBIOS, позволяют этой системе функ-
ционировать также на третьем уровне, заменяя при этом стек протоколов TCP/IP. Бо-
лее подробно NetBIOS рассматривается в главе 14.
NFS (Сетевая файловая система) и протоколы
ONC

Разработанный компанией Sun Microsystems, набор протоколов NFS (Network File
System, Сетевая файловая система) предоставляет группе взаимодействующих компью-
теров возможность совместно использовать online-файлы так. как будто это локальные
файлы. Сама процедура совместного использования файлов выглядит почт прозрачной
для пользователя. Кроме того, некоторые компании используют NFS для установления
взаимодействия между своими файловыми системами.

Для успешного функционирования действующего на прикладном уровне протокола
NFS требуется участие двух других протоколов: XDR (external Data Representation, Про-
токол внешнего представления данных) и RPC (Remote Procedure Call, Протокол уда-
ленного вызова процедуры). Как следует из самого названия, протокол XDR обслужи-
вает уровень представления. Протокол RPC относится к протоколам сеансовою уровня.
Упомянутые выше протоколы (XDR, NFS и RPC) образуют группу протоколов, обеспе-
чивающих открытые сетевые обработки (ONC, Open Network Computing). Объединен-
ные в одно семейство, эти протоколы позволяют разнотипным системам с отличающи-
мися характеристиками, начиная or простых PC и заканчивая мэйнфреймами, получать
доступ к файлам в прозрачном режиме.

Протокол XDR фактически представляет собой язык представления данных и обес-
печивает согласованное между различными реализациями NFS представление данных.
Протокол RPC, независимый от транспортного уровня и функционирующий на основе
передачи обмена сообщениями протокол, делает возможным взаимодействие между
клиентом и сервером в прозрачном режиме. Все протоколы семейства ONC рассматри-
ваются более подробно в главе IX.

Резюме

Уровень “Процесс/приложение" модели DoD эквивалентен трем верхним уровням
модели OSI; относящиеся к этому уровню прогокоты называются протоколами верхне-
го уровня (модель DoD). Уровень "Процесс/приложение’' отвечает за выполнение ряда
запрашиваемых пользователем функций: передача файлов, обмен файлами в системе
клиент/сервер, удаленный доступ, электронная почта, сетевое администрирование и
разрешение имен.

Три уровня модели OSI. соогвеютвуюшие уровню "Процесс/приложение" модели
DoD, — это прикладной уровень, уровень представления и сеансовый уровень. Приклад-
ной уровень предоставляет приложениям осуществлять обмен данными. Самой важной
функцией уровня представления является представление данных в формате, едином для
различных платформ. Сеансовый уровень координирует процесс установления соеди-
нений между двумя удаленными устройствами.
Вопросы для повторения

1.	Какие три уровня модели OSI соответствуют уровню "Процесс/приложение” моде-
ли DoD?

2.	Назовите основные функции уровня "Процесс/приложение"?

3.	Какие протоколы относятся к прикладному уровню?

4.	Назовите основную функцию уровня представления.

5.	Назовите основную функцию сеансового уровня.

6.	Какие протоколы относятся к протоколам ONC и какие уровни они обслуживают?
Глава 11

Telnet

В данной главе рассматриваются следующие темы:

•	Взаимодействие между клиентом и сервером Telnet (Telnet Client-server
Relationship)

•	Базовые сервисы Telnet (Telnet's Basic Services)

•	Сетевой виртуальный терминал (NVT, Network Virtual Terminal)

•	Параметры Telnet (Telnet Options)

Удаленный доступ

Протокол Telnet (Telecommunications Network, Протокол сетевого взаимодействия с
терминалами) предоставляет возможность пользователю, выполняющему сеанс связи с
терминала клиента, получить доступ к удаленному хосту сети (или серверу Telnet) че-
рез стек протоколов TCP/IP. Протокол Telnet работает в тесном взаимодействии с ори-
ентированным на соединение протоколом TCP через общеизвестный порт 23 и позво-
ляет исходному хосту и удаленному терминалу осуществлять обмен данными,
представляющими собой 8-разрядные символы. Протокол Telnet разработан таким об-
разом, чтобы он мог обслуживать хост или терминал любого типа. После установления
TCP-соединения с удаленным хостом пользователю предоставляется возможность вво-
дить команды-со своей клавиатуры так, как будто он работает на клавиатуре удаленно-
го компьютера. Telnet позволяет также считывать выходные данные удаленного хоста.
Взаимодействие между клиентом и сервером Telnet выполняется в прозрачном режиме,
что создает видимость работы с клавиатурой и дисплеем удаленного хоста. На рис. I l.l
показан конкретный пример функционирования протокола Telnet. Последовательность
событий, происходящих во время установления сеанса связи между клиентом и серве-
ром Telnet, выглядит таким образом:

I.	После запуска сеанса Telnet (Telnet session) функционирующее на хост компьютере
приложение становится клиентом Telnet.

2.	Клиент Telnet устанавливает TCP-соединение с сервером Telnet (удаленным хостом)
с помощью стандартной процедуры трехходового квитирования (three-way handshake).
Описание процедуры трехходового квитирования можно найти в главе 8
3.	Клиент получает возможность работать с клавиатурой и дисплеем через ТСР-соеди-
нение таким образом, как будто они подключены непосредственно к удаленному хо-
сту.

4.	Сервер Telnet использует в своей работе псевдотерминал (pseudo terminal device).
Псевдотерминал представляет собой механизм сопряжения двух операционных си-
стем, что позволяет Telnet передавать данные в другую операционную систему та-
ким образом, как будто эти данные поступают с одной и той же клавиатуры.

Протокол Telnet был разработан в 70-х годах, когда конечные устройства были чрез-
вычайно дорогими и неинтеллектуальными, а обработка данных, как правило, возлага-
лась на удаленные хосты. Терминалы ввода/вывода (неинтеллектуальные терминалы,
dumb terminals) осуществляли передачу данных удаленному серверу Telnet в посимволь-
ном режиме; сервер должен был возвращать принятые символы клиенту для отображе-
ния введенных им команд на его же экране. Тем не менее, такая процедура была необ-
ходима клиентам, поскольку терминалы не имели места для хранения обрабатываемой
информации. В настоящее время клиентские приложения выполняются на интеллекту-
альных устройствах, которые обеспечены своими собственными ресурсами и в случае
необходимости выполняют локальную обработку данных. Однако даже такие устройства
должны иметь возможность эмулировать исходную модель. Современные компьютеры,
на которых выполняются клиентские приложения, поддерживают такие режимы пере-
сылки данных (например, построчный режим), которые делают реализации Telnet бо-
лее производительными. В то же время, не все реализации Telnet поддерживают пост-
рочную передачу данных.

РИСУНОК 11.1

Данные
перемещаются от
клавиатуры к
удаленной
операционной
системе.

$ РЕЖИМЫ ПЕРЕСЫЛКИ ДАННЫХ

Существуют различные режимы пересылки данных (transmission modes), в число которых
входит режим посимвольной (character mode) и режим построчной (line mode) передачи
данных. При применении посимвольного режима данные пересылаются по одному сим-
волу (или 1 байт информации) за один раз. Это наименее эффективный способ пересыл-
ки данных. Построчный режим позволяет передавать всю строку одной порцией данных
(data chunk), и представляет собой более производительный способ передачи данных.

Telnet, несмотря на его простоту по сравнению с другими протоколами, широко ис-
пользуется сетевыми администраторами в качестве средства дистанционного админист-
рирования и поиска неиспр шностей (administration and troubleshooting tool). В большин-
стве случаев программное обеспечение Telnet клиента предоставляет пользователю воз-
можность подключиться к удаленному компьютеру посредством IP-адреса или имени
удаленного хоста. Когда Telnet клиент предпринимает попытку установления сеанса свя-
зи, используя при этом IP-имя хоста (IP host name), он сначала должен выполнить пре-
образование имени хоста в его логический адрес на сетевом уровне (logical Network layer
address), а затем — в локальный аппаратный адрес (local hardware address).

В случае если хост предпринимает попы)ку установить соединение, используя при
этом сетевой адрес, ему необходимо выполнить сначала преобразование логического
адреса хоста в его аппара!ный адрес. Как только хосту становится известным требуе-
мый локальный аппаратный адрес, он может направить дейтаграмму по этому адресу.
Далее в работу включается протокол TCP, который устанавливает соединение между
двумя хостами, что и приводи! Telnet в действие. Разрешение имен рассматривался более
подробно в главе 14.

Протокол Telnet функционирует на трех верхних уровнях (прикладном уровне, уровне
представления и сеансовом уровне) модели OSI, что эквивалентно уровню "Процесс/
приложение" модели DoD (см. рис. 10.1 в главе 10). Тагос расположение Telnet в моде-
ли OS1 имеет как определенные преимущества так и некоторые недостатки. Очевид-
ным преимуществом Telnet является то, что этот протокол предоставляет администра-
торам возможность вносить модификации в работу того иди иного устройства сети без
непосредственного подключения к этому устройству

С другой стороны, работа Telnet представляется достаточно неэффективной, если
учесть, что каждое нажатие клавиши влечет за собой перемещение данных по следую-
щему маршруту:

1.	Через операционную систему клиента.

2.	От клиента через сетевой комп ickc (Интранет) или Интернет к серверу.

3.	Через операционную систему сервера.

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

В то же время, данные должны возвратиться к клиенту по тому же маршруту. Это
требует больших непроизводительных затрат, что приводит, в свою очередь к неэффек-
тивному использованию ресурсов. Кроме того, данная процедура выполняется через
TCP-соединение. Это влечет за собой присвоение порядковых номеров (sequence
numbers) каждому сегменту передаваемых данных и выдачу подтверждений
(acknowledgements) об их получении, следствием чего являются дополнительные непро-
изводительные затраты. Используя Telnet, приходится расплачиваться потерей произ-
водительности за гарантию надежности.

Базовые службы Telnet

Описание трех базовых служб, предоставляемых Telnet, представлено в RFC 854; раз-
личные параметры работы Telnet специфицируются в RFC 855. Рассмотрение парамет-
ров Telnet следует ниже в данной главе. Telnet предоставляет следующие основные служ-
бы:
J. Сетевой виртуальный терминал (NVT, Network Virtual Terminal), представляющий
собой стандартный интерфейс взаимодействия двух удаленных систем.

2.	Согласование клиентами и серверами различных параметров (negotiating various
options)

3.	Симметричное отображение терминалов и процессов (symmetric view of terminals and
processes).

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

Сетевой виртуальный терминал

Telnet функционирует на базе протоколов TCP/IP и осуществляет свою работу на ос-
нове набора сетевых стандартов (который называют также канонической или стандарт-
ной формой представления данных). Этот набор сетевых стандартов известен как сете-
вой виртуальный терминал (NVT, Network Virtual Terminal). Протокол NVT обеспечивает
прозрачность работы Telnet и поддерживает минимальное количество параметров, под-
лежащих согласованию между клиентом и сервером Telnet. Реализация NVT в качестве
фронтального процессора (front end) позволяет скрьггь различия между взаимодействующи-
ми устройствами, предоставляя обеим сторонам общий набор команд и характеристик, ко-
торые делают партнеров но коммуникации до определенной степени тождественными.

В обязанности пользовательской или клиентской части Telnet входит отображение
входящих NVT-кодов в реальные коды, необходимые для вывода информации на дисп-
лей пользователя. Эта функция NVT позволяет сделать процесс коммуникации между
разнотипными системами целостным и лишенным промежуточных операций. Клиентс-
кая часть Telnet отвечает также за преобразование набора символов исходной клавиату-
ры в набор символов NVT. RFC 854 определяет NVT как виртуальное устройство, сти-
мулирующее операционную систему клиента преобразовывать систему кодирования
терминала пользователя (независимо от типа терминала) в систему кодирования NVT.
Telnet позволяет эмулировать работу таких терминалов, как IBM 3270, VT100, VT200 и
т.д. После преобразования данных в каноническую (стандартную) форму обе стороны
(и клиент, и сервер) могут взаимодействовать между собой независимо от того, какой
терминал используется на каждом конце процесса коммуникации (например, одна их
взаимодействующих сторон может использовать терминал DEC VT-100).

Обмен информацией через NVT посредством кода
ASCII

Для представления каждого символа, выводимого на экран дисплея в процессе пе-
редачи информации по Интернету, в системе кодирования NVT, формат которой опре-
делен в RFC 854, используется набор 7-разрядных символов ASCII (American Standard
Code lor Information Interchange, Американский стандартный код для обмена информа-
цией). Система кодирования NVT обеспечивает пересылку последовательности 7-раз-
рядных символов ASCII, дополненных до 8 бит начальным битом со значением 0. Со-
гласно указанному выше RFC дисплей отождествляется с печатающим устройством. Из
этого следует, что на экран дисплея выводятся только стандартные печатные символы,
представленные 7-разрядными символами ASCII. Предполагается также, что дисплей
пользователя должен иметь возможность распознавать и обрабатывать некоторые управ-
ляющие коды.

ASCII

Код ASCII используется многими приложениями. Компьютеры отправляют сообщения, пред-
назначенные для прочтения пользователем, в коде ASCII. Диапазон таких сообщений ва-
рьирует от сообщений об ошибках до сообщений о состоянии системы. В коде ASCII могут
быть представлены как текстовые данные (буквы, числа, знаки пунктуации), так и управ-
ляющие символы, которые на самом деле представляют собой команды, такие как воз-
врат каретки (Carriage Return, CR) и перевод строки (Line Feed, LF).

Представление символов в кодах ASCII предоставляет Telnet возможность работать
с максимально возможным количеством отличающихся по своим характеристикам сис-
тем, поскольку это позволяет Telnet приспосабливаться к специфическим элементам раз-
нотипных компьют еров и операционных систем. В некоторых системах используются
различные способы управления передачей текстовых строк (например, строка может за-
вершаться комбинацией символов ASCII для возврата каретки — Carriage Return, CR или
перевода с фоки — Line Feed, LF). Чтобы избежать трудностей, связанных с этими раз-
личиями, Telnet задает доступный ему способ пересылки данных и последовательнос-
тей команд по Интернету На рис. 11.2 проиллюстрирован процесс преобразования ко-
дов символов из формата локального хоста в формат NVT.

РИСУНОК 11.2

В процессе
функционирования
NVT выполняется
преобразование кодов
символов в формате
терминала хоста
но in зпвателя в формат
NVTи необорок,

Клавиатура
и дисплей

поль лов;, галл

"пользуется формат
клиентской системы

Используется
формат NVT

Сетевое ТСР-соединенив
через Интернет

Используется формат
серверной системы

С помощью клавиатуры NVT можно сгенериро iaib все 128 кодов, используя при этом
клавиши, комбинации клавиш, или последовательности символов, в состав которых могут
быть включение

•	95 печатных символов (буквы, цифры, знаки пунктуации); эти символы имеют те
же значения, что и в системе кодирования ASCII

•	33 управляющих кода

В таблице 11.1 представлены стандартные управляющие коды, распознавать которые
должна каждая реализация NVT.

Таблица 11.1 Обязательные управляющие коды I-JVT

Название	Код	Десятичное значение	Функция
NULL	NUL	0	Нет действий
Line Feed	LF	10	Передвижение печатающей головки на

следующую строку с сохранением при этом
прежнего горизсстального положения
Название	Код	Десятичное значение	Функция
Carnage Return CR	13	Передвижение печатающей головки к левому полю текущей строки

В таблице 11.2 представлены нсобя йгедьные управляющие коды NVT (optional control
codes), которые также должны отображаться на дисплее независимо от того, распозна-
ются они той или иной реализацией NVT или nei

Таблица 11.2 Необязательные управляющие коды NVT

Название	Код	Десятичное значение	Функции
BFLL	BEL	7	Подача звукового или визуально, о сигнала (печатающая головка не передвигается)
Back Space	BS	8	Передвижение печатающей головки на один символ в сторону левого поля
Horizontal iab	HT	9	Передвижение печатающей головки на следующую позицию вдоль строки (горизонтальная табуляция). Определение каждой стороной расстояния табуляции данным кодом не специфицируется
Vertical	VT	11	Передвижение печатающей головки на следующую позицию по вертикали (вертикальная табуляция). Определение каждой стороной расстояния табуляции данным кодом не специфицируется
Form Feed	FF	12	Передвижение печатающей головки на начало

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

Команды Telnet

В состав инструментальных средств протокола NVT службы Telnet входят различные
команды, управляющие взаимодействием между клиентом и сервером Telnet (Telnet
commands). Эти команды включаются в поток передаваемых между i лиентом и серве-
ром данных. Команды Telnet состоят из обязательной последовательности символов
(mandatory two-octet sequence) длиной два октета и необязательной (optional) третьей пос-
ледовательности. Telnet использует первый окзет для того, чтобы отмстить передавае-
мую информацию как команду. Этот октет известен как октет IAC (Interpret as command,
"интерпретировать как команду"). Второй октет идентифицирует код одной из команд,
перечисленных в таблице 11.3. В третьем октете представлена дальнейшая идентифика-
ция значения команды, если указанного ранее кода команды недостаточно. Различные
необязательные параметры Telnet представлены в таблице 11.4.

Таблица 11.3 Команды Telnet, которым предшествует байт IAC (2S5)

Команда	Десятичный код	Значение
EOF	236	End of File (конец файла)

11 Зак. 768
Команда	Десятичный код	Значение
SUSP	237	Suspend current process (приостановить текущий процесс): управление заданиями
ABORT	238	Abort process (аварийное завершение процесса)
EOR	239	End of record (конец записи)
SE	240	Subnegotiation end (конец дополнительного согласования)
NOP	241	No operation (нет операций)
DM	242	Data mark (метка данных): часть сегмента синхронизации ТОР, который всегда маркируется как "срочные данные" (Urgent data)
BRK	243	Break (прерывание): генерирует сигнал прерывания
IP	244	Interrupt Process (прерывание процесса): приостановка, прерывание или аварийное завершение процесса
AO	245	Abort output (прекратить вывод): позволяет завершить текущий процесс без отправки выходных данных пользователю
AYT	246	Are you there (вы здесь?): проверка работоспособности сервера
EC	247	Erase character (стереть символ): удаление последнего символа в отправленном ранее потоке данных
EL	248	Erase line (стереть строку): удаление текущей строки
GA	249	Go ahead (продолжить): сообщение партнеру о том, что он может продолжать передачу данных
SB	250	Subnegotiation (дополнительное согласование): следует дополнительное согласование указанного параметра
WILL	251	Will (будет использован): согласование параметров. Означает желание партнера по коммуникации использовать параметр или подтверждение его использования
WONT	252	Will not (не будет использован): согласование параметров. Означает отказ партнера по коммуникации от использования указанного параметра
DO	253	Do (выполнить): согласование параметров. Указывает на запрос партнера по коммуникации к другой стороне об использовании указанного параметра
DONT	254	Do not (не выполнять): согласование параметров Указывает на запрос партнера по коммуникации к другой стороне о прекращении использования параметра
IAC	255	Interpret as command (Интерпретировать как команду): интерпретировать следующий октет как команду

Согласование параметров

Первый обмен данными между клиентом и сервером Telnet происходит только пос-
ле сигнала согласования параметров (option negotiation signal), даже если партнеры по
коммуникации предполагают работу между собой в режиме NVT. Клиенты и серверы
Telnet используют процедуру согласования параметров (option negotiation) с целью дос-
тижения договоренности по поводу характеристик и функциональных возможностей,
подлежащих реализации в процессе коммуникации. Действия Telnet по отношению к обе-
им взаимодействующим сторонам симметричны: каждой из сторон предоставляется возмож-
ность выдать запрос на использование той или иной необязательной характеристики.
В случае если партнер но коммуникации не поддерживает какую-либо характерис-
тику, либо когда ему запрещено эту характеристику применять, он отвергает этот зап-
рос. Партнеры not свариваются между собой об использовании поддерживаемых ими ха-
рактеристик и поддерживают все дру| ие параметры в объеме стандартного минимального
набора опций NVT. Сразу же после завершения процедуры согласования параметров
клиент и сервер Telnet могут начинать обмен данными по Telnet-соединению. Каждая
из сторон может отправить один из следующих запросов:

•	WILL (будет использован): отправитель желает активизировать параметр.

•	DO (выполнить): отправитель желает, чтобы получатель активизировал параметр.

•	WONT (не будет использован): отправитель желает заблокировать параметр.

•	DONT (не выполнять): Отправитель желает, чтобы получатель заблокировал па-
раметр.

На рис. 11.3 показан процесс установления сеанса Telnet с помощью процедуры трех-
ходового квитирования протокола TCP Рис. 11.3 иллюстрирует также процесс согласо-
вания параметров между клиентом и сервером Telnet, а также процесс регистрации кли-
ента. Как видно но первому кадру, ТСР-порт 23 является портом получателя (D=23).

РИСУНОК 11,3 Непосредственно после установления ТСР-соединеиия (кадры 1.2 и 3) начинается
процесс согласования параметров между клиентом и сервером Telnet посредством обмена запросами
WILL, DO, WONT к DONT
Параметры Telnet

Клиент и сервер Telnet мшут согласовать с помощью соответствующих команд всю
совокунносгьпарамечроз Telnet на любом этапе сеанса связи Такая симметричность про-
цесса взаимодействия между клиентом и сервером позволяет каждому из них пересгро-
игь структуру соединения В соответствующих RFC каждая команда описывается отдель-
но. Всего существует более 40 параметров Telnet; в таблице И.4 перечислены те
параметры, которые используются наиболее часто.

Таблица 11.4 Параметры Telnet

Десятичный	Название	RFC	Значение  коа
0	Binary transmission	В56	Преобра ювание пересылаемых  (пересылка двоичных	данных в 8-разрядный двоичный формат  данных)
1	Echo	857	Разрешение партнеру отправить эхо  (эхо сообщение)	сообщение о полученных им данных
3	Supress go ahead	858	Запрещение передачи сигнала  (подавление сообщения	продолжения (Go ahead) после данных  Go ahead)
5	Status (состояние)	859	Заире на предоставление удаленным узлом  данных о состоянии параметра Telnet
6	Timing mark	860	Запрос г а ввод м°тки синхронизации  (метка синхронизации)	в обратный поток с целью синхронизации  действий партнеров по коммуникации
24	Terminal type	1091	Обмен информацией о производителе  (тип терминала)	и модели используемого терминала.  Позволяет программам видоизменять выходные данные так же, как и с помощью позиционирования курсора на терминале пользователя
25	End of record	885	Завершение пересылки данных,  (конец записи)	содержащих код EOR
31	Window size	1073	Передача серверу Telnet размера окна  (размер окна)
32	Terminal speed (быстро-	1079	Обмен информацией о  действие терминала)	быстродействии терминала
33	Remote flow control	1372	Разрешение, отмена и регулировка  (удаленное управление	потока  потоком)
34	Linemode	1116	Пересылка, отредактированных в  (построчный режим)	локальном режиме, строк
33	Environment	1408	Передача конфигурационных Variables  (переменные среды)	а едений

Клиент и сервер Telnet достигают соглашения об использовании тех или иных пара-
метров в процессе их согласования. Результатом такого сот ласовапия является общее
представление различных факультативных возможностей, оказывающих воздействие на
функционирование приложений и обмен данными между ними. Подобно другим опе-
рациям Telnet, каждый партнер по коммуникации может либо разрешить, либо отме-
нить тот пли иной параметр в локальном или удаленном режиме. Инициатор сеанса связи
отправляет 3-байтовую команду, имеющую следующий формат:

/АС, (тип операции), (команда)

Получатель этого сообщения отвечает аналогичным способом. Кроме гою, Telnet пре
доставляет каждой стороне возможность либо принять, либо отклонить запрос на акти-
визацию того или иного параметра; однако запрос на отмену параметра каждый парт-
нер по коммуникации должен принять обязательно. В таблице 11.5 представлены
возможные сценарии обмена командами согласования параметров WILL, DO, WONT и
DONT.

Таблица 11,5 Варианты возможных ответов на запросы Telnet

Запрос отправителя	Ответ получателя	Значение
WILL	DO	Отправитель желает активизировать параметр в случае если получатель имеет возможность оперировать им; получатель отвечает, что он имеет такую возможность. Параметр вводится в действие.
WILL	DONT	Отправитель желает активизировать параметр в случае если получатель имеет возможность оперировать им, получатель отвечает, что он не имеет такой возможности. Параметр не вводится в действие.
DO	WILL	Отправитель желает, чтобы получатель активизировал параметр; получатель отвечает, что он имеет такую возможность. Параметр вводится в действие.
DO	WONT	Отправитель желает, чтобы получатель активизировал параметр; получатель отвечает, что он не имеет такой возможности. Параметр не вводится в действие.
WONT	DONT	Отправитель желает отменить параметр. Получатель может ответить только сообщением DONT. что подтверждает запрос отправителя
DONT	WONT	Отправитель желает, чтобы получатель отменил параметр. Получатель может ответить только сообщением WONT, что подтверждает его прекращение дальнейшего использования параметра.

Рассмотрим конкретный пример. Если отправитель желает передать в адрес получа-
теля запрос на эхо сообщение, он отправляет последовательность следующих команд:

255 (/АС). 251 (WILL). / (ECHO)

Последним байт трехбайговои последовательности команд идентифицирует собствен-
но требуемое от получателя действие. Если получатель поддерживает выдачу эхо сооб-
щений, он ответит так:

255 (/АС), 253 (DO), 1 (ECHO)

Обмен сообщениями между клиентом и сервером Telnet фактически сводится к сле-
дующему диалогу между партнерами. Отправитель спрашивает: ”Вы позволите мне ис-
пользовать опцию х?" (WILL). Получатель отвечает либо "Я разрешаю использовать
опцию х" (DO), либо "Я не разрешаю использовать опцию х” (DONT). В каждом из ука-
занных случаев процесс согласования опций симметричен: сторона-получатель запроса
дает либо положительный, либо отрицательный ответ на запрос отправителя
Рис. 11.4, 11.5 и 11.6 иллюстрируют процедуру согласования иарачетрос между кли-
ентом и сервером Teinei.

РИСУНОК 11.4 Сервер (ТСР-порт 23) выдаст в адрес клиента (ТСР-порт 2921) запрос на
идентификацию типа терминали (1АС Du Terminal-Type).

РИСУНОК 11.5 В качестве типи терминала клиент укапывает терминал фирмы Sun
РИСУНОК 11.6 Сервер согласует с клиентом использование лхопечати (нажатие клавиши). а также
указывает операционную систему, используемую на терминале, тип которого бы i согзасован ранее —
операционная система SunOS (ОС, базирующаяся на Unix).

Согласование дополнительных параметров

Некоторые значения подлежащих согласованию параметров требуют дополнитель-
ного согласования (suboption negotiation) после тою, как обе стороны дости1ЛИ согла-
шения по поводу поддержки того или иного параметра (будь то О1мена или разрешение
параметра). Обычно для этого клиент отправляет серверу исходную грехбайтовю после-
довательность команд. Далее клиент и сервер сообщают дру| другу' требуемые значения
посредством обмена командами запроса значения (value query commands) и ответами на
ли запросы. Обшая Поспелова 1ельность команд процедуры согласования дополни 1епь-
ных параметров выгляди г следующим образом:

(АС (255), SB (250), (option code number), I, IAC. SE

IAC (255), SB (250), (option code), 0, (value). IAC. SE

Информация, предоставляемая в процессе дополнительного согласования, включает
в себя специальное значение, необходимое для реализации согласованной ранее харак-
теристики

Резюме

Telnet устанавливает TCP-соединение с удаленным хостом; посте этого пользователь
получает возможность вводить команды со своей клавиатуры так, как будто ла клави-
атура подсоединена к удаленному компьютеру. С помощью Telnet можно также считы-
вать выходные данные удаленного хоста Взаимодействие между клиентом и сервером
Telnei происходит в прозрачном режиме, что создает видимость работы с клавиатурой и
дисплеем, подключенными непосредственно к удаленному хосту

Telnet предлагает три базовых службы: сетевой виртуальный терминал (NVT), согла-
сование различных параметров между клиентом и сервером, а также симметричное ото-
бражение терминалов и процессов с обеих сторон NVT обеспечивает прозрачноеть ра-
боты протокола Telnet и поддержку минимального ко тичества параметров, используемых
каждым партнером по коммуникации и подлежащих сот .тасованию между клиентом и
сервером

NVT имеет в составе своих средств набор ком тнд, предназначенных для управления
взаимодействием между клиентом и сервером Telnet передает зти команды в потоке дан
пых. При этом первый октет, нтвсстныи под названием 1АС (Interpret as command. Ин-
терпретировать как команду), нетто ьзуегся для того, чтобы отметить передаваемую ин-
формацию как команду.

Клиент ы и серверы Telnet используют процедуру согласования параметров для того,
чтобы достичь договоренности по поводу характеристик и параметрон, подлежащих ре-
ализации в процессе коммуникации Действия Telnei по отношению к обеим взаимо-
действующим сторонам симметричны каждой из сторон предоставляется возможность
выдать запрос на использование той или иной необязательной характеристики Каждый
партнер по коммуникации может использовать следующие запросы: WILL.. DO, WONT
и DONT.

Вопросы для повторения

I.	Какие возможности предоставляет пользователю служба Гс1пеГ?

2,	Последовательное гь к ткнх событии требуется для у гтановления сеанса I elnel?

3.	Для чего используются команды Telnet?

4.	Назовите 12 самых важных и наиба tee широко используемых параметров Telnet, об-
щее число которых составляет более 40.

5.	Назовите три базовых службы, предоставляемые Telnet

6.	Что такое NVT и каковы его функции в работе Telnet?

7.	Для чего используется 7-разрядныи код ASCII?

8.	Что подразумевает симметричное соединение?

9.	Что означает символ IAC?

10.	Назовите четыре запроса, оправляемых партнерами по коммуникации во время со-
гласования параметров

11.	Назовите шесть возможных ответов, коюрые moi уз бы>ь отравлены партерами по
коммуникаций во время со1Ласовапия параметров.
Глава 12

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

В данной главе рассматриваются следующие темы:

•	Сеанс FTP (FTP Session)

•	Представление данных в FTP (Data Representation)

•	Струи гуры данных в FTP (Data Structures)

•	Режимы передачи в FTP (Transmission Modes)

•	Команды FTP (Commands)

•	Ответы FTP (Replies)

Краткая характеристика протокола FTP

Протокол FTP (File Transfer Protocol, Протокол передачи файлов), описание кото
рого представчено в RFC 959, обслуживает уровень "Процесс/приложение" (Process/
Application) модели DoD и является одним из наиболее распространенных приложений,
использующих протоколы стека TCP/IP. Протокол FTP отвечает та Пересылку больший
стна фан юн по Интернету; этот протокол позволяет как удаленным, так и локальным
клиентам или серверам осуществлять эффективную передач) файлов или данных, ис-
пользуя при этом надежный транспортный протокол TCP. Друпзми словами. протокол
ГТР предоставляет почьтователю возможность передавать файлы между двумя компью-
терами, как правило, через Итернет В сущности, для получения доступа к файлам
пользователю просто необходимо зареви |рировать свою учетную запись (account) на
удаленном сервере FTP (получение анонимного доеппа к FTP рассматривается ниже в
данной главе). На рис. 10 I в паве 10 можно увидел ь. к каким уровням моделей OSI и
DoD относится протокол FTP.

Протокол FTP выполняет четыре целевых функции а именно:

•	Поддерживает совмесшое использование файлов (компьютерных программ или
данных).

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

•	Ограждает пользователя oi проблем, связанных с различиями в файловых систе-
мах на запоминающих устройствах.

•	Осуществляет надежную и эффективную передачу данных.
Протокол FTP предоставляет в распоряжение полыователя различные службы пере-
дачи файлов (file transfer services) между удаленными хостами. В процессе пересылки
фай'юн с помощью FTP копии файлов передаются от одной системы к другой Иденти-
фикация пользователя сервером FTP происходит через уникальную учетную запись
пользователя (unique user account) или через анонимную учетную запись (anonymous
account), если такой тип учетной записи поддерживается конкретным ГТР-сервером С
помощью учетной записи пользователь имеет возможность japei истрироваться в систе-
ме. а затем осуществлять передачу файлов. Этол процесс рассматривается более подробно
ниже в данной главе. Подобно Telnet, протокол FTP действует между двумя хостами,
которые могут функционировать под управлением разных операционных систем с раз-
ными файловыми структурами н даже под .правлением наборов символов различных
типов. В отличие от Telnet, который использует 7-разрядный код ASCII NVTдля обслу-
живания множества неоднородных систем, FTP поддерживает ограниченное количество
типов фай юн (Ilie tvpesi и файловых структур (Tile structures).

£ ИЗ ИСТОРИИ ПР

Долгий путь развития протокола FTP начался в 1971 году, когда Абхай Бхушан (Aohay
Bhushan) (RFC 114) разработал первые алгоритмы пересылки файлов для реализации на
хостах компьютерной сети Массачусетского технологического института, США (M1T,
Massachussets Institute of Technolooies, USA). Сразу же после этого Эрик Хаслем (Епс
Harslem) и Джон Хефнер (John heafner) представили RFC 141, "Комментарии к RFC 114
(Протокол передачи файлов)" ("Comments on RFC 114 (a File Transfer Protocol")). Далее
события разворачиваются следующим образом:

•	23 июня 1971 г — в RFC 172 Бхушан представляет описание ориентированного
на пользовательский уровень протокола для передачи файлов между хост-компь-
ютерами, включая интерфейсный процессор сообщений (IMP)

•	17 ноября 1971 г. — Бхушан модифицирует RFC 172 и представляет RFC 265.

•	£ декабря 1971 г. — Алекс Маккензи (Alex McKenz.e) предлагает дальнейшие из-
менения р RFC 281.

•	25 января 1972 г. - Бхушан предлагает использование "типа набора данных" (sei
data tvpe) в RFC 294.

•	8 июля 1972 г — Бхушан представляет RFC 354, после чего RFC 264 и 265 стано-
вятся устаревшими и выходят из употребления. На данном этапе Бхушан опреде-
ляет FTP как протокол для передачи файлов между хостами в сети ARPANTT В
этом же RFC определена основная функция FTP надежная и аффективная пере
дача файлов между хостами, а гакже рациональное использование возможностей
удаленных файловых запоминающих устройств.

•	16 февраля 1973 г — Маккензи публикует первый официальный документ FTP в
RFC454

•	12 июля 1973 г. — Ненси Нешес (Nancy Neigus) публикует новый официальный
документ FTP р RTC 542. Хотя общая структура протокола в этом документе ос
таится прежней, в RFC 542 отражены существенные изменения по сравнению с
цредшеп ву ющеи версией FTP
•	1974 г. — появляется множество комментариев FTP в RFC 607, 614 и 624 (а также
во многих apvinx RFC). Это вдохновляет Брайана Харви (Brian Harvey) на разра-
ботку своей версии FTP и публикацию 10 мая 1975 г RFC 686 под названием
"Leaving Well Enough Alone".

•	Июнь 1980 г. — Джон Постел (John Postel) публикует RFC 765 с описанием дей-
ствия FTP на базе протокола TCP. Причиной публикации этого документа стала
замена протокола управления сетью (NCT. Network control Protocol) на протокол
управления передачей данных (TCP, Transmission Control Protocol).

•	Октябрь 1985 I. — Джон Постел (John Postel) и Джойс Рейнолдз (Joyce Reynolds)
публикуют текущее описание FTP, RFC 959. В этом RFC исправлены основные
ошибки предыдущих описаний FTP, улучшены разъяснения некоторых характе-
ристик протокола, а также добавлены некоторые команды.

Сеанс FTP

Представьте себе, что возникла необходимость в загрузке из сети Интернет нового
драйвера для звуковой карты: для этого нужно активизировать сеанс FTP. В большин-
стве случаев сеанс FTP (FTP session), который можно инициировать через браузер Web,
подразумевает взаимодействие пяти программных модулей (software elements):

•	Пользовательский интерфейс (User Interface): этот модуль предоставляет пользо-
вателю интерфейс, позволяющий ему работать с FTP, и активизирует интерпре-
татор протокола клиента

•	Интерпретатор протокола клиента (client protocol interpreter), сокращенно — PI
клиента (Client PI): этот модуль выдает команды в адрес интерпретатора прото-
кола удаленною сервера (remote server protocol interpreter), а также активизирует
процесс передачи данных (data transfer process).

•	Интерпретатор протокола сервера (server protocol interpreter), сокращенно — PI
сервера (Server PI): этот модуль отвечает на команды, полученные от PI клиента,
а также активизирует серверный процесс передачи данных.

•	Процесс передачи данных, выполняемый клиентом (client data transfer process),
сокращенно — DTP клиента (Client DTP): этот модуль осуществляет связь с сер-
верным процессом передачи данных (server data transfer process) и файловой сис-
темой локального хоста (local file system).

•	Процесс передачи данных, выполняемый сервером (server data transfer process),
сокращенно — DTP сервера (Server DTP): этот модуль осуществляет связь с DTP
клиента и файловой системой удаленного хоста (remote file system).

В состав пользовательского протокола FTP (User-FTP) входят следующие программ-
ные модули:

•	Пользовательский интерфейс (U1)

•	PI клиента (Client Pl)

•	DTP клиента (Client DTP)
В состав серверною протокола FTP (Server П1’) входят следующие программные
моду in:

•	PI сервера (Server PI) — порт управления (control port)

•	DTP сервера (Server DTP) — порт данных (data port)

Основное огчичие протокола FTP от ipvinx протоколов состоит в том. что FTP ис-
пользует два соединения между портами TCP Одно из этих соединений устанавливает-
ся между модулями П клиента и сервера FTP; это соединение называется соединением
для управления (control connection) Друюе соединение устанавливается между мод\ 1я-
ми D ГР клиента и сервера Fl Р; это — соединение для передачи данных (data connection).
Модули PI клиента и сервера используют управляющее соединение для установления и
коирдинапии процесса передачи данных между хостами под управлением протокола FTP
(FTp communication between hosts) Подобное ТСР-соединенне должно быть установле-
но еще до начала передачи файлов тем или иным хостом

PI сервера прослушивает все запросы, пос гупаюгци0 по управляющему соединению
на общеизвестный порт 21, и ожидает установления связи с клиентом. Со своей сторо-
ны PI клиента инициирует установление соединения посредством передачи запроса на
синхронизацию (SYN) протокола TCP (см 1 паву 8). Этот запрос передается в виде уп-
равляющего сооошения, направленною через общеизвестный 1 СР-порт 21 в адрес хос
та назначения. После установления управляющею соединения между взаимодействую-
щими сторонами это соединение остается активным до тех пор, пока происходит обмен
данными между клцентом и сервером. Протокол ПР использует управляющее соеди
некие для передачи команд от клиента к серверу и для передачи ответов сервера на
команды клиента.

Соединение между модулями DTP сервера и клиента (соединение для передачи дан
ных) устанавливается каждый раз, когда осуществляется пере (ача файлов. Это соедине-
ние может также быть установлено и в некоторых других случаях (об этом юворится
ниже в данной главе). Клиент FTP передает адрес данных на обшеизьестный порт 20
сервера DTP (порт, назначенных для передачи данных FTP). Порту клиента FTP при-
сваивается изменяемый номер, выделяемый только на время данною сеанса ПР Та
ким образом, протокол FTP использует два пути для установления логическою соеди-
нения: по одному пути устанавливается управляющее соединение (порт 21), не другому —
соединение для передачи данных (порт 20). ТСР-норт 21 управляющею соединения
должен быть открыт еще до начала обмена данными. Если пользователь намеревается
осуществить передачу файла (отправить или получить файл), сначала он должен выпол-
нить соответствующую команду ПР. Результатом выполнения такой команды ПР яв-
ляется открытие второго соединения — соединения для передачи данных (ТСР-норт 20).

В cociae возможностей протокола I 1 Р входит использование битов минимизации за-
держки прохождения данных но сети дли задания требуемого типа сервиса (эти бз.ты
устанавливаются н поле ToS заголовка IP). Необходимость в этом вошикае) из-за того,
чго команды ПР, как правило, вводятся пользователем через текстовый интерфейс, что
существенно замеояе! процесс передачи файлов Протокол TCP используй инфопма-
нию, указанную в битах поля ToS. для установки бита форсированной передачи данных
(push bit) в заготовке TCP. Эю действие приводи! к отправке по всему стеку протоко-
лов сообщений, юнерируемых сеансом ПР каждою хоста и содержащих запросы на
незамедлительную обработку данных. Эю, в свою очередь, уменьшает время обработки
данных но время обмена ннформапиен между клиентом и сервером.

')<? ПРИМЕЧАНИЕ

Необходимо помнить о том, что приложение может использовать биты поля типа обслу-
живания (ToS) заголовка IP для того, чтобы выдать в адрес маршрутизатора запрос на
передачу данных по особому пути, рассчитанному на основе требуемого уровня обслу-
живания Более подробную информацию о битах поля ToS можно найти в главе 3.

С целью увеличения производительности процесса передачи файлов (file transfer
performance) соединение для передачи данных может также использовать биты макси-
мизации пропускной способности кнналп. устанавливаемые в ноте ToS заголовка IP

Конкретная реализация битов поля ToS в соединениях РТР зависит от поставщика
сетевых услуг. Результатом целесообразною использования соответствующих требова-
ний к качеству обслуживания во время обмена информацией как по управляющему
соединению, так и по соединению для передачи данных, является повышение произво-
ди! ельности. что, в свою очередь, приводит к ускорению диалош между клиентом и
сервером ITP и собственно процесса передачи фай юв. На рис. 12.1 представлена об-
щая схема взаимодействия между клиентом и сервером FTP. На рис. 12.2 и 12.3 показа-
ны два разных соединения (соединение для управления н соединение для передачи дан-

ных) между клиентом и сервером

в том виде, в каком эти соединения интерпретирует

анализатор протоколов Sniffer.

FTP пользователя

РИСУНОК 12.1 Интерпретатор протокола отвечает ю обработку команд ПТ и ответов на них
Польчмате 1ъекин интерфейс обеспечивает пользователей средствами подачи команд FTP по
управ 1яющсму соединению в диалоговом режиме

Представление данных

Протокол FTP имеет мною возможностей, позволяющих решить проблему представ-
ления данных (data representation) и их хранения Еще до начала обмена информацией
между клиентам и сервером должно состоя!ься согласование параметров сеанса FTP
(session negotiation) Рис. 12.4 иллюстрирует происходящий между клиентом и сервером
процесс согласования типа файла.
РИСУНОК 12.2 A.iufhmr FTP (64 0.0.57) назначен изменяемый парт 2001 (этот номер попадает в

диапазон от 1024 до 65530) Д/т у& прения процесса обработки информации в за 'омнзке TCP
установ зен бит форсированной пепедачи данных

РИСУНОК 12.3 Порт дня передачи данных поотопила FTP открывается каждый раз, когда
постзпост запрос на передачу файлов. Для пересылки данных FTP используется ТСР-порт 20
(двщзцпвактныЯсерверный ТСР-порт d ie данных FTP).
РИСУНОК 12.4 Клиенты и серверы FTP согласуют тип передаваемого файла В данном примере тип
файла, подлежащего отправке, — ASCII (это можно увидеть в заголовке FTP)

Существует три параметра, согласование которых необходимо выполнить до пере-
дачи файла:

•	Представление данных (data representation): идентифицирует тип передаваемых
данных.

•	Структура данных (data structure): задает формат передаваемых данных

•	Режим передачи (transmission mode): определяет способ передачи данных по со-
единению ГТР для передачи данных.

FTP имеет в своем распоряжении четыре способа представления данных:

•	Представление данных в кодах ASCII (по умолчанию)

•	Представление данных в кодах EBCDIC

•	Двоичный образ данных (image file type)

•	Представление данных в формате локального файла (local file type)

Кроме тою, файлы типа ASCII и EBCDIC могут иметь следующие параметры, по-
зволяющие управлять форматом этих файлов во время их передачи:

•	Файл в формате ASCII с нераспечатываемыми (nonprinl) управляющими симво-
лами.

•	Управляющие символы форматирования Telnet (Telnet format control)

•	Управляющие символы вертикального форматирования языка Fortran (Fortran
carriage control).
FTP может испольювап. при пересылке фай лов три типа структуры данных;

•	Файловая структура (file) — по умолчанию

•	Структура записеи (record)

•	Страничная структура (page)

FTP имеет в своем распоряжении три режима перс гачи файлов.

•	Потоковый режим (default) - по умолчанию

•	Блочный режим (block)

•	Режим сжатия данных (compressed)

Различные сочетания указанных выше параметров образуют в своей совокупное! и
более 72 способов пересылки файлов. Задача применения параметров для разрешения
проблем, связанных с различиями в представлении данных и их хранении, состоит в
следующем:

•	Обеспечение поддержки каждою типа данных и файлов.

•	Преобразование файлов в единый для всех сетевых FTP-сервероь формат

•	Присвоение файлам ряда общих базовых свойств и поддержка этих свойств

Разработчики FTP могли бы избрать каноническое представление файлов (стандар-
тный формат файлов, в который взаимодействующие стороны должны были бы преоб-
разовывать свои файлы) — например, представление файлов в формате NVT. Вместо
згою был избран другой способ: обеспечение файлов совокупностью общих базовых
свойств. Подробное описание NV1 можно найти в 1лтве 11.

Типы данных FTP

Тип файла (file type) задает формат передаваемых данных. Протокол FTP пересыла-
ет текстовый файл по соединению для передачи данных в форма<е ASCII NVT Это оз-
начает, чю отправитель файла должен преобразовать локальный текстовый фаич в фор-
мат ASCII NVT. а получатель должен преобразовать файл в формате ASCII NVT в
локальный текстовый файл. Коней каждой строти обозначается парой управляющих сим-
волов CR/LF (возврат каретки/перснод строки, управляющие колы ASCII NVT), а это
значит, что получатель просматривает каждый байт данных на наличие пары CR/LF На
рис. 12.5. 12.6, 12.7 и 12.8 представлены чстырс разных типа данных, которыми прото
кол FTP может воспользоваться при передаче файлов: ASCII, EBCDIC, двоичный образ
данных и формат локальнобО файла

ASCII: тип данных по умолчанию для текстовых файлов

Y	

7	1	7	1	7	1

РИСУНОК 12.5 Д 1н представления текстовых файлов протокол FTP использует коО ASCH
(8-разрядпые ги.иво./ы) в качестве типа данных по умолчанию.

Подобное преобразование файлов из одною формата в другой объясняет тот факт,
что при передаче фантов хостами под управлением операционной системы Unix коли
честно переданных байтов больше реальною размера файла. Следует обратить внима-
ние на то, что если одна из систем или обе системы не применяют кодирования текста
с помощью кода ASCII, ответственность за преобразование файлов в формате ASCII NVT
в локальные текстовые файлы (другими словами, кодирование) принимают на себя про-
цессы передачи данных. Несмотря на то, что протокол FTP может применять любой из
четырех типов данных FTP, в действительности чаше всею исно тьзуются такие типы
представления данных, как ASCII и двоичный образ данных.

EBCDIC: Используется для текстовых файлов IBM

I Y ~ll Е II S _1

8	6	8

РИСУНОК 12.6 Представление данных в кодах EBCDIC (В разрядных символах), которые
первоначально использовались дзя текстовых файлов IBM. обеспечивает альтернативный способ
пересылки текстовых фай toe, когда обе взаимодействующие системы поддерживают систему
кодирования EBCDIC

Двоичный образ данных: Используется для обмена файлами между однотипными устройствами

РИСУНОК 12,7 Непрерывный поток битов используется для передачи данных в файлах. в которых
данные представ гены в форме двоичных образов (^разрядных символов), применяющихся, как
прави го. для обмена файлами между однотипными устройствами и д in обмена двоичными файлами

Байт, имеющий задаваемый локальным хостом размер: Используется в ситуациях,
когда необходимо придерживаться заданного размера модуля данных

I V II Е ||~ S П

XXX

РИСУНОК 12,8 Тип локального файла, который используется для передачи файлов между хостами i
применением байтов разных размеров и фиксированным размером модуля данных, предполагает
использование размера байта, опреде генного локальным хостом.

Форматирование передаваемых файлов

Применение тою или иною типа данных при пересылке файлов предполагает опре-
деленный способ форматирования лих файлов. Опция форматирования, как правило,
применяется при форматировании текстовых файлов, предназначенных для вывода на
устройства печати (принтеры). Различные управляющие символы форматирования, вклю-
чая указывающий на начало страницы символ, задают определенный способ вертикаль-
ного форматирования информации, содержащейся в передаваемом файле. Однако ука
тайные ниже параметры могут использоваться только файлами ASCII и EBCDIC

• Неструктурированный файл без управляющих символов форматирования
(nonprinl) — по умолчанию: файл с этим параметром не содержит никаких сим-
волов дтля управления печатью (никаких управляющих символов вертикальною
форматирования распечатываемою файла).

• Форматирование посредством управляющих символов протокола Telnet (Telnet
format control): файл с этим параметром содержит управляющие символы верш
кальншо форматирования протокола Telnei iTelnet vertical formal), задающие ре-
жим интерпретации принтером передаваемой на печать информации

• Форматирование посредством управляющих символов языка Fortran (Fortran
carriage control): этот способ форматирования задает интервал между строками
файла с помощью первого символа каждой строки (управляющего символа фор-
матирования языка Fortran, Fortran format control character).

Структуры данных FTP

Файлы, передаваемые с помощью протокола FTP, могут иметь свою внутреннюю
структуру, которая не нарушается в процессе пересылки. Процессы передачи данных
(DTP. Data Transfer Process) клиента и сервера FTP несут ответственность за преобра-
зование передаваемых структур данных в локальные структуры и наоборот. Различные
параметры задания структуры данных позволяют FTP обеспечивать передачу файлов
между хостами, функционирующими под управлением различных операционных сис-
тем и использующими различные структуры данных для передачи своих файлов. FTP
может использовать три различных типа структур данных: файловая структура (file
structure), структура 1анных в форме совокупности зип.мссй (record structure) и странич-
ная структура (page structure)

ПРИМЕЧАНИЕ

Важно отметить, что структуры данных FTP эквивалентны структурам файлов FTP однако
в данной книге с целью избежания неточностей в изложении материала в большинстве
случаев употребляется термин "структуры данных FTP”.

Данные, имеющие файловую структуру FTP, не имеют никакой внутренней струк-
туры и передаются в непрерывном потоке байтов информации (stream of contiguous bytes).
Протокол FTP использует файловую структуру данных по умолчанию. Структура дан-
ных в форме совокупности записей, которая используется только при пересылке тек-
стовых файлов, предполагает разбиение фаиюв на совокупность последовательных за-
писей (sequential records). Страничная структура файла представляет собоп файл,
образованный из автономных индексированных страниц (independent, indexed pages):
такая структура данных подлежит обработке операционной системо'1 TOPS-20. Странич-
ная структура данных используется для передачи дискретных файлов, в которых при-
сутствует дескриптор фа и.та или какие-либо другие относящиеся к пересылаемым дан-
ным сведения Каждая страница имеет свой номер, что предоставляет пользователю
возможность хранить полученные страницы в произво ibhom порядке. Рис. 12 4, 12.10 и
12 11 иллюстрируют различные структуры данных ГТР.

Файловая структура: файл не имеет внутренней труктуры и представляет собой
непрерывную последовательность байтов
    

РИСУНОК 12.9 Данный рисунок ил иострррует файловую структуру данных ГТР

РИСУНОК 12.10  Данный рисунок иллюстрирует empyi туру ванных FTP в форме совокупнпст и записей.	  	Структура записей файл состоит из совокупности последовательньх записей
	  	
	  	
Страничная структуре: файл состоит из автономных индексированных страниц

РИСУНОК 12.11

Данный рисунок
uwicmpupyem страничную
структуру данных FTP.

Режимы передачи данных FTP

Режим передачи данных (transmission mode) определяет способ пересылки файлов по
соединению FTP для передачи данных. Всего существует три режима: потоковый (stream),
блочный (block) и режим сжатия данных (compressed), однако в реальных условиях чаще
всего используется потоковый режим Потоковым режим передачи данных, при кото-
ром данные передаются в потоках байтов, принимается по умолчанию; этот режим по-
зволяет передавать данные также в форме совокупности записей. В потоковом режиме
отправитель закрывает соединение для передачи данных посредством управляющего
символа конца файла (end of file. FOF) для файловой структуры Для структуры запи
сей существует специальная 2-байтовая последовательность управляющих символов,
указывающая на конец записи (end of record, EOR) и на конец файла (end of file, EOF).

Елочный режим передачи данных применяется для пересылки файлов между терми-
налами. поддерживающими такой режим. В блочном режиме файлы передаются как
последовательность блоков данных, каждый из которых начинается заголовком разме-
ром один или более байтов.

Режим сжатия данных используется редко; способы сжатия данных Moiyr отличать-
ся в зависимости or того, какая версия FTP используется. В режиме сжатия данных
выполняется сжатие заполнителя (файлы ASCII или EBCDIC) и дублированных данных.
В этом режиме выполняется также сжатие текста и повторяющихся двоичных значений
в файле (например, последовательность двоичных нолей). Кроме того, передача данных
в режиме сжатия позволяет максимально увеличить ширину полосы пропускания. Ме-
тоды сжатия отличаются в зависимости от типа передаваемого файла. Например, если
выполняется сжатие файлов ASCII или EBCDIC, содержащих символ-заполнитель,
сссссссссс (Ю байтов данных), в два байта данных, в эти два байта будет включена сле-
дующая информация: 2 бита, указывающие на то, что выполнено сжатие дублирован-
ных данных: 6 битов — на представление в двоичном коде количество символов (0010Ю =
двоичное 10); 8 битов — для кодирования передаваемого символа "с".

Команды FTP

Интерпретаторы протокола клиента и сервера FTP обмениваются командами и от-
ветами на них по управляющему соединению. Команды и ответы FTP передаются в виде
последовательностей символов ASCII NVT (Telnet). Эти последовательности символов
Telnet начинаются с трех или четырех символов ASCII NVT верхнего регистра и завер-
шаются управляющими символами <CR>, <LF> (возврата каретки и перевода строки)
в конце каждой команды. Клиент может передать в адрес сервера более 30 команд. Эти
команды подразделяются на три категории: команды управления доступом (access control
commands), команды задания параметров пересылки файлов (transfer parameter commands)
и сервисные команды (service commands). Команды управления доступом определяют.
какой клиен i может получить доступ к тому или иному файл\. В таблице 12.1 представ-
лены рапичные команды управления доступом, которые сервер может выполнить

Таблица 12.1 Команды управления доступом протокола FTP____________________________

Кг манда/Пирали тр	Описание
"АССТ[идентификатор учетной записи]	Идентификация учетной записи пользователя.
CDUP	П реход в родительский каталог удаленной системы (сервера)
CWD[nyrb]	Переход в другой каталог сервера
PASS[napcwib]	Пароль пользовател11 Команда применяется сразу же после команды USER.
QUIT	Закрытие или разрыв соединения.
•REIN	Повторная инициализация, конец сеанса FTP без разрыва соединения. За этой командой должна последовать новая команда  USER для другого пользователя
•SMNTfnyTb]	Передача удаленной системе пути к структуре файловой системы
USER [имя пользователя]	Идентификация пользователя сервером по имени пользователя.
Звездочкой отмечены команды.	которые используются редко

Протокол FTP использует команды задания параметров пересылки файлов с целью
изменения параметров, используемых для передачи данных по соответствующему со-
единению FTP по умгччанию В (аблице 12.2 представлены различные команды зада-
ния параметров пересылки фаи юв.

Таблица 12.2 Команды задания параметров пересылки файлов

команда; Параметр	Описание
МООЕ[режим]	Режим передачи, потоковый, блочный или режим сжатия данных (параметры S. В или С)
•PASV	Указание серверу DTP на необходимость прослушивания порта передачи данных по поводу установления соединения
РОНТ[порт клиента]	Задание номера порта клиента, который должен прослушиваться DTP на получение запроса на установление соединения
STRU[crpyKryp 1]	Структура данных, содержащихся о файле файловая <лруктура, ыруктура записей или страничная структура (параметры F R или Р).
ТТ°Е[тип файле]	Тип файла ASCII, EBCDIC, двоичный образ данных или локальный Файл
отмечены команпы	которые используются редко.

Протокол FTP использует сервисные команды, кота пользователь запрашивает пе-
ресылку файла или операцию с файлом. Локальные правша сервера FTP управляют
заданием параметра пути к файлу. В таблице 12.3 представлены различные сервисные
команды FTP.

Таблица 12.3 Сервисные команды протокола FTP_____________________________________

Команда Параметр	Описание

ABOR	Отмена предыдущей сервисной команды и запущенной пересылки

данных.
Коианда/Параметр	Описание
•Ди_О[размер]	Резервирование пространства для файла перед его пересылкой. Параметры команды задают количество байтов.
•ДРРЕ[путь]	Присоединение файла в конец существующего файла
DELE [путь]	Удаление файла на удаленной системе.
НЕ1_Р[строка)	Получение от сервера справочной информации; например, списка поддерживаемых сервером команд.
LIST[nyTb|	Передача списка файлов или текста удаленной системе
МКО(путь]	Создание каталога.
NLSTInyrb]	Список имен. Передача полного списка файлов текущего каталога сервера по соединению для передачи данных
NOOP	Нет операций.
PWD	"Напечатать рабочий каталог": вывод имени рабочего каталога на сервере.
REST[Mapxep]	Перезапуск процесса передачи с маркера сервера.
RETR[nyibj	Получение файла от сервера
RMD[nyTb]	"Удалить каталог”.
•RNFRfnyTb]	"Переименовать из Задание старого пути файла, подлежащего переименованию. За этой командой следует команда RNTO
•RNTOfnyrb]	"Переименовать на.Задание нового пути файла эТк команда используется вместе с командой RNFR
•SITE(CTpoKa]	Параметры узла сети. Эта команда используется сервером для того, чтобы сделать доступными некоторые специфические службы сервера.
'STAT [путь]	Запрос информации о состоянии.
STOR[hmp файла]	Хранение файла на сервере.
•STOU	"Сохранить с уникальным именем" Действие этой команды аналогично действию команды STOR, за исключением того, что STOU не выполняет перезапись существующего файла
•SYST	Запоос к сеоверу о типе его операционной системы
Звездочкой отмечены команды, которые используются редко.	

Команды FT Р оперируют требованиями протокола Telnei ко всем выполняемым че-
рез управляющее соединение действиям. Всем командам с параметрами предшествуе!
пробел (управляющий символ <SP>). Все команды заканчиваются символом возврата
каретки с переводом строки <CRLF>. Команды FTP, требующие ввода идентификато-
ров управления доступом (access control identifiers) и параметров пересылки данных (data
transfer parameters), а также команды, содержащие запрос на обслуживание (service
request), разделяются символами <SP> и <CRLF>

Ответы FTP

Ответ I ГР (FTP replies) имеет вид трехзначною кода, за которым следует лоиотнп-
|ельное текстовое сообщение. Формат ответов ITP предоставляет возможное!ь как ра-
ботающему в диалоговом режиме пользователю, так и программному обеспечению про-
чи!ыва1ь 01веты. предоставляющие информацию о выполнении команды Состоящие
из трех цифр коды ответов используются программным обеспечением для того, чтобы
определить свои дальнейшие действия. Пользователь прочитывает текст или дополни-
тельное сообщение, чтобы оценить дальнейшие действия программного обеспечения. Эта
удобное свойство ответов FTP устраняет необходимость в запоминании громоздких
числовых последовательностей соответствующих этим ответам.

Ответы РТР гарантируют синхронизацию запросов клиентов и соответствующих им
отпетых действий сервера в процессе передачи файлов. Благодаря ответам FTP пользо-
ватель всегда осведомлен о состоянии сервера На каждую выданную в адрес сервера
команду сервер должен сформировать, по крайней мере, один ответ. Команды могут
передаваться упорядоченными группами, в таком случае в ответе будет указано проме-
жуточное состояние выполнения всех команд i руппы в процессе их обработки серве-
ром. В случае сбоя при обработке какой шбо из команд возникает необходимость в
повторной передаче всей последовательности команд.

Формат выдачи ответов FFP следующий: трехзначныи код, управляющий символ
пробела <SP>, текстовое сообщение; завершает ответ FTP стандартный управляющий
символ конца строки <CRLF>. Ответы, выходящие за рамки одной строки, должны быть
заключены в скобки и переданы в специальном формате. Подробное описание много-
численных ответов FTP изложено в RFC 959.

Каждая из трех цифр кода ответов FTP имеет определенное значение. Первая цифра
указывает на положительный или отрицательный исход той или иной операции. Вторая
цифра показывает, какая приблизительно ошибка имела место. Третья цифра, щачение
которой зависит от второй, представляет более точную опенку характера произошедшей
ошибки. В таблице 12.4 стображены значения первой цифры кода, в таблице 12.5 —
второй, в таблице 12.6 — примеры значений третьей цифры кода ответов FTP.

Таблица 12 4 Значения первой цифры кода ответов FTP________________________________

Кед	Значение

1 уг	Предварительный положительный ответ. Сервер ожидает отправки в его адрес

_________следующей команды

2yz______ртвег г положительном завершении	выполнения комзнды.______________________

Зуг	Ответ о положительном завершении	промежуточной	операции. Существует

_________необходимосп в пересылке еще одной команды._______________________________
4yz Ответ об отрицательном завершении выполнения команды по причи <е возникновения

промежуточной (исправимой) ошибки. Выполнение команды не завершено. Через
_________некоторое время команду необходимо выдать повторно._______________________
5уг Ответ об отрицательном завершении выполнения команды по причине возникновения

устойчивой (неисправимой) ошибки Сервер не имеет возможности выполнить
команду: повторные попытки не предпринимаются.

Символами "х, у. г" в таблицах зашифрованы соответственно первая, вторая и тре-
тья цифры кодов ГТР-ьтветив.

Таблица 12.5 Значения второй цифры кода ответов FTP

AjcJ	Значение

xOz______Chi токсическая ошибка.___________________________________________________

x1z Ответ на информационный запрос

*2?	Состояние соединения
Код	Значение
x3z	Аутентификация и регистрация учетной записи
x4z	В настоящее время значение не определено
x5z	Состояние файловой системы.
Таблица 12.6 Примеры значения третьей цифры кода ответов FTP	
Код	Значение
125	Установлено соединение для передачи данных; начат процесс передачи данных
200	Команда успешно выполнена
211	Система занята.
212	Состояние каталога
213	Состояние файла
214	Вспомогательные сообщения для пользователя.
331	Имя пользователя принято; требуется пароль
425	Нет возможности установить соединение для передачи данных.
452	Ошибка при записи файла.
500	Синтаксическая ошибка (сервер не распознал команду)
501	Синтаксическая ошибка (некорректно указаны параметры).
502	Требуемый режим передачи данных не реализован на сервере.

В таблице 12.6 представлен частичный перечень значении третьей цифры кода отве-
тов FTP. Полный список этих значений можно наиги в RFC 959

Действие протокола FTP

Действие протокола FTP инициируется пользователем. Ни одно из происходящих в
процессе функционирования FTP событий нс произошло бы. если бы у пользователя
не возникла необходимость в этом событии. Предположим, пользователю необходимо
за1рузить с сервера FTP нужную для его компании про1рамму. В качестве примера рас-
смотрим все выполняемые протоколом FTP шаги, отображенные в окне анализатора
протоколов Sniffer (рис. 12.12):

1.	Клиент FTP (64.0.0.57) вводит с клавиатуры команды, необходимые для установле-
ния контрольною сеанса связи TCP с сервером FTP (63.0.0.1). На рис. 12.12 можно
увидеть, что первые три кадра отображают стандартную процедуру трехходового кви-
тирования протокола TCP с ТСР-портом 21 в качестве порта получателя.

2.	Непосредственно после установления соединения между взаимодействующими сто-
ронами начинается обмен сообщениями FTP. По кадру 4 можно увидеть, что сер-
вер Fl Р гогов к процессу передачи данных.

3.	Клиент и сервер FTP выполняют процедуру аутентификации (кадры 5—8).

4.	В кадре 9 клиент отправляет команду RETR — запрос на получение данных, содер-
жащий просьбу к серверу FTP о предоставлении клиенту необходимого ему про-
граммного файла.
5.	Команда клиент RETR вызывает открытие TCP-nopia 20 для соединения FTP для
передачи данных (кадры 10-12).

6.	После установления обеими сторонами соединения для передачи данных начинает-
ся согласование параметров передачи требуемого файла.

7.	Когда сервер FTP завершает загрузку файда, порт для передачи данных закрывается
(кадры 15. 17 и 18). Порт для управления остается открытым на протяжении всею
сеанса взаимодействия между клиентом и сервером FTP. На этом этапе пользова-
тель имеет возможность выдать запрос на загрузку другого файла Порт для переда-
чи данных закрывается после завершения процесса передачи данных.

8.	В данном примере пользователю был нужен только один программный фаты, поэтому
он выполняет команду завершения сеанса FTP Это действие вызывает закрытие
управляющего соединения FTP, что отмечено сообщением "goodbye" и последую-
щим закрытием ТСР-порта 21 (кадры 19-22).

Сервер FTP готов к передаче данных (кадр 4)

Открывается порт 20 передачи _

Процедура аутентификации

(кадры 5-8)

Трехходовое квитирование TCP
(кадры 1-3)

— Клиент отправляет команду RETR (кадр 9)

Гл

10

данных (кадры 10-12)	£“ V

Закрывается порт данных (кадры 15. Ij—

17 и 18)

Закрывается ТСР-порт 21 _
(кадры 19 22)

РИСУНОК 12 12 Протокол FTP начинает функционировать в соответствии с потребностями
пшыовате ш в загрузке того и iu иного файла с удаленного сервера FTP В данном примере клиент
I TP(t>4 0.0.57) жеюет получить файл от сервера FTP (63.0.0.1).

Анонимный доступ к FTP

В большинстве случаен доступ к файлам FFP сервера можно получить с помощью
зарегистрированной па этом сервере учетном записи пользователя. В то же время неко-
торые серверы предлатают возможность пересылки файлов по сети Интернет не через
специальную учетную запись пользователя, а посредством анонимной учетной записи
на FTP (anonymous FTP). Эго означает, что пользователю нет необходимости регистри-
роваться в качестве официального пользователя какой-либо системы с целью получе-
ния доступа к нредлпгаемым этой системой файлам.
Серверы FTP. сконфигурированные для поддержки анонимною доступа пользова-
телей к файлам FTP, предлагаю! |ромадное количество разнообразной информации —
01 программного обеспечения до кулинарных ренетов — всем, кому эта информация
необходима. В то же время владс 1ьцы этих серверов в любое время могут заблокиро-
вать анонимный доступ к файлам FTP, сделав тем самым эти файлы недоступными для
пользователей с анонимной учетной записью на FTP. Такая ситуация вызывает необхо-
димость в официальной регистрации учетной записи пользователя на сервере FTP.

Анонимный доступ к FTP предлагают многие серверы сети Интернет. Эзи серверы
предоставляют пользователю возможность зарегистрироваться, используя в качестве
имени пользователя идентификатор "анонимный" ("anonymous") пли "ftp". Когда сервер
выдает приглашение на ввод пароля, пользователь может указать свой электронный
адрес. Практически все поставщики сетевых услуг предпочитают знать, с кем они име-
ют дело; вто же время некоторые иг них не запрашиваюз пароль. Сразу же после про-
верки сервером пароля пользователь может начинать поиск требуемого файла на дан-
ном сервере FTP. Как правило, самые содержательные файлы находятся в корневом
казало!е (pub directory).

Анонимный доступ к ГГР наносит серьезный ущерб безопасности поэтому следует
строго контролировать этот процесс. При реализации Г TP-сервера необходимо убедиться
в том, что пользователь с анонимной учел ной записью не сможет получить доступ к кон-
фиденциальной информации компании. Лучше всего было бы вообще заблокировать
анонимный доступ к этой информации, предоставляя к пей доступ только пользовате-
лю с официальной учетной записью через пароль. Совершенно недопустима ситуация,
когда какой-либо пользователь, разыскивающий, например, рецепт испанскою блюда
паелла, натолкнется на адреса и телефонные номера сотрудников компании или какую-
либо другую конфиденциальную информацию и ’случайно" скопирует эти данные.

Резюме

Протокол FTP предоставляет возможность передавать файлы между двумя компью-
терами. как правило, — через Интернет. Протокол FTP выполняет четыре целевых фун-
кции. а именно: поддержка совместною использования фай юв (компьютерных программ
или данных); содействие косвенному, или неявному использованию удаленных компь-
ютеров; предотвращение проблем, связанных с различиями в системах файловых запо-
минающих устройств; надежная и эффективная передача данных.

Протокол FTP функционирует на основе взаимодействия пяти программных моду-
лей: пользовательскою интерфейса, интерпретатора протокола клиента, интерпретато-
ра протокола сервера, процесса передачи данных клиента и процесса передачи данных
сервера. Пользовательский FTP состоит из интерпретатора протокола и процесса пере-
дачи данных клиента. Серверный ГТР состоит из интерпретатора протокола и процесса
передачи данных сервера. Протокол FTP отличается от других протоколов тем что он
использует два отдельных TCP-соединения: одно для управления, друюе — для переда-
чи данных

Протокол FTP оперирует значениями трех параметров, необходимых для пересылки
файла: представление данных, структура данных и режим передачи данных. FTP под-
держивает четыре способа представления данных: в кодах ASCH. EBCDIC, двоичный
образ данных или локальный файл В распоряжении FTP имеется три типа структуры
данных файловая структура, структура записей или страничная структура. FTP поддер-
живает три режима передачи данных потоковый режим, блочный режим или режим сжа-
тия данных.

Интерпретаторы протокола клиента и сервера FTP передают свои команды и ответы
по управляющему соединению в виде последовательностей символов ASCII NVT (Telnet)
Эти последовательности символов начинаются с трех-четырсх символов ASCII NVT
верхнего регистра с управляющими символами CR и LF в конце каждой команды.

Ответы FTP cot тоят из трехзначных цифровых кодов и дополнительных сообщений
в виде текста, следующего за трехзначным кодом. Подобный сЬормат ответов FTP по-
зволяет как пользователю, так и программному обеспечению прочитывать эти ответы.
Выдача протоколом FTP ответов на полученные команды гарантирует синхронизацию
запросов в процессе передачи файлов, а также предоставляет пользователю информа-
цию о состоянии сервера.

Некоторые серверы требуют, чтобы пользователь, желающий получить доступ к фай-
лам FTP, зарегистрировал в системе свою учетную запись В то же время друтие серве-
ры распространяют свои файлы по Интернету посредством механизма анонимного до-
ступа к FTP, не требуя при этом наличия официальной учетной записи.

Вопросы для повторения

1	Какие возможности предоставляет пользователю протокол FTP и каковы четыре ос-
новные задачи этого протокола?

2.	Перечислите пять прсчраммных модулей, образующих сеанс FTP.

3.	Каковы функции интерпретатора протокола во время сеанса FTP9

4.	На зовите функции моду зеи Р1 и DTP во время сеанса FTP?

5.	Назовите два TCP-соединения. устанавливаемые протоколом FTP, а также объяс-
ните их предназначение

6.	Какие три параметра использует протокол FTP для представления данных?

7.	Какие четыре способа представления данных имеет протокол FTP в своем распоря-
жении?

8.	Какие три типа структуры данных поддерживает протокол FTP?

9.	Какие три режима использует протокол I ТР для передачи данных?

10	Какие три способа форматирования использует протокол FTP и какие типы данных
применяются при этом?

II.	Каковы характеристики потокового режима передачи данных и как работает этот
режим9

12.	На какие три категории подразделяются команды FTP и для чего интерпретаторы
протокола используют эти команды?

13.	Что тарангируюг ответы FTP и каков их формат?

14	Изложите суть механизма анонимною доступа к FTP
Глава 13

Упрощенный протокол
электронной почты (SMTP)

В данной главе рассматриваются следующие темы:

•	Модель именования, специфицируемая стандартом Х.400

•	Модель пересылки и формат почтовых сообщений протокола SMTP

•	Команды и ответы протокола SMTP

•	Протоколы получения почтовых сообщений

•	Набор стандартов передачи мультимедийной информации MIME

В качестве высокой оценки значения протокола SMTP (Simple Mai) Transfer
Protocol, Упрошенный протокол электронной почты), можно было бы привести
тот факт, что именно этот протокол оказался стимулом к созданию известного кино-
фильма “You've Got Mail" ("Вам пришло сообщение") Задолго до появления Тома Хэн-
кса и Мэг Райян в этом фильме практически каждому было известно, что такое элект-
ронная почта. Однако в основе (не примитивного сюжета фильма, а притягательных
возможностей службы пересылки почты по Интернету) лежит тот протокол, который
приводит в действие все волшебство электронной почты, — протокол SMTP. Протокол
SMTP, описание которою представлено в RFC 821. обеспечивает обмен сообщениями
электронной почты (e-mail) между отправителем (клиентом) и получателем (сервером).
В RFC 822, который служит логическим продолжением RFC 821. специфицирован фор-
мат этих сообщении.

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

Как упоминалось выше, SMTP функционирует на базе модели взаимодействия кли-
ент/сервер и использует для обмена почтовыми сообщениями между хостами обычный
информационный канал (TCP-соединение). Процедура обмена почтовыми сообщения-
ми предпола!ает реализацию серии транзакций "запрос/ответ" между SMTP клиента
(отправителем сообщения) и SMTP сервера (получателем сообщения). Протокол SMTP
обеспечивает доставку сообщений между удаленным клиентом и почтовым сервером
посредством использования следующих программных модулей:-МТА (Message Transfer
Agenl. Агент передачи сообщении) и UA (User Agent, Aiern пользователя) Пользова-
тель нс вступает во взаимодействие с протоколом SMTP, чтобы сформировать почтовое
сообщение и отправить ею: SMTP функционирует в фоновом реж гме, обеспечивая до-
ставку сообщений между удаленными хостами. При эгрм предполагается, что пользова-
тель имеет возможность по тучить направченную в его адрес почту, обратившись к ка-
кому-либо устройству сети (почтовому серверу), предназначенному-для промежуточного
хранения почтовых сообщений. На рис. 13 I показаны основные компоненты протоко
та SMTP.

РИСУНОК 13.1 Мооен> функционирования протокою SMTP - упрощенного протокола электротиш
почты

Отравитель почтовою сообщения шаимодеистнуст с по.чучатс гем через серию зап-
росов и ответов SMTP, которые управляют процессом доставки сообщении. Для обмена
сообщениями электронной почты протокол SMTP использует команды MAIL FROM
(адрес отправителя) и RCPT ТО (адрес получателя). Предположим, у вас возникло же-
лание отправить Электронное сообщение своей маме. Для этою необходимо выполнить
следующие действия:

I.	Открыть одну из прикладных программ обслуживания электронной почты, которая
соединит вас с программным модулем SMTP клиента, то есть с агентом пользовате-
ля (UA, User Agent) на этом хосте.

2.	Составить подходящее сообщение в-a ipec мамы.

J Указать адрес пункта назначения (имя почтового ящика мамы). Адрес отправителя,
как прави ло, динамически-присоединяется к сообщению, в противном случае необ-
ходимо вручную ввести этот адрес.

4.	Нажать кнопку "Отправить" ("Send"): Это действие инициализирует установление се-
анса TCP. Дальнейшую ответственность за доставку сообщения берет на себя про-
токол TCP

5.	Клиент открывает локальныи TCP-порт для агента пользователя (UA) и запрашива-
ет установление TCP-соединения с сервером SMTP (агентом передачи сообщений,
МТА).

6.	Сразу же после установления TCP-соединения между UA и МТА получатель (элек-
 ройная учетная запись адресата) передает в своем ответе код операции 220, кото-
рый означает “Готов принять почту"
7.	Отправитель (электронная учетная запись пользователя) выдает приветственную ко-
манду вместе с именем отправителя "HELLO: Имя oi правителя”, что указывает на
начало почтового сообщения.

8.	Сервер отвечает кодом операции 250, что означает подтверждение правильности вы-
полненной операции, и начинается передача почтовой транзакции (mail transaction).

9.	SMTP клиента отправляет команду MAIL FROM, сообщая при этом серверу полное
имя отправителя.

)0. SMTP сервер проверяет содержание команды MAIL FROM на наличие синтакси-
ческих ошибок и на полноту представления требуемых сведении, и отвечает "ОК".

11	Далее SMTP-клиент отправляет команду RCPT ТО сообщая при этом серверу имя
адресата почтового сообщения.

12.	Если SM ГР-сервер имеет возможность принять почгу Д-ТЯ указанною адресата, он
отвечает "ОК". В противном случае он отвечает отклонением запроса на передачу
почтовою сообщения адресату (но не прекращением всей почтовой транзакции).

13.	БМТР-клиен! и SMTP-сервер могут согласовать между собой передачу почтовых со-
общений нескольким адресатам. после чего SM ГР-клиент отправляет почтовые дан-
ные.

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

Возможно, электронная почта так нравится всем последующей причине: вы не только
сделали свою маму счастливой, отправив ей такое милое электронное письмо; вы сде-
лали это без двухчасовою общения с мамой по телефону При этом вам удалось избе-
жать разнообразных вопросов о вашей личной жизни. Электронная почта — это сред-
ство необременительного, безболезненного общения.

Рассмотрим сеанс SM ГР в виде, в котором его интерпретирует анализатор протоко-
лов Snifter. Как показано на рис. 13.2. хост-огправитель. SMTP-клиент Atlantis, пред-
ставляется SMTP-серверу (192.42.252.1) приветственным сообщением "HELLO" Сервер
отвечает сообщением "Рад с вами познакомиться" ("Pleased to meet you”). Процедура
аутентификации продолжается выдачей отправителем команды MAIL FROM; со сторо-
ны получателя поступает положительное подтверждение действии отправителя (ОК).
Клиент задает имя адресата командой RCPT ТО. а затем передает данные, заканчиваю-
щиеся точкой (.). После эюго сервер SMTP выполняет доставку почты адресату.

Модель именования стандарта Х.400

Для того чтобы лучше понять механизм работы протокола SMTP, необходимо изу-
чить модель именования (naming model), предписываемую стандартом Х.400 (протоко-
лом международного обмена электронными сообщениями), поскольку SMTP следует
принятым в Х.400 условным обозначениям. Рис. 13.3 на примере обмена электронными
сообщениями с использованием стека протоколов TCP/IP и 1люстрируст базовую модель
обмена электронными сообщениями Х.400. На этом рисунке агенты пользователей (UA)
и тенты передачи сообщении (МТА) осуществляют обмен сообщениями электронной
почты. Модель Х.400 состош из следующих основных пршраммных модулей: агент пе-
редачи сообщений (МТА. Message Tiansfer Agent), банк сообщений (MS, Message Store),
aieHT пользователя (UA, User Agent) и модуль доступа (AU, Access Unit)

РИСУНОК 13.2 Перед осуществлением доставки мектриннои почты адресату протокол SMTP
Оо..жеи установить ТСР-соедииеиие.

В приведенном примере агент пользователя (UA) отвечает за формирование и ана-
лш заголовков сообщений (message Headers), формат которых определен в RFC 822
Пользователи получ. ют возможность немедленного взаимодействия с электронной по-
чтои через UA. Посредством этого же модуля пользователь формирует, представляет для
пересылки адресату и получает сообщения электронной почты Каждое сообщение со-
стоит из конверта сообщения (envelope) и тела сообщения (bodj). Коннер! содержит
информацию, необходимую для доставки и обработки сообщения. Тело сообщения со-
держит информацию, которую отправитель передает получателю. В простейшем случае
конверт состоит только из заголовка сообщения. Модуль UA, как правило, компонует
конверт SMTP (SMTP envelope) на саиге-источнике сообщения (originating site), когда
происходит первичное формирование очереди электронных сообщений, подлежащих
пересылке программным модулем SMTP клиента Адрес, по которому направляется
сообщение, указывается в одном из следующих полей: в ноле "Кому" ("То") где может
быть указан список рассылки сообщения (mailing list), либо в поле "Копия" ("Сс"). где
указывается адрес для пересылки копии сообщения (carbon сору) Команды MAIL и RCPT
пересылают конверт отдельно от самого сообщенил Команды SMTP 6о iee подробно рас
сматривакися ниже в данной главе.
Пользователь
I

Пользователь
I

UA - UA, Агент пользователя

МТА - МТА, Агент передачи сообщений
MS - MS, Банк сообщений
AU - AU, Модуль доступа

РИСУНОК 13.3

Аеент пользователя flU)

предоставляет

возможность составлять,

отправлять и получать
сообщения электронной
почты.

НА

-> МТА <-

РЗ ф Система передачи сообщении
Р1
МТА -<---------------► МТА----------

Система обработки сообща, ми

Функциональная модель X 400

Агенты передачи сообщений (МТА)

На основании анализа программы 1123 SMTP можно утверждать, что серверные про-
граммы SMTP имеют характеристики, сходные с характеристиками агентов передачи
сообщений (МТА, Message Transfer Agent) стандарта Х.400. Модули МТА осуществляют
обмен электронными сообщениями, а также несут ответственность за выбор маршрута
исресылки-сообшений электронной почты по сетевым комплексам. Фактически МТА
являются коммутаторами сообщений; совокупность таких коммутаторов сообщений
формирует систему передачи сообщений (MTS, Message Transfer System). МТА выпол-
няют следующие функции:

•	Прием сообщений UA или МТА. маршрутизация сообшения соответствующим UA,
МТА, а также доставка сообшения конечному адресату

•	Анализ содержащегося в сообщении списка получателей сообщения (recipient list)
и принятие решений о выборе маршрута. Передача сообшения модулю UА и фор-
мирование (в случае необходимости) уведомления о доставке сообщения (delivery
notification).

•	Пересылка сообщений модулю МТА с указанием на то. что они должны быть
переданы другому МТА.

•	Формирование уведомления о невозможности доставить сообщение (NDN. non-
delivery notification) в случае, если сообщение не доставлено из-за указанного не-
корректного или несуществующего адреса.

•	Создание копии сообщения и доставка этих копий по разным адресам в случае
пересылки мног оадресно!о сообшения (muJti-addressed message).

Комитет Международного союза по телекоммуникациям (ITU, International
Telecommunications Union) принял и реализовал набор стандартов Х.400, разработанных
и рамках СС1ТТ (Consultative Committee Гог International Telegraphy and Telephony, Меж-
дународный консул ьташвны11 ком hi ет но телеграфии и телефонии). Стандарт X 400
представляет собой ряд протоколов для адресации сообщений электронной почты, ко-
торыми обмениваются почтовые серверы Функции этих протоколов заключаются в
следующем.

•	Передача мультимедийных сообщений: звуковых и графических сообщении, со-
общений в ниде факсов и текстов tmultimedia messages).

•	Согласование действии разнотипных систем на базе общею интерфейса (interlacing
unlike systems).

•	Обеспечение защиты передачи сообщении от несанкционированного доступа
(security of message transmission).

•	Обеспечение надежности зраиснортировки сообщений (reliable transport of
messages).

•	Архивирование сообщении (archive of messages).

•	Создание служб каталогов для хранения электронных адресов и их локализации
(director}' services Гот locating addresses).

•	Формирование otneron о доставке и получении сообщений (reporting delivery and
receipt of messages).

Формат сообщений SMTP

Формат сообщения SMTP вьнлядит следующим образом: собственно сообщение,
состоящее из заюловка (header) и тела сообщения (body), и так называемый ''конверт"
(envelope), представляющий собой SMTP-адреса отправителя и получателя (SMTP source
and destination address). Подробное описание содержимого конверта и его интерпрета-
ция представлены в RFC 821 В следующем примере показаны две команды SMTP, сне
инфицирующие содержимое конверта (более подробно команды SMTP рассматривают-
ся ниже в данног! главе):

•	MAIL FroniXheatherPitacademy.com>

•	RC PT To:jason@ieacademy.com

Тело сообщения, согласно спецификациям RTC 822, состоит из текста ASCII
(American Standard Code for Information Interchange, Американский стандартный код для
обмена информацией). В коле ASCII можно представить как текстовые данные (буквы,
числа и таки препинания), так и управляющие символы, которые фактически пред-
ставляют собой команды, такие как возврат каретки и перевод строки. Аналогично дру
 им системам кодирования, ASCII преобразует информацию в стандартный цифровой
форма! с исно |ьзованнем состоящих из семи символов двоичных чисел (seven-digit binary
numbers). Эш двоичные числа, в свою очередь, состоят из последовательностей сихзво-
юв I н 0. Компьютеры взаимодействуют между собой, обрабатывают и храпя| данные,
используя это! цифровой формат. NV1. использующий семиразрядный код для пред
славления символов, передает |акой семиразрядный код ASCII в 8-разрядных okicijx.
в которых самый старшин бит установлен в значение О
Заголовок почтового сообшения (header) состоит из последовательности строк тек-
ста, известных как поля заголовка (header Fields). Содержание большинства полей зави-
сит от конкретной реализации той или иной системы, при этом только некоторые поля
являются обязатетьными (mandatory). Одна пустая (незаполненная) строка отделяет за-
головок от тела сообшения. Тело сообщения содержит только текст ASCII, максималь-
ная длина строки нс должна превышать 1000 символов. Само сообщение в целом также
не должно превышать предписанный максимальный ра<мср Каким образом можно пе-
редать сообщение, выходящее за рамки этих правит, разъясняется ниже в данной главе.

В большинст ве систем используются самые разные варианты формата почтовою со-
обшения (один из вариантов представлен в приведенном ниже примере). Формат сооб-
щения SMTP специфицирован в при южении А к RFC 822. В данном документе пред-
ставлено описание такого варианта формата, кбтерйй отвечал бы любым требованиям
пользователей, к какому уровню сложности эти требования не относились бы. В при-
мере. приведенном-ниже содержится сообщение SMTP с 11 полями, которых более чем
достаточно для обеспечения работы шрбой почтовой системы.

Dale

From
Subject
Sender

Reply-То :
To

СС

Comment

In Replv To:

X-Sptcial action:

Message-ID

27 Aug 76 0932 PDT

Ken Davis < Kdavist^This-Host. ihis-nct>

Re: The Syntax in the RFC
Ksecy^Oiher-Host
Sani IrvingtffReg Organization
George Jones <Group®1Sonie-Reg.An-Org>,
Al .Neuman^MAD.Publisher
Important folk
Tom Softwood <Ва15а<я4гее.Коо(>,
“Sam Irving’truOlher-Host;,
Standard Distnbut.on

/mian/davis/people/slandardfii Other- Host,
“<Jones>standard.dist.3”(a!Tops-2ll-Host>;
Sam is away on business He asked me to handle
Hts mail for him. He‘11 be able to provide a more accurate
expl ination when he returns Next week. (Сэм в командировке. Он
попросил меня просма1ривагь его почту. Сэм объяснит все более
подробно, когда возвратится на следующей неделе )
<some.slring(§lD Vl.Group>, Georgeks message

Это поле является примером задаваемою пользователем имени поля.
Этим именем может быть "Особое действие" ("Special-action"),
олнлко оно может бьпь заменено другим, более приоритетным
именем.

423l.b29.Xyzi Whai(oOther-Hosi

(В данном примере представлены следующие поля: Dale -Дата, Subject — Тема. Sender
— Отправитель. Reply 1 о — Кому ответить. То — Кому. Сс — Копия, Comment — Ком-
ментарий, In-Reply-To — В отвст на, X-Speci tl-Aclion — Особое действие X).
Команды SMTP

Команды протокола SMTP (RFC 821) относят почтовую транзакцию или запраши-
ваемую пользователем функцию почтовой системы к тому или иному типу операций. В
состав команды SMT P входит код команды (command code) и ее параметр гargument)
(см. табл. 13.1). Формирование команд SMTP подчиняется некоторым основным пра-
вилам:

•	Каждая команда SMTP состоит из кода команды и параметра.

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

•	Код команды отделяется от параметра не менее чем одним пробелом

•	Поскольку на каждом хосте почтовые адреса могут присваиваться по какому-либо
особому принципу, значение параметров "обратный путь" (reverse path) и "пря-
мой путь” (forward path) чувствителен к выбранному клавиатурному регистру.

•	Поле параметра команды завершается символами возврата каретки и перевода
строки (<CR>, <LF>).

•	Необязательные параметры (optional arguments) заключаются в югирагньм скобки

В таблице 13.1 представлены стандартные коды команд SMTP и их параметры.

Таблица 13.1 Коды команд SMTP

Код команды/ Параметр	Описание
HEL.O <SP» «имя домена» «CRLF»	Идентифицирует SMTP отправителя для SMTP получателя.
MAIL <SP> FROM- обратный путь» «CRLF»	Выполняет достазку почты в почтовый ящик.
RCPT <SP> TO. «прямой путь.- «CRLF»	Идентифицирует получателя дан ных.
DATA «CRLF»	Передает содержимое почтового сообщения.
RSET <CRLF>	Прерывает текущую почтовую транзакцию, вызывая возврат обоих участников транзакции в исходное состояние. Это действие удаляет всю сохраненную информацию об отправителе, получателях, а также передаваемые по' электронной почте данные.
SEND <SP"> FROM: «обратный путь: <CRLF>	Доставляет почту на терминалы
SOMI «SP» FROM «обратный гуть» «CRLF»	Отправляет сообщение не юсредственно на терминал получателя (если он активен) или оставляет сообщение в почтовом ящике.
SAML <SP> FROM «обратный путь» <CRLF>	Отправляет сообщение непос[щдственн! на терминал получателя (если он активен) или оставляет С( общение в почтовом ящике.
VRFV «SP> «строка символов» «CRLF»	Проверяет, соответствует ли последонзтельноспь символов, указанных в качестве параметра имени пользователя. Это действие позволяет клиенту запросить у отправителя проверку правильности адреса получателя i ообшения. не отправляя при этом никаких сообщений адресату (как правило, эта команда используется администратором для устранения возникших в процессе доставки сообщенья проблем).
Код команды Параметр	Описание
EXPN <SP> <строка символов.» <CRLF>	Подтверждает соответствие последовательности символов, указанной в качестве параметра команды, списку рассылки почтового сообщения Это действие раскрывает список рассылки.
HELP <SP> сстрока символовэ <CRLF>	Передает отправителю информацию о поддерживаемых сервером SMTP командах.
NOOP <CRLF>	Нет действий.
QUIT <CRLF>	Передает положительный ответ, после чего закрывает соединение
TURN <CRLF>	Выполняет смену ролей отправителя и получателя с тем, чтобы отправить почту в обратном направлении без закрытия TCP-соединения и создания нового. Отправитель не поддерживает эту команду.
<SP> - символ пробела, <CRLF> - символы возврата каретки и перевода строки.	

Ответы SMTP

Ответы SMTP служат средством подтверждения приема дейтаграмм SMTP, а также
средством передачи уведомлений об ошибках. Ответы SMTP представляют собой трех-
значный цифровой код, за которым с тсдует текст. Формат ответа SMTP выглядит сле-
дуюгцим образом: трехзначный цифровой код, пробел (<SP>), одна строка текста, и
завершается ответ символами перевода строки и возврата каретки (<CRLF>). Содержа-
ние текста отличается в зависимости от кода ответа, а различные комбинации символов
в коде укатывают на назначение ответа.

Клиенты и серверы SMTP используют три цифры, указываемые в кодах ответов
SMTP, чтобы сообщить партнеру по коммуникации о приеме информации, а также о
возникновении ошибки в процессе доставки данных. Трехзначный цифровой код отве-
тов SMTP компонуется по иерархическому принципу. Первая цифра кода представляет
общую информацию, вторая и третья цифры представляют более детальную характери-
стику ответа Такой способ формирования кодов ответов SMTP предоставляет хосту-
получателю достаточно информации для определения типа возникшей ошибки и, соот
ветственно, для выбора подходящею способе) обработки сообщения.

Для того чтобы определить дальнейшие действия, а именно — отбросит ь сообщение
в случае ошибки или передать его пользователю, получателю нет необходимости про-
сматривать сам текст сообщения; для этого достаточно только проанализировать циф-
ры, указанные в коде огветз. В таблице 13.2 представлены значения первой цифры, в
таблице 13 3 — второй. Таблица 13.4 содержит упорядоченный список числовых кодон
ответов SMTP, включая третью цифру.

Таблица 13.2 Значения первой цифры кода ответов SMTP__________________________

Код Значение	__________________

1yz_____Предварительный положительный ответ________ __________________________

2yz_____Ответ с положительном завершении выполнения команды___________________

3yz Ответ о положительном завершении промежуточной операции.
Kot! Значение

4yz Ответ об отрицательном завершении выполнения команды по причине возникновения
ПрОМеЖуТОЧНОИ (ИСПраВИМОЙ) иШИОКИ-

5yz Ответ об отрицательном завершении выполнения команды по причине возникновения
устойчивой (неисправимой) ошибки 

Таблица 13.3 Значения второй цифры кода ответов SMTP

Код	Значение
xOz	Синтаксическая ошипка.
x1z	Ответ на информационный запрос
x2z	Информация о состоянии соединения
x3z	В настоящее время значение не определено
x4z	В настоящее время значение не определено
x5z	Сведения о почтовой системе получателя
Таблица 13.4 Упорядоченный список кодов ответов SMTP	
Лси1	Значение
211	состояние системы или ответ помощи
214	сообщение помощи для пользователя электронной почты
220 <домен>	Служба гитова к работе.
221 --домен»	Служба закрывает канал передачи данных.
250	Подтверждение завершения запрашиваемого действия почтовой службы
251	Пользователь не является локальным Сообщение будет передано по адресу, указанному в параметре «.прямой путь».
354	Начало ввода почтовых данных Завершается <CRLF».
421 «.домен»	Служба недоступна, закрытие канала передачи данных. Этот код может быть указан в качестве ответа на люоую команду, если ,1звестнп, что данное действие почтовой службы по какой-либо причине должно быть приостановлено.
450	Запрашиваемое действие почтовой службы не принято почтовый ящик недоступен (почтовый ящик занят)
451	Аварийное прекращение выполнения запрашиваемого действия из-за локальной ошибки е процессе обработки почтового сообщения
452	Запрашиваемое действие не принято из-за недостаточного объема памяти в системе.
500	Синтаксическая ошибка, команда не поддается распознаванию. В число таких ошибок входит также превышение допустимой длины командной строки
501	Синтаксическая ошибка в параметрах
502	Команда не введена в действие.
503	Некорректная последовательность команд
504	Не указан параметр 'оманды.
550	Запрашиваемое действие не принято: почтовый ящик недоступен (почтовый ящик не найден; нет догтут а к почтовому ящику).
551	Пользователь не является локальным Отправителю рекомендуется отправить сооощение по адресу, указанному в параметре <прямой путь».
Код	Значение 

552	Аварийное прекращение выполнения запрашиваемого действия из-за

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

553	Запрашиваемое действие не принято: имя почтового ящика не разрешено к

_______________использованию_______________________________ ___ __________________

554 В процессе выполнения транзакции произошел сбой.

MIME

Протокол SMTP, созданный в SO-x годах, получил широкое распространение среди
пользователей благодаря своей простоте. Однако во многих случаях запросы пользова-
телей превосходят возможности проюкола SMTP, подобное происходит, когда возни-
кает необходимость в передаче сообщений, которые представлены не в текстовом, а
каком-либо другом формате. К таким сообщениям относятся, например, графические
изображения, сканированные фотографии или видеоклипы. Из простоты протокола
SMTP вытекают следующие ограничения, нала1аемые на передаваемые по электронной
почте сообщения:

•	Сообщение должно состоять только из символов ASCII.

•	Максимальная длина строки не должна превышать 1000 символов.

•	Сообщение нс должно превышать заданный ранее максимальный размер.

Набор многоцелевых расширении электронной почты в сети Интернет (MIME,
Multipurpose Internet Mail Extension) расширяет возможности стандартной службы элек-
тронной почты и, что еще более важно, возможности протокола SMTP Использование
стандарта MIME позволяет осуществлять передачу по электронной почте сообщении с
использованием следующих дополнительных возможностей:

•	Передаче данных с использованием наборов символов, отличных от символов
ASCII.

•	Передача мультимедийных сообщений, содержащих графические образы, звуко-
вые и видео файлы (image, audio, and video messages).

•	Передача множества объектов различных типов в очном сообщении (multiple
objects in a single message).

•	Передача сообщений с использованием различных типов шрифтов (multi-font
messages).

•	Передача сообщении неограниченной длины (messages of unlimited length).

•	Передача бинарных файлов (binary files) — файлов, содержащих двоичные дан-
ные или исполняемые коды.

В 1992 году рабочая группа разработки технических стандартов для сети Интернет
(IETF, Internet Engineering Task Force Working Group) представила описание стандарта
MIME в RFC 1521 и 1522. Стандарт MIME задает способ, по которому файлы присое-
диняются к сообщениям SMTP. Этот способ-расширяет ранее разработанный стандарт
пересылки электронной почты, с указанием в заголовке почтового сообщения допол-
нительных полей. В этих дополнительных полях должно быть представлено описание
типа содержания (content type) последующего-сообщения. а также особая структура тела
сообщения (specific message body organization).

Расширения, определяемые стандартом MIME, предусматривают передачу данных,
не поддерживаемую ранее существующей в сети Интернет почтовой службой. Это дос
тигается посредством применения к передаваемому сообщению одного из методов ко-
дирования, позволяющего представить данные в удобочитаемых символах ASCII с це-
лью формирования стандартного сообщения электронной почты. Расширение
возможностей протокола SM ГР позволяет транспортировать сообщения новых типов в
пункт назначения. В RFC 1652 представлено описание расширения для передачи неза-
кодированного соответствующим образом сообщения MIME в 8-разрядном формате.
Имея в своем распоряжении соответствующее расширение получатель может заявить о
поддержке передачи тех частей тела сообщения, кот зрые представлены в 8-разрядном
формате Получатель может также выдать запрос на передачу отдельного сообщения в
8 -разрядном формате Формат заголовка сообщения MIME определен в RFC 822.

Резюме

Упрощенный протокол пересылки почты (SMTP, Simple Mail Transfer Protocol), фун-
кционирующий в рамках стека протоколов TCP/IP, регламентирует процесс обмена
сообщениями в сети Интернет по электронной почте, а также связанные с этим дей-
ствия клиента и почтового сервера. Протокол SMTP начинает свою раоор' после уста-
новления клиентом TCP-соединения с сервером ч< рез общеизвестный порт 25. После
этого клиент и сервер испотьзуют соединение, установленное между программными
модулями SMTP клиента и сервера, в качестве канала свя зи. Клиент отправляет почту
серверу посредством выполнения серии транзакций "команда/ответ”, сформированной
самым тщательным образом.

Модель Х.400 обеспечивает взаимный обмен электронной почтой между агентами
пользователя (User Agents) и агентами передачи сообщений (Message Transfer Agents).
Агенты пользователей (UA), которые используются также и в модели пересылки почты
на основе протокола SMTP, обеспечивают необходимыми средствами немедленное вза-
имодействие с пользователем и доставку адресованных ему сообщений. С помощью UA
пользователь формирует, регистрирует в почтовой службе для дальнейшей пересылки,
а также получает сообщения электронной почты. Агенты передачи сообщении (МТА),
аналогично соответствующим npoi раммам SMTP, осуществляют обмен почтой гак же,
как и сам процесс коммуникации между клиентом и сервером, черьз ASCII NVT. Стан-
aapi Х.400 представляет ряд протоколов, назначение которых — адресация почтовых
сообщений, передаваемых между почтовыми серверами.

R формате SMTP почтовое сообщение состоит из заголовка, тела сообщения и кон-
верта. В состав конверта входит SMTP-адрес отправителя и получателя. Заголовок со-
общения состоит из совокупности текстовых строк, иначе называв мых полями заюлов-
ка. Состав полей заголовка зависит от соглашений, принятых в данной системе. Со)ласно
протоколу SMTP тело сообщения состоит из ограниченного по количеству символов
текста ASCII. Однако стандарт многоцелевых расширений электронной почты в сети
Интернет (MIME Multipurpose Internet Mail Extension) позволяет обойти эти правила и
включать в передаваемые по электронной почте сообшения документы, представленные
не в формате ASCII (звуковые и видео файлы, а также графические образы).

Вопросы для повторения

1.	Какова основная функция протокола SMTP?

2.	Каким образом функционируют агенты пользователей (User Agents, UA) в модели
передачи почтовых сообщений протокола SMTP9

3.	Чем отличается собственно протокол SMTP от агента пользователя (UA)?

4.	Назовите ограничения, налагаемые протоколом SMTP на передаваемые сообщения.

5.	Перечислите правила формирования команд протокола SMTP.

6.	Объясните, почему ответы SMTP играют столь важную роль в беспроблемной реа-
лизации почтовых транзакций.

7.	Почему ответ SMTP имеет такое большое значение для пользователя?

8.	Объясните, каким образом расширения Ml ML принимают участие в передаче по-
чтовых сообщений посредством протокола SMTP
Глава 14

Разрешение имен

В данной главе рассматриваются следующие темы:

•	Именование компьютеров (Naming Computers)

•	Пространство имен (Namespace)

•	Делегирование полномочий DNS (DNS Delegation of Authority)

•	Кэширование (Caching)

•	Формат сообщений сервера доменных имен (Domain Server Message
Format)

•	Имена доменов сети Интернет (Internet Domain Names) и их типы

Назначение процедуры разрешения имен

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

Принцип адресации компьютеров в сети можно пронл щтстрировать на примере ра-
боты телефонной сети. Представим себе, что каждый компьютер — это телефон Теле-
фонный аппарат не может распознавать имя абонента, поскольку это имя состоит из
букв, и идентифицирует самою абонента, а не номер аппарата, с которого он разгова-
ривает Если ваша мама желает позвонить вам, опа не может престо назвать ваше имя в
трубку. Имени недостаточно, чтобы определи!ь месюположение пункт назначения или
установить телефонное соединение
Чтобы связаться с вами по телефону, вашей маме необходимо зна1ь ваш телефон-
ным номер. Телефонный номер состоит из цифр, присвоенных в соответствии е иерар-
хической схемой, в которой каждая цифра на определимой позиции идентифицирует
область, город, дом и сам телефонный аппарат. Коммутаторы, находящиеся на станци-
ях абонентской телефонной сети общею пользования, используют отображаемую в те-
лефонном номере информацию для определения местоположения требуемою абонента
и установления телефонного соединения с ею аппаратом.

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

Сразу же после установления пути к пункту назначения выполняется непосредствен-
ная доставка данных от отправителя к получате по по его адресх нижнею уровня (МАС-
адресу). По существу, возможность применения в описанной выше процедуре имен
вместо адресов важна не для компьютеров, а для пользователей. Котда пользователь
предпринимает попытку установить взаимодействие с тем или иным устройством сети,
использ)я при этом имя. эго влечет за собой преобразование имени в логический адрес
устройства на сетевом уровне Сетевой адрес, в свою очередь, подлежит трансляции в
адрсе канальною уровня (физический адрес), необходимый на завершающем этапе до-
ставки данных в пределах локальной по отношению к пункту назначения сети Все эти
операции должны быть выполнены еще до начала передачи данных.

Приложения, функционирующие на основе стека протоколов TCP/IP, используют
службу именования доменов DNS (Domain Name Service) с гой же целью, с которой
используется оператор телефонной связи в телефонной сеги. Служба DNS возвращает
IP-адрес взамен имени, предоставленного ему хостом-отправителем или получателем
сетевых пакетов и позволяет значительно сократить размер пространства имен
(namespace), что существенно облегчает поиск необходимого устройства по ею имени.

Пространство имен

В настоящее время Интернет состоит из миллионов хостов, каждый из которых имеет
свой IP-адрес и имя (если оно сконфигурировано) Чтобы связаться с необходимым
хостом, достаточно использовать имя хоста вместо ею IP-адреса. С другой стороны, для
отображения имени хоста в его адрес необходим либо сервер DNS (аналотчно опера-
тору телефонной связи), либо .локальная таблица разрешения адресов.

Серверы DNS (серверы имен доменов) предоставляют в распоряжение пользовате-
лей поисковые службы отображения имени хоста в его IP-адрес (name — lo IP-address
lookup services), функции которых очень похожи на функции коммутаторов телефон-
ной станнин. Например, если вы xoinre заказать пиццу в пиццерии Серджио, вполне
вероятно, чго вы знаете только ее название, а не телефонный номер. В таком случае вы
можете предпринять одно из следующих действии:

•	Найти номер в своем телефонном справочнике (аналог локальной таблицы раз-
решения имен)

•	Узнать нужный номер, позвонив в справочную службу (аналог сервера DNS)
Применение любого из указанных выше методов нредпола1ает определение номера
по имени абонента перед набором телефонного номера, который, в конечном итоге,
завершится установлением телефонного соединения и собственно достижением требуе-
мой цели: заказом пиццы' Каким же образом можно отслеживать соответствие между
всеми этими универсальными именами и IP-адресами? На заре формирования сетевых
комплексов, когда в состав сети входило всего несколько сотен хостов, это было доста-
точно просто Вся информация хранилась в едином списке, имеющем форму текстово
го файла, иначе именуемого пространством имен (namespace). Специалисты сетевого ин-
формационного центра (NIC. Network Information Center) следили за своевэеменным
внесением в этот список изменений, связанных с включением в состав сети или исклю-
чением из него тех или иных хостов. Сетевой информационный центр отвечал за то,
чтобы не допускать использования неприличных имен, а также таких имен, которые
можно было бы перепутать с уже имеющимися.

Чтобы воспользоваться услугами сети Интернет в качестве ее равноправного участ-
ника, необходимо было связаться с центром NIC, получить копию списка и направить
его в адрес всех локальных шлюзов Интернета, занятых в процессе разрешения необхо-
димых адресов. Каждый раз, когда происходило изменение имени или IP-адреса (в слу-
чае подключения к сети Интернет или исключения из нее того или иного хоста) в спи-
сок имен и соответствующих им 1Р адресов вносились соответствующие изменения, а
пользователю приходилось заниматься получением очередной копии списка имен. Об-
служивание такого большого списка и своевременное внесение в него изменений тре-
бовало существенных затрат локальных вычислительных ресурсов, что оказалось весь-
ма нерациональным. Все указанные выше причины привели к разработке и реализации
специальной службы именования доменов (DNS, Domain Name Service), призванной за-
менить существовавшую ранее упрощенную схему разрешения имен.

Представьте себе пространство имен, поддерживаемое NIC, как адресную или теле-
фонную книгу. Вы сами принимаете решение, чьи номера записать в эту книгу, а чьи
вычеркнуть. Может также возникнуть необходимость как-то дополнительно обозначить
в вашем списке людей, чьи имена совпадают. Например, если вам необходимо записать
номера двух знакомых с одинаковым именем Кейти, вы можете либо присвоить одной
из них псевдоним Кэт, либо записать их обеих по фамилиям — Стивенс и Поллок. Вы
могли бы также назвать их Кейти! и Кейти2 (в том порядке, в котором вы с ними по-
знакомились) либо записать их номера по местам их работы. Можно придумать множе-
ство различных комбинаций независимо от того, какая именно схема именования из-
брана.

ПРИМЕЧАНИЕ

Следует обратить внимание на то, что служба именования доменов DNS позволяет уст-
ранить необходимость в формировании единого пространства имен на каждом локаль-
ном компьютере, поскольку DNS самостоятельно осуществляет поиск IP-адреса для каж-
дого имени домена и наоборот.

В приведенном выше примере и файл с именами, и адресная (телефонная) книга
имеют один и тот же недостаток отсутствие четкости представления информации и
простоты в использовании Поскольку вы являетесь единственным пользователем дан-
ного списка, только вы можете расшифровать все указанные в списке личные псевдо-
нимы, необычные символы или имена без фамилий. Вряд ли другой человек смог бы
без проблем найти нужные ем\ телефонные номера в вашем списке. Этот человек не
знает, что вы записали номер Кейти Стивенс под псевдонимом Кэт, а номер Кейти
Поллок под именем Кейти. Дело может закончиться тем, что этот человек позвонит по
номеру Кейти Поллок, в то время как ему нужно связаться с Кеити Стивенс. Болес того,
с течением времени в нашей телефонной книге появляется все больше имен, номеров,
псевдонимов, номеров семейных пар или деловых партнеров. Процесс поиска телефон-
ных номеров просто по именам становится все более и более сложным.

Аналогичные трудности возникают в процессе поиска имен и соответствующих им
IP-адресов в локальной таблице имен, хранящейся на хосте. Каждое имя в подобном
списке состоит из последовательности символов, не имеющей никакой структуры. До
тех пор пока компьютер центра NIC обслуживал небольшой список имен, пользователи
сети Интернет, число которых также было тогда небольшим, понимали эти имена и мотли
с ними работать По мере увеличения этого списка пользоваться им становилось все
труднее и труднее; при этом возникли следмошие проблемы:

•	Увеличение громоздкости списка имен по мере его расширения.

•	Усложнение процесса внесения изменений из-за перегрузки, связанной с обслу-
живанием слишком большого списка имен.

•	Неэффективность и высокая стоимость обслуживания слишком объемного спис-
ка.

Аналогично тому, как увеличивается количество знакомых вам людей, расширяется
и Интернет. По мере развития сети Интернет и регистрации все новых и новых компь-
ютеров и имен доменов в сети специалистам сетевого информационного центра NIC
становилось все труднее избегать конфликтных ситуаций, связанных с использованием
существующих имен (точно так же, как и в случае с нашей адресной книгой).

Список необходимых вам телефонных номеров, а также связанной с этими номера-
ми информации (деловые контакты, друзья, члены семьи, доктора и т.д.), возрастает
ежедневно; поддержание этого списка (внесение новых номеров и их систематизация)
может стать обременительным. Представьте себе ту нагрузку, которая выпадает на об-
служивающий персонал NIC в связи с необходимостью систематизации используемых в
Интернете имен, коша в сети ежедневно регистрируются тысячи новых сайтов, каждо-
му из которых, в свою очередь, подчиняется множество отдельных компьютеров и ра-
бочих станции. Подключение к сети каждою нового персонального компьютера требо-
вало одобрения сетевого информационного центра и внесения соответствующих
изменений в список имен.

При существующей тенденции к распространению Интернета по всей планете с ог-
ромным количеством пользователей реализация подобной схемы именования была бы
крайне сложной, неэффективной и дорогостоящей. В среде Интернет с прежней орга-
низацией регистрация имени каждого нового компьютера влекла бы за собой создание
и обслуживание нового списка имен на каждом сайте, что было бы напрасной трагой
времени и денег.
Делегирование полномочий DNS

Если бы вы отвечали за организацию какого-либо бизнеса с постоянно возрастаю-
щим количеством полномочий, вы передали бы часть этих полномочий другим отделам,
чтобы облегчить управление столь сложным делом. Система именования доменов (DNS,
Domain Naming System) организована по тому же принципу: она функционирует как
большая корпорация с хорошо налаженной разветвленной системой управления. При
дальнейшем разрастании корпорации ее руководители разделяют новые полномочия
между различными отделами, чтобы снизить общую рабочую нагрузку и поддерживать
действенность всей структуры. Каждый руководитель может для этого нанимать и уволь-
нять работников, распределять обязанности и определять рамки полномочий тех или
иных должностных лиц

Служба DNS функционирует аналоычно. Схема именования в DNS имеет древовид-
ную иерархическую структуру (hierarchical tree), в которой сетевои информационный
центр регулирует только процесс присвоения доменных имен верхнего уровня (lop-level
domains), а другие полномочия передает серверам доменных имен (name servers). В этом
и заключается деле, и рован не полномочии DNS (DNS delegation of authority). В таблице
14.1 представлены корневые домены (root domains), и m домены верхнею уровня.

Таблица 14.1 Домены высшего уровня____________________________________________

Домен Назначение	_________ _________ _ _______

MIL Военные организации 

GOV________Правительственные организации______________________________________

EDU	Учебные заведения_____ _____________________________ ______________

СОМ Коммерческие организации

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

центры (NIC) и сетевые операционные центры (Network Operations Center -NOC)

ORG________Некоммерческие организации_________________________________________

CON	Двухсимвольный код страны (например, код US для США, UK — для

Великобритании, и г.д.)

М? РЕКОМЕНДУЕМЫЕ ДОМЕННЫЕ ИМЕНА ВЕРХНЕГО УРОВНЯ

Семь указанных выше трехсимвольных доменов верхнегс уровня используются в каче-
стве групповых доменов. Двухсимвольные домены верхнего уровня (или домен CON) —
это коды разных стран. На рассмотрение пользователей предлагается также ряд других
доменных имен верхнего уровня, в число которых входят следующие имена, -firm, .shop,
.web, .arts, .rec. .info, .nom, .aero, .biz, -coop, .info, .museum, .name and .pro.

Возможно, вам известен домен ,tv, соответствующий коду страны, расположенной
на небольшом шхоокеанском острове Тувалу (Tuvalu). В настоящее время проводится
кампания по перерегистрации этого домена в качестве домена телевизионных органи-
заций. Для получения дополнительной информации по этому вопросу обращайтесь на
сайт htlp;//www.icann.org.lids.

В процессе трансляции имен доменов в соответствующие им IP-адреса серверы имен
предоставляют в распоряжение пользователей записи о ресурсах (RR, resource records).
Эти записи представляю! собои элементы базы данных DNS, посредством которых вы-
подияется разрешение имен, другими словами. определение IP-адреса но имени доме-
на и наоборот Функции сервера имен aii.uioiичны функциям секретаря в офисе какой-
либо компании. Если вам необходимо записаться к врачу, вы не звоните тлявному вра-
чу больнины, а ра довариваете непосредственно с секретарем в приемной. Серверы имен
работают по такому же принципу, обеспечивая максимальную эффективность и удоб-
ство в процессе трансляции имен доменов в IP-адреса. Подобный принцип функцио-
нирования серверов доменных имен позволяет выполня ть разрешение имен доменов и
избежать при этом напрасной траты времени и сил на перемещение по всей иерархи-
ческой структуре DNS.

РИСУНОК 14.1 Организация работы ONS по иерархическому принципу позволяет делегировать на
нижние уровни полномочия l).\'S по присвоению имен доменов и их трансляции в IP-adpeca.

Сетевой информационный центр (NIC), будучи главным административным орга-
ном DNS, обе '(ужинает верхний сектор иерархического дерена (домены верхнего уров-
ня). Все пространство имен состоит из отдельных зон (zones), каждая из которых пред-
ставляет собой автономное поддерево базы данных DNS (self-governing sub-lree). Зоны
второго уровня (second-level zones), в свою очередь, могут подразделяться на еще более
мелки зоны Например, если ваш сайг обслуживает ошн из университетов, каждая зона
может представлять факультеты лого университета. Если наш сайт действует в преде-
лах коммерческого предприятия, каждая зона может представлять ею подразделения,
например, филиал компании пли отдел, отвечающий за распределение функций между
подразделениями компании и ее работниками (отдел кадров)

По рис. 14.1 можно определить, что адрес сайта Университета Сан-Франииско выг-
ляди! следующим образом: ucsf.edu. Такое имя позволяет отличить этот сайт от сайтов
других учебных заведений, например. Государственного университета в Сан-Францис-
ко (sfsu.edu) Указание еше одною фра! мента имени нозволяез выделить Интернет-ад-
реса. представляющие отдельные кафедры (например, кафедру финансовой помощи
Университета Сан Франциско прсчставляет адрес fin ucsf.edu). Бозее подробно иерар-
хический принцип ор1анизании имен доменов Интернет (internet domain names) рас-
сматривается ниже в данной глине.
Для функционирования каждого отдела какою либо учреждения требуются служа-
щие; аналогично в каждой зоне требуется одно иди несколько обслуживающих ее уст-
ройств. Такими устройствами являются специальные серверы, называемые серверами
доменных имен (name servers). Для каждой зоны требуется наличие одного основного
сервера имен (primary name server) и одного или более вспомогательных серверов имен
(secondary name servers). Основной сервер имен загруж»ет информацию из файлов, хра-
нящихся на дисках. Вспомозательный сервер имен получает информацию ог основного
сервера Так же, как и в случае с обычными служащими, эти серверы должны иметь воз-
можность лез'зствовать самостоятельно, а также иметь возможность ликвидировать ошиб-
ки но мере их возникновения, чтобы эти ошибки не повлияли на службы присвоения
доменных имен в соотвезствуюших зонах

Для того чтобы вк почить имя нового хоста в состав той или иной зоны, необходимо
ввести требуемую информацию (или. по крайней мере, имя и IP-адрес) в хранящимся
на диске файл той системы, в рамках которой функционирует основной сервер. Для
основного сервера это действие является сигналом к началу повторною считывания
конфигурационных файлов. Каждые гри часа вспомогательный сервер отсылает в адрес
основного сервера запрос на предиставлеззие ему новой информации Если вспомога-
тельный файл обнаруживает новые данные, он получает эту информацию от основного
сервера посредством зональной процедуры пересылки данных (zone transfer)

С другой стороны, названные выше серверы не всегда располагают запрашиваемой
у них информацией (в этом случае считается, что сервер не имеет полномочизз на пре-
доставление информации такого рода, следовательно, эго — нсполномочный сервер, not
authoritative server).. Когда складывается подобная сзегеация, сервер устанавливает связь
с другим сервером имен и передает ему запрос на разрешение имен (name resolution
i-equest). рассчитывая на го, что этот сервер либо сам выполнит разрешение имени, либо
передаст запрос следующем*' серверу имен. В конце концов, запрос на р ззрешение имени
аос гиз нет того сервера, который деиствизельно располагает нужной информацией (та-
кой сервер является полномочным сервером, authoritative server).

Серверам доменных имен нет необхоцимосзи знать, как они могут связаться с дру-
гими серверами. Но, с друзой стороны, серверы имен обязательно должны иметь в сво-
ем распоряжениз! 1Р-адреса корневых серверов имен (root name servers). Так же, как и в
любом офисе, вам не нужно знать абсозюгно все номера тетефонон, чтобы получить
требуемую информацию. Вам достаточно знать толькс номер, нескольких надежных
источников, от которых вы можете поручить необходимые вам сведения. Корневые сер
веры работают ззо тому же принципу, что и а^гминистрвторы справочных телефонных
служб: они раеззолазают информацией об именах и IP-адресах каждого полномочного
сервера, обслуживающею домены второго уровня. После того как полномочный сервер
выдает запрос в адрес корневою сервера, корневой сервер переадресует этот запрос
другому полномочному серверу. Такая процедура формирования цепочки взаимных
ссылок между серверами позволяет передавать запрос по всему пространству имен до
тех пор. пока не будет найден сервер, который знает искомое имя и можез выполнит!,
процедуру его разрешения (этот сервер рассматривается как сервер, имеющий полно-
мочия на разрешение данного имензт). Результатом выполнения процедуры разрешения
имени является передача клиенту, отправившему запрос, соответствующею IP-адреса.
ПОЛНОМОЧНЫЕ И НЕПОЛНОМОЧНЫЕ СЕРВЕРЫ

Серверы имен считаются полномочными (authoritative), когда они имеют в своем распо-
ряжении искомое имя и могут выполнить процедуру его разрешения (другими словами,
процедуру определения по имени хоста соответствующего ему IP-адреса). Когда серве-
ры имен не имеют в своем распоряжении искомого имени (другими словами являются
неполномочными, not authoritative), они передают запрос другому серверу, рассчитывая
на то, что он окажется полномочным.

Служба DNS имеет возможность выполнять трансляцию имени домена в адрес сер-
вера обмена почтой (mail exchanger). DNS позволяет также хранить любой список иерар-
хических имен, необходимых пользователю на время работы с соответствующими до-
менами. Этой характеристикой службы DNS можно воспользоваться для удовлетворения
нужд той или иной компании. Например, можно хранить список предоставляемых ва-
шей фирмой услуг вместе с номерами телефонов, по которым покупатели имели бы воз-
можность выяснить дополнительную информацию стой или иной услуге. С другой сто-
роны, можно было бы хранить список товаров вместе с именами и адресами поставщиков,
продающих эти товары.

Имена доменов Интернета

Первое, что привлекает внимание при взгляде на доменное имя, — это то, что оно
состоит из ряда аббревиатур, разделенных точками. Если вы часто пользуетесь услуга-
ми сети Интернет либо вы сами имеете сайт в своем подчинении, Toiaa вы точно знае-
те, что эти аббревиатуры организованы именно по иерархическому принципу далеко не
случайно. Само расположение аббревиатур в доменном имени имеет определенную цель.
Представьте себе 10-значный телефонный номер. Вы знаете, что первые три цифры
всегда представляют собой код территориальной единицы, поскольку этот код все!да
указывается первым. Если вы не наберете первым этот код, вы не сможете связаться с
требуемым абонентом.

Служба DNS opt анизовываст иерархическую схему именования таким образом, что
пользователь имеет возможность быстро связаться с сервером и найти нужный Web-сайт
по его адресу. Рассмотрим схему, согласно которой DNS разделяет каждое доменное имя
на составные части. Каждый ccimcht доменного имени, соответствующий сайту или
группе сайтов, представляет собой так называемую метку (label) или домен (domain),
например — Fre.devry.edu.

DNS делит доменное имя на три домена. Чем ниже уровень домена, тем более де-
тальные сведения о хосте он идентифицирует. В приведенном выше примере домен
самого низкого уровня — Fredevry.edu, доменное имя для сайта университетского го-
родка в Фримонте (Fremont) Домен devry.edu — это домен второго уровня, соответствую-
щий сайту университета Деври (DeVry) в Фримонте. Домен "edu", используемый учебными
заведениями. — это домен верхнего уровня. Представьте себе, насколько громоздким
было бы все имя. если бы использовались полные названия, а не аббревиатуры. DNS
использует проиллюстрированный выше принцип сокращения имен, чтобы сделать их
более легкими для восприятия, систематизации и набора на клавиатуре.

При разработке системы доменов допускается произвольный выбор меток для каж-
дом части иерархической структуры доменного имени, поскольку DNS специфицирует
только форму имени, а не его содержание. В то же время, большинством пользователей
чаше всего применяются метки, принятые в официальной системе именования доме-
нов Интернета Несмотря на то, что эта система именования устанавливает определен-
ный порядок, она делает ло с учетом всех возможных условий и предлагает максималь-
ную 1ибкость. Такая система именования принимает все домены и позволяет избрать
любой способ именования: по территориальному или по административному принци-
пу. В дополнение ко всему сказанному выше стоит отметить, что нет необходимости
менять имена при подключении к сети Интернет посредством стека протоколов ТСР/
IP.

Запросы на разрешение имен и таблицы
отображения имен в IP-адреса

Для преобразования доменного имени в соогве1ствующин ему IP-адрес (и наоборот)
служба DNS испо |ьзует как механизм формирования запросов (queries), так и механизм
определения 1Р-адресон или доменных имен по таблицам. содержащим пары "домен-
ное имя — IP адрес" (mappings). Для реализации процедуры разрешения IP-адресов или
доменных имен DNS хранит соответствующую информацию на диске или кэширует ее
в буфере ОЗУ. Процедура кэширования рассматривается ниже в данной главе. Для тою
чтобы понять изложенный ниже материал, касающийся службы DNS. необходимо хо-
рошо усвоить смысл следующих терминов:

•	Термины "отображение" (mapping) и "разрешение” (resolving) означают определе-
ние IP адреса хоста по его доменному имени

•	Термин "обратное отображение" (inverse mapping) предполагает определение до-
менного имени хоста по cio IP-адресу.

•	Термин "обратный запрос" (inverse quiery) идентифицирует команду, используе-
мую для вызова процедуры обратного отображения. Как правило, обратные зап-
росы требуют от сервера действии, направленных на поиск имени по всему мно-
жеству существующих серверов имен; но этой причине обратные запросы
применяются достаточно редко

Кэширование

Сервер имен, подобно квалифицированному офисному работнику, сохраняет все ин-
формационные запросы, а также соответствия между доменными именами и IP-адреса-
ми либо посредством занесения информации в хранящийся на лиске файл, либо посред-
ством кэширования (caching) этой информации (размещения ее в кэше,
быстродействующей буферной памяти ОЗУ). Такой способ хранения информации по-
зволяет серверу отвечать на запросы о предоставлении новейших сведений, а также
получать в свое распоряжение обновленные данные, необходимые для успешною вы-
полнения процедуры разрешения имен. Кэширование, которому свойственно высокое
быстродействие, снижает также уровень затрат на разрешение имен, не являющихся ло-
кальными по отношению к данному серверу. Процедура преобразования доменных имен
в IP-алреса с использованием хранящейся в кэше информации состоит из следующих

этапов:
I Когда сервер получает запрос на разрешение того или иною имени, он проверяет,
входит ли это имя в ею зону (если да — сервер наделен полномочиями на разреше-
ние этого имени, другими словами. он является полномочным сервером в данной
зоне).

2	В противном случае (если сервер не находит имени в локальной таблице разреше-
ния имен), сервер проверяет на наличие этою имени кэш, в котором информация
хранится всего несколько дней.

3.	Если сервер обнаруживает необходимую информацию в кэше, он сообщает об этом
клиенту.

4.	При передаче информации клиенту сервер сообщает, что эта информация почучена
и локальном режиме или от другого уполномоченною сервера (не из локальной таб-
лицы данною сервера). Сервер предоставляет клиенту доменное имя и соответству-
ющий ему 1Р-адрес.

5.	Информация, предоставляемая сервером, может оказался устаревшей. Если при пе-
редаче данных важна скорость, можно использовать те данные, которые предос-
тавляет сервер. Если ошибка при передаче данных недопустима, необходимо свя-
заться с полномочным сервером и проверить достоверность сведении, полученных
в результате выполнения процедуры разрешения имен.

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

Достаточно часто складывается ситуация, когда сервер не может найти требуемою
имени лаже после проверки своею кэша. В таком случае сервер сам становится клиен-
том (действуя в качестве посредника по отношению к хосту-отправителю) и использует
сообщения, сформированные согласно специфицированному соответствующим RFC-
формату. для ошравки в адрес полномочного сервера совокупности запросов в одном
сообщении. Каждое такое сообщение включав! в себя следующую информацию:

•	Доменное имя. подлежащее разрешению (domain name)

•	Класс, или семейство протоколов, в системе которых работает данное доменное
имя (protocol class)

•	Тип доменного имени (domain name type)

Сервер, получивший запрос на разрешение имени, отвечает на этот запрос ответом
(сведения, представленные в ответе, содержатся в различных полях сообщения) Если
сервер не имеет в своем распоряжении информации, касающейся разрешения данною
имени, он передает в своем ответе IP-адреса серверов, которые могут располагать тре-
буемой информацией. На рис. 14.2 показан пример формата сообщения DNS. Описа-
ние полей сообщения DNS представлено после рисунка.

Поле идентификатора (ID)

Поле идентификатора (ID), имеющее длину 16 битов, предназначено для сопостав-
ления запросов и 01 ветов. Клиент устанавливает значение идентификатора в запросе, а
сервер возвращает это значение в своем ответе. Совпадение идентификаторов в полях
ID запроса и ответа означает, что ответ соответствует данному запросу.
РИСУНОК 14.2

Сообщение DNS состоит
из заголовка, имеющего
фиксированную длину 12
байт, и четырех полей
переменной длины.

Идентификатор	Флаг запросе или ответа	Тип операции (запроса или ответа)	Флаги	Код статуса ответа
Количество записей в сещии запроса (QDCCUM)	Количество затеей в секции ответа (ANCOUNT)			
Количество записей в секции полномочны* серверов NS (NSCOUNT)	Колтнество записей в секции дополнительной информации (ARCOUNT)			
С«ция ае.ipoct				
Секция ответов				
Секция полномочных серверов NS				
Секция дополнительной информации				

Поле флага запроса или ответа (QR)

Значение, устанавливаемое в поле QR (1 бит) указывает на то, является ли переда-
ваемое сообщение запросом или ответом. Значение 0 (QR=0) идежифицирует запрос,
значение I (QR=1) идентифицирует ответ.

Поле типа операции (запроса или ответа)

В поле типа операции (Opcode), имеющем длину 4 бита, указываются значения, пред-
ставляющие собой дальнейшую спецификацию запросов или ответов. В таблице 14.2
приведены различные коды типов операций DNS и их значения.

Таблица 14.2 Значения, устанавливаемые в поле Opcode________________________

Код________Значение___________________________________________________

О__________Стандартный запрос (QUERY)_______________________________________

I____ _____Обратный запрос (IQUERY)_________________________________________

2__________Запрос о статуса севера (STATUS)_________________________________

3	15 Коды зарезервированы

Поле флагов

В поле флагов (Flags), имеющем длину 7 битов, представлено дальнейшее описание
параметров сообшения DNS. Поле флагов, в свою очередь, подразделяется на пять сле-
дующих секций (см. рис. 14.3):

•	АА (authoritative answer) — флаг полномочного ответа, бит 5. Значением, устанав-
ливаемым в данном поле, отмечается полномочный ответ; из этого следует, что
данный сервер имен наделен полномочиями на разрешение доменного имени,
указанного в запросе.

•	ТС (truncation) — флаг усечения ответа, бит 6. Значением, устанавливаемым в дан-
ном поле, отмечается усеченный ответ, что означает следующее: длина ответа пре-
высила 512 байтов, следовательно, ответ усечен и передаются только его первые
512 байтов.
•	RD (recursion desired) — флаг рекурсивной обработки запросов (рекурсивная об-
работка желательна). бит 7. Устанавливаемый в запросе и возвращаемый в отве-
те, этот флат (в случае его установки) предписывает серверу доменных имен са-
мостоятельно (без ссылок Tia другие серверы) обрабатывать запрос; такой запрос
называется рекурсивным запросом (recursive query). С другой стороны, если зна-
чение данною бига не установлено, а также не установлен флаг полномочного
ответа (ДА, authoritative answer), сервер имен, которому был направлен запрос на
разрешение имен, возвращает в своем ответе список всех известных ему серве-
ров имен, имеющих в своем распоряжении ответ на данный запрос; запрос тако-
го типа является итеративным (iterative query).

•	RA (recursion available) — флаг поддержки рекурсивной обработки запроса (ре-
курсивная обработка возможна), бит 8. Флагом RA отмечается наличие в распо-
ряжении сервера имен такой возможное!!!, как поддержка рекурсивной обработ-
ки запросов Если сервер поддерживает такой тип обработки, этот бит
устанавливается в значение 1. Рекурсивную обработку запросов поддерживает
большинство серверов доменных имен.

•	Zero — ноль: биты 9—11 всегда установлены в значение 0.

На рис 14.3, кроме поля флаюв (Flags), изображены также поля QR, Opcode и Rcode,
а также их взаимосвязь с полем флагов.

QR	opcode	АА	ТС	RD	RA	(zero)	rcode

14	11113	4

РИСУНОК 14.3 Следует обратить внимание на соотношение других no ieu с полем флагов,
ралде итным на отдельные секции.

Поле кода ответа

В поле кода ответа (Rcode). длина которого 4 бита, указывается код ответа (response
code), значения, указываемые н этом поле, дополняют параметры, устанавливаемые в
битах 0—11. В таблице 14.3 представлены различные значения, устанавливаемые в поле
кода ответа (Rcode).

Таблица 14.3 Значения, устанавливаемые в поле Rcode

Номер бита	Значение
0	Ошибок нет
1	Ошибка в формате запроса
2	Отказ в работе сервера
3	Имя не существует
1	Не реализован
1	Отказ в выполнении процедуры разрешения
1	Бит зарезервирован

Поле Rcode завершает начинающееся с поля QR перечисление параметров (биты 0—15)
сообщения DNS. В таблице 14.4 представлено краткое описание различных битов, в
которых устанавливаются параметры сообщения DNS Целесообразно рассматривать эту таблицу в сочетании с рис.14.2 (Формат сообщений DNS).  Таблица 14.4 Значения битов поля параметров сообщения DN5	
Hewep бита	Значение
0	Операция:  0 запрос  1 ответ
1 —4	Тип запроса:
0 стандартный запрос	
1 обратный запрос	
2 запрос о с татусе сервера	
3-15 зарезервировано	
5	Устанавливается в случае, дели отве' является уполномоченным (флаг ДА)
6	Устанавливается в случае усечения сообщения (флаг ТС)
7	Устанавливается в случае необходимости рекурсивной и Зработки запросов (флаг RD)
8	Устанавливается в случае, если сервер п< одерживает рекурсивную обработку запрссов (флаг RA)
9-11	Биты зарезервированы (установлены в 0)
12-15	Тип ответа
0 Ошибок нет	
1 Ошибка в (Формате запроса	
2 Отказ в работе сервера	
3 Имя не ‘'уществует	
4 Не реализован	
5 Отказ в выполнении процедуры раз[ ешения	
6-15 Биты зарезервированы	

Заголовки запросов и ответов

От содержания следующих четырех нолей (QDCOUNT, ANCOUNT. NSCOLNT и
ARCOUNT) зависит нерешенная длина соответствующею этим нолям рдздела сообще-
ния DNS Все четыре тюля могуч* иметь длину 16 бигов; содержимое каждого из полей
та висит от содержимого друт их нот.ей. 3 таблице 14.5 представлены указанные выше поля
и их зн пения.

Таблица 14.5 Заключительные поля сообщения DNS

Hole	Значение
QDCOUNT	Количестве записей в секции запроса
ANCOUNT	Количество записей о ресурсах jRR) в секции ответа
NSCOUNT	Количество записей о ресурсах (RR) в секции уполномоченных серверов
ARCOUNT	Количество записей о ре< урсах (RR) в секции дополнительных записей

Количество секции является величиной сймоопредсяяемой. Клиент заполняет толь-
ко секцию кочнчества запросов (QIX'OL'NT) сообщения DNS Как правило, в поте
количества запросов (QDCOUNT) устанавливается значение I, а в оставшихся трех но-
лях — значение 0. Соответственно значение, установленное в поле количества ответов
(ANCOUNT), равно I, н то время как оставшиеся два поля имеют значения 0. Наиболее
распространенной является ситуация, когда в поле количества запросов (QDCOUNT)
указывается только один запрос На рис. 14.4 показан формат сообшения DNS, содер
жашего запрос.

РИСУНОК 14 4

Формат сообщения DNS.
содержащего запрос на
разрешение доменного
имени.

доменное имя, подлежащее разрешению (Query name)

тип запроса (Query type)	класс запроса (Query dass)

Фрагмент заголовка сообщения DNS, соответствующий запросу, состош из трех ча
стей: доменное имя, подлежащее разрешению (Query name), тип запроса (Query type) и
класс запроса (Query class). Тип запроса указывай! на то, какое имя требует трансляции
в физическим адрес, имя компьютера или почтовый адрес хоста. В качестве ответа на
запрос выдается сообщение, содержащее соответствующую запись базы данных DNS
(запись о ресурсах. RR). Каждый ответ можно отнести к одному из типов ответов, ко-
торые рассматриваются ниже в данной главе. Значение, указываемое в поле класса зап-
роса (Query class), предполагает использование в запросах имен сети Интернет. Секцию
ответов заполняет сервер. Поля количества ответов (ANCOLJNT), количества записей в
секции уполномоченных серверов (NSCOUNT) и количества дополнительных записей
(ARCOUNT) состоят из записей о ресурсах (RR), содержащих информацию о домен-
ных именах и соответствующих им аппаратных адресах. Каждая запись о ресурсах (RR)
содержит информацию только об одном доменном имени

Типы доменных имен

Когда служба DNS вводит то или иное имя в систему, этому имени присваивается
определенный тип (type), пель которого —продемонстрировать, в качестве какого име-
ни функционирует данное доменное имя: в качестве адреса компьютера, имени почто-
вого ящика, имени другого пользователя, и т.п Таким образом, даже если DNS сосре-
доточит имена разных типов в обшей массе, посетителям вашею Web-caina будет удобно
найти ваш адрес В таблице 14 6 представлены различные тины записей о ресурсах DNS
(RR).

Таблица 14,6 Типы записей о ресурсах (RR) протокола DNS

Имя	Описание	Значение
А	Адрес хоста	32-разрядный IP-адрес
CNAMF	Стандартное имя	Стандартное доменное имя. используемое в качестве псевдонима некоторых FTP-сайтов для их идентификации другой системой
HINFO	Имя ЦП и ОС	Имя центрального процессора или операционной системы
MINFO	Сведения о почтовом ящике	Информация о почтовом ящике или о списке электронных адресов
Имя	Описание	Значение
MX	Идентификатор обработчика почты	16 разр°"ное имя хоста, который функционирует в даннск» домене в качестве обработчика почты
NS	Запись о серверах имен	Идентифицирует уполномоченные серверы доменных имен
PTR	Указатель записи	IP-адрес хоста, указанный в п( ратном порядке, с суффиксом "in-addr агра"
SOA	Начало зоны полномочий сервера	Определяет, какая часть иерархии именования находится в компетенции того или иного сервера имен
TXT	Текст, не имеющий четкой структуры	Строка символов ASCII, не opi анизиванная согласно каким-либо правилам. Может служить средством присоединения текстовых комментариев к базе данных DNS

Примеры работы DNS

Рассмотрим некоторые примеры работы системы DNS в том виде, в каком их ин-
терпретирует анализатор протоколов Sniffer. В процессе рассмотрения этих примеров
будут проанализированы все этапы работы DNS, начиная с момента отправки запроса
и заканчивая получением результата выполнения процедуры разрешения указанного в
запросе доменного имени. Рис. 14.5 иллюстрирует процесс передачи одним из хостов
запроса на определение IP-адреса по имени.

РИСУНОК 14.5 Как видно по изображенному на данном рисунке окну анализатора протоком в Sniffer,
запрос поступил от клиента DNS через UDP-nopm отправителя с номерам 2798 и направляется в
адрес сервера DNS чере- общеизвестный UDP-nopm получатезя с номером S3.
В окне анализатора протоколов Sniffer, приведенном на рис. 14.5 в качестве приме-
ра, показан заголовок сообшения DNS. представляющего собой запрос на отображение
имени хоста Irwind.ind.irw.com в IP-адрес этого хоста. Клиент установил флаг рекурсив-
ной обработки запроса (Recursion desired, RD), предписывая тем самым серверу DNS
передать этот запрос другому серверу (в случае, если данный сервер не является полно-
мочным в данном домене и не имеет возможности выполнить успешное разрешение
указанного в запросе имени с использованием только локальной информации). Рис. 14.6
иллюстрирует действия неполномочною сервера DNS, передающего запрос другому
серверу or имени клиента.

РИСУНОК 14.6 На данном рисунке следует обратить внимание на то. что оба UDP-порта DNS
(и порт отправителя. и порт получателя) имеют номер 53, что означает следующее: как хост-
отправитель, тик и хост-получатель являются серверами DNS. использующими для обмена
сообщениями данный общеизвестный серверный порт (53).

Как следует из приведенною на рис. 14.6 примера, когда и хост-отправитель, и хост-
получатель используют для обмена сообщениями UDP-порты, выделенные для службы
DNS. с одним и тем же номером, это означает, что оба указанных хоста являются сер-
верами DNS. Подобная ситуация складывается, когда один сервер DNS не владеет ин-
формацией, требуемой в запросе (друтими словами, не наделен полномочиями на раз-
решение указанного в запросе имени). В таком случае этот сервер должен передать запрос
в адрес другого сервера от имени клиента.

Сервер, выдающий запрос, включил в запрос уникальный идентификатор 33628, по
которому будет определен соответствующий этому запросу ответ Следует обратить вни-
мание, что в поле количества запросов (Question count) установлено значение 1, а это
означает, что сервер передает запрос на разрешение только одного имени. В поле коли-
чества ответов (Answer count) установлено значение 0, поскольку еще не был получен
ни один ответ. В поле количества записей в секции уполномоченных серверов (Authority
count) установлено значение 0, поскольку данный сервер не имеет в своем распоряже-
нии информации, необходимой для тою, чтобы ответить на запрос клиента на разре-
шение имени han.press (этот сервер не является полномочным в данной зоне). Именно
по этой причине данный сервер в первую очередь передает запрос, на который он сам
не может ответить. Как видно по рисунку, сервер DNS желает выполнить разрешение
имени hart.press, при этом в качестве типа искомою ресурса указывается tint "адрес
хоста”, а в качестве класса указан класс "адрес Интернет".

На рис. 147 показано, как в ноле кода ответа (Response code) перелается значение
"Ошибка в имени" (Name error), что привело к отрицательному завершению процедуры
разрешения имени, указанного в запросе.

РИСУНОК 14.7 На данном рисунке следует обратить внимание на то. что значение идентификатора
(указанное в note ID) совпадает со значением идентификатора, указанным ранее в дейтаграмме,
содержащей запрос (см рис. 14.6).

Значения идентификаторов, указанные в приведенных на рис. 14.6 и 14.7 примерах,
совпадают. Это означает, что пары "запрос — ответ" службой DNS подобраны коррект-
но. На рис. 14.7 следует обратить внимание на то. что данный сервер является полно-
мочным за разрешение доменного имени, указанного в запросе; в то же время этого
имени нет в таблице отображения имен данного сервера. Поскольку указанною в зап-
росе имени нет в таблице, сервер отравляет ответ с указанием в поле кода ответа
(Response code) значения 3, которое означает отрицательное завершение процедуры
разрешения указанного имени.

Рис. 14.8 иллюстрирует процедуру выполнения сервером DNS процедуры разреше-
ния имени и ею отображения в соответствующий IP-адрес. В поле TTL установлено
значение 43200, из чего следует, что клиент может принять предложенную ему инфор-
мацию как верную и продолжать использовать ее до истечения установленного в тай-
мере значения. По истечении периода времени, указанною в таймере, клиент должен
передать повторный запрос на разрешение тою же имени.

РИСУНОК 14.8 Ни данном рисунке проиллюстрирован пример полномочного ответа, сгенерированного
сервером DNS в процессе выполнения процедуры разрешения имени suslu.4tanford.edu и отображения
этого имени в /Р-адрес 36.8.0.53.

NetBios

Сетевая базовая система ввода вывода (NetBIOS, Network Basic Input Output System)
представляет собой расширение базовой системы ввода-вывода BIOS (Basic Input Output
System), которая обеспечивает хост базисной возможностью получать доступ к своим соб-
ственным локальным ресурсам Компании IBM и Sytek дополнили обычную систему
BIOS возможностью получения доступа к информации, размещенной на удаленных
хостах, такая расширенная система была названа сетевой базовой системой ввода-вы-
вода, NetBIOS Целью разработчиков NetBIOS было предоставление в распоряжение
пользователей достаточно простого способа получения доступа к удаленным ресурсам
и службам, используя при этом имя, а не адрес.
Кажд >му устройству, под [ерживаюшему NetBIOS, присваивается уникальное имя,
состоящее из 15 символов; службам, выполняющимся на хостах, также могут быть при-
своены соотвеютву юшие имена. Подобные уникальные имена предоставляют пользо-
вателю возможность обнаруживать ту или иную выполняемую на хосте службу по ее
имени. На раннем этапе формирования компьютерных сетей, когда IBM и Sytek пред-
ставили данный протокол, маршрутизаторы еще не были разработ шы. Сетевая архитек-
тура IBM предполагала формирование одноранговой сети с мостами между отдельными
участками локальной сети (flat-bridged network); в этой структуре все хосты входили в
состав одной и той же локальной сети. Первоначально система NetBIOS была реализо-
вана IBM в качестве встроенного программно-аппара.ного обеспечения хоста с использо-
ванием для доставки сообщений протокола канального уровня, известного под назва-
нием NetBEUI (NetBIOS Basic Extended User Interface, Базовый расширенный
пользовательский интерфейс NetBIOS — протокол, используемый всеми сетевыми опе-
рационными системами компании Microsoft)

Протокол NetBEUI выполняет доставку дейтаграмм между хостами на канальном
уровне, используя МАС-а зреса отправителя и получателя ши идентификации взаимо-
действующих хостов. Поскольку в то воемя не было маршрутизаторов, такой способ
оказался самым удобным способом использования удаленных реезреов. Хосты, поддер-
живающие NetBIOS, просто передавали в адрес всех хостов сети широковещательное со-
общение, содержащее запрос на определение МАС-адреса хоста назначения по имени
этого хоста, присвоенного ему NetBIOS. Посколью устройства, функционирующие на
канальном уровне, не отфильтровывают широковещательных сообщений, все хосты сети
принимали такое сообщение' в конечном итоге хост, которому было присвоено данное
имя, отправлял в ориентированной дейтаграмме ответ, в котором указывай) свои МАС-
адрс».. Процесс разрешения имени считался заьершенным после получения хостом-от-
правителем МАС-адреса в качестве ответа на свои запрос на разрешение имени хоста-
получателя. После этого хост-отправитель и хост-получатель получали возможность
осуществлять взаимодействие на основе обмена ориентированными дейтаграммами.

Хост; । NetBIOS отправляют только первичный запрос в широковешат' тьной рассыл-
ке. Далее хосты могут обмениваться сообщениями непосредственно между собой, вклю-
чая и ответ, содержащий отображение имени в соответствующий ему МАС-адрес. По
завершению процедуры разрешения имени посредством NetBIOS хост вносит получен-
ную информацию в кэш и сохраняет ее на протяжении определенного периода времени
на случаи если эта информация понадобится в будущем

NETBIOS И NETBEUI

Многие путают NetBIOS и NetBEUI, и эта путаница вполне понятна поскольку обе систе-
мы тесно переплетены с аппаратно-программными средствами. NetBEUI представляет собой
протокол канального уровня, разработанный специально для передачи дейтаграмм NetBIOS
в рамках одноранговой сети с мостами между участками локальной сети. NetBEUI не опе-
рирует в своей работе информацией сетевого уровня, в том числе не пользуется систе-
мой логической адресации на сетевом уровне. Поскольку протокол NetBEUI не имеет воз-
можности оперировать логическими адресами сетевого уровня, с его помощью нельзя
передавать информацию через маршрутизаторы. Будучи протоколом канального уровня,
NetBEUI ограничивается информацией и системой адресации (МАС-адресамм) канального
уровня.
Первоначально система NetBIOS действовала непосредственно на базе упомянутого
выше протокола канального уровня, в функции которого входило выполнение проце-
дуры разрешения имен для всех входящих в состав данной локальной сети хостов на
основе рассылки широковещательных сообщений в рамках этой сети. С помощью про-
токола NetBEUI нельзя передавать информацию через маршрутизаторы. Но, с другой
стороны, усовершенствования, внесенные в NetBIOS, позволяют этой системе исполь-
зовать для передачи своих данных по сетевому комплексу поверх таких протоколов
маршрутизации, как IP и IPX. Эго позволяет передавать данные NetBIOS за пределы
сетевого уровня (с использованием маршрутизаторов)

Функции NetBIOS не ограничены только разрешением имен. В состав возможнос-
тей NetBIOS входит также управление сеансами связи между хостами, обработка запро-
сов браузеров, и т.д. Однако, принимая во внимание назначение данной книги, в ней
рассматриваются только те функции NetBIOS, которые обеспечивают разрешение имен

Функционирование NetBIOS на базе стека
протоколов TCP/IP

Как было упомянуто выше, первоначально компания IBM разработала NetBIOS как
систему, функционирующую на базе протокола NetBEUI в одноранговой сети с моста-
ми между участками локальной сети. Для обеспечения работы NetBIOS в такой сети
применялся также сервер IBM LAN Server и операционная система OS/2. Компания
Microsoft приняла этот протокол для использования в реализации своего программного
продукта "Администратор Л ВС (LAN Manager), — предшественника широко известной
серии операционных систем Windows NT. В первые реализации в NetBIOS или NetBEUI
не были внесены никакие модификации, которые бы устранили неспособность этих
протоколов маршрутизировать данные, что, в свою очередь, ограничивало возможнос-
ти клиентов получением доступа только к локальным ресурсам.

К середине 90-х программистами компании Microsoft было осуществлено функцио-
нальное экстрагирование NetBIOS от NetBEUI, что сделало систему NetBIOS примени-
мой н сочетании с протоколами IP и IPX. Отделение NetBIOS от NetBEUI, а также вклю-
чение в состав NetBIOS логических модулей API (Application Programming Interface,
Программный интерфейс приложения) позволило сформировать из NetBIOS подлинный
протокол сетевого уровня. Логические модули API сделали возможным функциониро-
вание NetBIOS на базе различных протоколов транспортного и сетевого уровней. Из
этого факта вытекает, с одной стороны, способность NetBIOS маршрутизировать дан-
ные, а с другой стороны — поддержка системой NetBIOS удобной для пользователя служ-
бы разрешения имен.

При установке операционной системы Windows фирмы Microsoft в качестве клнен
тской или серверной ОС предоставляется возможность выбора одного из следующих
протоколов (или их совокупности): IP. IPX и/или NetBEUI. Этот выбор отображает ту
гибкость, которая позволяет NetBIOS функционировать на базе одного из указанных
протоколов или на базе всех протоколов одновременно, в зависимости от конкретных
требований той или иной сети. Поскольку данная книга посвящена изучению стека про-
токолов TCP/IP, далее рассматривается только действие NetBIOS на базе TCP/IP. Дей-
ствие NetBIOS на базе других протоколов находится вне рассмотрения данной книги.
Как иротокст сеансовою уровня, NetBIOS обеспечен определенными программны-
ми средствами, которые позволяют этому протоколу функционировать ни базе стека
(поверх* проюко'юв TCP/IP. В то же время протокол NetBIOS действует на основе
широковещательных рассылок, из чего вьнекает тот факт, что маршрутизаторы не смо-
гут транслировать сообщений NetBIOS. Этот факт предо гавляет собой серьезную про-
б!ему. поскольку современный сетевой комплекс — это нс одноранювая сеть на баэе
мостовою сопряжения, а совокупность сетей, которые взаимодействуют меж. г собой
через маршрутизаторы. Для решения проблемы передачи сообщений NetBIOS через
маршрутизаторы в NetBIOS были внесены определенные модификации, позволяющие
этому протоколу г заимодействоватьс протоколами TCP/IP через общей шестые порты
UDP и TCP 137, 138 и 139 (см таблицу 14 7). Хотя за NetBIOS закреплены н другие
порты., в основном используются только порты, указанные выше. Принципы функцио-
нирования NetBIOS на базе стека протоколов TCP/IP представлены в RFC 1001 и 1002
Таблица 14.7 Порты TCP/IP, используемые протоколом NetBIOS________________________

Номер порта Описание

137	Служба имен NetBIOS (NBNS, NetBIOS Name Service). Обеспечивает

разрешение имен

138	Служба использования дейтаграмм NetBIOS для навигации в сети Позволяет

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

139	Служба использования дейтаграмм NetBIOS для передачи данных по

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

Пользователи moivt получать доступ к ресурсам удаленные хостов посредством ука
ыння UNC-имени сформированного по правилу универсальною именования (UNC,
Universal Naming Convention). Согласно этому правилу UNC-имя формируется следую-
щим образом- указывается имя компьютера, за которым следует имя совместно исполь-
зуемо! о ресурса (share name), а также путь к удаленному хосту, те находятся совместно
используемые ресурсы. Следующий пример является иллюстрацией применения правя
ла LNC для формирования универсальною имени;

\\Heat hersPCXhome.

UNC можно также использовать для создания имени, постоянно хранящегося в со-
ответствующем файле и отображающего путь от локального хоста к фашюнои системе
у валенною хоста. Например, можно использонап команду 'net use" для того, чтобы ото-
бразить н одном имени пучь оз какого-либо локального хоста (например, от диска Е:
этою хоста) к домашнему каталогу Хэзер (Heather's home directory) на комт ютере Хэ-
зер (Heather's PC). Для этого необходимо набрать команду "net use d:\\ HeatherPC\ homc\
heather". После применения этой команды нелокальном хосте указанный в команде путь
можно использовать, просто набрав на клавиатуре "d:", как если бы го был путь к ло-
кальному файлу

При использовании UNIC-имсни для получения доступа к ресурсам удаленною хос-
га необходимо выполнить преобразование этого имени в логические адрес сетевого
уровня (IP-адрес). После определения IP-адреса хоста нашачения этот адрес должен бьнь
отображен в локальный МАС-адрес для тою. чтобы выполнить доставку данных в пункт
назначения по соединению “точка-точка". Действие механизма разрешения адресов не
рассматривается в данной i лаве. поскольку этот вопрос рассматривался достаточно под-
робно в тане 4. В данной главе основное внимание сосредоточено ив том. каким обра-
зом протокол NetBIOS выполняет разрешение имен в сеги, функционирующей на базе
TCP/IP

Различные методы разрешения имен в NetBIOS

Как известно. NetBIOS работает на основе широковещательной рассылки сообще-
ний. а маршрутизаторы не передаю! сообщений такою типа. Koi да пользователь выда-
ет запрос на получение досгупа к удаленному хосту посредством имени этого хосга,
NetBIOS (в зависимости от конфигурационных параметров клиенте) после проверки
своей локальной кэш-памяти может воспользоваться одним из следующих методов транс-
ляции имени требуемою хоста в его сетевой адрес:

•	Метод В-узла (broadcast node type): широковещательная рассылка запроса на раз-
решение имени в пределах токальной сети; в случае неудачи выполняется про-
верка файла LMHost (LM, LAN Manager — Администрагор ЛВС, специальная
операционная система компании Microsoft для обслуживания модели взаимодей-
ствия "клиент/сернер")

•	Метод P-узла (point-to-point node type) передача запроса на разрешение имени
только на сервер NBNS (NetBIOS Name Service. Служба разрешения имен
NetBIOS).

•	Метод М-узла (mixed node type): клиент выполняет разрешение методом В-узла.
Р узла, а затем — проверяет файл LMHost.

•	Метод Н-узла (hybrid node type): клиент выполняет разрешение методом Р-ухча.
В-узла. а затем — проверяет файл LMHost.

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

Метод В-узла

При выпотненин разрешения имени методом В-узла (разрешения посредством рас-
сылки широковещательных сообщении) клиент, прежде всего, проверяет свою кэш-таб-
лицу. Если разрешение имени при этом выполнить не удается, клиент предпринимает
несколько попыток передачи запроса на разрешение имени в широковещательной рас-
сылке в пределах локальной сети. Если клиент не получает ответа на запрос, последним
действием, направленным на трансляцию имени в соответствующий IP-адрес, является
проверка хранящеюся на локнльном \ocie файла LMHost (в случае, если такой файл
сконфигурирован на данном хосте! В названии файла "LMHost" LM соответсrover тер-
мину “LAN Manager" (Администратор ЛВС) Этот термин обозначает одну из реализа-
ций операционной системы компании Microsoft, обслуживающую взаимодействие парт-
неров по коммуникации в модели взаимодействия "клиент/сервер". Создаваемый
системным администратором или пользователем, этот простой текстовый файл (LMHosi)
содержит папы "имя — IP-адрес" и служит для выполнения тех же функции, что и упо-
мянутая выше локальная таблица хоста.

Метод Р-узла

Хосты, выполняющие разрешение имени методом P-узла (разрешение посредством
передачи запроса между двумя узлами локальной сети непосредственно), прежде всего
проверяют свои кэш-таблицы и только после этого предпринимают попытку разреше-
ния имени посредством передачи направленной дейтаграммы в адрес сервера NBNS
(WlNS-серчера). "Сервер NBNS (WINS-серверы)" — это имя, присвоенное компанией
Microsoft каждому серверу, обслуживающему процесс преибра ювания имен хостов в их
IP адреса. Преимуществом данного метода является то. что при выполнении разреше-
ния 1акою типа не генерируется трафик широковещательных сообщений. Однако если
в кэш-таблине хоста или в базе данных WINS нет соответствующей записи, либо koi да
сервер недоступен, запрос на разрешение имени завершается нехдачеи. При примене-
нии данного метода разрешения имен неблагоприятный исход выполнения процедуры
разрешения имени наиболее вероятен.

Метод М-узла

Так же. как и в предыдущих случаях, при выполнении разрешения имени методом
М-узла (смешанною способа разрешения имен первого типа) клиент в первую очередь
проверяет свою локальную кэш-таблицу. В случае отрицательною результата этой про-
верки клиент выполняет разрешение имени методом В-узла и Р-узяа. На самом после-
днем этапе клиент проверяет на наличие соответствующей записи локальный фант
LMHost.

Метод Н-узла

Благодаря своей универсальности, разрешение имен методом Н-узла применяется в
большинстве реализаций. При применении ра «решения имени методом Н-узла (смешан-
ною разрешения агорою типа) преобразование имени хоста в его IP-aipec выполняет-
ся в следующем порядке:

I.	Проверка локальной кэш-таблицы

2.	Разрешение имени метолом Р-узла

3	Разрешение имени методом В-узла

4.	Проверка локального файла LMHosi

В богьшинстве случаев предпочтение отдается именно этому способу разрешения
имен, поскольку при его реализации перед передачей запроса на разрешение имени в
широковещательной рассылке выполняется разрешение методом Р-узла, что устраняет
избыточный трафик широковещательных сообщении и соответственно, увеличивает
производительность сети Кроме того, только метод Р-узла поддерживает передачу со-
общений. генерируемых службой разрешения имен NetBIOS, через маршрутизаторы
Клиенты, выполняющие разрешение имен методом P-узла, должны заранее знать IP-
адрес сервера NBNS (WINS-сервера) еше до передачи запроса на разрешение имени;
следовательно, им нет необходимости отправлять свои запросы в широковещательной
рассылке. Поскольку при выполнении разрешения методом P-узла используются ори-
ентированные дейтаграммы вместо широковещательных, маршрутизаторы могут пере-
давать содержащиеся в таких дейтаграммах запросы.

Каким же образом, в конечном итоге, клиент определяет искомый IP-адрес? Суще-
ствует несколько вариантов: либо системный администратор конфигурирует этот адрес
в таблице локального хоста, либо при начальной загрузке с сервера DHCP этот адрес
предоставляется в качестве одного из загрузочных параметров При выполнении разре-
шения имени методом P-узла системный администратор, как правило, предоставляет в
распоряжение клиентов IP-адреса основного и вспомогательного WINS-серверов. Если
основной сервер оказывается недоступным, клиент может предпринять попытку разре-
шения имени через вспомогательный сервер.

WINS (Сервер имен сети Интернет для Windows)

WINS (Windows Internet Name Server. Сервер имен сети Интернет для Windows) —
это предложенная фирмой Microsoft реализация NBNS. По существу WINS обеспечи-
вает динамическое разрешение имен хостов NetBIOS (аналогично службе DNS). Каж-
дый WINS-сервер поддерживает базу данных, содержащую имена хостов NetBIOS и
соответствующие им IP-адреса Сетевые администраторы должны осуществлять опти-
мальное размещение WINS-серверов в рамках сетевого комплекса с тем, чтобы эти сер-
веры выполняли успешное разрешение запрашиваемых клиентами имен. Упомянутая
выше база данных может формироваться либо вручную сетевым администратором, либо
динамически, посредством внесения WINS-серверами имен и соответствующих им IP-
адресов в базу данных.

WINS-клиенты, функционирующие в режиме online и сконфигурированные с IP-
адресом WINS-сервера, pet исгрируют свои имена и адреса на данном сервере на слу-
чай. если какому-либо хосту понадобится выполнить разрешение того или иного име-
ни. После начального запуска хосты, не имеющие в своем распоряжении IP-адресов
соответствующих WINS-серверов, передают в широковещательной рассылке свои име-
на NetBIOS, объявляя тем самым о своем присутствии в сети. Когда происходит подоб-
ное событие, локальный WI NS-сервер принимает такое широковещательное сообщение
и вводит содержащееся в нем имя и соответствующий IP-адрес в свою базу данных.

Прокси-агент WINS

Большинство компьютеров, работающих на базе операционных систем компании
Microsoft, а также некоторые маршрутизаторы функционируют в качестве прокси-аген-
тов WINS (WINS proxy agents) или WINS-серверов, выполняющих разрешение имен для
хостов, которые не поддерживают разрешение имен методом P-узла. Клиенты, не име-
ющие возможности реализовать метод P-узла, могут передавать запросы на разрешение
имен только в локальной широковещательной рассылке, что не позволяет им регистри-
ровать имена хостов и выполнять их разрешение через удаленные WINS-серверы.

В качестве прокси-агента может функционировать любой хост, сконфигурированный
таким образом, что он имеет возможность перехватывать локальные широковещатель-
ные запросы на разрешение имен и ретранслировать их в ориентированных деитаграм-
мах в адрес удаленного WINS-сервера с целью выполнения разрешения имени удален-
ного хоста. После получения ответа на запрос агент, выполнивший ретрансляцию зап-
роса на удаленный WINS-сервер (relay agent). кэширует локальный запрос для
использования в будущем и передает полученную информацию н адрес хоста-отправи-
теля запроса Такая процедура разрешения имен делает возможной обратную совмести-
мость модифицированной версии службы имен NetBIOS с ранними версиями, которые
поддерживаю! только разрешение имен методом В-узла (разрешение на основе рассыл-
ки широковеша1ельных запросов).

Примеры работы NetBIOS

Рассмотрим некоторые примеры работы NetBIOS в том виде, в каком их интерпре-
тирует анализатор протоколов SnilTer. Рис. I4.9 иллюстрирует процесс передачи одним
из хостов запроса на определение IP-адреса по имени На этом рисунке можно увидеть,
чго значение, указанное в поле идентификатора (1D) заготовка WINS, совпадав со
значением, указанным в соответствующем поле на рис. 14.10; из этого можно сделать
вывод о соответствии ответа запросу. Пл упомянутым рисункам можно заметить, чго
формат заюлонка WINS и его полей аналогичен формату' заголовка DNS, рассмотрен
ною ранее в данной главе. Этот факт объясняется тем, чго DNS и WINS выполняю!
аналогичные функции На рис. 14.9 представлен запрос на трансляцию имени Р60 (тип
имени — имя NetBIOS, или имя WINS) в соответствующий этому имени 1Р-адрес.

РИСУНОК 14.9 UDP-порты, указанные в заголовке UDP и соответствующие службе имен NilB/OS.
идентифицируют отправите т и палучатеы запроса на разрешение имени (опа порта имеют
номер 137)
Разрешение имен

s	uTLrz/'j....'L_ —. .: -. _

S t4* Цитког t«Xur* L'B»W Lown £roJoN цег	, Iffl x

g|c| a| | E|ri|o|w|j-|.aLJ jj J_________________________ ________________________________________

□ U[ г	T

- fej VIKS' —- WlKr Иаже Service needer

□ VIKS

J WINS TO - J2776

3V1FS Flags - 85

J VIHS ]	- R*bponse

1 VIHS	1	- Authoritative answer

1 WINS ООО 0	- Qwsry

J WINS	. 0 • Not truncated

. 1 WINS Flags - OX

VINS D	• Dato NOT verified

WINS 0	“ Recursion not eveliable

Л WINS Response cede - OK (0)

"j VINS 0	 Unicast packet

[j VINS Question count • 0. Ant ser count • 1

j 1 VINS. Authoritv count • 0 Additional record count - 0

.J ИН5

IJ VINS Answer section

J3 VINS h'5M • PbC
WINS Type • NetBIOS паже service (WINS) (NetBIOS пела.3ZJ

3 BINS Class - Internet (IN 1)

3 VINS	Tiae-to-live • 300D00 (seconds)

3 VINS	length - 6

3 VINS Node flogs • 60

1 j VINS 0	- Unique NetBIOS new

_) VINS 11	- Reserved node type

lJWINS Node address • [161 69 97 201]	P60

3 “INS	-

^rwcoee^MMu^ltuilTaUe7^RoifiCDifctUMxbf
rcjNrt'pfMiFI	Ji	JT.

lfisi«lj n Д gj	ВммТи». |	I -*JF».-*4rel | е>Ы»а-С |П .1 *«5FW

РИСУНОК 14 10 Сервер отправляет ответ на полученный lanpot. в ориентированной 'китагремме

Сервер, показанный на рис. 14.10. наделен полномочиями на разрешение указанно-
го в запросе имени. Ответ, полученный в результате разрешения имени Р60 методом Н
узла (в окне анализатора Sniffer этот способ разрешения имеет название "reserved node
гуре", или "зарезервированным метод разрешения"), а именно — IP адрес 161.69.97 201,
отправлен в ориентированной дейтаграмме и подтверждает уникальность имени, разре-
шение которого было выполнено. Хост, отправивший запрос, занесет полученную ин-
формацию в свою к эш-табл и ну для будущею использования. Время жизни, устанавли-
ваемое в поле ТTL WINS-серверами, составляет 300UO0 секунд и задает период времени,
в течение которого хост расценивает полученные данные кат верные и не выполняет
процедуру разрешения имен повторно с целью обновления имеющейся у него инфор-
мации

Резюме

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

13 Зш 76И
Вскоре после начала объединения сетей в сетевые комн 1ексы простой список домен-
ных имен разросся настолько, что это повлекло за собой необходимость в незамедли-
тельном решении следующих вопросов: удобство и простота использования системы
именования, а также связанные с этим рабочая нагрузка и стоимость. Пространство имен
хостов существующей в те времена сети не было разработано достаточно детально и не
всегда было доступно для понимания пользователям-новичкам, работающим на недав-
но подключенных к сеги компьютерах. Бурное разшпие всемирной сети Интернет при-
вело к тому, что v сетевою информационного центра (NIC) появилось множество про-
блем, связанных с ежедневным подключен nevi к Интернету тысяч новых компьютеров
и рабочих станций. В конечном итоге обслуживающему персоналу центра NIC прихо-
дилось выполнять обновление пространства имен на всех без исключения компьютерах,
что означало напрасную трату времени и денег.

Изложенное выше развитие собы ин привело к необходимости разработки и реали-
зации службы именования. Такой службой стала служба именования доменов (DNS.
Domain Name System), которая устраняет необходимость в существовании едино!о для
всей всемирной сети пространство имен и позволяет достаточно легко наити требуемый IP-
адрес для каждого доменною имени и наоборот. Служба DNS разделяет все пространство
имен на отдельные зоны, в обязанности которых входит разрешение какой-либо части
доменных имен. Каждую зону обслуживает основной и вспомогательный сервер DNS.

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

Вопросы для повторения

I Назовите три проблемы, связанные с формированием пространства имен в системе NIC.
2. Объясните разницу между первичным и вторичным серверами имен.

3.	Почему компьютеры не могут распознавать доменные имена?

4.	Объясните, каким образом служба DNS распределяет свои полномочия.

5.	Дайте определение термина "кэширование" и объясните, каким образом серверы
используют кэширование в процессе разрешения имен.

6.	Какое свойство формата сообщения DNS используется сервером для передачи не-
скольких сообщении DNS?

7.	Перечислите сведения, которые до 1жны содержаться в каждом сообщении DNS.

8.	Чем отличаются NetBIOS и NetBEUI?

9.	Каким образом NetBIOS может выполнять разрешение имен на сетевом уровне?

10.	Какие три основных iiopta TCP/UDP обслуживают NetBIOS и для чего они исполь-
зуются?

11.	Назовиге различные методы разрешения имен в NetBIOS. Дайте краткое описание
каждою из них.

12.	Что такое прокси-агент WINS?

1
Глава 15

Протокол передачи
гипертекстовых файлов (HTTP)

В данной главе рассматриваются следующие темы:

•	Хар?к герметики HTTP (HTTP Qualities)

•	Компоненты HTTP (HTTP Components)

•	Сеансы HTTP (HTTP Sessions)

•	Формат сообщений HTTP (Message Formats)

•	Ответы HTTP, коды состояния и ошибок (Status and Error Codes)

•	Сообщения об ошибках (Error Messayes)

HTTP и WWW

Представьте себе, что у восьмилетнего ребенка, за которым вы присматриваете, по-
явилось желание посмотреть новый диснеевский мультфильм. Выполнить это желание
дошаточно просто: для этого необходимо только открыть домашнюю стряниму (home
разе) компьютера и щелкнуть на ссылке развлечений. После этого открывается Web
страница развлечений, Web-адрес которой отображается в огне ввода URL (перед соб-
ственно адресом, в нем можно увидеть символы "HTTP", идентифиципуюшие исполь-
зуемый протокол). Далее остается только найти ближайший кинотеатр, в котором
демонстрируется мультфильм Диснея, и оорадовать ребенка сообщением о том, что он
сможет посмотреть мультфильм уже на сегодня.

Протокол HTTP (Hvpeilext Transfer Protocol, Протокол передачи гипертекстовых
файлов) — самый распространенный и популярный среди пользователей протокол сети
Интернет — активизируется каждый рат, koi да происходит щелчок на ссы же. или ког-
да выполняется ввод запроса на поиск одной из Web-страниц Протокол HTTP обеспе-
чивает процесс взаимодействия между браузером (browser) рабочем станции и Web сер-
вером Браузер, который представляет соиои обычную прикладную программу, oi крываег
Wcb-странипы Используя возможности HTTP, браузер в поисках требуемой страницы
дейстг-'ет за рамками операционной системы и оборудования хоста. В первоначальном
виде протокол HTTP способен был обслуживать только пересылку данных в самом про-
стом формате (leKcroBOM), однако в настоящее время НТ ГР поддерживаем перссьику
более сложных типов данных, например, таких как разнообразные фафичсскне обра-
зы. которые ежедневно можно встретить в сети Интернет
$ ГИПЕРТЕКСТ

Слово "гилер” в термине "гипертекст” означает, что а документе имеются ссыпки, с по-
мощью которых можно получить доступ к другим документам.

В данной главе рассматриваются те программные компоненты протокола HTTP,
позволяющие ему осуществлять путешествия по сети Интернет. Здесь рассматриваются
также процессы, которые активизируются протоколом HTTP ДЛЯ выполнения запроса
пользователя па поиск Web-страницы. Для всех компьютерных фанатов (таких, напри-
мер, как сам автор) в книге подробно анализируются причины возникновения ошибок
при поиске Web-страпин, формат сообщений HTTP различных типов, а также смысл
каждого фрагмента сообщения HIT Р.

Характеристики HTTP

Подобно хорошему работнику, протоколу HTTP свойственны особые качества, ко-
торые выделяют ею среди других протоколов. Протокол HTTP использует эти качества
для беспрепятственного осуществления достаточно простого с точки фения пользова-
теля процесса, называемого в компьютерной среде "серфингом по сети Интернет"
(surfing). Протокол HTTP обладает следующими уникальными характеристиками:

•	Протокол HTTP функционирует на прикладном уровне, обеспечивая канал свя-
зи для передачи сообщений в пункт назначения. HTTP не гарантирует надежную
передачу данных (эту задачу он возлашет на протокол TCP транспортного уров-
ня), а также нс выполняет повторную пересылку данных.

•	Сервер HTTP не архивирует данные о сеансах свят и о HTTP-запросах пользо-
вателя.

•	Протокол HTTP обеспечивает двунаправленную передачу данных (bidirectional
transfer), а это значит, что сервер может выполнять передачу копии требуемой
Web-страницы в адрес браузера, а браузер имеет возможность одновременно пе-
редавать в адрес сервера запрос пользователя на поиск другой Web-страницы

•	Протокол HTTP использует в своей работе процедуру согласования возможнос-
тей (capability negotiation), блаюдаря которой браузеры и серверы HTTP имеют
возможность согласовывать некоторые детали (например, выбор набора симво-
лов для передачи запросов и ответов)

•	Проюкол HTTP поддерживает кэширование (caching), что позволяет сэкономить
время: браузер храпит в своей базе данных копию каждой Web-страницы, извле-
каемой для пользователя из сети Интернет. Если у пользователя снова возникнет
необходимость в обращении к извлеченной ранее Web-странице, браузер Н ГТР
выясняет у сервера информацию о том вносились ли изменения в содержание
этой Web-страницы и отличается ти последняя версия Web-страницы от храня-
щейся в кэше копии. Процедура кэширования рассматривается более подробно в
гчане 14.

•	Протокол HTTP вовлекает в процесс поиска и извлечения Web-сграннц проме-
жуточные устройства (intermediaries), т е. любые устройства, находящиеся на пути
между браузером и сервером HTTP, могут функционировать в качестве прокси-
агентов сервера HTTP (proxy server) Прокси-агенты выполняют кэширование
Web-страниц, а также используют кэш-память для того, чтобы отвечать на запро-
сы. Механизм работы прокси-aiсига сервера НТ ГР рассматривается более под-
рооно в след; юшем разделе.

Компоненты HTTP

В одной из песен Битлз сказано: "Благодаря своим друзьям я как-нибудь сведу кон-
цы с концами". Таким же обра юм и протокол HTTP преодолевает все трудности сер-
финга в сети Интернет благодаря компонентам, вхотяшим в состав его нрелраммных
средств. В текущем разделе данной главы рассматриваются все компоненты, использу-
емые протоколом Hl ГР для выполнения запроса пользователя на поиск и извлечение
Web-страницы. В таолице 15.1 пре вставлено описание всех составных частей протокола
НИР.

Таблица (5.1 Компоненты HTTP

Компоненты	Описание
Браузер	Независимый внешний интерфейс, функционирующий (browser, в качестве сервисной программы графического пользовательского интерфейса (GUI. Graphic User Interface) и Преобразующий команды пользователя в запросы и ответы HTTP.
Киммунгткацис иная цепочка (communication chain)	Серия запросов и ответов, которыми обмениваются сервер и браузер Н ГТР в процессе поиска и извлечения Web-страницы. Посредством последовательности ответов (response chain J выполняется доставка запрашиваемой информации в пункт назначена Ниже в данной главе можно встретить примеры коммуникационных цепочек НТ ГР
Шлюз (gateway)	Хост HTTP, который функционирует в качестве промежуточного сервера HTTP и в прозрачном режиме обеспечивает выполнение запросов пользователя на получение ресурсов и служб от сервера-источника (origin server).
Сервер-источник (origin serve )	Сервер НТ ГР, который обязан своим названием тому, что именно он распоряжается запрашиваемой информацией и, следовательно, именно с этого хоста пользователь может извлечь из сети Интернет требуемые ресурсы.
Прокси-агент (proxy)	Промежуточный хост HTTP, функционирующий либо в ка 1ьстве клиента, либо в качестве сервера HTTP с целью ибеспечьния обмена информацией между агентом пользователя (UA, User Agent) и сервером-источником. Прокси-агенты Hl ТР передают запросы от клиентов к серверам Серверы HTTP также отвечают на запрос, если запрашиваемая информация является локальной.
Агент пользователя (UA. User Agent)	Программный модуль, открывающий сеанс HTTP и запрашивающий информацию для пользователя Модули UA подробно рассматриваются в главе 13
Методь HTTP оораще.чия к ресурсам (methods)	Методы получения доступа к ресурсам Могут быть активизированы посредством указания маркеров методов (method tokens) в заголовке lanpoca HTTP. (Ресурсы — это фрагменты информации, которые HTTP пытается извлечь для пользе >ателя во время сеанса связи с сервером HTTP).
Тоннель • (tunnel)	Промежуточный программный интерфей', который обеспечивает во время сеанса HTTP прозрачный для пользователя виртуальный канал передачи данных непосредственно между двумя конечными хостами
ПРОЗРАЧНЫЕ И НЕПРОЗРАЧНЫЕ ПРОКСИ-АГЕНТЫ

В зависимости от требовании, предъявляемых к прокси-агентам, они могут быть сконфи-
гурированы для работы в прозрачном или непрозрачном режиме. Прозрачные прокси-
агенты не могут вносить изменения в запросы клиентов или ответы серверов, за исклю-
чением тех случаев, когда проходящая через них информация требует идентификации и
аутентификации клиентов. С другой стороны, непрозрачные прокси-агенты могут в слу-
чае необходимости вносить в запросы и ответы HTTP изменения, необходимые для под-
держки таких сервисов, как фильтрация или групповая идентификация.

Сеансы HTTP

Протокол HTTP взаимодействует с протоколом транспортного уровня TCP с целью
обеспечения гарантированном доставки данных через общеизвестный порт сервера с
номером 80. Сеанс HTTP инициируется пользователем, при этом выполняются следую-
щие действия:

I	. Пользователь открывает браузер и вводит илешификационные данные о требуемой
информации или ресурсе посредством указания в браузере соответствующего UR1
(Uniform Resource Identifier. Универсальный идентификатор ресурса).

2	Протокол HTTP генерирует запрос нн соединение (connection request), цель которо-
го — установить сеанс HTTP между клиентом (UA) и либо сервером-источником,
либо промежуточным сервером.

$ ПРИМЕЧАНИЕ

При определенных обстоятельствах может возникнуть необходимость в открытии прото-
колом HTTP нескольких сеансов TCP. Такая ситуация может сложиться в случае, когда,
например, протокол HTTP принимает написанную на языке HTML Web-страницу, переда-
ча каждого объекта которой, а также собственно HTML-файла, требует открытия отдель-
ного сеанса TCP.

Для идентификации ресурса по его имени протокол HTTP использует сервис URN
(Uniform Resource Name, Унифицированное имя ресурса). Сервис URN обеспечивает
согласованную идентификацию ресурсов сети Интернет. Данный сервис более известен
под названием URL — Uniform Resource Locator, "Унифицированный указатель ресур-
са". URL (ичи URN) имеет следующий формат:

http://home-movies.excitecom/entertainrcent/

Как видно по приведенному выше примеру, первая часть URN идентифицирует
протокол, в данном случае — протокол HTTP. В следующей части URN указано имя
хоста, к которому пользователь пытается получить юступ через сервер-источник HTTP —
www.home-movies.exciie.com. За именем хоста следует дополнительная информация о
пути доступа к данному хосту. Заключительной частью URN является имя запрашивае-
мого ресурса (развлечения — entertainment).

Сервер-источник HTTP может обслужить запрос, отправленный UA клиента непос-
редственно в его адрес. Этот же запрос может передаваться в адрес сервера-источника
прокси-агентами НП Р. Шлюз HTTP также может обслужить запрос непосредственно.
Все способы обработки запроса остаются прозрачными для пользователя; при этом шлюз
обрабатывает запрос даже тогда. KOtjia оказывается, что сервер-источник уже выполнил
эту работу Насколько известно клиентам HTTP, установить взаимодействие с сервером-
источником, а также получить через него запрашиваемый ресурс достаточно просто. На
рис. 15.1, 15.2 и 15.3 представлены три коммуникационные цепочки, согласно которым
протокол HTTP может выполнить пересылку запрашиваемых ресурсов. На рис. 15.1 по-
казана цепочка "UA (азент пользователя) — сервер-источник”.

На рис. 15.2 проиллюстрирован процесс взаимодействия агента UA с сервером- источ-
ником через промежуточный сервер (прокси-агент). Следует обратить внимание на то.
что на пути к серверу-источнику запрос может пересекать любое количество встретив-
шихся ему компонентов HTTP, или промежуточных устройств, обслуживающих процесс
HTTP Эти устройства функционируют в качестве коммуникационных каналов < вязи
между клиентом и сервером.

На рис. 15.3 показан процесс взаимодействия между агентом пользователя (UA) и
промежуточным устройством. После отправления клиентом запроса в адрес сервера-
источника первое промежуто гное устройство передает запрос дальше, а второе проме-
жуточное устройство принимает запрос и обрабатывает его. Второму устропстах затре-
бованная агентом UA информация доступна в локальном режиме, что позволяет ему
отослать содержащую запрос коммуникационную цепочку вместе с запрашиваемой ин-
формацией в адрес клиента.

РИСУНОК 15.1

Агент пегьмвателя t гаимпдействуст
т ч ’ведет зенпо с сервером-источником,
mai.au процесс взоимсоеиствия между UA и
сервером-источником нс тредует наличия
промежуточных НТТР-хостов.

РИСУНОК 15.2

Прокси-агенты, или

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

РИСУНОК 15.3

В состае > оммуникиционнои цепочки
HTTP. содержащей запрос, входит более
чем одно промежуточное устройства. В
донном случае запрашиваемая информация
имеется в распоряжении торого
промежуточного НТТР-хоста.

В случае если запрос клиента обрабатывается промежуточным НТТР хостом, это
позволяет, с одной стороны, сэкономить время обработки запросов сервером-источни-
ком, а с другой стороны — ускорить процесс выдачи ответа на запрос клиента. Некото-
рые компании считают целесообразным со стратегической точки зрения размешать ча-
сто запрашива* мую информацию на промежуточных хостах и наделяют эти хосты правом
непосредственно обрабатывать запросы на предоставление та koi- информации с тем,
чтобы снизить загруженность сервера-источника Промежуточные устройства также
кэшир*ют информацию, затребованную ранее клиентом, и хранят эту информацию в
своей базе данных на случай получения повторного запроса на предоставление тех же
файлов.

Формат сообщений HTTP

Аналогично другим протоколам клиент и сервер HTTP взаимодействуют друг с дру-
гом посредством серии сообщений, которые называются запросами (requests) и ответа-
ми (responses). Сообщение, которое отправляет клиент, передается в последовательнос-
ти запросов (request chain), а ответ промежуточною хоста или сервера-источника на эти
запросы — в последовательности ответа (response chain). Оба типа сообщений форми-
руются в соответствии со следующим общим форматом:

•	Общая начальная строка (generic start line), называемая строкой запроса (request
line) для запросов и строкой состояния обрабо!ки запроса (status line) для отве-
тов

•	Общим таюловок (general header)

•	Заголовок сообщения (message header)

•	Одна пустая строка (empty line)

•	Тело сообщения (message body)

Общий формат начальной строки

Начальная строка представляет собой либо строку запроса, либо строку статуса. Агент
UA отсылает строку запроса, а сервер-источник или шлюз в ответ на этот запрос от-
правляют строку состояния. Начальная строка содержит в себе соответствующий URI.
идентифицирующий требуемый ресурс. Начальная строка функционирует в качестве
оперативной инструкции, содержащей описание действия, которое необходимо предпри-
нять по отношению к запрашиваемому ресурсу. В начальной строке указывается также
используемая версия протокола Н ГГР, за которой следует пустая строка (символ CR/
LF, возврат каретки с переводом строки). В таблице 15.2 представлены маркеры ресур-
сов HTTP и соответствующих методов доступа к ним. а также функции этих методов

Таблица 15,2 Маркеры ресурсов и соответствующих методов доступа, а также их функции
Маркер Функции

GET	Запрашивает предоставление ресурса с сервера-источника.
HEAD	Аналогичен GET, но в усеченном виде: клиенту возвращается только заголовок сообщения, содержащего ответ. Используется для тестирования гиперссылок и проверки доступа к ресурсам
PUT	Запрашивает передачу ресурса.
OPTIONS	Выясняет для UA характеристики и возможности HTTP
POST	Создает новый ресурс на сервере-источнике (например, выводит новое сообщение на доску объявлений).
DELETE	Клиент отправляет эту команду с целью удаления сервером-источником того или иного ресурса.
Trace	Помогает тестировать и диагностировать ошибки
Connect	Устанавливается прокси-агентами с целью использования их для операции тоннелирования.
Общий заголовок сообщений HTTP

Все сообщения HTTP начинаются с общего заголовка. Это относится как к запросу,
так и к ответу HTTP, но не относится к собственно передаваемому объекту. Общий за-
юлонок HTTP состоя 1 из следующих потей:

•	Поле кэш-кошроля (Cache-control)

•	Поле соединения (Connection)

•	Поле даты (Date)

•	Поле директивы (Pragma)

•	Поле заключительной части сообшения (Trailer)

•	Поле кодирования передачи (Transfer-encoding)

•	Поле обновления (Upgrade)

•	Поле промежуточных устройств (Via)

•	Поле предупреждения (Warning)

Поле кэш-контроля

Поле кэш-контрочя (Cache-control) позволяс! передавать информацию, содержащу-
юся в запросах и ответах HTTP, контролируя при этом процесс выполнения операции
кэширования такими компонентами НТ ГР, как агенты пользователя (UA), промежуточ-
ные устройства и серверы-источники. Информация, содержащаяся в поле кэш-контро-
ля (Cache-control), предписывает:

•	Кшда кэшировать или сохранять отправленную или принятую информацию.

•	Как долго эта информация должна оставаться в базе данных

•	Является ли внесенная в базу данных информация общедоступной, или она пред-
назначена для индивидуальною пользования.

Поле соединения

По информации, указанной в пале соединения (Connection), клиент HTTP опреде-
ляет, какие характеристики соединения (например, постоянность соединения —
persistence) должны быть применены. Такие дополнительные характеристики соедине-
ния со стороны клиента могут потребовать или не потребовать поддержки со стороны
промежуточною сервера иди сервера-источника. Прокси-агенты, в адрес которых по-
ступает данное поле с установленным в нем значением, могут принять или отвергнуть
указанную дополнительную характеристику соединения, но далее по коммуникацион-
ной цепочке (в адрес следующего промежхточного устройства или сервера-исгочника)
такая характеристика не передается.

Поле даты

Дату устанавливает инициатор запроса на извлечение ресурса (в случае даты запро-
са) или устройство, выполнившее этот запрос (в случае даты ответа). В поле даты (Data)
устанавливается дата и время формирования запроса или ответа
Поле директивы

Поле директивы (Pragma) используется для установки специальных директив участ-
никам соединения по поводу тою. какие действия они должны включить в цепочки
запросов или ответов.

Поле заключительной части сообщения

Поле заключительной части сообщения (Trailer) указывает на то, ч го данный набор
полей заголовка будет расположен в конце заголовка сообщения, закодированного ме-
тодом кодирования передачи с разбиением потока информации на фрагменты.

Поле кодирования передачи

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

Сообшения могут быть разбиты на фрагменты (chunks), в каждом из которых указа-
на длина этого фрагмента, а также представлена дополнительная заключительная часть
(optional trailer), содержащая поля заголовка объекта (entity-header fields). Когда пользо-
вателю нужно передать большой полок информации, он разбивает его на более мелкие
и более управляемые части (фрагменты), каждый из которых принадлежит к одному и
тому же потоку Каждому из фрагментов должен быть присвоен соответствующий иден-
тификатор, позволяющий получателю определить его принадлежность к данному пото-
ку. а также длину данного фрагмента потока. Разбиение потока информации на фраг-
менты (chunking) позволяет передавать в адрес получателя динамически формируемый
материал вместе с информацией, по которой получатель может определить целостность
полученных им фрагментов (целостность фрагментов можно определить посредством
проверки д'1ины фрагментов, принятых получателем).

Метод кодирования передачи с разбиением потока информации на фра!менты
(chunked transfer-encoding method) составляет значительную часть данного потя. Если
процедура кодирования передачи применяйся по отношению к телу сообщения, в эту
процедуру должно входить фрагментирование сообщения, в противном случае соеди-
нение будет разорвано. Кодирование передачи фра| мента (chunked transfer-coding) не
должно быть последним и единственным кодированием, применяемым к телу сообще-
ния.

Поле обновления

В поле обновления (Upgrade) устанавливается текущая версия протокола HTTP с
целью обеспечения совместимости между взаимодействующими устройствами.

Поле промежуточных устройств

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

Поле предупреждения

В поле предупреждения (Warning) содержится уведомление об ошибке.

Заголовки сообщений HTTP (заголовок запроса HTTP,
заголовок ответа HTTP и заголовок объектен HTTP)

Протокол HTTP функционирует на базе модели взаимодействия клиент/сервер. Кли-
ент HTTP отправляет запрос в адрес сервера HTTP, а сервер отсылает ответ Согласно
этой модели в сообщение HTTP может быть включено три типа заголовков: заголовок
запроса (request header), заголовок ответа (response header) и заголовок объекта (entity
header).

Заголовок запроса

В начальной строке сообшения HTTP, содержащею запрос клиента в адрес сервера
на извлечение ресурса, укалывается метол доступа к ресурсу, идентификатор ресурса и
применяемая версия протокола. Заголовок запроса позволяет клиенту передать допол-
нительную информацию о запросе, которая не бы та включена в первую строку или в
общий заюловок. В заголовке запроса содержится информация о клиенте HTTP, с ко-
торым работает пользователь а также информация о запрашиваемом ресурсе и о самом
сервере HTTP. В таблице 15.3 представлено описание значений различных заголовков
запроса.

Таблица 1S.3 Заголовки запроса и их значения

Заголовок запроса	Значение
Accept-Charset	Определяет набор символов, допустимым в ответе
Accept-Encodlng	Регламентирует кодировку содержимого тела сообщения
Accept-Language	Определяет основные языки, используемые для формирования тела сообщения.
Authorization	Содержит информацию аутентификации клиента для доступа к защищенным ресурсам
From	Содержит адрес электронной почты клиента, отправляющего запрос
Host	Интернет-хост, на котором находится запрашиваемый ресурс и номер порта, через который можно получить доступ к нему
If-Modrfied-Since	Позволяет убедиться а том. что занесенная а кэш версия ресурса является самой последней
If-None-Match	Используется дгя формирования условных методов
If-Range	Запрашивает весь ресурс или его часть
I F-Unmodif led-Since	Используется для формирования условии выполнения соответствующих методов
Max-Forwards	Определяет максимальное количество прокси-агентов или шлюзов, через которые может передаваться запрос.
Proxy-Authorization	Позволяет клиенту представить прокси-агенту свокэ идентификационную информацию.
Заголовок запроса Значение	
Rangr	Определяет фрагмент запрашиваемого ресурса, подлежащий пересылке в адрес клиента
Referer	Определяет исходный URL-адрес, с которого был получен запрос на извлечение документа.
UA	Содержит информацию об агенте пользователя, который инициировал запрос.

Заголовок ответа

Сервер HTTP передает заголовок ответ* в ответе на запрос ш еи га пользователя; в
зтом заголовке содержится состоящий из грех цифр код, идентифицир\ющии тип отве-
та. Сообщения, содержащие ответ сервера HTTP, а также коды ошибок и трехзначные
коды состоянии oiветов рассматриваются боле подробно ниже в данной главе.

Заголовок объекта

Заголовок объекта является необяза!ельным заюлонком; в нем содержится инфор-
мация о запрашиваемом ресурсе. В таблице 15.4 представлено описание значений раз-
личных заюловков объекта.

Таблица 15.4 Заголовки объекта и их значения	
Заголовок	Значение объекта
Allow	Содержит список методов, поддерживаемых ресурсом
Content-Base	Определяет базовый URL запрашиваемого ресурса.
Content Encoding	Содержит идентификатор типа дополнительней кодировки ресурса (других и словами, для использования эта о ре< урса он должен быть декодирован указанным алгоритмом).
Content-Language	Содержит основные языки ис.юлг зуьмые при формировании тела сообщения.
Content-Length	Определяет длину тепл сообщения.
Content-Location	Предоставляет cepeepv HTTP информацию о местоположении ресурса.
Content-MD5	OI еспечизает полную проверку надежности доставка сообщения
Content-Range	Определит область памяти для размещения тела сообщения.
Content-Type	Указывает гип физического носителя, по которому
будет передаваться тело сообщения.	
Etag	Опреде 1яет. какие тэги (описание которых представлено ниже в данной главе) соответствуют данному объекту.
Expires	Содержит дату/время окончания срока действия ресурса.
Last-Modified	Содержит дату последней модификации ресурса.

Пустая строка (CRLT)

Пустая строка обозначает копей предшествующего заготовка сообшения и начало тела
сообщения.
Тело сообщения

Тело сообщении — это собственно информация, предназначенная для пользователя.
В заголовках сообщений содержится информация, предназначенная для прочтения бра-
узером.

Ответы HTTP, коды состояния и ошибок

Во всех протоколах, которые функционируют достаточно надежно, серверы выдают
ответные сообщения на полученные ими запросы. Сообщения, содержащие ответы на
запросы, позволяют клиенту узнать информацию о происходящих процессах посредством
определенною набора кодов и синтаксических конструкций, подчиняющихся специаль-
ному формату Ответные сообщения формируются согласно следующему формату:

•	Строка состояния обработки запроса (Status Line)

•	Заголовки (Headers)

•	Пустая строка (CRLF)

•	Тело сообщения (Message body)

В строке состояния указывается версия протокола Непосредственно за строкой со-
стояния следует код состояния обработки 'запроса и короткая текстовая строка с описа-
нием состояния. Состояние обработки запроса HTTP и коды ошибок формируются со-
гласно тому же трехзначному цифровому формату, что и в случае протокола FTP
(протокол FTP рассматривается в главе 12). Значение этих колов варьируется от инфор-
мационных сообщении до предупреждений о неудачном завершении обработки запро-
са. Первая цифра соответствует обшей категории сообщения Последних две цифры
идентифицируют сообщение в рамках данной категории В RFC 2616 специфицируют-
ся следующие категории сообщении:

•	1хх: Информационное сообщение Запрос принят, процесс обработки продолжа-
ется.

•	2хх: Успешное принятие операции. Запрошенная операция успешно получена,
понята и принята к исполнению.

•	Зхх; Сообщение о перенаправлении. Для полного завершения обработки запроса
требуются дополнительные действия

•	4хх: Ошибка клиента Запрос содержит сншаксическую ошибку или не может быть
выполнен.

•	5хх: Ошибка сервера. Полянка сервера выполнить запрос завершилась неудачей.

В таблице 15 5 представлены особые коды состояния обработки запроса и нх значе-
ния.

Таблица 15.5 Коды состояния обработки sai оосов HTTP и их значения________

Код состояния Значение	_________________________

100_____________Продолжить (Continue)__________________________________

101	_______ Переключающие протоколы (Switching protocols)____________

gOO Обработка запроса успешно завершена (Okay)____________________________
Код состояния	Значение
201	Запрос создан (Created)
202	Запрос принят (Accepted)
203	Информация не авторизована (Non-authont?tlve information)
’04	Нет содержимого (No content)
205	Переустановить содержимое (Reset content)
206	Неполное содержимое (Partial content)
300	Множественный выбор (Multiple cLoiCes)
301	Перемещен постоянно (Mi vea permanently)
302	Перемещен временно (Moved temporarily)
303	Следовать другим запросам (See other)
304	Ресурс не модифицирован (Not modified)
305	Использовать прокси (Use proxy)
400	Запрос сформулирован некорректно (Bad request)
401	Неавторизованный ресурс (Unauthorized)
402	Требуется оплата (Needs payment)
403	Запрещен доступ к ресурсу (Prohioited)
404	Pecypi не найден (Not found)
405	Метод не разрешен (Method not allowed)
406	Запрос неприемлем (Unacceptable)
407	Требуем аутентификация прокси (Needs proxy authentication)
408	Тайм-аут приема запросов (Requests time out)
409	Конфликт (Conflict)
410	Запрос уиален (Gone)
411	Требуете.) длина (Neeos length)
412	Не выполнено входное условие (Precondition failed)
413	Слишком большой размер объекта запроса (Request entity too large)
414	Слишком больший размер указанного в запросе URL (Request URL too large)
415	He поддерживается тип физического носителя (Mndiu type not supported)
500	Ошибка внутреннего сервера (Internal Server error)
501	Запрос не реализован (Unimplemented)
502	Шлюз неисправен (Bad gateway)
503	Служба недоступна (Unavailable service)
504	Тайм-аут в работе шлюза (Gateway time out)
505	Не поддерживается версия HTTP (HTTP version unsupported)

Сообщения об ошибках HTTP

Вероятно, каждый польтовагель сталкивался в своей практике с ситуацией. копа
после длительною серфинга по Web-сайтам в адрес браузера пользователя приходит
постное сообщение “Запрос некорректно сформулирован" (Bad Request) Сообщения
подобного типа поступают в адрес клиента НПР в случае. когда Web-ссрвер получает
запрос, в котором содержа гея ошибки, как правило, такой запрос отправляется браузе-
ром. и именно браузер предпринимает безуспешные попытки продемонстрировать
пользователю, что требуется серверу для успешного приема запроса. Сообшения об
ошибках создаются сервером HTML (Hypertext Markup Language, Язык разметки гипер-
текста) Документ HTML состоит из текста, предназначенною для пользователя, а так-
же из заключенных в угловые скобки команд для компьютера, задающих правила ото-
бражения документа. Эти команды, называемые 1акже тэгами (lags), представляют собой
нечто большее, чем просто симно 1Ы. Эти тэги дотжпы показаться знакомыми пользова-
телю, который занимается программированием.

Поступающие в адрес клиента HTTP сообщения об ошибке выглядят в формате HTML
следующим образом.

<нтмь>

<HEADXTITLE>400 Bad Requsst</TITLE>

</HEAD>

<BODY>

<Hl>Bad Request</Bl> Your browser sent a request
that this server could not understand.

</BODY>

</HTML>

Заголовок документа HTML (другим* словами — все, что находится между тэгами
<HEAD> и </НЕАЕ») предназначен для браузера. Пользователь видит то зько тело со-
обшения.

Резюме

Протокол пересылки гипертекстовых фай юв (HTTP) функционирует в качестве ка-
нала передачи данных между браузером пользовате 1Я и сервером, когда пользователь
предпринимает попытку найти и открыть Web-страницу. Браузер работает как приклад-
ная программа, открывающая Wcb-стрпницы для пользователя. Чтобы Web-страница
была доступна для восприятия полигона! едем. она выводится на экран посредством гра-
фического пользовательского интерфейса (GUL Graphical User Interface).

Протокол HTTP обладает особыми характеристиками. Он не гарантирует надежность
доставки данных (эго делает протокол TCP на транспортном уровне) и не выполняет
повторную пересылку поврежденных данных. Сервер HTTP не архивирует данные о
сеансах связи и о HTTP запросах пользователя. Протокол HTTP поддерживает двунап-
равленную передачу данных которая подразумевает одновременную передачу сообще-
нии or сервера к браузеру и от браузера к серверу Протокол HTTP предоставляет бра-
узерам и серверам возможность соыасования деталей процесса обмена запросами и
ответами Для экономии времени протокол HTTP использует кэширование и поддер-
живает применение промежуточных устройств таким образом, чтобы каждое из них было
способно функционировать в качестве прокси-сервера HTTP.

Прокси-серверы обеспечивают процесс обмена информацией между агентом пользо-
вателя (UA) и сервером-источником. Aieiiiu поаьюнатедя формирую! oi имени пользе-
вате (я запрос на извлечение ресурса из какого-нибудь Web-сайта и передают этот зап-
рос в адрес сервера-источника Сервер-источник, имеющий доступ к запрашиваемому
ресурсу, передает его в адрес пользователя в своем ответе на запрос.

Сеанс HTTP инициируется открытием браузера и формированием запроса на извле-
чение информации. Протокол TCP на ранспорт ном уровне гарантирует надежную до-
ставку данных в пункт назначения. Запрос передается на сервер-источник или на про-
межуточный хост Протокол Н ГТР идеи।ифииирует запрашиваемый ресурс по его URI
(Uniform Resource Identifier. Унифицированный идентификатор ресурса), URL (Uniform
Resource Locator, Унифицированный указатель ресурса) или URN (Uniform Resource
Name, Унифицированное имя ресурса). Все эти идентификаторы ресурса формируются
в соответствии с общим соишшением об именовании ресурсов На шания URI, URL и
URN — это разные имена одною и тою ж сервиса, однако между ними существуют
определенные отличия Эти небольшие отличия состоят в следу ющем: как правило. URL
или URN идентифицируют компьютер, на котором расположен ресурс; URI идентифи-
цирует ресурс полностью (пш ресурса, хост, на котором он находится и путь к этому
хосту).

Вопросы для повторения

I.	Объясните назначение протокола HTTP.

2.	Какую функцию выполняет протокол HTTP по отношению к браузеру и серверу?

3.	Какие действия выполняет браузер9

4.	На каком уровне функционирует протокол HTTP и как по влияет на ею возмож-
ности?

5.	Перечислите характеристики протокола HTTP

6.	Обьяснше, каким образом поддержка кэширования протоколом HTTP влияет на
’ффективность получения доступа к требуемому ресурсу

7.	Объясните функции прокси-сервера.

8.	Какие компоненты протокола HTTP функционируют в качестве прокси9

9.	Опиши к общий формат сообщений HTTP.

10.	Для кою предназначено тело сообщения?

11.	Какой программный компонент HTTP считывает информации указанг-ю в заю-
ловках сообщении HTTP?

12.	Назовите программный компонент HTTP, благодаря которому пользователь полу-
чает сообщения об ошибках.
Глава 16

Простейший протокол
передачи файлов (TFTP)

В данной главе рассматриваются следующие темы:

•	Типы пакетов TFTP (TFTP Packet Types)

•	Действие TFTP (TFTP Operation)

•	Расширения TFTP (TFTP Extensions)

Краткая характеристика протокола TFTP

Из всею множества протоколов, использующих семейство TCP/IP, Л1Я передачи
файлов, чаше всего используется протокол FTP (см. главу 12). Однако не все приложе-
ния нуждаются нбольшом объеме функциональных возможностей протокола FTP. Кроме
того, не все приложения имеют в своем распоряжении достаточное количество ресур-
сов для поддержки работы столь сложного протокола, как FTP. Например, протокол FTP
требует от клиентов и серверов установки, обслуживания и организации работы несколь-
ких ТСР-соединенпй. Выполнение этого требования может оказаться существенной про-
блемой для тех компьютеров, которые функционируют под управлением достаточно
простой операционной системы или не имеют большого объема памяти. Функциониро-
вание протокола ГТР на компьютерах с отраниченными ресурсами может оказаться
невозможным Кроме тою, для некоторых пользователей протокол FTP может оказать-
ся трудным для реализации.

В стеке протоколов TCP/IP предусмотрено решение упомянутой выше проблемы, а
именно — пересылка данных с использованием простейшего протокола передачи фай-
лов (ТГГР. Trivia) File Transfer Protocol) Протокол TFTP обеспечивает простую по сути,
несложную в применении и недорогую для реализации службу пересылки фантов меж-
ду хостами Каждый сеанс обмена файлами начинается с запроса клиента на чтение или
на запись файла с сервера. Протокол ТЕГР не предлагает никаких других услуг, кроме
элементарной, быстрой пересылки файлов, что делает этот протокол очень простым и
выюдно отличает его от других, более сложных протоколов. Спецификация TFTP оп-
ределена в документе RFC 1350

Первоначально протокол TFTP разрабатывался для встраивания в ПЗУ сетевых плат
Ethernet бездисковых рабочих станций. Однако в настоящее время TFTP поддерживает-
ся и другими архитектурами передачи данных Исходная версия TFTP позволяет пере-
давать блоки данных размером 512 бант через UDP-порт 69; в то же время современные
реализации TFTP поддерживают передачу блоков данных большего размера. В отличие
от TCP и FTP протокол ТЕГР не требует аутентификации пользователя, но и не гаран-
тирует доставку данных в пункт назначения. Дли установления связи и транспортиров-
ки данных сторона-отправитель (клиент ТЕТР) прежде всего открывает изменяемый кли-
ентский UDP-порт. на который можно сослаться либо как на TFTP-порт. либо по
идентификатору порта передачи данных (transfer ID. TID). Далее сторона-отправитель
запрашивает пересылку тою или иною файла и ожидает подтверждения о получении
стороной-получателем каждою блока данных перед отправлением следующего блока.
Сторона-получатель, в свою очередь, подтверждает прием каждого блока данных.

В отличие от протокола FTP, который использует для установления связи и транс-
портировки данных два ТСР-соечинения. пересылка файлов посредством протокола
ТЕТР не мечет за собой больших непроизводительных затрат, поскольку при атом в
качестве транспортною протокола используется нс ориентированный на создание со-
единения протокол UDP. С трутой стороны использование UDP не позволяет протоко-
лу TFTP гарантировать надежность цзставки донных в пункт назначения. Однако именно
применение протоко та UDP для транспортировки данных делает ТЕТР более удобным
в эксплуатации; этим объясняется простота TF1 Р по самой своей сути, а также назва-
ние этого протокола — "простейший протокол пере гачи файлов" Поскольку рамки фун-
кциональных возможностей TFTP изначально ограничены простой пересылкой файлов
между хостами. »тот протокол обеспечивает упрошенный способ решения проблемы
пересылки файлов по сравнению с протоколом FTP. TFTP, будучи небольшим по объе-
му приложением, может легко поместиться в постоянном запоминающем устройстве
(ПЗУ) хоста, и поэтому может оказаться чрезвычайно важным для бездисковых устройств.

Бездисковая рабочая станция, поддерживающая прогокоч TFTP. может получить
копию затру точною файла или набор конфигурационных параметров из памяти удален-
ного сервера при включении в сеть. Эго позволяет бездисковому клиенту загружать
необходимые для инициализации параметры в удаленном режиме. Преимуществом TFTP
является то, что этот протокол позволяет операционной системе использовать иротрам-
му самозагрузки, которая хранится па сервере Т1~ГР Например. TFTP позволяет вы-
полнить самозатрузку компьютера с локальною или удаленного сервера TFTP уже при
включении компьютера в сеть.

Типы пакетов TFTP

Простота реализации протокола TFTP соответствует элементарной структуре этого
протокола. Первый передаваемый клиентом пакет содержит в себе тапрос на пересылку
того или иного фагота (с сервера); пере гача данного пакета инициирует установление
связи между изменяемым клиентским UDP-портом (известным под названием TID) и
общей шестым серверным портом TFTP с номером 69 В этом пакете указывается имя
файла, а также тип производимой с файлом операции: чтение (RRQ, Read Request, зап-
рос на чтение — зга операция предполагает пересылку требуемого файла с сервера в адрес
клиента) или запись (WRQ. Write Request, запрос на запись эта операция означает
передачу файла от клиента к серверу).
Протокол TFTP выполняет залачх чтения или записи файла посредством пересылки
непрерывного потока дейтаграмм в блоках данных, имеющих размер 512 байтов (блоки
данных могут иметь больший размер, если реализованы соответствующие расширения
TFTP). Заключительный блок данных должен содержать менее 512 байтов данных (или
менее сконфшурированною на данном устройстве размера блока данных), что указы-
вает на копен потока данных. Любая ошибка, возникшая в процессе пересылки файла,
прерывает процесс пересылки. Существует пять различных типов пакетов TFTP. В таб-
лице 16.1 представлены все типы пакетов TFTP и их описание. Указание в заголовке
TFTP соответствующего кода операции (Opcode) позволяет определить, какой именно
пакет передается в данной дейта! рамме.

Таблица 16.1 Типы пакетов TFTP

Код операции	Тип пакета Действие
1	Запрос на чтение — Read Request (RRQ)	
2	Запрос на запись — Write Request (WRQ)
3	Данные — Data (DATA)
4	Подтверждение — Acknowledgement (ACK)
5	Ошибка — Erroi (ERROR)

Па рис. 16.1 показан форма! различных типов пакетов TFTP.

Код операции	Имя файла	0	Режим	0

2 Строка символов 1 Строка символов 1 Октеты
Пехоты RRQ/WRQ

РИСУНОК 16.1

Два начальных байта (кой
операции, Opcode) мдают
формат сообщении ТГТР
Ciedyem обратить
внимание на то. что
пакеты ЯЯС и И RQ
имеют одинаковый
формат Первый
отправыемый клиентам
пикет йолмен быть
пикетом типа RRQ и ш
ИЯР

КОД
с. «рации

Номер
блока

Данные

2	0-512

Пакет Data Сланные)

2

Код операции	Номер бл.эта

2	2 Октеты

Октеты

Пакет АСК (подтверждение)

Код операции	Кодошибки	Сообщение об ошибке	0

2	2 Строка символов 1 Октеты

Пакет Error (Ошибка)

Пакеты RRQ и WRQ

Как упоминалось выше, пакеты RRQ и WRQ (пакеты типа I и 2) имеют одинаковую
структуру. Передача этих пакетов начинает запрос; в этих же пакетах указывается, ка-
кой файл необходимо переслать. В таблице 16.2 представлено описание полей, из кото- рых состоят пакеты RRQ и WRQ.  Таблица 16 2 Поля пакетов RRQ и WRQ		
Поле	Октеты	Описание
Код операции (Opcode)	2	Идентифицирует тип пакета  •	1 = RRQ  •	2 = WRQ
Имя файла (Filename)	Строка	Строка символов сетевой системы кодирования netascii (аналогичной ASCII) — 8-разрядный код, определенный ANSI (Национальным Институтом Стандартизации США) в 1968 г. в документе Х3.4. Буквенно-цифровые символы этой системы кодироаания специфицируют имя файла и предназначены для прочтения пользователями (а не компьютерами).
Ноль (2 поля) (Zero)	1	Завершает поля "Имя файла’ (Filename) и "Режим” (Mode).
Режим (Mode)	Строка	Задает режим передачи:  •	Netascii  •	Октет (ряд 8-разрядных байтов)  •	Почтовый режим (символы netascii. предназначенные для пользователя, а не для хоста): в настоящее время этот режим вышел из употребления.

Пакеты Data (Данные)

В пакетах Data (Данные), или пакетах гипа 3, передаются запрашиваемые клиентом
данные В таблице 16.3 представлено описание полей, из которых состоит данный тип
пакетов.

Таблица 16.3 Поля пакета Data (Данные)		
Поле	Октеты	Описание
Код операции (Opcode)	2	Значение 3. установленное в данном поле, идентифицирует пакет "Данные".
Номер блока  (Block Number)	2	Идентифицирует отдельный блок данных фиксированного размера
Данные (Data)	0-512	Содержит фактически подлежащую пересылке информацию. Любой блок данных, содержащий меньше 512 байтов информации или меньше максимальной длины специально сконфигурированного блок (максимальная длина которого 65 464 байта), означает конец процесса передачи данных Более подробную информацию о средствах расширения размера блоков можно найти в RFC 2348

Пакет АСК (подтверждение)

Пакет АСК (пакет типа 4) подтверждает прием каждого блока данных (пакета
Data), поступивших в адрес получателя в процессе пересылки данных Протокол
ТГТР использует метод обязате п>ного пошаювого подтверждения приема (the lock-slep
acknowledgement method), что предполагает выдачу подтверждения о приеме каждого
пакета до Пересы 1ки следующего пакета. Следует помнить о том. что TFTP передает по
одному блоку за одни раз; нумерация пересылаемых блоков производится с первого блока
(номер 1). Поскольку TFTP функционирует на базе транспортного протокола UDP. при
передаче файлов посредством этою протокола не предусмотрен оконный механизм пе-
редачи данных. Проюкол TFTP должен подтверждать получение всех пакетов, за нс
ключенисм пакетов, содержащих сообщения об ошибках. В пакетах АСК (подтвержде-
ние) или Error (Ошибка) передается подтверждение приема пакетов Data (Данные) и
WRQ (запрос на запись), в то время как в пакетах Data или Error передается подтверж-
дение приема пакетов RRQ (запрос на чтения) и АСК (подтверждение).

В таблице 16.4 представлено описание полей, из которых состоят пакеты АСК (под-
тверждение).

Таблица 16 4 Поля пакета АСК

Поле	Октеты	Описание
Код операции (Opcode)	2	Значение 4. установленное в данном поле, идентифицирует пакет АСК
Номер блока (Block Number)	2	Соответствует номеру блока, указанному в аналогичном поле пакета "Данные .

Пакеты Error (Ошибка)

В пакете Error (Ошибка), или пакете типа 5 содержится подтверждение приема па-
кетов всех других типов, а также сообщение о возникновении ошибки. Код ошибки —
это число, которое указывает на то, какая именно ошибка возникла. Сообщения об
ошибках предназначены для пользователей и кодируются символами netascii. Большин-
ство ошибок вызывают аварийное завершение процесса пересылки данных В таблице
16.5 представлено описание полей образующих пакет Error (Ошибка).

Таблица 16.5 Поля пакета "Ошибка"

Поле	Октеты	Описание
Код операции (Opcode)	2	Значение 5, указанное в данном поле, идентифицирует пакет "Ошибка".
Код ошибки (Error code)	2	Представляет описание возникшей в процессе пересылки файла проблемы, используя различные кодь ошибок (см. таблицу 16.6).
Сообщение об ошибке (Error message)	Строка	Строка символов netascii.
Ноль (Zero)	1	Завершает пакет

При возникновении ошибки хост отсылает пакет Error (Ошибка), чтобы прервать
связи и прекратить пересылку файла. Выдача пакетов этою типа может быть вызвана
одним из следующих событий:

•	Хост не имеет возможности выполнить запрос (например, не может определить,
|дс находится файл).

•	Хост получает задержанный или дублированный пакет.

•	Хост теряет доступ к какому-либо ресурсу (такому, как диск) в процессе пере-
сылки файла.
В поле кода ошибки (Error code) имеющем длину 2 байта, содержится значение опи-
сывающее характер возникшей ошибки. В таблице 16.6 перечислены все коды ошибок
и их значения.

Таблица 16.6 Значения кодов ошибок

Значение	Описание
0	Значение не определено, см сообщение об ошибке (если оно есть)
1	Не удается найти файл.
2	Нарушение доступа
3	Диск переполнен или превышен объем выделенной памяти.
4	Запрещенная операция TFTP
5	Неизвестный порт TJD
6	Файл уже имеется в наличии.
7	Пользователь не обнаружен.

Действие TFTP

Как было упомянуто выше, клиент TFTP инициирует установление соединения по-
средством передачи запроса на запись или на чтение файла с сервера. Соединение уста-
навливается между изменяемым клиентским портом отправителя (TFTP Т1D) и обще-
известным серверным TFTP-портом 69 получателя. Клиент указывает идентификатор
файла и тип данных в начальном запросе. После отправления клиентом начального зап-
роса происходит переназначение нового UDP-порта для использования этого порта в
качестве порта ТГТР T1D на время текущего сеанса передачи данных Собственно про-
цесс пересылки файла начинается после назначения новою порта. Если клиент отправ-
ляет запрос на чтение, сервер начинает пересылку, если же клиент отправляет запрос
на запись — передачу файла начинает сам клиент

На транспортном уровне ТПР использует протокол UDP, указывая имя TID в ка-
честве идентификатора назначенных клиенту и серверу TFTP UDP портов. Перед пе-
редачей файла отправитель вычисляет контрольную сумму на том фрагменте дейтаграм-
мы UDP, который соответствует заголовку TFTP Получатель проверяет эту контрольную
сумму (сравнивая ее с результатом собственных вычислений), чтобы убедиться в том.
что нн один бтгг данных не был поврежден но время пересылки. Процесс передачи дан-
ных продолжается до тех пор, пока клиент или сервер не передаст весь файл. Рис. 16.2,
16.3 и 16.4 иллюстрируют процесс передачи клиентом TFTP запроса на чтение; здесь же
представлено описание передачи этого запроса кадр за кадром.

Протокол TFTP реализует процесс обмена запросами и ответами на основе простой
схемы выдачи позиверждепии в порядке получения блоков данных, передавая при этом
только по одной дейтаграмме за один раз. Каждый раз, когда отправитель передает дей-
таграмму, он сохраняет эту дейтаграмму в своем буфере на случай возникновения не-
обходимости в повторной передаче. В случае подери этой дейтаграммы какой-либо из
сторон отправитель в конечном итоге обнаруживает это. поскольку он не получает под-
тверждения о приеме дейта) раммы oi другой стороны. По истечении тайм-аута отпра-
витель выполняет повторную передачу потерянной дейтшраммы, которая была сохра-
нена в его буфере.
РИСУНОК 16.2 На данном рисунке клиент TFTP 128.1.0.2 (UDP-nopm 1001. uru TH)) передает в
адрес сервера TFTP 128 10 1 (UDP порт о9) запрос на чтение файла Junk.txt. Заголовок UDP не
содержит никакой информации об упорядочивании передаваемых блоков, в соответствующих полях
заголовка UDP указана только контрольная сумма и длина передаваемой дейтаграммы.

Расширения TFTP

Расширение первоначальных спецификации TFTP явилось следствием возросшей не-
обходимости в согласовании параметров (option negotiation) пересылки файлов между
клиентом и сервером В расширениях TFTP (TFTP extensions) представлено описание
только одного специального параметра пересылки (размера блока данных, blocksize); с
другой стороны, эта спецификация является достаточно полной для того, чтобы постав-
щики сетевых услхт имели возможность реализовать тот набор параметров пересылки,
который им необходим Возможность передавать с помощью протокола TFTP блоков
данных большего размера значительно увеличивает производительность пересылки фай-
лов между удаленными хостами. В предшествующей реализации TFTP не поддержива-
ется |акое расширение, что ограничивает возможности обмена файлами пересылкой
б юков данных, имеющих стандартный размер 512 байтов.

Процесс согласования параметров контролируется клиентом. Сервер не может вы-
ла 1ь запрос на согласование параметров; он может только ответить клиенту на соответ-
ствующий запрос. Если клиент намерен реализовать дополнительные параметры пере-
сылки файлов, выходящие за рамки обычной спецификации TFTP, он имеет возможность
присоединить соответствующие данные к исходному запросу на чтение или на запись.
РИСУНОК 16.3 Второй кадр, изображенный на данном рисунке, содержит передаваемое без
установления прямого соединения подтверждение от сервера TFTP о приеме блока данных. В зтом
кадре указано, что было выполнено переназначение VDP-nopma со случайно выбранным номером
Данному серверу назначен новый UDP-порт (TID) с номером 1487.

Серверы TFTP, поддерживающие согласование параметров, могут передавать пакет
ОАСК (Option acknowledgement, подтверждение параметра); с помощью этого пакета
сервер сообщав клиенту, поддерживает ли он данный параметр. Когда сервер прини-
мает указанный параметр, он включает его в свой пакет ОАСК. Если сервер не прини-
мает параметр, он попросту игнорирует ею, не включая в состав кадра ОАСК.

Клиенты TFTP могут реализовывать только разрешенные серверами параметры. В
процессе cotласования клиент может отправить запрос на согласование совокупности
параметров, просто перечислив их в пакете RRQ (чтение) или WRQ (запись). Запрос на
согласование параметров присоединяется клиентом в стандартный запрос на чтение или
запись, используемого для инициализации сеанса связи между клиентом и сервером. Для
клиентов, поддерживающих согласование параметров, к заголовку пакета присоединяют-
ся два дополнительных кадра, coot встствующих следующим полям параметр (Option) — это
поле специфицирует собственно запрашиваемый параметр (например, размер блока
данных, blocksize); значение (Value) — в этом поле указывается значение данною пара-
метра. Например, размер блока пересылаемых данных может варьировать от 0 до
65 464 байтов.
РИСУНОК 16.4 На данном рисунке показан процесс передачи отправите гем первого блока донных,
входящего в состав передаваемого потока данных.

Пакет О АСК

Пакету ОАСК соответствует значение 6, указываемое в ноле кода операции (Opcode).
Сервер TFTP отправляет пакет ОАСК с целью отклонения или подтверждения запра-
шиваемых сервером параметров пересылки файлов. В таблице I6.7 представлено описа-
ние полей пакета ОАСК. Пара "параметр — значение" повторяется столько раз. сколько
параметров указано в запросе на сотласованис.

Таблица 16.7 Поля пакета ОАСК_______________________________________________

Поле	Октеты	Описание
Код операции 2 (Opcode)	Значение 6. указанное в поле кода операции, идентифицирует пакет ОАСК.
Параметр!	2  (Option!)	Соответствует первому параметру, входящему в состав списка параметров, представленного а пакете RRQ или WRQ клиента. Дополнительным параметрам, указанным в этом списке.  соответствуют поля Option2, Options и т.д.
Значение!	2  (Vamel)	Соответствует значению первого параметра, входящего в состав списка параметров, представленного в пакете RRQ или WRQ клиента Значения дополнительных параметров, указанных в этом списке, устанавливаются в полях Value2, Value3 и т.д.
Резюме

Протокол TFTP обеспечивает простую, быструю и недорогую службу пересылки
файлов между хостами. TFTP считывает или записывает файлы для клиента на сервер
или с сервера Каждый обмен данными инициируется выдачей клиентом запроса на
чтение или запись файла с сервера.

Первый отправленный пакет запрашивает пересылку файла с сервера и устанавли-
вает связь между изменяемым клиентским UDP-портом (известным пол названием TID)
и общеизвестным серверным UDP-портом 69. Первоначальная версия TFTP поддержи-
вает передачу файлов блоками данных, имеющими размер 512 байтов. В то же время
текущие реализации TFTP могут передавать блоки данных большего размера. Блок дан-
ных, содержащий менее 512 байтов информации, является последним блоком потока
данных.

Протокол TFTP оперирует пятью типами пакетов данных: RRQ (запрос на чтение),
WRQ (запрос на запись), АСК (подтверждение). Data (данные) и Error (ошибка). В па-
кете RRQ или WRQ указываегся имя подлежащего пересылке файла, а также лип про-
изводимой с файлом операции: чтение (в пакете RRQ) или запись (в пакете WRQ).
Пакеты Data (данные) содержат собственно запрашиваемые данные. Пакеты \СК под-
тверждают прием блоков данных. Пакеты Error (ошибка) содержат сообщения об ошиб-
ках. возникших в процессе пересылки блоков данных.

Вопросы для повторения

I.	Каковы различия между протоколами FTP и TFTP?

2.	Назовите преимущества использования протокола TFTP для пересылки файлов между
хостами.

3.	Дайте краткую характеристику службы пересылки файлов, которую предоставляет
протокол TFTP?

4.	Каким образом начинается каждый сеанс обмена данными?

5.	Какими пятью типами пакетов оперирует протокол TFTP; каковы функции этих па-
кетов?

6.	Признаком чего является блок данных, размер которого менее 512 байтов?

7.	Объясните суть метода обязательного пошаговою подтверждения приема данных. Как
TFTP использует зтот метод?

8	Какие три события могут привести к передаче пакета, содержащею сообщение об
ошибке?

9.	Что означают операции "прочитать файл", "записать файл"?

10.	Дайте краткое описание действия протокола TFTP

11	Расширения TFTP делают возможным согласование параметров пересылки файлов
между клиентом и сервером. Каким образом это влияет на размер передаваемых
блоков данных?

12.	Объясните механизм процедуры согласования параметров.

13.	Объясните назначение и функции пакета ОАСК
Глава 17

SNMP (Простой протокол
управления сетью)

В данной главе рассматриваются следующие темы:

•	Сетевое администрирование (Network Management)

•	Протокол SNMP

•	Диспетчеры, агенты и прокси-агенты SNMP (Managers, Agents, Proxies)

•	Формат сообщений SNMP (SNMP Message Format)

Сетевое администрирование

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

Сетевое администрирование можно интерпретировать по-разному. Согласно одним
представлениям, это — устранение проблем в тот момент, koi да они возникают; соглас-
но другим — это профилактическое предупреждение возникающих в сети проблем еще
до их появления (либо, ио крайней мере, ограничение связанных с работой сети зат-
руднений только незначительными сбоями). Однако какой бы подход к сетевому адми-
нистрированию не был избран — превентивное решение проблем или реагирование на
них постфактум — реализацию обоих подходов обеспечивает протокол SNMP (Simple
Network Management Protocol, Простой протокол управления сетью)

Описание первоначальнои реализации протокола SNMP, который яв гяется основ-
ным протоколом удаленного сетевою администрирования в наши дни, представлено в
документе RFC 1157. Первоначально протоко i SNMP, который быт известен тогда под
названием SGMP (Simple Gateway Management Protocol, Простой протокол управления
шлюзами), был разработан в качестве средства обеспечения удаленною управления хо-
стами и шлюзами сети Интернет. Однако с течением времени этот протокол быт усо-
вершенствован с такой целью, чтобы он мог поддерживать работу всего разнообразия
конечных устройств.

Основная роль в разработке такого протокола управления сетью, который позволил
бы осуществлять сетевое администрирование независимо от конкретных реализаций
npoipaMMHOio и аппаратною обеспечения, принадлежит Совету по архитектуре сети
Интерне! (IAB, Internet Architecture Board). В середине 80-х быти сформированы раз-
личные Интернет-комитеты. целью работы ко юры х было исследование потенциальных
протоколов сетевою администрирования. В результате проделанной работы были вы-
делены следующих три протокола:

•	Протокол HEMS (High-level Entity Management Systems, Высокоуровневая систе-
мах правления объектами ).

•	Протокол SGMP (Simple Gateway Management Protocol, Простой протокол управ-
ления шлюзами) — переименованный в SNMP.

•	Стандартный протокол сетевого администрирования ISO — протокол CMIP
(Common Management Information Protocol, Общий протокол управляющей инфор-
мации).

^ПРИМЕЧАНИЕ

ISO (Internationa) Organization for Standardization, Международная организация по стан-
дартизации) — это одна из международных организации по стандартизации, которая, среди
прочих своих функций, устанавливает специальные стандарты для сетевых протоколов. Наи-
более распространенным стандартом является состоящая из семи уровней эталонная мо-
дель взаимодействия открытых систем OS) (Open System Interconnection Reference Model).

После тщательного изучения упомянутых выше протоколов в качестве протокола,
который можно было бы использовать для сетевого администрирования, на переходный
период был избран протокол SGMP Однако в будущем планировалось преобразовавь зтот
протокол в соответствии с требованиями стандарта сетевого администрирования ISO —
протокола CMIP. Pets штатом усовершенствования имеющеюся протокола SGMP стал
протокол SNMP, который, как упоминалось ранее, до сих пор остается наиболее широ-
ко используемым протоколом сетевою администрирования и является официальным
стандартом в сфере организации компьютерных сетей.

Протокол SNMP предоставляет средства независимого от конкрстных реализаций
управления сетью. Информация, необходимая для осуществления сетевого администри-
рования всеми упомянутыми выше протоколами, изложена в документах RFC 1065 и
1066. В 31 их документах представлено описание способа идентификации управляемых
объектов (managed objects) посредством языка ASN.l (Abstract Syntax Notation I, Абст-
рактная синтаксическая нотация версии 1). Система ASN.1 представляет собой способ
представления управляемых объектов через условно сформированные структуры данных
(arbitrary data structures).

Согласно RFC 1156, стандартные базы данных М1В сети Интернет (MIBs. Management
Information Bases, Базы управляющей информации) — MID I и MIB II, идентифициру-
ют общеизвестные управляемые объекты и представляют их логическое описание в ка-
честве составной части обшей иерархической древовидной структуры управляемых
объектов сети Интернет. Все реализации SNMP должны поддерживать стандарты MIB
хотя бы в минимальном объеме. С другой стороны, для каждой версии SNMP возможна
реализация отдельного поддерева MIB. в состав которого входили бы управляемые объек-
ты, отвечающие определенным ъ RFC 1156 требованиям SMI (Structure of Management
Information. Структура управляющей информации).
Протокол SNMP

Протокол SNMP функционирует на основе транспортною протокола UDP и обес-
печивает быструю доставку управляющих запросов и ответов между хостами, на кото-
рых реализованы выполняющие SNMP приложения (такие как SunNelM.tnager компа-
нии Sun или Open View корпорации HP). Упомянутые приложения — эго только
небольшая часть всего множества приложений, использующих протокол SNMP для уда-
ленною мониторинга и управления поддерживающих SNMP yciponcTB.

Протокол SNMP предоставляет услуги по доставке управляющих запросов и ответов
от имени приложений SNMP функционирует независимо оз особенностей приложении,
а также независимо от конкретной архитектуры сети на нижнем или верхнем уровне.
Это делает протокол SNMP достаточно простым и применимым для целою класса при-
ложений; несмотря на простоту, SNMP является мощным протоколом сетевого адми-
нистрирования, применимым на различных платформах, с различными операционны-
ми системами и протоколами. Исторически сложилось так. что протокол SNMP
функционирует в сочетании с протоколом IP. однако благодаря своей универсальной
сущности этот протокол может работать и на базе друз их протоколов, таких как прото-
кол IPX

Протокол SNMP имеет в своем составе три основных программных модуля, кото-
рые делают возможным удаленное управление сетью:

•	Диспетчер (Manager) — программный модуль, в состав которого входят програм
мы-генераторы команд (command generators) и программы-получатели уведомле-
нии (notification receivers).

•	Агент (Agent) — программный модуль, в состав которого входят программы-ис-
полнители команд SNMP (command responders) и программы-создатели уведом-
лений (notification originators).

•	Прокси-агент (Proxy) — программный модуль, в состав которого входят програм-
мы. обеспечивающие продвижение управляющей информации в пункт назначе-
ния (forwarders).

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

Диспетчеры SNMP

Диспетчеры SNMP функционируют на базе отдельных хостов и выполняют управ-
ляющие прикладные программы сетевого администрирования (такие как Open View) для
гою, чтобы осуществлять удаленный контроль и мониторинг (отслеживание работы)
агентов SNMP. Эти хосты осуществляют общее руководство системой, а также реализу-
ют пользовательский интерфейс с применением элементов SNMP, предназначенный для
выполнения доставки команд агентам. Это дает операторам возможность получать нуж-
ную информацию, изменять конфигурационные параметры и даже перезагружать уда-
ленный компьютер. Диспетчеры SNMP получают также незатребованные (то есть вы-
даваемые без запросов) сообщения (unsolicited messages), содержащие уведомления о
состоянии системы (сообшения такого типа известны под названием "Trap messages") —
сообшения, получаемые диспетчерами от агентов SNMP и содержащие отчеты агентов
о наиболее важных событиях или нарушениях, возникших в работе системы Среди та-
ких нарушении может быть команда о необходимости изменении конфигурационных
параметров, полученная неполномочным диспетчером SNMP (unauthorized SNMP
manager).

В качестве примера запросов SNMP можно привести запросы двух типов: Get-requests
("Получить”), используемые для получения управляющей информации, а также Set-
requests ("Установить"), используемые с целью установления управляющих параметрон.
Диспетчеры SNMP направляют свои запросы в пункт назначения через UDP-порт 161,
открытый для агента SNMP. Незапрашиваемые информационные сообшения (сообше-
ния Trap) агентов SNMP прослушиваются диспетчерами SNMP через UDP-порт 162.

Агенты SNMP

Агенты SNMP функционируют на базе отдельных хостов и реализуют свою работу с
помошью программ, которые обеспечивают выполнение команд SNMP и формируют
уведомления о состоянии системы. Агенты SNMP прослушивают запросы SNMP, отправ-
ляемые диспетчерами через UDP-порт 161. Диспетчеры SNMP запрашивают у агентов
информацию, которая хранится в локальной базе данных, известной под названием М!В
(Management Information Base, База управляющей информации). Поскольку программ-
ное обеспечение агента SNMP имеет достаточно небольшой размер, оно помешается в
микросхемы ПЗУ. которые, как правило, включаются в состав аппаратного обеспече-
ния устройств, поддерживающих работу SNMP-aieiiTOB (таких как ириемопередаюшии
nopi (transceiver port) для маршрутизаюра или коммутирующий интерфейс (switch
interface)). Агенты SNMP отслеживают работу базы данных MIB, имеющую иерархичес-
кую древовидную структуру и состоящую из множества подлежащих управлению и мо-
ниторингу объектов.

Например, сетевой интерфейс Ethernet интерпретирует такой управляемый объект,
как маршрутизатор, посредством отдельного агента SNMP С помошью этою агента
можно было бы отслеживать конкретную информацию, касающуюся прохождения ин-
формационною потока через интерфейс данного маршрутизатора (например, информа-
цию о количестве широковещательных сообщении, сведения об обнаруживаемых посред-
ством алгоритма CRC ошибках, данные о возникновении конфликтных ситуации, и т.д.).

В дополнение к способности агентов SNMP отвечать на запросы диспетчеров SNMP
о получении или изменении какой-либо конкретной информации, разработчиками про-
токола SNMP предусмотрена возможность конфигурирования агентов SNMP таким
образом, чтобы они отсылали в адрес диспетчеров уведомления о проблемах, возника-
ющих в процессе работы системы. Механи jm уведомления диспетчеров SNMP реализу-
ется посредством передачи незатребованных (то есть выдаваемых без запросов) сооб-
щений Trap. Сообшения такого типа передаются в адрес диспетчера SNMP либо в случае
возникновения проблемы, либо в случае нарушения полномочии, другими словами, когда
агент SNMP получает запрос на изменение параметра от ненолномочного диспетчера
SNMP. Агенты отправляют в адрес диспетчеров сообшения Trap через UDP порт 162
Модуль MIB

Каждый «пент SNMP хранит свой набор локально управляемых объектов в своей базе
данных Mill, называемой также моду чем MIB (MIB view). Для получения доступа к
какому-либо из содержащихся в модуле MIB объектов диспетчер должен указать имя
объекта (object name), присвоенное объекту в соответствии с системой условных обо-
значении ASN.I. Система ASN.1 точно описывает месторасположение объекта в базе
управляющей информации, а также привязку уникальных параметров объекта к управ-
ляемому устройству.

Имя объекта, идентифицирующее месюрасположение этою объекта в информаци-
онной базе, состоит из последовательности целых чисел, описывающей путь к объекту
по дереву базы данных Ml В. Поставщики сетевых услуг могут зарегистрировать специ-
альные идентификаторы для своих собственных поддеревьев, что дает им возможность
расширить древовидную структуру сети Интернет, включив в состав сети свои объекты
в качестве отдельных составляющих Выделением идентификаторов поддеревьев для
различных административных единиц сети Интернет занимается организация IANA
(Internet Assigned Numbers Authority Агентство по выделению имен и уникальных па-
раметров протоколов сети Ишернет).

Прокси-агенты SNMP

Прокси-агенты протокола SNMP обеспечивают продвижение сообщении между аген-
тами и диспетчерами SNMP. Прокси-агент функционируют также в качестве проме-
жуточных звеньев между агентами хостов, поддерживающими разные версии протоко-
ла SNMP, что обеспечивает совместимость этих хостов.

Ассоциация

Для того чтобы начать прием запросов, а также иметь информацию о том, кому и
куда отсылать уведомления о возникших нарушениях и проблемах, агенты SNMP дол-
жны зарегистрировать свои связи с соответствующими диспетчерами. Способ иденти-
фикации агентами диспетчеров SNMP, а также способ ре1истрании связей с этими дис-
петчерами, зависит от конкретной реализации. Для упрощения организации процедуры
обмена сообщениями агенты и диспетчеры SNMP должны обязательно входить в состав
одного и тою же домена, который известен как ассоциация (community). Существует
только один домен, который используется по умолчанию, — корневой домен (public
domain). С другой стороны, на том же множестве управляемых объектов можно выде-
лить другие ассоциации. Формирование других ассоциаций, которым можно присваи-
вать произвольно выбранные имена, позволяет шраничть несанкционированный дос-
туп к управляемым объектам.

Если кто-то пожелает подключить к сети свои управляющий хост с целью получе-
ния несанкционированного доступа к агентам SNMP, в первую очередь ему придется
угадать имя ассоциации и соответствующим образом, с использованием именно этого
имени, сконфигурировать свой диспетчер. Безусловно, простое создание новых ассоци-
аций и присвоение им каких-либо зашифрованных имен не помешает умному хакеру
узнать эту "секретную" информацию, гак что аутентификация и списки контроля над
предоставлением доступа (ACL. Access Control Lists -список контроля доступа) крайне
необходимы для зашиты от несанкционированною доступа. Протоколом SNMP аутен-
!ификация и контроль над доаупом не предусмотрены, однако эти функции выполня-
ют те приложения, которые используют в своей работе протокол SNMP.

Если в процесс сетевою администрирования вовлечены прокси-агенты SNMP, они
также должны входить в состав той же ассоциации, поскольку диспетчер SNMP и под-
чиненные ему агенты должны заре! истрировать свои связи с этим прокси-агентом, что-
бы иметь возможность начать процедуру продвижения сообщении по сети. Все обьекты
ассоциации должны быть локально сконфшурированы с именем, присвоенным данной
ассоциации, а также любой другой необходимой информацией, касающейся аутентифи-
кации и защиты от несанкционированною доступа. Агентам необходимо также иметь в
своем распоряжении сетевой адрес диспетчера, чтобы отправлять вею адрес ответы на
все его запросы, а также незатребованные сообщения, содержащие уведомления о воз-
никших проблемах.

Формат сообщений SNMP

Все сообщения SNMP, за исключением сообщения Trap, формируются согласно од-
ной и той же базовой структуре В каждом сообщении передастся номер версии, имя
ассоциации (для обеспечения минимального уровня аутентификации), а также один или
более PDLJ (Protocols Data Unit. Модуль данных протокола) в зависимости от тою. ка-
кая информация запрашивается диспетчером. На рис. 17.1 представлена архитектура
коммуникационной сети с использованием протокола SNMP версии I (SNMPvl). Рис.
17.2 ил.чюс1рнрует базовый формат сообщении SNMP.

Управляющая
система SNMP

Управляемая
система SNMP

РИСУНОК 17.1 Протокол 5Л МР использует своей работе только пять типов сообщений: зто
является частью упрощенного подхода данного протокою к сетевому администрированию
РИСУНОК 17.2 Для формирования всех сообщении ЛЛ МР (Get. Get Next. Set Get-RespomeN за
исключением сообщения Trap, используется один и тот же базовый фюрмит

Поле версии

В поле версии (Version) указывается используемая версия протокола SNMP. Оба уча-
стника процесса сетевою администрирования, как диспетчер, гак и агент, должны ис-
пользовать одну и ту же версию SNMP В противном случае сообщения SNMP должны
передаваться с использованием прокси-агента SNMP, который обеспечивав! совмести-
мость разных версий протокола

Поле имени ассоциации

В данном поле (Community Name) указывается имя ассоциации. Простейший уро
вень аутентификации процесса взаимодействия между диспетчером и агентом обеспе-
чивается их конфигурированием таким образом, чтобы они входи и в состав одной и
той же ассоциации Системные администраторы присваивают ассоциациям идентифи-
каторы, представляющие собой простые текстовые имена, которые используются с це-
лью формирования ipvnn полномочных диспетчеров и агентов SNMP. Агенты могу г
входить в состав только одной ассоциации. Диспетчеры могут быть включены в состав
нескольких ассоциаций, что позволяет им взаимодействовать с множеством разных аген-
тов,

Поле модулей данных протокола SNMP (PDU)

Данное иоле идентифицирует тип PDU протокола SNMP. Существует пять обяза-
тельных типов PDU протокола SNMP:

•	Get request (Запрос на получение управляющей информации)

•	Get next request (Запрос на последующее получение управляющей информации)

•	Get response (Ответ на запросы Get. Get-next, Set)

•	Set request (Запрос на установление значений управляющих параметров)

•	Trap (Незатребованное сообщение, содержащее уведомление о возникших про-
блемах)

Во всех PDU типа Get и Set содержатся одни и те же поля (см таблицу 17.1). PDU
типа Trap передается в сообщении с друнтм форматом, которым рассматривается ниже
в данной главе

14 Заг 768
Таблица 17.1 Основные поля PDU протокола SNMP	
Поле	Описание
Идентификатор  Запроса (Request ID)	В каждом запросе передается уникальным идентификатор, используемый для согласования запроса и ответа агента на этот запрос.
Статус ошибки  (Error Status)	Используется для указания на ошибку В запросах в данном поле всегда устанавливается значение 0. Значения, отличающиеся от значения 0, означают следующие ошибки  •	0 = ошибок нет (по error)  •	1 - слишком большой размер PDU (PDU too big)  •	2 - не существует такого имени (no such name)  •	3 = неверное значение (bad value)  •	4 = только чтение (read only)  •	5 - ошибка общего характера (general error)
Индекс ошибки  (Error Index)	Специфицирует тип возникшей ошибки в случае, если в поле статуса ошибки установлено значение, указывающее на наличие ошибки
ID объекта и значение (Object ID and value)	Устанавливает соответствие между конкретным объектом (его идентификатором) и значением в системе ASN.1.

PDU типа Trap

PDU типа Trap передаются в сообщениях, имеющих отличный от предыдущих четы-
рех сообщений формат, поскольку в сообщениях данного типа содержатся незатребо-
ванные уведомления о возникновении серьезных проб чем. а не ответы на запросы дис-
петчера SNMP. На рис 17,3 показана структура PDU типа Trap; в таблице 17.2
представлено описание по чей сообщения Trap.

РИСУНОК 17.3 Формат PDU типа Trap отличается от формата PDU других типов сообщений

Таблица 17.2 Поля PDU типа Trap

Поле	Описание
Тип объекта (Enterpnse)	Указывает на тип объекта, который сформировал сообщение Trap.
Адрес агента (Agent Address)	Специфицирует сетевой адрес агента, который является источником сообщения Trap.
ID общего сообщения Trap (Generic Trap ID)	Указывает на причину, вызвавшую необходимость в передаче сообщения Trap:  •	0 = холодный запуск (cold start)  •	1 = горячий запуск (warm start)  •	2 - нарушение работы канала связи (link down)  •	3 восстановление работы канала связи (link up)  •	4 = отказ в аутентификации запроса (authentification failure)
Ноле	Описание
	5 = сосед по протоколу EGP не функционирует (EGP neighbor loss)  	6 = запрос сформирован другим объектом (enterp.ise specific)	
ID сообщения Trap производителя (Specific Trap ID)	Идентифицирует формируемое лроизялд.|телем сообщение Trap
Временная метка (Time stamp)	Указывает на время формирования агентом сог бщения Trap в результате некоторого события
ID объекта и значение (Object ID and value)	Идентифицирует ID объекта, для которого было сформировано сообщение Trap, и соответствующее ему значение.

Резюме

В середине 80-х различные Интернет -комитеты провели исследование тех протоко-
лов, которые могли бы стать инструментом успешного сетевою администрирования. В
процессе этого исследования в качестве потенциальных протоколов управления сетью
были избраны три протокола HEMS, CMIP и SGMP (позднее переименованный в
SNMP, или Простой протокол управления сетью) Протокол SNMP должен был стать
временным решением проблемы управления сетью, однако остался основным протоко-
лом сетевого администрирования до настоящего времени.

Протокол SNMP предоставляет в распоряжение сетевых администраторов службы
допавки управляющих запросов и ответов от имени приложении. Протокол SNMP дей-
ствует независимо от особенностей того или иною приложения, что делает этот прото-
кол применимым для решения целою класса задач, возникающих в процессе управле-
ния се|ью. Диспетчеры SNMP функционируют на основе специального программного
обеспечения, осуществляющего контроль над процессом сетевою администрирования.
Задача диспетчеров SNMP заключается в удаленном управлении и мониторинге работы
агентов SNMP Агенты SNMP, получающие запросы от диспетчеров, функционируют
на базе выполнения программ-исполнителей команд SNMP (command responders) и
программ-создателей уведомлений (notification originators).

Вопросы для повторения

1.	Под каким названием был ранее известен протокол SNMP?

2	Назовите три основных программных модуля SNMP, которые летают возможным
удаленное управление сетью.

3.	Что такое агенты SNMP?

4	Чю такие прокси агенты SNMP?

5.	Чю такое диспетчеры SNMP?

6.	Объясните, что представляет сооои PDU сообщения Trap
Глава 18

Протоколы открытой сетевой
обработки данных

В данной главе рассматриваются следующие темы:

•	Протоколы открытой сетевой обработки (ONC, Open Network Computing)

•	Сетевая файловая система (NFS, Network File System)

•	Внешнее представление данных (XDR, External Data Representation)

•	Удаленный вызов процедур (RPC, Remote Procedure Call)

Краткая характеристика протоколов ONC

В 1985 году компания Sun Microsystems разработала протокол управления распреде-
ленной файловой системой, известный под названием NFS (Network File System, Сете-
вая файловая система). Этот протокол был включен в состав серии программных про-
дуктов, обеспечивающих огорьиую обработку сетевой информации (ONC, Open Network
Computing). Термин ONC имеет собирательное значение и характеризует все множество
протоколов и служб, предлагаемых фирмой Sun, как единую платформу для сетевой
обработки данных, которая обеспечивает независимость от конкретной операционной
системы. Такая независимость iiotboimci разнотипным системам в прозрачном режиме
получать доступ к фа и шм, поддерживающим вычислительные технологии любой слож-
ности, начиная oi простых персональных компьютеров и заканчивая мэйнфреймами.

Несмшря на то, что NFS функционирует на прикладном уровне, для обеспечения
его работы требуется реализация двух npyiiix протоколов: XDR (External Data
Representation, Внешнее представление данных) и RPC (Remote Procedure Call, Удален-
ный вызов процедур) XDR поддерживает функционирование протокола NFS на уров-
не представления, RPC — на сеансовом уровне. Все протоколы, входящие в состав се-
мейства ONC. рассматриваются более подробно ниже в данной главе.

Все три указанных выше протокола (NFS, XDR и RPC), тесно взаимодействуя меж-
ду собой, предоставляют прозрачный доступ к распределенным файловым системам в
среде локальных или глобальных сетей В модели DoD протоколы ONC функциониру-
ют на уровне Процесс/приложение В данной главе в первую очередь анализируется
протокол NFS (протокол самого высокого уровня среди протоколов ONC), после чего
рассматриваются два других протокола — XDR и RPC. На рис. 18.1 покатано, на каких
уровнях эталонной модели OSI функционируют прогоколы ONC.
РИСУНОК 18.1

Совместными усилиями
протоколов семейства
ONC обеспечивается
прозрачный доступ к
распределенным файловым
системам в средах
зональных и гюбавъных
сетей.

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

Уровень
представления

Сеансовый
уровень

NFS, Сетевая файловая система	Информационные службы NFS (в прошлом — Желтые страницы (YP, Yellow Pages))	Диспетчер состояния	Диспетчер блокировки
XDR  Внешнее предста ение данных			
°РГ  Удала ныи вызов гр< тедур			

Основные характеристики NFS

Протокол NFS, как следует из самого названия, — "Сетевая файловая система", обес-
печивает доступ к информации в сети с . побои архитектурой через распределенные фей
ловые системы. NFS функционирует на основе модели взаимодействия клиент/сервер,
что позволяет клиентам NFS получать доступ к рассредоточенным по всему миру фай-
лам посредством простой передачи на удаленные серверы Nl S соответствующих запро-
сов.

Протокол NFS поддерживает множество клиентских операционных систем tMS DOS,
NetWare. Windows, NT, VMS и т.д.), а также такие apxMieKiypw локальных и глооаль-
ных сетей на канальном уровне, как Ethernet. Token-Ring, Х.25, Frame Relay и другие
(см. таблицу 18.2). Реализация работы сетевой файловой системы в прозрачном для
пользователя режиме включает в себя выполнение клиентом и сервером собственно
программного обеспечения NFS, каждое вовлеченное в процесс обслуживания NFS ус-
1ройство должно также поддерживать протокол внешнего пре кзявления данных (XDR),
который делает выполняемые NFS действия независимыми oi конкретной операцион-
ной системы, а также коммуникационный протокол (RPC), обеспечивающий взаимо
действие между клиентом и сервером NFS посредством передачи соответствующих зап-
росов и ответов.

Текущая версия NFS — версия 3, заменила версию 2; версия I не была представлена
компанией Sun для широкого использования Первоначально система NFS и ее компо-
iieiiibi были разраиотаны специалистами компании Sun таким обраюм, чтобы этот про
граммный продукт функционировал на базе транспортного протокола LJDP, однако
современные версии NFS могут также работать пл основе протокола TCP Несмотря на
то, что NFS в настоящее время функционирует в основном в среде стека протоколов
TCP/IP, возможности NFS не ограничиваются юлько протоко 1ами этого семейства: в
будущем NFS можно будет испольтовать па базе любою другого стека протоколоа В
таблице 18.1 перечислены все характеристки NFS версии 2 и версии 3.

Таблица 18.1 Характеристики NFS версий 2 и 3

Характеристика	И?	V3	Преимущество
Автоматическое монтирован,ie (automatic mounting)	да	да	Распространенные по всему миру файловые системы файловые системы доступны ди» пользователей в прозрачном

режиме
Характеристики	V2	и	Преимущество
Масштабируемости (scalability)	Да	да	Сеть легко расширяется по мере развертывания компании.
Централизованное администрирование (centralized administration)	да	да	Сокращается объем непроизводительных затрат на администрирование сети.
Совместное использование пространства имен, поимьняем jx в файловой системе (shared hie system namespace)	да	Дь	Пользователи и приложения могут беспрепятственно перемещаться по сети.
Поддержка конфи! ураций: бездисковых (diskless), не обрабатывающих данные (dateless) и работающих в автоматическом режиме (autochart) клиентов	да	да	Поддерживает работу недорогих клиентских систем с ограниченными ресурсами „
Гибкая система защиты от несанкционированного доступа (flexible security arcl itecture)	да	да	Поскольку NFS предоставляет широкий выбор пазличных методов защиты от несанкционированного доступа, система безопасности можег быть с энфигурирована согласно конкретным нуждам.
Множество разных способов аутентификации (multiple authentication flavors'	да	да	DES, Kerberos, "Unix Style”.
Множество разных cni собов авторизации (multiple authorization flavors;	да	да	ACLS, "Unix Style".
Поддержка аг'оритма DUAL версии 1 или 2	в настоящее время не поддерживается		
Использование TCP в качестве протокола транспортного уроаня	да	да	Обеспечивает надежную передачу данных е рамках локальной или глобальной сети.
Повышение производительности (performance improvements)	да	да	Обеспечивает быстрый доступ к удаленным файлам.
Кэширование данных на локальных дисках (local disk caching)	да	да	Увеличивает объем кэш-памяти и.  соответственно, повышает производительность.
Асинхронность (asynchronous)	нет	да	Позволяет клиенту увеличить производител_.ность записи информации.
Запросы с сокращенным количеством параметров (reduced atributes requests)	нет	да	Увеличивает масштабируемость и общую производительность.
Поддержка 64-разрядного представления данных и смещс нит (64-oit sizes and offset support)	нет	да	Возможен доступ к находящимся на серверах NFS мультигигабайтным файлам
Поддержка дублирующего сервера, предназначенного только для чтения файлов (read-only replica server support)	да	да	Дублирует сервер NFS и может заменить его в случае выхода основного сервера из строя.
Сервер NFS с высоким уровнем доступности (highly available server) - дополнительная характеристика	да	да	Позволяет регулировать работу си темы или сети в случае возникновения каких- либо нарушений.
Сокращенней формат запросов на предоставление справочной информации о содержании каталогов (directory lookup information)	нет	да	Увеличивает масштабируемость и производительность.
В таблице 1k.2 представлен список поставщиков профаммных продуктов NFS и со-
ответствующих этим нргчраммным продуктам операционных систем.

Таблица 18.2 Программные продукты NFS разных поставщиков

Поставщик	Используемая операиионная система
Amdahl	UTS
Apple	A, UX
Beame and Whiteside	DOS. Windows
BSDI	Unix
Cray	UNICOS
DEC	Ultrix. VMS
Dell	SVR4
FTP Software	DOS, Windows OS/2
Frontier Technology	DOS. Windows
Hewlett-Packard	HP-UX
IBM	AIX, MVS
Intel	Unix
ICL	Unix
Net Manage	DOS, Windows
Nlxdorf	TOS 35
Novell	Netware
OSF	OSF1
Santa Cruz Operation	SCu Unix
Sunsoft	Solaris. DOS, Windows
Silicon Graph.cs	IRIX
Process Software	VMS
Sony	NeWs
Texas Instruments	Tl SVR3 2
TGV	VMS

Действие NFS

Ключевым Элементом всей модели NFS является совокупность терриюриальни рас-
средоточенных файловых серверов (File servers), которые обеспечивают доступ клиен-
тов к совместно используемой информации (см рис. 18.2) Серверы NFS предоставля-
ют коллективный доступ к файловым системам посредством операции экспорта файлов
(exporting). Совместно используемые катало!и, находящиеся на файловом сервере (shared
server directories), испольтуются в качестве экспор тируемых файловых систем (exported
file systems). Посредством команды экспорта файлов (export) администратор, обслужи-
вающий файловый сервер, выделяет фрагменты хранящейся на сервере файловой сис-
темы, подлежащие передаче в адрес клиентов.

После определения администратором экспортных зон файловой системы f export areas)
клиенты NI S могут воснолыоваться командой монтирования (mount) для гою, чтооы
виртуально подключиться к экспортной тоне сервера, установив снять между удаленной
файловой системой и локальной зоной клиента, известной как точка монтирования
(mount point). Эта процедура предоставляет пользователю возможность получать доступ
к файлам удаленной файловом системы гик. как будто это — локальные файлы. На рис.
18.2 представлены основные этапы процесса взаимодействия между клиентом и серве-
ром NFS, необходимые для получения доступа к файлам и их совместною использова-
ния.

РИСУНОК 18.2

Команда mount
предписывает ядру
операционной системы Unix
выполнить подключение
новой фии твой системы к
укхпаииому фай. iy в
ладанной точке
монтирования.

'Психлючить' удаленную
файловую систему.
Эта система действует
как локальная

Сервер NTS

Выполнение сетевых операций
(процедур сервера NFS) в прозрачном
для пользователя режиме

Клиент NFS

Состав про1раммных средств, необходимых для обеспечения процесса коллективно-
ю использования файлов, зависит от типа операционной системы, а также от архитек-
туры системы. Для выполнения запросов на монтирование (mounting requests) и демон-
тирование (unmounting requests) файловой системы каждому клиенту необходимо иметь
в своем распоряжении специальную upoipaMMy NFS. Процедура монтирования
(mounting) позволяет инкорпорировать удаленную экспортную зону совместною пользо-
вания в локальную файловую систему клиента (эта локальная файловая система пред-
ставляет собой древовидную фантовую структуру каталогов клиента, client tree). Демон
тирование (unmounting) — процедура, противоположная по своей сути процедуре
монтирования, позволяет клиенту деблокировать ранее подключенную файловую сис-
тему, освобождая при этом вовлеченные в данный процесс ресурсы и отсоединяя экс-
портную зону от точки монтирования (mount point) локального дерева.

Точка монтирования — это определенный участок локального дерева катало!ов кли-
ента. к которому присоединяется подключаемая файловая система. В настоящее время
разработан усовершенствованный программный инс!румент подключения новой фай-
ловой системы к локальному дереву ка1алоюв. имеющий название "программа автома-
тического монтирования" (automounter). Эта программа делает возможным автоматичес-
кое монтирование (automatic mounting) и демонтирование (automatic dismounting)
экспортируемых файловых споем на основе специально сконфигурированной инфор-
мации об отображении экспортируемой файловой системы на ючку монтирования
(mapping information). Прорамма автоматического монтирования nenciaycr cot 1асно
тому же принципу, что и вводимая вручную команда mount, соединяющая удаленную
экспортную юну с локальной файловой системой клиента (ючкои монтирования). В то
же время процедура автоматическою моншрования выполняется динамически с исполь-
зованием предварительно сконфстурнровашюго фаила, содержащего отображения пу-
тей к удаленным файловым системам на соответствующие имена локальных дисков или
каталогов (точки монтирования)

В концепции монтирования удаленной файловой системы и ее использования в ка-
честве составной части лекального дерева каталогов пет ничего нового: эта идея реали-
зована в таких операционных системах как NetWare компании Novell или различные
версии Windows компании Microsoft. В случае использования этих операционных сис-
тем в качестве платформы для реализации NFS процедура моншрования идентична
процедуре формирования путей к файлам цди каталогам по иерархической структуре
файловой системы. Чтобы получить доступ к какому-либо ресурсу на удаленном хосте,
можно просто обозначить путь к каталогу удаленной файловой системы очередным
именем лиска, еще не задействованным для идентификации локальных дисков: напри-
мер Е:, F: и т л. После выполнения этой операции доступ к удаленной экспортной зоне
можно получить посредством элементарного ввода имени, отображающею путь к уда-
ленному ресурсу. В описанном выше случае этот символ (Е:. F:) является именем дис-
ка, который, в свою очередь, играет роль точки монтирования нового каталога (файло-
вой системы); в дальнейшем кляеьт использует по имя для того, чтобы получить доступ
к удаленной зоне.

Имя. которым обозначен путь к удаленной файловой системе, можно интерпрети-
ровать как ярлык, с помощью которою можно получть быстрый доступ к этой систе-
ме Раньше каждый раз при возникновении необходимое!и в по (учении доступа к уда-
чен ному ресурсу приходилось создавятьполный путь к серверу и искомому подкаталогу.
Почучение доступа таким неэффективным способом требовало большого количества вре-
мени, чю, н свою очере tb, существенно замедляло процесс доступа к удаленным ресур-
сам. Создание так называемой "карты путей" (системы отображения путей к удаленным
фантовым системам на присвоенные им имена) позволяет проложить прямой путь к
удаленным ресурсам. Да чее можно просто укашть имя, присвоенное пому пути, чтобы
получить доступ к нужному ресурсу.

Идентифицировать локально ю точку моншрования можно либо посредством удоб-
ною для пользователя имени каталога (например, /home/heather), жбо посредством
имени локальною диска (Е:, I и т.д ) Находящаяся на сервере экспортная зона, под-
лежащая 11одк1|юченн|о к локальной точке монтирования (другими словами, экспорти-
руемая фаи .овая система) может быть расположена на любом участке файловой струк-
туры сервера, в состав коюрой ни подуровнях различной 1лубины вложенности
включены мно!очисленные под ка галош и файлы (п стример NFSServ:/exporl/homedir/
heather).

Выполнение клиентом процедуры локально) о монтирования в (счет за собой подклю-
чение удаленной файловой системы к локальной точке моншрования. Совокупность всех
точек монтирования представляет собой пространство имен, обозначающих пути к гем
или иным удаленным ресурсам. Посредством такого пространства имен пользователь
имеет возможность получать доступ к любой информации, хранящейся в экспортируе-
мой файловой системе, просто указывая либо соответствующее имя клиента (/home/
heather), либо имя диска. идентифицирующее удаленную зону (например, F:). На
рис. 18.3 представлена схема работы программы автоматического монтирования на ос-
нове пространства имен NFS

РИСУНОК 18.3

клиенты NFS получают доступ к
находящимся на NFS-cepeepax
файлам посредством подключения к
локальной точке монтирования
экспортируемой с сервера файловой
системы. Для этого клиентам NFS
необходимо иметь в своем
распоряжении отображение пути к
искомой файловой системе сервера
на соответствующее имя
гока 1ьного диска и iu каталога

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

Сервер NFS

На сервере NFS хранятся распределенные файловые системы, которые клиент NFS
может получить в совместное с другими клиентами пользование простым выделением
экспортных зон (экспортируемых файловых систем) посредством команды export, вы-
полняемой пршраммой обеспечения совместною использования ресурсов (share
program). Сервер NFS отвечает на запросы клиентов NFS о предоставлении им совмес-
тно используемой информации.

В обязанности сетевого администратора входит создание конфигурационною файла
экспортной информации (export configuration file) — файла, содержащею информацию
об экспортируемых файловых системах и путях к ним. Администратор должен также
сконфигурировать следующую информацию:

•	Какие файлы подлежат коллективному использованию.

•	Кто может получить доступ к совместно используемой зоне

•	Любые ограничения па получение доступа к данной зоне и содержащимся в ней
данным.

•	Полный список путей, идешифииирующих подлежащие экспорту каталоги.

•	Список клиентов NFS. которым разрешено получать доступ к экспортируемым

каталогам.
•	Перечень особых ограничении на по |ученпе доступа к информации, содержащей-
ся в тон или иной зоне.

При инициализации сервера NFS выполняемая на этом сервере программа обеспе-
чения совместного использования ресурсов применяет информацию. содержащуюся в
конфигурационном файле экспортной информации, для ввода экспортных характерис-
тик и идентификации экспортируемых файловых систем. Выполнение запросов NFS-
клиентов на получение доступа к хранящейся на сервере NFS фантовой системе обес-
печивается двумя процессами, выполняемыми операционной системою mount-d и nfs-d.
В данных терминах символ "d" означает "daemon" (сетевая программа, работающая в
фоновом режиме), а сами названия означают следующее: inouni-d — монтирование фай-
ловых систем в фоновом режиме; nfs-d — выполнение программного обеспечения NFS
в фоновом режиме.

Действие программы автоматического монтирования и ее компоненты

Как упоминалось ранее, программа автоматического монтирования файловых сис-
тем — это усовершенствованный программный инструмент подключения новых ката-
логов к локальным точкам монтирования. Эта про1рамма позволяет выполнять автома-
тическое подключение и отключение экспортируемых файловых систем на основе
специально сконфигурированной информации о путях к этим системам Программа ав-
томатическою монтирования состоит из следующих основных про|раммных модулей:

•	Команда автоматического монтирования (aulomount command)

•	Программа выполнения автоматического монтирования в фоновом режиме
(automount-d)

•	Виртуальная файловая система программы автоматического монтирования (autofs,
automount virtual file system)

Команда автоматического монтирования

Команда авюмалическою монтирования (autocommand) инициализируется непосред-
ственно после начальнои затруikh системы. После инициализации команда автомати-
ческого монтирования открывает и в дальнейшем использует исходным файл конфигу-
рации автоматического монтирования (auto master) — специальный крнфшуряционный
файл, содержащий информацию об экспортируемой файловой системе. Эта информа-
ция испотьзуется для создания на хосге локальной габ шны монтирования (local mount
table)

После создания таблицы автоматическою монтирования пользователь может полу-
чить доступ к требуемо!! файловой системе посредством команды CD (Greate directory' —
создать каталог) Когда пользователь предпринимает попьнку получить доступ к уда-
ленной файловой системе через локальную точку монтирования, программа автомати-
ческого монтирования в фоновом режиме выполняет замену виртуальной файловой
системы autofs. которая является структурным заполнителем, предназначенною для эк-
спортируемой фан повой системы места, на необходимую пользователю файловую сис-
тему.

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

Внешнее представление данных (XDR)

Протокол XDR (External Data Representation. Внешнее представление данных), при-
нимающий непосредственное участие в обеспечении работы сетевой файловой системы
NFS, делает ее совместимой с различными операционными системами. Описание про-
токола XDR, разработанного компанией Sun Microsystems, представлено в стандартном
документе сети Интернет — RFC 1014. Основной функцией XDR является обеспечение
платформенной независимости NFS.

Благодаря протоколу XDR клиентские и серверные программы NFS могут выпол-
няться на базе принципиально отличающихся операционных систем и аппаратных
средств, начиная от хостов Macintosh и заканчивая Unix-хостами. при этом процесс
совместного использования файлов остается прозрачным для пользователей. XDR обес-
печивает такую прозрачность, скрывая специфические внутрисистемные программные
средства от каждой из взаимодействующих сторон и выполняя соответствующее преоб-
разование информации перед се передачей или после приема.

Действие протокола XDR построено па основе использования стандартной библио-
теки ноднротрамм (standard library of programming routines), написанных на языке про-
граммирования С Эта библиотека подпротрамм, позволяющая представлять данные в
независимом от конкретной реализации виде, может быть использована поставщиками
сетевых услуг в поддерживаемой ими сетевой среде. На рис. 18.4 показано, каким обра-
зом протокол XDR обеспечивает машинно-независимые функциональные возможнос-
ти NTS.

РИСУНОК 18.4

Протокаi XDR выполняет
такое лреобра ювание
донных, которое лрзего 1яет
двум различным
операционным системам
взаимодействовать друг с
другом в процессе
обеспечения работы NFS.

Способ хранения данных — конкретный порядок байтов, адреса ячеек памяти и тщ. —
все это имеет значение только для процесса XDR локальною хоста. XDR обеспечивает
двустороннюю Jioiическую связь mc>k.tv NFS и RPC Когда про1раммньп) модуль NFS
того или иною хоста формирует определенную совокупность данных для передачи в
адрес клиента, он передает эти данные для обработки протоколом XDR, протокол XDR
в свою очередь, передает полученную информацию в а трее протокола нижнего (сеан-
совою) уровня — протокола RPC

Кота протокол XDR функционирует в режиме приема информации, он принимает
сообщения NFS от протокола RPC, интерпретирует их и преобразует содержащуюся в
31 их сообщениях информацию в формат, распознаваемый операционной системой хос-
та-получателя. Как утверждается в посвященных протоколам уровня представления раз-
делах глав 1 и II), функция уровня представления заключается в представлении данных
в формате, который должен быть совместимым с операционной системой данного хос-
та. а также должен быть согласован с конкретными аппаратными требованиями этого
хоста. На уровне представления выполняйся трансляция данных в ioi или иной фор-
мат, кодирование и декодирование информации, преобразование из формата ASCH в
EBCDIC и наоборот и т.д.

Функции уровня представления, как правило, выполняются программным обеспе-
чением большинства протоколов верхних уровней и не выде тяются отдельно, как в случае
с протоколом XDR Компания Sun Microsystems включи ia в состав своего стека прото-
колов протокол уровня представления (XDR) как отдельную единицу, для того чтобы
более эффективно использовать функциональные возможности NFS посредством реа-
лизации предоставляемых XDR преимуществ Проюкол XDR поддерживает взаимодей-
ствие между разнотипными хостами, позволяя про|раммистам более точно приспосаб-
ливать используемые протоколы к нуждам конкретной операционной системы, что. в
свою очередь, упрощает процесс совместимое!и с операционной системой другого хос-
та. Несмотря на то, что протокол XDR — яо самостоятельный протокол, он выполняет
функции, которые являкнея неотъемлемой частью работы проюколов верхнего уровня
Следствием эюго является то, что аннлизатор протоколов Snifter не распознает прото-
кол XDR в качестве самостоятельной единицы.

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

Компания Sun Microsystems разработала механизм удаленного вызова процедур (RPC,
Remote Procedure Call), описание которою включено в один из докуменюв сети Интер-
нет — RFC 1057 Механизм RPC, в состав коюрою входит собственно протокол и неза-
висимый интерфейс, отвечает за предоставление двустороннею канала передачи дан-
ных между удаленными коммуникационными процессами. RPC функционирует на
сеансовом уровне, следовательно, в его обязанности входит установление сеанса связи
между выполняемыми на различных хостах процессами, а также поддержка этого сеан-
са связи и отслеживание его работы. Коша хосты больше не нуждаются в наличии меж-
ду ними логическою соединения. RPC закрывает сеанс связи и освобождает задейство-
ванные в нем локальные ресурсы.

Рассмотрим действие RPC на конкретном примере передачи сообщении, содержа-
щих запрос на вызов удаленных процедур Предположим, что выполняемый на локаль-
ном хосте процесс формирования и передачи запросов на предоставление информации
реализуется с помощью локально)о вызова процедур (Local Procedure Call, LPC). Когда
локальный хост запрашивает выполнение какой-либо процедуры удаленным хостом и
ожидает от этого хоста обработки данною запроса и передачи ответа на него. — это уже
функция RPC. На рис. 18.5 проиллюстрирован процесс взаимодействия между LPC и
RPC.

РИСУНОК 1в.5 Ласт выполняет вызов процедур, которые имеют видимость школьных. в то время
как на са ном деле эти процедуры выпоаняются на удаленном компьютере

Хосты, выполняющие RPC. используют лот механизм для передачи на хост назна-
чения запросов на выполнение таких процедур, как чтение, запись, печать фактов и т.д.
Xoci назначения, в свою очередь, обрабатывает полученные запросы и передаст поло-
жительный или отрицательный ответ на них. Благодаря взаимодеиствию с протоколом
XDR действие RPC совсем не зависит от операционных систем локального и удаленно-
го хостов; решение проблемы интерпретации специфичной для того или иною компь-
ютера информации, передаваемой в запросах и ответах. RPC также возлаыет на прото-
кол верхнею уровня (XDR).

Механизм вызова удаленных процедур RPC представляет собой достаточно простои
программный инструмент, коюрый выполняет 1арантированную передачу поступающих
от протокола верхнего уровня запросов в адрес получателя. Как правило. RPC функци-
онирует на базе транспор того протокола UDP. В то же время, благодаря своей адап-
1ивности RPC может дейс1вовап> и на базе трансиортого протокола TCP. 1аранзирую-
щего надежность доставки сообщений н пункт назначения. Такая адаптивность RPC к
различным условиям функционирования стала возможной после реализации RPC вереде
принципиально новых операционных систем (имеется в виду платформа Windows NP
компании Microsoft) во взаимодействии с новым протокольным окружением.

Формат сообщения RPC, содержащего запрос на
вызов процедуры

Вызов каждой удаленной процедуры обеспечивается активизацией со стороны кли-
ента соответствующей программы, которая формирует и передаст в адрес сервера сооб-
шенис, содержащее запрос на низов топ или иной процедуры (call message). Как прави-
ло, для обслуживания удален ны\ процедур нсети имейся одна и .и несколько прснрамм
Ниже представлено описание полей кполовка сообщения RPC. содержащего запрос на
вызов удаленной процедуры.

Поле идентификатора транзакции

Клиент, передпющий запрос на вызов процедуры, присваивдет этому запросу иден-
тификационный номер (ID number), который устанавливается в поле идентификатора
транзакции (transaction ID) Протокот RPC использует это поте для сопоставления зап-
росов на вызов процедуры и ответов на них.

Поле типа сообщения

Значение. устанавчивармое в поле Туре, идентифицирует тип сообщения: запрос на
вызов процедуры (Call) ити ответ на этот запрос (Reply):

•	0 = Call

•	I = Reply

Поле версии

В поле версии (Version) указывается номер используемой версии протокола RPC. В
настоящее время всегда указывается версия 2 про юкола RPC.

Поле программы

Значение, устанавливаемое в поле про1раммы (Program), идентифицирует ту про1рам
му, которая применяет в своей работе протокол RPC (например, NFS). В таблице 18.3
перечислены все использующие RPC прозраммы, коюрым присвоены зарегистрирован-
ные ИРС-номера

Таблица 18.3 Зарегистрированные программы, использующие RPC		
Номер RPC	Ими программы	Описание
1J000G	PMAPPR'jG	Portmapper - зеркало портов
100001	RSTATPROG	Remote stats — Удаленное состояние
100002	RUSERSPROG	Remote users — Удаленные пользователи
100003	NFSPROG	NFS
100004	YPPROG	Yellow Радей — желтые страницы
100005	MOUNTPROG	Mount daemon — демон монтирования
100006	DBXPROG	Remote DBX — Удаленные ПВХ
100007	YBINDPROG	YP binder — связывание желт ix страниц
10Р00В	WALLPROG	Shutdown message — Сообщение об отключении
100009	YPPASSWDPROG	YP Password password server — Сервер паролей желтых страниц
100010	ETHERSTATPROG	Ethernet Stats — состояние Ethernet
100011	QQUOTAPROG	Disk quotas — квиты диске
100012	SPRAYPROG	Spray packets — пакеты Spray
Номер  RPC	Имя программы	Описание
100013	IBM3270PROG	3270 mappar — отображение терминала IBM 3270
100014	F’MRJEPROG	RJE .nppper — отображение дистанционного ввода заданий
100015	SELNSVCPROG	Selection service — выбор службы
100016	RDATABASEPROG	Remote database at cess — удаленный доступ к базам данных
100017	REXECPROG	Remote execution — удаленное выполнение заданий
IOOO I8	ALICEPROG	Alice office automation — автоматизация учреждений
100019	SCHEDPROG	Scheduling service — служба расписаний
100020	LOCKPRUG	Local lock manager — локальное управление блокировкой
100021	NETLOCKPROG	Network lock manager - сетевое управление блокировкой
100022	X 25PROG	Х.25 INR Protocol — протокол Х.25
100023	STATMON1PROG	Status monitor 1 — Диспетчер состояния 1
100024	STATMON2PROG	Status monitor 2 — Диспетчер состояния 2
100025	SELNLIBROG	Selection library — выбор библиотеки
100026	BOOTPARAMPPOG	Boot parameters service — служба параметров загрузки
100027	MAZE PROG	Mazeware game — игра ЛАБИРИНТ
10002В	YPUPDATEPROG	UP update — оонпвление желтых страниц
100029	KEVSERVEPROG	Key server — сервер ключей
100030	SECURECMDPI OG	Secure login — защита регистрации
100031	netfwdiprog	NFS net forwarder mit — сетевая инициализация перенаправления NFS
100032	NETFWDTPROG	NFS net forwarder trans — сетевое преобразование NFS
100033	SUNLINKMAPPROG	Sunlink MAP — Карта подканала
100034	NETMONPRGG	Network monitor — Сетевое управление
100035	DBAbFPROG	Lightwaiaht database — Простая база да юых
100036	PWDAUTHPF.OG	Password authentication — пароль аутентификации
100037	TFSPROG	Translucent file service - • протоачная файловая служба
100038	NSEPROG	NSE server — сервер NSE
100039	NSE ACTIVATE_PROG	NSE activate daemon — активный демон NSE
150001	PCNFSDPROG	PC password authorization — пароль аутентификации PC
200000	PYRAMIDLOCKINGFROG	Pyramid-iockmg — Блокировка Pyramid
200001	PYRAMIDSYS5	Pyramid-sys5 — система Pyran iid-sys5
200002	CADDSJMAGE	CV cadds imaqe — версия CADDSJMAGE
300001	ADT RFLOCKPROG	ADT file locking — олокировка файлов ADT

Примечание научного редактора.

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

* rpcinfo -р имя_сервера
Будет выведена перечень программ, версий, протоколов и номеров портов, подоб- ный с 1едующему:				
program	vers	proto	port	
100000	2	udp	111	portmapper
100017	1	tep	1024	rexd
100005	1	udp	1027	mountd
100003	2	udp	2049	rtfs
100024	1	udp	1039	status
100024	1	tep	1025	status
100021	1	tep	1026	nlockmgr
100021	1	udp	1051	nlockmgr
100020	1	udp	1054	llockmgr
100020	1	tep	1028	llockmgr
100021	2	tep	1032	nlockmgr

Можно также ncno'ibaonaib rpcinlo для проверки работоспособности сервера mountd:

# rpcinfo -и имя_с«-рверв mountd

Команда возвращает:

program 100005 version 1 ready and waiting

(прщрамма 100005 версии I готова и находится в состоянии ожидания)

Поле процедуры

В данном поле (Procedure) указывается соответствующий точу ruin иному приложе-
нию номер процедуры. Эго значение меняется в зависимости от того, какое приложе-
ние обращается к какой процедуре. Номера процедур предоставляются поставщиком
программного продукта В таблице 18.4 перечислены номера процедур сервера NFS.

Таблица 18.4 Процедуры NFS____________________________________________________

Номер	Имя процедуры	Описание процедуры
0	Пустая процедура (Do nothing)	Позволяет выполнить тестирование и синхронизацию ответов сервера
1	Получение атрибутов файла (Get file atributes)	Позволяет клиенту получить атрибуты файла сервера.
2	Установление атрибутов файла (Set file attributes)	Позволяет клиенту установить (некоторые) атрибуты файла сервера
3	Получение корневого каталога файловой системы (Get filesystem root)	Вышедшая из употребления процедура
4	Поиск имени файла (Look up file name)	Позволяет клиенту выполнить поиск файла в каталоге.
5	Чтение данных из файла по символической ссылке (Read from symbolic link)	Позволяет клиенту считывать данные из файла, на который указывает связанная с ним символическая ссылка
6	Чтение данных из файла (Read from file.	Позволяет клиенту считывать данные из файла.
Номер	Имя процедуры	Описание процедуры
7	Запись данных з кэш (Write ю cache)	Используется только в NFS версии 3.
8	Запись данных в файл (Write to *ile)	Позволяет клиенту записать данные в файл сервере
9	Создание файла (Create file)	Позволяет клиенту создать новый файл на сервере
10	Удаление файла (Remove file)	Позволяет клиенту удалить файл с сервера.
11	Переименование файла (Rename fllei	Позволяет клиенту переименовать файл на сервере
12	Создание ссылки на файл (Create link to file)	Позволяет клиенту создать файл, содержащий ссылку на другой файл
13	создание символьной ссылки (Create symbolic link)	Позволяет клиенту создать фпи.1 с символьной ссылкой на другой Файл
14	Создание каталога (Create directory)	Позволяет клиенту создать каталог на сервере
15	Удаление каталога (Remove directory)	Позволяет клиенту удалить каталог с сервера
16	Чтение данных из каталога (Read from directory)	Позволяет клиенту считывать некгторые записи из катало а сервера
17	Получение атрибутов файл* вой системы (Get lilesvstem attributes i	Позволяет клиенту проверить атрибуты сервера.
В таблице 18.5 перечислены процедуры моншрования  Таблица 18.5 Процедуры монтирования		
Номер	Имя процедуры	Описание процедуры
0	Пустая процедура (Do nothing)	Позволяет выполнить тестирование и синхронизацию ответов сервера
1	Добавить элемент монтирования (Add mount entry)	Добавляет еще одну файловую систему к списку файловых систем, к которым клиент имеет доступ.
2	Выдача списка элементов монтирования файловых (Return mount entiies)	Позволяет клиенту просмотреть список подключенных систем.
3	Удалить элемент монтирования (Remove mount entry)	Удагяат файловую систему из списка файлоаых систем, к которым клиент имеет доступ.
4	Удалить все элементы монтирования (Remi ve all mount entnes)	Удаляет все файловые системы из списка файловых систем, к которым клиент имеет доступ на сервере.
5	Выдача списка экспортируемых файловых систем (Return expo t list)	Позволяет клиенту просмотреть список удаленных файловых систем, предлагаемых конкретным сервером.

Поле типа аутентификации

В поле Authenticate Т, ре у^гананливается значение, идентифицирующее тип аутен-
тификации. 3to значение указывает, запрашивается ли аутентификация, а если ла — то
аутентшЬик шия какого типа
•	0 = Null (нет аутентификации)

•	1 = Unix (аутентификация Unix)

•	2 = Short (сокращенный тип аутентификации, задаваемый поставщиком)

•	3 = DES (аутентификация по стандарту шифрования данных DES)

Поле объема данных аутентификации

Значение, устанавливаемое в поле Authentication Byte Size, идентифицирует размер
(в бантах) данных аутентификации, которые представлены в следующем поле.

Поле данных аутентификации

Поле, в котором указываются данные аутентификации (Authentication Data) имеет
переменную длину. В этом поле передается собственно информация об аутентифика-
ции.

Поле проверки типа аутентификации

Поле проверки типа аутентификации (Authentication Verification) специфицирует
метод аутентификации, который предположительно должен использоватьполучатель для
проверки данного запроса на вызов процедуры или ответа на него. Хосты, взаимодей-
ствующие между собой, должны поддерживать один и тот же тип аутентификации:

•	0 = Null (нет аутентификации)

•	I = Unix (аутентификация Unix)

•	2 = Short (сокращенный тип аутентификации, задаваемый поставщиком)

•	3 = DLS (аутентификация по стандарту шифрования данных DES)

Сообщение, содержащее ответ на запрос о вызове
процедуры

Как упоминалось выше, каждый вызов удаленной процедуры осуществляется посред-
ством активизации клиентской про!раммы, передающей запрос на вызов процедуры в
адрес сервера, который, в свою очередь, возвращает ответ на этот запрос. Получение
сервером запроса на вызов процедуры может завершиться двумя способами- этот зап-
рос может быть принят или отклонен. В последующих разделах данной главы представ-
лено описание заголовка сообщения, содержащего ответ сервера на запрос о вызове
удаленной процедуры (reply message). Этот заголовок состоит из двух полей:

•	Поле статуса ответа (Status)

•	Поле содержания ответа (Accept status)

Поле статуса ответа

Значение, устанавливаемое в поле статуса (Status), указывает на факт принятия или
отклонения сервером запроса на вызов удаленной процедуры, полученного ранее. В
данном поле могут быть указаны два следующих значения:

•	0 = Accepted (Запрос принят)

•	I Denied (Запрос отклонен)
Поле содержания ответа

В поле содержания ответ (Accept Status) представлено дальнейшее описание резуль-
тата обработки запроса на вызов удаленной процедуры. В данном поле могут быть уста-
новлены следующие значения:

•	0 = Success (Успешное выполнение запроса)

•	I ~ Program unavailable (Программа недоступна)

•	2 = Program version mismatch (Несовпадение версий программы)

•	3 = Procedure unavailable (Процедура недоступна)

•	4 = Garbage arguments to procedure (В описании процедуры указаны ненужные па-
раметры)

Примеры работы протокола NFS

Существует множество различных выполняемых службой NFS процедур, следователь-
но, заголовки NFS отличаются друг от друза в зависимости от того, к какой процедуре
происходит обращение, а также от тою, является ли данное сообщение запросом на вызов
процедуры или ответом на него. На рис. 18.6 проиллюстрирован запрос на вызов про-
цедуры чтения файла (тин процедуры чтения файла соответствует номеру 6). Дескрип-
тор файла (длинная последовательность чисел, указанная после поля типа процедуры)
идентифицирует конкретный файл на удаленном хосте.

РИСУНОК 18.6 NFS функционирует на базе типично// модели в/аимодеиствин к тент сервер
Со. шсно реализации зтой модели в системе NFS /окольный к. тент, выпаи/яю/ций при luMVHUt
может по /учить доступ к находнши. йен на сервере NFS фаи зам
На рис. 18.6 следует обратить внимание на то, что установленное в поле смешения
(Offset) значение равно 4096 байтам. Это значение указывав! на то место в запрашива-
емом файле, с которою должно начинаться считывание содержащихся в фа>ыс данных.
Значение 4906, установленное в поле количества байтов (Count), указывает на обший
объем подлежащих считыванию данных.

Рис. 18.7 иллюстрирует ответ NFS на полученный ранее запрос на чтение (тип про-
цедуры 6, чтение файла). Следует обратить внимание на то, что сервер NFS проверяет ука-
занный клиентом идентификатор пользователя (User ID) и идентификатор группы (Group
ID), а также соответствующие разрешения на выполнение той или иной операции
(permissions). Цель такой проверки — убедиться в том, что пользователь имев! соответству-
ющее разрешение на выполнение запрашиваемой процедуры В данном примере пользо-
вателю и группе предоставлено право на чтение и запись данных (rw, read and write).

РИСУНОК 18.7 С помощью NFS клиент может получить доступ к фаи юм сервера в прозрачном
режиме, независимо от того, где находится сам клиент или обслуживающий его сервер

На рис. 18.8 представлен пример тапроса RPC на вызов удаленной процедуры. Со-
гласно данному примеру протоколу RPC выделен порт назначения UDP с номером 2049.
Из заголовка RPC можно выяснить следующую информацию. RPC использус! идеши-
фикатор транзакции (Transaction ID) для того, чтобы сопоставить полученный о>вет с
отправленным ранее запросом. Тип передаваемого RPC-сообщсния — запрос на вызов
удаленной процедуры. Зарегистрированное значение номера программы для NFS —
I00003; тип версии — 2; тип аутентификации — Unix. Следует обратить внимание на
то. что в данном сообщении передается также имя компьютера (Mafalda), идентифика-
торы пользователей (UIDs) и идентификаторы групп (GIDs). Это делается для тою. чтобы
получатель сообшения moi выполнить аутентификацию пользователей и проверку со-
обшения перед ею обработкой.

РИСУНОК 18.8 NFS предостав <яст птыователям возможность совместного использования
каталогов и файлов независимо от того, какие операционные системы обслуживают работу их

компьютеров

Резюме

Сетевая файловая система NFS инициирует запрос на выполнение чтения, записи,
копирования, переименования удаленного файла (и других операций с файлами), а также
отвечает на этот запрос. NFS выполняет, подюговку запроса или ответа для передачи по
сети, а затем передает сформированный запрос на вызов процедуры или ответ на него
протоколу XDR с целью интерпретации запроса/ответа и его перекодировки. XDR пе-
редает полученную информацию в адрес протокола RPC. который отвечает за установ-
ление и поддержание сеанса связи между двумя взаимодействующими хостами.

Вопросы для повторения

I.	Назовите три протокола, входящие в состав семейства ONC.

2.	Какая основная функция NFS?

3.	Какая основная функция XDR?

4.	Какая основная функция RPC?

5	Какая компания разработала протоколы ONC?
Приложение А*

I

Запросы на комментарии (RFC)
по главам

Глава 1: Обзор моделей и стандартов сетевых
технологий. Стандарты

1095 CommonManagemern Information Servicesand Protocol Over TCP/IP(CMOT). U.S.
Warricr and L. Besaw. (April 1989) (Format: TXT=157506 bytes)

1180 TCP/IP Tutorial. T J Socolofsky and C. J. Kale. (January 1991) (Format: TXT=65494
bytes) (Status: INFORMATIONAL)

1195 Use of OS! 1S-IS for Routing in TCP/IP and Dual Environments. R. W. Callon.
(December 1990) (Format: TXT= 187866, PS=362052 bytes) (Status: PROPOSED
STANDARD)

Глава 2: IP-адресация

1219 On Ilie Assignment of Subnet Numbers. P. F. Tsuchiya. (April 1991) (Formal:
TXT=30609 bytes) (Status: INFORMATIONAL)

Глава 3: Протоколы сетевого уровня/
Протоколы Интернета

760 Internet Protocol

777 Internet Control Message Protocol

781 Specification of the Internet Protocol (IP) Timestamp Option

791 Internet Protocol

792 Internet Control Message Protocol

815 IP Datagram Reassembly Algorithms

Kill Official Internet Protocols. J.K. Reynolds and J. Postel. (June 1987) (Format.
ГХТ=129194 bytes) (Status: INFORMATIONAL) (Obsoletes RFC0991) (Status:
UNKNOWN)

• В связи с тем. что Запросы на комментарии (Rf-Sj не являются стандартизованными документами. а являют-
ся тшъ прои звсыьно сформулированными спецификациями протоколов и соответствующих информационных тех-
нологии, было приято решение представить читателю список RFC на языке оригинала документа Но номеру RFC
читатель может самостоятельно искать документ в Интернете на русском языке При этом надо иметь ввиду,
что только часть документов имеют русский перевод, и установление точного соответствия перевода к ориги-
налу остается ta читателем (прим научи. ред.).
1016 Something a Host Could Do With Source Quench. The Source Quench Introduced
Delay (SqulD). W. Prue, J Postel. (July 1987) (Format: TXT=47922 bytes) (Status:
UNKNOWN)

1018 Some Comments on SqulD. A.M. McKenzie. (August 1987) (Format: TXT=7931 bytes)
(Status: UNKNOWN)

1025 TCP and IP Bake Off. J. Postel. (September 1987) (Format TXT=21297 bytes) (Status:
UNKNOWN)

1027 Using ARP to Implement Transparent Subnet Gateways. S. Carl-Mitchell and J S.
Quarterman. (October 1987) (Format: TXT=82440 bytes) (Status: HISTORIC)

1051 Standard for the Transmission of IP datagrams and ARP Packets Over ARCNET
Networks. P. A. Prindville. Mar-01-1988. (Format: TXT=7779 bytes) (Obsoleted by
RFCI20I, sld0046) (Status: UNKNOWN)

1054 Host Extensions for IP Multicasting. S. E. Deering. May-01-1988 (Format:
TXT=45465 bytes) (Obsoletes RFC0988) (Obsoleted by RFC1112) (Status:
UNKNOWN)

1053 Nonstandard for Transmission of IP Datagrams Over Series I Uines: SLIP J.L. Romkey.
Jun-01-1988. (Format: TXT=I29I I bytes) (Status: STANDARD)

1063 Path MTL1 Discovery Options. J C. Mogul, C. A. Kent, C. Partridge, and K.
McCloghrie Jul-01 -1988. (Format: TXT=27I2I bytes) (Obsoleted by RFCI19) (Status:
UNKNOWN)

1071 Computing the Internet Checksum. R. T. Braden. D A. Borman, and C. Partridge.
Sep-01-1988. (Format; TXT=54941 bytes) (Updated by RFCI 141) (Status:
UNKNOWN)

1077 Critical Issues in High-bandwidth Networking. В. M. Leiner. Nov-01-1988. (Formal:
TXT=116464 bytes) (Status: UNKNOWN)

1141 Computation of the Internet Checksum via Incremental Update. T. Mallorv and A.
Kullberg. Jan-01-1990 (Formal: TXT=3587 bytes) (Updates RFC1071) (Updated by
RFCI624) (Status: INFORMATIONAL)

1188 Proposed Standard for the Transmission of IP Datagrams Over FDDI Networks. D.
Katz Oct 01 1990. (Format: TXT=2242 bytes) (Obsoletes RFCI 103) (Status: DRAFT
STANDARD)

1191 Path MTU Discovery. J. C. Mogul. S. E. Deering. Nov-01-1990. (Format: TXT=47936
bytes) (Obsoletes RFC 1063) (Status: DRAFT STANDARD)

1208 Glossary of Networking Terms. O. J. Jacobsen and D C. Lynch. Mar-01-1991. (Format:
TXT=41156 bytes) (Status: INFORMATIONAL)

1256 ICMP Router Discovery Messages. S Deering. Sep-01-1991. (Format: TXT=43059
bytes) (Also RFC0792) (Status: PROPOSED STANDARD)

1413 Identification Protocol. M St. Johns. January 1993. (Format: TXT=1629I bytes)
(Obsoletes RTC93I) (Status: PROPOSED STANDARD)

1624 Computation of the Internet Checksum via Incremental Update. A Rijsinghani, Editor.
May 1994. (Format: TXT=9836 bytes) (Updates RFC1141) (Status:
INFORMATIONAL)
1788 ICMP Domain Name Messages. W. Simpson. April 1995. (Formal: TXT=11722 bytes)
(Status: EXPERIMENTAL)

2002 IP Mobility Support. C. Perkins. October 1996. (Formal: TXT=193IO3 bytes) (Updated
by RFC2290) (Status: PROPOSED STANDARD)

2005 Applicability Statement for IP Mobility Support. J.Solomon. October 1996. (Format:
TXT-10509 bytes) (Status: PROPOSED STANDARD)

2041 Mobile Network Tracing. B. Noble, G. Nguven, M Salyanarayanan, and R Katz.
December 1996. (Format: TXT=64688 bytes) (Status: INFOMRATIONAL)

2058 Microsoft Vendor-specific RADIUS Attributes. C. Rigney. A Rubens, W. Simpson.
S. Willens. January 1997. (Format: TXT=l 18880 bytes) (Obsoleted by RFC2138)
(Status: PROPOSED STANDARD)

2059 RADIUS Accounting. C. Rigney. January 1997. (Formal: TXT =44237 bytes) (Obsoleted
by RFC2139) (Status: INFORMATIONAL)

2113 IP Router Alert Option. D. Katz. February 1997 (Formal: TXT=7924 bytes) (Status:
PROPOSED STANDARD)

2138 Microsoft Vendor-specific RADIUS attributes. C. Rigney, A. Rubens, W. Simpson.
S. Willens. April 1997. (Format: TXT=I24O7 bytes) (Obsoletes RFC2058) (Status:
PROPOSED STANDARD)

2139 RADIUS Accounting. C. Rigney. April 1997. (Formal: ТХГ—44919 bytes) (Obsoletes
RFC2059) (Status: INFORMATIONAL)

2194 Review of Roaming Implementations. B. Aboba. J. Lu. J. Ding. W. Wang. September
1997. (Format; TXT=8I533 bytes) (Status: INFORMATIONAL)

2290 Mobile-lPv4 Configuration Option for PPP IPCP. J. Solomon and S. Glass. February
1998. (Format: TXT=39421 bytes) (Updates RFC2002) (Status: PROPOSED
STANDARD)

2344 Reverse Tunneling for Mobile IP. G. Montenegro. May 1998. (Format :TXT=39468
bytes) (Status: PROPOSED STANDARD)

2356 Sun's SKIP Firewall Traversal for Mobile IP. G. Montenegro and V. Gupta. June 1998
(Formal: TXT=53198 bytes) (Status: INFORMATIONAL)

2477 Criteria for Evaluating Roaming Protocols. B. Aboba and G. Zorn. December 1998.
(Formal: TXT=23530 bytes) (Status: INFORMATIONAL)

2486 The Network Access Identifier. B. Aboba and M. Beadles. January 1999. (Format:
TXT= 14261 bytes) (Status. PROPOSED STANDARD)

250) Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and
Evaluation Considerations. S. Corson and J. Macker. January 1999. (Format:
TXT=28912 bytes) (Status: INFORMATIONAL)

2521 ICMP Security Failures Messages. P. Karn and W. Simpson. March 1999. (Format:
TXT=14637 bytes) (Status: EXPERIMENTAL)

2548 Microsoft Vendor—specific RADIUS Attributes. G. Zom March 1999. (Format:
TXT=80763 bytes) (Status: INFORMATIONAL)

2607 Proxy Chaining and Policy Implementation in Roaming
Глава 4: Разрешение адресов

826 Ethernet Address Resolution Protocol’ On Convening Network Protocol Addresses
to 48-bit Ethernet Address for Transmission on Ethernet Hardware

903 Reverse Address Resolution Protocol

925 Muln-LAN Address Resolution

1027 Using ARP to Implement Transparent Subnet Gateways, S Carl-Mitchell and J S.
Quanerman. Oct-Ol-1987. (Format: TXT=2I297 bvles) (Status: UNKNOWN)

1029 More Fault-tolerant Approach to Address Resolution for a Multi-LAN System of
Ethernets. G.Parr. May-01-1988. (Format: TXT=44019 bytes) (Status. UNKNOWN)

1107 Plan for Internet Directory Services K. R. Soilins. Jul-01-1989. (Format: TXT=51773
bytes) (Status: INFORMATIONAL)

1112 Host Extensions for IP multicasting. S. E. Deering Aug-01-1989. (Formal: TXT=39904
bytes) (Obsoletes RFCO988, RFC1054) (Updated by RFC2236) (Status: STANDARDj

1293 Inverse Address Resolution Protocol. T. Bradley and C Brown. January 1492. (Format:
TXT=1I368 bytes) (Obsoleted by RFC2390) (Status: PROPOSED STANDARD)

1329 Thoughts On Address Resolution for Dual MAC FDDI Network' P. Kuehn. May 1992.
(Format: TXT=58150 bytes) (Status: INFORMATIONAL)

1433 Directed ARP. J. Garrett. J Hagen, and J Wong March 1493. (Format: TXT=41028
bytes) (Status: EXPERIMENTAL)

1868 ARP Extens.on-UNARP G Malkin. November 1995. (Format TXT=768I bytes)
(Status: EXPERIMENTAL)

1931 Dynamic RARp Extensions for Automatic Network Address Acquisition. D. Brownell.
April 1996. (Format: TXT=470')5 bvtes) (Status: PROPOSED STANDARD)

2390 Inverse Address Resolution Protocol. T. Bradley and C. Brown. A. Malis. AuguM 1998
(Format. TXT=20849 bytes) (Obsoletes RFC1293) (Status: PROPOSE D STANDARD)

Глава 5: IP-маршрутизация

917 Toward An Internet Standard Scheme Гог Subnelting

932 Toward An Internet Standard Scheme For Subnettmg

936 Toward An Internet Standard Scheme For Subnelting

940 Toward an Internet Standard Scheme For Subnelting

950 Internet Standard Subnelting Procedure

1042 Standard for Transmission of IP datagrams Over IEEE 802 Networks. J. Postel and J.
K. Reynolds. Feb-01-1988. (Formal TXT=34359 bytes) (Obsoletes RFCO948) (Status:
STANDARD)

1136 Administrative Domains and Routing Domans: A Model for Routing in the Internet.
S. Hares and D Katz Dec-Ol 1989. (Format: TXT=22158 bytes) (Status:
INFORMATIONAL)

1219 On the Assignment of Subnet Numbers. P. F Tsuchiaya. Apr-01 1991 (Format:
TXT=30609 bytes) (Status: INFORMATIONAL)
1234

1335

1347

1365

1366

1375

1385

1454

1466

1475

1526

1550

1597

1621

1622

1627

1667

1668

1669

Tunneling IPX Traffic Through IP Networks. D. Provan. Jun-01-1991. (Formal:
TXT=12333 bytes) (Status: PROPOSED STANDARD)

A Two-tier Address Structure for the Internet: A Solution to the Problem of Address
Space Exhaustion. Z. Wang and J. Crowcroft. May 1992. (Format: TXT=15418 bytes)
(Status: INFORMATIONAL)

TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet
Addressing and Routing. R. Callon June 1992. (Format: TXT=26563, PS=42398 bytes)
(Status: INFORMATIONAL)

An IP Address Extension Proposal. K. Siyan. September 1992 (Formal: TXT=12790
bytes) (Status: INFORMATIONAL)

Guidelines for Management of IP Address Space. E. Gerich. October 1992. (Format:
TXT=17793 bytes) (Obsoleted by RFC1466) (Status: INFORMATIONAL)

Suggestion for New Classes of IP Addresses. P. Robinson. October 1992. (Format;
TXT= 16990 bytes) (Status: INFORMATIONAL)

EIP: The Extended Internet Protocol. Z. Wang. November 1992. (Format: TXT=39I23
bytes) (Status: INFORMATIONAL)

Comparison of Proposals for the Next Version of IP. T. Dixon. May 1993. (Format:
TXT=35064 bytes) (Status: INFORMATIONAL)

Guidelines for Management of IP Address Space. E. Gerich. May 1993. (Format:
TXT=22262 hvtes) (Obsoletes RFC1366) (Status: INFORMATIONAL)

TP/IX: The Next Internet R. Ullmann. June 1993. (Formal: TXT=77854 bytes) (Status:
EXPERIMENTAL)

Assignment of System Identifiers forTUBA/CLNP Hosts. D. Piscitcllo. September
1993. (Format: TXT=I6848 bytes) (Status: INFORMATIONAL)

IP Next Generation (IPng) White Paper Solicitation. S Bradner and A Mankin
December 1993. (Formal: 7XT=12472 bytes) (Status: INFORMATIONAL)
Address Allocation for Private Internets. Y. Rekhter, В Moskowitz. D Karrenberg.
and G. de Groot. March 1994. (Format: TXT=I743O bytes) (Obsoleted by BCP0005,
RFC 1918) (Status: INFORMATIONAL)

Pip Near-term Architecture. P. Francis. May 1994 (Formal: TXT=I289O5 bytes)
(Status: INFORMATIONAL)

Pip Header Processing. P. Francis May 1994. (Format: TXT=34837 bytes) (Status:
INFORMATIONAL)

Network 10 Considered Harmful (Some Practices Shouldn't be Codified). E. Lear, E.
Fair, D. Crocker, and T. Kessler. June 1994. (Format: TXT=I8823 bytes) (Obsoleted
by BCP0005, RFC1918) (Status. INFORMATIONAL)

Modeling and Simulation Requirements for I Png. S. Svmington. D. Wood, and M
Pullen. August 1994. (Formal. TXT=I729I bytes) (Status: INFORMATIONAL)
Unified Routing Requirements for IPng. D. Estrin. T. Li. and Y. Rekhter August 1994.
(Format: TXT=5IO6 bytes) (Status: INFORMATIONAL)

Markel Viability as a IPng Criteria. J. Curran August 1994 (Formal TXT=8099 bytes)
(Status: INFORMATIONAL)
1670 Inpul to [Png Engineering Considerations. D. Heagerly. August 1994. (Format.
TXT=5350 bvtes) (Status; INFORMATIONAL)

1671 IPng White Paper on Transition and Other Considerations. B. Carpenter. August 1994.
(Formal TXT=1763I bytes) (Status: INFORMATIONAL)

1672 Accounting Requirements for IPng. N Brownlee. August 1994. (Format: TXT=6I84
bytes) (Status: INFORMATIONAL)

1673 Electrical Power Research Institute Comments on IPng. R. Skelton. August 1994.
(Format: TXT=7476 bytes) (Status: INFORMATIONAL)

1674 A Cellular Industry View of IPng. M Taylor. August 1994. (Format TXT=6I57 bytes)
(Status: INFORMATIONAL)

1675 Security Concerns for IPng. S. Bellovin. August 1994. (Format: TXT=8290 bvtes)
(Status INFORMATIONAL)

1676 INFN Requirements for IPng. A Ghiselli, D. Salomon), and C. Visloli. August 1994.
(Format: TXT—8493 bytes) (Status: INFORMATIONAL)

1677 Tactical Radio Frequency Communication Requirements for IPng. B. Adamson. August
1994. (Format: TXT=24065 bytes) (Status; INFORMATIONAL)

1678 IPng Requirements of Large Corporate Networks. E. Britton and J Tavs. August 1994
(Formal: TXT= 18650 bytes) (Status: INFORMATIONAL)

1679 HPN Working Group Input to the IPng Requirements Solicitation. D Green, P. key,
D. Marlow, and K. O’Donoghue. August 1994. (Format: TXT=I7846 bytes) (Status:
INFORMATIONAL)

1680 IPng Support for ATM Services. C. Brazdziunas. August 1994. (Format: TXT=17846
bytes) (Status: INFORMATIONAL)

1681 On Many Addresses per Host. S. Bellovin. August 1994. (Format: TXT=11964 bytes)
(Status: INFORMATIONAL)

1682 IPng BSD Host Implementation Analysis. J. Bound. August 1994. (Format: TXT=22295
bytes) (Status: INFORMATIONAL)

1683 Multiprotocol Interoperability In IPng. R. Clark. M Ammar, and K. Calvert. August
1994. (Format: TXT=28201 bytes) (Status: INFORMATIONAL)

1686 IPng Requirements: A Cable Television Industry Viewpoint. M Vecchi. August 1994.
(Format: TXT-39052 bytes) (Status: INFORMATIONAL)

1687 A Large Corporate User’s View of IPng. E. Fleischman. August 1994. (Format:
TXT=3412O bytes) (Status: INFORMATIONAL)

1688 IPng Mobility Considerations W Simpson. August 1994. (Format: TXT=I9151 bytes)
(Status: INFORMATIONAL)

1705 Six Virtual Inches to the Left: The Problem With IPng. R Carlson, and D. Ficarella.
October 1994. (Format: TXT=65222 bytes) (Status: INFORMATIONAL)

1707 CATNIP: Common Architecture for the Internet. M. McGOvern and R Ullmann.
October 1994. (Format TXT=37568 bytes) (Status: INFORMATIONAL)

1710 Simple Internet Protocol Plus White Paper. R. Hinden October 1994 (Format:
TXT=56910 bytes) (Status: INFORMATIONAL)
1715 The Н Ratio for Addresses per Host. C. Huitema. November 1994. (Format: TXT=7392
bytes) (Status: INFORMATIONAL)

1719 A Direction lor IPng. P. Gross. December 1994. (Format: TXT=11118 bytes) (Status:
INFORMATIONAL)

1726 Technical Criteria for Choosing IP The Next Generation (IPng). C. Partridge and F.
Kastenhoz. December 1994. (Format: TXT=74109 bytes) (Status: INFORMATIONAL)

1744 Observations on the Management of the Internet Address Space. G. Huston. December
1994. (Format: TXT=43675 bytes) (Status; PROPOSED STANDARD)

1752 Tiie Recommendation for the IP Next Generation Protocol. S Bradner and A. Mankin
January 1995. (Format: TXT=127784 bytes) (Status: PROPOSED STANDARD)

1753 IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture.
N Chiappa. December 1994. (Formal: TXT=46586 bytes) (Status: INFORMA-
TIONAL)

1797 Class A Subnet Experiment. Internet Assigned Numbers Authority (IANA), April 1995.
(Format: TXT=6779 bytes) (Status: EXPERIMENTAL)

1809 Using the Flow Label Field in IPv6. C. Partridge. June 1995 (Format: TXT=1359I
bytes) (Status: INFORMATIONAL)

1814 Unique Addresses Are Good. E. Gerich. June 1995. (Format: TXT=5936 bytes) (Status:
INFORMATIONAL)

1860 Variable Length Subnet Table for IPv4. T. Pummill and В Manning. October 1995.
(Format: TXT=5694 bytes) (Obsoleted by RFC1878) (Status: INFORMATIONAL)

1878 Variable Length Subnet Table for IPv4. T Pummill and B. Manning. December 1995.
(Formal: TXT=19414 bytes) (Obsoletes RFCI860) (Status: INFORMATIONAL)

1879 Class A Subnet Experiment Resultsand Recommendations. В Manning. January 1996
(Format. TXT=10589 bytes) (Status: INFORMATIONAL)

1880 IPv6 Address Allocation Management. IAB&IESG. December 1995. (Format;
TXT=32I5 bytes) (Status: INFORMATIONAL)

1883 Internet Protocol, Version 6 (IPv6) Specification. S. Deering and R Hinden December
1995. (Format: TXT82O89 bytes) (Status. PROPOSED STANDARD)

1884 IP Version 6 Addressing Architecture. R. Hinden and S. Deering, Editors. December
1995. (Format: TXT=37860 bytes) (Obsoleled by RFC2373) (Status; PROPOSED
STANDARD)

1885 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6). A. Contra and S. Deering. December 1995. (Format: TXT=32214 bytes) (Status:
PROPOSED STANDARD)

1886 DNS Extensions to support IP version 6. S. Thomson and C. Huitema. December 1995.
(Formal: TXT=6424 bytes) (Status; PROPOSI D STANDARD)

1887 An Architecture for IPv6 Unicast Address Allocation. ¥. Rckhlerand T. Li, Editors.
December 1995. (Format: TXT=66066 bytes) (Status: INFORMATIONAL)

1888 OSI NSAPs and IPv6. J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, and
A. Lloyd August 1996. (Format: TXT=36469 bvtes) (Status EXPERIMENTAL)
1897 IPv6 Testing Address Allocation. R. Hinder! and J. Postel. January 1997. (Formal.
TXT“6643 bytes) (Status: EXPERIMENTAL)

1900 Renumbering Needs Work. B. Carpenter and Y. Rekhter. February 1996. (Formal:
TXT=9528 bytes) (Status; INFORMATIONAL)

1916 Enterprise Renumbering: Experience and Information Solicitations. H. Berkowitz, p.
Ferguson. W Leland, and P. Nesser February 1996 (Format: TXT=I6I17 bytes)
(Status: INFORMATIONAL)

1918 Address Allocation for Private Internets. Y. Rekhter. В Moskowitz, D. Karrenberg,
G. J. de Groot, and E. Lear. February 1996 (Format: TXT=22270 bytes) (Obsoletes
RFCI627, RFC1597) (Also BCP0005) (Status: BEST CURRENT PRACTICES)

1933 Transition Mechanism for IPv6 Hosts and Routers. R Gilligan and E. Nordmark. April
1996. (Format: TXT=47005 bytes) (Status; PROPOSED STANDARD)

1955 New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG. R Hinden.
June 1996. (Format: TXT=IO115 bytes) (Status: INFORMATIONAL)

1970 Neighbor Discovery for IP Version 6((Pv6) T. Nartcn, E. Nordmark, and W Simpson.
August 1996. (Format: TXT=I97632 bytes) (Status: PROPOSED STANDARD)

1971 IPv6 Stateless Address Autoconfiguration. S. Thomson and T. Narten. August 1996
(Format: TXT=61210 bvtes) (Obsoletes RFC1971) (Status: DRAFT STANDARD)

1972 Transmission of IPv6 Packets Over Ethernet Networks. M. Crawford. August 1996.
(Format: TXT=6353 bytes) (Status: PROPOSED STANDARD)

1981 Path MTU DiscOvery for IP version 6. J. McCann. S Deering, and J Mogul. August
1996. (Format: TXT=56890 bytes) (Status; PROPOSED STANDARD)

2008 Implications of Various Address Allocation Policies for Internet Routing. Y Rekhter
and T. Li. October 1996. (Formal: TXT=34717 bvtes) (Also BCP0007) (Status: BEST
CURRENT PRACTICES)

2019 Transmission of IPv6 Packets Over FDDI Networks. M. Crawford. October 1996
(Formal: TXT=12344 bytes) (Status PROPOSED STANDARD)

2023 IP Version 6 Over PPP. D. Haskin, E. Allen. October 1996. (Formal: TXT=2O275 bytes)
(Status: PROPOSED STANDARD)

2036 Observations on the Use of Components of the Class A Address Space Within the
Internet. G. Huston. October 1996. (Format: TXT=20743 bytes) (Status:
INFORMATIONAL.)

2071 Network Renumbering Overview: Why Would I Want it and What Is It Anyway? P.
Ferguson and H. Berkowitz. January 1997. (Format: TXT=33218 bvtes) (Status:
INFORMATIONAL)

2072 Rouler Renumbering Guide. H Berkowtiz. January 1997. (Format TXT=l 10591 bytes)
(Status: INFORMATIONAL)

2073 An IPv6 Provider-based Unicast Address Formal. Y. Rekhter, PI Lothberg, R. Hinden,
S. Deering, and J. Postel. January 1997. (Format: TXT=15549 bytes) (Obsoleted by
RFC2374) (Status: PROPOSED STANDARD)

2080 RIPng for IPv6. G. Malkin, R. Minnear. January 1997. (Format: TXT=47534 bvtes)
(Status: PROPOSED STANDARD)
2081

2101

2133

2147

2185

2292

2373

2374

2375

2391

2450

2452

2454

2460

2461

2462

2463

2464

RIPng Protocol Applicability Statement. G. Malkin January 1997. (Format: TXT=6821
bytes) (Status: INFORMATIONAL)

IPv4 Address Behavior Today. B. Carpenter, J. Crowcroft, and ¥ Rckhter. February
1997. (Format: TXT=3I4O7 bytes) (Status: INFORMATIONAL)

Basic Sockel Interface Extensions for IPv6. R. Gilligan. S. Thomson. J. Bound, and
W Stevens. April 1997 (Format: TXT=69737 bytes) (Status: INFORMATIONAL)
TCP and LDP Over IPv6 Jumbograins. D. Borman. Mav 1997. (Format: TXT=1883
bytes) (Status: PROPOSED STANDARD)

Routing Aspects of IPv6 Transition. R. Callon and D. Haskin. September 1997.
(Format: TXT=3128l bytes) (Status: INFORMATIONAL)

Advanced Sockets API for IPv6 W Stevens and M. Thomas. February 1998. (Format:
TXT= 152077 bytes) (Status: INFORMATIONAL)

IP Version 6 Addressing Architecture. R Hinden, S. Deering. July 1998. (Format:
TXT=52526 bytes) (Obsoletes RFCI884) (Status: PROPOSED STANDARD)

An IPv6 Aggregatabic Global Unicast Address Format. R. Hmden, M O’Dell, and S.
Deering. July 1998. (Formal: ТХГ=25068 bytes) (Obsoletes RFC2073) (Status:
PROPOSED STANDARD)

Address Assignments. R. Hinden and S. Deering. July 1998. (Format: TXT= 14356 bytes)
(Status: INFORMATIONAL)

Load Sharing Using IP Network Address Translation (LSNAT). P. Srisuresh and D.
Gan. August 1998. (Format: TXT=44884 bytes) (Status: INFORMATIONAL)

Proposed TLA and NLA Assignment Rule. R. Hinden. December 1998. (Format:
TXT=24486 bytes) (Status: INFORMATIONAL)

IP Version 6 Management Information Base for the Transmission Control Protocol
M. Daniele December 1998. (Format TXT=19066 bytes) (Status: PROPOSED
STANDARD)

IP Version 6 Management Information Base for the User Datagram Protocol. M
Daniele. December 1998. (Format: TXT=I5862 bytes) (Status: PROPOSED
STANDARD)

Internet Protocol, Version 6 (IPv6) Specification. S. Deering and R. Hmden. December
1998. (Format: TXT=85490 bytes) (Obsoletes RFC 1883) (Status. DRAFT
STANDARD)

Neighbor DiscOvcrv for IP Version 6(lPv6) T Nancn. E. Nordmark, and W: Simpson.
December 1998. (Format: TXT=222516 bytes) (Obsoletes RFC1970) (Status DRAFT
STANDARD)

1 Pv6 Stateless Address AutoconlTguration. S. Thomson and T. Narten. December 1998.
(Format: TXT=61210 bytes) (Obsoletes RFCI97I) (Status: DRAFT STANDARD)
Internet Control Message Protocol (ICMPv6) fertile Internet Protocol Version 6 (IPv6)
Specification. A. Contra and S. Deering. Decemer 1998. (Format TXT=34190 bytes)
(Obsoletes RFCI885) (Status; DRAFT STANDARD)

Transmission of IPv6 Packets Over Ethernet Networks. M. Crawford. December 1998.
(Format: TXT=I2725 bvtes) (Obsoletes RFCI972) (Status: PROPOSED STANDARD)
2465 Management Information Base for IP Version 6: Textual Conventions and General
Group D. Haskin and S Onishi December 1998. (Format: TXT=77339 bytes) (Status:
PROPOSED STANDARD)

2466 Management Information Base for IP Version 6:ICMPv6 Group D. Haskin and S.
Onishi. December 1998. (Format: TXT=27547 bytes) (Status: PROPOSED
STANDARD)

2467 Transmission of IPv6 Packets Over TDDI Networks. M. Crawford. December 1998.
(Format: TXT= 16028 bytes) (Obsoletes RFC20I9) (Status: PROPOSED STANDARD)

2470 Transmission of IPv6 Packets Over Token Ring Networks. M. Crawford, T. Narten,
and S. Thomas. December 1998. (Formal. TXT=21677 bytes) (Status. PROPOSED
STANDARD)

247] IPv6 Testing Address Allocation. R. Hinden, R. Fink, and J Postel December 1998
(Format: TXT=8O31 bytes) (Obsoletes RFC1897) (Status: EXPERIMENTAL)

2472 IP Version 6 Over PPP. D Haskin, E. Alien October 1996. (Format TXT=20275 bytes)
(Status: PROPOSED STANDARD)

2473 Generic Packet Tunneling in IPv6 Specification. A. Contra and S Deering December
1998. (Format: TXT=77956 bytes) (Status: PROPOSED STANDARD)

2491 IPv6 Over Non-broadcast Multiple Access (NBMA) networks. G. Armitage. P.
Schulter, M. Jork. and G. Harter. January 1999. (Formal: TXT=IOO782 bytes) (Status:
PROPOSED STANDARD)

2492 IPv6 Over ATM Networks. G.Armitage, P. Schulter, M. Jork January 1999. (Format:
TXT=21199 bytes) (Status. PROPOSED STANDARD)

2497 Transmission of IPv6 Packets Over ARCnet Networks. I. Souvatzis. January 1999.
(Format: TXT=10304 bytes) (Also RFCI20I) (Status: PROPOSED STANDARD)

2526 Reserved IPv6 Subnet Anycast Addresses. D. Johnson and S. Deering. March 1996,
(Format: TXT=I4555 bytes) (Status: PROPOSED STANDARD)

2529 Transmission of IPv6 Over IPv4 Domains Without Explicit Tunnels. B. Carpenter and
C. Jung March 1999. (Format: TXT=21049 bytes) (Status: PROPOSED STANDARD)

2545 Use ot BGP-4 Multiprotocol Extensions for IPv6 Interdomain Routing. P. Marques
and F. Dupont. March 1999 (Format TXT= 10209 bytes) (Status: PROPOSED
STANDARD)

2546 6Bone Routing Practice. A. Durand and B. Buclin. March 1999. (Formal: TXT= 17844
bytes) (Status: PROPOSED STANDARD)

2553 Basic Sockel Interface Extensions for IPv6 R Gilligan, S. Thomson, J. Bound and S
Stevens. March 1999. (Format: TXT=892I5 bytes) (Status. INFORMATIONAL)

2590 Transmission of IPv6 Packets Over Frame Relay

2675 IPv6 Jumbograms

2710 Multicast Listener Discovery (Ml D) for IPv6

2711 IPv6 Router Alert Option
Глава 6: Протоколы маршрутизации

823 DARPA Internet Gateway

827 Exterior Gateway Protocol Formal Specification

875 Gateways, Architectures, and Hcffalumps

888 Exterior Gateway Protocol Formal Specification

890 Exterior Gateway Protocol Formal Specification

904 Exterior Gateway Protocol Formal Specification

911 EGP Gateway Under Berkeley UNIX 4.2

970 On Packet Switches With Infinite Storage

975 Autonomous Confederations

985 Requirements Гог Internet Gateways—Draft

1046 Queuing Algorithms to Provide Type-of-service for IP Links. W. Prue and J. Postel.
Feb-01-1988. (Format: TXT=3OIO6 bytes) (Status: UNKNOWN)

1058 Routing Information Protocol. C.l. Hedrick. Jun-01-1988 (Format. TXT=93285 bytes)
(Updated by RFCI388.RFC1723) (Status: HISTORIC)

1074 NSFNET Backbone SPF-Based Interior Gateway Protocol. J. Rekhter. Oct-Ol-1988.
(Formal: TXT=36000 bvtes) (Obsoleted by RFCI323) (Status; UNKNOWN)

1075 Distance Vector Multicast Routing Protocol. D. Wailzman, C. partridge, and S. E.
Deering. Nov-01-1988. (Format; TXT=5473i bytes) (Status; EXPERIMENTAL)

1092 EGP and Policy-based Routing in the New NSFNET Backbone. J. Rekhter. Feb-01 -
1989 (Format: TXT=11865 bytes) (Status: UNKNOWN)

1093 NSFNET Routing Architecture. H. W. Braun. Feb-01-1989. (Formal: TXT=20629
bytes) (Status: UNKNOWN)

1102 Policy Routing in Internet Protocols. D. D. Clark. May-01-1989 (Format: TXT=59664
bytes) (Status: UNKNOWN)

1104 Models of Policy-based Routing. H W. Braun. Jun-01-1989. (Formal: TXT=25468
bytes) (Status: UNKNOWN)

1105 Border Gateway Protocol (BGP). K. Loughheed and Y.Rckhler. Jun-01-1989. (Format:
TXT=37644 bytes) (Obsoleted by RFCII63) (Status: EXPERIMENTAL)

1125 Policy Requirements for Interadniinistrative Domain Routing. D. Estrin. Nov-01-1989.
(Format: TXT=55248, PS=282123 bytes) (Status: UNKNOWN)

1131 OSPF Specification. J. Moy. Ocl-Ol-1989. (Formal: TXT=268. PS=85728O bytes)
(Obsoleted by RFCI247) (Status: PROPOSED STANDARD)

1133 Routing Between the NSFNET and the DDN. J Y. Yu and H. W. Braun. Nov-01-
1989. (Format: TXT=23169 bytes) (Status: INFORMATIONAL)

1136 Administrative Domains and Routing Domains: A Model for Routing in the Internet.
S Hares and D. Katz. Dec-01-1989. (Format: TXT=22158 bytes) (Status: INFOR-
MATIONAL)

1142 OSI IS IS Intradomam Routing Protocol D.Oran. Feb-01 1990. (Format.
TXT=425379, PS=I2O4297 bvtes) (Status: INFORMATIONAL)
1163 Border Gateway Protocol (BGP). К. Lougheed and Y Rekhter. Jun-01-1990. (Format:
TXT-69404 bytes) (Obsoletes RFCI 105) (Obsoleted by RFC1267) (Status:
HISTORIC)

1164 Application of the Border Gateway Protocol on the Internet. J. C. Honig, D Katz,
M. Mathis, Y. Rekhter and J. Y. Yu. Jun-01 -1990. (Format: TXT-56278 bytes)
(Obsoleted by RFC1268) (Status: HISTORIC)

1195 Use of OSI IS IS for Routing in TCP/IP and Dual Environments. R W Callon. Dec-
01-1990. (Format: TXT-187866. PS=362052 bytes) (Status: PROPOSED
STANDARD)

1222 Advancing the NSFNET Routing Architecture. H. W Braun and Y. Rekhter. May-
01-1991 (Formal: TXT-15067 bvtes) (Status: INFORMATIONAL)

1245 OSPF Protocol Analysis. J. Moy Jul-01 1991. (Format: TXT-26160, PS—33546 bvtes)
(Also RFCI247.RFC1246) (Status: INFORMATIONAL)

1246 Experience With OSPF Protocol. J. Moy. Jul-01-1991. (Format: TXT=70441,
PS-141924 bytes) (Also RFC1247, RFC1245) (Status: INFORMATIONAL)

1247 OSPF Version 2. J. Moy. Jul-01-1991. (Formal. TXT-433332.PS-989724 bytes)
(Obsoletes RFCI 131) (Obsoleted by RFC1252) (Status: PROPOSED STANDARD)

1252 OSPF Version 2 Management Information Base. F. Bakerand R Coltun. Aug-01-1991.
(Format: TXT-74471 bytes) (Obsoletes RFCI24S) (Obsoleted by RFCI253) (Also
RFC 1247, RFC 1245) (Status: PROPOSED STANDARD)

1253 OSPFVersion 2 Management Information Base. F. Bakerand R. Coltun Aug-01-1991
(Format; TXT-74453 bytes) (Obsoletes RFC1252) (Obsoleted by RFC1850) (Also
RFC1247, RFCI245, RFCI246) (Status PROPOSED STANDARD)

1254 Gateway Congestion Control Survey A Mankin and К Ramakrishnan. Jul-01-1991.
(Format: TXT=67609 bytes) (Status: INFORMATIONAL)

1264 Internet Engineering Task Force Internet Routing Protocol Standardization Criteria.
R M Hinden Oct-Ol 1991. (Formal ГХТ-17016 bytes) (Status: INFORMA-
TIONAL)

1265 BGP Protocol Analysis. Y. Rekhter Ocl-Ol-1991. (Formal: TXT—20728 bvtes) (Status:
INFORMATIONAL)

1266 Experience With the BGP Protocol. Y Rekhter. Oct-Ol-1991. (Formal: TXT—21928
bytes) (Status: INFORMATIONAL)

1267 Border Gateway Protocol 3(BGP-3). K. Lougheed and Y Rekhter. Oct-Ol-1991
(Format: TXT-80724 bytes) (Obsoletes RFCI 163) (Status: HISTORIC)

1268 Application of the Border Gateway Protocol in the Internet. Y. Rekhter and P. Gross.
Oct-Ol-1991. (Format: TXT 31102 bytes) (Obsoletes RFCI 164) (Obsoleted by
RFCI655) (Status: HISTORIC)

1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3. S. Willis
and J. W. Burruss. Oct-Ol-1991. (Formal: TXT-25717 bytes) (Status: PROPOSED
STANDARD)

1322 A Unified Approach to interdomain Routing. D. Estrin, Y. Rekhter. and S. Hotz May
1992 (Formal: TXT-96934 byres) (Status INFORMATIONAL)
1364

1370

1383

1387

1388

1389

1397

1403

1465

1477

1478

1479

1482

1504

1517

1519

1519

158)

BGP OSPF Interaction К Varadhan. September 1992.

Application Statement for the OSPF. Internet Architecture Board, L. Chapin. October
1992. (Format: TXT=4303 bytes) (Status: PROPOSED STANDARD)

An Experience in DNS based IP Routing

RIP Version 2 Protocol Analysis. G. Malkin. January 1993. (Format: TXT=5998 bytes)
(Obsoieted by RFCI72I) (Status: INFORMATIONAL)

RIP Version 2 Carrying Additional Information. G Malkin. January 1993. (Format.
TXT=16227 bytes) (Obsoieted by RFCI7213) (Updates RFC1058) (Status:
PROPOSED STANDARD)

RIP Version 2 MIB Extensions. G. Malkin. F. Baker. January 1993, (Format
TXT=23569 bytes) (Obsoieted by RFC 1724) (Status: PROPOSED STANDARD)
Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway
Protocol. D. Haskin. January 1993. (Formal: TXT=4124 bvtes) (Status: PROPOSED
STANDARD)

BGP OSPF Interaction. K. Varadhan. January 1993. (Formal: TXT=36173 bytes)
(Obsoletes RFC1290) (Aho FY100I0) (Status: INFORMATIONAL)

Routing Coordination for X 400 MHS Services Within a Multi-Prolocol/Multi-Network
Environment Table Format V3 for Static Routing.

IDPR as a Proposed Standard. M Steenstrup. July 1993. (Format: TXT=77854 bvtes)
(Status: EXPERIMENTAL)

An Architecture for ln(erdomain Policy Routing. M. Steenstrup. July 1993. (Format:
TXT=275823 bytes) (Status: PROPOSED STANDARD)

Inter-domain Policy Routing Protocol Specification Version 1. M. Steenstrup. Julv
1993. (Format: TXf-275823 bytes) (Status: PROPOSED STANDARD)

Aggregate Support in the NSFNET Policy-based Routing Database. Mark Knopper
and Steven J Richardson. July 1993. (Format: TXT=25330 bvtes) (Status: INFORMA-
TIONAL)

Appletalk Update-based Routing Protocol: Enhanced Appletalk Routing. A
Oppenheimer. August 1993. (Formal: TXT—201553 bvtes) (Status:
INFORMATIONAL)

Applicability Statement for the Implementation of Classless Inter-Domain Routing
(CIDR). Internet Engineering Steering Group. R. Hinden. September 1993. (Format
TXT=7357 bytes) (Status: PROPOSED STANDARD)

Classless Inlerdomain Routing (CIDR)' an Address Assignment and Aggregation
Strategy. V. Fuller. T. Li. J Yu, and К Varadhan September 1993. (Formal.
TXT=59998 bytes) (Obsoletes RFC1338) (Status: PROPOSED STANDARD)

Exchanging Routing Information Across Provider Boundries in the CIDR Environment.
Y Rekhter and C. Topolcic. September 1993. (Format: TXT=20389 bytes) (Status:
INFORMATIONAL)

Protocol Analysis for Extensions to RIP to Support Demand Circuits. G. Mevcr.
February 1994. (Formal: TXT=7536 bytes)
1582 Extensions to RIP to Support Demand Circuits. G Meyer. February 1994. (Format;
TXT=63271 bvtes) (Status: PROPOSED STANDARD)

1583 OSPF Version 2. J. Moy. March 1994. (Format; TXT=532636, PS=990794 bytes)
(Obsoletes RFC1247) (Obsoleted by RFC2178) (Status; DRAFT STANDARD)

1584 Multicast Extensions to OSPF. J. Moy. March 1994. (Formal: TXT=262463.
PS=426358 bytes) (Status: PROPOSED STANDARD)

1585 MOSPF; Analysis and Experience. J. Moy. March 1994. (Format: ГХТ=297э4 bytes)
(Status: INFORMATIONAL)

1586 Guidelines Гог Running OSPF Over Frame Relay Networks O. deSouza and M
Rodrigues. March 1994. (Format: TXT=I4968 bvtes) (Status: INFORMATIONAL)

1587 The OSPF NSSA Option. R Coliun and V. Fuller. March 1994. (Formal: TXT=374I2
bvtes) (Status: PROPOSED STANDARD)

1654 A Border Gateway Protocol 4 (BGP-4) Y. Rekhter and T. I i. Editors. July 1994.
(Formal: TXT=130l 18 bytes) (Obsoleted by RFC1771) (Status: PROPOSED
STANDARD)

1701 Generic Routing Encapsulation (GRE). S. Hanks. T. Li, D. Farinacci, and P. Trains
October 1994. (Format: TXT=15460 bytes) (Status: INFORMATIONAL)

1702 Generic Routing Encapsulation Over IPv4 Networks. S. Hanks, T. Li, D. Farinacci,
and P. Traina. October 1994 (Format;TXT=7288 bytes) (Status: INFORMATIONAL)

1721 RIP Version 2 Protocol Analysis. G. Malkin. November 1994. (Formal: TXT=6680
bytes) (Obsoletes RFC 1387) (Status; INFORMATIONAL)

1722 RIP Version 2 Protocol Applicability Statement. G.Malkin. November 1994. (Format:
TXT=10236 bytes) (Status: DRAFT STANDARD)

1723 RIP Version 2—Carrying Additional Information. G. Malkin. November 1994. (Format:
TXT=I8597 bytes) (Obsoletes RFCI388) (Updates RFC1058) (Status: DRAFI
STANDARD)

1745 BGP4/IDRP Гог 1P-OSPF Interaction. К Varadhan. S Hares, and Y. Rekhter
December 1994. (Format: TXT=43675 bytes) (Status: PROPOSED STANDARD)

1765 OSPF Database Overflow. J.Moy. March 1995. (Format; TXT=21613 bytes) (Status:
EXPERIMENTAL)

1771 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter and T. Li. March 1995. (Formal:
TXT =11606 bytes) (Status; INFORMATIONAL)

1772 Application of the Border Gateway Protocol in the Internet Y. Rekhter & P Gross.
March 1995. (Formal; TXT=43916 bytes) (Obsoletes RFCI655) (Status: DRAFT
STANDARD)

1773 of (he BGP 4 protocol. P. Traina. March 1995. (Format: TXT=)9936 bvtes) (Obsoletes
RFCI656) (Status: INFORMATIONAL)

1774 BGP-4 Protocol Analysis. P. Traina, Editor March 1995. (Format: TXT=23823 bytes)
(Status: INFORMATIONAL)

1786 Representation of the IP Routing Policies in a Routing Registry (ripe-8l++). T, Bates,
E. Gerich, L. Joncheray, J. M Jouanigot. D. Karrenberg, M Тсгрмга, and J. Yu.
March 1995. (Format: TXT=I33643 bytes) (Status- INFORMATIONAL)
1787 Routing in a Multi-provider Internet. Y Rekhter April 1995. (Format: TXT=20754
bytes) (Status’ INFORMATIONAL)

1793 Extending OSPF to Support Demand Circuits. J Moy. April 1995. (Formal.
TXT=16389 bytes) (Status: EXPERIMENTAL)

1817 CIDR and Glassful Routing. Y. Rekhter. August 1995. (Format: TXT=34I6 bytes)
(Status: INFORMATIONAL)

1863 A BGP/IDRP Route Server Alternative to Full Mesh Routing. D. Haskin. October
1995. (Format: TXT=37426 bytes) (Obsoletes RFC1645 bytes) (Status:
EXPERIMENTAL)

1923 RIPvl Applicability Statement for Historic Status. J. Halpern & S Bradner. March
1996. (Format: TXT=5560 bytes) (Status: INFORMATIONAL)

1965 Autonomous System Confederations for BGP. P. Traina. June 1996. (Format:
TXT=I3575 bytes) (Status: EXPERIMENTAL)

1966 BGP Route Reflection: An alternative to Full Mesh IBGP. T. Bates and R.
Chandrasekeran. June 1996. (Format: TXT= 14320 bytes) (Status: EXPERIMENTAL)

1992 The Nimrod Routing Architecture. I Casineyra, N. Chiappa. and M. Steestrup. August
1996. (Formal: TXT=46255 bytes) (Status: INFORMATIONAL)

1997 BGP Communities Attribute. R Chandra. P. Traina. and T. Li. August 1996. (Format:
TXT=8275 bytes) (Status: PROPOSED STANDARD)

1998 An Application of the BGP Community Attribute in Multi-home Routing. E. Chen &
T. Bates. August 1996. (Format: TXT=I6953 bytes) (Status: INFORMATIONAL)

2009 GPS-based Addressing and Routing. T. Innclinski and J. Navas. November 1996.
(Format: TXT=66229 bvtes) (Status: EXPERIMENTAL)

2082 RIP-2 MD5 Authenticalion. F. Baker and R Atkinson. January 1997. (Format:
TXT=25436 bytes) (Status: PROPOSED STANDARD)

2091 Triggered Extensions to RIP to Support Demand Circuits. G. Meyer and S Sherry.
January 1997. (Formal: TXT=44835 bytes) (Status: PROPOSED STANDARD)

2092 Protocol Analylsis for Triggered RIP. S Sherry, G Mever. January 1997. (Format:
TXT=10865 bytes) (Status: INFORMATIONAL)

2102 Multicast Support for Nimrod: Requirements and Solution Approaches. R
Ramanathan. February 1997. (Formal: TXT=50963 bytes) (Status:
INFORMATIONAL)

2103 Mobility Support for Nimrod: Challenges and Solution Approaches. R. Ramanathan.
February 1997. (Format: TXT=4I352 bytes) (Status: INFORMATIONAL)

2117 Protocol Independent Multicast-Sparse Mode (PIM- SM): Protocol Specification. D.
Esirin, D. Farinacci, A Helmy, D. Thaler, S. Deering. M Handley, V Jacobson, C.
Liu, P. Sharma, and L. Wei. June 1997. (Format: TXT—I5I886 bytes) (Obsoleted by
RFC2362) (Status: EXPERIMENTAL)

2)54 OSPF with Digital Signatures. S. Murphy, M. Badger. B. Wellington. June 1997.
(Format- TXT=7270l bytes) (Status: EXPERIMENTAL)

2178 OSPF Version 2. J. Moy. July 1997. (Format: TXT=495866 bytes) (Obsoletes RFC 1583)
(Obsoleted bv RFC2328) (Status: DRAFT STANDARD)
2189 Core-based Trees (СНТ Version 2) Multicast Routing. A Balardie. September 1997.
(Format TXT=52O43 bvtes) (Status: EXPERIMENTAL)

2201 Core-based Trees (CBT) Multicast Routing Architecture. A. Ballardie. September 1997.
(Format: TXT=38l)40 bvtes) (Status: EXPERIMENTAL)

2260 2260Scalabic Support Гог Multi-homed Multi provider Connectivity T Bales, Y.
Rekhter January 1998 (Format. EXT =28085 bytes) (Status: INFORMATIONAL)

2270 Using a Dedicated AS Гог Sites Homed to a Single Provider. J. Stewart, T. Bates. R.
Chadra. and E. Chen. January 1998. (Formal: TXT= 12063 bytes) (Status:
INFORMATIONAL)

2280 Routing Policy Specification Language (RSPL). C Alaellinoglu. T. Bates. E Gerich,
D. Karrenbcrg, D. Meyer, M. Terpslra. and C. Villamizar. January 1998. (Format:
TXT-114985 bytes) (Status: PROPOSED STANDARD)

2281 Cisco Hol Standby Router Protocol (HSRP). T. Li. В Cole. P Morton, D Li. March
1998. (Format: TXT=35I6I bvtes) (Status: INFORMATIONAL)

2283 Multiprotocol Extensions for BGP-4. T Bates. R. Chandra. D. Katz, Y. Rekhier.
February 1998. (Formal. TXT= 18946 bytes) (Status: PROPOSED STANDARD)

2328 OSPF Version 2. J Moy. April 1998. (Format: TXT=447367 bytes) (Obsoletes
RFC2178) (Also STD0054) (Status: ST ANDARD)

2329 OSPF Standardization Report. J. Moy. April 1998 (Format. TXT=I5I3O bytes) (Status:
INFORMATIONAL)

2338 Virtual Router Redundancy Protocol S. Knight. D Weaver. D Whipple. R Hinden,
D. Mitzel. P Hunt, P. Higginson, M. Shand, and A Lindem. April 1998. (Format:
TXT=59871 bytes) (Status: PROPOSED STANDARD)

2362 Protocol Independent Multicast-Sparse Mode (PIM-SM) Protocol Specification. D
Esirin. D Farinacci, A Helmy, D. Thaler. S. Deering, M. Handley, V. Jacobson, C.
Liu. P. Sharma, and L. Wei. June 1998. (Format: TXT=I59833 bytes) (Obsoletes
RFC2117) (Status: EXPERIMENTAL)

2370 Tlie OSPF Opaque LSA Option. R Collun. July 1998. (Formal. TXT=33789 bytes)
(Also RFC2328) (Status: PROPOSED STANDARD)

2385 Prolection оГ BGP Sessions via the TCP MD5 Signature Option. A. Heffernan August
1998. (Formal: TXT= 12315 bytes) (Status: PROPOSED STANDARD)

2439 BGP Route Flap Damping. C Villamiar. R. Chandra. R. Gros indan. November 1998
(Formal: TXT=86376 bytes) (Status PROPOSED STANDARD)

2453 RIP Version 2. G. Malkin. November 1998. (Format. TXT=98462 bytes) (Obsoletes
RFCI388, RFCJ723) (Updates RFCI723. RFCI388) (Also STD0056) (Status:
STANDARD)

2519 A Framework for Interdomain Route Aggregation. E. Chen, J. Stewart. February 1999.
(Format. TXT=25394 bytes) (Status: INFORMATIONAL)

2622 Routing Policy Specification Language (RPSL)

2650 Using RPSL in Practice

2676 QoS Routing Mechanisms and OSPF Extensions

2715 Interoperability Rules for Multicast Routing Protocols
Глава 7: Транспортный/межхостовый уровень

1162 Connectionless Network Protocol (ISO 8473) and End Systems to Intermediate System
(ISO 9542) Management Information Base. G. Satz Jun-01-1990. (Format:
TXT=1O9893 bytes) (Obsoleted by RFC1238) (Status: EXPERIMENTAL)

Глава 8: Протокол управления передачей

675 Transmission Control Protocol

700 Protocol Exerperiment

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

761 Transmission Control Protocol

793 Transmission Control Protocol

794 Pre-emption

813 Window and Acknowledgement Strategy in TCP

872 TCP on-a-LAN

879 TCP Maximum Segment Size and Related Topics

889 Internet Delay Experiments

896 Congestion Control in 1P/TCP Internetworks

962 TCP-4 Prime

964 Some Problems With the Specifications of the Military Standard Transmission Control
Protocol

1006 ISO Transport Services On Top ofTCP: Version 3. M.T. Rose and D.E. Cass. May-
01-1987. (Format TXT-31935 bytes) (Obsoletes RFC0983) (Status. STANDARD)

1072 TCP Extensions for Long-delay Paths. V. Jacobson and R.T. Braden. Oct-Ol-1988.
(Format: TXT=36000 bytes) (Obsoleted by RFC1323) (Status: UNKNOWN)

1078 TCP port service Multiplexer (TCPMUX). M.Loltor.Nov-01-1988. (Formal:
TXT=3248 bytes) (Status: UNKNOWN)

1106 TCP Big Window and NAK Options. R. Fox. Jun-01-J989. (Formal: TXT=37105 bvtes)
(Status: UNKNOWN)

1110 Problem With the TCP Big Window Option. A. M McKenzie Aug-01-1989. (Format:
TXT-5778 bytes) (Status: UNKNOWN)

1144 Compressing TCP/IP Headers for Low-speed Serial Links. V Jacobson. Feb-0l-199U.
(Formal: TXT=12O959. PS-534729 bytes) (Status: PROPOSED STANDARD)

1185 TCP Extensions for High-speed Paths. V Jacobson, R T. Braden, and L. Zhang. Oct-
01-1990. (Format: TXT=49508 bytes) (Obsoleted by RFC1323) (Status:
EXPERIMENTAL)

1263 TCP Extensions Considered Harmful. S. O’Malley and L. L. Peterson. Oct-Ol-1991.
(Format: TXT=54078 bytes) (Status: INFORMATIONAL)

1323 TCP Extensions for High Performance. V. Jacobson, R. Braden, and D. Borman. May
1992 (Format: TXT-84558 bvtes) (Obsoletes RFCI072. RFC1185) (Status:
PROPOSED STANDARD)
1337 TIME-WAIT Assassination Hazards for TCP. R Braden. May 1992. (Format:
TXT=22887 bytes) (Status: INFORMATIONAL)

1379 Extending TCP for Transactions—Concepts. R. Braden. November 1992. (Format:
TXT=9I353 bytes) (Status: INFORMATIONAL)

1644 T/TCP—TCP Extensions for Transactions Functional Specifications. R Braden July
1994. (Format: TXT =87362 bytes) (Status: EXPERIMENTAL)

1693 An Extension of TCP: Partial Order Service. T. Connolly. P Amer, and P. Conrad.
November 1994. (Format: TXT=26I63 bytes) (Status: PROPOSED STANDARD)

2001 TCP Siow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery
Algorithms. W. Stevens. January 1997. (Format: TXT=1298I bytes) (Status:
PROPOSED STANDARD)

2018 TCP Selective Acknowledgement Options M. Mathis, J Mahdavi, S. Floyd. A.
Romanow. October 1996. (Format: TXT=25671 bytes) (Status: PROPOSED
STANDARD)

2140 TCP Control Block Interdependence. J. Touch. April 1997. (Formal: TX 1=26032 bytes)
(Status. INFORMATIONAL)

2398 Some Testing Tools lor TCP Implementors. S. Parker. C. SchmecheL August 1998.
(Format: TXT=24l07 bytes) (Obsoletes NONE) (Updates NONE) (Also NONE)
(Status: INFORMATIONAL)

2414 Increasing TCP’s Initial Window. M. Allman, S. Floyd, and C. Partridge. September
1998. (Formal: TXT=320)9 bytes) (Status: EXPERIMENTAL)

2415 Simulating Studies of Increased Initial TCP Window Size. K. Poduri and К Nichols.
September 1998. (Format: TXT=24205 bytes) (Status: INFORMATIONAL)

2416 When TCP Starts Up With Four Packets Into Only Three Buffers. T Shepard, C.
Partridge. September 1998. (Format: TXT= 12663 bytes) (Status: INFORMATIONAL)

2488 Enhancing TCP Over Satellite Channels using Standard Mechanisms. M. Allman, D.
Glover, and L. Sanchez. January 1999 (Format: TXT=47857 bytes) (Also BCPOO28)
(Status: BEST CURRENT PRACTICE)

2525 Known TCP Implementation Problems. V. Paxson, M. Allman, S. Dawson, W Fenner,
J. Griner, I. Heavens. K. Lahey, H. Semke. and B. Volz. March 1999. (Formal:
TXT=1372O1 bytes) (Status: INFORMATIONAL)

2581 TCP Congestion Control. M. Allman, V. Paxson, W. Stevens. April 1999. (Format:
TXT=3135I bytes) (Obsolets RFC200I) (Status: PROPOSED STANDARD)

2582 The NewReno Modification to TCP’S Fast Recovery Algorithm. S. Floyd. T
Henderson. April 1999. (Format: TXT=29393 byles) (Status: EXPERIMENTAL)

Глава 9: Протокол передачи пользовательских
дейтаграмм (UDP)

768 User Diagram Protocol
Глава 11: Telnet

91 Proposed User-User Protocol

97 First Cut al a Proposed Telnet Protcol

103 Implementation of Interrupt Keys

110 Response to NWG/RFC 110

114 File Transfer Protocol

135 Response to NWC/RFC 110

137 Telnet Protocol—a Proposed Document

139 Discussion of Telnet Protocol

158 Telnet Protocol A Proposed Document

172 File Transfer Protocol

190 DEC PDP-10-1MLAC Communication System

205 NETCRT—a Character Display Protocol

206 User Telnet—a Description of Initial Implementation

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

216 Telnet Access to UCSB’S Online System

265 File Transfer Protocol

318 Telnet Protocols

328 Suggested Telnet Protocol Changes

339 ML I NLT: A "Multi Telnet" Subsystem forTenex

340 Proposed Telnet Changes

346 Response to NWG/RFC 346

354 File Transfer Protocol

355 Response to NWG/RFC 346

357 Echoing Strategy for Satellite Links

377 Using TSO via ARPA Network Virtual Terminal

393 Comments on Telnet Protocol Changes

426 Reconnection Protocol

435 Telnet Issues

452 TEI ENET Command on Host LL

466 Telnet Logger/Server for Host LL-67

495 Telnet Protocol Specifications

513 Comments on New Telnet Specifications

529 Note on Protocol Synch Sequences

542 File I’ransfer Protocol

559 Comments on The New Telnet Protocol and its Implementation

160 Remote Controlled Transmission and Echoing Telnet Option
562 Modifications to the Telnet Specifications

563 Comments on the RCTE Telnet Option

570 Experimental Input Mapping Between NVT ASCII and UCSB Online System

576 Proposal and Identifying Linking

581 Corrections Io RFC 560: Remote Controlled Transmission and Echoing Telnet Option

587 Announcing New Telnet Option

593 Telnet and FTP Implementation Schedule Change

594 Second Thoughts in Defense of Telnei Go-Ahead

600 Interfacing an Illinois Plasma Terminal to the ARPANET

651 Revised Telnet Status Option

652 Telnet Output Carriage-return Disposition Option

653 Telnet Output Horizontal Tabstops Option

654 Telnet Output Horizontal Tab Disposition Option

655 Telnet Output Formfeed Disposition Option

656 Telnet Output Vertical Tabstops Option

657 Telnet Output Vertical Tab Disposition Option

658 Telnet Output Linefeed Disposition

659 Announcing Additional Telnet Options

669 Julv, 1975 Survey of New-Protocol Telnet Servers

679 July. 1975 Survey of New-Protocol Telnet Servers

681 Network UNIX

688 Tentative Schedule for the New Telnet Implementation for the TIP

701 Julv. 1975 Survey of New-Protocol Telnet Servers

702 July, 1975 Survey of New-Protocol Telnet Servers

703 July. 1975 Survey of New-Protocol Telnet Servers

718 Comments on RCTE Irom the Tenex Implementation Experience

719 Discussion on RCTE

726 Remote Controlled Transmission and Echoing Telnet option

727 Telnet Logout Option

728 Minor Pitfall in the Telnet Protocol

729 Telnet Byte Macro Option

730 Telnet Data Entry Terminal Option

731 Telnet Data Entry Terminal Option

735 Revised Telnet Byte Macro Option

736 Telnet SU PDUP Option

746 SUPDUP Graphics Extension

747 Recent Extensions to the SUPDUP Protocol

748 Telnet SUPDUP-Output Option
764 Telnet Protocol Specifications

765 File Transfer Protocol

779 Telnet Send-Location Option

782 Virtual Terminal Management Protocol

818 Remote User Telnet Service

854 Telnet Protocol Specifications

855 Telnet Option Specifications

856 Telnet Binary Transmissions

857 Telnet Echo Option

858 Telnet Suppress Go-Ahead Option

859 Telnet Status Option

860 Telnet Timing Mark Option

861 Telnet Extended Options: List Option

884 Telnet Terminal Type Option

885 Telnet End of Record Option

927 TACACS User Identification Telnet Option

930 Telnet Terminal Type Option

946 Telnet Terminal Location Number Option

959 File Transfer Protocol

1041 Telnet 3270 Regime Option. Y Rekhter. Jan-01-1988 (Format: TXT=1I6O8 bytes)
(Status: PROPOSED STANDARD)

1043 Telnet Data Entry Terminal option: DODIIS Implementation. A. Yasuda and T.
Thompson. Fcb-01-1988. (Format TXT=59478 bytes) (Updates RFC0732) (Status:
PROPOSED STANDARD)

1053 Telnet X.3 PAD Option. S Levy and T Jacobson Apr-01-1988. (Format: TXT=48952
bytes) (Status: PROPOSED STANDARD)

1073 Telnet Window Size Option. D. Waitzman. Oct-Ol-1988 (Format' TXT=7639 bvtes)
(Status: PROPOSED STANDARD)

1079 Telnet Terminal Speed Option. C. L. Hedrick. Dec-01-1988. (Format: TXT=4942 bytes)
(Status: PROPOSED STANDARD)

1080 Telnet Remote Flow Control Option C. L Hedrick Nov-01-1099. (Format: TXT=6688
bytes) (Obsoleted by RFC1372) (Status. UNKNOWN)

1091 Telnet Ternunal-type Option. J. VanBokkelen, Feb-01-1989. (Format: TXT=13439
bytes) (Obsoletes RFC0930) (Status- PROPOSED STANDARD)

1096 Telnet X Displav Location Option. G. A Marcy Mar-01-1989. (Format. TXT=4634
bytes) (Status: PROPOSED STANDARD)

1097 Telnet Subliminal Message option B. Miller. Apr-01 1989 (Formal: TXT=549O bytes)
(Status: UNKNOWN.)

1116 Telnet Linemodc Option. D A. Borman. Aug-01-1989. (Formal: TXf=47473 byles)
(Obsoleted by RFCI 184) (Status: PROPOSED STANDARD)
1143 The Q Method of Implementing TELNET Option Negotiation. D. J. Bernstein. Feb-
01-1990. (Format: TXT=2333I bytes) (Status: EXPERIMENTAL)

1184 Telnet Linemode Option. D. Л. Borman. Oct-01-1990. (Formal: TXT=53085 bytes)
(Obsoletes RFCI116) (Status: DRAFT STANDARD)

1205 5250 Telnet Interface. P. Chmielewski. Feb-01-1991. (Format: TXT= 27170 bytes)
(Status: INFORMATIONAL)

1372 Telnet Remote Flow Control Option. C. Hedrick, D. Borman. October 1992 (Format:
TXT=II098 bytes) (Obsoletes RFC1080) (Status: PROPOSED STANDARD)

1408 Telnet Environment Option. D. Borman, Editor January 1993. (Format: TXT=I3119
bytes) (Obsoieted by RFCI571) (Status: HISTORIC)

1409 Telnet Authentication Option. D. Borman, Editor. January 1993. (Format: TXT=)3119
bytes) (Obsoieted by RFC14I6) (Status: EXPERIMENTAL)

1411 Telnet Authentication: Kerberos Version 4 D. Borman, Editor. January 1993. (Format:
1XT=7967 bytes) (Status: EXPERIMENTAL)

1412 Telnet Authentication: SPX.K Alagappan. January 1993. (Format: TXT=6952 bvtes)
(Status: EXPERIMENTAL)

1416 Telnet Authentication Option. D. Bonnan, Editor. February 1993. (Format. TXT= 13270
bytes) (Obsoletes RFC 1409) (Status: EXPERIMENTAL)

1571 Telnet Environment Option Interoperability Issues. D. Bonnan. January 1994. (Format;
TXT=8117 bytes) (Updates RFCI408) (Status: INFORMATIONAL)

1572 Telnet Environment Option. S. Alexander. January 1994. (Format. TXT=14676 bytes)
(Status: PROPOSED STANDARD)

1576 TN3270 Current Practices. J. Penner. January 1994. (Format: TXT=24477 bytes)
(Status INFORMATIONAL)

1646 TN3270 Extensions for Luname and Printer Selection C. Graves. T Butts, and M.
Angel. July 1994. (Format: TXT=27564 bytes) (Status: INFORMATIONAL)

1647 TN3270 Enhancements. B. Kelly. July 1994. (Format: TXT=84420bytes) (Obsoieted
by RFC2355) (Status: PROPOSED STANDARD)

1921 TNVIP Protocol. J. Dujonc. March 1996. (Formal: TXT=57475 bytes) (Status:
INFORMATIONAL)

2066 TELNET CHARSET Option R Gellens. January 1997. (Format: TXT=26088 bytes)
(Status: EXPERIMENTAL)

2217 Telnet Com Pon Control Option. G. Clark. October 1997. (Format: TXT=31664 bytes)
(Status. EXPERIMENTAL)

2355 TN327O Enhancements. B. Kelly. June 1998. (Format: TXT=89394 bytes) (Obsoletes
RFCI647) (Status: DRAFT STANDARD)

Глава 12: Протокол передачи файлов (FTP)

133 File Transfer and Recovery

141 Comments on RFC 114 A File Transfer Protocol

238 Comments on DTP and FTP Proposals
250 Some Thoughts on File Transfer

269 Some Experience with File Transfer

281 Suggested Addition to File Transfer Protocol

294 The Use of "Set Data Type” Transaction in File Transfer Protocol

310 Another Look al Data and File Transfer Protocols

385 Comments on the File Transfer Protocol

412 User Fl P Documentation

413 File Transfer Protocol (TTP) Status and Further Comments

430 Comments on File Transfer Protocol

438 FTP Server-Server Interaction

448 Print Files in FTP

463 FTP Comments and Response to RFC 430

468 FTP Data Compression

478 FTP Server-Server Interaction—11

479 Use of the FTP by the NIC Journal

480 Host-dependent FTP Parameters

486 Data Transfer Revisited

487 Free File Transfer

501 Un-muddling “Free File Transfer”

505 Two Solutions to a File Transfer Access Problem

506 FTP Command Naming Problem

520 Memo to FTP Group Proposal for File Access Protocol

532 UCSD-CC Server-Fl P Facility

535 Comments on Г lie Access Protocol

571 Tenex FTP Problem

607 Comments on the File Transfer Protocol

614 Response to RFC 607: "Comments on the File Transfer Protocol”

624 Comments on the File Transfer Protocol

630 FTP Error Code Usage for More Reliable Mail Service

640 Revised FTP Reply Codes

691 One More Try on the Fl P

697 CWD Command of ГТР

737 FTP Extension: XSEN

743 FTP Extension: XRSO/XRCP

775 Directory-oriented П P Commands

949 FTP Unique-named Store Command

1415 FTP FTAM Gateway Specification. J. Mindel and R. Slaski. January 1993. (Format:
TXT~ 128261 bytes) (Status: PROPOSED STANDARD)
1440 SIFT/UFE: Sendcr-initiated/Unsoliciled File Transfer. R Troth July 1993. (Formal:
TXT=17366 bytes) (Status: EXPERIMENTAL)

1545 FTP Operations Over Big Address Records (FOOBAR) D Piscilello. November 1993.
(Format: TXT=8985 bytes) (Obsoleted by RFCI639) (Status: EXPERIMENTAL)

1579 Firewall-friendly FTP. S. Bellovin February 1994. (Formal: TXT=8806 bytes) (Status:
INFORMATIONAL)

1635 How to Use Anonymous FTP P. Deutsch. A Emtage, and A. Marine. May 1994.
(Format: TXT=27259 bytes) (Also FY10024) (Status: INFORMATIONAL)

1639 FTP Operations Over Big Address Records (FOOBAR). D. Piscilello. June 1994.
(Formal: TXT=JOO55 bytes) (Obsoletes RFCI545) (Status: EXPERIMENTAL)

2204 ODETTE Fite Transfer Protocol. D. Nash. September 1997. (Format: TXT=I5I857
bytes) (Status: INFORMATIONAL)

2228 FTP Security Extensions. M Horownz. S. Lunt October 1997. (Format TXT=58733
bytes) (Updates RFC0959) (Status: PROPOSED STANDARD)

2389 Feature Negotiation Mechanism for the File Transfer Protocol. P. Hethmon and R.
Ek. August 1998. (Format: TXT= 18536 bytes) (Also RFC0959) (Status: PROPOSED
STANDARD)

2428 FTP Extensions for IPv6 and NATs. M. Allman. S Ostermann. and C. Metz. September
1998. (Formal: TXT=I6O28 bytes) (Status. PROPOSED STANDARD)

2577 FTP Securitv Considerations. M Allman and S. Ostermann. May 1999. (Format:
TXT=17870 bytes) (Status: INFORMATIONAL)

2640 Internationalization of File Transfer Protocol

Глава 13: Упрощенный протокол электронной
почты (SMTP)

196 Revision of the Mail Box Protocol

22) Revision of the Mail Box Protocol

224 Revision of the Mail Box Protocol

278 Revision of the Mail Box Protocol

333 Proposed Experiment with a Message Switching Protocol

458 Mail Retrieval via I ГР

475 FTP and Network Mail System

491 What is ‘Free"?

498 On Mail Service to CCN

524 1 houghls on the Mail Protocol Proposed in RFC 524

539 Thoughts on the Mail Protocol Proposed in RFC 524

555 Responses to Critiques of the Proposed Mail Protocol

561 Standardized Network Mail Headers

574 Announcement of a Mail Facility at UCSB
577

644

680

706

720

724

732

744

751

753

754

757

763

771

772

780

784

785

786

788

806

821

822

841

886

915

918

934

937

974

975

976

984

987

993

Mail Priority

On the Problem of Signature Authentificalion for Network Mai)

Message Transmission Protocol

On the Junk Mail Problem

Address Specification Syntax for Network Mail

Proposed Official Standard for the Format of ARPA Network Text Messages

Standard for the Format of ARPA Network Text Messages

MARS—a Message Archiving and Retrieval Service

Survey of FTP mail and ML FL

Internet Message Protocol

Oul-of-nel Host Addresses for Mail

Suggested Solution to the Naming, Addressing, and Delivery Problem for ARPANET

Message System

Role Mailboxes

Mail Transition Plan

Mail Transfer Protocol

Mail Transfer Protocol

Mail Transfer Protocol ISl TOPS20 Implementation

Mail Transfer Protocol ISl TOPS2D File Definitions

Mail Transfer Protocol: ISl TOPS20 MTP NI MAIL Interface

Simple Mail Transfer Protocol

Proposed Federal Information Processing Standard: Specification for Message Format
for Computer-based Message Systems

Simple Mail Transfer Protocol

Standard for the Formal of ARPA Internal Text Messages

Specification for Message Format for the Computer-based Message System

Proposed Standard for Message Header Munging

Network Mail Path Service

Post Office Protocol: Version 2

Proposed Standard for Message Encapsulation

Post Office Protocol: Version 2

Mail Routing and the Domain System

UUCP Mail Interchange Format Standard

Network News Transfer Protocol

PCMAIL: A Distributed Mail System for Personal Computers

Addendum to RFC 987: (Mapping Between X.400 and RFC-822)

PCMAIL: A Distributed Mail System for Personal Computers
102ft Addendum lo RFC 9X7 (Mapping Between X 400 and RFC-822) S.E. Kille. Sep-01-
1987. (Formal: TXT=7II7 bytes) (Obsoleted by RFC1327,, RFCI495, RFC2156)
(Updates RFCQ987) (Updated by RFCI138, RFC 1148) (Status: UNKNOWN)

1047 Duplicate Messages and SMTP. C. Partridge. I cb-01 -1998. (Format. TX (=15423 bvtes)
(Obsoleted by RFC1084, RFC 1395, RFCI497, RFC1533) (Status: UNKNOWN)

1049 Content-type Header Field lor Internet Messages. M. Л Sirbu. Mar-OI-1988. (Format:
1XT=51540 byte.) (Obsoleted by RIC1O57) (Status: HISTORIC)

1056 PCMAIL: A Distributed Mail System (or Personal Computers. M. L. Lambert. Jun-
01-1988. (Formal: TXT=119I1 b tes) (Status: SIANDARD)

IOb4 Interactive Mail Access Protocol Version 2. M R. Crispin Jul-01-1988. (Format'
TXT=578I3 bvtes) (Obsoleted by RFC11 7ft RFC 1203) (Status: UNKNOWN)

1081 Post Office Protocol: Version 3. M. T. Rose. Nov-01-1988 (Format: TXT=37009 bytes)
(Obsoleted by RFCI225) (Status UNKNOWN)

1082 Post Office Protocol: Version 3. Extended Service Offerings. JM. T. Rose. Nov-01-
1988 (Formal TXT=25423 bytes) (Obsoleted by RFC 1225) (Status: UNKNOWN)

1090 SMTP on X.25. R. Ullmann. Feb-OI-1989. (Format: TXT-6141 bytes) (Status:
UNKNOWN»

1113 Privacy enhancement for Internet Electronic Mail: Part I—Message Encipherment and
Authentication Procedures. J. Linn. Aug-01-1989. (Format: TXT=89293 bvtes)
(Obsoletes RFC0989 RFCI040) (Obsoleted by RFC142I) (Status: HISTORIC)

1114 Privacy Enhancement for Internet Electronic Mail: Part 11 Certificate—based Key
management. S. T Kent, J. Linn. Aug-01-1989 (Formal: TXF =09661 bytes) (Obsoleted
by RFCI422) (Status: HISTORIC)

1115 Privacy Enhancement lor Internet electronic mail: Part ill—Algorithms, Modes, and
Identifiers. J. Linn. Aug-01 -1989. (Format: TXT=18226 bytes) (Obsoleted by
RFCI422) (Status: HISTORIC)

1137 MuPpmg Between Ful1 RFC 822 and RFC 822 with Restricted Encoding. S. Kille. Dec-
01-1989. (Format: TX f-6266 b-tea) (Upda.es RFC0976) (Status: HISTORIC)

1138 Mapping Between X.4(JO(1988)/ISO 10021 and RFC 822. S. E. Kille Dec-01-1989.
(Format: TX I =191029 bytes) (Obsoleted by RFC 1327, RFC 1495. RFC2I56) (Updates
RFC0822. RFC0987, RFC1026) (Updated bv arfcll48) (Status: EXPERIMENTAL)

1148 Mapping Between X.400 (I988)/ISO 10021 and RFC 822. S.E. Kille.

1153 Digest Message Formal F. J. Wancho. Apr-01-1990. (Formal TXT=6632 bvtes)
(Statu». EXPERIMENTAL)

1154 Encoding Header Message Field for Internet Messages. D. Robinson and R Ullmann.
Apr-01-1990. (Format: TXT-12214 bytes) (Obsoleted by RFC 1505) (Status:
EXPERIMENTAL)

1168 Intermail and Commercial Mail Relay Services. A. Wcstme. A. L DeSchon. J. Postel.
С. E. Ward. Jul-01-1990 (Format: EXT-= 149816 bvtes) (Status: INFORMATIONAL)

1176 Interactive Mail Access Protocol Version 2. M. R. Crispin Aug-0l-'990. (Format
TXT=67330 bvtes) (Obsoletes RFCI064) (Status: EXPERIMENTAL)
1203 Interactive Mail Access Protocol: Version 3. J. Rice. Feb-01-1991. (Formal.
TXT=I23325 bytes) (Obsoletes RFC1064) (Status: HISTORIC)

1204 Message Posting Protocol (MPP). S. Yeh, D. 1 ее. Feb-01-1991. (Format: TXT=I 1371
bvtes) (Status: EXPERIMENTAL)

1211 Problems With Maintenance о Г Large Mailing Lists. A. Westine, J. Postel. Mar-01-
1991. (Format: TXT96167 bytes) (Status: INFORMATIONAL)

1225 Post Office Protocol: Version 3. M. T. Rose. May-01-1991. (Formal: TXT=37340 bvtes)
(Obsoieted RFCI081) (Obsoieted by RFCI460) (Status: DRAFT STANDARD)

1327 Mapping Between X.4()()(1988)/ISO 10021 and RFC 822. S. Hardctitle-Kile. May 1992.
(Format: TXT=228598 bvtes) (Obsoletes RFC987, RFC1026. RFCI138. RFCI148)
(Obsoieted by RFC1495, RFC2156) (Updates RFC0822, rfcO822) (Status: PROPOSED
STANDARD)

1339 Remote Mail Checking Protocol. S. Domer and P Resnick. June 1992. (Format:
TXT=I31I5 bytes) (Status: EXPERIMENTAL)

1341 Multipurpose Internet Mail Extensions (MIME) Part One: Format oi'Internet Message
Bodies. N. Borenstein and N. Freed. June 1992. (Format. TXT=211117, PS=347082
bytes) (Obsoieted by RFCI521) (Status: PROPOSED STANDARD)

1342 MIME (Multipurpose Internet Mail Extensions), Part Three. K. Moore. June 1992.
(Format: EXT=15845 bytes) (Obsoieted by RFCI522) (Status INFORMA! 1ONAL)

1343 A User Agent Configuration Mechanism fm Multimedia Mail Format Information.
N. Borenstein. June 1992. (Formal: 1XT=29295, PS=59978 bytes) (Status:
INFORMAIIONAL)

1344 Implications ol MIME for Internet Gateways. N. Borenstein. June 1992. (Format:
TXT=25872, PS=51812 bytes) (Status: INI ORMATIONAL)

1357 A Format for E-mailing Bibliographic Records. D Cohen. July 1992. (Format:
TXT=25O2I bytes) (Obsoieted by RFC1807) (Status: INFORMATIONAL)

1405 Mapping Between X.400 (1984/1988) and Mail- II (DECnet mail) C. Allocchio.
January 1993. (Format' TXT=33885 bytes) (Obsoieted by RFC2162) (Status:
EXPERIMENTAL)

1425 SMTP Service Extensions. J. Klensin. WG Chair, N. Freed, Editor. M. Rose, E.
Stefferud & D. Crocker. February 1993. (Format: TXT=2O932 bytes) (Obsoieted by
RFC1651) (Status: PROPOSED STANDARD)

1426 SMTP Service Extension for 8bii-MlMEtransport. J. klenisin. W. G Chair; N. Freed,
Editor; M Rose; E. Stefferud; and D. Crocker. February 1993. (I orniat: ТХГ=1161
bytes) (Obsoieted by RFC 1652) (Status: PROPOSED STANDARD)

1427 SMTP Service Extension lor Message Size Declaration. J. Klensin; W. G. Chair; N.
f reed. Editor; K. Moore. February 1993. (Format: TXE=17856 bytes) (Obsoieted by
RI CI653) (Status: PROPOSED STANDARD)

1428 Transition of Internet Mail from Just-Send-8 to 8-bil SMTP/MIML. G. Vaudreuil
February 1993. (Formal: TXT=I2O64 bytes)(Status: INFORMATIONAL)

1461) Post Office Protocol, Version 3. M. Rose. June 1993. (Formal: TXT=38827 bytes)
(Obsoletes RFCI225) (Obsoieted by RFC 1725)
1494 Equivalences Between <988 \ 400 and RFC-822 Message Bodies. H. Alvestrandtfc S.
Thompson. August 1493. (| orni.it JXT=37273 bvtes) (Status: PROPOSED
STANDARD)

1495 Mapping Between X.4D0 and RPC-822 Message Bodies. H. Al vestrand, S. Kille, R
Miles, M. Rose, and S Thompson August 1993. (Format: TXT=20071 bytes)
(Obsoletes RFC987 RFC987, RFC1026, RFCI 138, RFCI 148, RFCI327) (Obsoleted
by RFC2156) (Status: PROPOSED STANDARD)

1496 Rules Гог Downgrading Messages from X 400/88 to X 4DU/84 when MIME Content
Tipesare Present in the Messages. H. Alvcslrand, J. Roniaguera, and K. Jordan. August
1993 (Format: TXT=8411 bytes) (Status PROPOSED STANDARD)

1502 X.400 Use of Extended Character Sets. H. Alvestrand. August 1993. (Format:
TXT=279?6 bvtes) (Status: PROPOSED STANDARD)

1505 Encoding Header Message Field lor Internet Messages. A. Costanzo, D. Robinson,
and R. Ullmann. August 1993. (Formal: 1ХГ=63796 bytes) (Obsoletes RFCI 154)
(Status: EXPERIMENTAL)

1506 A Tutorial on Gale.vaving Between X.400 and internet Mail J. Houttuin. September
199’ (Format: TXT=.8555U bytes) (Status: INFORMATIONAL)

1521 Multipurpose Internet Mail Extensions (MIME) Pan One: Mechanisms for Specifying
and Describing the Format of Internet Message Bodies N. Borenstein and N. Freed.
September 1993. (Format: TXT=187424, PS=393670 bytes) (Obsoletes RFCI34I)
lObsoletcd bv RFC2045. RFC2046. RIC2047. RI C2048. RFC2049. BCP0013)
(Updated by ИГС1590) (Status: DRAFT STANDARD)

1522 MIME ^Multipurpose Internet Mail Extensions). Part Two: Message Header
Extensions for Non ASCII Text. K. Moore. September 1993. (Format: TXT=22502
bvtes) (Obsoletes RFCI’42) (Obsoleted by RFC2045. RFC2046. RFC2047 RFC2018,
RFC2(>49, BCP0013) (Status: DRAFT STANDARD)

1523 The Text-enriched MIME Content Type. N. Borenstein. September 1Q93. (Format
TXT=32b91 bvtes) (Obsoleted by RFC1563. RFC1896) (Status: INFORMATIONAL)

1524 A User Agent Configuration Mechanism for Multimedia Mail Format Information
N. Borenstein. September 1991 (Format: TXT=26464 bytes) (Status: INFORMA-
TIONAL)

1544 rhe Content-MDS Header Field M Rose. November 1993. (Formal: TXF=64?B bytes)
(Obsoleted by RFCI864) (Status: PROPOSED STANDARD)

1556 Handling of Bidirectional Texts in MIME H. Nussbacher and Y Bourvine. December
1993 (Formal: TXT=9273 bvtes) (Status: INFORMATIONAL)

1563 The Text-enriched MIME Content Type N Borenstein. January 1994. (Format
TXT=329I3, PS=73543 bytes) (Obsoletes RFC 1523) (Obsoleted by RFC 1896) (Status:
INFORMATIONAL)

1590 Media Type Registration Procedure J. Postel. March 1994. (f ormal: TXT=13044 bvtes)
(Obsoleted by RTC2045, RFC2046, RFC2047, RFC2048. RIC2649, BCP0013)
(Updates RFC 1521) (Status INFORMATIONAL)

1615 Migrating Form X 400(84)10 X.400(88). .1. Houttuin and J. Craigie. May 1994 (Format:
TXT=39o93 bytes) (Status: INI ORMATIONAL)
1610 X.400(I98b)for the Academic and Research Community in Europe RAREWG-MSG
Task Force 88. E. Fluizei and J. Romagueta, Editors. May 1994 (Format: TXT=IO7432
bytes) (Status: INFORMATIONAL)

1641 Using Unicode With MIME. D. Goldsmith and M. Davis. July 1994. (Format:
TXT=I 1258, PS=204M bytes) (Status: EXPERIMENTAL)

1642 UTF-7 A Mail- safe Transformation Format of Unicode. D. Goldsmith and M. Davis.
Juiv 1994 (Format: TXT=27770 PS=50907 bvies) (Obsoleted by RFC2152) (Status:
EXPERIMENTAL)

1648 Postmaster Convention for X.4U0 Operations. A Cargille. July 1994. (Format:
TXT=876I bytes) (Status: PROPOSED STANDARD)

1649 Operational Requirements for X.400 Management Domain in the GO-MHS
Community. ₽ H .gens and A. Hansen. July 1994. (Formic ГХТ=23138 bytes) (Status:
INFORMATIONAL)

1651 SMTP Service Extensions. Klensin, N Freed. M. Rose. E. StelTerid, and D. Crocker.
July 1994. (Formal: TXT=22I53 bytes) (Obsoletes RFC1425) (Obsoleted by RFC1869,
STD0010) (Status: DRAFT STANDARD)

1652 SMTP Service Extension Гог 8-bil MIME Transport. Klensin, N Freed, M Rose, E.
Slefferud. and D. Crocker. July 1994. (Format: TXT=11842 bytes) (Obsoletes
RFCI426) (Status: DRAFT STANDARD)

1653 SM ГР Service Extension for Message Size Declaration. J. KJenisn, N. Freed, and K.
Moore. Ji.lv 1994. (Formal TXT=17883 bytes) (Obsoletes RFC1427) (Obsoleted by
RFC1870, SI D0011) (Also SID00I I) (Status: DRAFT STANDARD)

1685 Writing X 400 O/R Names. H. Al vest rand. August 1994. (Formal: TXT=21242 bytes)
(Also RTR00I2) (Statu.1 INFORMATIONAL)

1711 Classifications in E-mail Routing. J. Houtluin. October 1994. (Formal TXT=47584
bytes) (Status: INFORMATIONAL)

1725 Post Office Protocol, Vei sion 3 J. Meyers and M. Rose November 1994. (Format:
1XT=35u58 bytes) (Obsoletes RFC 1460) (Obsoleted bv RFC1939, STDOO53) (Status:
DRAFT STANDARD)

1730 Internet Message Access Protocol, Version 4. M. Crispin. December 1994. (Format:
TXT=15666O bytes) (Obsoleted by RFC2060. RFC206I) (Status: PROPOSED
STANDARD)

1731 1MAP4 Authentication Mechanisms. J Mvers. December 1994. (Format: TXT =11433
bytes) (Status- PROPOSED STANDARD)

1732 1MAP4 COMPATABIL1TY WITH IMPAP2 AND IMPA2BIS. M. Crispin. December
1994 (Format: TXT -9276 bvtes) (Status: INFORMATIONAL)

1733 DISTRIBUTED ELECTRONIC MAIL MODELS IN 1МАГ4 M. Crispin December
1994 (Formal TXT =6205 bytes) (Status: INFORMATIONAL)

1734 POP3 Authentication command J. Mvers. December (994 (Format: TXT=8499 bytes)
(Status: PROPOSED STANDARD)
1740 MIME Encapsulation of Macintosh Files—MacMIME. P. Falstrom, D Crocker, and
E. Fair. December 1994. (Format: TXT=3I297 bytes) (Status: PROPOSED
STANDARD)

1741 MIME Content-type for BinHex Encoded Files. P. Fallstrom, D. Crocker, and E. Fair.
December 1994. (Format: TXT=!OI55 bytes) (Status: INFORMATIONAL)

1767 MIME Encapsulation of EDI Objects. D. Crocker. March 1995. (Formal: TXT=15293
bytes) (Status: PROPOSED STANDARD)

1806 Communicating Presentation Information in Internet Messages: The Content-
Disposition Header R Troost and S. Domer June 1995. (Format: TXT=15548 bytes)

1807 A Formal for Bibliographic Records. R. Lasher and D. Cohen. June 1995. (Formal:
TXT=29417 bytes) (Obsoletes RFCI357) (Status: INFORMATIONAL)

1820 Multimedia E-mail (MIME) User Agent Checklist. E Huizer. August 1995. (Format:
TXT=14672 bytes) (Obsoieted by RFCI844) (Status: INFORMATIONAL)

1830 SMTP Service Extensions for Transmission of Large and Binary MIME Messages.
G. Vaudreuil. August 1995. (Format: TXT= 16555 bytes) (Status: EXPERIMENTAL)

1838 Use of an X.500/LDAP Directory to Support Mapping Between X.400 and RFC 822
Addresses. S. Kille. August 1995. (Format. TXT=I22)6 bytes) (Obsoieted by RFC2164)
(Status: EXPERIMENTAL)

1844 Multimedia E-mail (MIME) User Agent Checklist. E. Huizer. August 1995. (Format:
TXT=15072 bytes) (Obsoletes RFC182O) (Status: INFORMATIONAL)

1845 SMTP Service Extension for Checkpoint/Restart. D. Crocker. N. Freed and A. Cargille.
September 1995. (Format: TXT=15399 bvtes) (Status: EXPERIMENTAL)

1846 SMTP 521 Reply Code A. Durand and F. Dupont. September 1995. (Format:
TXT=6558 bytes) (Status: EXPERIMENTAL)

1847 Security Multipart* for MIME: Mullipart/Signcd and Multipart/Encrvpted. J. Galvin,
S. Murphy. S. Crocker, and N Freed. October 1995. (Format: TXT-23679 bytes)
(Status: PROPOSED STANDARD)

1848 MIME Objects Security Services. S. Crocker. N. Freed, J. Galvin, and S. Murphy.
October 1995. (Format: TXT=95010 bytes) (Status. PROPOSED STANDARD)

1854 SMTP Service Extension for Command Pipelining. N Freed. October 1995. (Format:
TXT-14097 bytes) (Obsoieted by RFC2197) (Status: PROPOSED STANDARD)

1864 The Content-MD5 Header Field. J. Mvers and M. Rose. October 1995. (Format:
TXT=7216 bytes)

1869 SMTP Service Extensions. J. Klensin, N. Freed, M. Rose, E. Stefferud, and D. Crocker.
November 1995. (Format: TXT=23299 bytes) (Obsoieted by RFC165I) (Also
STD0010) (Status: STANDARD)

1870 SMTP Service Extension for Message Size Declaration J.Klensin, N. Freed, and K.
Moore. November 1995. (Formal: TXT=18226 bytes) (Obsoletes RFC1653) (Also
STD00I0) (Status: STANDARD)

1872 The MIME Multipan/Related Content-type. E. Levinson. December 1995. (Format:
TXT 15565 bytes) (Obsoieted bv RTC2112) (Status: EXPERIMENTAL)
1873 Message/Extemal-Bo lv Contcnl-ID Access Type. E. Levinson December 1995.
(Formal: TXT=5878 bytes) (Status: I X IT KI MENTAL)

1891 SMTP Service Extension for Delivery Status Notifications. K. Moore. January 1996.
(Format: TXT=65I92 bytes) (Status. PROPOS1 D STANDARD)

1892 The Multipan/Repon Content-type for the Reporting of Mail System Administrative
Messages. G. Vaudreuil. January 1996. (Format: TXT=7800 bvtes) (Status:
PROPOSED STANDARD)

1893 Enhanced Mail System Status Codes. G. Vaudreuil. January 1996. (Format. TXT=28218
bvtes) (Status: PROPOSED STANDARD)

1894 An Extensible Message Format for Delivery Status Notifications. K. Moore and G.
Vaudreuil. January 1996. (Foimat: TXT=77462 bytes) (Stilus: PROPOSED
STANDARD)

1895 The Apphcation/CALS-1840 Content-type. E. Levinson. February 1996. (Format:
TXT =10576 bytes) (Status INFORMATIONAL)

1896 The text/enriched MIME Content-type. P Resnick & A. Walker. February 1996.
(Format: TXT=45926, PS—81217 bytes) (Obsoletes RFC1523, RFC1563) (Status:
INFORMATIONAL)

1957 Sonu Observations on Implementations of the Post Office Protocol (POP3). R. Nelson
June 1996 (Format. TXT=2325 bytes) (Updates RFC1939) (Status:
INFORMATIONAL)

1985 SMTP Service Extension for Remote Message Queue Starting. J. DeWinter. August
1996 (Format: TXT=I48I5 bytes) (Status: PROPOSED STANDARD)

2015 MIME Security with Pretty Good Privacy (PGP). M. Elkins. October 1996. (Format:
TXT= 14223 bytes) (Status: PROPOSED STANDARD)

2016 Uniform Resource Agents (URAs). L. Daigle, P. Deutsch. В Heelan, C. Alpaugh,
M Maclachlan. October 1996. (Format: TXT=38355 bytes) (St itus:
EXPERIMENTAL)

2033 Local Mail Transfer Protocol. J. Myers October 1996. (Format: TXT=147II bytes)
(Status: INFORMATIONAL)

2034 SMTP Service Extension for Returning Enhanced Error Codes N. Freed. October 1996.
(Format: TXT= 10460 bytes) (Status: PROPOSED STANDARD)

2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message
Bodies. N.Freed & N. Borenstein. November 1996. (Format: TXT=72932 bytes)
(Obsoletes RFCI521, RFCI522, RFC15906) (Updated by RFC2I84. RFC2231)
(Status: DRAFT STANDARD)

2046 Multipurpose Internet Mail Extensions (MIME), Part Two: Media Types. N Freed
and N. Borenstein. November 1996. (Format: TXT=l05854 bytes) (Obsoletes
RFC 1521, RFCI522, RFC1590) (Status: DRAFT STANDARD)

2047 MIML (Multipurpose Internet Mail Extensions), Part Three: Message Header
Extensions for Non-ASCII Text. K. Moore. November 1996. (Formal: TXT 3326T2
bvtes) (Obsoletes RFC1521, RFCI522, RFCI590) (Updated by RFC2I84, RFC223I)
(Status: DRAFT STANDARD)
2048 Multipurpose Internet Mail Extensions (MIME). Part Four; Registration Procedures.
N.Freed. J. Klensin. and J. Postel November 1996. (Format: EXT=45033 bytes)
(Obsoletes RFC1521. RFCI522, RFCI590) (Also BCP0013) (Status. BEST
CURRENT PRACTICE)

2049 Multipurpose Internet Mail Extensions (MIME). Part Five: Conformance Criteria and
Examples. N. Freed & N. Borenstein. November 1996. (Format: TXT=51207 bytes)
(Obsoletes RFCI52I. RFC1522. RFCI390) (Status: DRAFT STANDARD)

2060 Internet Message Access Protocol. Version 4revl. M. Crispin. December 1996. (Format:
TXT=1665I3 bytes) (Obsoletes RFCI730) (Status: PROPOSED STANDARD)

2061 1MPA4 Compatibility With IMAP2BIS. M. Crispin. December 1996. (Format:
TXT=5867 bytes) (Obsoletes RFC1730) (Status. INFORMATIONAL)

2062 Internet Message Access Protocol—Obsolete Syntax. M Crispin. December 1996.
(Formal TXT=14222 bytes) (Status PROPOSED STANDARD)

2076 Common Internet Message Headers. J.Palme. February 1997. (Format TXT=47639
bytes) (Status: INFORMATIONAL)

2077 The Model Primary Content-type for Multipurpose Internet Mail Extensions. S.
Nelson. C. Parks. Mitra. January 1997. (Format. TXT=30158 bytes) (Status:
PROPOSED STANDARD)

2086 1MAP4 ACL Extension J Myers. January 1997. (Format: TXT=I3925 bytes) (Status:
PROPOSED STANDARD)

2087 IMAP4 QUOTA Extension. J. Myers, January 1997. (Format: TXT—8524 bytes) (Status:
PROPOSED STANDARD)

2088 IMAP4 Non-synchronizing literals. J Myers January 1997. (Format: TXT=4052 bytes)
(Status: PROPOSED STANDARD)

2095 IMAP/POP Authorize Extension for Simple Challcnge/Response. J Klensin, R Catoe,
and P. Krumvicde. January 1997. (Format: TXT-10446 bytes) (Obsoleted by RFC2195)
(Status: PROPOSED STANDARD)

2110 MIME Encapsulation of Aggregate Documents Such As HTML (MHTML). J. Palme
and A Hopmann. March 1997. (Formal: TXT=41961 bytes) (Status: PROPOSED
STANDARD)

21)2 The MIME Mulliparl/Related Content-type. E. Levinson. February 1997. (Formal:
TXT=l7052 bytes) (Obsoletes RFC1872) (Obsoleted bv RFC2387) (Status:
PROPOSED STANDARD)

2142 Mailbox Names for Common Services, Roles, and Functions.D. Crocker. May 1997.
(Format: TXT=12195 bytes) (Status: PROPOSED STANDARD)

2152 UTF-7 A Mail-Safe Transformation Format of Unicode. D. Goldsmith. M. Davis.
May 1997. (Format’ TXT=28O65 bytes) (Obsoletes RFC1642) (Status:
INFORMATIONAL)

2156 MIXER (Mime Internet X.4D0 Enhanced Relay): Mapping between X.400 and RFC
822/MIME. S. Kille. January 1998. (Format TXT=280385 bytes) (Obsoletes RFCO987,
RFCI026, RFCII38. RFC! 148, RFC1327. RFCI495) (Updates RFC0822) (Status:
PROPOSED STANDARDS)
2157 Mapping between Х.400 and RFC-822/MIME Message Bodies. H Alveslrand Januan
1998. (Format: TXT-92554 bytes) (Status: PROPOSED STANDARD)

2158 X.4()0 Image Body Parts. H. Alvestrand. January 1998. (Format: TXT=5547 bytes)
(Status: PROPOSED STANDARD)

2160 Carrying PostScript in X.400 and MIME H. Alvestrand. January 1998. (Format:
TXT=7059 bytes) (Status: PROPOSED STANDARD)

2161 A MIME Body Part Гог ODA H AlvestranJ January 1998. (Format: TXT=8009 bvtes)
(Status: EXPERIMENTAL)

2162 MaXIM-l I Mapping Between X.400/lnternel Mail and Mail-11 Mail. C. Allocchio.
January 1998. (Format: TXT-58553 bytes) (Obsoletes RFC1405) (Status.
EXPERIMENTAL)

2163 Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping
(MCGAM). C Allocchio. January 1998. (Format: TXT—58789 bytes) (Obsoletes
RFC 1664) (Status. PROPOSED STANDARD)

2164 Use of the X.5t)0/LDAP Directory to Support MIXER Address M ipping. S. Kille.
January 1998. (Format: TXT-16701 bytes) (Obsoletes RFC1838) (Status: PROPOSI D
STANDARD)

2177 IMAP4 IDLE command. B. Leiba June 1997. (Formal TXT=6770 bytes) (Status*
PROPOSED STANDARD)

2180 IMAP4 Malli-accessed Mailbox Practice M Gahms. July 1997. (Format: TXT—24750
bytes) (Status: INFORMATIONAL)

2184 MIME Parameter Value and Encoded Word Extensions. Character Sets, Languages,
and Continuations. N. Freed and К Moore August 1997. (Format:TXT=17635 bytes)
(Obsoletes RFC2184) (Obsoieted by RFC2I84 RFC223I) (Updates RFC2045,
RFC2047. RTC2I83) (Status: PROPOSED STANDARD)

2192 IMAP URL Scheme C Newman. September 1997. (Format: TXT=31426 bytes)
(Status; PROPOSED STANDARD)

2193 IMAP4 Mailbox Referrals. M. Gahms. September 1997 (Formal TXT= 16248 bytes)
(Status PROPOSED STANDARD)

2195 iM AP./POP Authorize Extension for Simple Chailenge/Response J Klensin R Catoe,
P Krumviede. September 1997. (Form it; TXT=1U468 bytes) (Obsoletes RFC2095)
(Status: PROPOSED STANDARD)

2197 SMTP Service Extension for Command Pipelining. N. Freed. September 1997. (Format:
TXT-1500J bytes) (Obsoletes RFC 1854) (Status: DRAFT STANDARD)

2220 The Application/MARC Content-type. R. Guenther. October 1997. (Format:
TXT-7025 bytes) (Status INFORMATIONAL)

2221 IMAP4 Login Referrals. M. Gahms October 1997. (Formal: ГХТ—9251 bytes) (Status:
PROPOSED STANDARD)

2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages,
and Continuations N Freed and K. Moore. November 1997. (Format: TXT-19280
bxtes) (Obsoletes RFC2184' (Updates RFC2045 RTC2O4 7 RFC2183) (Status:
PROPOSED STANDARD)
2298 An Extensible Message Fonnat Гог Message Disposition Notifications. R Fajman
March 1998. (Format- TXT-62059 bytes) (Status: PROPOSED STANDARD)

2302 Tag Image Fjlc Fonnat (TIFD—Image/tiff MIME Sub-type Registration G. Parsons,
J. Railed}, S Zilles. March 1998 (Format: 1 XT= 14375 bvtes) (Status: PROPOSED
STANDARD)

2311 S/MIME Version 2 Message Specification. S. Dusse, P. Hoffman, B. Ramsdell, L.
Lundblade. L. Repka. March 1998. (Format: TXT=7091 bytes) (Status:
INFORMATIONAL)

2312 S/MIME Version 2 Certification Handling. S. Dusse, P. Hofffman, B. Ramsdell, and
J. Weinstein. March 1998. (Formal: TXT-39829 bvtes)

2318 The Text/CSS Media Type. H Lie, B. Bos, and C. Lilley. March 1998. (Format:
TXT-7819 bytes) (Status: INFORMATIONAL)

2342 IMAP4 Namespace. M. Gahms and C. Newman. May 1998. (Format: TXT=I9489
bytes) (Status; PROPOSED STANDARD)

2359 IMAP4 UIDPLUS Extension. J. Myers. June 1998. (Format ГХТ—10862 bytes)
(Status: PROPOSED STANDARD)

2384 POP URL Scheme. R. Gellens August 1998 Format: TXT=I3649 bytes) (Status:
PROPOSED STANDARD)

2387 The MIME Multipart/Rclated Content-type E. Levinson. August 1998. (Format.
TXT-18864 bytes) (Obsoletes RFC2II2) (Status: PROPOSED STANDARD)

2424 ContenlDuration MIME Header Definition. G. Vaudreuil and G Parsons. September
1998. (Format: TXT-7116 bytes) (Status: PROPOSED STANDARD)

2425 A MIME Content-type for Directory Information. T. Howes, M. Smith, and F.
Dawson September 1998 (Format: TXT=64478 bytes) (Status: PROPOSED
STANDARD)

2426 vCard MIMI Directory Profile. F. Dawson and T. Howes. September 1998. (Format:
TXT-74746 bytes) (Status: PROPOSED STANDARD)

2442 Hie Batch SMTP Media Type. N. Freed, D. Newman, H. Belissen, and M Hoy.
November 1998. (Format: TXT=18384 bytes) (Status: INFORMATIONAL)

2449 POP3 Extension Mechanism R Gellcns, C. Newman, and L. Lundblade. November
1998. (Format: TXT=36017 bytes) (Updates RFC1939) (Status: PROPOSED
STANDARD)

2476 Message Submission. R. Gellens and H. Klensin. Decembei 1998. (Forma' TXT—30050
bytes) (Status PROPOSED STANDARD)

2480 Gateways and MIME Security Multiparts N. Freed. January 1999 (Format:
TXT-11751 bytes) (Status PROPOSED STANDARD)

2487 SMTP Service Extension for Secure SMTP Over Tl S P. Hoffman. January 1999.
(format: TXT-15120 bytes) (Status: PROPOSED STANDARD)

2503 MIME Types for Use with the ISO ILL Protocol. R. Moulton and M. Needleman
February 1999. (Format: TXT—9078 bvtes) (Status: INFORMATIONAL)

25U5 Anti-Spam Recommendations for SMTP MTAs. G.Lindberg. February 1999 (Format.
TXT-53597 bytes) (Also BCP0030) (Status: BEST CURRENT PRACTICES)
2524 Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version
1.3. M. Banan. February 1999. (Format: TXT=I53I71 bytes) (Status:
INFORMATIONAL)

2554 SMTP Service Extension for Authentication J. Meyers. March 1999. (Format:
TXT= 20534 bytes) (Status: PROPOSED STANDARD)

2557 MIME Encapsulation of Aggregate Documents Such As HTML (M HTML). J. Palme,
A Hopmann, and N. Shelness March 1999. (Formal; TXT=61854 bytes) (Obsoletes
RFC2110) (Status: PROPOSED STANDARD)

2586 The Audio/L16 MIME

2595 Using TLS with IMAP, POP3, and АСЛР

2632 S/MIME Version 3 Certificate Handling

2633 S/MIME Version 3 Message Specification

2634 Enhanced Security Service for S/MIME

2645 On-demand Mail Relay (ODMR) SMTP With Dynamic IP Addresses

2646 The Text/Plain Formal Parameter

2683 1MAP4 Implementation Recommendations

Глава 14: Разрешение имен

752 Universal Host Table

756 NIC Name Server—a Datagram-based information Utility

799 Internet Name Domains

811 Hostname Server

819 Domain Naming Convention for Internet User Applications

830 Distributed System for Internet Name Service

881 Domain Names Plan and Schedule

882 Domain Names’ Concepts and Facilities

883 Domain Names’ Implementation Specification

897 Domain Name System Implementation Schedule—Revised

920 Domain Requirements

921 Domain Name System Implementation Schedule—Revised

953 Hostname Server

973 Domain System Changes and Observations

1001 ProtocolSlandard for a NetBIOS Service on a TCP/UDP Transport: Concepts and
Methods. NetBIOS Working Group Defense Advanced Research Projects Agency,
Internet Activities Board, End-to-End Services Task Force. Mar-01-1987. (Format:
TXT=I58437 bytes) (Status: STANDARD)

1002 Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Detailed
Specifications. NetBIOS Working Group. Defense Advanced Research Projects
Agency, Internet Activities Board, End-to-End Services Task Force. Mar-01-1987.
(Format: TXT= 170262 bytes) (Status: STANDARD)
1031

1032

1033

1034

1035

1036

1037

1038

1101

1183

1348

1383

1386

1394

1464

1480

M1LNET Name Domain Transition W. D. Lazear. Nov-0i-1987 (Format:
TXT=20137 bytes) (Status: UNKNOWN)

Domain Administrators Guide. M. K. Stahl. Nov-01-1987. (Formal: TXT=29454 bvtes)
(Status: UNKNOWN)

Domain Administrators Operations Guide. M Lotlor. Nov-01-1987. (Format:
TXT=37263 bvtes) (Status: UNKNOWN)

Domain Names—Concepts and Facilities. P. V. Mockapetris. Nov-01-1987. (Formal:
TXT=l29180 bytes) (Obsoletes RFC0973. RFCO882, RFC0883) (Obsoieted by
RFCI065. RFC23O8) (Updated by RFCI101, RFC1I83, RFCI348. RFCI876.
RFC1982, RFC2065. RFC2I8I. RFC23O8) (Status: STANDARD)

Domain Administrators Guide. M. K. Stahl. Nov-01-1987. (Format: TXT=29454
bytes) (Status: UNKNOWN)

Domain Administrators Guide. M. Loltor. Nov-01-1987. (Гbrmat: TXT=37263 bytes)
(Status: UNKNOWN)

Domain Names—Concepts and Facilities. P. V. Mockapeiris. Nov-01-1987. (Format:
TXT= 129180 bytes) (Obsoletes RFC0973, RFC0882. RFCO883) (Obsoieted by
RFC1O65, RFC2308) (Updated by RFCI10I, RFCU83, RFC1348, RFCI876.
RFCI982, RFC1995, RFC1996, RFC2065, RFC2181, RFC2I36. RFC2137, RFC2308)
(Status: STANDARD)

Domain Names—Implementation and Spec i Heat ion. P. V Mockapctris. Nov-01-1987.
(Formal: TXT=125626 bytes) tObsoleles RFC0973. RFCO882, RFCO883) (Updated
by RFCII01. RFCH83, RFCI348, RFCI876. RFC1982, RFC1995. RFC1996,
RFC2O65, RFC2181, RFC2I36. RFC2I37, RFC2308) (Status: STANDARD)

DNS Encoding of Network Namesand Other Types P. V. Mockapetris. Apr-01-1989.
(Format: TXT=28677 bytes) (Updates RFCI034. RFCIO35) (Status. UNKNOWN)
New DNS RR Definitions. C. F Everhart, L. A. Mamakos. R. Ullmann, and P. V.
Mockapetris. Oct-01-1990. (Format: TXT=23788 bytes) (Updates RFC 1034.RFC 1035)
(Status: EXPERIMENTAL)

DNS NSAP Resource Records. B. Manning. July 1992 (Format TXT=6871 bytes)
(Obsoieted by RFC1637) (Updates RFC1034, RFCI035) (Updated by RFC1637)
(Status: EXPERIMENTAL)

An Experiment in DNS-based IP Routing. C Huitema. December 1992 (Format:
TXT=32680 bytes) (Status: EXPERIMENTAL)

The US Domain. A. Cooper and J. Postel. December 1492. (Format; TXT=62310 bytes)
(Obsoieted by RFC1480) (Status: INFORMATIONAL)

Relationship of Telex Answerback Codes to Internet Domains. P. Robinson January
1993. (Format: TXT=43776 bvtes) (Status: INFORMATIONAL)

Using the Domain Name System to Store Arbitrary Siring Attributes R. Rosenbaum.
May 1993. (Format: TXT=7953 bvtes) (Status' EXPERIMENTAL)

The US Domain. A. Cooper and J. Postel. June 1993. (Format: TXT=10()556 bytes)
(Obsoletes RFCI386) (Status: INFORMATIONAL)
1535 A Security Problem and Proposed Correction With Widely Deployed DNS Software.
E. Gavron October 1993. (Formal TXT=9722 bytes) (Status: INFORMATIONAL)

1536 Common DNS Implementation Errors and Suggested Fixes. A.Kumar, J. Postel, C.
Neuman, P Danzig, and S. Miller. October 1993 (Format: TXT=25476 bvtes) (Status:
INFORMATIONAL)

1537 Common DNS Operational and Configuration Errors. P Bccrtema. October 1991.
(Iormat TXT=19825 bytes) (Obsoleted by RFCI912) (Status. INFORMATIONAL)

1591 Domain Name System Structure and Delegation J Postel. March 1994 (Format:
TXT=I6481 bytes) (Status: INFORMATIONAL)

1637 DNSAP Resource Records. В Manning and R. Colella June 1994. (Format:
TXT=2I768 bytes) (Obsoletes RFCI348) (Obsoleted by RFC1706) (Updates RFC1348)
(Status: EXPERIMENTAL)

170b DNS NiAP Resource Records. B. Manning and R. Colella October 1994. (Fonnat:
TXT=19721 bvtes) (Obsoletes RFC 1637) (Status: INFORMATIONAL)

1712 DNS Encoding of Graphical Location. C. Farrell, M. Schulze. S. Pleitner, and D.
Baldom. November 1994 (Format: TXT=I3237)

1713 Tools for DNS Debugging. A. Romao. Novenibei 1994. (Format: TXT=33500 bvtes)
(Also FYUOO27) (StatusJNFORMATIONAL)

1794 DNS Support for Luad Balancing T. Brisco. April 1995. (Fonnat: TXT-15494 bytes)
(Status: INFORMATIONAL)

1876 A Means for Expressing Location Information in the Domain Name System. C Davis,
P Vixie, T. Goodwin, and I. Dickinson. January' 1996. (Format TXT-29631 bvtes)
(Updates RFC 1034, RFCN?35) (Status: EXPERIMENTAL)

1912 Common DNS Operational and Configuration Errors. D. Barr. February 1996 (Formal
TXT=38252 bytes) (Obsoletes RFCI537) (Status: INFORMATIONAL)

1982 Serial Number Arithmatic. R. Elz and R Bush. August 1996 (Format TCT=14440
bvtes) (Updates RFC1O34, RFCI035) (Status. PROPOSED STANDARD)

1995 Incremental Zone Transfer in DNS. M. Ohia. August 1996 (Format: TXT=1681i) bytes)
(Updates RI CI035) (Status: PROPOSED STANDARD)

1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY). P. Vixie.
August 1996. (Format: TXT=I5247 bytes) (Updates RFC1G35) (Status: PROPOSED
STANDARD)

2010 Operational Criteria for Root Name Servers. В Manning and P. Vixie. October 1996.
(Format: TXT=14870 bytes) (Status: INFORMATIONAL)

2052 A DNS RR for Specifying the Loc ation of Services (DNS SRV) A Gulbrandensen,
P. Vixie. October 1996. (Format: TXTI9257 bytes) (Status: EXPERIMENTAL)

2u65 Domain Name System Security Extensions D. Lastlake. 3rd Edition. C. Kaufman.
January 1997 (Format: TXT=97718 bytes) (Updates RFC1034, RFCIG35) iSt.itus-
PROPOSED STANDARD)

2136 Dynamic Updates in the Domain Name System (DNS UPDATE). P Vixie. Ed.. S.
Thomson, Y. Rekhter, J. Botina April 1097. (Format TXT=*36354 bytes) (Updates
RFCI035) (Status PROPOSED STANDARD)
2137 Secure Domain Name System Dynamic Update. D. Eastlake. April 1997. (Format’
TXT 24824 bvtes) (Updates RFC1O35) (Status: PROPOSED STANDARD)

2181 C larification of DNS Specification. R. Elz arid R. Bush. Julv 1997. (Format:
TXT=36989 bvtes) (Updates RFCI034. rfclO35, RFCII23) (Status: PROPOSED
STANDARD)

2182 Selection and Operation for Secondary DNS Servers. R. Elz, R Bush, S. Bradner,
and M. Patton. July 1997. (Format: TXT=2745b bytes) (Also BCPU016) (Status: BESE
CURRENT PRACTICE)

2219 Use of DNS Aliases for Network Services. M Hamilton and R. Wright. October 1997.
(Format: TXT=17858 bytes) (Also BCP00I7) (Status: BEST CURRENT PRACTICE)

2230 Key Exchange Delegation Record for the DNS. R. Atkinson. October 1997. (Formal.
TXT=25563 bytes) (Status: INFORMATIONAL)

2240 A Legal Basis for Domain Name Allocation. O. Vaughan. November 1997. (Formal:
TXT=13602 bytes) (-Obsoleted by RFC2352) (Status: INFORMATIONAL)

2308 Negative Caching of DNS Queries (DNS NCACHF). M. Andrews. March 1998.
(Format: TXT=4I428 bvtes) (Obsoletes RFCI034) (Updates RFC1034 RFC1035)
(Status: PROPOSED STANDARD)

2317 Classless IN-ADDR.ARPA Delegation H. Eidnes, C. de Ciroot, and P Vixic. March
1998 (format: TXT=I7744 bytes) (Also BCP0020) (Status: BEST CURRENT
PRACTICE)

2517 Building Directories from DNS: Experiences from WWWSeeker. R. Moats and R.
Huber February 1999. (Foimat: TXT=14001 bytes) (Status: INFORMATIONAL)

2535 Domain Name System Security Extensions. D. Eastlake. March 1999. (Format:
TXT=110958 bytes) (Updates RFC2181. RFCI035. RFC1034) (Status; PROPOSED
STANDARD)

2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS) D Eastlake.
March 1999. (Formal TXT=21049 bytes) (Status. PROPOSED STANDARD)

2540 Detached Domain Name System (DNS) Information. D. Eastlake. March 1999.
(Format: TXT=12546 bytes) (Status: EXPERIMENTAL)

2541 DNS Security Operational Considerations. D. Eastlake March 1999. (Format:
TXT=I4498 bv<es) (Status: INFORMATIONAL)

2606 Reserved Top-level DNS Names

2671 Extension Mechanisms for DNS (LDNSO)

2672 Non-turminal DNS Name Redirection

2673 Binary Labels in the Domain Name System

Глава 15: Протокол передачи гипертекстовых
файлов (HTTP)

1009 Requirements for Internet Gateways. R. T Braden and J. Postel. Jun-01-1987 (Formal:
TXT=I28J73 bvtes) (Status: HISTORIC)
1945 Hypertext Transfer Protocol—НТТР/1.0. Т Berners-Lee, R Fielding, and Н Frvstuk.
May 1996. (Format: TXT-137582 bytes) (Status: INFORMATIONAL)

2068 Hypertext Transfer Protocol—HTTP/LI R.Ftelding, J. Gettys, J. Mogul, H. Frystyk,
and T Berners-Lee. January 1997. (Format: TXT=378114 bytes) (Status: PROPOSED
STANDARD)

2069 HTTP Authentication: Basic and Digest Access Authentication. J.Franks, P.Hallam-
Baker, J. Hosteller, P. Leach, A. Luotonen. E Sink, L. Slewart. January 1997. (Formal:
TXT-41733 bytes) (Status: PROPOSED STANDARD)

2109 HTTP Stale Management Mechanism. D. Kristol and L.Monlulli. February 1997.
(Format: TXT-43469 bytes) (Obsoletes RFCI920) (Status: PROPOSED STANDARD)

2145 Use and Interpretation of HTTP Version Numbers. J. C. Mogul, R Fielding, J Gettys,
and H. Frvstuk. May 1997. (Format: TXT-13659 bytes) (Status: INFORMATIONAL)

2169 A Trivial Convention for using HTTP in URN Resolution R. Daniel. June 1997.
(Format: TXT-17763 bytes) (Status: EXPERIMENTAL)

2227 Simple Hit Metering and Usage Limiting for HTTP. J. Mogul and P. Leach. October
1997. (Format: TXT=85127 bytes) (Status: PROPOSED STANDARD)

2295 Transparent Content Negotiation in HTTP К Holtman and A. Mutz. March 1998.
(Format: TXT=125I3O bytes) (Status: EXPER1MENTAL)2518HTTP Extensions for
Distributed Authoring—WEBDAV. Y. Goland, E. Whitehead, A. Faizi, S. Carter, and
D. Jensen. February 1999. (Format: TXT—202829 bytes) (Status: PROPOSED
STANDARD)

2616 Hypertext Transfer Protocol—HTTP/1.1

2660 The Secure Hypertsext Transfer Protocol

Глава 16: Простейший протокол передачи
файлов (TFTP)

906 Bootstrap Loading Using TFTP

1782 TFTP Option Extension. G. Malkin and A. Harkin March 1995. (Format: TXT=11508
bytes) (Obsoieted by RFC2347) (Updates RFC 1350)

1783 TFTP Blocksize Option. G. Malkin and A. Harkin March 1995. (Format: TXT=7814
bytes) (Obsoieted by RFC2348) (Updates RFC1350) (Updated by RFC1350) (Status:
PROPOSED STANDARD)

1784 TFTP Timeout Interval and Transfer Size Option. G. Malkin and A. Harkin. March
1995. (Formal: TXT-6106 bytes) (Obsoieted by RFC2349) (Updates RFCI350) (Status:
PROPOSED STANDARD)

1785 TFTP Option Negotiation Analysis. G. Malkin and A. Harkin March 1995. (Format:
TXT-3354 bytes) (Updates RFC1350) (Status INFORMATIONAL)

2090 TITP Multicast Option. A. Embcrson. February 1997. (Format: TXT—11857 bytes)
(Status: EXPERIMENTAL)

2347 TFTP Option Extension G. Malkin and A Harkin May 1998. (Format: TXT= 13060
bytes) (Obsoletes RFC 1782) (Updates RFC1350) (Status: DRAFT STANDARD)
2348 ТГГР Blocksize Option G. Malkin and A Harkin. May 1998. (Formal: TXT=9515
bytes) (Obsoletes RFC1783) (Updates RFC135O) (Status: DRAFT STANDARD)

2349 TFTP Timeout Interval and Transfer Size Option. G. Malkin and A Harkin May 1998.
(Format: TXT=7848 bytes) (Obsoletes RFCI784) (Updates RTCI350) (Status. DRAFT
STANDARD)

Глава 17: SNMP (Простой протокол управления
сетью)

1067 Simple Network Management Protocol (SNMP). J.D. Case. M. Fedor, M. L.
Scholfsiall, and J. Davin. Aug-01-1988 (Format: TXT=69592 bvtes) (Obsoleted bv
RFC1098) (Status UNKNOWN)

1089 SNMP Over Ethernet. M. L. Schoffslall, C. Davin, M. Fedor, and J. D Case. Feb-
01-1989 (Format: TXT=4458 bytes) (Status: UNKNOWN)

1098 Simple Layer Management Protocol (SNMP). J. D. Case, M. Fedor, M. L. Schoffslall.
and C. Davin. Apr-01-1989. (Format. TXT=71563 bytes) (Obsoleted by RFCI 157)
(Status: UNKNOWN)

1157 Simple Network Management Protocol (SNMP). J D. Case, M. Fedor, M. L.
Schoffslall, and C. Davin. May-01-1990. (Format: TXT=74894 bytes) (Obsoletes
RFCIO66) (Status: HISTORIC)

1161 SNMP Over OSI M. T. Rose. Jun-01 1990. (Format: TXT=I6O36 bytes) (Obsoletes
by RFC 1418) (Status: EXPERIMENTAL)

1187 Bulk Table Retrieval for the SNMP. M. T. Rose. К McCloghrie, and J R Davin.
Oct-01-1990. (Formal: TXT=27220 bytes) (Status: EXPERIMENTAL)

1212 Concise M1B Definitions. M. T. Rose, K. McCloghrie Mar-01-1991 (Formal:
TXT=43579 bytes) (Status. STANDARD)

1215 Convention for Defining Traps to Use With the SNMP. M. T. Rose. Mar-01-1991.
(Format; TXT= 19336 bytes) (Status: INFORMATIONAL)

1227 SNMP MUX Protocol and MIB. M. T. Rose. May-01-1991. (Format. TXT-25868
bytes) (Status HISTORIC)

1228 SNMP-DPL Simple Network Management Protocol Distributed Program Interface,
Version 2.0. G Carpenter and B. Wijnen. Mav-Ol-I99L (Format. TXT=96972 bytes)
(Obsoleted by RFC1592) (Status; EXERIMENTAL)

1229 Extensions to the Generic-interface MIB. K. McCloghrie. May-01-1991. (Formal:
TXT=36022 bytes) (Obsoleted by RFC1573) (Updated by RFC1239) (Status:
PROPOSED STANDARD)

1239 Reassignment of Experimental MIBs to Standard MIBs. J. K. Reynolds. Jun-01-1991
(Formal: TXT=3656 bytes) (Updates RFCI229, RFC1230. RFC123I, RFC1232.
RFC1233) (Status: PROPOSED STANDARD)

1270 SNMP Communication Services. F Kastenholz. Oct-O) -1991 (Format. TXT= 26167
bytes) (Status: INFORMATIONAL)
1283

1298

1303

1351

1352

1353

1369

1418

1419

1420

1441

1442

1443

1444

1445

1446

1448

SNMP Over OSI. М. Rose Decembei 1991. (Format TXT=16857 bytes) (Obsoleted
by RFCI418) (Status: EXPERIMENTAL)

SNMP Ovei IPX R Vvijrmlev, S. Bostock February 1992. (Format: TXT=7878 bytes)
(Obsoleted bv RFCI420) (Status' INFORMATIONAL)

A Convention for Describing SNMP-based Agents. K. Met loghrie and M Rose.
February 1992 (Formal: TXT=22915 byies) (Also RFC) 155. RFC1212. RFC1213,
RFCI157) (Status INFORMATIONAL)

SNMP Administrative Model J Davin, J. Galvin, and К McCl rghrie. July 1992.
(Format TXT=80721 bytes) (Status PROPOSED STANDARD)

SNMP Security Protocols. J. Galvin. К McCIghrie. and J. Davin. July 1992. (Format:
TXT=8072l bvtes) (Status: PROPOSED STANDARD)

Definitions of Managed Objects for Administration of SNMP Patties. К McCloghrie,
J Davin, and J. Galvin July 1992 (Format: TXT=59556 bytes) (Status: PROPOSED
STANDARD)

Implementation Noles and Experience for the Internet Ethernet MIB. F Kastenholz.
October 1992 (Formal TXT= 13921 bvtes) (Status: PROPOSED STANDARD)

SNMP Over OSI. M Rose. March 1993 (Formal TXT 7721 bytes) (Obsoletes
RFCI16I, RFC 1283) (Status: PROPOSED STANDARD)

SNMP Over AppleTalk. G. M inshall and M Ritter. March 1993 (Formal: TXT= 16470
bvtes) (Status: PROPOSED STANDARD)

SNMP Over IP> S. Bostock March 1993 (Formal: EXT=6762 bytes) (Obsoletes
RFC1298) (Status: PROPOSED STANDARD)

Introduction to Ven.ion 2 of the Internet standard Ne'work Management Framework
J.Case. K. McCloghrie. M. Rose, t nd S. Waldbusser. April 1993. (Format: TXT=2538b
bvtes) (Status: PROPOSED STANDARD)

Structure of Management Information Гог Version 2 of the Simple Network
Management Protocol (SMIv2). J. Case. K. McCloghrie. M Rose, and S Waldbusser.
April 1993. (Format: TXT-95779 bytes) (Obsoleted by RFC19O2) (Status. PROPOSED
STANDARD)

Textual Conventions lor Version 2 of the Simple Network Management Protocol
(SMIv2), J. Case. K. McCloghrie. M Rose, and S. Waldbusser. April 1993. (Formal
TXT=60947 bytes) (Obsoleted by RFCI903) (Status- PROPOSED STANDARD)
Conformance Statements for Version 2 oi the Simple Network Management Protocol
(SMIv2). J. Case, K. McCloghrie, M. Rose, and S. Waldbusser. April 1993. (Format:
1XT=57744 bytes) (Obsoleted by RFC 1904) (Status PROPOSED STANDARD)

Administrative Model lor Version 2 ol the Simple Network Management Protocol
(SNMPv2)

Security Protocols for Version 2 of the Simple Network Management Protocol
(SNMPv2) J.Galvin and К McCloghrie, M Rose, and S. Waldbusser. April 1993.
(Format: TXT=9v443 bytes) (Status: HISTORIC)

Protocol Opeiations for Version 2 of the Simple Network Management Protocol
(SNMPv2). J. Case, K. McCloghrie. M Rate, and S. Waldbusser April 1993. (Format:
TXT=74224 bvtes) (Obsoleted bv RI С1Ч05) (Status: PROPOSED STANDSRD)
1449 Transport Mappings lor Version 2 of the Simple Network Management Protocol
(SNMPv2). J. Case. K. McCloghrie, M Rose, and S. Waldbusser. April 1993. (Format:
TXT=41I61 bytes) (Obsoieted by RFCI906) (Status: PROPOSE D STANDARD)

1452 Coexistence Between Version I and Version 2 of the Internet-standard Network
Management Framework. J Case, K. McCloghrie. M. Rose, and S Waldbusser. April
1993. (Forni.l: TXT-32176 bytes) (Obsoieted by RFCI908) (Status: PROPOSED
STANDARD)

1503 Algorithms for Automating Administration in SNMPv2 Managers. K. McCloghrie
andM Rose. August 1993. (Formal: TXT—33542 bytes) (Status. INFORMATIONAL)

1856 The Opsial Client-Server Model for Statistical Retrieval. H. Clark. October 1995.
(Format TXT=299?4 bytes)(Status: INFORMATIONAL)

1901 Introduction for Communilv-based SNMPv2. SNMPv2 Working Group, J.Case, K.
McCloghrie. M Rose, and S Waldbusser. January 1996. (Format' TXT—15903 bytes)
(Status: EXPERIMENTAL)

1902 Structure of Management Information for Version 2 of the Simple Network
Management Protocol (SMIv2). SNMPv2 Working Group. J.Case, K. McCloghrie,
M. Rose-, and S. Waldbusser. January 1996 fFormat: TXT-77453 bytes) (Obsoletes
RFC1442) (Status: DRAFT STANDARD)

1903 Textual Conventions for Version 2 of the Simple Network Management Protocol
(SMIv2). SNMPv2 Working Group. J. Case. K. McCloghrie, M. Rose, and S.
Waldbusser January 1996 (Format: TXf—52652 bytes) (Obsoletes RFCI443) (Status.
DRA1T STANDARD)

1904 Conformance Statements lor Version 2 of the Simple Network Management Protocol
(SMIv2). SNMPv2 Working Group. J Case, K. McCloghrie, M. Rose, and S.
Waldbusser. January 1996. (Format: TXT—47083 bytes) (Obsoletes RFCE1444) (Status:
DRAFT STANDARD)

1905 Protocol Operations for Version 2 of the Simple Network Management Protocol
(SNMPv2). SNMPv2 Working Group, J.Case, K. McCloghrie, M Rose, and S.
Waldbusser. January 1996. (Format TXT—55526 bytes) (Obsoletes RFC 1448) (Status:
DRAFT STANDARD)

1906 Transport Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2) SNMPv2 Woiking Group, J.Case, K. McCloghrie, M. Rose, and S.
Waldbusser. January 1996 (Formal TXT =27465 by tes) (Obsoletes RFC 1449) (Status.
DRAFT STANDARD)

1908 Coexistence between Version I and Version 2 of the Internet-standard Network
Management Framework. SNMPv2 Working Group, J. Case, K. McCloghrie, M.
Rose, and S Waldbusser. January 1996. (Format: TXT—21463 bytes) (Obsoletes
RFCI452) (Status: DRAFT STANDARD)

1909 An Administrative Infrastructure forSNMPv2. K. McCloghrie. February 1996 (Format:
TXT-45773 bytes) (Status: EXPERIMENTAL)

1910 Usei -based Security Model for SNMPv2. G. Waters. February 1996. (Format:
TXT-98252 bvtes» (Status: EXPERIMENTAL)
2011 SNMPv2 Management information Base for the internet Protocol Using SMIv2. K.
McCloghrie. November 1996 (Format: TXT=3I168 bytes) (Updates RFCI213) (Status
PROPOSED STANDARD)

2012 SNMPv2 Management Information Base for the Transmission Control Protocol using
SMIv2. K. McCloghrie November 1996. (Format- TXT-16792 bytes) (Updates
RFCI213) (Status PROPOSED STANDARD)

2013 SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2.
K. McCloghrie. November 1996. (Format: TXT=9333 bytes) (Updates RFC12I3)
(Status PROPOSED STANDARD)

2039 Applicability for Standards Track MIBs to Management оГ World Wide Web Servers.
C. Kalbl'leisch. November 1996. (Format TXT=31966 bytes) (Status:
INFORMATIONAL)

2089 V2ToVI Mapping SNMPv2 Onto SNMPvl Within a Bilingual SNMP Agent. B.
Winjnene. D. Levi. January 1997. (Format: TXT=238I4 bytes)

2107 Ascend Tunnel Management Protocol ATM P. K. Hamzeh. February 1997. (Formal:
TXT=44300 bytes) (Status: INFORMATIONAL)

2257 Agent Extensibility (AgentX) Protocol Version I M Daniele, B. Wijnen. D. Francisco.
January 1998. (Format: TXT=177452 bytes) (Status PROPOSED STANDARD)

2261 An Architecture for Describing SNMP Management Frameworks. D. Harrington, R.
Presuhn, B. Wijnen. January 1998. (Formal: TXT= 128036 bytes) (Obsoleted by
RFC2271) (Status: PROPOSED STANDARD)

2262 Message Processing and Dispatching for the Simple Network Management Protocol
(SNMP) J. Case, D. Harrington, R. Presuhn, В Wijnen. January 1998. (Format:
1 XT—88254 bytes) (Obsoleted by RFC2272) (Status: PROPOSED STANDARD)

2263 SNMP Applications D. Levi, P. Meyer, and В Stewart. January 1998 (Format:
TXT= 143493 bytes) (Obsoleted by RFC2273) (Status: PROPOSED STANDARD)

2264 User-based Security Model (USM) for Version 3 of the Simple Network Management
Protocol (SNMPv3). U. Blumenthal and B. Wijnen. January 1998. (Formal:
TXT=168759 bytes) (Obsoleted by RFC2274) (Status: PROPOSED STANDARD)

2265 View-based Access Control Model (VACM) for the Simple Network Management
Protocol(SNMP). B. Wijnen, R Presuhn. and K. McCloghrie. January 1998 (Format:
ТХГ=77807 bytes) (Obsoleted by RFC2275) (Status: PROPOSED STANDARD)

2271 An Architecture for Describing SNMP Management Frameworks. D Harrington. R.
Preesuhn. and B. Wijnen. January 1998. (Format: TXT=128227 bytes) (Obsoletes
RFC2261) (Status: PROPOSED STANDARD)

2272 Message Processing and Dispatching for the Simple Network Management Protocol
(SNMP) J. Case, D. Harrington, R. Preesuhn, B. Wijnen. January 1998. (Format:
TXT=88445 bytes) (Obsoletes RFC2262) (Status: PROPOSED STANDARD)

2273 SNMPv3 Applications D Levi, P. Meyer, and B. Stewart. January 1998 (Format:
TXT= 143754 bytes) (Obsoletes RFC2263) (Status: PROPOSED STANDARD)

2274 User-based Security Model (USM) for Version 3 of the Simple Network Management
Protocol (SNMPv3). U. Blumenthal and B. Wijnen. January 1998. (Format:
TXT= 168950 bytes) (Obsoletes RFC2265) (Status: PROPOSED STANDARD)

16 Заж 768
2275 View-based Access Control Model (VACM) for the Simple Network Management
Protocol! SNMP) В Wijnen, R. Presuhn. and К McCloghrie. January 1998. (Format:
TXT=77998 bytes) (Obsoletes RFC2265) (Status; PROPOSED STANDARD)

2438 Advancement of M1B Specifications on the IETF Standards Track. M O’Dell, H.
Alvestrand, B. Wijens. and S. Bradner. October 1998. (Format' TXT= 13633 bytes) (Also
BCP0027) (Status: BEST CURRENT PRACTICE)

2493 Textual Conventions for M1B Modules Using Performance History Bas :d on 15-minute
Intervals К Tesink, Editor January 1999. (Format: TXT=I8749 bytes) (Status:
PROPOSED STANDARD)

2570 Introduction to Version 3 of the Internet-standard Network Management Framework
J. Case R Mundy, D. Partain, and B. Stewart April 1999 (Format: TXT=50381 bytes)
(Status: INFORMATIONAL)

2571 An Architecture for Describing SNMP Management Frameworks. B. Wijnen. D.
Harrington, and R. Presuhn. April 1999 (Format: TXT=13926O bvtes) (Obsoletes
RFC2271) (Status: PROPOSED STANDARD)

2572 Message Processing and Dispatching for the Simple Network Management Protocol
(SNMP). J. Case, D Harrington, R Presuhn, and B. Wijnen. April 1999. (Format:
TXT=96035 bvtes) (Obsoletes RI C2272) (Status: DRAFT STANDARD)

2573 SNMP Applications. D. Levi, P. Meyer, B. Sit wart. April 1999. (Format: TXT=150427
bytes) (Obsoletes RFC2273) (Status: DRAFT STANDARD)

2574 User-based Security Model (USM) for Version 3 ofthe Simple Network Management
Protocol (SNMPv3). U. Blumenthal, B. Wijnen April 1ч99. (Format: TXT=l9t)755
bytes) (Obsoletes RFC2274) (Status DRAFT STANDARD)

2575 View-based Access Control Model (VACM) for the Simple Network Management
Protocol(SNMP). B. Wijnen, R. Presuhn, and K. McCloghrie. April 1999. (Format:
TXT=79642 bvtes) (Obsoletes RFC22275) (Status: DRAIT STANDARD)

2578 Structure of Management Information Version 2(SMIv2). K. McCloghrie, D Perkins,
J. Schoenwaelder. April 1999 (Formal TXT=89712 bytes) (Obsoletes RFCI902) (Also
STD0058) (Status: STANDARD)

2579 Textual Conventions for SMIv2. K. McCloghrie, D. Perkins. J Schoenwaelder April
1999 (Format: 1 XT =59039 bytes) (Obsoletes RFC1903) (Also STDOO58) (Status:
STANDARD)

2581) Conformance Statements for SMIv2 K. McCloghrie, D. Perkins, J. Schoenwaelder.
April 1999. (Format TXT=54253 bytes) (Obsoletes RFCI904) (Also STD0‘)58j (Status:
STANDARD)

2593 Script M1B Extensibility Protocol Version 1.0

Глава 18: Протоколы открытой сетевой
обработки данных

I0I4 XDR: External Data Representation standard. Inc. Sun Microsystems. Jun-01-1987.
(Format: TXT=393I6 bytes) (Status: UNKNOWN)
KW4 NFS: Network File System Protocol specification. Inc. Sun Microsv items. Mar-OI-
1989 (Format: ГХТ =51454 bytes) (Also RFC18I3) (Status: INFORMATIONAL)

1813 NFS Version 3 Protocol Specification. B. Callaghan. B. Pawlowski & P. Staubach.
June 1995 (Format: TXT=229793 bytes) (Also RFC1094) (Status:
INFORMA! IONAI )

2054 WebNFS Client Specification. B. Callaghan. October 1996. (Formal: TXT=4128 bytes)
(Status: INFORMATIONAL)

2055 WebNFS Server Specification. B. Callaghan. October 1996. ( Format: TXT=20498 bytes)
(Status: INFORMATIONAL)

2o23 NFS Version 2 and Version 3 Security Issues and the NFS Protocol’s Use of
RPCSEC_GSS and Kerberos V5

2624 NTS Version 4 Design Considerations
Приложение В

Список аббревиатур

А

ABR (area border rouler) — маршрутизатор грани области

АСК (acknowledgement) — подтверждение

ANSI (American National Standards institute) — Национальный институт стандартиза-
ции США

API (application program interlace) — про1раммный интерфейс приложения

ARP (Address Resolution Protocol) — протокол разрешения адресов

ARPANET (Advance Research Projects Agency network) — сеть управления перспек-
тивных исследовательских программ

AS (autonomous system) — автономная система

ASBR (autonomous system border router) — маршрутизатор границы автономной сис-
темы

ASCII (American Standard Code for Information interchange) — американский стандар-
тный код для обмена информацией

ASN.I (Abstract Syntax Notation One) — абстрактная синтаксическая нотация версия I.

ATM (Asynchronous Transfer Mode) — асинхронный режим передачи

В

BDR (backup designated router) — управляющий (назначенный) резервный маршру-
тизатор

BER (Basic Encoding Rules) — базовые правила кодировки

BGP (Border Gateway Protocol) — протокол граничного шлюза

BIND (Berkeley Internet Name Domain) — служба доменных имен в сети Интернет,
разработанная Калифорнийским университетом

ВООТР (Bootstrap Protocol) — протокол начальной за!рузки

BPF (Berkeley Packet Filter) — пршрамма фильтрации пакетов, разработанная Кали-
форнийским университетам

В RI (Basic Rate Interface) — интерфейс передачи данных с номинальной скоростью
BSD (Berkeley Software Distribution) — программное изделие Калифорнийского уни-
верситета

С

CCITT (Consultative Committee for International Telegraphy and Telephony) — консуль-
тативный комитет по международной телеграфной и гелефонной связи
CIDR (classless interdomain routing) — бесклассовая междоменная маршрутизация

CIX (Commercial Internet Exchange) — биржа коммерческого информационного об-
мена

CLNP (Connectionless Network Protocol) — протокол сетевою обслуживания без ус-
тановления соединения

CPU (centra) processing unit) — центральный процессорный модуль

CSMA/CD (carrier sense multiple access collision detection) — множественный доступ
с контролем несущей и обнаружением конфликтов

CRC (cyclic redundancy check) — контроль при помощи циклического избыточного
кода

CSLIP (compressed SLIP) — сокращенный межсетевой протокол для последователь-
ного канала

CSMA (carrier sense multiple access) — множественный доступ с кон1ролем несущей
CSU (channel service unit) — устройство обслуживания канала

CUT (Coordinated Universal Time) — координированное всемирное время

D

DARPA (Defense Advanced Research Projects Agency) — Управление перспективных
исследовательских программ США

DCE (Distributed Computing Environment) — распределенная вычислительная среда

DDN (Defense Data Network) — Оборонная сеть передачи данных (глобальная сеть
Министерства обороны США)

DDR (Dial-on-Demand Routing) — маршрутизация по требованию (посредством на-
бора номера)

DECNel (Digital Equipment Corporation Network) — сеть корпорации DEC

DEMUX (Demultiplexer) — демультиплексор

DF (don’t fragment held (IP header)) — поле "не фрагментировать" (заголовок IP)

DHCP (Dynamic Host Configuration Protocol) — протокол динамической конфигура-
ции хостов

DLC (Data Link control) — протокол управления каналом передачи данных

DLPI (Data Link Provider Interface) — интерфейс поставщика канала передачи дан-
ных

DNS (Domain Name System) — служба имен доменов

DoD (Department of Defense (Reference Model)) — Министерство обороны (эгалон-
ная модель)

DR (designated router) — управляющий (назначенный) маршрутизатор

DSAP (Destination Service Access Point) — точка доступа к службе получателя

DSU (data service unit) — модуль цифрового обслуживания

DTP (data transfer process) — процесс передачи данных

DTS (Distributed Time Service) — распределенная служба системного времени

DUAL (Diffusing Update Algorithm) — алгоритм диффузною обновления (маршрут-
ной информации)

DVMRP (Distance-vector Multicast Routing Protocol) — дистаннионно-векюрный про-
токол маршрутизации на базе многоадресных рассылок
Е

EBGP (external BGP (router)) — внешний BGP (маршрутизатор)

EBONE (European IP Backbone) — пан-евронейская магистральная IP ость — Ebone

EOL (end of option list) — коней списка опций

EGP (Exterior Gateway Protocol) — протокол внешнего шлюза

EIGRP (Enhanced Interior Gateway Routing Protocol) — улучшенный протокол марш-
рутизации внешнего шлюза

EMI (electromagnetic interference) — электромагнитные помехи (излучение)

F

FCS (frame check sequence) — контрольная пос гедсвательность кадра

FDDI (Fiber Distributed Data Interface) — распределенный интерфейс передачи дан-
ных ио волоконно-оптическому кабелю

FIFO (first in, first out) — “первым вошел, первым вышел"

FIN (finish flag, TCP header) — флаг завершения передачи (заголовок TCP)

FQDN (fully qualified domain name) — полностью определенное имя домена

Fl Р (File Transfer Protocol) — протокот передачи файлов

G-H

НА (hardware address) — аппаратный адрес

HDIC (high-level data link control) — протокол высокого уровня управления кана-
лом передачи данных

IAB (Internet Architecture Board) — Совет по архитектуре сети Интернет

1АС (interpret as command) — интерпретировать как команду

IANA (Internet Assigned Number Authority) — Агентство по выделению имен в сети
Интернет

1BGP (internal BGP (router)) — внутренпи" BGP (маршрухватор)

ICMP (Internet Control Message Protocol) — протокол управляющих сообщений Ин
гериета

1DRP (Interdomain Routing Protocol) — протокол междоменнои маршрутизации

IEEE (Institute of Electrical and Electronics Engineers) — Институт инженеров no элек-
тротехнике и электронике

IESG (Internet Engineering Steering Group) — Испочнительныи комитет IETF

IETF (Internet Engineering Task Force) — Рабочая группа по проектированию сети
Интернет

1GMP (Internet Group Management Protocol) — межсе гевои протокол управления ipyn-
пами

IGP (Interior Gateway Protocol) — протокол внутреннего шлюза

IGRP (Interior Gateway Routing Protocol) — протокол маршрутизации внутреннего
шлюза
IP (Internet Protocol) — протокол Интернета

IPNG (Internet Protocol Next Generation) — новое поколение Интернет протокола
IPX (Internetwork Packet Exchange — протокол межсетевого обмена пакетами)

IRTF (Internet Research Task Force) — рабочая группа по исследованиям сети Интер-
нет

ISDN (Integrated Services Digital Network) — цифровая сеть с интегральным обслу-
живанием.

IS-IS (Intermediate System to Intermediate System Protocol) — прогокол взаимодействия
между промежуточными системами

ISN (initial sequence number) — начальный порядковым номер

ISO (International Organization for Standardization, - Международная организация по
станг аргизации

ISOC (Internet Society) — сообщество сеги Интернет

J-L

LAN (Local Area Network) — локальная ьычислигепьная сеть

LAPB (Link Access Procedure, Balanced) — LAPB Протокол доступа к сбалансирован-
ному каналу связи

L\PD (Link Access Procedure. D channel) — Протокол доступа к цифровому каналу
связи

LBX (low bandwidth X) — "узкополосная версия X" для всех X — серверов (которые
используют технику уменьшения сетевого траффика: кэширование, отправку из-
менений от предыдущих пакетов и сжатие — поим редактора).

LCP (link control protocol) — протокол управления каналом связи

LFN (long lat network) — сеть с повышенной пропускной способностью

LIFO (last in first out) — последним вошел, первым вышел

LLC (logical link control) — протокол управления логической связью

LSA (Link-state advertisement) — объявление (сообщение) о состоянии каналов связи
LSRR (loose source and record route) - потеря отправителя и запись маршрута

м

MAC (media access control) — управление доступом к среде

MBONL (multicast backbone) — многоадресная ма! истра 1ь

MIB (management information base) — информационная база управления

МП NET (Military Network) — военная сеть Milnet

MIME (multipurpose Internet mail extensions) — многоцелевые расширения электрон-
ной почты в сети Интернет

MS (message store) — банк сообщений

M/S (master/slave) — управляюший/подчинепный (маршрутизатор, устройство)

MSL (maximum segment liletime) — максимальное время жизни сегмента

MSAU (Multi-station Access Units) — модуль многоесанционного доступа

MSS (maximum segment size) — максимальный размер сегмента

МТА tmessage transfer agenti - aicHr передачи сообщений
MTU (maximum transfer uml) — максимальный модуль пересылки

MUX (Multiplexer) — мультиплексор

N

NAT (Network Address Translation) — трансляция сетевых адресов

NUMA (non-broadcast multi-access) — сегь с множественным доступом, не поддержи-
вающая широковещательных рассылок

NCP (Network Control Protocol) — протокол управления сетью

NDN (non-delivery notification) — уведомление о неудачном завершении процедуры
доставки сообщения

NetBIOS (Network Basic Input Output System) — сетевая базовая система ввода выво-
да

NFS (Network File System) — сетевая файловая система

NIC (network interface card) — сетевая интерфейсная плата, сетевой адаптер

NIT (network interface lap) — "краник" в сетевом интерфейсе (потоковый (STREAMS)
драйвер псевдоустройства в SunOS 4.1. х — прим, ред.)

NNTP (Network News Transfer Protocol) — сетевой протокол передачи новостей

NOP (no operation) — нет действия

NSFNET (National Science Foundation network) — сеть национальною научного фон-
да

NSI (NASA Science Internet) — сеть Интернет для научных исследований NASA

NSSA (not so stubby area) — “не совсем тупиковая область"

NTP (Network Time Protocol) — протокол сетевой синхронизации

NVT (network virtual terminal) — виртуальный сетевой терминал

О

Opcode (Operation code) — код операции

OSF (Open Software Foundation) — организация ио разработке программного обеспе-
чения для открытых систем

OSI (Open Systems Interconnection (Reference Model)) — эталонная модель взаимо-
действия открытых систем

OSPF (Open Shortest Path First) — протокол поиска кратчайшего пути

Р

РА (protocol address) — протокольный адрес

PDU (protocol data unit) — модуль данных протокола

Pl (protocol interpreter) — интерпретатор протокола

POS1X (Portable Operating System Interface) — интерфейс переносимой операцион-
ной системы

PPP (Point-to-Point Protocol) — протокол двухточечной связи (протокол "точка-точ-
ка")

PRI (Primary Rale Interface) — интерфейс передачи данных с базовой скоростью

PSH (push flag (TCP header)) — флаг форсированной передачи данных, заголовок TCP
Q

QoS (Quality of Service) — качество обслуживания

R

RARP (Reverse Address Resolution Protocol) — протокол обратного разрешения адре-
сов

RFC (Request for Comment) — запрос на комментарии

RFI (radio frequency interference) — радиопомехи

RIP (Routing Information Protocol) — протокол маршрутной информации

RPC (remote procedure call) — вызов удаленных процедур

RR (resource record) — запись о ресурсах

RRQ (read request) — запрос на чтение

RST (reset flag, TCP header) — флаг переустановки соединения, заголовок TCP

RTO (retransmission timeout) — тайм-аут повторной пересылки

RTT (round-trip lime) — время полного обхода (время на передачу и подтверждение
приема сообщения)

S

SA (source address) — адрес отправителя

SACK (Selective Acknowledgement) — выборочное подтверждение

SAP (service access point) — точка доступа к службе

SDLC (Synchronous Data Link Control) — протокол синхронного управления переда-
чей данных

SLIP (Serial Line Internet Protocol) — межсетевой протокол для последовательного
канала

SMI (structure of management information) — структура управляющей информации
SMTP (Simple Mail Transfer Protocol) — упрошенный протокол электронной почты
SNA (System Network Architecture) — сетевая архитектура вычислительных систем
SNAP (Subnetwork Access Protocol) — протокол доступа к подсетям

SNMP (Simple Network Management Protocol) — простой протокол управления сетью
SQE (Signal Quality Error) — ошибка качества сигнала

SRRT (smooth round trip timer) — таймер беспрепятственного полного обхода

SSAP (source service access point) — точка доступа к службе отправителя

SWS (silly window syndrome) — синдром "глупого” окна

SYN (synchronize sequence numbers flag, TCP header) — флаг синхронизации пород
ковых номеров, заголовок TCP

т

ГСР (Transmission Control Protocol) — проюкол управления передачей (данных)
TFTP (Trivial File Transfer Protocol) — простейший протокол пересылки файлов
TLI (Transport Layer Interface) — интерфейс транспортного уровня

ToS (typc-of-servicc) — тип обслуживания
TTL <time-io-live) — время жизни

TUBA (TCP and UDP with bigger addresses) — TCP и UDP с увеличенными адресами
Telnet (Telecommunication Network Protocol) — протокол сетевого взаимодействия с
терминалами

и

UA (user agent) — агент пользователя

UDP (User Data Protocol) — протокол передачи пользовательских дейтаграмм

UI (user interface) — пользовательский интерфейс

URG (urgent pointer flag (TCP header)) — флаг срочности, заголовок TCP

UUCP (Unix-to-Unix Copy) — протокол обмена данными между согласованными
UNIX-системами

V

VC (virtual circuit) — виртуальный канал

VLAN (Virtual Local Area Network) — виртуальная локальная вычислительная сеть

VLSM (Variable Length Subnet Mask) — маска подсети переменной длины

w

WAN (Wide Area Network) — глобальная сеть

WRQ (write request) — запрос на запись

WWW (World Wide Web) — Web. всемирная "паутина"

x-z

XDR (external data representation) — протокол внешнего представления данных

XID (exchange ID or transaction ID) — идентификатор обмена, или идентификатор
транзакции

XTI (X/Opcn Transport Laver Interface) — открытый интерфейс транспортного уров-
ня
Приложение С

Номера портов TCP/UOP

В таблице С.1 представлен список номеров портов протоколов TCP и UDP.

Таблица С.1 Номера общеизвестных портов TCP/UDP_______________________________

Десятичный номер	Ключевое  слово	Протокол	Описание
20	FTP-DATA	TCP	Протокол передачи файлов (данные по умолчанию)
21	FTP	TCP	Протокол передачи файлов (управлание)
23	TELNET	TCP	Telnet
25	SMTP	TCP	Упрощенный протокол электронной почты
37	NTP	TCP	Протокол сетевой синхронизации
49	LOGIN	TCP	Протокол регистрации хостов
53	DNS	TCP/UDP	Служба именования доменов
63	VIA-FTP	TCP	Протокол передачи файлов между системами
67	BOOTPS	UDP	Протокол начальной загрузки сервера
60	BOOTPC	UDP	Протокол начальной загрузки клиента
69	TFTP	UDP	Простейший протокол передачи файлов
69	TFTP	TCP	Простейший протокол передачи файлов
70	Gopher	TCP	Файловая служба Gopher
80	WWW	TCP	Службы WWW
137	NelBIOS-NS	TCP	Служба именования NetBIOS
139	NetBIOS-DG	TCP	Служба пересылки дейтаграмм NetBIOS
161	SNMP	UDP	Простой протокол управления сетью
161	SNMP	TCP	Простой протокол управления сетью

179	BGP	TCP	Протокол граничного шлюза
Приложение D

Глоссарий

1BASE5. Реализация стандарта IEEE 802.3 (Ethemei). специфицирующая метод пе-
ресылки данных со скоростью I Мбит/с на основе немодулированной однополос-
ной передачи данных по физическому носителю (по толстому коаксиальному кабе-
лю) с максимальной длиной cei мента 500 метров,

I0BASE2 Реализация стандарта IEEE 802.3 (Ethernet), специфицирующая метод пе-
ресылки данных со скоростью 10 Мбит/с на основе немодулированной однополос-
ной передачи данных по физическому носителю (по тонкому коаксиальному кабе-
лю) с максимальной длиной cei мента 185 метров.

10BASE5. Реализация стандарта IEEE 802.3 (Ethernet), специфицирующая метод пе-
ресылки данных со скоростью 10 Мбиг/с на основе немодулированной однополос-
ной передачи данных по физическому носителю (по толстому коаксиальному кабе-
лю) с максимальной длиной сегмента 500 метров.

10BASE-T. Реализация стандарта IEEE 802.3 (Ethernet), специфицирующая метод
пересылки данных со скоростью 10 Мбит/с на основе немодулированной однопо-
лосной передачи данных по физическому носителю (по кабелю из витых пар). Дан
ный стандарт позволяет присоединять AUI-совместимые устройства к нсэкраниро-
ванному кабелю из витых пар 24-го калибра (0,511 мм — прим, научи, ред) вместо
обычною коаксиального кабеля.

J00BASE-FX. Реализация стандарта IEEE 802.3 (Ethernet), специфицирующая метод
пересылки данных со скоростью 100 Мбит/c на основе немодулированной однопо-
лосной передачи данных по физическому носителю (по многомодовому волоконно-
оптическому кабелю).

I00BASE-T. Реализация стандарта IEEE 802.3 (Ethernet), специфицирующая метод
пересылки данных со скоростью 100 Мбит/с на основе немодулированной однопо-
лосной передачи данных по физическому носителю (по неэкранированной витой
паре).

I00BASE-T4 Реализация стандарта IEEE 802.3 (Ethernet), специфицирующая метод
пересылки данных со скоростью 100 Мбит/с на основе немодулированной однопо-
лосной передачи данных но физическому носи гелю (по четырем витым парам кате-
гории 3, 4 и 5).

I00BASE-TX. Реализация стандарта IEEE 802.3 (Ethemei), специфицирующая метод
пересылки данных со скоростью 100 Мбит/с на основе немодулированной однопо-
лосной передачи данных но физическому носителю. Данный стандарт позволяет при-
соединять AUI-совместимые устройства к неэкранированному кабелю из витых пар
24-калибра (0,5) I мм) вместо обычного коаксиального кабеля.
100BASE-X. Спецификация Fast Ethernet, реализующая метод пересылки данных со
скоростью 100 Мбиг/с по волоконно-оптическому кабелю на базе стандартов
10UBASEFX и IOOBASETX.

lOOVG-AnvLAN. Совмещенная тсхнолотя Fast Ethernet и Token-Ring, обеспечива-
ющая пересылку данных со скоростью 100Мбит/с по физическому носителю (по че-
тырем витым парам категории 3, 4 и 5).

А

ABR (Area Border Router — Маршрутизатор грани области). Маршрутизатор, распо-
ложенный на грани одной или более областей OSPF и подсоединяющий эти облас-
ти к Mai нстральной сети.

AC (Access Control — управление доступом) Байт DLC сети Token-Ring стандарта
IEEE 802.5, в котором содержится указатель маркера и информация об уровне при-
оритетности кадра.

Access list (список управления доступом). Список, поддерживаемый маршрутизато-
рами с целью управления доступом к различным службам через данный маршрути-
затор.

Access method (метод доступа). Метод (алгоритм), по которому устройства получа-
ют доступ к данной сети.

Access server (сервер доступа). Процессор, подсоединяющий асинхронные устрой-
ства к глобальной или локальной сети посредством соответствующих npoipaMM эму-
ляции.

АСК (Acknowledge — пакет "Подтверждение”) Сетевой пакет, содержащий подтвер-
ждение приема данных хостом-получателем.

Acknowledgement (подтверждение). Передаваемое от одного устройства сети к дру-
гому уведомление, подтверждающее, что произошло какое-либо событие.

Active monitor (Активный инспектор). Компьютер в сети Token-Ring, функциони-
рующий в кольцевой топологии в качестве контроллера. Такой компьютер рсгули-
руег передачу маркера, а также дру!ие аспекты процесса передачи данных в сети с
кольцевой тополстией.

Address (адрес). Структура данных, однозначно идентифицирующая объект.

Address mapping (отображение адресов), Метод преобразования адресов из одного
формата в другой, позволяющий различным протоколам взаимодействовать между
собой.

Address resolution (разрешение адресов). Метод решения проблемы отличий между
различными схемами компьютерной адресации.

Adjacency (отношения смежности). Процесс формирования взаимоотношений меж-
ду соседними устройствами.

ADSP (AppleTalk Data-Stream Protocol — Протокол перенаправления потоков дан-
ных AppleTalk). Протокол, устанавливающий и поддерживающий полнодуплексное
взаимодействие между двумя сокетами AppleTalk.
Advertising (объявление). Процедура, с помощью которой тот или иной сервис со-
общает о своем существовании в сети. Используется также маршрутизаторами для
распространения маршрутной информации по сеги.

Agent (Агент). Программный модуль, обрабатывающий запросы и формирующий
ответы на них.

Algorithm (алгоритм). Определенное правило или процедура решения той или иной
залами.

All-routes explorer packet (пакет-анализатор всех маршрутов). Анализирующий пакет,
который путешествует по всей сети SRB (source route bridging — мостовая передача
с маршрутизацией от источника), исследуя все возможные пути к пункту назначе-
ния.

AMI (alternative mark inversion, Tl lines — кодирование с чередованием полярности
элементе в линиях TI). Схема кодирования импульсной передачи данных с исполь-
зованием знакопеременной полярности в последовательности импульсов.

ANSI (American National Standards Institute — Национальный институт стандартиза-
ции США). Организация в сфере информационных технологий, которая курирует
разработку торювых и коммуникационных стандартов.

API (Applications Program Interface — интерфейс прикладных программ). Программ-
ный интерфейс, обслуживающий обмен данными между протоколами различных
уровней и определяющий способ представления функции и данных одного программ-
ною модуля для получения доступа к другому модулю.

AppleTalk. Разработанный корпорацией Apple Computers набор протоколов обмена
данными.

Application layer (Прикладной уровень). Уровень 7 эталонной модели OS1, который
предоставляет соответствующие службы прикладным процессам, функционирующим
за рамками модели OSI

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

ARCNET (Attached Resources Computing Net — Вычислите 1ьная сеть с присоединен-
ными ресурсами) Сеть с немодулированной однополосной передачей маркера кор-
порации Datapoint. в рамках когороп могут взаимодействовать до 255 станций со ско-
ростью передачи данных 2.5 Мбит/с.

ARP (Address Resolution Protocol — Протокол разрешения адресов) Протокоч, вхо-
дящий в состав стека протоколов TCP/IP и используемый для определения адреса
узла на канальном уровне (DLC-адреса) по его IP-адресу. Ишерпретируется интер-
претатором протокола (PI) в рамках стека протоколов VINES корпорации Banyan
Systems.

ARPANET (Advanced Research Projects Agency Network — Сеть управления перспек-
тивных исследовательских проектов). Сеть с коммутацией пакетов, организованная
в 1969 г.

AS (Autonomous System — Автономная система, АС) Совокупность сетей с центра-
лизованным управлением. Сети, входящие в состав одной АС. следуют одной п той
же стратегии маршрутизации пакетов.
ASBR (Autonomous System Boundary Router — Маршрутизатор границы автономной
системы). ABR (маршрутизатор грани области), расположенный между автономной
системой под управлением протокола OSPF и сетью, функционирующей не под уп-
равлением протокола OSPF.

ASCII (American Standard Code Гог Information Interchange — Американский стандар-
тный кол для обмена информацией). Обеспечивает преобразование между числовыми
кодами и графическими символами Используется как в составе программного обес-
печения персональных компьютеров фирмы IBM, так и в составе прикладных про-
грамм, обеспечивающих функционирование мэйнфреймов других фирм.

Asynchronous transmission (асинхронная передача). Способ передачи данных, позво-
ляющий выполнять пересылку 8-разрядных символов с неравномерными интерва-
лами; при этом каждый передаваемый символ сопровождается стартовым и стопо-
вым битом (start and stop bit).

AUI (Attachment Unit Interface — Интерфейс устройств доступа). Кабель внешнего
доступа в сети Ethernet, ведущий or станции к приемопередатчику.

AutoSPID (Automatic Service Profile Identifier — Автоматическое установление иден-
тификатора профиля). Характеристика терминального адаптера, позволяющая заг-
ружать данные об идентификаторе SPID с совместимого коммутатора.

Availability (доступность). Период времени, на протяжении которого сеть находится
в рабочем состоянии.

В

В channel (Всагег channel — В-канал, канал-носи i ель). Однонаправленный канал-
носитель данных с пропускной способностью 64 Кбит/с, по которому передаются
собственно полезные данные пользователя.

Backbone (магистраль). Магистраль — это часть коммуникационной сети, перено-
сящая самый интенсивный трафик. Является базой для разработки всего сетевого
сервиса.

Background task (фоновая задача). Дополнительное задание, выполняемое одновре-
менно с выполнением основного задания пользователя, например, — выполнение
сетевым сервером операции, связанных с функционированием сети (управление
процессом взаимодействия между устройствами сети), в то время как пользователь
в приоритетном режиме выполняет какое-либо приложение (например, текстовый
редактор).

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

Bandwidth domain (зона полосы частот). Все устройства, совместно использующие
для передачи данных одну и ту же полосу частот.

Bandwidth reservation (резервирование полосы частот). Процесс выделения полосы
частот- пользователям и приложениям, которых обслуживает данная сеть. Резерви-
рование поносы частот позволяет задать приоритет прохождения различных инфор-
мационных потоков на основании важности и срочности передаваемых данных.
Ba: eband (нсмодулированная монополосная передача). Метод, позволяющий выпол-
нять передачу данных без использования частоты более высокого порядка. Для пе-
редачи данных используется вся полоса частот передающей среды.

Baud rate (скорость передачи в бодах) Показатель скорости прохождения сигнала в
процессе передачи данных; эга скорость измеряется в количестве элементарных сиг-
налов, которые могут быть переданы за одну секунду. В большинстве случаев (при
низких скоростях) скорость передачи в бодах — это практически то же самое, что и
скорость передачи данных в битах в секунду.

BDR(B<xkup Designated Router — назначенный резервный маршрутизатор). Поддер-
живает функционирование протокола OSPF и является резервным по отношению к
управляющему маршрутизатору (DR).

Beacon (сигнальный кадр, маяк) Пакет Token-Ring, chi нализирующий о серьезном
нарушении в работе кольца

BECN (Backward Explicit Congestion Notification — Уведомление о явной иерефузке
в обратном направлении). В технолопш Frame Relay — шее гой бит второго октета
заголовка кадра Frame Relay, используется с целью информирования абонентского
V< гройсгва о перегрузке в обратном направлении.

BGP (Border Gateway protocol — Протокол граничного шлюза) Протокол BGP. со-
гласно RFC 1771. предоставляет пользователю возможност ь осуществлять свободный
от зацикливания процесс междоменнои маршрутизации между автономными систе-
мами.

Binary (двоичная система счисления). Система счисления, использующая для пред-
ставления данных только два шачсния — 0 и I (I = включено, 0 = выключено).

BIOS (Basic Input/Output System — Базовая система ввода вывода). Набор стандар-
тных программ, взаимодействующих с аппаратным обеспечением с целью поддерж-
ки передачи информации между элементами системы. В состав такого аппаратного
обеспечения входит запоминающее устройство, диски, монитор и др.

Bit (бит). Двоичный разряд, используемый для представления данных в двоичной
системе счисления; может принимать значение 0 или 1.

Bit rate (скорость передачи битов). Скорость, с которой выполняется передача би-
тов информации; обычно исчисляется в битах в секунду (бит/с).

BNC (Bayonet Network Connector — Байонетный сетевой соединитель) Стандарт-
ный соединитель для коаксиального кабеля; используется для подсоединения кабе-
лей в сетях ARCNFT и Thin Ethernet (сеть с тонким коаксиальным кабелем).

ВООТР (Boot protocol — Протокол начальной загрузки). Протоюл. входящий в со-
став стека протоколов ГСР/1Р, который используется для загружи начальных про-
грамм на подключенные к сети рабочие станции. Интерпретируется в рамках стека
TCP/IP посредством интерпретатора протокола PI.

BPDU (Bridge Protocol Data Unit — Модуль данных протокола мостового сопряже-
ния устройств). Пакет протокола octobhoi о дерева

(spanning-tree protocol packet), отправляемый с конфигурируемым интервалом для
обмена информацией с мостами данной сети
Bps (bits per second — бит/с, бит в секунду). Единица измерения скорости передачи
данных.

Breakout box (коммутационный бокс) Контрольное устройство, предназначенное для
тестирования сигналов, поступающих через RS-232, V.35 или другой интерфейс. Ком-
мутационный бокс используется для обнаружения неисправностей интерфейса.

Bridge (мост). Устройство, используемое для соединения двух отдельных-яокальных
сетей в одну расширенную сеть. Мосты выполняют передачу только тех пакетов, ко-
торые предназначены для подсоединенной через данный мост сети.

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

Broadcast. (I) (Широковещательное сообщение). Сообщение, рассылаемое по всем
рабочим станциям сеги или совокупности сетей. (2) (Широковещательный адрес).
Адрес пункта назначения, по которому сообщение направляется по всем рабочим
станциям.

Buffer (буфер) Программа, область памяти в ОЗУ. отдельное устройство, использу-
емые для хранения данных. Например, накопительный буфер анализатора прото-
колов Sniffer функционирует в качестве временной области памяти для хранения на-
копченных сетевых данных до тех пор. пока эти данные не будут проанализированы
и сохранены на диске.

Burstv traffic (пульсирующий трафик). Термин, обозначающий неравномерный ре-
жим передачи данных.

Bus (шина). Группа линий электрических соединений, обеспечивающих передачу
ст налов между различными компонентами компьютера (известна также под назва-
нием магистраль, highway).

Bus topology (шинная топология). Архитектура локальной сети, в соответствии с ко-
торой все рабочие станции подключены к общему линейному каналу передачи дан-
ных.

Byte (байт). Группа из восьми битов, обрабатываемая как единое целое.

С

СА (Certificate Authority — бюро сертификации). Независимая организация, устанав-
ливающая подлинность продукции и выдающая цифровые сертификаты

Caching (кэширование). Способ копирования данных в кэш-память, при котором
информация, полученная в результате предыдущей транзакции, используется в про-
цессе обработки следующей транзакции.

Capture (захват). Процедура, посредством которой анализатор протоколов Sniffer
выполняет запись сетевого трафика для осуществления анализа сетевой информа-
ции. В сущности, подобная интерпретация происходит во время вывода информа-
ции на экран В то же время экспертное приложение Sniffer может одновременно
выполнять и сбор, и интерпретацию сетевого трафика.
Category cabling (категории кабелей). Существует пять категорий UTP-кабелей (ка-
белей из неэкранированных витых пар), описание которых представлено в стандар-
те EIA/TIA-586

CCITT (Consultative Committee Гог International Telegraphy and Telephony — Консуль-
тативный комитет по международной тепеграфной и телефонной связи) Предше-
ствующее название оршнизации ITU (International Telecommunications Union — Меж-
дународный союз по телекоммуникациям), которая является специальным органом
ООН. Союз ITU поддерживает разработку ряда стандартов, обслуживающих сети
передачи данных, а также стандартов телефонной коммутации, терминалов и циф-
ровых систем

Channel ( канал ). Коммуникационный путь для осуществления обмена данными.
Channel attached (канал подсоединяющий* Канал передачи данных по которому
выполняется непосредс.венное подсоединение устройств к компьютеру.

channelized El (тиния El с разделением полосы частот на отдельные каналы). Ка-
нал типа EI. поддерживающий скорость передачи данных 2, 048 Мбит/с.

channelized Т1 (линия Т1 с разделением полосы частот на отдельные каналы). Ка-
нал типа Т1. поддерживающий скорость передачи данных 1, 544 Мбит/с.

CHAP (Challenge Handshake Authentication Protocol — Протокол аутент ификации с
предварительным согласованием вызова). Средство защиты от несанкционирован-
ною доступа, поддерживаемое на линиях с инкапсуляцией данных посредством
протокола РРР.

Chat script (интерактивный сценарий). Гр1 ппа из трех интерактивных цепочек (ус-
тановление, простуживание и отсоединение), выполняющая управление присвое-
нием коммуникационных параметров асинхронною устройства.

Chat string (интерактивная строка). Последоватепьность символов, соответствующих
командам/ответам UNIX, загружаемая в серийное устройство с целью управления
его работой

CIDR (Classless Interdomain Routing — Бесклассовая междоменная маршрутизация).
Маршрутизация по множеству выделенных Интернет-провайдерам и присваиваемых
клиентам адресов класса С. обтединенных пол одним ичи более 1Р-адрессв. объяв-
ленных в таблице маршрутизации.

CIR (Committed Information Rate — Сои всованная скорость передачи информации).
Минимальная пропускная способность постоянного виртуального канала (PVC) в
сети Frame Relay. С IR присваиваегся в момент инициализации службы ретрансля-
ции кадров Frame Relay.

Circuit ( капал связи). Коммуникационный путь между двумя или более точками.

Circuit switching (коммутация каналов) Технология коммутации в сети передачи дан-
ных, согласно которой физическое соединение Me»av отправителем и покупателем
устанавливается толы о на время передачи данных

Classful routing protocols (Протоколы маршрутизации по классам адресов). Прото-
колы маршрутизации, не леречаюшие в своих заголовках информацию о длине пре-
фикса (фра!мента адреса, сио1ветсгвующею адресу сети).
Classless routing protocols (Протоколы бесклассовой маршрутизации). Протоколы
маршрутизации, в заголовки сообщений об обновлении маршрутной информации
которых включена информация о длине префикса (фрагмента адреса, соответству-
ющею адресу сети).

CLI (Command-line Interface — Интерфейс командной строки). Интерфейс, предос-
тавляющий пользователю возможность взаимодействия с операционной системой
посредством ввода команд и дополнительных параметров.

Client (клиент) (1) Программный модуль, использующий службы другого программ-
ного модуля, например, — сеансовый уровень является клиентом транспортного
уровня. (2) Персональный компьютер или рабочая станция, получающая доступ к
службам или приложениям, функционирующим на другом персональном компью-
тере или рабочей станции (сервере)

CODEC (Coder-Decoder — Кодер-декодер), Устройство, использующее импульсно-
кодовую модуляцию (PCM, Pulse-code Modulation) в процессе преобразования ана-
логовых сигналов в цифровые и наоборот.

Collision (конфликт). В Ethernet — результат передачи данных одновременно двумя
и более узлами. Катры, передаваемые каждым из устройств, при встрече на физи-
ческом носителе вступают в противоречие и могут быть повреждены.

Collision domain (Область коллизий: домен коллизии). В Ethernet — область сети, по
которой передаются вступившие в противоречие кадры.

Community (Сообщество). В SNMP — ло!ическая группа управляемых устройств и
станций управления сетью (NMS, Network Management Station), входящих в состав
одного административного домена.

Community string (Идентификатор сообщества) Текстовая строка, функционирую-
щая в качестве пароля, она используется для аутентификации сообщений, переда-
ваемых между станцией управления сетью и маршрутизатором, на котором активи-
зирован агент SNMP

Compression (сжатие). Сокращение ширины полосы пропускания или количества
битов, необходимых для кодирования информации.

Concentrator (концентратор). Центральное устройство, связывающее несколько от-
дельных рабочих станций в сетях с кольцевой toiiojioi ией. Как правило, применя-
ется в сетях FDDI.

Connection-oriented Data Transfer (Передача данных, ориентированная на соедине-
ние). Передача данных, требующая установления виртуального канала связи.

Connectionless Data Transfer (Передача данных, не ориентированная на соединение).
Передача данных, которая осуществляется без установления виртуального канала свя-
зи

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

Core Layer (Базовый уровень). Уровень иерархической локальной сети, обеспечива-
ющий ошимальпый транспорт между узлами.
CPU (Central Processing Unit — Центральный процессорный элемент (модуль),
ЦПЭ(М)). Основной процессор устройства, такого как компьютер или маршрутиза-
тор.

CRC (Cyclic Redundancy Check — Контроль при помощи циклическою избыточно-
го кода). Алгоритм проверки целостности данных посредством исполг зования в конце
кадра контрольного слова (как правило, 2 или 4 байта) для обнаружения ошибок в
сос.аве передаваемых в казре данных,

CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance — Множественный
доступ с контролем нссушей и предотвращением конфликтов). Метод произволь-
ного или основанного на конкуренции доступа к среде. Алгоритм, используемый в
сетях LocalTalk и осуществляющий управление передачей данных

CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance — Множественный
доступ с контролем несущей и обнаружением конфликтов). Метол произвольного
или основанного на конкуренции доступа к среде Алгоритм. используемый в сетях
IEEE 802.3 Ethernet и осуществляющий управление передачей данных.

CSU (Channel Service Unit — Устройство обслуживания канала) Аппаратный интер-
фейс, обеспечивающий корректность формата и синхронизации цифровых сигналов
при передаче данных по линиям связи. Часто функционирует в комплексе с моду-
лем цифровою обслуживания (DSU, Data Service Unit).

Custom queuing (формирование очереди методом предварительного заказа). Способ
организации очереди, применяющийся для обеспечения гарантированного выделе-
ния полосы частот для графика посредством выделения пространства в очереди на
основании номера порта, протокола или согласно каким-либо другим критериям.
Cut through packet switching (сквозная коммутация пакетов). Метод коммутации па-
кетов, со1ласно которому поток данных проходит через коммутатор таким образом,
что первая часть пакета поступает в порт вывода еще до завершения приема всего
пакета через порт ввода.

D

D Channel (Data channel - D-канал, канал данных). Канал сети ISDN, используе-
мый для передачи служебной управляющей информации между коммутирующим
оборудованием и оборудованием пользователя. D-канал не используется для пере-
дачи сооственно полезных данных пользователя.

DAC (Dual Attachment Concentrator — Концентратор с двойным подключением)
Концепт paiup. предлагающий два канала подключения к сети FDDI. в обязанности
которых ьходш обеспечение адат наносы двойного кольца FDDI и друтх портов
к каналам других концентраторов или станций FDDI

DAS (Dual Attachment Station — Станция с двойным подключением). Станция, один
интерфейс которой подключен к одном* кольцу, а другой интерфейс — к другому
колы v FDDI

Datagram (Дета1 рамма) Логический модуль информации, рассматриваемый в ка-
честве блока данных сетевого уровня, предназначенного для передачи по физичес-
ких.1 постелю без установления виртуального канала евши.
Data Link layer (Канальный уровень). Уровень 2 эталонной модели OSI. обеспечи-
вающий надежную передачу данных но физическому каналу.

DB-9 (разъем DB-9). 9-контактный стандартный соединительный кабель, использу-
емый в персональных комлькмерах для подключения к сети Token-Ring ("мама"),
для подключения к последовательному порту ввода/вывода ("пана”), и для вывода
RGBI (применяемого также в LocalTalk).

DB-15 (разъем DB). 15-контактный стандартный соединительный кабель, применя-
емый на приемопередатчике для подключения к внешнему кабелю, а также для со-
единения компонентов сети IEEE 802.3 или Ethernet.

DB-25 (шина DB-25) 25-контактный стандартный соединительный кабель, приме-
няемый в персональных компьютерах для портов параллельного вывода данных
("мама" в аппаратном блоке IBM PC) или для последовательных портов ввода/вы-
вода ("папа" в аппаратном блоке IBM PC).

DCE (Data Circuit-terminating Equipment, Data Communications Equipment —Обору-
дование передачи данных) На последовательном канале связи — устройство, под-
соединяющее терминальное оборудование к линии или каналу связи.

DDP (Datagram Delivery Protocol — Протокол доставки дейтаграмм). Протокол, рас-
ширяющий службы базового протокола доступа к каналу передачи данных
(Underlying Link Access Protocol) посредством обеспечения сетевого комплекса
AppleTalk возможностью адресации пакетов через сокеты тою или иною узла Про-
токол DDP функционирует в составе стека протоколов AppleTalk РТ

DDR (Dial-on-Demand-Routing — Маршрутизация по требованию). Метод маршру-
тизации, посредством которого маршрутизатор Cisco имеет возможность автомати-
чески инициировать и закрывать сеанс связи с коммутацией каналов по мере по-
ступления запросов на действие такого типа со стороны передающих станций.

DE (Discard Eligibility — Флаг DE, допустимость отбрасывания кадра). Флаг, уста-
навливаемый в седьмом бите второго октета заголовка кадра Frame Relay. Значение
1. устанавливаемое в этом бите, означает, что допустимо отбрасывание кадра при
его прохождении через перебуженную сеть.

Decapsulation (расформирование, декапсуляиия). Освобождение данных от заголов-
ка того или иного протокола.

Decryption (декодирование, дешифрирование). Восстановление данных в их перво-
начальном. незакодированном (дешифрированном) виде.

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

Dedicated line (выделенная линия). Линия связи, зарезервированная для передачи
данных на постоянной основе, а не распределяемая в процессе коммутации кана-
лов по мере поступления запроса на передачу данных.

Default route (маршрут по умолчанию). Запись в таблице маршрутизации, которая
используется для ориентировки дальнейшего продвижения пакета, для которого сле-
дующий транзитный участок в таблице маршрутизации не отображен однозначно.
Default router (маршрутизатор no умолчанию). Маршрутизатор, куда направляются
пакеты, для которых следующий транзитный участок в таблице маршрутизации не
отображен однозначно.

Delay (задержка). Период времени между началом транзакции со стороны отправи-
теля и первым ответом, полученным отправителем.

Delay-Sensitive (трафик, чувствительный к задержке). Сетевой трафик, требующий
своевременной доставки и соответствующего этому требованию варьирования ин-
тенсивности продвижения по сети.

Destination Address (Адрес хоста-получателя, адрес пункта назначения). Часть сооб-
шения. в которой идентифицируется получатель сообщения.

DHCP (Dynamic Host Configuration Protocol — Протокол динамической конфигура-
ции хостов) Протокол, выполняющий динамическое назначение IP-адресов хостам
таким образом, чтобы эти адреса можно бы то использовать повторно, если отпада 
ет необходимость в их дальнейшем использовании.

D'al-up Line (комму тируемая линия связи с набором номера). Двухсторонний канал
передачи данных, выделяемый дтя передачи данных в резутьтате выполнения про-
цедуры коммутации каналов посредством установления соединения через телефон-
ную сеть.

DIP switch (Dual Inline Package Switch — Переключатель DIP). Встраиваемый в пе-
чатную плату миниатюрный переключите >ь, который можно заменить с помощью
небольшой отвертки Существ) ет два положения пероютючатеяя: включено (on) и
выключено (оГГ*. В печатную плату, кек правило, встраивается целый блок переклю-
чателей типа DIP. который используется для конфигурирования платы на полупос-
тояннои основе.

DISC (Disconnect — Рассоединить) Управляющий кадр LLC (не содержащих полез-
ных данных), передача которою означает, что соединение, установленное ранее по-
средством передачи кадров SABM или SABML. должно быть разорвано.

Display (вывод (отображение) данных на экран). Процедура, посредством которой
анализатор протоколов Suiffar интерпретирует трафик, запись которого была выпол-
нена в результате процедуры захвата (capture) Вс время вывода данных на экран
анализатор выполняет декодирование заголовков кадров протоколов различных vpoe 
ней и отображает эти заюливки на экране в доступном для прочтения пользовате-
лем ваде.

Distance vector routing algorithm (Дистаннионно-векториый алгоритм маршрутиза-
ции). Категория алгоритмов маршрутизации, согласно которым каждый маршрути-
затор должен отираю.ять всю свою таблицу маршрутизации или ее часть в адрес
соседних устройств.

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

DLC (Data Link Control — Протокол управления каналом передачи данных). Про-
токол нижнею уровня, используемый для передачи кадра но сети. В состав оголов-
ка DLC. как правило, входит поте IP-адреса отравителя (Source Address), поле IP-
адреса получателя (Destination Address) и — в некоторых случаях — специальная
управляющая информация.

DLC1 (Data Link Connection Identifier — Идентификатор канала передачи данных».
10-разрядное число, используемое протоколом Frame RJay (Frame Relay Protocol) и
идентифицирующее виртуальный канал связи.

DM (Disconnected Mode — Режим отключения). Сообщение LLC, подтверждающее
разрыв ранее установленного соединения.

DNS (domain name service — служба именования доменов). Протокол, входящий в
состав стека протоколов TCP/IP и используемый для поиска ин формации о ресур-
сах посредством базы данных, распределенной между различными серверами имен.
Выполняется в составе стека протоколов TCP/IP.

DR (Designated Router — Управляющий маршрутизатор) Маршрутизатор OSPF, ге-
нерирующий сообщения LSA для рассылки по хостам сети с множес твенным досту-
пом.

DSO (Digital Signal Level 0 — цифровой сигнал уровня 0). Линии TI. Один канал с
полосой 64 Кбит/с в составе сигнала DSI. См. также DS1 и DS3.

DSI (Digital Signal Level 1 — цифровой сигнал уровня 1) Линии Т1. Базовый циф-
ровой сигнал для передачи данных по линии TI. Сигнал DS1 передается по 24 кана-
лам с полосой 64 Кбит/с (называемых каналами DS0, каналами передачи цифровых
сигылов уровня U); сроме этого, 8 Кбит/с используется для синхронизации и фор-
мирования анналов; следовательно, суммарная полоса частот — 1 544 Кбит/с.

DS3 (Digital Signal Level 3 — цифровой сигнал уровня 3). Линии ТЗ. Стандарт для
передачи цифровых сигналов со скоростью 44, 736 Мбит/с.

DSAP (Destination Service Access Point — Точка доступа к службе получателя). Точ-
ка доступа к службе (SAP) на подуровне LLC канального уровня, предназначенная
для протокола, предположительно используемого станцией назначения для декоди-
рования данных передаваемого кадра.

DSL (Digital Subscriber Line — Цифровая абонентская линия). Технология, переда-
чи данных, используемая для удовлетворения провайдером сетевых успут исходных
условий заказчики посредством применения диапазонов высоких частот с цетью обес-
печения большей производительности полосы частот на стандартных медных про-
водниках

DSU (Data Service Unit — Модуль цифрового обслуживания). Устройство, через ко-
topoe выполняется подключение терминального оборудования к цифровым линиям
связи. См. также CSU

DTE (Data Terminal Equipment — Терминальное оборудование) Общий термин, ис-
пользуемый для описания хоста или компьютера конечного пользователя, подклю-
ченного к последовательному каналу свят

DUAL (Diffusing Updale Algorithm — Алгоритм диффузного обновления маршрут-
ной информации) Алгоритм сходимости, используемый в расширенной версии про-
токола IGRP для вычисления маршрута, обеспечивающего свободный от зацикли-
вания процесс передачи трафика в пункт назначения
Duplex (дуплск ный (двусторонний) режим передачи дачньн). Одна из характерис-
тик процесса передачи данных. Существует полнодуплексный (lull-duplex) и полу-
дуплексный (hair duplex) режим передачи данных. Полнодуплексный режим допус-
кает одновременную передачу данных в двух направлениях. В полудуплексном
режиме данные передаются только одним из партнеров по коммуникации.

DVMRP (Distance Vector Multicast Routing Protocol — Протокол дистанционно- вск-
топной многоадресной маршру гилании). Протокол, предназначенный для маршру-
тизации многоадресных дейтаграмм в рамках сетевого комплекса.

Dynamic routing (динамическая маршрутизация). Метод маршрутизации, позволяю-
щий автоматически приспосабливать сетевую топологию к изменениям остевого тра-
фика.

Е

Е1 Цифровой канал передачи данных со скоростью 2, 1)48 Мбит/с (версия CCITT
линии Т1).

EBCDIC {Extended Binary Coded Decimal Interchange Code — Расширенный цвоич-
но-десятичныи код для обмена информацией). Преобразование числовых кодов в
 рафические символы, используемые в мэйнфреймах фирмы IBM, а также в разра-
ботанных фирмой IBM протоколах передачи данных.

Echo (Эхо). (I) Протокол формирования запросов/ответов, входящий в состав стека
протоколов XNS. который используется с целью проверки наличия хоста в сети. (2)
Очин из протоколов семейства AppleTalk, дозволяющий каждому узлу отправлять
дейтаграммы ь атрес любого тругого узла, а также получать при этом отраженную
копию отправленного пакета либо с целью проверки существования хоста назначе-
ния, либо для измерения периода полного обхота. Интерпретируется PI в составе
стека протоколов AppleTalk (3) Протокол, информация которого передается в кад-
ре Net RPC одного из протоколов стека VINES корпорации Banyan Systems

EGP (Exterior Gateway Protocol - Протокол маршрутизации внешнею шлюза). Про-
токол, вхояяшин в состав стека Протоколов TCP/IP, который используется для об-
мена маршрутной информацией между шлюзами, принадлежащими к одном или к
разным системам.

EIA (Electronic Industries Association — Ассоциация электронной промышленности
США). Нормативная организация, специализирующаяся на стандартизации элект-
рических и функциональных харак!еристик интерфейсного оборудования.

EIGRP (Enhanced Interior Gateway Routing Protocol — Улучшенный протокол марш-
рутизации внутреннего шлюза). Расширенная версия протокола IGRP и протоколов
маршрупиании компании Cisco, используемых в стеке TCP/IP и сетевых комплек-
сах OSI.

ELAP См. LAP

Encapsulation (инкапсуляция) Заключение данных в заголовок того или иного про-
токола.
Encryption (шифрование). Применение специальною алгори1ма с целью изменения
внешнего вица данных для тою, чтобы прешл враги)ь несанкционированный дос-
туп к этим данным.

Error (Ошибка). Входящий е состав семейства XNS протокол, посредством которого
рабочая станция сообщаете получении и отбрасывании поврежденного пакета. Ин-
Tcpnpernpvi тся посредством интерпретатора протоколов PI в составе стека прото-
колов XNS.

Error rale (частота появления ошибок). В процессе передачи данных — соотноше-
ние между количеством некорректно переданных элементе и общим количеством
отправленных элементов данных.

ESF (Extended Suprrframe Format — Расширенный суперкадр». Формат кадрирова-
ния Т1 Модификация формата DS1, использующая 193-й бит для передачи сигнала
о возникновении проблем в пинии связи.

Ethernet. Сетевой стандарт, использующий метод доступа к среде CSMA/CD. Пер-
воначально разработан специалистами корпорации Xerox Термин Ethernet анало-
гичен (и часто используется поочередно) термину, обозначающем’ стандарт IEEE
802.3.

Ethenvpe. Код типа протокола, который указывается в одном из полей заголовка
кадра Ethernet длиной 2 байта. Используется несколькими прои шодителями, но
является независимым от стандарта IEEE 802.3.

Event (событие). Сетевое сообщение, указывающее на нарушения в работе физичес-
ких компонентов сети

Expansion (расширение). Выполнение на наборе сжатых данных специального алго-
ритма, восстанавливающего набор данных до ею Первоначальных размерив.

Explorer packet (анализирующий пакет) Пакет, формируемый конечной станцией и
предпринимающий попытки проложить путь через сеть SRB.

Exterior Gateway Protocol (Протокол внешнего шлюза). Межсетевой протокол, ис-
пользуемый для обмена маршру гной информацией между автономными системами

F

Fast Ethernet Технология, включающая в себя любые спецификации Ethernet со ско-
ростью передачи данных 100 Мбит/с, в 10 раз более протводительна, чем специ-
фикация lOBaseT стандарта Ethernet

FC (Frame Control — Управление потоком) В сети Token-Ring — байт DLC, в кото-
ром установлен тип кадра

FCS. См. "Frame Check Sequence".

FDDl (Fiber Distributed Data Interface — Распределенный интерфейс передачи дан-
ных по волоконно-оптическому кабелю). Стандарт ANSI/ISO, специфицирующий
передачу данных в рамках локальной сети по волоконно-оптическому кабелю с ис-
пользованием синхронизированной передачи маркера по деревьям, формирующим
двойное кольцо.
FE (Framing Error — Ошибка кадрирования передаваемых данных) Ошибка, возни-
кающая в результате некорректного кадрирования передаваемых блоков данных. В
процессе асинхронной передачи данных ошибка кадрирования происходит в резуль-
тате расхождения (deviation) значений стопового бита.

FECN (Forward Explicit Congestion Notification — Уведомление о явной перегрузке
при пересылке данных в сетях Frame relay) Пятым бит второго октета заголовка кадра
Frame relay. Используется для информирования абонентского устройства о персгруз-
ке в прямом направлении (по направлению к пункту назначения).

FEP (Front-End Processor — фронтальный процессор) Разработан с целью обеспе-
чения дистанционной передачи данных таким образом, чтобы ресурсы самого ком-
пьютера использовались собственно для обработки данных.

Fiber-optic cable (волоконно-оптический кабель). Кабель, по которому данные пе-
редаются в форме модулированных световых сигналов.

Filter (фильтр). Анализатор протоколов Snifter использует несколько разновиднос-
тей фильтров, в том числе — фильтры захвата (capture fillers), позволяющие опреде-
лить, какой из поступающих кадров анализатор должен отбросить, а какой — оста-
вить. Анализатор Sniffer использует также фильтры вывода на экран (display filters),
позволяющие определить, какие из хранящихся в накопительном буфере кадров
подлежат выводу на экран. Удаление кадра с экрана дисплея посредством фильтра
вывода на дисплеи не означает удаления кадра из памяти.

Firewall (Брандмауэр, аппаратно-пршраммные средства межсетевой зашиты). Сер-
вер доступа или маршрутизатор, назначенный в качестве буферного усзроиства между
сетями общего пользования и конкретной частной сетью. Маршрутизатор, выпол-
няющий роль брандмауэра, обеспечивает защиту частной сети от несанкциониро-
ванного доступа.

Flash update (Mi новенное обновление). Сообщение об обношении маршрутной ин-
формации, передаваемое в асинхронном режиме в ответ на изменения сетевой то-
пологии

Floating static route (плавающий статический маршрут). Статический маршрут, по
которому можно передать данные на большее расстояние, чем по определяемому ди-
намически маршруту. Плавающий статический маршрут может быть откорректиро-
ван с помошью полученной динамическим способом маршрутной информации.

Flooding (потоковая (лавинная) передача трафика). Технология распространения
трафика, используемая мостами и коммутаторами для передачи принятого через один
из интерфейсов трафика по всем интерфейсам устройства, за исключением того, с
которого первоначально поступил трафик.

Flow control (Управление потоком). Аппаратный или программный механизм при-
остановки процесса передачи данных в том случае, если принимающая рабочая стан-
ция не в состоянии сохранить поступающие в се адрес данные из-за ограниченнос-
ти ресурсов. "Управление потоком" — термин, обозначающий различные методы
регулирования потока данных в процессе информационного обмена. Одним из при-
меров управления потоком является использование буферов для временною хране-
ния информации.
Fragmentation (фрагментация) Процедура разоиения пакета данных на более мел-
кие фрагменты при пересылк : пакета по сети, не поддерживающей передачу пакета
исходного размера.

Frame (катр). Многобайтовый модель данных, передаваемый станцией по сети в
процессе одной транзакции Синоним термина "пакет".

Frame Check Sequence, FCS (Контрольная последовательность кадра). В бит-ориен-
тированных протоколах — 16-разрядное поле, присоединяемое в конец кадра и со-
держащее информацию о проверке наличия ошибок в процессе передачи данных.
Frame Relay. Модернизированный протокол доступа к среде передачи, используе-
мый, как правило, для обеспечения процесса взаимодействия между удаленными ло-
га юными сетями.

FRMR (Frame Reject — Отклонение кадра). Ответная команда LLC, указывающая
на то. что полученный ранее кадр имеет неверный формат и отбрасывается по этой
причине. В кадре FRMR длиной 5 байтов содержится объяснение причин отбрасы-
вания полученною ранее кадра.

Front-end processor (Фронтальный процессор). См. FEP

FS (Frame Status — Статус кадра!. Байт, присоединяемый к кадру Token-Ring, сле-
дующий за полем CRC. Содержит биты AR (Address Recognized. Распознавание ад-
реса) и FC (Frame Copied, Копирование кадра).

FTP (File Transfer Protocol — Протокол передачи файлов), (1) Протокол, взаимодей-
ствующий с другими протоколами стека TCP/IP для надежной передачи файлов Ин-
терпретируется посредством интерпретатора протоколов PI стека ТСР/ГР. (2) Пре
токол, информация которого передается в кадре Net RPC одного из протоколов стека
V1NF.S корпорации Banyan Systems.

Tull-duplex mode (полнодуплексный режим передачи данных). Режим одновремен-
ной передачи данных между станцией-отправителем и станцией получателем в обо-
их направлениях

Full Mesh (полная интеграция). Принцип организации топологии сети на основе
полной интеграции (Full Mesh Topology), согласно которому каждый сетевой узел
соединен с каждым из оставшихся узлов сети посредством виртуального или физи-
ческого канала связи

Functional address (функциональный адрес). Ограниченный широковещательный ад-
рес пункта назначения для передачи данных по сетям Token-Ring стандарта IEEE
802.5. Отдельные биты этого адреса специфицируют характеристики, которые дол-
жны иметь станции, имеющие право на прием данною кадра Анало1ичен группо-
вому адресу.

G

Gateway (шлюз). Компьютер, соединяющий различные сети. Как правило, это бы-
вают разнотипные сети. В терминологии TCP/IP шлюзом называется компьютер, со-
единяющий две раздельно администрируемые подсети, которые могут функциони-
ровать либо под управлением одних и тех же сетевых протоколов, либо под
управлением разных протоколов.
GNS (Gel Nearest Server — Установить ближайший сервер). Пакет, передаваемый
по управляемой протоколом IPX сети и содержащий запрос клиента на обнаруже-
ние ближайшего активною сервера заданного типа.

GUI (Graphical User Interface — Графический пользовательский интерфейс) Опе-
рационная система или среда, выводящая опции на экран в виде пиктограмм или
графических изображений.

н

Handshaking (квитирование, подтверждение установления связи). Обмен предвари-
тельно сформированными электрическими сигналами в момент установления соеди-
нения между двумя устройствами, осуществляющими обмен данными. Компьюте-
ры должны "обменяться рукопожатием" посредством установленной процедуры
приветствия партнера по коммуникации.

HDLC (High-Level Data Link Control — Протокол высокого уровня управления ка-
налом передачи данных). Стандартный бит-ориентированный протокол, разработан-
ный Международной организацией по стандартизации (ISO). В заюловке HDLC уп-
равляющая информация всегда размещается на одном и том же месте. Отдельные
комбинации битов, используемые для управления, существенно отличаются от тех
сочетаний значений битов, которые применяются для представления данных, что
позволяет минимизировать количество ошибок при передаче данных Во многих
компаниях, владеющих разветвленными сетевыми комплексами (таких как Cisco и
Vitalink), разработаны версии HDLC, которые являются собственностью этих ком-
пании и распознаются прикладной программой анализа сетевых протоколов Sniffer.
Header (заголовок). Начальный фрагмент сообщения, содержащий в себе IP-адрес
хоста-получателя (destination address), IP-адрес хоста-отправителя (source address),
порядковый номер сообщения (sequence number), а также другие данные. Заголовок
помогает сетевым протоколам корректно направлять сообщение во время его про-
движения по сети. Каждый протокол имеет особый формат заголовка сообщения.
Heartbeat ("сердцебиение”) В Ethernet — сигнал SQE, генерируемый приемопере-
датчиком в конце передаваемого кадра с целью проверки качества передаваемого
сигнала. См. "SQE test".

Нор (транзит, транзитный участок). Термин, используемый в маршрутизации тра-
фика. Транзит — это один канал передачи данных. Путь, сформированный по сети
от источника сообшения до пункта назначения, состоит из ряда транзитных участ-
ков. Каждый транзитный участок имеет свою стоимость, что позволяет вычислить
оптимальный маршрут к пункту назначения (в данном случае — маршрут с наимень-
шей стоимостью).

Hop count (Счетчик транзитов, количество транзитов). Метрика маршрута (metric),
используемая для измерения расстояния между хостом-отправителем сообшения и
пунктом назначения.

Host (хост). Подключенная к сети вычислительная система, функционирующая под
управлением протоколов стека TCP/IP.
Hosi number (номер хоста). Часть IP-адреса, идентифицирующая адресуемый узел
подсети.

Hub (концентратор). Устройство, выполняющее в сети функции концентратора иди
повторителя. Концентратор является центральным пунктом системы монтажных со-
единений, или центральным пунктом выполнения вычислении всели.

I

IARP (Inverse Address Resolution Protocol — Протокол обратного разрешения адре-
сов; Протокол IARP позволяет станнин ретрансляции калров определить протоколь-
ный адрес поданному аппаратному адресу хоста.

ICMP (Internet Control Message Protocol — Протокол управляющих сообщений Ин-
тернета). Протокол, иходчшии в состав стека протоколов TCP/IP и используемый
главным образом для информирования об ошибках, происходящих в процессе пе-
редачи дейтаграмм. Интерпретируется в стеке протоколов TCP/IP.

IEEE (Institute of Electrical and Electronics Engineers, Inc. —Институт инженеров по
электротехнике и электронике) OpiaH стандартизации, основное внимание которого
сосредоточено на разработке программного и аппаратного обеспечения канального
и физического уровней, а также на разработке средств управления локальными вы-
числительными сетями.

IETF (Internet Engineering Task Гогсе — Рабочая iруппа по проектированию сети
Интернет). Рабочая ipvnna, состоящая из более 80 подразделений, в обязанности ко-
торых входит разработка стандартов сети Интернет.

1-Frame, Information Frame (Информационный кадр). Тип кадра LLC, HPLC или
SDLC, используемою для пересылки упорядоченных данных, получение которых
должно быть обязательно подтверждено.

IGMP (Internet Group Management Protocol - Межсетевой протокол управления груп-
пами) Используется для информирования соседних многоадресных маршрут изато-
ров о прннад.‘1ежнис1И ряда хостов сети к одной и гой же i руппе. сформированной
в рамках отдельно взятой локальной сети.

IGP (Interior Gateway Protocol — Протокол внутреннего щяюза). Протокол Интер-
нета, используемый для обмена маршрутной информацией в рамках одной автоном-
ной системы.

IGRP (Interior Gateway Routing Protocol — Протокол маршрутизации внутреннею
шлюза). Протокол маршрутизации компании Cisco, разработанный для маршрути-
зации графика на ограниченном участке глобальной сети, в отличие от протоколов
глобал ьной маршрута за ци и.

Interlace (интсрфсис). (1) Граница соединения между двумя устройствами или сис-
темами (2) Граница сетевого соединения — в маршрутной терминологии. (3) Про-
межуточное устройство коллективного пользования в телефонии. (4) Гранина меж-
ду смежными уровнями в модели OS I.

Internet (Интернет). Самая большая в мире глобальная сеть, объединяющая тысячи
рассредоточенных по всему миру сетей и компьютеров.
Internetwork (сетевой комплекс, интернет). Сетевой комплекс, состоящим из одной
или более локальных сетей, которые взаимодействуют через промежуточны.* устрой
ства под управлением разных протоколов. Сетевой комплекс (internet) не следует
путать с глобальной сетью Интернет (Internet).

Intranet (ин1ранет). Внутренняя сеть организации или компании, работа которой
ба iHpyeiCH на использовании Web-технологий

I/O (Input/Output — Ввод/Вывод). Часть программного обеспечения компьютера,
обеспечивающая прежде всего, передачу информации в центральный процессор или
запоминающее устройство, а также извлечение информации из процессора или за-
поминающего устройства.

IP (Internet Protocol — Протокол Интернета). Протокол нижнего уровня в стеке иро-
токспов TCP/IP, в оолзанности которого входит управление сквозной передачеи па
кетовит хосга-отправителя в пункт назначения, а также фрагментация пакетов, пре-
вышающих допустимый размер Интерпретируется посредством интерпретатора
протоколов в составе стека протоколов TCP/IP. Аналогичный протокол интерпре-
тируется также в стеке протоколов VINES корпорации Ranyan Systems. См. также
IPX и ISO.

IP multicast (многоадресная рассылка в IP). Способ маршру шзации, позволяющий
передавать IP-трафик либо от одного источника в адрес нескольких пунктов назна-
чения, либо от совокупности источников в адрес многих пунктов назначения.

IPX (Internet Packet Exchange — Протокол межсетевого обмена пакетами, Рехчиза-
11т>я фирмы Novell протокола IDP (Internetwork Datagram Protocol, Протокол меж-
сетевого обмена дейтаграммами) компании Xerox. Интерпретируется PI в составе
стека протоколов Novell NetWare.

ISDN (Integrated Services Digital Network — Цифровая сеть с интегральными услуга-
ми). Цифровая технология телефонной сети объединяющая службы передачи зву-
ковых и цифровых ши налов в одном канале

ISL (Inter-Switch L ink — Протокол обслуживания каналов связи межд‘ 1 оммутато-
рами). Протокот компании Cisco, обслуживающий пересылку информации в рам-
ках виртуальной локальной сети (VLAN) на этапе прохождения трафика между ком-
мутаторами и маршрутизаторами.

ISO (International Standards Organization — Международная организация по стандар-
тизации). (1) Консорциум, определяющий стандарты сетевых протоколов. (2, Про-
токолы, стандартизованные ор|анизацией ISO.

ISP (Internet Service Provider — прогаидер уедут сети Интернет) Коммерческая фир-
ма, предоставляющая доступ к службам сеги Интернет компаниям или отдельным
пользователям

ITLI-T (International Telecommunications Union Telecommunication Standardization
Sector — Международны:! союз по телекоммуникациям. Отдел стандартизации).
Международный орган, определяющий мировые ciaiuapiu технологий в области те-
лекоммуникаций.
J-K

Kbps (Kilobits per second — Кбит/с, килобит в секунду). Единица измерения скоро-
сти передачи данных.

Keepahve Interval (Поддержание соединения активным, период). Период времени
между сообщениями, которые отправляет сетевое устройство о поддержании соеди-
нения активным.

Keepalive message (Поддержание соединения активным, сообщение). Сообщение,
передаваемое из одной сети в другую и информирующее о поддержании соедине-
ния между устройствами этих сетей в рабочем состоянии.

LAN (Local Area Network — Локальная вычислительная сеть). Сеть, охватывающая
ограниченную в территориальном плане область и имеющая в своем составе неко-
торое множество компьютеров, объединенных в единую структуру на базе специ-
альною аппаратного и программного обеспечения.

LANE (I AN Emulation — Эму ляция локальных селей) Процедура, позволяющая се-
тям ATM (сетям с асинхронной передачей пакетов) функционировать в качестве ма-
гистральной локальной сети.

LAP (Link Access Protocol — Протокол доступа к каналу связи). Протокол логичес-
кою уровня семейства AppleTalk Существует два варианта протокола LAP: ELAP
(LAP для Ethernet) и LLAP (LAP для сетей LocalTalk). Интерпретируется PI стека
AppleTalk.

LAPB (Link Access Protocol Balanced — Протокол доступа к сбалансированному ка-
налу связи). Сокращенный вариант протокола HDLC.

LAPD (Link Access Protocol-D — Протокол доступа к цифровому каналу связи). Про-
текал управления доступом к цифровым каналам связи, базирующийся на HDLC.
LAT (Local Area Transport — Протокол доступа к терминалу в сетях DECnet). Про-
токол DECnet, управляющий либо передачей терминальною трафика (трафика, пе-
редаваемого от клавиатуры к экрану) в адрес хостов, работающих в режиме разде-
ленного времени, либо приемом трафика от этих хостов

Latency (время ожидания). (1) Период времени между выдачей устройством запроса
на предоставление доступа к сети и получением разрешения на передачу данных.
(2) Называется также задержкой на ввод (insertion delay) — период времени между
получением кадра устройством и моментом времени, кстда кадр может быть отправ-
лен в адрес порта назначения.

Leased line (арендуемая линия). Телефонная линия, арендуемая для эксклюзивного
длительного использования. Как правило, используется с целью соединения удален-
ных локальных сетей. Синоним терминов "leased circuit”, "dedicated circuit” или "leased
channel".

Link (канал). Канал сетевого взаимодействия, состоящий из оборудованного соот-
ветствующим образом пути передачи данных между отравителем и получателем.
Термин, часто используемый в связи с соединением с глобальной сетью.
Link protocol (Протокол канала передачи данных. Протокол канальною уровня).
Набор правил, согласно которым выполняется установка логического канала пере-
дачи данных, а также выполняется сам процесс передачи данных по этому каналу.
В число функций протокола канального уровня входит форматирование данных.

(Link Slate Routing Protocol — Протокол маршрутизации по состоянию каналов свя-
зи). Известен также под названием "Протокол поиска кратчайшего пути". Типич-
ным примером протоколов подобного типа являются протоколы NLSP и OSPI Про-
токолы маршрутизации по состоянию каналов связи поддерживают карты топологии
сети, предлагают более быструю сходимость и отправляют сообщения об обновле-
нии только в случае появления изменений в сети.

LLAP См. LAP

LLC (Logical Link Control — Протокол управления логическим соединением). Про-
токол, обеспечивающий управление установлением соединения и мультиплексиро-
ванием передачи данных в адрес протоколов следующих уровней; специфицирован
стандартами IEEE 802.2 и 1SO/DIS 8802/2.

1 Ml (Local Management Interface — Интерфейс локального управления). Протокол
обмена сигналами о получении доступа к среде передачи, предназначенный для се-
тей с ретрансляцией кадров. LM1 передает информацию о постоянных виртуальных
соединениях между сетью и абонентским устройством. Дополнения к протоколу LM1
могут обеспечивать групповую адресацию (multicasting), ьтобальную адресацию
(global addressing) и управление потоком (flow control).

Load Balancing (выравнивание нагрузки). Способность маршрутизатора равномерно
распределять трафик по всем своим сетевым портам. Эта характеристика маршру-
тизатора способствует повышению производительности полосы частот сети.

Local Explorer Packet (Локальный анализирующий пакет). Пакет, который форми-
руется конечной системой в сети SRB с целью обнаружения хосга, подключенного
к локальному кольцу.

LOOP (Loopback — Протокол диагностики методом обратной петли) Ethernel-npo-
токол, предназначенный для отправки диагностических сигналов с целью получе-
ния соответствующей реакции

LSB (Least Significant Bit — самый младший двоичный разряд). Самый младший (как
правило, крайний справа) разряд двоичною числа.

м

MAC (Medium Access Control — Управление доступом к среде). Подуровень каналь-
ного уровня, отвечающий пересылку кадров управления сетью но сети Token-Ring,
специфицированной стандартом 802.5. Большинство кадров МАС обрабатываются
сетевым адаптером в прозрачном для пользователя режиме.

MAC Address (МАС-адрес). Стандартный адрес любого устройства или порта локаль-
ной сети на канальном уровне. Известен также под названиями "MAC layer address”
(адрес уровня MAC), "hardware address" (аппаратный адрес) или " physical address"
(физический адрес)
MAN (Metropolitan-Area Network — Региональная вычислительная сеть). Сеть, про-
межуточная по масштабу между локальной и глобальной, которая охватывает тер-
риторию, приблизительно равные площади большого города с пригородами
Managed device (управляемое устройство). Сетевое устройство. поддающееся управ-
лению со стороны протокола управления сетью.

Manchester encoding (Манчестерское кодирование). Метод кодирования, объединя-
ющий как данные, так и синхронизирующие сигналы в потоке передаваемых бигов
Переход сигнала к противоположному состоянию в середине разрядною периода
действует в качестве синхронизирующего сигнала.

MAU (Multiple Access Unit — Модуль множественного доступа). И s вест г н также под
названием Medium Attachement Unit” (Устройство подключения к среде). Физичес-
ки подключенный к локальной сети концентратор или приемопередатчик исполь-
зуемый для по'1к.'гючения к среде рабочих сганци.г сети

MB (Megabyte — Мегабайт). Единица измерения объема перетаваемых данных.

.MBps (Megabytes per second — Мбайт/с, мегабайт в секунду). Единица измерения
скорости передачи данных

Mesh (интеграция). Сетевая топология, согласно которой некоторое количество ус-
тройств формирует участок сети, где между всеми узлами установлены взаимные со-
единения

MIC (Media Interface Connector — Интсрфексныи соединитель физического носите-
ля). Соединительная пара волоконно-оптического кабеля, соединяющая носитель с
узлом FDDI или с другим кабелем.

Modem (модем). Устройство, совмещающее функции модулятора и демодулятора
устройство преобразования, устанавливаемое парами на каждом конце аналоговой
линии связи. При передаче данных модем налагает (модулирует) цифровые сигна-
лы компьютера на непрерывную несущую частоту телефонной линии, а при полу-
чении извлекает (демодулирует) информацию из носителя и преобразует ее в циф-
ровой формат, распознаваемый компьютером.

MOP (Maintenance Operations Protocol — Протокол операций по обслуживанию).
Протокол в составе DECnet, используемый для тестирования и диагностики возни-
кающих проблем.

МьВ (Most Significant Bit — самый старший двоичный ра гряд). Самый старший раз-
ряд двоичного числа, не считая знакового разряда.

MTBF (Mean Time Between Failure — Средний период времени между сбоями). Сред-
ний период времени между появлением сбоев в работе устройства.

MTU (Maximum Transmission Unit — Максимальный модуль пересылки). Максималь-
ный размер пакета (в байтах), поддающийся обработке отдельным интерфейсом.

MTU Discovery (Определение MTU). Функция, позволяющая программному обес-
печению определять и применять максимальный размер кадра, которыг позволит
избежать фраг ментаиии кадра.

Multicast message (многоадресное сообщение). Сообщение, направляемое по группе
станций сети или совокупности сетей (в отличие от широковещательного сообще-
ния, направляемого по нсем станциям сети или сетевого комплекса).
Multicast address (групповой адрес). IP-адрес, присвоенный группе хостов сети, по
которому направляется многоадресное сообщение (см. "Multicast message ")

N

s!AK (Negative Acknowledgment — Отрицательное подтверждение) Ответ от полу-
чи геля данных в адрес отравителя, в котором сообшае гея, что сеанс передачи дан-
ных завершился неудачен (другими словами, данные были повреждены в результате
возиiikUohcния ошибок в процессе передачи)

NBMA (Non-Broadcast Multi Access — Нешириковещагельная сеть с множественным
доступом). Сеть с множественным доступом, которая либо нс поддерживает рассылку
широковешпте п>ных сообщений, либо икая рассылка по какой-либо причине не-
выполнима

NCP (NetWare Core Protocol Основной протокол NetWare). Протокол прикладного
уровня компании Novell, предназначенный для обмена командами и данными меж-
ду файловыми серверами и рабочими станциями. Интерпретируется PI стека про-
токолов Novell NetWare.

NDS (Network Directory Services — Служба каталогов сети). Приложение Novell,
которое вместе с NCP обеспечивает управление сетевыми ресурсами

NetBEUI (NetBIOS Basic Extended User Interface — Расширенный базовый пользо-
влельскии интерфейс NetBIOS). Программная спецификация для NetBIOS.

NetBIOS (Network Basic Input/Ouiput System — Сетевая базовая система ввода/вы-
вода). (1) Протокол, реализуемый в виде программного обеспечения персонального
компьютера локальной сети для поддержки взаимодействия компьютера со станци-
ями с присвоенными им символическими именами, а также для обмена данными
между ними. (2) Прыраммныи интерфейс (API), используемый для передачи и при-
ема сообщении NetBIOS. Существует несколько различных, не совместимых между
собой реа 1изации NetBIOS, каждая — со своими API; например, различные реали-
зации NetBIOS входчг в состав стеков протоколов фирм IBM и Novell.

NetWare. Сетевая вычисли re 1ьная система, разработанная корпорацией Novell, а
также используемые в этой системе протоколы.

Network (сеть). Совокупность компьютеров, принтеров, коммутаторов, маршрути-
заторов и других ycrpi nicTB, взаимодействующих между собой через передающую сре-
ду.

Network Address (сетевой адрес). Адрес сетевого ровня, идентифицирующий логи-
ческое сетевое устроиство; известен также как протокольный адрес (protocol address).
Network Laver (Сетевой уровень). Уровень 3 эталонной модели OSI, обеспечиваю-
щий связность ухюв сети (connectivity) и выбор маршрута между двумя конечными
системами.

Network Management (Сетевое шминистрирование). Аппаратно-программные сред-
ства MOHHioptiHia и управления сетевыми ресурсами

Network Management Protocol (Протокол управления сетью). Протокол, осуществ-
ляющий управление объектами. подчиненными NMS (Network Management Station,
Станция управления сетью), с целью устанончения взаимодействия с тентами уп-
равляемых устройств.

Network Topology (гопо кипя сети). Территориальное расположение устройств сети.
В настоящее время самыми распространенными сетевыми топологиями являются
кольцевая (ring), шинная (bus) и звездообразная (star) топологии.

NFS (Network File System — Сетевая файловая система) Протоке г. разрабоганный
корпорацией Sun Microsystems для передачи запросов и ответов между клиентом и
соевым файловым сервером

NLM (NetWare Loadable Module — Загружаемый модуль системы NetWare) Отдель-
ная программа, которая может зшружаться в намято и функционировать как часть
сетевой операционной системы NetWare

NLSP (NetWare Link Services Protocol — Протокол коммуникационных услуг вере-
де NetWare). Протокол маршрутизации по состоянию каналов связи, который улуч-
niaei производительность, надежность, масштабируемость и администрируемосгь
IPX-трафика в крупномасш1абных локально-глобальных сетевых комплексах.

Nodes (узлы). Пункты сети, в которых прогостив 1яется или используется тот и ли
иной сервис или в которых происходит взаимодействие между каналами передачи
данных. Термин "node" (узел) используется наряду с термином "workstation" (рабо-
чая станция).

Non-Local Traffic (нелокальный трафик). Трафик, подлежащий пересылке по раз-
личным локальным сетям.

NOS (Network Operating System — Сетевая операционная система) Термин, отно-
сящийся к распределенным файловым системам.

N(R) (Receive Sequence Number — порядковын номер кадра на приеме). Поле заго-
товка информационною кадра LLC или HDLC. в котором укатывается порядковый
номер кадра, ожидаемою следующим; таким образом, все кадры до N(R) уже неяв-
но подтверждены.

N(S) (Send Sequence Number — порядковый номер передаваемого кадра). Поле за-
готовка информационного кадра I LC или HDLC, в котором указывается порядко-
вый номер кадра, передаваемого по соединению в текущий момент времени
NT1 (Network Termination 1 — Сстевое терминальное устройство I) В сетях ISDN —
устройство, обеспечивающее интерфейс между оборудованием, находящимся в по
мешении клиента. и коммутирующим оборудованием центрального офиса
NTP/SNTP (Network Time Prolocol/Simple Network Time Protocol — Протокоi сете-
вой синхронизации/Упрошенный протокол сетевой синхронизации) Протокол NTP
или SNTP обеспечивает механизмы синхронизации распределения времени в сети
Интернет.

Null Modem Cable (Безмоземныи кабель). Кабель, с двумя разъемами на концах,
контакты которых соезинены перекрестно. Такой кабель, как правило, использует-
ся для соединения зерминальных устройств по схеме "точка-точка”

NVRAM (Non-Volatile RAM — энергонезависимое ОЗУ). ОЗУ. содержимое которо-
го сохраняется при отключении компьютера от cent
О

Octet (октет). Состоящий из восьми Зитов единица измерения информации, сино-
ним зермина "байт"

ODI (Open Data-Link interlace — Открытый интерфейс канального уровня). Специ-
фикация Novell, предоставляющая стандартизованным интерфейс для сетевых ин-
терфейсных плат (NIC, Network Interface Card) и позволяющая множеству протоко-
лов использовать один сетевой адаптер.

OSI (Open Systems Interconnection — Модель взаимодействия открытых систем)
Обобщенная многоуровневая архитектура, стандартизирующая уровни обслужива-
ния и типы взаимодействия устройств обменивающихся информацией через ком-
муникационную сеть.

OSPF (Open Shortest Path Firsl — Алгоритм поиска кратчайшею пути). Алгоритм
маршрутизации по состоянию каналов связи протокола ЮР, предложенный в каче-
стве преемника протокола RIP в сети Интернет.

Overhead (непроизводительные затраты) З-лгроты на передачу информации, кото-
рая обеспечивает выполнение вычислительных процессов, но не является собствен-
но частью полезных данных, только вспомогательной частью процесса передачи
данных.

Packet (пакет). Модуль данных фиксированною размера, передаваемый станцией по
сети Синоним термина 'дейтаграмма" (datagram).

Packet Switching ।коммутация пакетов). Метод пересылки данных в пакетах через сеть
к удаленному пункту назначения. Данные распределяются по отдельным пакетам,
каждый из которых имеет сво.1 собственный идентификатор; в заголовке пакета ука-
зывается IP-адрес хоста назначения. Корректно сформированные пакеты могут пе-
редаваться по разным маршрутам; в пункте назначения выполняется сборка паке-
тов в исходной последовательности по идентификаторам пакетов.

PAD (Packet Assembler Disassembler — Сборшик/разборщик пакетов) Устройство в
сетях с коммутацией пакетов (например, Х.25), которое позволяет асинхронным тер-
минальным устройствам использовать для передачи данных синхронной сети Х.25
посредством пакетирования асинхронного трафика в отдельные пакеты

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

различным несущим частотам одного канала

Parity bit (бит четности) Двоичной разряд, присоединяемый к массиву битов с тем,
чтобы сделать сумму значении разрядов массива всегда чегной или всегда нечетной.
Применяется в процедуре контроля четности с целью обнаружения ошибок в пере-
даваемых двоичных данных.

Parity check (контроль четности). Процедура контроля четности передаваемых датш
ных для сохранения их целостности в процессе передачи данных.	Л
Partial Mesh (частичная интефация) Топология сети, согласно которой часть уст-
ройства сети взаимодействуют в соответствии с принципом полной интеграции (full
mesh), а оставшиеся устройства соединяются только с одним или двумя другими
узлами сети

PAT (Port Address Translation — Трансляция адресов через номера портов). Характе-
ристика продуктов компании Cisco, позволяющая выполнять преобразование част-
ных адресов в зарегистрированные IP-адреса с использованием номеров портов
Patch Panel (коммутационная панель). Устройство, через которое можно установить
временные соединения между входящими и исходящими линиями связи. Использу-
ется для модификации и реконфигурации коммуникационных систем или для под-
соединения тестирующих средств (таких как анализатор сетевых протоколов Sniffer)
к отдельным линиям связи

Path Control Layer (Уровень управления маршрутом). Уровень 3 в иерархической
модели SNA. Поддерживает реализацию служб упорядочивания, обеспечивающих
сборку данных в надлежащем порядке.

Payload (полезная нагрузка). Часть кадра, содержащая информацию верхних уров-
ней (собственно полезные данные).

PC (Personal Computer — персональный компьютер. Общепринятая аббревиатура
для обозначения персонального компьютера.

PDU (Protocol Data Unit — Модуль данных протокола). Данные, доставляемые еди-
ным блоком между равноправными процессами, выполняемыми на различных ком-
пьютерах. Термин OS1, применяемый к пересылке данных на всех уровнях модели
OSI

PDV (Path Delay Value — значение задержки по маршруту). Общее значение перио-
да задержки при полном обходе (round-trip propagation delay) в сети Ethernet.

Physical layer (Физический уровень). Уровень 1 эталонной модели OSL Занимается
механическими и электрическими аспектами поддержания каналов связи между ко-
нечными системами.

Pilot (экспериментальный образец сети). Экспериментальная ("пилотная") сеть — это
упрощенный прототип сети, используемый для демонстрации базовых функции;
часто применяется для сетей небольшого размера

Ping (Packet Internet Groper). Служебная диагностическая программа, входящая в
состав распределенной системы анализатора Sniffer (Distributed Sniffer System) сте-
ка протоколов TCP/IP и определяющая доступность удаленного хоста посредством
передачи эхо-запросов ICMP по конкретному IP-адресу.

Policy Routing (стратегическая маршрутизация). Схема маршрутизации, согласно
которой пакеты передаются на конкретные интерфейсы в соответствии с методи-
кой, сконфигурированной пользователем.

Port (гюрз). Физическая точка доступа к компьютеру, мультиплексору, устройству
или сети, через которую может осуществляться передача или прием ст налов.

РРР (Point-to-Point Protocol — Протокол двухточечной связи) Специфицированный
в RFC 1331 протокол канального уровня, который используется для обеспечения вза-
имодеиствия узлов, соединенных между собой непосредственно через канал связи
(в обход X 25) в» базе протокола HDLC

Pps (Packets per second — пакетов а секунду). Единица измерения пропускной спо-
собности и производительности сетей и сетевых устройств.

Preamble (Преамбула). Фиксированный набор данных, передаваемый в начале каж-
дого кадра для тою, чтобы предоставить получателю возможность выполнить синх-
ронизацию. а также распознать начало кадра

Presentation layer (Уровень представления) Шестой уровень модели OSI (стандарт
ISO 8823). управляющий форматом отображения содержащихся в кадре ынных на
экране, а также форматом файлов Уровень представления контролирует способ
кодирования данных, применение специальной графики и наборов символов, а также
выполняет преобразование данных в совместимый формат.

PRI (Primary Rate Interlace — Интерфейс передачи данных с базовой скоростью).
Интерфейс ISDN, обеспечивающий доступ к среде передачи с базовой скоростью.
Priority Queuing (формирование очереди по приоритету). Метод формирования оче-
реди на доступ к среде передачи. гаран!ирующий выделение полосы частот для пе-
редачи трафика посреди нюм выделения полосы частот на базе типа протокола, но-
мера порта или других критериев. Предоставление доступа по приоритетам имеет
четыре уровня: низкий, обычный, средний и высокий Устройство, расположенное
в очереди с высоким уровнем приори тета, первым получает доступ к среде переда-
чи.

Private Addresses (частные адреса). Зарезервированные IP-адреса, предназначенные
юлько для ьну ।peimeiо Пользования. В число таких адресов входят следующие ад-
реса: 10.0.0.0-10.255.255.255, 172.16.0.0-172 31.255.255 и 192.168.0.0-192.168.255.255.
Process Switching (коммутация (переключение) процессов). Действие, обеспечиваю-
щее высокий уровень производительности каналов передачи данных посредством вы-
равнивания нагрузки при передаче пакетов по параллельным глобальным каналам.
Подобная процедура подразумевает передачу целых кадров по маршруту к централь-
ному процессору, где выполняется повторное пакетирование кадров с целью их
доставки через инирфеис tповальной сети; при этом маршрутизатор выполняет
выбор маршру ia для каждою пакета в отдельности.

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

Protocol Stack (стек протоколов) Набор взаимозависимых коммуникационных про
токопов, функционирующих в комплексе и выполняющих адресацию процесса пе-
редачи данных h i всех семи уровнях эталонной модели OS1.

Prototype (прототип) Прототип сети — это реализация опытного образца сети с це-
лью проверки соответствия структуры сети тем требованиям, которые предъявля-
ются к однотипным сетям белее крупных размеров.

Provisioning (инициализация). Определение типа глобальной сети, в том числе — за-
дпние специфик чти и параметров сети.
Proxy (прокси, посредник). Объект, выполняющий функции другого объекта с пе-
чью обеспечения эффективности процесса передачи данных

Proxy ARP. Prow Address Resolution Protocol (Прокси ARP) Промежуточное устрои-
сгво. отправляющее ответы протокола ARP от имени конечною узла в адрес хоста,
отправившего запрос на разрешение адресов.

PUP (PARC Universal Packet — Универсальный пакет PARC). Гни Ethernet- пакета,
ко юры и использовался ранее корпорацией Xerox в сети исследовательского центра
в Пало Альто (Palo Alto). Кадр данного типа интерпретируется Р1 в стеках протоко-
лов XNS/MS-Net и TCP/IP. но не включается в состав нршраммных средств этих
стеков протоколов, поскольку такой тип кадров больше не используется.

PVC (Permanent Virtual Circuit — Постоянный виртуальный канал) Уникальный пре-
допределенный логический путь между двумя конечными пунктами сети. Исполь-
зуется в техполотн ретрансляции кадров (Frame Relax).

Q

Query (запрос). Сообщение, содержащее запрос о значении переменной н.ли набора
переменных.

Queue (очередь). (1) Список элементов (в порядке очередности), ожидающих обра-
бо!ки. (2) В маршрутизации трафика — совокупность пакетов, ожидающих пересыл-
ки в пункт назначения

QoS (Quality of Service — Качество обслуживания). Мера производите 1ыюсти пере-
дающей системы с учетом обеспечения требуемого качества процесса передачи дан-
ных.

R

RAM (Random Access Memory — Оперативное запоминающее устройство, ОЗУ). За-
поминающее устроново. из которого микропроцессор может считать или куда мо-
жет записать информацию.

RARP (Reverse Address Resolution Protocol — Протокол обратного разрешении адре
сов). Протокол, входящий в состав стека протоколов 1CP/IP и используемый для
определения IP-адреса узла но ею DLC-адресу Интерпретируется Р1 в стеке про-
токолов ГСР/1Р.

Rate Sensitive Traffic (чувствительность графика к скорости передачи данных) Ха-
рактеристика трафика, позволяющая отказаться от своевременности доставки в
пользу скорости передачи.

Reassembly (повюоная сборка). Повторная сборка дейтаграммы в пункте назначе-
ния посте ее фрагментации.

Redistribution (повторное распрос1ранение). Распространение маршрутой инфор-
мации. полученной посредством одною нро|околй маршрутизации, в сообщениях
об обновлении другою протокола маршрутизации

Redundancy (И убыточность, связанная с резервированием). Дублирование устройств,
соединений, сервисов с тем. чтобы в случае сбоя эти устройства. соединения или
сервисы moi.hi выполнять функции вышешшх из строя объектов
REJ (Reject — Отбрасывание кадра). Кадр LLC. запрашивающий повторную пере-
дачу отправленных ранее кадров.

Reliability (надежное!ь). Соотношение ожидаемых и полученных сообщений о под-
держании соединения активным. Если по соотношение имеет высокое значение, ли-
ния связи является надежной

REM (Ring Error Monitor — Диспетчер возникающих в кольце ошибок). Станция в
сети Token-Ring стандарта 802.5, которая принимает от других станций сообщения
об ошибках на уровне МАС

Repeater (повторитель, репитер). Устройство, включенное с определенным интер-
валом в состав сети по всем длине канала связи с целью усиления и восстановления
передаваемого сигнала.

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

RFC (Request For Comment — Запрос на комментарии). Наименование документов,
используемых для поддержки исследовании и разрабо!ки протоколов стека TCP/IP
модели DoD или OS1.

RG-58. Наименование коаксиального кабеля с сопротивлением 50 ом, используе-
мого в сети Cheapemet (Ethernet на базе тонкого коаксиального кабеля).

RG-59. Наименование коаксиального кабеля с сопротивлением 75 ом, используе-
мою в широкополосной локальной сети персональных компьютеров.

RG-62. Наименование коаксиального кабеля с сопротивлением 75 ом, используе-
мого в сети ARCNET.

Rll (Routing Information Indicator — Индикатор маршрутной информации) Если в
первом бите IP-адреса хоста-отправителя кадра Token-Ring установлено значение
I, это значит, что поле данных начинается с маршрутной информации. RI1 интер-
претируется анализатором протоколов Sniffer в сети Token-Ring или Ethernet неза-
висимо от других интерпретаторов протоколов.

Ring (кольцо). Соединение двух или более станций в логическую кольцевую топо-
логию. Информация передастся последовательно от одной активной станции к дру-
гой.

Ring Topology (кольцевая тополотя). Сетевая топология, подразумевающая нали-
чие ряда повторителей, соединенных дру| с другом посредством однонаправленных
каналов передачи данных с целью формирования единого замкнутого контура (single
closed loop) Каждая станция сети с кольцевой топологией подключается к сети че-
рез повторитель. Сети с кольцевой топологией чаше всего формируют так называе-
мую звезду с передачей данных по замкнутому циклу (closed loop star).

RIP (Routing Information Protocol — Протокол маршрутной информации). Протокол,
входящий в стеки протоколов XNS и TCP/IP и используемый для обмена маршрут-
ной информацией между шлюзами. Интерпретируется РТ в стеке XNS и PI в стеке
TCP/IP.

RISC (Reduced Instruction Set Computer — компьютер с сокращенным набором ко-
манд). Тип архитектуры микропроцессора, ориентированный на быстрое и эффек-
тивное выполнение относительно небольшого набора встроенных команд
RJ-45. Наименование 8-жильных модульных соединителей, используемых в сетях
10BASE-T. Аналогичен стандаргному телефонному модульному соединителю (RJ-) 1),
но имеет Солее широкие возможности.

Rlogin (Remote Login — удаленная регистрация). Программа эмуляции терминала,
предлагаемая в большинстве реализации UNIX, которая позволяет выполнять дис-
танционный вход в систему.

RMON MIB (Remote Monitoring Management Information Base — База данных уда-
ленного мониторинга). Использует протокол SNMP и стандартную архитектуру Ml В
для обеспечения возможности взаимодействия между программами мониторинга и
управляющими станциями разных поставщиков.

RNR (Receive Not Ready — Не готов к приему информации). Команда (ответ) LLC
и HDLC, указывающая на то, что процесс передачи данных заблокирован.

ROM (Read-Only Memory — Постоянное запоминающее устройство, ПЗУ). Память,
из которой микропроцессор может считывать информацию, но не может изменять
ее (выполнять запись в ПЗУ).

Route (маршрут). Путь через сетевой комплекс.

Route Sumni । natron (суммирование маршрутов). Объединение нескольких объявлен-
ных в таблице маршрутизации адресов в один адрес. Формирование суммарного мар-
шрутного адреса позволяет сократ1ггь количество маршрутов в таблице маршрути-
зации, а также сократить объем графика информации об обновлении маршрутов, и
в целом — сократить обшие непроизводительные затраты или затраты маршрутиза-
тора.

Routed Protocol (маршрутизируемый протокол). Протокол, который может быть мар-
шрутизирован посредством маршрутизатора. В распоряжении маршрутизируемого
проюкола имеется достаточно адресной информации сетевого уровня, для того чтобы
направить трафик пользователя из одной сети в другую. Маршрутизируемые прото-
колы определяют формат и предназначение полей пакета.

Router (маршрутизатор). Устройство сетевого комплекса, функционирующее на се-
тевом уровне (уровне 3 модели OSI) и осуществляющее передачу данных между раз-
личными объектами сетевого комплекса.

Routing (маршрутизация). Процесс обнаружения пути к хосту назначения. Процесс
маршрутизации можег оказаться достаточно сложным в больших сетях, поскольку
на пути к пункту назначения пакет передается через множество промежуточных
устройств.

Routing Domain (маршрутный домен). Группа конечных и промежуточных систем,
функционирующих пол управзением одного и тою же набора правил управления
маршрутизацией (одного и тою же протокола маршрутизации).

Routing Metric (метрика маршрута). Стандарт измерения характеристик маршрута
(таких, например, как длина пути — path length), используемый алгоритмами мар-
шрутизации в процессе вычисления оптимального пути к пункту назначения. Мет-
рика маршрута хранится в таблице маршрутизации. Метрики маршрутов могут ото-
бражать различные характеристики этих маршрутов: стоимость передачи данных по
тому или иному маршруту (communication cost), ширина полосы частот (bandwidth).
счетчик транзитов (hop count), задержка (delay), стоимость пути (path cost), макси-
мальным модуль пересылки (MTU), и, наконец, надежность (reliability).

Routing Protocol (протокол маршрутизации). Протокол, поддерживающим маршру-
тизируемым протокол, предоставляя в ею распоряжение определеннее механизмы
получения маршрутной информации. Сообщения протоколов маршрутизации пере-
даются между маршрутизаторами Протокол маршрутизации позволяет маршрути-
заторам взаимодействовать с другими маршрутизаторами с целью обновления и об-
служивания таблиц маршрутизации. В сообщениях протоколов маршрутизации не
передается трафик конечного пользователя из одной сети в другую. Протоколы мар-
шрутизации используют маршрутизируемые протоколы для передачи информации
между маршрутизаторами

Routing Table (таблица маршрутизации). Таблица, которая хранится в памяти мар-
шрутизатора пли другого устройства сетевого комплекса с целью отслеживания мар-
шрутов к отдельным пунктам назначения в той или иной локальной сети. Наряду с
собственно маршрутами в таблицах маршрутизации хранятся метрики этих марш-
рутов.

Routing Update (обновление маршрутной информации). Сообщение об обновлении
маршрутной информации, задача которого — определить достижимость сети и свя-
занную с этим стоимость передачи информации. Как правило, сообщение об обнов-
лении маршрутной информации отправляется с одинаковым интервалом времени
сразу после появления изменении в топологии сети

RPC (Remote Procedure Call — Удаленный вызов процедур) Протокол, в обязанно-
сти которою входит активизация функции удаленной станции и получение резуль-
татов в резулыатс выполнения этих функции. Лна готчный протокол существует в
стеке протоко юв XNS корпорации Xerox

RPL (Remote Program Load — Загрузка удаленной программы). Протокол, исполь-
туемыи фирмой IBM веет IEEE 802.5 Token-Ring с целью начальной загрузки про-
грамм на подключенные к сет станции. Интерпретируется Р1 в сгске протоколов
IBM

RPS (Ring Parameter Server — Сервер параметров кольца). Станция в сети Token-
Ring, на которой хранится информация МАС-уроння относительно конфигурации
локальной сети (такая информация, как номера козец и и.1ен1ш|>и каюры местопо-
ложения физических устройств).

RR (Receive Ready — Готой к приему) Нсииформапионныи кадр LLC, отмечающий
факт готовности к приему информации oi друюй станции.

RS232 or RS232C (Recommended Standard 232 or 232С — RS232 или RS232C, Реко-
мендуемый стандарт 232 или 232С). Стандарт EIA. определяющий электрические ха-
рактеристики сигналов, которые передаюпся ио кабе 1ям. соединяющим DTE (Data
Terminal Equipment. Терминальное оборудование) и DCE (Data Communications
Equipment, Оборудование передачи данных)

RTMP (Routing Table Maintenance Protocol — Протокол обслуживания таблиц мар-
шрутизации) Протокол, используемый в сетях AppleTalk для того, чтобы предоста-
вить маршрутизаторам возможное!!.динамически обнаруживать маршру гы к рагчич-
ным локальным сетям соевого комплекса. Узел сети, нс являющийся маршрутиза-
тором, использует сокращенную версию протокола RTMP (R ГМР stribx аля опреде-
ления номера сети, к которой подключен узел, а также для определения идентифи-
каторов маршрутизаторов той сети, в состав ко горой входит данный узел.

S

S or S Frame (Supervisory Frame — Контрочьный кадр). Тип кадра LLC. HDLC или
SDLC, используемого для выполнения контрольных функции.

SABM (Set Asynchronous Balanced Mode — Установить асинхронный сбалансирован-
ный режим передачи данных). Неинфирмационный кадо LLC, содержащий запрос
на установление соединения, по которому будут переданы пронумерованные инфор-
мационные кадры

SABME (Set Asynchronous Balanced Mode (Extended!) — Установигь асинхронный
сбалансированный режим пере гачи данных (расширенный к;ир|). SABM с двумя или
более цополнитечьными байтами в поле управления (Control field). Испочьзустся в
LAPB.

SAC (Single Attachment Concentrator — Концентратор с возможностью подключения
только к одному кольцу TDDI). Концентратор, предлагающим только очин S-порт
для подключения к сеги FDDI и нескольго М-портов для подключения станции к
другим концентраторам.

SAP (1) Service Access Point (Точка доступа к службе). Небольшое число, использу
емое по соглашению или установленное одной из рабочих групп по разоаоотке стан-
дартов, которое определяет формат последующих данных LLC; средство демультип-
лексирования взаимоисключающих протоколов, поддерживаемых LLC. (2) Service
Advertising Protocol (Протокол извещения об уелмах). Используется серверами
NetWare для широковещательной рассылки имен и адресов серверов, а также дщ1
передачи конкретного ответа в адрес любой ciaiiuiiit. отправившей соответствующий
запрос.

SDLC (Synchronous Data Link Control — Протокол синхронною травления переда-
чей данных). Протокол последовательной передачи данных старшего пока 1ения, по-
служившим моделью для разработки протокола LLC и имеющим много общих с этим
протоколом характеристик

Security Management (администрирование мер безопасности). Одна из пяти катего-
рий сетевого администрирования, специфицированных стандартами ISO для адми-
нистрирования сетей OSI. Система администрирования мер безопасност и позволя-
ет управлять предоставлением доступа к разливным сетевым службам

Segment (сегмент) (I) Участок локальной сети, границы которою определяются мар-
шрутизаторами. мостами или коммутаторами (2) В локальных сетях, сформирован
ных на базе шинной топологии, сегмент — ло непрерывная электрическая цепь, во
многих случаях подключенная к другим сегментам посредством повторитечеи (ЗУ В
терминологии TCP сегмент — это единый блок информации, передаваемой ня гране-
портном уровне.
Serial Interface (Прследоввтедшмый интерфейс). Интерфейс, требующий последова-
тельной передачи данных или такой передачи данных, при которой все биты, со-
ставляющие гот или иной символ, передаются последовательно, по одной линии
передачи

Server (сервер). Узел сети, на котором установлена прщрамма управления доступом
ко всей сети или к се части, таким образом сервер формирует ресурсы для компью
юров, функционирующих в качестве клиентов сети.

Session (Сеанс) Название протокола сеансовою уровня из серии протоколов ISO.
Интерпретируется Pi в стеке протоколов ISO.

Session layer (Сеансовый уровень). Уровень 5 эталонной модели OSI, который уп-
равляет установлением, поддержанием и завершением сеансов связи между прило-
жениями, а также управляет обменом данными между объектами уровня представ-
ления.

Shieldeo Cable (экранированный кабель) Кабель, заключенный в специальный изо-
лятор с целью сокращения влияния электромаюитных помех.

Silicon Switching (коммутация на полупроводниках). Тип коммутации пакетов, со-
гласно которому входящий пакет соответствует записи в кэше силиконового ком-
мутирующего процессора,
размещенном в модулях SSE или SSP.

Simplex Transmission (односторонняя (симплексная) передача данных). Возможность
осуществления передачи данных только в одном направлении от станции-отправи-
теля ь адрес принимающей станции.

Single-Route Packet (пакет, направляемый по одному маршруту) Пакет в сети SRB,
который следует к пункту назначения только по одному конкретному маршруту.
Sliding Window Flow Control (механизм скользящих окон для управления потоком).
Метод управления шпиком, согласно которому получатель выдает передающему ус-
тройству разрешение на передачу данных только до тех пор, пока окно не запол-
нится. При заполнении окна передающее устройство должно приог гановпть пере-
дачу данных, пока получатель не сообщит об увечичении размера окна

SLIP (Serial Line Internet Protocol — Межсетевой протокол для последовательного
канала). Стандартный протокол для передачи данных по последовательным прямым
соединениям с использованием других протоколов TCP/IP.

SMB (Server Message Block — Ьлок серверных сообщений). Протокол, определяю-
щий регламент совместного использования файлов компьютерами в локальной сети
и отвечающий за формирование запросов от станции пользователя в адрес сервера
и ответив на эти запросы со стороны сервера. Многие функции SMB аналогичны
функциям, выполняемым прикладными программами на компьютере под управле-
нием операционной системы DOS или OS/2.

SMDS (Switched Multi Megabit Data Service — Служба Mei збитовой коммутации дан
ных). Технология формирования глобальных сетей на базе коммутации пакетов и
пересылки данных в дейтаграммах.

SMT (Station Management — Управление станциями). Протокол, обеспечивающий
управление передачей данных по кольцам IDDI
SMTP (Simple Mail Transfer Protocol — Упрошенный протокол электронной почты).
Протокол, входящий в состав стека протоколов TCP/IP и обеспечивающий надеж-
ный обмен сообщениями электронной почты. Интерпретируется Р1 в стеке прото-
колов TCP/IP.

SNA (1) Systems Network Architecture (Сетевая архитектура вычислительных систем).
Набор протоколов, используемых фирмой IBM для осуществления передачи данных
в сети, главным образом между мэйнфреймами. Интерпретируется PI в стеке про-
токолов IBM. (2) Sniffer Network Analyzer (Анализатор сетевых протоколов Sniffer).
Разработанный компанией Network General сетевой анализатор, функционирующий
в сети с целью мониторинга, записи, анализа и интерпретации процессов передачи
данных по сети. Мониторинг и анализ передачи данных — это две разные опции
анализатора протоколов Sniffer, обеспечивающие высокоуровневый анализ, а также
поиск и локализацию неисправностей в сложных системах локальных и глобальных
сетей.

SNAP (Subnetwork Access Protocol — Протокол доступа к подсетям). Иногда этот
протокол можно встретить под названием ''Subnetwork Access Convergence Protocol”
— Протокол сходимости доступа к подсетям. Расширение протокола LLC стандарта
IEEF. 802.2, предоставляющее станциям возможность использовать для передачи
данных различные протоколы сетевого уровня. Согласно спецификациям этого про-
токола, адреса DSAP и SSAP должны формироваться в шестнадцатеричном форма-
те. Поле, следующее за полем SSAP. идентифицирует один конкретный протокол.
Протокол SNAP интерпретируется PI в стеках протоколов TCP/IP и AppleTalk.

SNMP (Simple Network Management Protocol — Простой протокол управления се-
тью). Сетевой протокол, разработанный для сбора отчетной информации, инфор
мации о конфигурации и данных о производительности с помощью администрато-
ров и агентов SNMP. Интерпретируется в стеке протоколов TCP/IP.

SNRM (Set Normal Response Mode — Установить обычный режим формирования
ответов). Неинформационный кадр SDLC, посредством которого на второстепен-
ной станции устанавливается такой режим, который предотвращает отправление с
данной станции невостребованных кадров. Управление всем потоком сообщений вы-
полняет основная рабочая станция.

SNRME (Set Normal Response Mode [Extended] — Установить обычный режим фор
мирования ответов [расширенный кадр|). SNRM с двумя дополнительными байта-
ми в иоле управления (Control field). Используется в SDLC.

Socket (соке-i). Логически адресуемый объект или сервис узла, который служит для
более точной идентификации отправителя или получателя.

Source Address (адрес хоста-огправителя). Часть сообщения, идентифицирующая от-
правителя сообшения.

Spanning Tree (связующее дерево). Метод создания свободной от образования мар-
шрутных петель логической топологии расширенной локальной сети. Формирова-
ние топологии связующего дерева для передачи сообщений через мосты базируется
на принятом в сфере сетевых технологий стандартном алгоритме формирования свя-
зующих деревьев, специфицированном в стандарте IEEE 8O2.id.
Sp.inning-Тгее Algonihm (Алгорн1М связующего дерева). Алгоритм. используемый для
создания связующею дерена.

Spanning-Tree Protocol (Протокол связующего черева). Мостовой протокол, реали-
зующий алгоритм связующего дерева, что позволяет обучающемуся мосту в шна-
мическом режиме обрабатывать образование петель в сетевой топологии посредством
создания связующего дерева Для обнаружения петель мосты обмениваются сооб-
щениями BPDU с другими мостами.

SPT (Shortest Path First — Алгоритм выбора кратчайшего пути). Алгоритм маршру-
пгзацни. выполняющий повторное вычисление глины пути с целью формирования
связующего дерева кратчайшего пути к пункту назначения.

SPIFJ (Service Profile Identifier — И 1ентифнкатор профиля службы). Число, исполь-
зуемое некогорыми поставщиками сетевых услуг для идентификапни сервисов, ко-
горые абонирует устронство ISDN

Split Horizon (Ограничение поля видимости). Правило маршрутизации. согласно
которому маршрутизатор не имеет права передавать маршрутную информацию по
ceiи через тот же интерфейс, через контрый информация была подучена.

SPX (Scqueniial Packet Exchange — Протокол последовательного обмена пакетами).
Разработанная фирмои Novell версия протокола SPP компании Xerox Интерпрети-
руется PI в щеке протоколов Novell NetWare.

SQE (Signal Quality Гrror — Ошибка в качестве сигнала) Cm нал приемопередатчи-
ка о возникновении конфликта в сети 802.3/Elhcmet.

SQI Test (Тестрование качества сигнала). Сигнал SQE. формируемый нриемопе-
редагчиком в конце переливаемого кадра с целью тестирования цени SQE (форми-
рование подобного сигнала известно в Ethernet под названием "сердцебиение,
heartbeat ”).

SQL (Structured Querv Language — Язык сгрук1хрированных запросов). Использует-
ся для получения доступа к базам данных

SQL Server (сервер SQL) Сервер, распознающий язык структурированных запросов
SQL.

SR/TLB (Source-Route Translational Bridging — Мостовое соединение с трансляцией
между протоколами отправителя и получателя). Метод мостового соединения, со-
i таено которому станции на маршруте от источника могу г взаимодействовать в про-
зрачном режиме с шумя зругими станциями, подключенными через промежугоч-
ныи мост, осуществляющий трансляцию между двумя промежуточными
протоколами.

SSAP (Source Service Access Point — Точка доступа к службе отправителя). SAP по-
дуровня LLC для протокола, используемого станцией-источником сообщения.

SSE (Silicon Switching Engine — Механизм коммутации на полупроводниках) Ме-
ханизм коммутации и маршрутизации сравнивающий «головок входящего пакета
на канальном или сетевом уровне с записью в кзше силиконового коммутирующею
процессора; таким образом определяется приемлемое в данном случае действие и
выполняется передача пакет на подходящий интерфейс. Посредством такого меха-
низма можно выполняп» коммз (ацию без вовлечения системного процессора.


Г пессарии	32/

SSP (I) (Silicon Switch Processor —силиконовый коммутирующий процессор) Высо-
копроизводительный полупроводниковый коммутатор, обе |уживаюшии серию мар-
шрутизаторов Cisco 7000 и обеспечивающий распределенную обработку и управле-
ние функционированием интерфейсных процессоров. (2) (Switch-to-switch Protocol —
Межкоммутаторныи протокол). Протокол, специфицированный стандартом DLSw,
который используется маршрутизаторами для установления DLSw-соединении, для
передачи данных в пункт назначения, локализации ресурсов и устранения ошибок.
S/T Interface (Интерфейс S/Т). В сетях ISDN — соединение между интерфейсом BRI
и устройством NTI.

Static Route (статический маршрут). Однозначно сконфшурированный маршрут,
внесенный в таблицу маршрутизации.

Store and Forward Packet Switching (коммутация пакетов по метолу "сохранить и пе-
редать"). Метод коммутации пакетов, согласно которому кадры полностью буфери-
зуются и обрабатываются перед их пересылкой в пункт назначения через надлежа-
щий порт. Такой метод коммутации пакетов предполагает вычисление алюритма
CRC и проверку правильности адреса пункта назначения Мосты и коммутаторы,
использующие этот метод, выполняют проверку кадра перед ею дальнейшим про-
движением по сети. Если кадр оказывается поврежденным, он не передается даль-
ше. Устройства, выполняющие коммутацию пакетов по методу "сохранить и пере-
дать", изолируют домены, в которых возникают конфликты.

STP (Shielded Twisted Pair — экранированная витая пара) Кабель, состоящий из двух
проводников и образующий правильную спираль, который используется во многих
сетевых реализациях. См. также другое значение термина STP — "Spanning-Tree
Protocol".

Stub Area (Тупиковая область). Область OSPF. через которую проходи i маршрут по
умолчанию, а также внутриобластные и межобластные маршруты, но через эту об
ласть не проходят внешние маршруты (маршруты между автономными областями).
Slub Network (Тупиковая сеть). Часть сетевого комплекса, доступ к которой можно
получить только по одному маршруту.

SUA (Stored Upstream Address — сохранений адрес восходящею соединения). Сете-
вой адрес соседнего по отношению к станции Token Ring устройства, распо южен-
ного в направлении, противоположном основному трафику. 13 Texas Instruments эют
адрес имеет название UNA (Upstream Neighbor Address).

Subinterface (подинтерфейс). Один из ряда виртуальных интерфейсов, расположен-
ных на одном физическом интерфейсе.

Subnet (подсеть). Термин, который используется для обозначения любой сетевой тех-
нологии, позволяющей соединить все узлы сети таким образом, чтобы казалось, что
все они находятся на расстоянии в один транзитный участок от миною у ыа. Дру
гимн словами, пользователь подсети может осуществлять непосредственное нтаимо-
действие со всеми узлами данной подсети. Совокупность подсетей, объединенных в
одно целое на сетевом уровне под управлением одного протокола маршрути танин,
образует локальную сеть.
Subnet Address (адрес подсети). Часть IP-адреса, идентифицируемая как адрес под-
сети посредством маски подсети (subnet mask).

Subnet Mask (маска подсети) 32-разрядное число, сопоставленное с определенным
IP-адресом Каждый разряд в маске подсети указывает на способ интерпретации со-
ответствующего разряда в IP-адресе.

SVC (Switched Virtual Circuit — коммутируемый виртуальный канал). Виртуальный
канал, устанавливаемый по требованию (как в случае с коммутируемой телефонной
линией связи или вызовом Х.25).

Switch (I) (коммутатор). Сетевое ус!ройство, которое выполняет фильтрацию, пе-
ресылку непосредственно в пункт назначения или потоковую рассылку пакетов на
основе IP-адреса хоста-получателя каждого кадра. (2) (переключатель). Электрон-
ное или механическое устройство, которое устанавливает соединение в случае не-
обходимости. а также разрывает соединение в случае, если нет необходимости в
поддержании сеанса связи.

Symptom (симптом). Аварийное или непредусмотренное событие в сети, которое
указывает на возможное возникновение проблемы

SYN (Synchronized — флаг синхронизации). (1) Бит синхронизации в сегменте TCP,
используемый для указания на то, чго данный сегмент является сегментом синхро-
низации SYN. (2) Первый отправляемый протоколом TCP сегмент, используемый с
целью синхронизации действий партнеров по коммуникации в процессе подготов-
ки к установлению соединения.

Synchronous Transmission (синхронная передача). Метод передачи данных, согласно
которому данные передаются блоками (кадрами) битов через рапные интервалы вре-
мени.

Syslog Служба, принимающая сообщения либо от выполняющихся на локальных
хостах приложений. либо от удаленных хостов, сконфигурированных с целью про-
движения сообщений по сети.

т

TI. Канал передачи цифровых данных, поддерживающий скорость I, 544 Мбит/с.
ТЗ. Канал передачи цифровых данных, поддерживающий скорость 44. 736 Мбиз/с.
ТА (Terminal Adapter — герминальный адаптер). Адаптер, обеспечивающий внеш-
нее соединение от персонального компьютера к другому устройству.

TACACS (Terminal Access Controller Access Control System — Система управления
доступом с использованием контроллера доступа к терминалам). Идентификацион-
ный протокол, обеспечивающий аутентификацию удаленного доступа, а также со-
ответствующие службы, например, регистрация событий (event logging). В процессе
аутентификации используются пароли пользователей.

TCP (Transmission Control Protocol — Протокол управления передачей данных). Ори
визированный на соединение протокол, входящий в состав стека протоколов ТСР/
IP и обеспечивающий надежную сквозную передачу данных с использованием ме-
ханизма упорядочивания передаваемого поюка данных
TCP/IP (Transmission Control Protocol/lnternet Protocol — Протокол передачи дан-
ных/Протокол Интернета). Стек сетевых протоколов, первоначально разработанный
для правительственной сети США (ARPANET) и используемый в настоящее время
несколькими производителями аппаратного и программною обеспечения для локаль-
ных вычислительных сетей. Протоколы, входящие в стек протоколов TCP/IP, пере-
числяются в данном глоссарии отдельно.

Telnet. Протокол виртуальною терминала, входящий в состав стека протоколов ТСР/
1Р и позволяющий подключаться к терминалу удаленного хоста и работать с ним
как с локальным терминалом. Интерпретируется в стеке протоколов TCP/IP.

Terminal (терминальное, оконечное устройство). Простое устройство (например,
компьютер), посредством которого можно выполнять передачу данных по сети или
получение данных из нее.

Terminator (терминатор). Резистор, подключенный к каждому концу кабеля с целью
предотвращения влияния помех на передаваемый сигнал.

TFTP (Trivial File Transfer Protocol — Простейший протокол пересылки файлов).
Протокол, входящим в состав стека протоколов TCP/IP и используемый для обмена
файлами между подключенными к сети станциями. Интерпретируется Р1 в стеке про-
токолов TCP/IP.

Throughput (производительность, пропускная способность) Объем данных, переда-
ваемых между узлами сети за единицу времени (обычно — за секунду).

ТНТ (Token Holding Timer — таймер удержания маркера). Максимальный период
времени, на протяжении которого удерживающая маркер станция может иниции-
ровать асинхронную передачу данных по кольцу Начальное значение таймера ТНТ
соответствует разности между временем получения таймера станцией и TTRT
(FDDI).

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

Token Bus (эстафетная магистраль). Тип локальной сети, в которой все станции мо-
гут прослушивать информацию, передаваемую другими станциями и в которой раз-
решение на передачу данных в форме маркера передается от станции к станции в
заданном порядке.

Token-Ring. Локальная сеть с кольцевой топологией, согласно которой каждая стан-
ция может непосредственно прослушивать передаваемую ближайшим соседом ин-
формацию. Разрешение на передачу станция получает вместе с приемом циркули-
рующего по кольцу маркера.

Topology (топология). Физическое расположение узлов сети и каналов передачи дан-
ных между ними в рамках сетевой структуры предприятия.

ToS (Type of Service — Тип обслуживания). Поле заголовка дейтаграммы IP. в кото-
ром указывается способ обработки передаваемой дейтаграммы

Traffic Shaping (формирование трафика). Использование очередей для ограничения
переполнения сети трафиком. Данные заносятся в буфер для временного храпения,
а затем передаются из буфера в сеть регулируемыми обз.емами; такой способ пере-
дачи сетевого трафика гарантирует вмещаемость фрагмента i рафика в те границы,
которые позволят передать ею по данному соединению.

Transparent Bridging (прозрачное мостовое сопряжение устройств сети). Схема со-
пряжения устройств сети, согласно которой кадры передаются через мосты на рас-
стояние в один транзитный участок за один раз на основе информации, хранящей-
ся в таблицах соответствия межах конечными узлами и портами мостов Часто
используется в сети Ethernet

Transport Layer (Транспортный уровень). Уровень 4 эталонной модели OSI. в обя-
занности которого входит обеспечение надежных сетевых транспортных коммуни
каций между конечными ухтами На транспортном уровне реализуется механизм
управления потоком и устранения ошибок Транспортный уровень часто использу-
ет виртуальные каналы связи для обеспечения надежной доставки данных в пункт
назначения

Trap (сообщение Trap). Невостребованное сообщение, отправляемое агентом SNMP
в адрес станпии управления сетью <NMS) консоли и ж терминала, которое содер-
жит уведомление о том. что произошло важное событие.

Tree Topology (древовидная топология). Топология сети, аналогичная шинной то-
ПО.ТО1ИН Сети с древовидной тополотей состоят из сегментов с множеством узлов.
TSR (Terminate and Stay Resident — резидентная программа). DOS-программа, ко-
торая посте начальной зафузки в ОЗУ остается в оперативной памяти в фоновом
режиме до тех пор. пока она не будет выведена из ОЗУ или пока устройство не бу-
дст отключено оз электрической сети.

TEL (Time to Live — Время жизни) Поле заюловка IP, в котором указывается, на
протяжении какою периода времени пакет считается достоверным.

Tunneling (тонеллирование). Архитектура, обеспечивающая виртуальное соединение
для канала передачи данных между двумя однотипными сетями через сеть, функци-
онирующую под управлением другого протокола.

Twisted Pair (витая пара). Физический носитель канала передачи данных с относи-
тельно низкой скоростью, состоящий из двух изолированных проводов, скрученных
вместе. Провода, из которых состоит витая пара, moivt быть экранированными или
неэкранированными

и

UA (Unnumbered Acknowledgment — непронумерованное подтверждение). Кадр LLC,
подтверждающим предшествующий запрос SABME или DISC.

UDP (User Datagram Protocol — Протокол (передачи) пользовательских дейтаграмм).
Не ориентированный на установление соединения протокол, входяшии в состав стека
протоколов TCP/IP и предназначенный для выполнения передачи неупорядоченных
кадров данных, которые в прошвном случае нс интерпретируются в TCP/IP

UI (Unnumbered Information — непронумерованные данные). Тип кадра LLC HDLC
или SDLC, используемого для передачи данных без присвоения порядковых номе-
ров.
U Interlace (U-илтерфеис) Соединение между устройством NT1 и сетью ISDN
UNA (Upstream Neighboi Address — адрес соседа по кольцу в восходящем направле-
нии). Сетевой адрес соседнего по отношению к станции Т >ken- Ring устройства, рас-
положенною в направлении, противоположном основному трафику. В IBM имеет
название SUA yStored Upstream Address)

UNI (User-to-Network interface — интерфейс “пользователь— геть”). Спецификация
форума ATM, определяющая стандартный интерфейс взаимодействия между распо-
ложенными в локальной сети продуктами Al М, которые базируются на технологии,
и ЛТМ-коммутаторами, расположенными в ооычных телефонных сетях.

Un’cast (одноадресное сообщение). Сообщение, отправляемое в один пункт назна-
чения в сети.

Unicast Address (адрес одноадресною сообщения). Адрес, идентифицирующий сете-
вое устройство, которое является конечным пунктом назначения одноадресного со-
общения

UNIX Широко респрошраненная переносимая операционная система, разработан-
ная AT&T

Utilization (коэффициент использования) Процент от обшей производительности
сегмента сети.

UTP (Unshielded Twisted Pair — неэкранированпая витая пара) Четырехжильный
кабель, исполыуемыи во мнотих сетях. Неэкранированная витая пара не требует на-
личия фиксированных промежутков между соединениями.

V

V	.24. Стандарт Международною тслекомму никационного союза (ITU-T) тля интер-
фейсов физического уровня между терминальным оборудованием (DTE) и обору-
дованием передачи данных (DCE)

V	25bis Спецификация ITU-T, в которой представлено описание механизмов уста-
новления и завершения вызова процедур через интерфейс DT E-DCE в сетях с ком-
мутацией пакетов (PSDN. Packet Switched Data Network)

V	.32. Спепифинированныи ITU-T стандартный протокол для последовательного ка-
нала. предназначенный для осуществления чвунапрааленной передачи данных.

V	.32bis. Спепифицированнын 1TU-T стандарт, расширяющий возможности V.32 до
скорости 14 400 Кбит/сек.

V	.34. Ct iHjtupi ITU-T, в котором специфицирован протокол последовательного ка-
нала.

V	.35. Широкополосный интерфейс, рекомендованный CCI ГТ для применения в гло-
бальных сетях

VC (Virtual Circuit — виртуальный канал). Лотческий канал передачи данных, раз-
работанный с целый обеспечения надежной передачи данных между двумя устрой-
ствами сети. Вирпадьныи канал может быть либо постоянным, либо коммутируе-
мым, он попользуется в технологиях Frame Relay и X 25. В технологи ATM
виртуальные каналы hochi название "virtual channels”.
VINES (Virtual Network Software — Программное обеспечение виртуальной сети).
Сетевая 1 псрационная система, разработанная корпорацией Banyan Svstems а так-
же используемые в ней протоколы. Особого упоминания заслуживают такие компо-
ненты VINFS, как SireeiTalk и Net RPC.

Virtual Circuit (виртуальный канал). Канал передачи данных, выполняющий функ-
ции выделенною соединения типа "точка-точка".

VLAN (Virtual LAN — виртуальная Л ВС). Логическое, а не физическое объединение
устройств в одну tpvnny. Устройства группируются посредством применения про-
грамм управления коммутацией (switch management software) с тем, чтобы они име-
ли возможность взаимодействовать между робой гак, будто они подключены к од-
ному кабелю, в то время как фактически эти устройства могут быть расположены в
разных физических сегментах локальной сети.

VLSM (Variable Length Subnet Mask — Маска сети переменной длины) Возможность
определять различные маски подсети для одного и того же номера сети в разных под-
сетях VLSM способствует оптимизации использования доступного адресною про-
странства

(Virtual Private Network — виртуальная частная есть). Позвишез передавать 1Р-тра-
фнк по общей cei и под управлением TCP/IP без угрозы получения к этом_, трафику
несанкционированного доступа посредством шифрования данных при передаче из
одной фокальной сети в другую Для шифрования всей информации, передаваемой
на уровне протокола IP, в VPN исполь. тется процедура тонеллирования.

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

W

WAN (Wide Area Network — глобальная сеть). Совокупность локальных сетей, или
станций и хостов, рассредоточенных на обширной территории, которые могут быть
соединены либо физическими носителями общественною пользования, либо част-
ными линиями. Как правило, скорость передачи данных по глобальным сетям мень-
ше. чем по локальным сетчм

WFQ (Weighted Fair Queuing — формирование очереди по принципу взвешенной
равной доступности ресурсов). Метол формирования очередей, согласно которому
приоритет о|дае.ся менее насыщенному трафику перед Оолее насыщенным с тем,
чтобы выровнять время ответа на запросы с выполнении приложений конспектив-
но! о пользования.

Wildcard Mask (маска с использованием группового символа). 32-разрядное значе-
ние, используемое в связи с IP-адресом для того, чтоб определить, какие разряды
IP-адреса следует проигнорировать при сравнении этого адреса с другим 1Р-алре-
сом. Маска с использованием группового символа специфицируется в момент фор-
мирования списков дос гуле.

Window (окно). Количество cei ментов данных, которые отправителю разрешается
передавать без получения подшержтения.
Windowing (механизм формирования окон) Механизм контроля над объемом пере-
даваемой между конечными устройствами информации посредством формирования
окон различных размеров.

WINS (Windows Internet Naming Service — Служба имен сети Интернет для Windows).
Предоставляет клиентам в различных IP-подсетях возможность динамически реги-
стрироваться в сети и просматривать доступные сетевые ресурсы без использования
широковещательных рассылок.

Workgroup (рабочая группа). Совокупность рабочих станций и серверов локальной
сети, сформированная для обеспечения взаимодействия и обмена данными в рам-
ках группы.

WWW (World Wide Web — "Всемирная паутина", Web). Большая сеть Интернет-сер-
веров, обеспечивающая передачу гипертекстов и других служб на терминальные ус-
троЯства, выполняющие клиентские приложения.

WWW browser (браузер WWW) Клиентская прикладная программа, которая базиру-
ется на использовании графического пользовательского интерфейса и предназначе-
на для предоставления клиентам доступа к гипертекстовым документам, а также
другие службы, расположенные на рассредоточенных по всему миру удаленных сер-
верах.

X—Y

Х.25. Рекомендованный CCITT стандарт, специфицирующий стандаршый комму-
никационнып интерфейс для получения доступа к сетям с коммутацией пакетов.

XID (Exchange Identification — Идентификация обмена). Непронумерованный кадр
LLC, применяемый для согласования использования тех или иных служб LLC во
время соединения.

XNS (Xerox Network Systems — Сетевые системы Xerox). Стек протоколов, стандар-
тизованный компанией Xerox; особо следует выделить Транспортные протоколы Ин-
тернета (Internet Transport Protocols), входящие в состав этого стека протоколов.

X Window. Протокол, предназначенный для управления формированием на рабо-
чих станциях цветных окон с высокой разрешающей способностью. Разработан ком-
паниями MIT, DLC и IBM; впоследствии права на этот протокол переданы консор-
циуму поставщиков и производителей.

Z

ZIP (Zone Information Protocol — Протокол зональной информации). Используется
в стеке протоколов AppleTalk для обслуживания процедуры отображения локальных
сетей на имена зон в которых они находятся. Протокол ZIP используется в работе
протокола NBP (Name Binding Protocol, Протокол связывания имен) с целью опре-
деления. какие сети входят в состав данной зоны. Интерпретируется PI в стеке про-
токолов TCP/IP

Zone (зона). В сетях AppleTalk — набор из одного или более узлов сетевою комп-
лекса.
Приложение Е

Ответы на вопросы

Глава 1

I.	Основное предназначение эталонной модели OS1 — обеспечение независимой от
посгавшиков аппаратною и программного обеспечения платформы для осуществ-
ления коммуникаций между различными хостами локальной сети, а также между
локальными сетями в рамках глобальной сети. Такая единая платформа позволяет
однотипным и разнотипным протоколам, оборудованию, операционным сетям и
сетевым архитектурам сосуществовать и осуществлять успешное взаимодействие.

2.	Управление коммуникационным диалогом (полнодуплексным и полудуплексным)
межту различными службами осуществляется на сеансовом уровне модели OSI.

3.	Обработка ошибок и управление информационным потоком выполняется на транс-
портном уровне. Надежность доставки данных в пункт назначения зависит от того,
каткой протокол транспортного уровня при этом используется. Например, протокол
TCP гарантирует надежную доставку данных, но при этом теряется скорость. С дру-
гой стороны, протокол UDP обеспечивает высокую скорость передачи данных, но
не гарантирует надежность доставки

4.	Процедура коммутации выполняется на уровне 2 модели OSI (канальном уровне).
Именно на этом уровне в процесс передачи данных вовлекаются коммутаторы и
мосты, которые используют адреса уровня 2 (МАС-адреса) для принятия решений о
дальнейшем продвижении данных.

5.	Протоколы IP и ICMP функционируют на сетевом уровне модели OSI.

6.	Модель DoD состоит из следующих четырех уровней: уровень процесс/приложение,
межхостовый уровень, уровень Интернета, уровень доступа к сети

7.	В число функций подуровня МАС канального уровня входит вычисление алгоритма
CRC и проверка целостности данных согласно вычисленному значению, а также
обеспечение доступа к среде передачи.

8.	Протокол UDP транспортного уровня не ориентирован на установление соедине-
ния.

Глава 2

I.	Существуют следующие классы IP-адресов и диапазоны их значений: класс А (1-127),
класс В (128-191). класс С (192-223), класс D (224-239), класс Е (240-247)
2.	Маски подсетей позволяют определить, является ли хост назначения локальным (в
этом случае хост-отправитель имеет возможность самостоятельно выполнить доставку
дейтаграммы в пункт назначения) или хост назначения расположен в другой локаль-
ной сети (в таком случае хост-отправитель должен передать дейтаграмму для даль-
нейшего продвижения в адрес шлюза). Для определения локальности хоста-получа-
теля по отношению к хосту-отправителю сравнивается маска подсети
хоста-отправителя с IP-адресом хоста назначения. Такое сравнение выполняется
посредством процедуры побитового применения операции & (эта процедура позво-
)яет определить ту часть адресного поля IP-адреса хоста-получателя, которая соот-
ветствует адресу сети).

3.	Адрес сети и адрес узла — это составные части общего адресного поля — сетевого
адреса хоста Сетевой адрес — это 32-разрядный IP-адрес хоста, который может бьпь
присвоен тому ичи иному хосту вручную или динамическим способом.

4.	Некоторые IP-адреса запрещено присваивать в общем порядке. Например, адрес
255.255.255.255 присвоен для рассылки широковещательных сообщений по всем уз-
там или по всем сетям сетевого комплекса. IP-адрес 0.0.0.0 используется в случае,
когда неизвестен IP-адрес хоста пли сети назначения; адрес 0.0.0.0 идентифицирует
либо адюз по умолчанию, либо последний на пути к сети назначения шлюз. IP-ад-
рес 127.0.0.1 используется для внутреннею петлевого тестирования. В общем порядке
не присваиваются также адреса, выделенные для частною использования. Частные
IP-адреса применяются в большинстве случаев с целью оптимальной реализации
схемы IP-адресаиии в рамках сети какой-либо компании, однако такие адреса нельзя
использовать в сети Интернет. Для того чтобы частные адреса были доступны для
внешнего — по отношению к сети компании — применения, необходимо выполнить
трансляцию этих адресов в зарегистрированные IP-адреса. Частные адреса могут вы-
деляться из следующих диапазонов адресов. 10.0.0.0—10.255.255.255. 172.16.0.0—
172.31.255.255, 192.168.0.0-192.168.255.255

5.	В IP-адресе класса С для обозначения идентификатора сети выделяется 8 разрядов
адресного поля.

6.	В сети 193.1 1.0 с маской подсети 255.255.255 240 можно выделить 14 подсетей и 14
хостов.

7.	IP-адресу 193.1.1.32 с адресом подсети /28 соответствует маска подсети
255.255.255.224

8	Если маска подсети — 255.255.254.0, то в данной локальной сети можно выделить
126 подсетей и 510 хостов.

9.	Если в составе сети класса С необходимо иметь 19 хостов, то из той части адресного
поля, которая соо)ветствует идентификаюрам хостов, нужно выделить 5 разрядов.

10.	Если в составе сети класса В необходимо иметь 1000 хостов, из той части адресного
поля, которая соответствует идентификаторам хостов, требуется выделить 10 разря-
дов (точное количество хостов в этом случае равно 1022).

11	Двоичному числу 10110111 соответствует десятичное число 182 (128+32+16+4+2+1)

12.	Десятичному значению маски подсети 201 соответствует двоичное число 11001001
(128+64+8+1)
Глава 3

1.	За фрагментацию и сборку дейта! рамм отвечает протокол IP сетевого уровня.

2.	Для проверки наличия связи между двумя удаленными хостами пользователь запус-
кает утилит» Ping; сам процесс проверки осуществляется посредством следующих
сообщении протокола ICMP: эхо-заироса (тип 8) и эхо-ответа (mil 0).

3.	После получения данных от протокола TCP или UDP протокол IP пакетирует эти
данные в дейтаграммы, включив в заголовок дейтаграммы адреса хоста-отправите-
ля и хоста-получателя на сетевом уровне (IP-адреса).

4.	Минимальная длина заголовка IP — 20 байтов, еслр ь состав полей заголовка не
включено поле дополнительных параметров Заголовок JP состоит из следующих по-
тей:

•	Поле версии протокола (Version),

•	Поле длины заголовка (Header Length);

•	Плте типа обслуживания ( Type of Service);

•	Поле общей длины (Total Length);

•	Поле идентификации (Identification);

•	Поле флаюв (Flags);

•	Поле смещения фрагментов (Fragment offset);

•	Поле времени жизни (Time to Live);

•	Поле протокола (Protocol),

•	Поле IP-адреса отправителя (Source Address);

•	Поле IP-адреса получателя (Destination Address).

Эти поля составляют 20 байтов заголовка IР1: к основном части зш оловка присоеди-
няется в случае необходимост поле пополнительных параметров 'Options), а затем
следуют собственно данные

5.	Биты поля типа обслуживания (ToS) используются приложениями для того, чтооы
специфицировав требуемый для пересылки дейтаграмм уровень обслуживания в
процессе маршрутизации трафика.

6.	Для сборки дейтаграмм в правильной последовательности хост-пол та гель исполь-
зует значения поля идентификации (Identification) и поля смещения фрагмента
(Fragment OITset)

7.	Сообщение "Недостижимый хост назначения” соответствует типу 3 сообщений ICMP
Смысл этого сообщения состоит в гом, что либо запрашиваемая сеть назначения (хост
или порт) находится на слишком большом (превышающем максимально допустимое)
расстоянии, либо эта сеть (хост или порт) является недостижимой.

8	Смысл сообщения об ошибке, имеющего код 0 и относящегося к типу 3 сообщений
ICMP, состоит в том. что хост является недостижимым, поскольку требуется фраг-
ментация дейтаграммы, а значение бига DF (Don't Fragment^. Не фрагментировать)
установлено некорректно.
9.	Сообщение об ошибке, имеющее кол 4 и относящееся к типу 3 сообщении ICMP,
состоит в том, что запрашиваемый хост является недостижимым

10.	Сообщение ‘Время превышено" соответствует типу 11 сообщений ICMP. Смысл этого
сообщения состоит в том. что значение таймера TTL истекло (достигло нулевой
отметки)

Глава 4

1.	Протокол ARP выполняет преобразование логических адресов сетевого уровня в co-
ot вост вуюшие им аппаратные адреса канальною уровня. Разрешение адресов про-
токолом ARP выполняется на базе широковещательных рассылок.

2.	Протокол RARP выполняет преобразование аппараюых адресов канального уровня
в ло1ические адреса сетевого уровня Протокол RARP используется конечными ус-
тройствами с целью получения от сервера RARP соответствующих IP-адресов и кон-
фигурационных параметров. Запросы на разрешение адресов и ответы на них пере-
даются в широковещательной рассылке.

3.	Протокол ВООТР стал преемником протокола RARF Основное отличие между про-
токолами ВООЗ Р и RARP состоит в следующем: шлюзы и агенты-посредники не
имеют возможности передавать запросы и ответь. RARP. но могут передавать зап
росы и отвпы ВООЗ Р.

4	Основное отличие между протоколами DHCP и ВООТР сошоит в юм, ч то возмож-
ности протокола DHCP не ограничива отся применением только статической таб
липы отображения адресов. Протокол DHCP может поддерживать как статическое,
так и динамическое отображение адресов.

5.	В зависимости от конкретной реализации протокола ARP, для внесения изменений
в ARP-таблицы могут быть испильювдны следующие механизмы:

•	Конфигурируемый в оперативной памяти таймер ARP контролирующий период
времени, по истечении которого следует заменить запись об определенных дина-
мическим способом адресных данных.

•	Одноадресный опрос хоста-получателя по поводу имеющегося у хоста-отправи-
теля аппаратного адреса получателя.

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

6.	Использование прокси ARP позволяет устройству, такому как шлюз, отвечать на
ARP-запросы от имени удаленного хоста.

7.	Значение, устанавливаемое в поле кода сообщения (Opcode) заголовка ARP или
RARP, определяет тип выполняемой протоколом ARP или RARP операции.

8.	Когда хост предпринимав! попытку установить взаимодействие е удаленным ycipoii-
ством, он сравнивает IP-адрес хоста-получателя с локальной маской подсети хоста-
отправителя Такое сравнение позволяет определить, входи’ .лц хосг назначения в
состав того же сегмента локальной сеги, что и хост-отправитель данных. Если пункт
назначения находится в той же подсети, хост-отправитель может отправить по всем
хостам данной подсети локальным широковещательный ARP-запрос на разрешение
IP-адреса хоста-получателя (другими словами, выполнить процедуру "shouting"). В
противном случае хост-отправитель должен отправить локальный широковещатель-
ный ARP-запрос на определение аппаратною адреса шлюза (выполнить процедуру
"routing"), через который дейтаграммы будут в дальнейшем передаваться в пункты
назначения, находящиеся за рамками данной локдц.нои сети.

10. Четырехэтапный процесс конфигурирования клиента DHCP в сети выполняется
посредством обмена между клиентом и сервером DHCP сообщениями следующих
типов: поиск (Discover), предложение (ОГГег). запрос (Request) и подтверждение
(АСК).

Глава 5

1 Существуют следующие способы маршрутизации, результатом применения которых
является создание таблиц маршрутизации:

•	Непосредственное сопряжение маршру гизатора с сетью назначения через сетевой
интерфейс (Directly connected interface).

•	Статическая маршрутизация (Static routing).

•	Маршрутизация по умолчанию (Default routing).

•	Динамическая маршрутизация (Dynamic routing)

2.	Статической маршрутизации свойственны следующие характеристики.

•	Ручной ввод администратором в таблицу маршрутизации каждого маршрута

•	Отсутствие связанного с обновлением маршрутов графика.

•	Максимальное соответствие требованиям к маршрутизации трафика по соедине-
ниям типа "точка-точка" в глобальных сетях или в сетях с выделением каналов
связи по требованию.

•	Возможность использования резервного маршрута в случае повреждения исход-
ною маршрута.

•	Связанная с необходимостью поддержания всей таблицы маршрутизации неэф-
фективность.

•	Большой объем непроизводительных административных затрат.

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

3.	Динамической маршрутизации свойственны следующие характеристики

•	Определение маршрутов посредством рассылки широковешатезьных сообщений

•	Маршрутизация по классам адресов (в сообщения об обновлении не включаются
маски подсетей).

•	Контроль над передачей сообщений об обновлении маршрутной информации с
помощью специально сконфшурированных таймеров.

•	Передача всей таблицы маршрутизации независимо oi наличия тменении в то-
пологии сети
•	Возможность образования маршрутных петель.

•	Ограничение диаметра с< ти максимальным расстоянием, на которое может быть
передан трафик.

•	Использование количества транзитов в качестве метрики маршрута.

•	Оптимальность реализации для маршрутизации трафика в сетях небольшого и
среднего размера.

4	Статическую маршрутизацию целесообразно применять для маршру гизации трафи-
ка в небольших сетях или по каналам связи типа ’’точка-точка". Кроме того, приме-
нение статической маршрут и гации мЬфекгивно, если возникает необходимость в ми-
ними>ации объема трафика обновления маршрутной информации. Динамической
маршрутизации следует отдавать предпочтение, коша возникает необходимость в ав-
томатическом обн (ружении новых и восстановлении поврежденных каналов связи
или маршрутов.

5.	Маршрутизация по умолчанию предусматривает использование маршрута по умол-
чанию в случае, когда к пункту назначения не существует дру>их маршрутов.

6.	Каждый протокол динамической маршрутизации можно отнести к одной из катего-
рии: протокол внутреннего шлюза (1GР, interior Gateway Protocol) и протокол внеш-
него шлюза (EGP, Exterior Gateway Protocol).

7.	К категории IGP относятся следующие протоколы: RIPvl. RIP v2, IGRP, EIGRP и
OSPF.

8	Дистанционно-векторные прогоколы маршрутизации, такие как RIPvl, RIPv2 и
IGRP. оценивают наилучший путь к пункту назначения по стоимости этого пути,
измеряемому в количестве транзитов (hops) В основу работы этих протоколов по-
ложен дистанционно-векторный алгоритм Как правило, прогоколы данной катего-
рии используют в своей работе только широковещательные рассылки, хотя прото-
кол RIPv2 поддерживает также и многоадресные рассылки.

9.	Для вычисления оптимальною маршрута дистанционно-вякторные протоколы ис-
пользуют количество транзитов на нуги к пункту назначения. Протокол RIP специ-
фицирует максимальное расстояние, на которое может быть передана дейтаграмма,
равным 15 транзитам, протокол IGRP — равным 255 транзитам

10.	Для предотвращения образования маршру гных петель дистанционно-векторные про-
токолы маршрутизации используют следующие механизмы: подсчет транзитов до
предельного значения (count to infinity}, подавление изменений (holddown), ограни-
чение поля видимости (split horizon) и неприменимость обратного маршрута (poison
reverse).

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

•	Производительность полосы пропускания (bandwidth);

•	Задержка (delay),

•	Надежность (reliability);

•	Нагрузка (load);

•	Максимальный модуль пересылки (MTU, maximum transmission unit)
13.	Протоколам маршрутизации по состоянию каналов связи свойственны следующие
хараыеристикн:

•	Рассылка многоадресных сообщении (multicasts).

•	Тршгерное обновление (triggered updates).

•	Бесклассовая маршрутизация (classless routing).

•	Обеспечение заданного в заюловке IP тина сервиса (ToS, Type of service) и каче
ства сервиса (QoS, Quality of service)

•	Целесообразность применения в средних и больших сетях.

•	Большой объема времени, памяти и других ресурсов, расходуемых центральным
процессором для сбора и обработки маршрутной информации

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

Глава 6

1.	Протокол R1P является протоколом маршрутизации внутреннего шлюза (IGP) и от-
носится к категории дистанционно-векторных протоколов маршрутизации.

2.	Протокоту RIP свойственны следующие основные характеристики:

•	Протоко । R1P функционирует на основе широковещательных рассылок.

•	Протокол R1P принадлежит к категории протоколов IGP.

•	Применение протокола RIP наиболее эффективно для маршрутизации графика в
средних сетях.

•	Протокол RIP — это дистанционно-век горный протокол маршрутизации.

3.	Для вычисления оптимального пути протокол RIP использует расстояние до пункта
назначения, измеряемое в количестве транзитов

4.	Протокол RIP отправляет свою таблицу маршрутизации в широковещательных со-
общениях. рассылаемых каждые 30 секунд.

5.	В своем широковещательном сообщении протокол RIP может передавать до 25 за-
писей таблицы маршрутизации

6.	Согласно протоколу RIPv I дейтаграмма может пересечь не более 15 транзитов, если
пункт назначения считается недостижимым.

7	Протоколу RIPv2 свойственны следующие характеристики, которые не свойствен-
ны протоколу RIPvl: многоадресная рассылка сообщений (multicast), аутентифика-
ция (authentication) и бесклассовая маршрутизация (classless routing), другими сло-
вами — использование масок сети переменной длины (VLSM)

8.	Протокол R)Pv2 является обратно совместимым с RIPvl, а это значит, что RIPv2
может выполняться на шлюзах, обслуживающих RIPvl. Однако дзя того чтобы шлю-
зы RIPvl и шлюзы RlPv2 могли обмениваться информацией, они должны исполь-
зовать общие характеристики, которые свойственны обеим версиям протокола RIP:
только широковещательные рассылки сообщений, отсутствие аутентификации и мар-
шрутизация по классам адресов; а это не позволяет в полной мере испольтови1ь
преимущества RIPv2 С другом стороны, в настоящее время более широкое распро-
странение получают протоколы маршрутизации по состоянию каналов связи, кото-
рые обеспечивают оптимальные методы маршрутизации трафика в пункт назначе-
ния.

9.	Протоколу- RIPv2 свойственны следующие недостатки:

•	Работа протокола RIP построена на основе широковещательных рассылок, что
приводит к генерированию избыточного трафика в сети.

•	В процессе обновления маршрутной информации протокол RIP отправляет всю
таблицу маршрутизации, даже если в нее не внесены никакие изменения.

•	Поскольку обновление маршрутной информации контролируется специальными
таимервмн синхронизации, протокол RIP обеспечивает медленную сходимость
(процесс соыташения между маршрутизаторами по поводу оптимального марш-
рута)

•	Протокол RIP предусматривает ограничение максимального расстояния до пун-
кта назначения 15 транзитами.

•	В процессе маршрути мции трафика под управлением протокола RIP существует
большая вероятность образования маршрутных петель.

•	Протокол R1P относится к категории протоколов маршрутизации по к 1ассам ад-
ресов (Classful routing protocol); следовательно. RIPv I не поддерживает VLSM (мас-
ки адреса переменном длины).

10.	Для предотвращения образования маршрутных петель протокол RIP использует сле-
дующие механизмы: подсчет транзитов до предельного значения (count to infinity),
подавление изменений (holddown), ограничение ноля видимости (spin horizon) и не-
применимость образного маршрута (poison reverse).

II.	Для обеспечения временной синхронизации при обновлении маршрутной инфор
мании протокол R1P использует три таймера таймер периодического обновления
(periodic update tinier), таймер обнаружения нерабочих маршрутов (invalid timer) и
таймер временного подавления изменений (holddown timer).

12.	Протокол OSPF является протоколом маршрутизации внутреннего шлюза (IGP) и
относится к категории протоколов маршрутизации по состоянию каналов связи

13.	Протокол OSPF принимает решения с выборе маршрута на основании следующих
показателей:

•	Производительность полосы пропускания канала связи (bandwidth capacity of а
link);

•	Нагрузка (load.».

•	Ml (J, Максимальный модуль пересылки (maximum transmission unit);

•	Надежность (reliability);

•	Задержка (delay)

14.	Протокол OSPF имеет следующие преимущества по сравнению с протоколом RIP:

•	Способность кинсЬиглрироввния иерархических маршру гных доменов (hierarchical
routing domains).
•	Способност ь быстро адаптироваться к происходящим во время межсетевого об-
мена маршрутной информацией изменениям.

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

•	Поддержка работы больших сетей.

•	Поддержка выравнивания нагрузки (load balancing).

•	Обеспечение аутентификации (authentication) процесса обмена маршрутной ин-
формацией.

•	Поддержка маски подсети (VLSM. Variable Length Subnet Mask — маска подсети
переменной длины).

•	Использование многоадресных рассылок сообщений об обновлении маршрутной
информации.

15.	Протоколу OSPF свойственны следующие характеристики:

•	Многоадресная рассылка сообщений (multicast).

•	Быстрая сходимость (fast convergence).

•	Триггерное обновление маршрутной информации (triggered updates)

•	Бесклассовая маршрутизация (classless routing).

•	Обеспечения типа сервиса (ToS) и ih качества сервиса (QoS) в процессе маршру-
тизации графика.

•	Поддержка аутентификации (authentication).

•	Использование эквивалентных и неэквивалентных по стоимости маршрутов
(equal- and unequal-cost routes).

•	Использование одной или нескольких областей (areas).

16.	Маршрутизаторы OSPF создают и используют для маршрутизации графика следую-
щие типы баз данных-

•	База данных для хранения снедений о смежных маршрутизаюрах (Adjacency
database) — другими словами, таблица сведении о соседях (neighbor table).

•	База данных для хранения сведений о состоянии каналов связи (Link-slate database)
— другими словами, карта топологии области OSPF (topology map).

•	База данных для хранения маршрутной информации о передаче данных в пункт
назначения (Forwarding database) — другими словами, таблица маршрутизации
(routing table).

17.	База данных OSPF для хранения сведений о смежных маршрутизаторах — эю фак-
тически таблица маршрутных сведений о соседних устройствах. Сели отношения
смежности между соседними устройствами не сформированы маршрутизатором, про-
цесс обмена информацией между этими устройствами невозможен

18.	База данных OSPF для хранения снедении о состоянии каналов связи — это полная
карта топологии сетевого комплекса.
19.	База данных OSPF для хранения маршрутной информации о передаче данных в пункт
назначения — это локальная таблица маршрутизации, в которой содержатся сведе-
ния об оптимальных маршру i ах для продвижения трафика в ipe6veMi.in пункт на-
значения.

20.	LSA (Link State Adverticement) — эю сообщения о состоянии каналов связи, кото-
рые используются протоколом OSPF в процессе формирования базы данных для хра-
нения сведений о состоянии каналов связи с цетыо осуществления процесса пере-
дачи данных либо в рамках области OSPF, либо за ес рамками

2I.	Внутриобластные объявления OSPF (Inlra-Area Advertisements) отправляются мар-
шрута шторами OSPF только в адрес маршрутизаторов находящихся в пределах от-
дельной области OSPF межобластные объявления (Inter-Area Advertisements) OSPF
передаются маршрута заторам и границы области (ABR) в адрес маршр,Лгизаторов, рас-
положенных за пределами данной области. в других областях OSPF, которые непос-
редственно сопряжены сданной областью.

22.	Маршрутизатор OSPF должен пройти несколько этапов подготовки к участию в про-
цессе маршрутизации На каждой стадии такой подштовки маршрутизаторы OSPF
находятся в одном из следующих состояний:

1.	Пассивное состояние (Down state),

2.	Состояние инициализации (Init state);

3.	Состояние двусторонней связи (Two-Way state);

4.	Предстартовое состояние (Exstart state);

5.	Состояние обмена (Exchange state);

6.	Состояние загрузки (Loading state);

7.	Состояние готовности (Full state).

23.	Существует четыре следующих типа маршрутизаторов OSPF:

•	Внутренний маршрутизатор (internal router);

•	Маршрутизатор базовой области (backbone router);

•	Маршрутизатор |рани области (ABR area border router);

•	Маршрутизатор границы автономной системы (ASBR, Autonomous system boundary'
router)

24 Базовая область (backbone area, тип 0) является связующим звеном между всеми ос-
тальными областями автономной системы. Кроме всех внутриобластных объявлении,
распространяемых в самой базовой об lacru, все межиб!асгные итоговые объявле-
ния (отправляемые маршрутизаторами грани области. ABR), и объявления внешней
автономной системы (отправляемые маршрутизаторами |раницы AC, ASER) пере-
секают область I' на пути к подобластям. Базовая область может принимать объяв-
ления LSA типов 1 — 5.

25.	Существует пять типов пакетов OSPF:

•	Приветственный пакет (Hello packet, тип I),

•	Пакет, содержащий описание содержимого балы данных (Database Description
packet, тип 2);
•	Пакет, содержащий запрос о состоянии канала связи (Link-state Request packet,
гии 3);

•	Пакет, содержащий корректировки состояния канала связи (Link-state Update
packet, тип 4):

•	Пакет, содержащий подтверждение о состоянии канала (Link-state
Acknowledgement packet, тип 5).

26.	Приветственный пакет протокола OSPF устанавливает и поддерживает отношения
смежности между соседними устройствами.

27.	В пакете, содержащем описание базы данных, передается содержимое этой базы дан-
ных.

28.	Протокол IGRP принимает решения о выборе маршрутов на основании совокупно-
сти следующих показателей:

•	Полоса пропускания канала связи (bandwidth);

*	Задержка (delay);

•	Надежность (reliability);

•	Нагрузка (load);

•	Счетчик транзитов (hop count).

29.	Максимальное значение счетчика транзитов (255), устанавливаемое протоколом
IGRP, позволяет этому протоколу поддерживать маршрутизацию в сетях большего
по сравнению с друшми протоколами размер?.

30.	Протокол IGRP использует в процессе маршрутизации следующие таймеры:

•	Таймер обновления (Update timer). Определяет интервал между отправленными
сообщениями об обновлении маршрутной информации. По умолчанию этот ин-
тервал равен 90 секундам.

•	Таймер обнаружения нерабочих маршрутов (Invalid timer). Задает период време-
ни, в течение которого маршрутизатор должен ожидать получения сообщения об
обновлении. Значение этого периода времени ио умолчанию равно 270 секундам.

•	Таймер временного подавления изменений (Holddown timer). Задает период вре-
мени, в течение которого подавляются любые изменения, касающиеся объявлен-
ного недостижимым пункта назначения. По умолчанию значение данного таймера
равно 280 секундам.

•	Таймер исключения маршрута из таблицы маршрутизации (Flush). Задает период
времени, по истечении которого нерабочий маршрут удаляется из таблицы мар-
шрутизации. Значение по умолчанию — 630 секунд.

31.	Протоколу EIGRP свойственны следующие характеристики, отличающие его от дру-
। их протоколов маршрутизации:

•	Обеспечение более быстрой по сравнению с другими протоколами маршрутиза-
ции сходимости (convergence) посредством триггерной рассылки сообщений об об-
новлении маршрутной информации.

•	Поддержка VLSM и включение маски подсети в сообщения об обновлении.
•	Поддержка ряда протоколов, включая IP. IPX и протоколы стека протоколов
AppleTalk

•	Храпение резервных маршрутов в таблице Маршрутизации EIGRP.

•	Поддержка маршрутизации сотласно требованиям уровня обслуживания, задан-
ным в поле ToS заголовка IP

•	Использование для обнаружения оптимальных маршрутов (так же как и в случае
IGRP) метрик, вычисленных на основе стоимости маршрутов к пунктам назна-
чения.

•	Использование резервных путей при наличии множес1ва маршрутов к пункту
назначения.

•	Поддержка как многоадресной, так и одноадресной рассылки сообщений об об-
новлении маршрутной информации.

32.	Протокол E1GRP считается сбалансированным протоколом смешанного типа
(balanced hybrid protocol), поскольку в нем обьединены преимущества дистанцион-
но-векторных протоколов маршрутизации и протоколов маршрутизации но состоя
нию каналов связи.

33.	Способность протокола EIGRP поддерживать ряд протоколов важна для компаний,
использующих различные протоколы, такие как IPX. IP и стек протоколов AppleTalk.
В противном случае этим компаниям потребовалось бы применять по одному от-
дельному протоколу маршрутизации на каждым из указанных выше протоколов, что
существенно увеличило бы объем трафика обновления, генерируемою в процессе
обнаружения и эксплуатации маршрутов Единственный недостаток протокола
EIGRP заключается в том, что для ею реализации требуется использование только
маршрутизаторов компании Cisco, за исключением случаен, когда маршрутизаторы
других сторонних ирон (водителей поддерживают протокол EIGRP.

34.	Протокол EIGRP может хранить в таблице маршрутизации несколько маршрутов к
одному пункту н< значения. Оптимальный маршрут (т.е. маршрут с самой низкой
стоимостью, которая ио умолчанию вычислена на основе показателей полосы про-
пускания и задержки) определяется в качестве преемника (successor). Следующий
по стоимости (резервный) маршрут обозначается как потенциальный преемник
^feasible successor).

35.	Существует пять типов пакетов EIGRP:

•	Приветственные пакеты/Пакеты-подтнерждения (Hrllo/ACK packets) — пакеты,
содержащие приветственные сообшения (Hello) ияи подтверждения приема ин-
формации (АСКЕ

•	Пакеты обновления (Update packets) — пакеты, содержащие сообшения об обнов-
лении маршрутной информации (Updates).

•	Пакеты, содержащие обращения к соседям rQacry packets) о предоставлении ими
маршрутных сведений

•	Ответные пакеты (Reph packets) — пакеты, содержащие ответы (Replies) на по-
лученные обращения (Queries) о предоставлении маршрутной информации.
•	Пакеты, содержащие запросы (Request packets) на предоставление исчерпываю-
щего списка всех маршрутов к пунктам назначения, необходимого для построе-
ния таблицы маршрутизации.

36.	Протоколы категории EGP (например, протокол BGP) выполняют посредством своих
маршрутизаторов обнаружение и обработку данных обо всех сетях назначения, ко-
торые находятся в Интернете, а также информацию о маршруте, пролегающем че-
рез автономные системы и позволяющем передать трафик в эти сети. Протоколы
категории 1GP (такие как RIP, IGRP, EIGRP и OSPF) продолжают контролировать
процесс локальной маршрутизации в автономной системе даже после достижения
трафиком удаленной сети назначения.

37.	Протокол BGPv4 стал основным протоколом маршрутизации, используемым в сети
Интернет, благодаря следующим расширениям:

•	Поддержка бесклассовой маршрутизации (включение VLSM в сообщения об об-
новлении).

•	Аггрегирование маршрутов (объединение нескольких маршрутов в один).

•	Поддержка бесклассовой междоменной маршрутизации (CIDR).

38.	Реализация протокола BGP целесообразна в следующих случаях:

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

•	Если, с одной стороны, существует множество путей к разным Интернет-провай-
дерам, а с другой стороны, вам необходимо самостоятельно ретулировать переда-
чу трафика по этим каналам.

•	Если существует необходимость в более интеллектуальном выборе пути к пункту
назначения на основе особых критериев.

•	Если инфраструктура той или иной сеги используется в качестве транзитного
участка для передачи трафика других организаций.

39.	Отличия в топологии сетей под управлением BGP в случае полной и частичной ин-
теграции заключаются в следующем. Тополоигя сети на основе полной интеграции
(full-mesh topology) требует наличия соединений TCP между всеми маршрутизато-
рами BGP, входящими в состав одной автономной системы, что позволяет шлюзам
быстро обнаруживать маршрутные петли и удалять их. Топология сети на основе
частичной интеграции (partial mesh topology) не требует от маршрутизаторов BGP
поддержки логического соединения друг с другом. Это сокращает количество соеди-
нений TCP, но открывает возможность образования маршрутных петель.

40.	В сети, функционирующей под управлением протокола BGP, существует четыре типа
маршрута заторов:

•	Маршрутизаторы — спикеры BGP (BGP speaker routers);

•	Равноправные, или соседние маршрутизаторы (peer or neighbor routers);

•	Внутренние равноправные маршрутизаторы (internal peer routers);

•	Внешние равноправные маршрутизаторы (external peer routers).
41.	Независимо от того, с какой таблицей работай спикер BGP, он должен иметь воз-
можность дифференцировать полученную информацию последующим категориям:
• Информация об обновлении маршрутов (т.е. корректировки):

•	Маршрутная информация, подлежащая передаче другим маршрутизаторам;

•	Локальная таблица маршрутизации протокола BGP.

42.	Протокол BGP функционирует на базе протокола TCP.

43.	Существует следующих четыре типа сообщений BGP:

•	Первичное сообщение (Open message);

•	Сообщение об обновлении (Update message);

•	Сообщение, содержащее уведомление об ошибке (Notification message);

•	Сообщение о поддержании соединения активным (Keepalive message).

44.	Первичное сообщение BGP (тип 1) инициирует формирование равноправных отно-
шений между внутренними и внешними равноправными маршрутизаторами.

45.	Сообшения BGP, содержащие уведомления об ошибках (тин 3), генерируются мар-
шрутизаторами BGP в случае возникновения ошибок в процессе маршрутизации.
Сообщения BGP данного типа вызывают завершение сеанса TCP.

46.	Для определения оптимального маршрута протока'! BGP использует такой показа-
тель, как атрибуты пути (path attributes)

47.	Атрибуты пути BGP подразделяются на следующие категории:

•	Общеизвестный обязательный (well-known mandatory);

•	Общеизвестный необязательный (well-known discretionary);

•	Дополнительный транзитивный (optional transitive);

•	Дополнительный незранзитивный (optional nontransitive)

48.	Атрибут локального предпочтения применяется только маршрутизаторами, входящи-
ми в состав одной автономной системы, и не передается в другие автономные сис-
темы. Если существует несколько путей для передачи трафика за пределы данной
автономной системы, входящие в ее состав маршрутизаторы могут установить для
одного из путей более высокое значение атрибута локального предпочтения по срав-
нению со значениями других путей, указывая тем самым на предпоч гительный мар-
шрут. Внутренние маршрутизаторы осуществляют дальнейшую передачу трафика на
основе этой информации, а именно — посредством выбора пути с наивысшим зна-
чением атрибута локального предпочтения.

49	Между протоколами BGPv4 и BGPv3 существуют следующие различия. Протокол
BGPv4 поддерживает VLSM, суммирование маршрутов и атрибут локального пред-
почтения, в то время как протокол BGPv3 не поддерживает указанных возможнос-
тей. Протокол BGPv4 поддерживает топологию сети как с полной, так и с частич-
ной интеграцией, протокол BGPv3 поддерживает только полную интеграцию.
Глава 7

1.	1 ранспорт.тый/межхостовын уровень предоставляет следующие сервисы:

•	Управление сквозной передачей данных (end-to-end communication) между двумя
процессами, выполняемыми на различных хост компьютерах.

•	Предоставление верхним уровням ориентированных или не ориентированных на
создание соединения сервисов.

•	Идентификация процессов, выполняемых на хост-компьютере, по IP-адресам и
номерам портов сервера и клиента.

•	Разоиение данных на сегменты для обработки полученных сегментов приложе-
ниями верхнего уровня.

2.	Всем ориентированным на установление соединения протоколам свойственны сле-
дующие характеристики:

•	Установление сеанса связи (session setup)

•	Завершение сеанса связи (session teardown);

•	Формирование подтверждений (acknowledgements, АСК);

•	Упорядочивание данных (sequencing);

•	Управление потоком (flow control);

•	Поддержа me соединения активным (keepalive);

•	Надежная доставка данных (reliable delivery):

•	Более медленная (по сравнению с не ориентированными на соединение прото-
колами) доставка данных (slow delivery);

•	Большой объем непроизводительных затрат (overhead);

•	Устранение ошибок {error recovery) и повторная передача данных (retransmission
of data).

3.	Общеизвестные r.opibi серверов (well-known) относятся к известным промышленным
программам; являются официальным стандартом адресации таких программ Диа-
пазон номеров общеизвестных портов — от 0 до 255.

4.	Менее известные порты серверов (диапазон номеров — от 256 до 1023) — это заре-
зервированные порты, которые могут быть реализованы по мере возникновения не-
обходимости.

5.	Порты для приложений клиентов (диапазон номеров от 1024 до 65536) — это изме-
няемые порты, номера которым назначаются оперативно каждый раз, когда начи-
нает выполняться приложение клиента и открывается новый порт.

6.	IP-адрес клиента и порт с динамически назначаемым номером, а также IP-атрис хо-
ста-получателя вместе с общеизвестным портом сервера составляют пару сокетов
(socket pair). Такая пара сокетов образует сквозное соединение между двумя хоста-
ми (отправителем и получателем), в котором задействованы соответствующие IP-
адреса и порты. Пары сокетов однозначно идентифицируют процессы, вступающие
во взаимодействие с каждой стороны.
7.	Протокол UDP (не ориентированный на соединение протокол) предлагает быстрый,
но ненадежный обмен сообщениями между приложениями, выполняемыми на уда-
ленных хостах. Протокол TCP (ориентированный на соединение протокол) гаран-
тирует надежную доставку данных между двумя конечными системами.

8.	Управление потоком (flow control) — это механизм, позволяющий хосту-получате-
лю согласовать с хостом-отправителем вопрос о замедлении или полном прекраще-
нии процесса передачи данных.

9.	При принятии решения о реализации того или иного протокола транспортного уров-
ня поставщики сетевых услуг стоят перед дилеммой: что предпочесть — скорость
(протокол UDP) или надежность (протокол TCP), которой сопутствуют непроизво-
дительные затраты.

10.	Процедуры формирования подтверждений о получении данных и упорядочивания
передаваемых сегментов данных применяются протоколом TCP. Эти процедуры
помогают отслеживать прохождение трафика по сети, а также позволяют гаранти-
ровать надежную доставку данных в пункт назначения.

Глава 8

I.	Для управления взаимодействием между процессами, выполняемыми на удаленных
хостах, протокол TCP использует шесть следующих базовых функций:

•	Установление соединения (connection setup);

•	Закрытие соединения (connection teardown);

•	Мультиплексирование (multiplexing);

•	Передача данных (data transfer);

•	Управление потоком (flow control);

•	Надежность (reliability);

•	Приоритет (precedence) и защита данных (security).

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

3.	Протокол TCP имеет возможность одновременно устанавливать и поддерживать не-
сколько коммуникационных каналов между двумя удаленными хостами благодаря
одной из своих характеристик, а именно — благодаря возможности мультиплекси-
рования (multiplexing).

4.	Протокол TCP получает потоки данных (сообщения) от приложений верхних уров-
ней и разбивает их на сегменты для передачи на сетевой уровень с целью формиро-
вания дейтаграмм.

5.	Протокол TCP регулирует входящий поток данных посредством механизма сколь-
зящих окон (sliding windows mechanism).

6.	Протокол TCP обеспечивает надежную доставку пакетов в пункт назначения посред-
ством механизмов упорядочивания передаваемых сегментов данных (sequencing) и
формирования подтверждений об их получении (acknowledging).
7.	Ориентированным на соединение протоколам свойственны следующие базовые ха-
рактеристики:

•	Установление сеанса связи (session setup);

•	Завершение сеанса связи (session teardown);

•	Упорядочивание передаваемых данных (sequencing);

•	Выдача подтверждений о получении (acknowledgements),

•	Поддержание соединения активным (keepalives);

•	Управление потоком данных (Bow control).

8.	Так называемую пару сокетов (socket pair) образуют сокет источника (его адрес на
сетевом уровне и порт клиента), а также сокет назначения (его адрес на сетевом
уровне и порт сервера) Один клиент или совокупность клиентов могут затребовать
установления соединений с одним и тем же удаленным сервером. Образование пар
сокетов позволяет разграничивать различные запросы на установление соединения,
поскольку такой способ позволяет TCP уникальным образом идентифицировать и
правильно организовывать процесс взаимодействия между парами удаленных про-
цессов. Для успешного функционирования протокола TCP, в обязанности которого
входит обслуживание множества всевозможных соединений, образование пар соке-
тов (socket pairing) имеет решающее значение.

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

10.	В состав заголовка TCP ьходят следующие поля:

•	Поле порта отправителя (Source Port);

•	Поле порта получателя (Destination Port);

•	Поле порядковою номера (Sequence Number);

•	Поле номера подтверждения (Acknowledgement Number);

•	Поле смещения (Offset);

•	Зарезервированное поле (Reserved) ;

•	Поле флагов (U,A,P,R,S,F);

•	Поле окна (Window);

•	Поле контрольной суммы (Checksum);

•	Поле указателя срочности (Urgent Pointer);

•	Поле дополнительных параметров (Options);

•	Поле полезных данных (Data).
Глава 9

1.	Подробное описание протокола UDP представлено в RFC 768.

2.	Протокол UDP обеспечивает не ориентированную на соединение, быструю, но не-
надежную доставку сообщений между приложениями, выполняющимися на удален-
ных хостах.

3.	В заголовке IP протокол UDP идентифицируется типом протокола 17.

4.	Протокол UDP не использует процедуры упорядочивания и подтверждения приема
для обеспечения надежности доставки данных в пункт назначения. Протокол UDP
идентифицирует порты отправителя и получателя (source port, destination port) и вы-
полняет передачу данных, предпринимая лишь напряженную попытку доставки дей-
таграмм адресату (best effort delivery), но не гарантирует надежность доставки: при
этом задача обнаружения и восстановления потерянных или отсутствующих дейтаг-
рамм делегируется на другие уровни.

5	Выбор протокола UDP в качестве транспортного протокола, используемого прото-
колом TFTP для передачи файлов, предполагает, что передающей среде должны быть
свойственны следующие характеристики:

•	Стабильность сетевой инфраструктуры;

•	Вероятность появления только самых простых ошибок в процессе передачи дан-
ных.

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

6.	Протокол I'DP не имеет никаких организационных обязанностей по поводу под-
держания соединения. L’DP не устанавливает соединение междх хостами; следова-
тельно, поддержание такого соединения не входит в круг его обязанностей.

7.	Протокол VDP обеспечивает более быструю по сравнению с протоколом TCP дос-
тавку данных, а также позволяет значительно снизить объем непроизводительных
затрат.

8.	Для проверки целостности кадров протокол UDP использует алгоритм CRC (Cyclic
Redundancy Check. Контроль при помоши циклическою избыточного кода), кото-
рый позволяет проверить на наличие повреждении заголовок I'DP, данные верхних
уровней, а также псевдозаголовок UDP.

9.	Контрольная сумма позволяет проверить правильность следующих данных:

•	Данных, содержащихся в заголовке UDP;

•	Данных протоколов верхних уровней;

•	Информации, содержащейся в псевдозаголовке UDP.

10.	Псевдозпголовок UDP содержит следующую информацию.

•	Логический адрес хоста-отправителя;

•	Адрес хоста-получателя на сетевом уровне;

•	Код типа протокола, использующего протокол транспортною х ровня:

•	Длину дейтаграммы I ’DP.
Глава 10

1.	Уровень "Процесс/нриложснне" (Process/Application layer) коммуникационной мо-
дели DoD соответствует ерем верхним уровням модели OSI: прикладному уровню
(Application Layer). уровню представления (presentation Layer) и сеансовому уровню
(Session Layer).

2.	Уровень "Процесс/приложение" выполняет следующие основные функции:

•	Передача файлов (протокол FTP или ТГТР)

•	Организация файловой системы типа клиент/сервер посредством сетевой файло-
вой системы NFS;

•	Удаленный доступ к ресурсам и службам на удаленных хостах через службу Telnet;

•	Электронная почта.

3.	К прикладному уровню относятся прогоколы FTP TFTP

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

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

6.	К протоколам ONC(Opcn Network Computing Открытые сетевые вычисления) от-
носятся следующие протоколы: протокол NFS (прикладной уровень), протокол XDR
(уровень представления) и протокол RPC (сеансовый уровень).

Глава 11

I.	Служба Telnet (Telecommunications Network, Протокол сетевого взаимодействия с
терминалами) предоставляет возможность пол ..зов;, гелю, выполняющему сеанс связи
с терминалом, получить доступ к удаленному хосту сети (или серверу Telnet) через
стек протоколов TCP/IР.

2.	Последовательность событий, происходящих во время установления сеанса связи
между клиентом и сервером Telnet, вы(лядит таким образом:

•	После установления сеанса Telnei (Telnet session) функционирующее на исходном
хосте приложение становится клиентом Telnet.

•	Клиент Telnet устанавливает TCP-соединение с сервером Telnet (удаленным хос-
том) с помощью стандартной процедуры трехходового квитирования (three-way
handshake). Описание процедуры трехходового квитирования можно найти в гла-
ве 8.

•	Клиент получает возможность работать с клавиатурой и дисплеем через ТСР-со-
сдинение таким образом, как будто они подключены непосредственно к удален-
ному хосту.
•	Сервер Telnet использует в своей работе пссвдотерминал (pseudo terminal device).
Псевдотерминал представляет собой механизм сопряжения двух операционных си-
стем, что позволяет Telnet передавать данные в другую операционную систему та-
ким образом, как будто эти данные пощупают с одной и той же клавиатуры.

3.	Команды Telnet используются с целью согласования параметров между клиентом и
сервером Telnet.

4.	Пересыпка двоичных данных (Binary transmission), эхо-сообщение (Гсйо), подавле-
ние сообщения (Suppress go ahead), состояние (Status), метка синхронизации (Timing
mark), тип терминала (Terminal type), конец записи (End of record), размер окна
(Window size), быстродействие терминала (Terminal speed), удаленное управление
потоком (Remote flow control), построчный режим (Line mode), переменные среды
(Environment variables) — таков перечень самых важных и наиболее широко исполь-
зуемых параметров Telnet, общее число которых составляет более 40.

5.	Telnet предоставляет следующие базовые службы:

•	Сетевой виртуальный терминал (NVT, Network Virtual Terminal), представляющий
собой стандартный интерфейс взаимодействия двух удаленных систем.

•	Согласование клиентами и серверами различных необязательных параметров
(option negotiation)

•	Симметричное отображение терминалов и процессов (symmetric view of terminals
and processes)

6.	Протокол NVT обеспечивает прозрачность работы Telnet и поддерживает минималь-
ное количество параметров, подлежащих согласованию между клиентом и сервером
Telnet Реализация NVT в качестве фронтального процессора (front end) позволяет
скрыть различия между взаимодействующими устройствами, предоставляя обеим сто-
ронам общий набор команд и характеристик, которые делают партнеров по комму-
никации до определенной cienemi тождественными.

7.	7-разрядный код ASCII используется для представления каждою символа, выводи-
мого на экран дисплея в процессе передачи информации по Интернету посредством
NVT. Система кодирования NVT обеспечивает построчную пересылку последова-
тельности 7-разрядных символов ASCII, дополненных до 8 битов начальным битом
со значением 0.

8.	Действия Telnet по отношению к обеим взаимодействующим сторонам симметрич-
ны каждой из сторон предоставляется возможность выдать запрос на использова-
ние той или иной необязательной характеристики В случае если партнер по ком-
муникации не поддерживает какую-либо характеристику, либо когда ему запрещено
эту характеристику применять, он отвергает этот запрос. Партеры до!свариваются
между собой об использовании поддерживаемых ими хараюеристик и поддержива-
ют все дручие параметры в объеме стандартною минимального набора опции NVT.

9.	Символ IAC (Interpret as command, {интерпретировать как команду,) используется доя
тою, чтобы отмстить передаваемую информацию как команду. Этот символ уста-
навливается в нервом октете команды Telnet.
10	В процессе согласования парамегрон партнеры по коммуникации обмениваются сле-
дующими запросами:

•	WILL (будет использован): отправитель желает активизировать параметр.

•	DO (выполнить): отправитель желает, чтобы получатель активизировал параметр.

•	WONT (не будет использован): отправитель желает заблокировать параметр

•	DONT (нс выполнять) Отправитель желает, чтобы получа1ель заблокировал па-
раметр.

11. Во время согласования параметров партнеры по коммуникации могут направлжь
друг другу следующие ответы: WILL/DO, WILL/DON'T, DO/WILL. DO/WONT,
WONT/DONT и DON’T/WONT.

Глава 12

I Протокол FTP предоставляет удаленному или локальному клиенту и серверу осу-
ществлять аффективную пересылку файлов и данных с использованием надежного
транспортною протокола TCP. В частности, протокол FTP выполняет следующие
функции:

•	Поддерживает совместное использование файлов (компьютерных программ или
данных).

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

•	О|раждаез пользователя от проблем, связанных с различиями в системах файло-
вых запоминающих устройств.

•	Осуществляет надежную и эффективную передачу данных

2. В большинстве случаев сеанс FTP (FTP session), который можно инициировать че-
рез браузер Web, подразумевает взаимодействие пяти программных модулей (software
elements):

•	Пользовательский интерфейс (User Imerface): этот модуль предоставляет пользо-
вателю интерфейс, дающий ему возможность работать с FTP

•	Интерпретатор протокола клиента (client protocol interpreter), сокращенно — PI
клиента (Client PI): этот модуль выдает команды в адрес интерпретатора прото-
кола удаленного сервера (remote server protocol interpreter), а также активизирует
процесс передачи данных (data transfer process).

•	Интерпретатор протокола сервера (server protocol interpreter), сокращенно — Pl
сервера (Server PI): этот модуль отвечает на команды, полученные от Р1 клиента,
а также активизирует процесс передачи данных.

•	Процесс передачи данных, выполняемый клиентом (client data transfer process),
сокращенно — DTP клиента (Client DTP): этот модуль осуществляет связь с сер-
верным процессом передачи данных (server data transfer process) и файловой сис-
темой локального хоста (local file system).
•	Процесс передачи данных, выполняемый сервером (server data transfer process),
сокращенно — DTP сервера (Server DTP): этот модуль осуществляет связь с DTP
клиента и файловой системой удаленного хоста (remote file system)

3	Интерпретатор протокола отвечает за обработку команд FTP и ответов на них Р!
сервера прослушивает все запросы, поступающие по управляющему соединению на
общеизвестный порт 21, и ожидает установления связи с клиентом Со своей сторо-
ны PI клиента инициирует установление соединения посредством передачи запроса
на синхронизацию (SYN) протокола TCP в форме управляющею сообшения, направ-
ленного через общеизвестный ТСР-порт 21 в адрес хоста назначения.

4	Модуль DTP устанавливает соединение между клиентом и сервером (соединение для
передачи данных) каждый раз, когда осуществляется передача файлов. Клиент FTP
передает адрес данных на общеизвестный порт 20 сервера DI P (порт, назначенный
для передачи данных FTP). Пор>у клиент FTP присваивается изменяемый номер,
выделяемый только на время данного сеанса FTP.

5.	Протокол FTP использует два пути для установления логического соединения: по
одному пути устанавливается управляющее соединение (порт 21). по другому — со-
единение для передачи данных (порг 20). ТСР-порт 21 управляющего соединения
должен быть открыт еще до начала обмена данными. Если пользователь намерева-
ется осуществить передачу файла (отправить пли получить файл), сначала он дол-
жен выполнить соответствующую команду FTP. Результатом выполнения такой ко-
манды FTP является открытие второго соединения — соединения для передачи
данных (ТСР-порт 20).

6.	В процессе передачи данных протокол FTP использует следующие параметры:

•	Представление данных (data representation) идентифицирует тип передаваемых
данных.

•	Структура данных (data structure): задает формат передаваемых данных.

•	Режим передачи (transmission mode): определяет способ передачи данных по со-
единению FTP для передачи данных.

7.	Протокол FTP имеет в своем распоряжении следующие способы представления дан-
ных:

•	Представление данных в кодах ASCII (по умолчанию);

•	Представление данных в кодах EBCDIC;

•	Двоичный образ данных (image file type);

•	Представление данных в формате, задаваемом локальным хостом (local file type)

8.	FTP может использовать при пересылке файлов три типа структуры данных:

•	Файловая структура (file) — по умолчанию:

•	Структура записей (record);

•	Страничная структура (page).

9.	FTP имеет в своем распоряжении три режима передачи файлов

•	Потоковый режим (default) — по умолчанию;
•	Блочный режим (block);

•	Режим сжатия данных (cumpresaed).

10.	Протокол FTP использует следующих три способа форматирования:

•	Файл в формате ASCII с нсраснечагываемыми (nonprint) управляющими симво-
лами.

•	Управляющие символы форматирования Telnet (Telnet format control).

•	Управляющие символы вертикальною форматирования тыка Fortran (Fortran
carriage control).

11.	Потоковый режим передачи данных, при котором данные передаются в потоках бай-
тов, принимается но умолчанию; этот режим позволяет передавать данные в форме
совокупности записей.

12.	Интерпретаторы протокола клиента и сервера FTP обмениваются командами и от-
летами на них по правляющему соединению. Команды и ответы П Р передаются в
виде последовательностей символов ASCII NVT (Telnet). Команды FTP подразделя-
ются на три категории: команды управления доступом (access control commands),
команды «аддния параметров пересылки фай юв (transfer parameter commands) и сер-
висные команды (service commands). Команды управления доступом определяют,
какой клиент может получить доступ к тому или иному файлу. Команды задания
пар,.мс|ров псресы >н и файлов используются с целью изменения параметров, исполь-
зуемых для передачи данных по соответствующему соединению ГТР по умолчанию.
Протокол FTP использует сервисные команды. ко!да пользователь запрашивает пе-
ресылку файла или операцию с файлом.

13.	Ответы FTP (FTP replies) гарантируют синхронизацию запросов клиентов и соот-
ветствующих им отвешых действии сервера в процессе передачи файлов. Ответ FTP
имеет вид тре.хзначною кода, за которым следует дополнительное текстовое сооб-
щение. Форма 1 ответов FTP предос гавляет во 1можность как работающему в шало-
юном режиме пользователю, так и программному обеспечению прочитывать отве-
1Ы, предоставляющие информацию о выполнении команды Состоящие из трех цифр
коды ответов используются пр<>|раммным обеспечением для тою, чтобы определить
свои дальнейшие действия. Пользователь прочитывает текст, или дополнительное
сообщение, для тою, чтобы оценить дальнейшие действия программною обеспече-
ния. Эта удобное свойство ответов ПР устраняет необходимость в запоминании
। ромоздких числовых последовательностей, соответствующих этим ответам

14.	Суть механизма анонимного доступа к F ТР состоит в возможности пересылки фай-
лов по сети Интернет не чере« специальную учетную запись пользователя, а носред
ством анонимной учетной записи па F ГР (anonymous ЕГР) Это означает, что пользо-
вателю нет необходимости регистрироваться в качестве официального пользователя
какой-либо системы с целью получения доступа к предлагаемым этой системой
файлам.
Глава 13

1.	Упрошенный протокол электронной почты (SMTP, Simple Mail Transfer Protocol)
обеспечивает обмен сообщениями электронной почты (e-mail) между отправителем
(клиентом) и получателем (сервером).

2.	Пользователи получают возможность немедленною взаимодействия с электронной
почтой через UA. Посредством этою же модуля пользователь формирует, представ-
ляет для пересылки адресату и получает сообщения электронной почты.

3.	Посредством программного модуля МТА (Message Transfer Agent, Агент передачи
сообщений) протоке;! SMTP обеспечивает доставку почтовых сообщений между при-
кладными программами удаленною клиента и почтового сервера (эти прикладные
программы известны под названием UA, User Agents — Агенты пользователя).

4.	Протокол SMTP налагает следующие ограничения на передаваемые по электронной
почте сообщения: тело сообщения содержит только текст ASCII; максимальная длина
строки не должна превышать 1000 символов. Само сообщение в целом также не
должно превышать предписанный максимальный размер.

5.	Формирование команд SMTP подчиняется некоторым основным правилам:

•	Каждая команда SMTP состоит из кода команды и параметра.

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

•	Код команды отделяется от параметра не менее чем одним пробелом.

•	Поскольку на каждом хосте почтовые адреса могу! присваиваться но какому-либо
особому принципу, значения параметров "обратный путь" (reverse path) и "пря-
мой путь" (forward path) зависят от конкретных условий.

•	Поле параметра команды завершается символами возврата каретки и перевода
строки (<CR>, <LF>).

•	Необязательные параметры (optional arguments) заключаются в квадратные скоб-
ки.

6.	Ответы SMTP, представляющие собой трехзначный цифровой код, служат средством
подтверждения приема дейтаграмм SMTP, а также средством передачи уведомлений
об ошибках.

7.	Ответы SMTP представляют собой трехзначный цифровой код (предназначенный для
компьютера), за которым следует текст (предназначенный для прочтения пользова-
телем). По представленной таким образом информации пользователь имеет возмож-
ность определить статус запроса.

8.	Расширения, определяемые стандартом MIME, предусматривают передачу данных,
не поддерживаемую ранее существующей в сети Интернет почтовой службой. Это
достигается посредством применения к передаваемому сообщению одного из мето-
дов кодирования, позволяющего представить данные в удобочитаемых символах
ASCII с целью формирования стандартного сообщения электронной почты.
Глава 14

1.	По мере увеличения пространства имен в системе NIC возникли следующие про-
блемы:

•	Увеличение громоздкости списка имен по мере его расширения.

•	Усложнение процесса внесения изменений из-за перегрузки, связанной с обслу-
живанием слишком большого списка имен

•	Неэффективность и высокая стоимость обслуживания слишком объемного спис-
ка.

2.	Основной сервер имен загружает информацию из файлов, хранящихся на дисках.
Всгюмо1ательный сервер имен получает информацию от основного сервера.

3.	Компьютеры не могут распознавать доменные имена, поскольку они используют для
адресации только цифры (например, IP-адреса или МАС-адреса). Отсюда следует
необходимость в существовании какого-либо метода ра«решения имен (например,
DNS).

4.	Схема именования в DNS имеет древовидную иерархическую структуру (hierarchical
tree), в которой сетевой информационный центр регулирует только процесс присво-
ения доменных имен высшею уровня (top-level domains), а другие полномочия пе-
редает серверам доменных имен (name servers). В этом к заключается делетирова-
ние полномочий DNS (DNS delegation of authority).

5.	Процедура кэширования состоит в занесении информации в ОЗУ. Сервер имен со-
храняет все информационные запросы, а также соответствия между доменными име-
нами и IP-адресами либо посредством занесения информации в хранящийся на диске
файл, либо посредством кэширования (caching) этой информации (размещения ее в
кэше, быстродействующей буферной памяти ОЗУ) Такой способ хранения инфор-
мации позволяет серверу отвечать на запросы о предоставлении новейших сведений,
а также получать в свое распоряжение обновленные данные, необходимые для ус-
пешного выполнения процедуры разрешения имен. Кэширование, которому свой-
ственно высокое быстродействие, снижает также уровень затрат на разрешение имен,
не являющихся локальными по отношению к данному серверу

6.	Если сервер не может найти фебуемого имени даже после проверки своего кэша,
тогда он сам становится клие^ггом (действуя в качестве посредника по отношению
к xoctv-отправителю) и использует сообщения, сформированные согласно специфи-
цированному соответствующим RFC формату, для отправки в адрес полномочного
сервера совокупности запросов в одном сооощепии.

7.	Каждое сообщение включает в себя следующую информацию:

•	Доменное имя, подлежащее разрешению (domain name);

•	Класс, или семейство протоколов, в системе которых работает данное доменное
имя (protocol class);

•	Тип доменного имени (domain name type)

8.	NetBEUI представляет собой протокол канального уровня, разработанный специаль-
но для передачи дейтаграмм NetBIOS в рамках одноранговой сети с мостами между
участками локальной сети. NetBIOS представляет собой службу именования хостов,
но функции NetBIOS не ограничены только разрешением имен В состав возмож-
ностей NetBIOS входит также управление сеансами связи между хостами, обработ-
ка запросов браузеров и т.д.

9.	Усовершенствования, внесенные в NetBIOS, позволяют этому протоколу функцио-
нировать на базе стека протоколов TCP/IP

10.	NetBIOS взаимодействует с протоколами TCP/IP через общеизвестные порты UDP
и TCP 137 , 138 и 139. Порт 137 вылечен для службы имен NetBIOS (NBNS, NetBIOS
Name Service), обеспечивающей разрешение имен. Порт 138 выделен для службы ис-
пользования дейта1рамм NetBIOS для навигации в сети, позволяющей хостам анон-
сировать и находить различные службы по их именам. Порт 139 выделен для служ-
бы использования дейтаграмм NetBIOS для передачи данных по постоянным сетевым
соединениям, которая обеспечивает возможность использования локальными хос-
тами ресурсов удаленных хостов

11.	В NetBIOS существуют следующие методы разрешения имен:

•	Метод В-ухча (broadcast node type): широковеша1ельная рассылка запроса на раз-
решение имени в пределах локальной сети; в случае неудачи выполняется про-
верка файла LMHost.

•	Метод Р-ухча (point-to-poini node type): передача запроса на разрешение имени
только на сервер NBNS.

•	Метод М-узла (mixed node tvpe): клиент выполняет разрешение методом В-ухча,
Р-ухча, а затем — проверяет файл LMHost.

•	Метод H-yxia (hybrid node type) клиент выполняет разрешение методом Р-узла,
В-узла, а затем — проверяет файл LMHost.

12.	Прокси-агент WINS (WINS proxy agent) — эго WINS-сервер, выполняющий разре-
шение имен для хостов, которые не поддерживают разрешение имен методом Р-узла.
В качестве прокси агента может функционировать любой хост, сконфигурирован-
ный таким образом, что он имеет возможность перехватывать локальные широко-
вещательные запросы на рагрешение имен и ретранслировать их в ориентирован-
ных дейтаграммах в адрес удаленного WINS-сервера с целью выполнения разрешения
имени удаленного хоста.

Глава 15

I Протокол HTTP tHvpertcxt Transfer Protocol. Протокол передачи гипертекстовых
файлов) — самый'распространенный и популярный среди пользователей протокол
сети Интернет, активизируется каждый раз, koi да происходит шеччок на ссылке или
когда выполняется ввод запроса на поиск одной из Web-страниц. Символы JHTTPJ
можно увидеть в окне ввода URL, в начальной его части.

2.	Протокол HTTP обеспечивает процесс взаимодействия между браузером (browser)
рабочей станции и Web-сервером.
3.	Браузер, коюрый представляет собой обычную прикладную профамму. открывает
Web-ст ранимы.

4.	Протокол НТ ГР функционирует на прикладном уровне, обеспечивая канал связи для
передачи сообщений в пункт назначения. HTTP не гарантирует надежную передачу
данных (эту задачу он возлагает на протокол ГСР транспортного уровня), а также
не выполняет' повторную пересылку данных.

5.	Прогокоч HTTP обладает следующими уникальными характеристиками: двунаправ-
ленная передача данных (bi-directional transfer), согласование возможностей (capability
negotiation); применение промежуточных устройств (intermediaries), поддержка кэ-
ширования (caching); отсутствие архивирования данных о сеансах связи и о НТТР-
занросах пользователя; обеспечение канала передачи данных и продвижения дей-
та1 раммы в пункт назначения на прикладном уровне.

6.	Протокол HTTP поддерживает кэширование (caching), что позволяет сэкономить
время: браузер хранит в своей базе данных копию каждой Web-страницы, извлека-
емой для пользователя из сети Интернет. Если у пользователя снова возникнет не-
обходимость в обращении к извлеченной ранее Web-стран ипе, браузер HTTP выяс-
няет у сервера информацию о том, вносились ли изменения в содержание этой
Web-страницы и отличается ли последняя версия Web-страницы от хранящейся в
кэше копии

7.	Прокси-агент HTTP (proxy) — это промежуточный хост, функционирующий либо в
качестве клиента, либо в качестве сервера HTTP с целью обеспечения обмена ин-
формацией между агентом пользователя (UA, User Agent) и сервером источником.
Прокси-агенты HTTP передают запросы от клиентов к серверам Серверы HTTP
также отвечают на запрос, если запрашиваемая информация является локальной

8.	Любой хост на nyni от браузера к серверу может функционировать в качестве про-
кси-сервера.

9.	Оба типа сообщений формируются в соответствии со следующим общим форматом:

•	Общая начальная строка (generic start line), называемая строкой запроса (request
line) для запросов и строкой состояния обрабо1ки запроса (status line) для отве-
тов;

•	Общий заголовок (general header);

•	Заголовок сообщения (message header);

•	Одна пустая строка (empty line);

•	Тело сообщения (message body).

10.	Тело сообщения — это собственно информация, предназначенная для пользовате-
ля.

II.	В заюловках сообщении содержится информация, предназначенная для прочтения
брау зером

12.	Сообщения об ошибках создаются сервером HTML (Hypertext Markup Language, Язык
pa 1метки i ипертекста) и содержат указания на типы ошибок, произошедших в про-
цессе доставки данных в пункт нашачения.
Глава 16

1.	Протокол FTP функционирует на базе протокола TCP, что делает протокол FTP ори-
ентированным на соединение; протокол TFTP функционирует на базе протокола
UDP, поэтому TFTP является не ориентированным на установление соединения про-
токолом

2.	Преимущество протокола TFTP (по сравнению с протоколом FTP) состоит в том,
что он обеспечивает более простой и быстрый метод пересылки файлов с неболь-
шим уровнем непроизводительных затрат.

3.	Протокол TFTP обеспечивает простую по сути, несложную в применении и недо-
рогую для реализации службу пересылки файлов между хостами

4.	Для установления связи и транспортировки данных сторона-отправитель файла (кли-
ент TFTP) прежде всего открывает изменяемый клиентский UDP-порт, на который
можно сослаться либо как на TFTP-порт, либо по идентификатору порта передачи
данных (transfer ID, TID).

5.	Протокол TFTP оперирует следующими пятью типами пакетов

•	Запрос на чтение — Read Request (RRQ);

•	Запрос на запись — Write Request (WRQ);

•	Данные — Data (DATA);

•	Под1верждение — Acknowledgement (ACK);

•	Ошибка — Error (ERROR).

Передача пакетов RRQ (тип 1) и WRQ (тип 2) начинает запрос; в этих же пакетах
указывается, какой файл необходимо переслать. В пакетах Data (Данные), или па-
кетах типа 3 передаются запрашиваемые клиентом данные Пакет АСК (пакет типа
4) под1верждает прием каждого блока данных (пакета Data), поступивших в адрес
получателя в процессе пересылки данных. В пакете Error (Ошибка), или пакете типа
5 содержится подтверждение приема пакетов всех других типов, а также сообщение
о возникновении ошибки.

6.	Блок данных, размер которого менее 512 байтов, является признаком завершения
процесса передачи файлов.

7.	Протокол ТЕТР использует метод обязательного пошагового подтверждения приема
(the lock-step acknowledgement method), что предполагает выдачу подтверждения о
приеме каждого пакета до пересылки следующего пакета. Следует помнить о том,
что TFTP передает по одному блоку за один раз, нумерация пересылаемых блоков
производится с первою блока (номер I).

8.	Выдача пакетов Error (Ошибка) может быть вызвана одним из следующих событий:

•	Хост не имеет возможности выполнить запрос (например, не может определить,
|де находится файл).

•	Хост получает задержанный или дублированный пакет.

•	Хост теряег доступ к какому-либо ресурсу (такому как диск) в процессе пересыл-
ки файла.
9.	В случае если клиент отправляет запрос на чтение — сервер начинает пересылку;
если же клиент отправляет запрос на запись — передачу файла начинает сам кли-
ент.

10.	Клиент TFTP инициирует установление соединения посредством передачи запроса
на запись или на чтение файла с сервера. Соединение устанавливается между изме-
няемым клиентским портом отправителя (TFTP TID) и общеизвестным серверным
TFTP-портом 69 получателя. Клиент указывает идентификатор файла и тип данных
в начальном запросе. После отправления клиентом начального запроса происходит
переназначение нового UDP-порта для использования этого порта в качестве порта
TFTP T1D на время текущего сеанса передачи данных. Собственно процесс пере-
сылки файла начинается после назначения новою порта. В случае если клиент от-
правляет запрос на чтение — сервер начинает пересылку; если же клиент отправля-
ет запрос на запись — передачу файла начинает сам клиент.

II.	В расширениях TFTP (TFTP extensions) представлено описание специального пара-
метра пересылки (размера блока данных, blocksize); эта спецификация позволяет
передавать с помощью протокола TFTP блоки данных большего размера, что зна-
чительно увеличивает производительность пересылки файлов между удаленными
хостами

12.	Суть механизма согласования параметров состоит в следующем. Серверы TFTP, под-
держивающие согласование параметров, передают пакет ОАСК (Option
acknowledgement, подтверждение параметра); с помощью этого пакета сервер сооб-
щает клиенту, поддерживает ли он данный параметр. Когда сервер принимает ука-
занный параметр, он включает его в свои пакет ОАСК. Если сервер не принимает
параметр, он попросту игнорирует его, не включая в состав кадра ОАСК Клиенты
TFTP могут реализовать только разрешенные серверами параметры. В процессе со-
гласования клиент может отправить запрос на согласование совокупности парамет-
ров, просто перечислив их в пакете RRQ (чтение) или WRQ (запись). Запрос на
согласование параметров присоединяется клиентом в конец стандартного запроса
на чтение или запись, используемого для инициализации сеанса связи между кли-
ентом и сервером.

13.	Пакет ОАСК предназначен для подтверждения согласования дополнительных пара-
метров.

Глава 17

1.	Протокол SNMP был ранее известен под названием SGMP.

2.	Протокол SNMP имеет в своем составе три основных программных модуля, кото-
рые делают возможным удаленное управление сетью:

•	Диспетчер (Manager);

•	Агент (Agent);

•	Прокси-агент (Proxy)
3.	Агенты SNMP функционируют на базе отдельных хостов и реализуют свою работу с
помощью программ, которые обеспечивают выполнение команд SNMP и формиру-
ют уведомления о состоянии системы.

4.	Прокси-агенты протокола SNMP обеспечивают продвижение сообщений между аген-
тами и диспетчерами SNMP. Прокси-агенты функционируют также в качестве про-
межуточных звеньев между хостами агентов, поддерживающими разные версии про-
токола SNMP, что обеспечивает совместимость этих хостов.

5.	Диспетчер SNMP — это программный модуль, в состав которого входят програм-
мы-генераторы команд (command generators) и программы-получатели уведомлений
(notification receivers). Диспетчеры SNMP функционируют на базе отдельных хос-
тов и выполняют управляющие прикладные программы сетевого администрирова-
ния (такие как OpenView) для того, чтобы осуществлять удаленный контроль и мо-
ниторинг (отслеживание работы) агентов SNMP. Эти хосты осуществляют общее
руководство системой, а также реализуют пользовательский интерфейс с примене-
нием элементов SNMP, предназначенный для выполнения доставки команд аген-
там

6.	PDU типа Trap передаются в сообщениях, в которых содержатся незатребованные
уведомления о возникновении серьезных проблем, таких как проблемы с аутенти-
фикацией запроса.

Глава 18

I.	В состав семейства протоколов ONC входят протоколы NFS, RPC и XDR.

2.	Протокол NFS обеспечивает доступ к информации в сети с любой архитектурой че-
рез распределенные файловые системы.

3.	Протокол XDR выполняет такое преобразование данных, которое позволяет двум
различным операционным системам взаимодействовать друг с другом. XDR обеспе-
чивает платформенную независимость.

4.	Механизм RPC, в состав которого входит собственно протокол и независимый ин-
терфейс, отвечает за предоставление двустороннего канала передачи данных между
удаленными коммуникационными процессами. RPC функционирует на сеансовом
уровне, следовательно, в его обязанности входит установление сеанса связи между
выполняемыми на различных хостах процессами, а также поддержка этого сеанса
связи и отслеживание его работы.

5.	Протоколы ONC разработаны корпорацией Sun Microsystems.
Предметный
указатель

А

математическое назначение 141

Автономная система 213

Агент

пользователя 348

передачи сообщений 3э1

Агрегирование 75

Адрес

аппаратный 116

отправителя 92

получателя 93

Адресация

IP 54, 56

логическая 30

на канальном уровне 31

Алгоритм

контроля при помощи циклического кода
(CRC) 26, 31

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

(PCS) 26, 31

Анонимный доступ 344

Арендуемая линия 46

Атрибуты путей 245

Б

Бесклассовая междоменная маршрутизация
(CIDR) 76

В

Верхние уровни 24

Взаимодействие открытых систем (OSI) 19

Виртуальные каналы 216

Внешние объявления 200

Внутриобластные объявления 199

Временное подавление изменений 183

Время жизни 95, 110

Выбор маршрута 177

Выделение подсетей 66

Выделенная линия 46

Высокоуровневый протокол управления

каналом передачи данных (HDLC) 49, 51

Глобальные сети 46, 89

д

Двоичная система счисления 54

Дейтаграмма 149

Делегирование полномочий 364
Диапазон адресов хостов 71
Динамическая трансляция адресов 80
Динамическое назначение 141
Домены высшего уровня 364

3

Завершение сеанса 283

Заголовки

ICMP 100

АВР 123

ВООГР 135

RARP 131

DHCP 152

HTTP 393

LSA 202

OSPF 217

RIP 179

TCP 263

UDP 301

дейтаграммы IP 85
дополнительные 219
запросов и ответов 372
канального уровня 25
прикладного уровня 25
сеансового уровня 25
сетевого уровня 25
транспортного уровня 25
уровня представления 25

Задержка 178

Закрытие соединение 271

Запрос

АВР 63, 119

маршрутизатора 109

о временной метке 114

о маске адпеса 113
Запросы на комментарии 51

Зарезервированные адреса 60

И

Идентификатор приложения 94

Идентификатор сети (NetlD) 57

Имена доменов 367

Интерпретатор протокола клиента 331

Интерпретатор протокола сервера 331

Интранет 53

Информация от маршрутизатора 109

К

Кадр (frame) 26

Кадрирование пакета 31

Кадры

Ethernet 36, 37, 38

Token Ring 44

Каналы связи по требованию 187

Качества сеовиса 168

Классы адресов

класс А 59

класс В 60

класс С 60

класс D и Е 60

Команды

FTP 339

RIP 180

SMTP 352

Telnet 321

KoMMyTaiop(Switch) 31

Коммутация

каналов 46

пакетов 46

Конфликты 36

Корневые домены 364

Л

Rui ический адрес сетевого уровня 116

Локальные сети

Ethernet 33

Fast Ethernet 41

FDDI 45

Gigabit Etnernet 41

Slow Ethernet 39

Token-Ring 42

M

Максимальный модуль передачи 91, 106, 178

Маршрутизация

статическая 158

по умолчанию 160

динамическая 161

дистанципнно-векторная 162

по состоянию канала связи 167

смешанного типа 169

по классу адресов 185

МАС-адрес 31, 36

Маска подсети 61

переменной длины 67, 168, 193

Международная организация по

стандартизации (ISO) 19

Международные организации

ANSI

ARIN 57

ISOC 53

IAB 53

IETF 53

IRTF 54

NIC

Межобластные объявления 200

Метод

В-узла 381

М-узла 382

Н-узла 382

Р узла 382

Многоцелевое расширение электронной почты
357

Множественный доступ с контролем несущей
и обнаружением конфликтов (CSMA/CD) 35

Мидель

DoD 19, 21, 83, 98, 116

OSI 20, 64. 98, 116

Модуль множественного доступа (MSAU) 42,

43

Мультиплексирование 49, 272

Н

Нагрузка 178

Надежность 275

Недостижимый пункт назначения 104

Неприменимость обратного маршрута 165

Неприменимый обратный маршрут 185

Нейрон? юдительные затраты 91

Нижние уровни 24

О

Область 0 214

Обновления маршрутной информации 186
Образование пар сокетов 278

Объединение сетей 75

Ограничение поле видимости 164, 184

Односторонний опрос 121

Операция & 65

Оптимальный путь 84

Ответ

FTP 341

SMTP 355

о временной метке 113

о маске адреса 113

П

Перенаправление 109

Петли маршрутизации 163

Повторная передача 289

Подавление

изменений 165

источника 108

Поддержание состояние активным 244, 291

Подсчет транзитов 165, 183

Подтверждение (ACKi 97. 143

Полоса пропускания 89

Порт недостижим 105

Порты

UDP 97, 301

TCP 97

Порты и сокеты 258

Потенциальный преемник 232

Преамбула 38

Преемник 232

Приоритет и защита данных 275

Прокси 122

Пропускная способность 89

Пространство имен 361

Протокол недостижим 105

Протоколы

АВР 62, 115, 116

BGP 89, 235

ВООТР 115, 133

DNS 306

DHCP 115, 139

EIGRP 89. 2301

FTP 307, 329

 HTTP 309, 387

ICMP 84, 98

IGRP 89, 226

OSPF 89, 192

RAHP 115, 127

RIP 89, 174

RPC 28

SNMP 306

SMTP 306, 347

TCP 29, 254. 263

UDP 29. 299

ТГГР 306

Telnet 310, 317

NetBIOS 313, 377

NFSWINS 383

XDR 27

дистанционно-векторные 162

доступа к подсетям 37

Интернета 83

инкапсуляции 46

маршрутизации 84

не ориентированные на соединение 257

ориентированные на соединение 255

Процедура

routing 118

shouting 118

Р

Разрешение

адресов 116

имен 360

Редиректор 21

Резервный управляющий маршрутизатор 211

С

Сборка дейтаграмм 84. 93

Семиуровневая архитектура 22

Сетевая

архитектура 19

интерфейсная карта (NIC) 23

Сетевой виртуальный терминал 319

Сеть недостижима 104

Сквозная передача 30

Службы

адресации 25

маршрутизации 24

межсетевые 27

сетр ые 27

транспортные 24

Сообщения DHCP 142

Согласование параметров 322

Стандарт Х.400 349

Стандартная
область 214

тупиковая область 215

Статическая трансляция адресов 80

Т

Таблица

адресного поля IP адресов 68

маршрутизации 157

формирование суммарных маршрутных

адресов 77

Тайм-аут 121

Таймеры 186, 229, 290

Тип сервиса 87, 168, 276

Тип сообщений

ICMP 102

Точка доступа к службе

отправителя (SSAP) 39

получателя (DSAP) 39

Точка-точка 47, 211

Транзакция 145

Трансляция сетевых адресов (NAT) 78

Тупиковая область 214

У

Упорядочивание кадров 286

Управление канальным уровнем (DLC) 123

Управление потоком 274,292

Управляющий маршрутизатор 211

Уровни

доступа к сети 22

Интернета 22

канальный 23, 31

межхостовый 22

представления 27

прикладной 27

сеансовый 28

сетевой 30

транспортный 29

процесс/приложение 22

управления

доступом к среде МАС) 42

логическим каналом (LLC) 42

физический 32, 26

Установление

сеанса 277

соединения 271

Утилита Traceroute 111

Ф

Флаги

Не фрагментировать 91, 105

Есть еще фрагменты 91, 93

Фрагментировать 1

Последний фрагмент 91, 93

Формат

Сообщений SMTP 352

Сообщений ICMP 100

Протокола RIP

Форматирование передаваемых файлов 337

Формирование суммарных маршрутных
адресов 75

Фрагментация дейтаграмм 84, 93

X

Хост недостижим 104

Хост-отправитель 30, 119

Хост-получатель 30, 119

Ш

Широковещательная рассылка 211

Широковещательные адреса 71, 74

Шлюз 120

Э

Электронная почта 27

Эталонная модель 19

Эхо-запрос 103

Эхо-ответ 103
Марк Спортак, Френк Паппас и др

Компьютерные сети и сетевые
технологии

ISBN966-7992-05-5

210x270 мм, 736с. тв. переплет

Книга «Компьютерные сети и сетевые технологии» представляет
собой всеобъемлющее описание доступных на сегодняшний ден* сете-
вых средств и техноло! ий. Благодаря стилю и глубине изложения мате-
риалов, данная книга может стать настольным руководством для широ-
кого круга читателей: от новичков, желающих приумножить свои знания

в области сетевых технологий, до профессиональных «сетевиков», разрабатывающих проектные реше-
ния для конкретных сетей компьютеров. Подробно опии шаются архитектура, структурная организация,
топология, компоненты, операционные системы практически всех современных типов сетей компьюте-
ров. Особое внимание уделяется практическим особенностям организации работы однородных и гете-
рогенных сетей. Рассматриваются средства административного управления сетями, а также механизма
и технологии обеспечения безопасности и целостности сетевых информационных ресурсов.

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

Краткое оглавление

Часть 1 Введена сети юмпьютеров

Глава 1. Концепция и архитектура сетей
компьютеров

Глава 2. Типы сетей кг1 тьютеров

Часть 2. Локально сети компьютеров

Глава 3. Физическ <и уровень локальных сетей

Глава 4. Канальном уровень локальных сетей

Глава 5. Технилоп-п Ethernet

Глава 6. Технология Token Ring

Глава 7. Технология FDDI

Глава 8. Технология ATM

Глава 9. Технология ATM

Глава 10. Мосты, концентратоои и коммутаторы для
локальных сетей

Часть 3. Глобальные сети компьютеров

Глава 11. Аналоговые тепеЛонные каналы связи для
। рганизации глобальных сетей

Глава 12. Выделенные каналы связи

Глава 13. Введение в технологию xDCL

Глава 14. Коммутируемые каналы 56 Кбит/с

Глава 15 Каналы Т-1

Глава 16. Сети передачи данных с коммутацией кана-
лов

Глава 17. Сети передачи данных с ксм-'утацией па-
кетов

Глав? 18. Технология ISDN

Глава 19 Маршрутизаторы в глобальных сетях

Глава 20. Шлюзы

Часть 4. Организация работы сетей компьютеров

Глава 21. Выбор операционной системы

Глава 22. UNIX/Unux

Глава 23. Windows NT

Глава 24 NetWare

Глава 25 Стеки межсетевых протоколов

Глава 26. Адми 1исглативное управление сетями

Глава 27. Мониторинг компьютерных сетей

Приложение А. Организации по стандартизации

Поиложение В. Глоссарий терминов

Предметный иатепь
Чарльз Дж. Брукс

Аттестация А+.

Техник по обслуживанию ПК.
Организация, обслуживание, ремонт и
модернизация ПК и ОС

ISBN 5-93Л 2-024-5
210x270 мм. мягкий переплет, 816 с.



иааа

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

Подробно рассматриваются следующие темы: весь
спектр оборудования ПК вплоть до элементарных
разъемов; профилактика и поиск возникающих от-
казов; материнские платы, процессоры и память;
дисководы жестких и гибких дисков; принтеры, ска-
неры и модемы; вся линейка ОС компании
Microsoft, начиная со старой доброй MS-DOS. Каж-
дая глава завершается тщательно подобранными
контрольными и экзаменационными вопросами,
которые встречаются на реальных экзаменах (ра-
зумеется. вместе с правильными ответами!). Чи-
татели смогут найти в книге не только примеры
организации экзаменов, но также и советы, кото-
рые окажут неоценимую помощь при сдаче экза-
менов.

Словом, книга инкапсулирует в себе настоль боль-
шой объем сведений, что она по праву станет на-
стольной книгой не только для начинающих техни-
ков, но и для уже сложившихся, опытных специа-
листов; она будет служить своего рода "талмудом",
к которому придется обращаться вновь и вновь
Сопроводжающий книгу CD-ROM существенно уп-
рощает освоение материала, в особенности для
тех, кто планирует сдавать аттестационные экза-
мены А+ за рубежом.

Краткое оглавление

Часть 1. Техники по обслуживанию основной:
оборудования

Глава 1. 1.0 Установка, конфигурирование и мо-
дернизация

Глава 2 2 0 Диагностика и устранение неисправ-
ностей

Глава 3 3.0 Профилактическое техобслуживание

Глава 4. 4.0 Системная плата/Процессоры/Память

Глава 5. 5.0 Принтеры

Глава 6. 6.0 Основы организации сетей

Часть 2. Технологии операционных систем

Глава 7. 1.0 Фундаментальные основы операци-
онных систем

Глава 8. 2.0 Установка, конфигурирование и мо-
дернизация

Глава 9.3 0 Диагностика, поиск и устранение не-
исправностей

Глава 10. 4.0 Сети

Часть 3. Заключительный обзор

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

Экзамен по технологиям операционных систем
Советы по изучению и подготовке к экзаменам
Техник по обслуживанию основного оборудования
Технологии операционных систем

Приложение А. Словарь терминов

Приложение В. Обзор процесса сертификации

Приложение С. Что находится на CD-ROM
Приложение D. Использование программы
ExamGear. Training Guide Edition

Предметный указатель
КНИЖНЫЙ КЛУБ «комп@с.

(ОФИЦИАЛЬНЫЙ ПАРТНЕР ТОРГОВО-ИЗДАТЕЛЬСКОГО ДОМА «ДС»)

Приглашаем всех желающих вступить в книжный клуб «Комп@с» Вступив в клуб, Вп получите скидки,
содействие в поиске и покупке необходимых Ввм книг Мы своевр. менно реагируем на запросы читателей и
своей издательской деятельностью способствуем их профессиональному рос’у. Вы раньше других будете иметь
возможность познакомиться с новинками, получая наш прайс-лист, иллюстрированный каталог по почте либо
обратившись на нвш сайт www.diasoft kiev чв.

Вы сможете: пользоваться системой скидок при покупке книт
высказать свое мнение, пожелания и замечании относительно книг издательства;
найти новых друзей и партнеров по интересам,
заочно встретиться и пообщаться с авторам? книт
участвовать в розыгрыше призов бесплатной лотереи

И главное, впервые <ленам клуба будет предоставляться бесплатное комплексное ноогоаммное обес-
печение, позволяющее осуществлять связь с «нижней базой данных, получать оперативные изменения
в базе, компоновать заказы, получать информации о книгах издательств - объем, гопержание (краткое или
глобальное) аннотация текст одной из тлав, внешний вид обложки и т.д. С более подробной информаииеи Вы
можете ознакомиться на сайте www.diasolt.klev.ua

ПРИЕМ В КЛУБ

Для того чтобы стать членом книжного клуоа, достаточно купить одну из книг нашего издательства в любой
торговой точке, заполнить анкету, помещенную в книга, и отправить ев по тдресу издательства либо купить три
любых книги на одном из торговых мест ТИД ДС»

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

Карточка тыдается сразу же при покупке нв торговом месте ТИД дс« или у партнеров ТИД «ДС» (адреса
смотри на следующей странице). В остальных случаях (заказ по почте через электронный магазин, а также
покупка у независимых торговых организаций книги ТИД ДС») Вам необходимо заполнить анкету, помещенную
в книге, и отпрввить ее в издательство. Действие карточки распространяется на всв торговые точки, перечис-
ленные в этом пункте, кроме независимых торговых организаций

СИС ГЕМА СКИДОК

Став членом книжного клуба, Вы получовте первоначальную г кидку в размере 5% на весь ассортимент книг

(книги ТИД <Д& более WOO наименований книг издательств г крайни и стран СНГ).

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

При покупка в ечгние квартала пяти и болев хниг карточка заменяется на новую с 10% скидкой

Более подробную информацию о системе скидок можно получить, обратившись на наш сайт по адресу
www.diasoft Kiev ua

АНКЕТА

1.	Название книги_____________________________________________

2.	Где, по какой цене, когда (с точностью до месяца) Вы приобрели эту книгу9

3.	Ф.И О._____________________________________________________________________________

4.	Кем и де райгтаете___________________________________________________________________

5.	Параметры Вашего ПК__________________________________________________________________

6.	Адрес, тилефон e-mail, web узел______________________________________________________

Дата заполнения

Вышлите анкету по адресу. Украина, 03055, Киев-55, а/я 100, Издательство ' ДиаСофт».
ТОРГОВЫЕ МЕСТА ТОРГОВО- ИЗДАТЕЛЬСКОГО ДОМА «ДС>

КИЕВ

ХАРЬКОВ

ХПИ

и« т
опюупсроа

ДНЕПРОПЕТРОВСК

САНКТ-ПЕТЕРБУРГ

Пр-т Оиухлиско! обороны, д. 105
ДК им. Крулосой, м. Елплюлсхая*

АДРЕСА МАГАЗИНОВ,
ГДЕ МСи<НО КУПИТЬ КНИГИ ТИД >ДС»

' ПАРТНЕРЫ ТИД «ДС-

Киев

т.'ф 212-12-54.216-35-64

Кии i-почтой: 03055, а\я 100
e-man Dooksuediaraft kiev ua
е ma' bss@diasnn kiev.ua
e-mu. stepanD@akcecc.kiev.ua

Днепропетровск

i. (0562)33-27-74

Книга-почтой: 4900В, а\я 466
e-mail diasolt@mail dnepr.net

Харьков

T./0572M7-20-67

-mail: tx)uk ' 'rail.kliarkov.com

Львов

г /ф (0322)39-87-06

Одесса

T.IO482) 68-73-99

e-mail" kvanl@eurocom.od.ua
e-mail kvanl@tekom.Odessa ua

Москва

T.(095) 726-80-67

email" diascftjTisk@>rosmall ru

Санкт-Петербург

- (812) 316-78-24

e-mail: dlasoll_spt@mail convey.ru

КИЕВ
'Знання'.ул К₽сщяги*,45 т.224-22-01
Твхиичесгая iwi',
ул.Крйсно8₽мсйскяя.51 Т.227-25-88
'Сучасник’, пр-т Победы, 29
г 274 52-35
"Книжмжый сиЬ'.гр-т Победы,?
1 219-26 17
'Библгэтвчиый кол лектор'
rp-f 40-гетмя Октября. 100/2
т.263-20 54. 263 20-04
тел /факс 263-60-56

ДНЕПРОПЕТРОВСК
Мггаэы Тсхшч кнмп’
плОстровсют, I
телефон (0562) 33-08-55
Мвпда* 'Таджчвсюя юыпГ
гр КМарксс 40
телефон (0552} 744-86-72

ДОНЕЦК

•Дом ики'упЛртрю 147 
телефон (0622) 55 74-49
ЧП 'ИнфоКоы улДлвш 83
телефон (0622) 382-64-59
криво!» рог
'БунФдст-СвлстГ
пл Осаобоедсмш 1
телефон (0564) 29-31-21

ЛЬВОВ

*Техимчесхзя u«n', пл Рымм, 10
г.72-54-06

’Йллс’, Университет Лыжнсий
политехнж,корпуса 4,5, т^Э-ЕТМ

ЛУГАНСК
'Кмиги’.ул Соевтааи, 5В
т 53-62 30

ХАРЬКОВ
'Вища ид от’,ул Петрсвсиого.в
Т.47-В0-20
"Книги 3", ул.ПоптмсЕМЙ шлях.37,
т.12-55-27

МОСКВА
*Акздеыкммге*.ул 8атлош,55
т. 124 92 02

*Бмблмо-Г 1юбус’,уЛ-Мкми4Лаа,6
гм 928-87-44

•Дом тепмчвской ЕНИГН’.

Ленинский пр-т.40,т. 137-60-38
•Моолкжмй дам книги",
ул .Новый Дрбот 8
'ЬЬф'Дг-мнгрэйсшй пр-т.78
Г152-45-П
‘Энергия’, ул Н.Кржнной.Ю
т 145-52-00

'Мир печати* ул .2  Тевроая Аспя.54
т 978-50-47. 978-55-07

'Молодая гвардия', ул Балыпв Ломка, 28
Т238-11-44, 238 00 32

САНКТ-ПЕТЕРБУРГ
*Дом «мгм'.Невамй лр-т 28
г 318-64-16
"Техничхаав. пнига".
уп Пуижиютя 2.т 164-86-65
"Энергия". Маскжхмй пр-т, 189
т.443-01-47

МИНСК
'Книг ЮСГ
пр-т Ф.Скарины, 02,
ст.ы Мосяжхая,
т 64-31-05, 64-27-97
Как сделать, аказ и получить книги

Для организаций

I)	Получите полный прайс лист по адресу,
указанному ниже.

2)	Аккуратно заполните бланк заказа.

3)	Отправьте его нам по факсу, почте или
e-mail.

4)	В течение одною рабочего дня в Ваш ад-
рес будет направлен счет по факсу или е-
mail. В течение срока действия счета мы
гарантируем наличие книг и неизменность
цены

5)	После оплаты счета Ваш заказ, а также
оригинал счета, расходная и налоговая на-
кладные будут высланы Вам посылкой

Для частных лиц

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

2)	Аккуратно заполните бланк заказа

3)	Отправьте его нам по факсу, почте или
e-mail.

4)	В течение одного рабочего дня в Ваш адрес
будет направлен счет по факсу или e-mail. В
течение срока действия « чета мы гаранти-
руем наличие книг и неизменность цены.
Ишсиание! Не оплачивайте покупку до по-
лучения счета.

5)	Оплатите счет в любом коммерческом бан-
ке. Деньги можно отправить на наш расчет-
ный счет и почтовым переводом, но это не-
сколько дороже. чем через банк

Заказы, по» тупившие по электронной почте, обрабатываются в первую очередь.

Заказы «на южепиым платежом»—1 ie принимаю, ся.

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

Отоимо ть доставки по Украине или курьером по Киеву—7 грн.

Стоимость доставки по России—в зависимости от региона.

Получайте пелиый прайс-лист па все книга н направляйте заказы по адресу,
г Киев:03055а/я 100, тел-/факс(О44)212-1254,216-3564с-тай.	book.«nkiras»jftkiev ua

____________________________________________________________.<epanb4<jakcccc kiev.ua

www.diasoft.kiev.ua — всегда полный ассортимент наших книг
Прайс-лист ТиД “ДиаСофт"

Код	Автор	Название	Стр.	Формат	Заказ
		“"Использование ПК в целом			
4043	Нортон П„ Гуд	Рабата на персональном компьютере. Самоучитель	584	84x108/16	
6172	Михлин	Эффективный самоучитель работы на ПК	704	70x100/16	
6567	Клименко А.	Эффективный самоучитель работы на ПК. Основной 1	496	70x100/16	
6173	Клименко, Нор	Эффективный самоучитель работы на ПК Изд 2-е ле	736	70x100/16	
5675	Вебер	Сборка, конфигурирование, настройка, модернизация	624	70x100/16	
6455	Анонимный ав	Максимальная защита в Linux. Второе издание	752	70x100/16	
6175	Бююпь, Цефел	SPSS' искусство обработки информации	Ь08	70x100/16	
6169	Дома рев	Безопасность информационных технологии	688	84x108/16	
5228	Митчелл Ш.	Толковый словарь компьютерных технологий	720	76x100/16	
6583	Брукс Чарльз /	Аттестация А*. Техник по обслуживанию ПК Организ;	816	84x108/16	
4020	Нортон П. Гуд	Внутренний мир персональных компьютеров, 8е издаг	548	84x108/16	
4683	Канер Сэм и дс	Тестирование программного обеспе тения	544	60x84/16	
6538	Макгрегор	Тестирование объектно-орентированого программной	432	70x100/16	
		Операционные системы.			
5003	Вильямс М.	Программирование в Windows 2000. Энциклопедия пс	640	84x108/16	
5511	Кессел Пол	Microsoft Windows 2000 Professional Энциклопедия пс	832	70x100/16	
5954	Браун Т	Microsoft Windows 2000 Server Энциклопедия попьзОЕ	672	70x100/16	
6521	Чуприн А И.	Эффективный самоучитель работы в Windows ХР Pro	336	70x100/16	
6455	Анонимный aai	Максимальная защита в Linux Второе издание	752	70x100/16	
6523	Cki ювская	Команды Linux Справочник 2-е изд. переработанное у	720	70x100/16	
5717	Шенк Т.	Ped Hat Linux для системных администратироЕ Энци!	672	84x108/16	
6174	Болл. Питтс	Red Hat Linux 7 в офисе и дома	448	70x100/16	
5463	Сэри П.	Сервер Red Hat Linux для Windows	400	70x100/16	
5953	Г риффитс А	Прогаммированич 3NOME/GTK* Энциклопедия npori	720	70x100'16	
5758	Сэтчэлл Стеф<	Linux IP Slacks в комментариях	( + CD ROM )	288	70x100/16	
3926	Паркер Т им	Linux 5.2 Энциклопедия пользователя + 2 CD ROM	688	84x108'16	
1557	Бурк Р., Хирея	Unix для системных администраторов. Энциклопедия	864	60x84/8	
4318	Бурк Робин.Хо	UNIX для Internet Энциклопедия пользователя ( * С	496	84x108/16	
44	Келли М.	Ответы на актуальные вопросы по OS/2 Warp	352	60x84/16	
6496	Эбен Майкл	FreeBSD. Энциклопедия пользователя	736	70x100/16	
		Программирование			
5953	ГриффитсА	Прогдммирование GNOME'GTK+. Энциклопедия прог|	720	70x100/16	
5462	Пратв С.	Язык программирования C++. Лекции и упражнения	656	84x108/16	
5853	Седжвик Робе(	Фундаментальные алгоритмы на C++ Анализ/ Структу	688	70x100/16	
5804	Хэзфилд Р	Искусство программирования на С. Фундаментапьные	73b	84x108/16	
4754	Либерти Джее	C++ Энциклопедия пользователя с приложением	584	84x108/16	
3850	Зиткен Питер	Программирование на Visual Basics Этюды профессз	480	84x108/16	
4461	Дантеменн	Программирование в среде Delphi	0		
3621	Калверт Ч	Delphi 4. Самоучитель (без приложения)	192	84x108116	
5845	Кандзюба С П.	Delphi 6. Базы данных и приложения Лекции и улражг	576	70x100/16	
2757	Капвеот Ч.	Delphi 4. Энциклопедия пользователи ( + CD-ROM )	400	84x108116	
93	Конопка Р.	Создание оригинальных компонент в среде Delphi	512	60x84/16	
6103	Глинский Я.Н.	Turbo Pascal 7 0 и Delphi Учебно» пособие	208	60x84/16	
5852	Зеленяк О.П.	Практикум программирования на Turbo Pascal Задачу	320	60x84/16	
6206	Голубь Н Г.	Искусство программирования на Ассемблере. Лекции	656	70x100/16	
1057	Гаппагер С . Х<	Power Builder 6.0. Энциклопедия пользователя ( + CD-	816	60XP4/8	
6148	Леинекер	UOM+ Энциклопедия программиста + CD-ROM	656	70x100.16	
5799	Клименко	Kylix 1.0. Базы данных и приложения Лекции и упражг	288	70x100/16	
6522	Саймон	Windows 2000 API. Энциклопедия программиста 2-е и	1088	70x100/16	
		Офисные пакеты.			
4303	Нортон Питчр	Microsoft Offic' 2000 Избранное от Питера Нортона	552	84x108/16	
941	ТамураР и др	Lotus Notus и Domino Server 4 5 Энциклопедия польз	720	60x84/8	
6622	Кишик А.	Office ХР Эффективный самоучитель. Быстро...прост	432	70x100/16	
		Текстовые редакторы,			
6454	Кишик А.Н.	Word 2002. Эффективный самоучитель Быстро...прос	256	70x100/16	
		Электронные таблицы.			
6104	Кишик А.Н.	Excel 2002 Эффективный самоучитель. Быстро., прос	240	70x100/16	
		Настольные базы данных			
6623	Послед Б.С.	Access 2000. Гриложания баз данных Лекции и упрах	656	70x1)0/16	
5096	Форт С .Хоуи I	Программирование в среде Access 2000 Энцикпопец,	544	84x108/16	
		Базы данных клиент-сервер			
1493	AIS	Oracle 8 Энциклопедия пользователя ( + CD ROM )	864	60x84/8	
4925	Бьлсон Дон и д	Внутренний мир Огайев Проектирование и нагтроика	800	84x108/16	
5057	Г рин Джо	Oracle 8/8i Server. Энциклопедия пользователя	576	84x108/16	
6168	AIS	Oracle 8. Энциклопедия пользователя Изд. 2-е. пере;	864	60x84/8	
5640	Бьелетич Шаре	MS SQL Server 2000 Энциклопедия пользователя	688	70x100/16	
2010	Мак-Налли Д. i	Informix Энциклопедия пользователя	800	60x64/6	
		Г рафика и анимация.			
2472	Боутон Г и до	Пнутренний мир Adobe Photoshop 5 i + CD-ROM )	496	84x108116	
5513		Adobe Photoshop 6.0 Принижение к книге "Внутренние	32	34x108/16	
1556	Лаи Д. Симсик	Магия Photoshop 4.0 Том 1: Оформление текстов ( +	352	84x108/16	
6497	Кишик	Adobe Photoshop 6 0 Эффективным самоучитель 2-е	336	70x100/16	
5587	Компания Adot	Adobe Illustrator 9.0. Учебник ( <• tD-ЙОМ )	368	70x100/16	
5515	Ковтанюк Ю.С	CorelDRAW 1 п для дизайнера	880	70x100/16	
570	Элпиот: С	Внутренний мир 3D Studio МАХ. Том . ( * CD-ROM )	752	84x108/8	
2471	Эллиотт С.. Мк	Внутренний мир 3D Studio МАХ 2. Гом 1 ( + LD-ROM )	848	84x108/16	
649	Эспиноза Д.	3D Studio МАХ..Внутреннии мир. Том 2-и ( + CD-ROM	432	64x108/16	
6171	Хаббелл. Борд	3D Studic VIZ 3 + CD-ROM	624	70x100/16	
3925	Маэстри Джор/	Бнутренни i мир 3D Studio MAX 2 ГомЗ Анимация ( <	408	84x108/16	
5080	Миллер Ф	Внутренний мир 3D Studin MAX 3 моделирование мат	720	84x108/16	
2860	Бордмэн Г, Ха	Внутренний мир 3D Studio МАХ 2 Том 2 Модепирова	368	84x108116	
6498	Темин	3D Studio МАХ 4 Эффективный самоучитель 2-е изда	480	70x109/16	
4634	Бордмэн	Внутренний ми[ 3D Stud'O МАХ 3 ' Моделирование мг	456	84x108/16	
6520	Ли Ким	3D Studio МАХ 4 для дизайнера. Искуство трехмерной	832	70x100/16	
5262	Мипьберн К К[	Внутренний мир FLASH 5 для дизайнера ( + CD ROM	496	70x100/16	
5029	Мортиер Р.	Внутренний мир Вгусе 4 для дизайнера ( + CD-ROM )	336	70x100/16	
5069	МильбнрН Кер,	Внутренний мио Flash 4 для дизайнера (♦ CD-ROM )	448	70x100/16	
2101	Браун Де! в и $	Adobe Web-дизаин и публикация Энциклопедия поль	650	60x84-3	
6646	Китинг Д	Flash MX. Искусство создания юеб-саитов	848	70x100/16	
6170	Китченс, Гавен	BRYCE для дизайнера + CD ROM	656	84x108/16	
Ы95	Дэн Аблан	LghlWave 6/7 для дизайнера. Искусство трехмерного	864	/0x100/16	
		Издательские системы			
5163	Хансен Хан	Разработка сценариев для PageMaker { + CD-ROM )	704	60x84/16	
6566	Компания Adot	Page Maker 7 0 Учебник от Adobe	384	70x100/16	
		CAD-пакеты.			
3924	Барчард Б и д	Внутренний мир AuloCAD I ‘ Новые возможности ( +	767	84x108/16	
6146	Чуприн м И	AutoCAD 2002. Лекции и упражнения	768	70x100/16	
4753	Бар нард Билл	Внутренний мир AutoCAD 2000. ( + CD-ROM )	688	34x108/16	
6559	Харрингтон	AvtoCAD 2002 для конструкторов Искусство проек.ир	944	70x100/16	
6235	Титаренко	Mechanical Desktop 4 5 6 Искусство трехмернного пре	304	70х100/'6	
		Сети, коммуникации и сетевые продукты			
3947	СпогтакМ ид	Компьютерные сети Книга 1: Hinh-Porformance Netwo	432	60x84/8	
3927	СлортакМ ид	Компьютерные сети. Книга 2. Netwjrking Essentials Эг	432	84x108/16	
6384	Спортак Марк	Компьютерные сети и сетевые технологии	736	70x100116	
4577	Хейвуд Дрю	Внутренний мир Microsoft TCP/IP	496	84x108/16	
1295	ГринД и др.	Microsoft BackOffice 2 Энциклопедия пользователя ( т	800	60x84/8	
1032	Оливер Дик. Ф	Популярные Web броузеры. Энциклопедия пспьзоват	469	6пх84/8	
		Использование Интернет.			
4636	Хан Харли	Обучает работе в Internet	448	60x84/16	
6145	Киселев Ю Н	Электронная коммерция Прак гическое руководство	224	60x84/16	
5510	Хан Харли	Эффективный самоучитель работы в Internet	448	60x84/16	
802	Акоста Н и др.	Внутренний мир World Wide Web	544	84x1 ОЯ/Е	
40	Левин Я., Леви	Ответы на актуальные вопросы по Internet	384	60x84/16	
5258	Холден Грет.У:	Apache Server в комментариях./ + CD-ROM )	480	84x108/16	
		Программзгование дпя Интернет			
945	Морган Б	Visual J+т, Энциклопедия пользователя ( * Cl I-ROM )	496	60х84/Р	
5165	Вайк Аллен	JavaScript в примерах	304	70x100/16	
5355	Вайк А.. Вагнер	JavaScript Энциклопедия юльзогатепя (+ CD-ROM )	404	84x108Мб	
Г-646	Китинг Д	Flash MX Искусство создания web-сайт ib	848	70x100'16	
5955	Томсон Л ..Beni	Разработка Web припож< ний на PHP и MySQL ( + СС	672	70x100/16	
5963	Вайнман Л.,Ви	Динамически HTML Руководство разработчика Web-	464	70x100/16	
6147	Лесса Андре	Python. Руководство разработчика.	688	70x100/16	
6495	Перкс Анна-Ма	Dreamweaver 4 Искусство создания wcb-саитов	688	70x100/16	
6147	Лесса Андре	Pvthoii. Руководство разработчика.	Ь88	70x100/16	
5720	Вайк А,	PHP. Справочник	448	70x100/16	
6094	Кишик А.Н.	Flash 5.0. Анимация. Эффективный самоучитель. Быс	240	70x100/16	
650	Чепмен Д.	Разрабп.ка lnternet-притжений в Delphi 2 ( + CD-ROh	640	60x84/16	
5721	Хьюгс С,, Змие	PHP Руководсп о разработчика	384	70x100/16	
5149	Бизли Девид W	Язык программирования Python. Справочник	336	70x100/16	
		Мультимедиа.			
314	СкиббЛ.,Хейс|	Оптимизация мультимедиа ПК ( + CD-RCM )	352	60x84/16	
		Экономика			
4849	Устинова Г.М.	Информационные системы менеджмента	368	60x90/8	
		Словари			
5228	Митчелл LU.	Толковый словарь компьютерных технологий	720	70x100/16	
Научное издание

Остерлох Хезер

TCP/IP.

СЕМЕЙСТВО ПРОТОКОЛОВ ПЕРЕДАЧИ ДАННЫХ
В СЕТЯХ КОМПЬЮТЕРОВ

Заведующий редакцией СП. Козлов
Научный редактор. Н.И.Алишов
Верстка ГА. Булавке
Главный дизайнер О.А.Шадрин

ООО «ДиаСофтЮП», 196105. Санкт-Петербург, пр. Ю. Гагарина, д. 1, ком, 108
Лицензия №000328 от 9 декабря 1999 г.

Сдано в набор 03.06.2002. Подписано в печать 30.07.2002. Формат 70x100/16.

Бумага типографская Гарнитура Таймс Печать офсетная Псч.л. 36,00
Тираж 3000 экз. Заказ № 76S

Отпечатано с готовых диапозитивов
в ФГУП ордена Трудового Красного Знамени «Техническая книга»
Министерства Российской Федерации по делам печати,
телерадиовешания и средств массовых коммуникаций

198005, Санкт-Петербург, Измайловский пр., 29.
Книга посвящена описанию современных технологий
транспортировки пользовательских данных и системных
сообщений в локальных, корпоративных и глобальных сетях
компьютеров на базе семейства протоколов TCP/IP.

Профессиональное и доступное изложение прикладных
функции TCP/IP позволяет использовать книгу при
проектировании и эксплуатации компьютерных сетей.
Основное внимание в книге уделено технологиям
использования протоколов в сети Интернет

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

Детально рассматриваются

Пользовательские протоколы

Передача файлов (FTP TFTP, NFS)

Электронная почта (SMTP MIME)

Передача гипертекстовых файлов (WWW HTTP)

Управление сетями (SNMP)

Удаленный терминал (TELNET)

Протоколы маршрутизации

Протокол маршрутной информации (RIP)

Протокол поиска кратчайшего пути (OSPF)

Протокол граничного шлюза (BGP)

Протокол маршрутизации внутреннего шлюза (IGRP)

Усовершенствованный протокол маршрутизации внутреннего
шлюза (EIGRP)

Протоколы транспортировки данных

Управление передачей данных (TCP)

Передача пользовательских дейтаграмм (UDP)

Интернет протоколы (IP, ICMP)

Адресные протоколы

IP-адресация (192 168.33 44 255 255.0 0.)

Разрешение адресов (ARP)

Обратное разрешение адресов (RARP)

Загрузочный протокол (ВООТР)

Динамическое конфигурирование хостов (DHCP)

Именование компьютеров (Naming Computers)

Пространство имен (Namespace)

Служба именования flOMeHOB(DNS)

Имена доменов сети Интернет (IDN: http//..1in.ucsf edu.ua)

Трансляция сетевых адресов (NAT: 10.0.0.1 > 122.33.44.55)

Протоколы в сетях

Глобальные сети

Корпоративные сети

Интернет, Интранет

Х.25

Frame Relay

Ethernet (Fast. Gigabit)

Token Ring

е-та books@diasoft.kiev.ua wet сляг www.diasoft.kiev.ua

КАТЕГОРИЯ
ОБОЛОЧКА
УРОВЕНЬ

Компьютерные сети
TCP/IP

Начинающий Средний Мтстср Эисперт

Об авторе