Теги: компьютерные технологии оргсвязь программирование компьютерные сети
ISBN: 5-8046-0041-9
Год: 2004
Текст
77m Parker
and Karanjit S. Siyan
TCP/IP
Unleashed
3d edition
SAMS
ББК 32.988.02
УДК 681.324
П18
П18 TCP/IP. Для профессионалов. 3-е изд. / Т. Паркер, К. Сиян. — СПб.: Питер,
2004.— 859 с: ил.
ISBN 5-8046-0041-9
Главной особенностью этой книги является то, что материал в ней изложен с позиций, не
связанных с программированием. Авторы рассказывают о том, как работает протокол TCP/IP, как
он взаимодействует с другими протоколами своего семейства, какие функции выполняет.
Описания сопровождаются подробными инструкциями по установке и настройке протоколов и
служб, приводятся используемые для этого команды и примерные результаты их выполнения. Вы
узнаете, как организовать поддержку TCP/IP во многих операционных системах, включая
Windows 9x, Windows NT, Windows 2000, NetWare и в популярной системе Linux. В книге также
затронуты вопросы безопасности.
ББК 32.988.02
УДК 681.324
Права на издание получены по соглашению с Sams Publishing.
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного
разрешения владельцев авторских прав.
Информация, содержащаяся в данной книге, получена из источников, рассматриваемых издательством как надежные. Тем не
менее, имея в виду возможные человеческие или технические ошибки, издательство не может гарантировать абсолютную
точность и полноту приводимых сведений и не несет ответственности за возможные ошибки, связанные с использованием книги.
© 2002 by Sams Publishing
ISBN 0-672-32351-6 (англ.) © Перевод на русский язык, ЗАО Издательский дом «Питер», 2004
ISBN 5-8046-0041-9 © Издание на русском языке, оформление, ЗАО Издательский дом «Питер», 2004
Краткое содержание
Благодарности 26
Введение 27
Глава 1. Открытые коммуникации 29
Глава 2. TCP/IP и Интернет 43
Глава 3. Общий обзор TCP/IP 57
Глава 4. Имена и адреса в сетях IP 70
Глава 5. ARP и RARP 99
Глава 6. DNS 123
Глава 7. WINS 138
Глава 8. Автоматизированная настройка TCP/IP 162
Глава 9. Обзор семейства протоколов IP 190
Глава 10. Протокол IP 204
Глава 11. Транспортные протоколы 248
Глава 12. IPv6 306
Глава 13. Маршрутизация в сетях IP 326
Глава 14. Шлюзовые протоколы 347
Глава 15. Протокол RIP 353
Глава 16. Протокол OSPF 385
Глава 17. Протокол IPP 408
Глава 18. Протоколы удаленного доступа 413
Глава 19. Брандмауэры 444
Глава 20. Сетевая и системная безопасность 457
Глава 21. Общая конфигурация 470
Глава 22. Настройка TCP/IP в Windows 95 и Windows 98 485
Глава 23. Настройка TCP/IP в Windows 2000 505
Глава 24. Поддержка IP в Novell NetWare 548
Глава 25. Настройка TCP/IP в системе Linux 563
Глава 26. Whois и Finger 584
Глава 27. Протоколы пересылки файлов 599
Глава 28. Telnet 620
Глава 29. Инструментарий удаленного доступа 636
Глава 30. Протоколы совместного доступа к файловой системе: NFS и SMB/CIFS . . . 648
Глава 31. Интеграция TCP/IP с прикладными службами 667
Глава 32. Почтовые протоколы Интернета 672
Глава 33. Служба HTTP 688
Глава 34. Служба сетевых новостей и протокол NNTP 704
Глава 35. Установка и настройка web-сервера 713
Глава 36. Настройка и оптимизация протоколов в системах семейства Unix .... 729
Глава 37. Реализация DNS 744
Глава 38. Управление сетью TCP/IP 756
Глава 39. Протокол управления сетью SNMP 777
Глава 40. Безопасность передачи данных TCP/IP 790
Глава 41. Инструментарий и методы диагностики 805
Приложение A. RFC и стандарты 828
Приложение Б. Сокращения и акронимы 837
Алфавитный указатель 846
Содержание
Благодарности . 26
Введение 27
От издательства 28
Глава 1. Открытые коммуникации 29
Эволюция открытых сетей 30
Многоуровневая структура коммуникаций 30
Эталонная модель OSI 32
1. Физический уровень 33
2. Канальный уровень 34
3. Сетевой уровень 34
4. Транспортный уровень 35
5. Сеансовый уровень 35
6. Представительский уровень 37
7. Прикладной уровень 37
Использование модели 37
Эталонная модель TCP/IP 40
Анатомия модели TCP/IP 40
Итоги 42
Глава 2. TCP/IP и Интернет 43
История Интернета 43
ARPANET 44
TCP/IP 44
NSF 45
Интернет сегодня 45
RFC и процесс стандартизации 46
Источники информации о RFC 47
Индексы RFC 48
Краткое знакомство со службами Интернета 48
Whois и Finger 48
FTP 48
Telnet 49
Электронная почта 49
World Wide Web 49
Usenet 49
Интрасети и эксграсети 50
Интрасети 50
Преимущества интрасетей 50
Области применения интрасетей 51
Предоставление внешнего доступа к интрасети 51
Будущее Интернета 52
NGI (Next Generation Internet) 52
vBNS 52
Internet2 A2) 53
Так кто же главный в Интернете? 53
ISOC (Internet Society) 53
IAB (Internet Architecture Board) 53
IETF (Internet Engineering Task Force) 54
IESG (Internet Engineering Steering Group) 54
IANA (Internet Assigned Numbers Authority) 54
ICANN (Internet Corporation for Assigned Names and Numbers) 54
InterNIC и другие регистрирующие органы 55
Редактор RFC 55
Поставщики услуг Интернета 55
Итоги 56
Глава 3. Общий обзор TCP/IP 57
Преимущества TCP/IP 57
Уровни и протоколы TCP/IP 58
Архитектура 58
TCP 59
IP 61
Прикладной уровень 63
Транспортный уровень 63
Сетевой уровень 64
Канальный уровень 64
Telnet 64
FTP 64
TFTP 65
SMTP 66
NFS 66
SNMP 67
Место TCP/IP в системе 68
Концепция интрасети 69
Итоги 69
Глава 4. Имена и адреса в сетях IP 70
Адресация в протоколе IP 70
Двоичная и десятичная запись 71
Форматы адресов IPv4 72
КлассА 73
КлассВ 74
Классе 74
Класс D 75
КлассЕ 76
Недостатки схемы адресации IPv4 76
Специальные IP-адреса 77
Адресация сети 78
Направленная широковещательная рассылка 78
Ограниченная рассылка 79
Нулевой IP-адрес 79
IP-адрес хоста в текущей сети 80
Обратная связь 80
Исключение в схеме адресации IP 81
Появление подсетей 81
Подсети 82
Пример использования подсети 85
Маски подсети переменной длины 87
CIDR 88
Бесклассовая адресация 89
Расширенное агрегирование маршрутных данных 89
Суперсети 89
Принцип работы CIDR 90
Открытые адресные пространства 91
RFC 1597 и 1918 91
Адресация в частных сетях 92
Назначение адресов класса С 94
Настройка IP-адресов 95
Адресация в IP версии 6 96
Итоги 98
Глава 5. ARP и RARP 99
Механизмы адресации 99
Адресация в подсетях 100
Физические адреса 100
Адрес LLC 101
Сетевые кадры 102
IP-адреса 103
Общие сведения о протоколе ARP 104
toiuARP 105
Тип оборудования 106
Тип протокола 107
Длина аппаратного адреса (HLen) 108
Длина протокольного адреса (PLen) 108
Код операции 108
Аппаратный адрес отправителя 108
IP-адрес отправителя 108
Аппаратный адрес получателя 108
IP-адрес получателя 108
Схема работы ARP 109
Строение протокола ARP 110
Сетевой мониторинг с использованием ARP 111
Тайм-аут в кэше ARP 111
ARP в мостовых сетях ИЗ
Дублирование адресов и ARP 114
Дублирование IP-адресов клиентов TCP/IP 114
Дублирование IP-адресов на серверах TCP/IP 116
Проверка дублирования адресов ARP 117
Proxy ARP 117
RARP 118
Схема работы RARP 119
Сбой сервера RARP 121
Основные и резервные серверы RARP 121
Команда ARP 122
Итоги 122
Глава 6. DNS 123
Система доменных имен: общие принципы 123
Иерархическое строение DNS 125
Делегирование полномочий 126
Распределенная база данных DNS 127
Домены и зоны 127
Домены верхнего уровня в Интернете 128
Выбор сервера имен 128
Процесс разрешения имен 128
Рекурсивные запросы 128
Итеративные запросы 129
Кэширование 129
Запросы на обратное разрешение 129
Безопасность DNS 129
Ресурсные записи (RR) 129
Ресурсные записи типа SOA 130
Ресурсные записи типа А 132
Ресурсные записи типа NS \ 132
Ресурсные записи CNAME 132
Ресурсные записи PTR 133
Делегированные домены 133
Ресурсные записи HINFO 133
Ресурсные записи ISDN 134
Ресурсные записи MB 134
Ресурсные записи MG 135
Ресурсные записи MINFO 135
Ресурсные записи MR 135
Ресурсные записи MX 135
Ресурсные записи RP 136
Ресурсные записи RT 136
Ресурсные записи ТХТ 136
Ресурсные записи WKS 137
Ресурсные записи типа Х25 137
Итоги 137
Глава 7. WINS 138
NetBIOS 138
Разрешение имен в NetBIOS 141
Динамическое разрешение имен в NetBIOS 143
Преимущества WINS 144
Как работает WINS 144
Настройка клиентов WINS 146
Настройка WINS для прокси-агентов 147
Настройка прокси-агента в NT 4 148
Настройка прокси-агента в Windows 95/98 148
Настройка сервера WINS 148
Администрирование и сопровождение WINS 149
Добавление статических записей 149
Сопровождение базы данных WINS 150
Архивация базы данных WINS 153
Архивация данных реестра 154
Восстановление базы данных WINS 154
Сжатие базы данных WINS 154
Репликация WINS 155
Рекомендации по реализации WINS 156
Интеграция служб разрешения имен 156
Предоставление данных WINS через DHCP 157
Разрешение имен NetBIOS через файл LMHOSTS 158
Итоги 160
Глава 8. Автоматизированная настройка TCP/IP 162
Динамическая настройка конфигурации с применением ВООТР 162
IP-адреса запросов/ответов ВООТР 163
Потеря сообщений ВООТР 166
Формат сообщения ВООТР 166
Фазы ВООТР 168
Дополнительные данные 169
Динамическая настройка с использованием DHCP 171
Распределение IP-адресов в DHCP 171
Назначение IP-адресов в DHCP 172
Формат сообщения DHCP 175
Трассировка протокола DHCP 178
Итоги 189
Глава 9. Обзор семейства протоколов IP 190
Модель TCP/IP 190
Семейство протоколов TCP/IP 190
Протоколе 191
Заголовок IPv4 192
Задачи протокола IP 193
Поврежденные пакеты 194
Протокол TCP 195
Структура заголовка TCP 195
Задачи протокола TCP 197
Протокол UDP 200
Структура заголовка UDP 201
Задачи протокола UDP 201
Сравнение TCP с UDP 202
Итоги 203
Глава 10. Протокол IP 204
Абстрактная модель IP 204
Размер дейтаграммы IP 207
Фрагментация в IP 209
Структура дейтаграмм IP 210
Структура заголовка IP 211
Сетевой порядок байтов 238
Трассировка IP 239
Итоги 247
Глава 11. Транспортные протоколы 248
Протокол TCP 248
Возможности TCP 250
Программная среда хостов TCP 258
Открытие и закрытие соединений TCP 260
Структура пакета TCP 261
Адаптивный тайм-аут в TCP 275
Снижение последствий перегрузки сети в TCP 278
Борьба с синдромом мелкого окна 279
Разрыв соединений TCP 282
Конечный автомат TCP 283
Протокол UDP 298
Структура заголовка UDP 300
Иерархия UDP и инкапсуляция 301
Трассировка UDP 302
Итоги 304
Глава 12. IPv6 306
Дейтаграмма IPv6 307
Классификация приоритетов 309
Потоковые метки 310
128-разрядные IP-адреса 311
Заголовки расширения IP 312
Хосты с несколькими IP-адресами 320
Направленные, групповые и альтернативные адреса 321
Переход с IPv4 на IPv6 323
Итоги 325
Глава 13. Маршрутизация в сетях IP 326
Основы маршрутизации 326
Статическая маршрутизация 327
Недостатки статической маршрутизации 328
Дистанционно-векторная маршрутизация 331
Топологическая маршрутизация 334
Согласование в сетях IP 336
Адаптация к топологическим изменениям 337
Время согласования 342
Построение маршрутов в сетях IP 343
Хранение альтернативных маршрутов 344
Механизм инициирования обновлений 344
Маршрутные метрики 345
Итоги 346
Глава 14. Шлюзовые протоколы 347
Шлюзы, мосты и маршрутизаторы 347
Шлюз 348
Мост 348
Маршрутизатор 349
Автономная система 349
Знакомство со шлюзовыми протоколами 349
Протоколы IGP и EGP 350
Протокол GGP 350
Протокол EGP 351
Протоколы IGP 352
Итоги 352
Глава 15. Протокол RIP 353
RFC 1058 353
Формат пакета RIP 354
Таблица маршрутизации RIP 356
Механика работы RIP 358
Вычисление расстояний 360
Обновление таблицы маршрутизации 365
Проблемы адресации 367
Топологические изменения 370
Согласование 371
Проблема бесконечного отсчета 373
Недостатки RIP 382
Ограничение количества переходов 382
Фиксированные метрики 382
Высокий уровень трафика при обновлении таблиц 383
Медленное согласование 383
Отсутствие распределения нагрузки 383
Итоги 384
Глава 16. Протокол OSPF 385
Происхождение OSPF 385
Принципы работы OSPF 386
Зоны OSPF 387
Типы маршрутизации 389
Межсетевая маршрутизация 390
Обновление маршрутных данных 391
Знакомство со структурами данных OSPF 394
Пакет подтверждения состояния канала 400
Построение маршрутов 401
Автоматическое вычисление 401
Использование стоимости маршрутов по умолчанию 402
Ручная настройка значений 403
Дерево кратчайших путей 404
Дерево кратчайших путей для маршрутизатора 3 404
Дерево кратчайших путей для маршрутизатора 2 406
Итоги 407
Глава 17. Протокол IPP 408
История IPP 408
Протокол IPP с точки зрения пользователя 409
Реализация IPP от HP 411
Итоги 412
Глава 18. Протоколы удаленного доступа 413
Удаленное подключение 413
ISDN 414
Кабельные модемы 414
DSL 416
Радиосети 417
RADIUS 417
Аутентификация RADIUS 418
Транспортировка дейтаграмм IP в протоколах SUP, CSLIP и РРР 420
Протокол SLIP 420
Протокол CSLIP 421
Протокол РРР 422
Туннелирование удаленного доступа 427
Протокол РРТР (Point-to-Point Tunneling) 428
Агрегирование сеансов РРР 429
Отдельный управляющий канал 430
Поддержка других протоколов 431
Аутентификация и защита 431
Типы туннелей РРТР 431
Добровольный туннель 431
Принудительный туннель 432
Туннельный протокол уровня 2 (L2TP) 433
IPSec 439
Итоги 442
Глава 19. Брандмауэры 444
Безопасность сети 444
Функции брандмауэров 446
Использование брандмауэров 446
Прокси-серверы 447
Пакетные фильтры 448
Защита служб 449
Электронная почта (SMTP) 449
HTTP: World Wide Web 450
FTP 450
Telnet 451
Usenet: NNTP 452
DNS 452
Построение собственного брандмауэра 452
Использование коммерческих брандмауэров 453
Итоги 456
Глава 20. Сетевая и системная безопасность 457
Шифрование 458
Шифрование с парными ключами 459
Шифрование с симметричным закрытым ключом 460
DES, IDEA и другие 461
Аутентификация с применением цифровых подписей 463
Раскрытие шифров 464
Защита сети 465
Вход в систему и пароли 466
Разрешения доступа к файлам и каталогам 466
UUCP в системах Unix и Linux 468
Приготовьтесь к худшему 469
Итоги 469
Глава 21. Общая конфигурация 470
Установка сетевой платы 470
Сетевые платы 471
Настройка ресурсов 472
Установка программного обеспечения сетевой платы 473
Редиректоры и API 474
Службы 475
Сетевые интерфейсы 476
Сетевые и транспортные протоколы 476
Обязательные параметры конфигурации IP 476
Настройка адреса основного шлюза 478
Настройка адреса сервера имен 479
Настройка адреса почтового сервера 479
Регистрация доменного имени 480
Разновидности конфигурации IP 480
Настройка таблицы маршрутизации 481
Инкапсуляция внешних протоколов 482
Итоги 483
Глава 22. Настройка TCP/IP в Windows 95 и Windows 98 485
Сетевая архитектура Windows 98 485
Установка сетевой платы 486
Мастер установки нового оборудования 487
Изменение параметров конфигурации сетевой платы 489
Если Windows 98 не загружается 490
Настройка TCP/IP в Windows 98 491
Сбор предварительной информации 491
Установка TCP/IP 492
Настройка реализации TCP/IP от Microsoft 492
Статические конфигурационные файлы 498
Настройка реестра 498
Тестирование TCP/IP 502
Итоги 504
Глава 23. Настройка TCP/IP в Windows 2000 505
Установка TCP/IP 505
Настройка IP-адреса 507
Назначение IP-адресов при отказе сервера DHCP 510
Настройка параметров DNS 510
Настройка адресов WINS 514
Безопасность и фильтрация TCP/IP 516
Настройка служб разрешения имен 518
Службы NetBIOS 519
Механизмы разрешения имен 521
Настройка кэша имен NetBIOS 523
Настройка широковещательных запросов на разрешение имен 524
Настройка файла LMHOSTS 526
Настройка файла HOSTS 532
Другие служебные файлы TCP/IP 533
Файл NETWORKS 533
Файл PROTOCOL 534
Файл SERVICES 535
Установка и настройка службы сервера FTP 538
Установка и настройка службы сервера FTP на сервере Windows 2000 539
Настройка TCP/IP для печати из Windows 2000 на принтерах Unix 541
Установка и настройка сетевой печати TCP/IP 541
Печать в Windows 2000 из клиентов Unix 543
Программы командной строки TCP/IP 544
Итоги 547
Глава 24. Поддержка IP в Novell NetWare 548
Novell иТСР/IP 548
IPnNetWare4 548
NetWare 5 и NetWare 6 549
Традиционные решения: IP в NetWare 3.x-4.x 550
IP Tunneling 551
IP Relay 551
LAN Workplace 552
IPX-IPGateway 552
NetWare/IP 553
NetWare 5/NetWare 6 — IP и все удобства Novell 554
Полноценная поддержка IP 554
Поддержка нескольких протоколов 554
Варианты установки 555
Установка NetWare 5 и NetWare 6 для IP 555
Что необходимо знать перед установкой 556
Установка NetWare 5 и NetWare 6 для IPX 557
Что необходимо знать перед установкой 557
Смешанная установка IPX/IP 557
Что необходимо знать перед установкой 558
Средства, упрощающие переход на IP 558
NDS 558
DNS 559
DHCP 559
DDNS 559
SLP 559
Режим совместимости 560
Migration Agent 560
Стратегии перехода 560
Тестовая платформа 561
Возможные сценарии перехода 561
Итоги 562
Глава 25. Настройка TCP/IP в системе Linux 563
Подготовка системы к настройке TCP/IP 564
Доступ к сетевому интерфейсу 566
Настройка интерфейса обратной связи 567
Настройка интерфейса Ethernet 569
Служба имен 571
Шлюзы 573
Графические программы настройки сетевых интерфейсов 574
Программа netcfg 575
Программа linuxconf 575
Настройка SLIP и РРР 578
Настройка фиктивного интерфейса 579
Настройка SLIP 580
Настройка РРР 581
Итоги 583
Глава 26. Whois и Finger 584
Протокол Whois 584
Регистрация имен в Интернете 585
Базы данных Whois 586
Примеры 589
Расширения Whois 592
RWhois 592
WHOIS++ 592
Finger 592
Команда finger 593
Демоны Finger 595
Finger в других системах 596
Необычное применение Finger 596
Итоги 598
Глава 27. Протоколы пересылки файлов 599
Роль FTP и TFTP в современном мире 599
Пересылка файлов через FTP 600
Подключения FTP 600
Управляющий порт 601
Порт данных 602
Подключение с использованием клиентов FTP 603
Интерактивный режим FTP 604
Безопасность при использовании FTP 612
Серверы и демоны FTP 615
Анонимный доступ FTP 616
TFTP 618
Отличия TFTP от FTP 618
Команды TFTP 619
Итоги 619
Глава 28. Telnet 620
Знакомство с протоколом Telnet 620
Виртуальный терминал 622
Демон Telnet 623
Использование Telnet 625
Команда telnet в системе Unix 625
Графические клиенты Telnet 626
Команды Telnet 627
Примеры использования Telnet 629
Дополнительные возможности Telnet 630
Безопасность 630
Приложения Telnet 631
Работа с другими службами TCP/IP через Telnet 633
Итоги 635
Глава 29. Инструментарий удаленного доступа 636
R-команды 636
R-команды и безопасность 637
Запрет использования г-команд 637
Альтернативы для г-команд 640
Справочник г-команд 641
Демоны г-команд 641
rsh 641
rep 642
rlogin 642
rup 643
ruptime 643
rwho 643
rexec 644
Другие файлы 644
Функциональность г-команд на других платформах 646
Итоги 647
Глава 30. Протоколы совместного доступа к файловой
системе: NFS и SMB/CIFS 648
Что такое NFS? 648
Краткая история NFS 649
Почему NFS? 649
Реализация —как работает NFS 649
RPCnXDR 650
Жесткое и мягкое монтирование 650
Файлы и команды NFS 651
Демоны NFS 651
Служебные файлы NFS 654
Серверные команды NFS 656
Создание общих ресурсов 656
Отключение общих ресурсов 658
Клиентские команды NFS 659
Демонтирование ресурсов NFS 661
Пример: организация совместного доступа и монтирование файловой системы NFS . . . 662
Распространенные проблемы NFS и их решения 663
Ошибки при монтировании ресурсов 663
Ошибки при демонтировании ресурсов 664
Жесткое и мягкое монтирование 664
Другие протоколы и продукты 664
WebNFS 665
PC-NFS и другие клиентские программы 665
SMBhCIFS 665
Другие продукты 666
Итоги 666
Глава 31. Интеграция TCP/IP с прикладными службами ..... 667
Применение браузера на представительском уровне 668
Интеграция TCP/IP с унаследованными приложениями 669
Использование TCP/IP в других сетях 669
NetBIOS и TCP/IP 670
IPXnUDP 671
Итоги 671
Глава 32. Почтовые протоколы Интернета 672
Электронная почта 672
История электронной почты 672
Стандарты и их разработчики 673
Х.400 673
SMTP 675
MIME и SMTP 675
Другие стандарты кодировки двоичных данных 676
Команды SMTP 676
Коды состояния SMTP 677
Расширение SMTP 678
Заголовки SMTP 679
Достоинства и недостатки SMTP 679
Получение почты с применением POP и IMAP 680
Протокол POP 681
Протокол IMAP 681
Сравнение РОРЗ с IMAP4 682
Нетривиальные возможности электронной почты 683
Безопасность 683
Спам и другие нежелательные сообщения 686
Анонимный сервис электронной почты и пересылка 686
Итоги 687
Глава 33. Служба HTTP 688
Worldwide Web 688
Краткая история Web 688
Создатели и попечители Web 688
Стремительное развитие Web 689
Унифицированные указатели ресурсов 689
Web-серверы и браузеры 691
Протокол HTTP 692
НТТР/1.1 692
MIME и Web 695
Пример сеанса HTTP 696
Нетривиальные возможности Web 696
Средства, работающие на стороне сервера 697
SSLhS-HTTP 697
Языки Web 697
Будущее Web 701
HTTP-ng 701
ПОР 702
IPv6 702
IPP 702
XML 702
Итоги 703
Глава 34. Служба сетевых новостей и протокол NNTP 704
Usenet 704
Конференции и иерархии 705
Протокол NNTP 707
Получение списка конференций 708
Прием сообщений 709
Отправка сообщений 710
Спам и блокировка 711
Итоги 712
Глава 35. Установка и настройка web-сервера 713
Принципы работы web-серверов 713
Терминология web-серверов 714
Популярные web-серверы 716
Установка и запуск web-сервера Apache 717
Загрузка, установка и настройка Apache 717
Компиляция и установка Apache 719
Настройка Apache 720
Запуск и остановка Apache 722
Загрузка двоичных файлов Apache 723
Установка и настройка Apache в двоичном формате 725
Использование Apache для Windows 725
Другие web-серверы 727
Итоги 728
Глава 36. Настройка и оптимизация протоколов в системах
семейства Unix 729
Инициализация системы 729
Процесс inlt и/etc/inittab 729
Сценарии гс 731
Конфигурационные файлы 735
Определение сетевых протоколов в/etc/protocols 735
Имена хостов в/etc/hosts 736
Клиент DNS и файл/etc/resolv.conf 742
Итоги 743
Глава 37. Реализация DNS 744
Серверы имен DNS 744
Ресурсные записи 745
Резольвер 747
Настройка сервера DNS в Unix и Linux 748
Ввод ресурсных записей 748
Остальные файлы DNS 749
Запуск демонов DNS 754
Настройка клиента 754
Windows и DNS 754
Итоги 755
Глава 38. Управление сетью TCP/IP 756
Разработка плана сетевого мониторинга 757
Анализ и диагностика сетевых проблем 758
Средства управления сетью 759
Анализаторы протоколов 759
Экспертные системы 761
Анализаторы на базе PC 762
Поддержка протоколов управления сетью 763
Интеграция со средствами сетевого моделирования 764
Настройка SNMP 765
Настройка SNMP в системе Windows 765
Настройка SNMP в системе Unix 767
Параметры безопасности SNMP 768
Управление сетью и агенты SNMP 768
Инструментарий и команды SNMP 770
RMON и другие модули MIB 771
Выработка требований 772
Построение подробного списка информации 772
Передача списка в службу поддержки 772
Формулировка стратегии построения отчетов 772
Определение показателей, используемых для оповещения об экстренных
ситуациях (в реальном времени) 772
Выбор информации для составления ежемесячных отчетов 773
Выбор информации для оптимизации 773
Обратная связь 773
Реализация требований 774
Оповещение служб поддержки 774
Повторный анализ требований 774
Информирование технической службы 774
Пробные проверки 774
Обучение технической службы 774
Документирование диагностических процедур 775
Упрощение систем управления элементами 775
Использование искусственного интеллекта 775
Итоги 776
Глава 39. Протокол управления сетью SNMP 777
ЧтотакоеБММР? 777
MIB 779
Использование SNMP 780
Unix и SNMP 781
Настройка SNMP в Unix и Linux 782
Команды SNMP 783
Windows и SNMP 784
Windows NT/2000 784
Windows9x/ME 786
Итоги 789
Глава 40. Безопасность передачи данных TCP/IP 790
Планирование сетевой безопасности 790
Что такое сетевая безопасность? 791
Почему важна сетевая безопасность? 792
Уровни безопасности 792
Пароли и файлы паролей 793
Ограничение доступа к паролям 794
Сетевая безопасность 795
Типы атак 795
Меры, обеспечивающие сетевую безопасность 797
Настройка приложений 799
Демон Интернета и файл /etc/inetd.conf 799
Программы шифрования 801
TCP Wrappers 802
Порты 803
Брандмауэры 803
Пакетные фильтры 804
Шлюзы приложений 804
Приложения-фильтры 804
Итоги 804
Глава 41. Инструментарий и методы диагностики 805
Наблюдение за состоянием сети 805
Стандартные утилиты 806
Проверка базового соединения 806
Диагностика проблем на сетевом уровне 810
Проверка маршрутов 813
Проверка службы имен 817
Диагностика сетевого интерфейса 818
Диагностика на сетевом уровне (IP) 819
Параметры конфигурации TCP/IP 819
Диагностика проблем TCP и UDP 825
Проблемы с сокетами 825
Файл SERVICES 826
Диагностика на прикладном уровне 826
Проблемы разрешения имен 827
Итоги 827
Приложение A. RFC и стандарты 828
Информационные ресурсы 828
World Wide Web 828
FTP 829
Электронная почта 829
Бумажные копии 829
Тематический список полезных RFC 829
Общие сведения 830
TCPnUDP 830
IPhICMP 830
Нижние уровни 831
Загрузка 831
DNS 832
Пересылка и доступ к файлам 832
Электронная почта 832
Протоколы маршрутизации 832
Политика и производительность маршрутизации 833
Терминальный доступ 833
Другие приложения 834
Управление сетью 835
Туннелирование 835
OSI 836
Безопасность 836
Разное 836
Список RFC по номерам 836
Приложение Б. Сокращения и акронимы 837
Алфавитный указатель 846
радости в жизни, и моим родителям,
так много сделавшим для меня...
Благодарности
Одна из самых приятных обязанностей автора — выражение благодарности
людям, внесшим вклад в успех книги. Спасибо всем, кто был рядом со мной:
Харприт (Harpreet), Ахал Сингх (Ahal Singh), Теджиндер Каур (Tejnder Kaur),
Харджит (Harjeet), Джагджит 0а&Д0> Куки (Kookie) и Долли (Dolly). Я
особенно благодарен маме, Сен Жермен (Saint Germain), Эль Морья Хану (Е1 Могуа
Khan), Дживалу Кулу (Djwal Kul), Кутуми Лал Сингху (Kuthumi Lai Singh),
Куан-Йину (Kuan-Yin), Бхагавану Кришне (Bhagwan Krishna) и Бабаджи (Babaji).
Без их духовной поддержки эта книга никогда бы не появилась.
Я хочу поблагодарить Боба Санрегрета (Bob Sanregret) и Андерса Амундсо-
на (Anders Amundson), которые когда-то привлекли меня к написанию учебных
материалов на компьютерную тематику. Кроме того, спасибо сотрудникам Higher
Technology и Learning Tree за их помощь и поддержку в различных проектах.
Особую благодарность хочу выразить Филипу Вайнбергу (Philip Weinberg),
Ленин Бернстайну (Lenny Bernstein), доктору Дэвиду Коллинзу (Dr. David Collins),
Эрику Гарену (Eric Garen) и Джону Мориарти (John Moriarty).
Спасибо Дайну Исли (Dayna Isley) за сопровождение этого проекта и
выпускающему редактору Джинни Бесс (Ginny Bess). Также я благодарен Элизабет
Финни (Elizabeth Finney) и Уильяму Вагнеру (William Wagner) за помощь в
работе над книгой.
Введение
Протокол TCP/IP (Transmission Control Protocol/Internet Protocol) стал
фактическим стандартом не только для Интернета, но и для интрасетей. В интрасе-
тях протокол TCP/IP когда-то был лишь одним из многих и существовал
наряду с протоколами Novell IPX/SPX, Microsoft NetBIOS и NetBEUI, а также
AppleTalk. Хотя в наши дни в сетях по-прежнему встречаются другие
протоколы, основным коммуникационным протоколом стал TCP/IP.
Чем обусловлен переход на TCP/IP в интрасетях? Это происходило
постепенно. С развитием серверов Windows NT/2000 и Novell NetWare в них
появилась поддержка TCP/IP. Фирма Microsoft включила стек TCP/IP в Windows 9x
и NT/2000. Одним из преимуществ перехода на единый протокол является
расширение возможностей системной интеграции — например, компьютеры Unix,
Windows и Macintosh могут свободно общаться друг с другом. Переходу на
TCP/IP также способствовала возможность прямого подключения к Интернету
без необходимости преобразования сетевых протоколов. Из-за этого
большинство современных сетей (как гетерогенных, так и Windows-сетей) работает на
основе протокола TCP/IP. Протокол IPX/SPX занимает незначительный сектор
рынка, a NetBEUI используется только в малых и простых сетях Windows.
Впрочем, изменения оказались благоприятными. TCP/IP — один из самых
надежных сетевых протоколов, и он продолжает развиваться. Проблемы
безопасности TCP/IP хорошо известны и исследованы. Для повышения степени
защищенности TCP/IP были созданы новые стандарты (такие, как IPSec). Протокол
TCP/IP реализован почти на всех устройствах, подключаемых к сети. Наконец,
TCP/IP относится к числу открытых стандартов, а это означает, что все
спецификации опубликованы и доступны для всех желающих.
Естественно, развитие Интернета способствовало выдвижению TCP/IP на
ведущее место среди сетевых протоколов. В результате бурного роста World
Wide Web каждый компьютер должен поддерживать TCP/IP, чтобы общаться
с интернет-провайдером. Тем не менее протокол TCP/IP широко использовался
еще до начала революции Web, произошедшей всего несколько лет назад. Многие
из нас еще в начале 1980-х использовали TCP/IP для работы с электронной
почтой, FTP и Usenet на старых системах Unix и СР/М. Тогда для работы с TCP/IP
было недостаточно уметь нажимать две-три кнопки в графическом диалоговом
окне.
В наши дни полки магазинов забиты книгами о TCP/IP, многие из которых
повторяют друг друга. У протокола TCP/IP есть весьма странная особенность:
он очень прост и одновременно очень сложен. Если вам потребуется подключить
компьютер Windows к сети TCP/IP, это делается так просто, что описание
займет пару-тройку страниц. Но если вы захотите поближе познакомиться с
протоколами и стандартными утилитами семейства TCP/IP, для этого не хватит
тысячи страниц. Еще больше должен знать программист, занимающийся
разработкой приложений TCP/IP. Настоящее издание книги ориентируется на
читателя, который хочет познакомиться с протоколами и программами,
используемыми в работе TCP/IP, научиться подключать новые компьютеры к сетям
TCP/IP и знать то, на что следует обратить особое внимание; однако материал,
относящийся к программированию TCP/IP, в книге едва затронут.
Материал книги весьма обширен: мы подробно рассмотрим все базовые
протоколы TCP/IP. Вы увидите, как используются эти протоколы, как TCP работает
на базе протокола IP, который, в свою очередь, базируется на низкоуровневом
сетевом протоколе. В книге будут рассмотрены многочисленные приложения
базовых протоколов TCP/IP. Многие инструменты, используемые для
решения повседневных задач в крупных сетях — DNS (Domain Name System), NFS
(Network File System) и NIS (Network Information System), — работают на базе
протокола TCP/IP. Другие протоколы, предназначенные для
администраторов — такие, как SNMP (Simple Network Management Protocol) и ARP (Address
Resolution Protocol), — тоже основаны на базовых протоколах TCP. Даже такие
простые приложения, как почтовые клиенты, используют протоколы семейства
TCP. Вездесущий стек TCP/IP встречается при выполнении практически всех
повседневных задач. Понимание протокола и принципов его работы поможет
вам лучше разобраться в работе системы.
В этой книге мы постарались изложить материал с позиций, не связанных
с программированием. В книге показано, как работает протокол TCP/IP, как он
взаимодействует с другими протоколами семейства TCP/IP, какие функции он
выполняет в сети и как установить его поддержку на вашем компьютере.
Изложение сопровождается подробными инструкциями по установке и
настройке протоколов и служб. Мы приводим используемые команды и типичные
результаты, которые будут получены при их выполнении. Вы узнаете, как
организовать поддержку TCP/IP во многих операционных системах, таких как
Windows 2000, NetWare и Linux. В книге приводится информация о брандмауэрах
и безопасности. Короче говоря, в книгу включено все, что относится к TCP/IP,
кроме программирования приложений. Надеемся, книга вам понравится.
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу электронной
почты comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На web-сайте издательства http://www.piter.com вы найдете подробную
информацию о наших книгах.
1 Открытые
коммуникации
Марк А. Спортак (Mark A. Sportack)
Безусловно, протокол TCP/IP (Transmission Control Protocol/Internet Protocol)
можно считать самым успешным из всех когда-либо разрабатывавшихся
коммуникационных протоколов. В общем случае термин TCP/IP обозначает целое
семейство протоколов: TCP для надежной доставки данных, UPD (User
Datagram Protocol) для негарантированной доставки, IP (Internet Protocol) и других
прикладных служб.
Наглядным доказательством успеха TCP/IP является Интернет — самая
большая из когда-либо построенных открытых сетей. Первоначально Интернет
проектировался для упрощения оборонных исследований и для того, чтобы
правительство США сохранило систему связи даже в случае возможного ядерного
удара огромной разрушительной силы. Протокол TCP/IP был разработан именно
для этой цели.
Современный Интернет в большей степени ориентируется на коммерческие
и потребительские функции. Несмотря на столь радикальную смену ориентации,
все исходные атрибуты (то есть открытость, повышенная живучесть и
надежность) по-прежнему играют исключительно важную роль. Они обеспечивают
надежную доставку данных с использованием специально разработанных
протоколов (таких, как TCP), а также возможность автоматического обнаружения
и обхода сбойных участков сети. Но что еще важнее, TCP/IP является открытым
коммуникационным протоколом. Открытость означает, что он обеспечивает
связь в любых комбинациях устройств независимо от того, насколько они
различаются на физическом уровне.
Данная глава посвящена происхождению открытых коммуникаций и тем
концепциям, на которых базируется открытый обмен данными. Кроме того, в ней
представлены две основные модели, превратившие теоретические принципы
открытых коммуникаций в реальность: эталонная модель OSI (Open Systems
Interconnect) и эталонная модель TCP/IP. Эти модели существенно упрощают
понимание логики работы сети за счет ее разделения на функциональные
компоненты, объединенных в уровни. Хорошее знание этих уровней и концепции
открытых коммуникаций формирует основу для более осмысленного изучения
компонентов и областей применения TCP/IP.
Эволюция открытых сетей
В своем первоначальном варианте компьютерные сети представляли собой
системы, позволявшие соединять разнородные компоненты и обладавшие закрытой
архитектурой. Если в доисторические времена до появления персональных
компьютеров какая-либо компания пыталась автоматизировать обработку данных
или бухгалтерский учет, она обращалась к одному поставщику и приобретала
целый аппаратно-программный комплекс, готовый к эксплуатации.
В такой закрытой среде, ориентированной на определенную
фирму-поставщика, прикладные программы работали только в окружении, поддерживаемом
определенной операционной системой. Операционная систем работала только
в контексте безопасности оборудования, предоставленного тем же поставщиком.
Даже терминалы конечных пользователей и средства подключения к
центральному компьютеру были частью того же интегрированного решения,
разработанного конкретным поставщиком.
В эпоху безраздельного царствования интегрированных решений
Министерство обороны осознало необходимость надежной и защищенной от ошибок
коммуникационной сети, которая могла бы объединить все входящие в нее
компьютеры, а также компьютеры университетов, научных центров и
фирм-подрядчиков. На первый взгляд задача кажется не такой уж грандиозной, но это
впечатление обманчиво. На заре компьютерных технологий фирмы-поставщики
разрабатывали комплексы из программных, аппаратных и сетевых компонентов
с очень высокой степенью интеграции. Пользователю, пожелавшему
организовать обмен данными с другой платформой, пришлось бы нелегко. Объяснялось
это очень просто: поставщики Министерства обороны хотели привязать к себе
заказчиков.
Заставить всех субподрядчиков Министерства обороны и связанные с ними
научные организации перейти на единый стандарт оборудования было абсолютно
нереально. Соответственно, возникла необходимость в средствах для соединения
разнородных платформ. Так появился первый протокол открытых
коммуникаций: IP (Internet Protocol).
Таким образом, открытой следует считать сеть, обеспечивающую
взаимодействие и совместное использование ресурсов на разнородных компьютерах.
Открытость достигается посредством объединенной разработки и сопровождения
технических спецификаций. Эти спецификации, также называемые открытыми
стандартами, свободно распространяются и доступны для всех желающих.
Многоуровневая структура коммуникаций
Открытые коммуникации возможны только при четком согласовании всех
функций, необходимых для взаимодействия и обмена данными между двумя
конечными системами. Идентификация этих важнейших функций и установление
порядка их выполнения закладывают основу для открытых коммуникаций. Две
системы смогут взаимодействовать только в том случае, если они договорятся
о том, как будет организовано это взаимодействие. Иначе говоря, они должны
следовать общим правилам получения данных от приложения и их упаковки для
передачи по сети. Никакие подробности, даже второстепенные, не могут считаться
сами собой разумеющимися или зависеть от случайностей.
К счастью, существует более или менее логичная последовательность
событий, необходимых для проведения сеанса связи. В минимальном варианте
необходимо выполнить следующие операции:
О Данные передаются от приложения коммуникационному процессу (также
называемому протоколом),
О Коммуникационный протокол должен подготовить данные приложения для
передачи по сети. Обычно при этом данные разбиваются на сегменты более
удобного размера.
О Сегментированные данные заключаются в служебную структуру данных
{конверт) для передачи по сети заданному устройству (или устройствам).
Дополнительная информация, содержащаяся в этой структуре, должна позволить
любому сетевому вычислительному устройству определить, откуда поступил
конверт и куда он передается. В зависимости от используемого протокола эта
структура может представлять собой кадр, пакет или ячейку.
О Кадры (или пакеты) преобразуются в физическое битовое представление для
передачи. Биты передаются в виде световых импульсов по оптоволоконным
сетям (например, FDDI) или в электронном состоянии (наличие/отсутствие
сигнала) по электронным сетям — например, Ethernet или любой другой сети,
в которой данные передаются в электрическом виде по металлическим
проводам.
В точке приема, то есть на компьютере-получателе, эти действия выполняются
в рбратном порядке.
Во время сеанса связи также может возникнуть необходимость и в других
операциях, координирующих действия отправителя и получателя и обеспечивающих
благополучное прибытие данных. К числу таких операций относятся следующие:
О Регулировка объема передаваемых данных, чтобы предотвратить перегрузку
получателя и/или сети.
Q Проверка целостности полученных данных, в ходе которой получатель
убеждается в том, что данные не были повреждены в процессе передачи.
Проверка осуществляется с использованием контрольных сумм — например, по
алгоритму CRC (Cyclic Redundancy Checksum). Полиномиальный
математический алгоритм вычисления контрольной суммы CRC позволяет
обнаруживать ошибки в передаваемых данных.
О Координация повторной передачи данных, которые либо не прибыли по месту
назначения, либо были получены в поврежденном виде.
О Наконец, получатель данных должен заново собрать сегменты в форму,
распознаваемую приложением-получателем. С точки зрения получателя,
принятые данные должны точно совпадать с данными, отправленными
приложением-отправителем. Иначе говоря, результат должен выглядеть так, словно
данные передаются напрямую между двумя приложениями. Данное свойство
называется логической смежностью.
Вероятно, основные принципы многоуровневых коммуникаций, включая
логическую смежность, лучше всего объяснять на примере эталонной модели OSL
Эталонная модель OSI
Международная организация по стандартизации (ISO, International Organization
for Stanartization) разработала эталонную модель взаимодействия открытых
систем (OSI, Open Systems Interconnection) в 1978/1979 годах для упрощения
открытого взаимодействия компьютерных систем. Открытым называется
взаимодействие, которое может поддерживаться в неоднородных средах, содержащих
системы разных поставщиков. Модель OSI устанавливает глобальный стандарт,
определяющий состав функциональных уровней при открытом взаимодействии
между компьютерами.
Эталонная модель OSI разрабатывалась почти 20 лет назад, и лишь немногие
коммерческие системы следовали ее спецификации. В то время производители
компьютерного оборудования стремились привязать клиентов к
запатентованным архитектурам, поддерживаемым одним поставщиком. С точки зрения
производителей конкуренция была нежелательна. Соответственно, все функции как
можно плотнее интегрировались в готовых решениях. Концепция
функциональной модульности или многоуровневой структуры казалась прямо
противоречащей намерениям любого производителя.
Следует заметить, что модель настолько успешно справилась со своими
исходными целями, что в настоящее время ее достоинства уже практически не
обсуждаются. Существовавший ранее закрытый, интегрированный подход уже
не применяется на практике, в наше время открытость коммуникаций считается
обязательной. Как ни странно, очень немногие продукты полностью
соответствуют стандарту OSI. Вместо этого базовая многоуровневая структура часто
адаптируется к новым стандартам. Тем не менее эталонная модель OSI остается
ценным средством для демонстрации принципов работы сети.
Несмотря на все успехи, с эталонной моделью OSI связан ряд устойчивых
заблуждений, поэтому в этом разделе придется привести ее очередной обзор
с указанием и исправлением этих заблуждений.
Первое заблуждение заключается в том, что эталонная модель OSI была
разработана Мелсдународной организацией стандартов (International Standards
Organization). Это не так. Эталонная модель OSI разрабатывалась Международной
организацией по стандартизации (International Organization for Standartization),
а эта организация предпочитает использовать мнемоническое сокращение
вместо акронима. Мнемоника основана на греческом слове isos, которое означает
«равный» или «стандартный».
Модель OSI разделяет процессы, участвующие в сеансе связи, на семь четко
различающихся функциональных уровней. Структура уровней соответствует
естественной последовательности событий, происходящих во время сеанса связи.
На рис. 1.1 изображена схема эталонной модели OSI. Уровни 1-3
обеспечивают доступ к сети, а уровни 4-7 посвящены логистике поддержки
коммуникаций сквозной передачи.
Уровень Номер
OSI OS1
Прикладной уровень 7
Представительский уровень 6
Сеансовый уровень 5
Транспортный уровень 4
Сетевой уровень 3
Канальный уровень 2
Физический уровень 1
Рис. 1.1. Эталонная модель OSI
1. Физический уровень
Нижний уровень модели называется физическим уровнем (physical layer) и
отвечает за передачу битового потока. Физический уровень получает кадры данных
от уровня 2 (канального уровня) и передает их структуру и содержимое; обычно
передача осуществляется последовательно по одному биту. Физический уровень
также отвечает за побитовый прием входящих потоков данных. Затем этот поток
передается канальному уровню для повторного формирования кадров.
В сущности, физический уровень имеет дело только с нулями и единицами.
Он не обладает механизмом интерпретации передаваемых или получаемых битов.
Все, что его интересует, — это физические характеристики электрических и/или
оптических средств передачи сигнала. В частности, сюда относится напряжение
электрического тока, используемого для передачи сигнала, тип носителя,
характеристики волнового сопротивления и даже физическая форма коннектора,
подключенного к передающей среде.
Основное заблуждение состоит в том, будто уровень 1 модели OSI включает
компоненты, способные генерировать или передавать коммуникационные сигналы.
На самом деле это не так, поскольку уровень 1 является всего лишь
функциональной моделью. Физический уровень ограничивается процессами и механизмами,
необходимыми для подачи сигнала в передающую среду и для приема сигналов
от этой среды. Его нижней границей является физический коннектор,
подключенный к передающей среде. Сама среда в этот уровень не входит, хотя
различные стандарты локальных сетей (LAN, Local Area Network), такие как 10BASET
и 100BASET, указывают тип передающей среды.
Все средства непосредственной передачи сигнала, сгенерированного
механизмами уровня 1 модели OSI, относятся к передающей среде. Среди примеров
передающей среды можно назвать коаксиальные кабели, оптоволоконные
кабели и витую пару. Вероятно, недоразумение обусловлено тем фактом, что
физический уровень определяет некоторые обязательные характеристики, которыми
должна обладать передающая среда для работы процессов и механизмов,
определенных на физическом уровне.
Соответственно, передающая среда остается за пределами физического уровня.
Иногда ее называют нулевым уровнем эталонной модели OSI.
2. Канальный уровень
Второй уровень эталонной модели OSI называется канальным уровнем (data link
layer). Его задачи, как и задачи всех остальных уровней, делятся на две
категории: прием и передача данных. Он отвечает за достоверность переданных
данных, обычно — по физическому каналу
На передающей стороне канальный уровень отвечает за упаковку
инструкций, данных и т. д. в кадры. Кадр (frame) представляет собой структуру данных,
специфическую для канального уровня; эта структура содержит информацию,
достаточную для успешной передачи данных по физическому каналу (например,
по локальной сети) к точке приема.
Успешная доставка означает, что кадр достигает положенного места
назначения без изменений. Следовательно, кадры также должны содержать
информацию для проверки целостности содержимого после доставки.
Гарантированная доставка происходит при выполнении двух условий:
О Узел-отправитель должен получить подтверждение того, что каждый кадр
был принят узлом-получателем без изменений.
О Перед тем как подтверждать прием кадра, узел-получатель должен проверить
целостность его содержимого.
По некоторым причинам переданные кадры могут не достигнуть места
назначения или их содержимое будет искажено и станет непригодным в процессе
передачи. Канальный уровень отвечает за обнаружение и исправление всех подобных
ошибок. Также он отвечает за повторную сборку двоичного потока, полученного
от физического уровня, и формирование кадров. Впрочем, если учесть, что в
кадрах передается как управляющая информация, так и содержимое, канальный
уровень на самом деле не восстанавливает кадры, а просто накапливает
поступающие биты до получения полного кадра.
Уровни 1 и 2 обязательны для всех типов коммуникаций, как в локальных,
так и в глобальных сетях. Как правило, функциональность уровней 1 и 2
реализуется сетевым адаптером, установленным внутри компьютера.
3. Сетевой уровень
Сетевой уровень (network layer) отвечает за установление маршрута между
отправителем и получателем. Этот уровень не располагает собственными средствами
обнаружения/исправления ошибок передачи, поэтому он использует средства
надежной пересылки данных уровня 2. Надежность сквозной передачи данных
по нескольким физическим каналам в большей степени относится к функциям
транспортного уровня (уровень 4).
Сетевой уровень используется для установления связи с компьютерными
системами, не входящими в местный сегмент локальной сети. Это возможно
благодаря его собственной архитектуре маршрутной адресации, независимой от
машинной адресации уровня 2. Подобные протоколы называются
маршрутизируемыми. К этой категории относятся протоколы IP, IPX (компания Novell)
и AppleTalk, хотя в этой книге будет рассматриваться исключительно протокол
IP, а также связанные с ним протоколы и приложения.
Использование сетевого уровня при коммуникациях не обязательно. Сетевой
уровень необходим лишь в том случае, если компьютеры находятся в разных
сегментах сети, разделенных маршрутизатором, или взаимодействующие
приложения должны использовать возможности сетевого или транспортного уровня.
Например, два хоста, напрямую подключенных к одной локальной сети, могут
взаимодействовать, ограничиваясь только механизмами локальной сети (уровни
1 и 2 эталонной модели OSI).
ПРИМЕЧАНИЕ
В наши дни необходимость в соединении сетей возникает так часто, что сетевой уровень уже не
считается необязательным. Работа старых протоколов, не обладающих собственной реализацией
сетевого уровня (например, NetBEUI), в современных сетевых архитектурах обеспечивается как
особый случай.
4. Транспортный уровень
Транспортный уровень (transport layer), как и канальный уровень, отвечает за
целостность передаваемых данных. Тем не менее транспортный уровень
способен выполнять эту функцию за пределами местного сегмента локальной сети.
Он обнаруживает пакеты, отвергнутые маршрутизатором, и автоматически
генерирует запрос на повторную передачу. Другими словами, транспортный уровень
обеспечивает настоящую надежность сквозной передачи.
Другая важная функция транспортного уровня — переупорядочивание
пакетов, поступивших с нарушением исходной последовательности. Нарушение
может происходить по разным причинам — например, из-за того, что пакеты
перемещались в сети по разным маршрутам или были повреждены в процессе
пересылки. Так или иначе, транспортный уровень способен определить
исходную последовательность пакетов и расположить их в этой последовательности
перед тем, как передавать их содержимое сеансовому уровню.
5. Сеансовый уровень
Пятое место в модели OSI занимает сеансовый уровень (session layer). Он
используется относительно редко, многие протоколы реализуют его функциональные
возможности на своих транспортных уровнях.
Основная функция сеансового уровня OSI — организация сеанса, то есть
передачи управления во время связи двух компьютерных систем. Сеанс
определяет направленность передачи данных (одно- или двусторонняя), а также
гарантирует завершение обработки одного запроса до принятия следующего.
Сеансовый уровень также может поддерживать некоторые из следующих
дополнений:
О Управление диалогом.
О Управление маркерами.
О Управление операциями.
В общем случае сеанс поддерживает двусторонний (дуплексный) режим обмена
данными. В некоторых приложениях вместо него может понадобиться
односторонний (полудуплексный) режим обмена. Сеансовый уровень позволяет выбрать
нужный режим, и эта возможность называется управлением диалогом.
Для работы некоторых протоколов очень важно, чтобы в любой момент
времени попытки выполнения критических операций могли выполняться только
одной из сторон. Чтобы обе стороны не пытались одновременно выполнить одну
и ту же операцию, необходимо реализовать специальный механизм
управления — например, основанный на использовании маркеров (tokens). В этом
случае выполнение операции разрешается только той стороне, которую в
настоящий момент удерживает маркер. Определение того, на какой стороне находится
маркер и как он передается между двумя сторонами, называется управлением
маркером. Функции управления маркером используются в протоколах
сеансового уровня ISO.
ПРИМЕЧАНИЕ
Не путайте термин «маркер» с похожим термином, существующим в архитектуре Token Ring.
Управление маркером на уровне 5 модели OSI происходит на значительно более высоком уровне.
Архитектура IBM Token Ring работает на 1 и 2 уровнях модели OSI.
Если передача файла между двумя компьютерами занимает один час, а
сетевые сбои происходят примерно каждые 30 минут, скорее всего, переслать файл
вообще никогда не удастся. После каждого аварийного завершения пересылку
приходится начинать заново. Для решения этой проблемы вся пересылка файла
рассматривается как одна операция, а в поток данных вставляются контрольные
точки. В этом случае при возникновении сбоя сеансовый уровень может
продолжить пересылку данных с предыдущей контрольной точки. Эти контрольные
точки называются точками синхронизации.
Точки синхронизации делятся на первичные и вторичные. Первичные точки
синхронизации, вставленные в поток данных любой из взаимодействующих
сторон, должны подтверждаться другой стороной, тогда как вторичные точки
синхронизации подтверждения не требуют. Часть сеанса между двумя первичными
точками синхронизации называется диалоговым блоком, а управление всем
процессом называется управлением операциями. Операция состоит из одного или
нескольких диалоговых блоков.
В сетях TCP/IP отсутствует общий протокол сеансового уровня. Это
объясняется тем, что некоторые характеристики сеансового уровня обеспечиваются
протоколом TCP. Если приложениям TCP/IP потребуются специальные
возможности сеансового уровня, они должны реализовать их самостоятельно. Например,
файловая система NFS (Network File System) самостоятельно реализует сервис
сеансового уровня — протокол RPC (Remote Procedure Call).
ПРИМЕЧАНИЕ
Протокол NFS также использует собственный сервис сеансового уровня — протокол XDR (External
Data Representation).
6. Представительский уровень
Представительский уровень (Presentation Layer) отвечает за управление
кодировкой данных. Во многих компьютерных системах используются разные
схемы кодировки, и представительский уровень должен обеспечить преобразование
между несовместимыми кодировками — такими, как ASCII (American Standard
Code for Information Interchange) и EBCDIC (Extended Binary Coded Decimal
Interchange Code).
Представительский уровень также может использоваться в качестве
промежуточного звена, обеспечивающего преобразование между форматами
представления вещественных чисел, числовыми форматами (например, поразрядным
дополнением до единицы или двойки), порядком следования байтов, а также
предоставляющего возможности шифрования/дешифрования данных.
Представительский уровень обеспечивает представление данных с единым
синтаксисом и семантикой. Если все узлы будут использовать этот общий язык
и понимать его, это предотвратит возможную неправильную интерпретацию
представления данных. Примером такого общего языка является рекомендуемый
OSI язык ASN.l (Abstract Syntax Representation, Rev.l). Кстати говоря, ASN.l
используется протоколом SNMP (Simple Network Management Protocol) для
кодирования данных высокого уровня.
7. Прикладной уровень
На самом верху эталонной модели OSI находится прикладной уровень (application
level). Несмотря на свое название, этот уровень не включает в себя
пользовательские приложения, а лишь обеспечивает взаимодействие этих приложений
с сетевым сервисом.
Этот уровень может рассматриваться как сторона, непосредственно
инициирующая сеанс связи. Предположим, почтовый клиент должен запросить новые
сообщения с почтового сервера. Клиентское приложение автоматически
генерирует запрос к соответствующему протоколу (или протоколам) 7 уровня и
инициирует сеанс связи для получения нужных файлов.
Использование модели
Вертикальное расположение уровней отражает функциональную структуру
процессов и данных, участвующих в передаче. Каждый уровень связывается со
смежными уровнями через интерфейсы. Связь между системами
обеспечивается передачей данных, инструкций, адресов и т. д. между уровнями. Различия
между логической и фактической последовательностю передачей управления во
время сеанса связи показаны на рис. 1.2.
ПРИМЕЧАНИЕ
Хотя эталонная модель состоит из семи уровней, это не означает, что все уровни задействованы
в каждом сеансе связи. Например, обмен данными через один сегмент локальной сети может
производиться исключительно на уровнях 1 и 2, без участия других уровней.
Номер Уровень Уровень Номер
OSI OSI OSI OSI
7 Прикладной уровень Прикладной уровень 7
I 6 I Представительский уровень 1 логическая Представительский уровень I 6
5 Сеансовый уровень передача Сеансовый уровень Т 5
управления —
4 к Транспортный уровень м* hV Транспортный уровень \а 4
3 \ Сетевой уровень Сетевой уровень I/ 3
2 I \ Канальный уровень Канальный уровень /1 2
1 \ Физический уровень Физический уровень / I 1
I 1 ^ 1 I :_ ^—I 1
\
Ч
Хх Фактическая у'
х"^^ передача ^~''
*^-^ управления ^-'''
Рис. 1.2. Логическая и фактическая последовательность передачи
управления в многоуровневой коммуникационной модели
Хотя управление передается по вертикали, каждый уровень воспринимает
это так, словно он может напрямую взаимодействовать со своим аналогом на
удаленном компьютере. Чтобы создать логическую смежность уровней, каждый
уровень стека протоколов компьютера-отправителя добавляет свой заголовок,
который распознается и используется только этим уровнем или его аналогами
на других компьютерах. Стек протоколов компьютера-получателя
последовательно извлекает заголовки по уровням в процессе передачи данных приложению.
Этот процесс проиллюстрирован на рис. 1.3.
Например, сегменты данных упаковываются уровнем 4 компьютера-отправителя
для передачи уровню 3. Уровень 3 преобразует данные, полученные от уровня 4,
в пакеты, снабжает адресами и отправляет протоколу уровня 3
компьютера-получателя через свой уровень 2. Уровень 2 преобразует пакеты в кадры, снабженные
адресами, распознаваемыми локальной сетью. Кадры передаются уровню 1 для
преобразования в поток двоичных цифр (битов), передаваемых уровню 1 получателя.
На компьютере-получателе эта цепочка повторяется в обратном порядке, при
этом каждый уровень удаляет заголовки, добавленные аналогичными уровнями
на компьютере-отправителе. К тому моменту, когда данные достигнут уровня 4,
они имеют ту же форму, в которой они были представлены на уровне 4
отправителя. Соответственно, результат выглядит так, словно два протокола 4 уровня
являются физически смежными и обмениваются данными напрямую.
ПРИМЕЧАНИЕ
Следует учитывать, что многие современные сетевые протоколы используют собственные
многоуровневые модели. Эти модели различаются по степени соответствия стандартам разделения
функций, заявленным в эталонной модели OSI. Довольно часто эти модели объединяют семь
уровней OSI в пять и менее уровней. Кроме того, верхние уровни иерархий часто не соответствуют
в полной мере своим аналогам в модели OSI.
р71+рт| \ "*™»** 7 РтКРт]
I Data I J Hdr. | \ уровень / | Hdr. | | Data |
I Data J Hdr. J | Hdr. | \ W*** / | Hdr. | | Hdr. | Data |
I Layer I Layer I Layer I I Layer I \ rw*»^ / Г^*1 I Layer I Layer | Layer I
776 + 5 \ \^eT / 5 Г в 7 7
I Data J Hdr. [ Hdr. | | Hdr. | \ урмвнь / | Hdr. | | Hdr. | Hdr. | Data |
I Layer I Layer I Layer I layer I I Layer I \ т™шг™гт-^ / I 1дУвг I HwTlayeTTl^TlayeTl
7765 + 4 \ «ранспоршыи /4 + 5677
I Data I Hdr. I Hdr. J Hdr. | | Hdr. | \ уровень / | Hdr | | Hdr. | Hdr. | Hdr. | Data |
I Layer I Layer I Layer I Layer I Layer I I Layer I \ гшпш* /I layer I I Layer I Layer I Layer I Layer I Layer I
7 7 6 5 4 + 3 \ «^ / 3 + 4 5 6 7 7
| Data I Hdr. I Hdr. J Hdr. | Hdr. [ | Data | \ ypoeeHb / | Hdr. | | Hdr. | Hdr. | Hdr. | Hdr. | Data |
I Layer I layer I layer I layer I Layer I layer I [ Layer |\ йцапьмый A l*l&\ I Layer] Layer I Layer I layer I Layer I Layer I
7 7 I 6 5 I 4 3 + 2 \ \~~*ь / 2 + 345677
I Data J Hdr. J Hdr. | Hdr. J Hdr. J Hdr. | | Data | \ wuacno/ | Hdr. | | Hdr. | Hdr. | Hdr. | Hdr. | Hdr. | Data |
------ ------------- ---- -----^^--J^------------------------
layer Layer Layer Layer Layer Layer Layer Layer физи- Layer layer Layer Layer Layer layer layer Layer
7765432 И1 веский 1М2345677
I Data J Hdr. J Hdr. | Hdr. | Hdr. | Hdr. | Hdr. | | Data | ypo- | Hdr. | | Data | Hdr. | Hdr. | Hdr. | Hdr. | Hdr. | Data |
Рис. 1.З. Применение многоуровневых заголовков для поддержки
логической смежности уровней
На самом деле уровень 3 передает данные «вниз» уровню 2, который, в свою
очередь, преобразует кадры в битовый поток. После того как битовый поток
поступает устройству уровня 1 получателя, он передается уровню 2 для
повторного формирования кадров. После успешного завершения приема кадра
служебные данные удаляются, а хранящийся в кадре пакет передается уровню 3
получателя. Информация поступает точно в таком же виде, в котором она была
отправлена. С точки зрения уровня 3 передача данных производилась
фактически напрямую.
Возможность обмена данными между смежными уровнями (с точки зрения
этих уровней) стала одним из факторов, обусловивших успех модели.
Хотя эталонная модель OSI изначально предназначалась для определения
архитектуры протоколов открытых коммуникаций, в этом качестве ее ждал
бесславный провал. В сущности, модель почти полностью выродилась в
академическую абстракцию. Но зато эта модель великолепно подходит для
объяснения концепций открытых коммуникаций и логической последовательности
выполнения необходимых действий в сеансе связи. Для практических целей
существует другая, гораздо более содержательная модель — эталонная модель
TCP/IP. Она описывает архитектуру семейства протоколов IP, являющихся
основной темой настоящей книги.
Эталонная модель TCP/IP
В отличие от эталонной модели OSI, модель TCP/IP в большей степени
ориентируется на обеспечение сетевых взаимодействий, нежели на жесткое разделение
функциональных уровней. Для этой цели она признает важность иерархической
структуры функций, но предоставляет проектировщикам протоколов
достаточную гибкость в реализации. Соответственно, эталонная модель OSI гораздо
лучше подходит для объяснения механики межкомпьютерных взаимодействий, но
протокол TCP/IP стал основным межсетевым протоколом.
Гибкость эталонной модели TCP/IP по сравнению с эталонной моделью OSI
продемонстрирована на рис. 1.4.
Уровень I Номер I Эквивалентный
OSI | OSI J уровень TCP/IP
Прикладной уровень I 7 I
Прикладной
Представительский уровень б уровень
Сеансовый уровень 5
Межхостовой
Транспортный уровень 4 уровень
Сетевой уровень 3 Межсетевой уровень
Канальный уровень 2 Уровень сетевого
т : доступа
Физический уровень 1
Рис. 1.4. Сравнение эталонных моделей TCP/IP и OSI
Эталонная модель TCP/IP разрабатывалась значительно позже описываемого
ей протокола и отличается значительно большей гибкостью, чем модель OSI,
поскольку она в большей степени подчеркивает иерархическое расположение
функций вместо жесткого определения функциональных уровней.
Анатомия модели TCP/IP
Стек протоколов TCP/IP состоит из четырех функциональных уровней:
прикладного, межхостового, межсетевого и уровня сетевого доступа. Эти четыре
уровня приблизительно соответствуют семи уровням эталонной модели OSI с
сохранением общей функциональности.
Прикладной уровень
Прикладной уровень содержит протоколы удаленного доступа и совместного
использования ресурсов. Хорошо знакомые нам приложения — такие, как Telnet,
FTP, SMTP, HTTP и многие другие — работают на этом уровне и зависят от
функциональности уровней, расположенных ниже в иерархии. Любые
приложения, использующие взаимодействие в сетях IP (включая любительские и
коммерческие программы), относятся к этому уровню модели.
Межхостовой уровень
Межхостовой уровень IP приблизительно соответствует сеансовому и
транспортному уровням эталонной модели OSI. К функциям этого уровня относится
сегментирование данных в приложениях для пересылки по сети, выполнение
математических проверок целостности принятых данных и мультиплексирование
потоков данных (как передаваемых, так и принимаемых) для нескольких
приложений одновременно. Отсюда следует, что межхостовой уровень располагает
средствами идентификации приложений и умеет переупорядочивать данные,
принятые не в том порядке.
В настоящее время межхостовой уровень состоит из двух протоколов:
протокола управления передачей TCP (Transmission Control Protocol) и протокола
пользовательских дейтаграмм UDP (User Datagram Protocol). С учетом того, что
Интернет становится все более транзакционно-ориентированным, был
определен третий протокол, условно названный протоколом управления
транзакциями/передачей Т/ТСР (Transaction/Transmission Control Protocol). Тем не менее
в большинстве прикладных сервисов Интернета на межхостовом уровне
используются протоколы TCP и UDP.
Межсетевой уровень
Межсетевой уровень IPv4 состоит из всех протоколов и процедур,
позволяющих потоку данных между хостами проходить по нескольким сетям.
Следовательно, пакеты, в которых передаются данные, должны быть
маршрутизируемыми. За маршрутизируемое™ пакетов отвечает протокол IP (Internet Protocol).
Впрочем, функциональность межсетевого уровня не ограничивается
формированием пакетов. Уровень должен обладать средствами преобразования
адресов уровня 2 в адреса уровня 3, и наоборот. Эти функции обеспечиваются
одноранговыми (peer-to-peer) протоколами, описанными в главе 5.
Кроме того, межсетевой уровень должен поддерживать маршрутизацию и
функции управления маршрутами. Эти функции предоставляются внешними
протоколами, которые называются протоколами маршрутизации. К их числу
относятся протоколы IGP (Interior Gateway Protocols) и EGP (Exterior Gateway
Protocols). Хотя эти протоколы также находятся на межсетевом уровне, они не
являются «родными» протоколами семейства IP. Следует отметить, что многие
протоколы маршрутизации позволяют обнаруживать и строить маршруты в
архитектурах, использующих адресацию с несколькими протоколами маршрутизации.
Другими примерами протоколов маршрутизации с разными архитектурами
адресации являются IPX и AppleTalk.
Уровень сетевого доступа
Уровень сетевого доступа состоит из всех функций, необходимых для
физического подключения и передачи данных по сети. В эталонной модели OSI этот
набор функций разбит на два уровня: физический и канальный. Эталонная
модель TCP/IP создавалась после протоколов, присутствующих в ее названии,
и в ней эти два уровня были слиты воедино, поскольку различные протоколы
IP останавливаются на межсетевом уровне. Протокол IP предполагает, что все
низкоуровневые функции предоставляются либо локальной сетью, либо
подключением через последовательный интерфейс.
Итоги
Представленные в этой главе основные концепции сетей, их функции и даже их
возможные применения — всего лишь начало; эти «строительные блоки» будут
гораздо более подробно рассмотрены в книге. А эта глава всего лишь дает
читателю представление о некоторых основополагающих терминах и концепциях
открытых сетевых коммуникаций.
В главе 2 более подробно освещается роль TCP/IP в Интернете и
рассматриваются различные механизмы, благодаря которым TCP/IP по-прежнему
остается актуальным. Эталонные модели OSI и TCP/IP будут неоднократно
упоминаться в книге.
^ TCP/IP и Интернет
Нил Джеймисон (Neal S.Jamison)
Благодаря протоколу TCP/IP Интернет стал тем, чем он является сегодня. В
результате Интернет произвел в нашем стиле жизни и работы почти такие же
революционные изменения, как печатный станок, электричество или компьютер.
Настоящая глава посвящена истории Интернета, его попечителям и
перспективам будущего развития. В ней рассматривается процесс превращения идей
в стандарты, а также кратко представлены некоторые популярные протоколы
и службы, в том числе Telnet и HTTP.
История Интернета
История Интернета начинается с незапамятных времен. Рисунки на стенах
пещер, дымовые сигналы, голубиная почта — все эти виды связи наводили
наших предков на мысль, что должны существовать более совершенные способы.
Затем появился телеграф, телефон и трансатлантическая беспроводная связь...
и это уже было на что-то похоже. Потом были изобретены первые компьютеры —
громадные устройства, выделяющие уйму тепла. По своей вычислительной
мощности они уступали любому современному карманному калькулятору,
однако эти гиганты помогали выигрывать войны и использовались при переписи
населения. Впрочем, их было очень мало, никто не мог себе купить личный
компьютер и уж тем более — установить его дома.
В 1960-х годах на смену электронным лампам пришли транзисторы, размеры
и стоимость компьютеров начали падать, а интеллект и вычислительная мощность
этих машин стали расти. В это время группа ученых уже начала работать над
проблемой взаимодействия компьютеров. Леонард Клейнрок (Leonard Kleinrock),
в те времена аспирант MIT, предложил концепцию технологии коммутации
пакетов и опубликовал статью на эту тему в 1961 году. Тогда же Управление
перспективного планирования научно-исследовательских работ ARPA (Advanced
Research Project Agency) разрабатывало для себя (и для военных) новую систему
связи, и работа Клейнрока дала необходимый импульс. ARPA объявило конкурс
на создание первой сети с пакетной коммутацией. Контракт достался небольшой
фирме BBN (Bolt Beranek and Newman) из Массачусетса, занимавшейся
акустикой. Так родилась сеть ARPANET. Это произошло в 1969 году.
ARPANET
Исходная сеть ARPANET состояла всего из четырех хостов — по одному в
Калифорнийском университете Лос-Анджелеса, в Стэнфордском
научно-исследовательском институте, в университете Санта-Барбары и университете штата Юта.
Эта маленькая сеть на базе протокола NCP (Network Control Protocol) позволяла
своим пользователям регистрироваться на удаленных хостах, осуществлять
печать на удаленном принтере и передавать файлы. В 1971 году Рэй Томлинсон
(Ray Tomlinson), инженер из BBN, написал первую программу для работы с
электронной почтой.
TCP/IP
В 1974 году, всего через пять лет после рождения ARPANET, Винтон Серф
(Vinton Cerf) и Роберт Кан (Robert Kahn) разработали протокол управления
передачей TCP (Transmission Control Protocol). В начале 1980-х годов протокол
TCP/IP, спроектированный с расчетом на независимость от базового
компьютера и сети, заменил ограниченный протокол NCP, что позволило организовать
взаимодействие с другими разнородными ARPANET-подобными сетями (интер-
нетами). Так родился Интернет.
ПРИМЕЧАНИЕ
Термин «интернет» (со строчной буквы «и») обозначает сеть, состоящую из разнородных
компьютеров. Интернет (с прописной буквы «И») — ТА САМАЯ Сеть, объединяющая миллионы
компьютеров и пользователей.
Распространению TCP/IP способствовало Министерство обороны, которое
выбрало TCP/IP своим стандартным протоколом и потребовало его
обязательного использования фирмами-подрядчиками. Примерно в то же время
разработчики из Калифорнийского университета (Беркли) выпустили новую
разновидность операционной системы Unix, 4.2BSD (Berkeley Software Distribution),
которая распространялась бесплатно. Этот факт благотворно отразился на
протоколе TCP/IP, плотно интегрированном с 4.2BSD. Версия BSD Unix была
заложена в основу других систем семейства Unix, что объясняет господство TCP/IP
в мире Unix.
Протокол TCP/IP обеспечил надежность связи, необходимую для
начального развития Интернета, а ученые и инженеры начали включать в семейство
TCP/IP новые протоколы и приложения. FTP, Telnet и SMTP
поддерживались с самого начала. К числу новых пополнений семейства TCP/IP
относятся ШАР (Internet Mail Access Protocol), POP (Post Office Protocol) и,
конечно, HTTP.
NSF
Исключительно важная роль в становлении Интернета также принадлежит сети
NSFNet. Национальный научный фонд NSF (National Science Foundation)
оценил важность работ по созданию ARPANET и решил создать собственную сеть.
Сеть NSFNet соединяла несколько суперкомпьютеров, установленных в
университетах и правительственных учреждениях. Популярность сети росла, и в NSF
решили увеличить ее возможности за счет модернизации магистральных
каналов связи. Сеть NFSNet начиналась с линий со скоростью 56 кбит/с, перешла
на линии Т-1 A,544 Мбит/с), затем на Т-3 D3 Мбит/с) и вскоре стала самым
быстрым интернетом того времени.
На этом временном отрезке также создавались и другие сети, в том числе
BITNET (Because It's Time Network) и CSNET (Computer Science Research
Network). Сеть ARPANET продолжала расти невероятными темпами, с удвоением
количества хостов за каждый год.
В конце 1980-х и начале 1990-х годов сеть NFSNet заменила старую и более
медленную сеть ARPANET и стала официальной опорной сетью Интернета.
Интернет сегодня
В 1992 году Европейская организация ядерных исследований CERN (Conseil
Europeen pour la Recherche Nucleaire) и Тим Бернерс-Ли (Tim Berners-Lee)
выдвинули концепцию «Всемирной паутины» WWW (World Wide Web). Через
год была выпущена клиентская программа WWW, которая называлась Mosaic.
Эти два события превратили Интернет из текстовой среды, использовавшейся
преимущественно учеными и студентами, в графическую среду, которая сегодня
используется многими миллионами людей.
В апреле 1995 года сеть NFSNet была заменена более современной,
коммерческой опорной сетью. В результате ограничения на подключения к хостам в
Интернете были снижены и появился совершенно новый тип пользователей —
коммерческий пользователь.
Протокол РРР (Point-to-Point Protocol) был создан в 1994 году, а в 1995 году
он получил повсеместное распространение. РРР позволял использовать TCP/IP
в телефонных линиях, что облегчало доступ в Интернет для домашних
пользователей. В то же время стали появляться поставщики услуг Интернета (ISP, Internet
Service Providers), которые обеспечивали подключение к Интернету домашних
пользователей и организаций. Это привело к бурному росту количества
домашних пользователей.
Интернет развивался (и продолжает развиваться!) ошеломляющими
темпами — до 100 процентов в год.
В наши дни даже поверхностное знакомство с WWW наглядно показывает
важность эволюции Интернета. Использование Интернета вышло за рамки
академических и оборонных коммуникаций и научных исследований. Сейчас в
Интернете можно покупать товары и выполнять банковские операции, a Web откры-
вает доступ к всевозможной информации, от кулинарных рецептов до текстов
книг. Перспективы использования Интернета безграничны.
RFC и процесс стандартизации
В процессе эволюции Интернета новые идеи и комментарии представлялись
в виде документов, называемых запросами на комментарии, или RFC (Requests
for Comments). В этих документах обсуждаются многие аспекты коммуникаций,
связанных с Интернетом. Первый документ RFC (RFC 1) назывался «Host
Software» и был написан в апреле 1969 года Стивом Крокером (Steve Crocker),
аспирантом Калифорнийского университета в Лос-Анджелесе и автором восьми
из первых 25 RFC. Тексты первых RFC чрезвычайно интересны для всех, кто
интересуется историей Интернета. Спецификации протоколов Интернета,
определяемые IETF и IESG, также публикуются в форме RFC.
Редактором RFC называется лицо, публикующее RFC и отвечающее за
окончательное рецензирование документов. Роль редактора обсуждается ниже в этой
главе.
Хорошим источником информации обо всех типах RFC является сайт http://
www.rfc-editor.org/.
ПРИМЕЧАНИЕ
Джон Постел (Jon Postel) внес важный вклад в создание ARPANET, а следовательно, и в создание
Интернета. Он участвовал в создании системы доменных имен Интернета и в течение многих
лет занимался ее администрированием; эта система продолжает использоваться и сейчас. Джон
возглавлял Агентство по выделению имен и параметров протоколов Интернета IANA (Internet
Assigned Numbers Authority) и был редактором RFC. Джон скончался в октябре 1998 года. Его
памяти был посвящен RFC 2468 (Винтон Серф, октябрь 1998 года).
Документы RFC являются основным средством распространения новых идей
в области протоколов, исследований и стандартов. Если исследователь хочет
предложить новый протокол, научную работу или учебник по некоторой теме,
он оформляет их в виде документа RFC. Таким образом, к числу RFC
принадлежат описания стандартов Интернета, предложения по пересмотру старых и
внедрению новых протоколов, описания стратегий реализации, учебники, сборники
полезной информации и т. д.
Протоколы, которым суждено стать стандартами Интернета, проходят
несколько стадий в соответствии со степенью завершенности: предложенный
стандарт, проект стандарта и стандарт. По мере развития стандарта объемы
аналитических и тестовых данных растут. После завершения этого процесса протоколу
присваивается определенное число STD, то есть номер нового стандарта.
По мере совершенствования технологий некоторые протоколы заменяются
своими улучшенными версиями или перестают использоваться. Такие протоколы
помечаются как «исторические» («historic»). В некоторых RFC документируются
результаты анализа и разработки новых протоколов, которые помечаются как
«экспериментальные» («experimental»).
Протоколы, разработанные другими стандартизирующими организациями,
конкретными фирмами-поставщиками или частными лицами, также могут
представлять интерес и рекомендоваться для применения в Интернете.
Спецификации таких протоколов также публикуются в виде RFC для удобства и простоты
распространения в Интернет-сообществе. Такие протоколы помечаются как
«информационные» («informational»).
Иногда протоколы получают широкое распространение без одобрения или
участия IESG. В частности, это может быть связано с эволюцией протоколов
по маркетинговым или политическим причинам. Некоторые из этих
протоколов даже начинают играть важную роль в Интернет-сообществе, поскольку
коммерческие организации используют их в своих интрасетях. Согласно
официальной позиции IAB, при эволюции протоколов рекомендуется
использовать процесс стандартизации; тем самым обеспечивается максимальный
уровень совместимости и предотвращается возникновение конфликтных
требований к протоколам.
Не все протоколы должны быть обязательно реализованы во всех системах,
потому что из-за огромного разнообразия существующих систем в некоторых
случаях реализация протоколов не имеет смысла. Например, к таким
устройствам Интернета, как шлюзы, маршрутизаторы, терминальные серверы, рабочие
станции и многопользовательские хосты, предъявляются совершенно разные
требования. Не для всех из них нужны одни и те же протоколы.
Источники информации о RFC
Тексты RFC хранятся в нескольких архивах. Возможно, поиски следует
начинать с индекса RFC. Список индексов приведен в следующем разделе.
Существует несколько способов получения RFC: Web, FTP, Telnet и даже
электронная почта. В табл. 2.1 перечислены некоторые архивы RFC, доступные
через FTP.
Таблица 2.1. Архивы RFC, доступные через FTP
Сайт Имя/Пароль/Каталог
ftp.isi.edu anonymous/name@host.domain/in-notes
wuarchive.wustl.edu anonymous/name@host.domain/doc/rfc
Некоторые архивы также рассылают RFC по электронной почте. Например,
вы можете отправить сообщение по адресу nis-info@nis.nsf.net с пустой строкой
темы и текстом «send rfcnnnn.txt», где пппп — номер нужного RFC.
Как и следовало предполагать, многие архивы также предоставляют доступ
к документам через Web. Если вы захотите воспользоваться этой возможностью,
поиски можно начать с сайта http://www.rfc-editor.org.
За дополнительной информацией о получении RFC обращайтесь по адресу
http://www.isi.edu/in-notes/rfc-retrieval.txt.
Индексы RFC
Полный индекс документов RFC занимает слишком много места, чтобы
приводить его здесь. Впрочем, в Web представлены индексы в форматах ASCII, HTML
и в специальном поисковом формате. Ниже перечислены некоторые примеры:
О Текстовый формат: ftp://ftp.isi.edu/in-notes/rfc-index.txt.
О HTML: ftp://ftpeng.cisco.com/fred/rfc-index/rfc.html.
О HTML by Protocol: http://www.garlic.com/~lynn/rfcprot.htm.
По адресу http://www.rfc-editor.org/rfcsearch.html находится поисковый
механизм RFC.
Краткое знакомство со службами Интернета
Без популярных протоколов и служб — таких, как HTTP, SMTP и FTP —
Интернет был бы просто большим количеством компьютеров, связанных в
бесполезный клубок. В этом разделе кратко описаны самые распространенные (и самые
полезные) протоколы Интернета со ссылками на главы, в которых вы найдете
дополнительную информацию.
Whois и Finger
Служба и протокол Whois предназначены для получения информации о хостах
и доменах Интернета. Обращаясь с запросом к любому из серверов баз данных
Whois, клиенты Whois могут получить разнообразные сведения — контактные
данные узлов и доменов, географические адреса и т. д. Whois используется в
некоторых организациях (особенно в университетах) в качестве электронного
каталога персонала.
Whois находится на хорошо известном порте TCP с номером 43. Подробное
описание приведено в RFC 954.
Служба/протокол Finger предназначены для сбора информации о пользователе
Интернета. В частности, вы можете узнать адрес электронной почты
пользователя, определить, имеются ли у него непрочитанные сообщения и подключен
ли он к Интернету в данный момент, и даже получить частичную информацию
о том, над чем он в данный момент работает. Ввиду специфики этой службы
некоторые администраторы предпочитают отключать ее на своих хостах. Finger
ведет прослушивание на порту TCP с номером 79, а подробное описание
приведено в RFC 1288.
За дополнительной информацией об этих службах обращайтесь к главе 29.
FTP
Служба/протокол FTP (File Transfer Protocol) обеспечивает пересылку файлов
по Интернету. Протокол FTP также относится к числу ранних протоколов, он
появился еще в 1971 году. В наше время FTP повсеместно используется для
предоставления открытого доступа к файлам (через анонимный вход).
Протокол FTP работает на хорошо известных портах TCP с номерами 20 и 21.
Подробное описание приведено в RFC 959.
За дополнительной информацией о FTP и других протоколах пересылки
файлов обращайтесь к главе 30.
Telnet
Программа Telnet предназначена для эмуляции терминала в Интернете. Проще
говоря, Telnet позволяет регистрироваться на удаленных хостах, не беспокоясь
о совместимости терминалов. Telnet также принадлежит к числу самых первых
протоколов и служб раннего Интернета (см. RFC 15). Telnet работает на хорошо
известном порте TCP с номером 23. Подробное описание приведено в RFC 854.
За дополнительной информацией о Telnet обращайтесь к главе 31.
Электронная почта
Протокол SMTP (Simple Mail Transfer Protocol) определяет Интернет-стандарт
для работы с электронной почтой. Многие пользователи ежедневно используют
этот протокол, даже не осознавая этого. SMTP дополняется другими протоколами
и службами (такими, как РОРЗ и ШАР4), позволяющими выполнять операции
с сообщениями на почтовом сервере и загружать их на локальный компьютер
для чтения. Протокол SMTP работает на хорошо известном порте TCP с
номером 25. Подробное описание приведено в RFC 821.
За дополнительной информацией о SMTP, а также других протоколах и
службах для работы с электронной почтой обращайтесь к главе 35.
World Wide Web
Протокол HTTP заложен в основу работы World Wide Web. В сущности, именно
HTTP принадлежит основная заслуга в бурном развитии Интернета в
середине 1990-х годов. Сначала появились первые клиенты HTTP (такие, как Mosaic
и Netscape), которые позволяли наглядно «увидеть» Web. Вскоре стали
появляться web-серверы с полезной информацией. В наше время в Интернете
существует более шести миллионов web-сайтов, работающих на базе HTTP.
Протокол HTTP работает на хорошо известном порте TCP с номером 80, а подробное
описание его текущей версии, HTTP/1.1, приведено в RFC 2616.
За дополнительной информацией о HTTP, а также других протоколах и
службах для работы в Web обращайтесь к главе 36.
Usenet
Служба/протокол NNTP (Network News Transfer Protocol) обеспечивает
публикацию, прием и пересылку новостей Usenet. Несомненно, Usenet — явление
историческое. Это доска объявлений в масштабе Интернета, состоящая из конфе-
ренций (newsgroups) — форумов, в которых обсуждаются всевозможные темы.
Протокол NNTP работает на хорошо известном порте TCP с номером 119, а его
подробное описание приведено в RFC 977.
За дополнительной информацией о NNTP обращайтесь к главе 31.
Интрасети и экстрасети
После произошедшей в 1991 году коммерциализации Интернета корпорации
довольно быстро открыли новые возможности использования Интернета, его
служб и технологий для экономии времени и денег, а также для получения
стратегических преимуществ. Одним из самых масштабных применений этой
технологии в наши дни стали интрасети.
Интрасети
Интрасетью (intranet) называется корпоративная локальная сеть, в которой
основным коммуникационным протоколом является TCP/IP. Прикладные службы
интрасетей основаны на стандартных службах Интернета — HTTP, FTP, TELNET,
SSH и т. д.
Проще говоря, интрасеть представляет собой конечную, замкнутую сеть,
использующую технологии Интернета для совместного использования данных.
Интрасеть может быть подключена к Интернету с установлением контрольных
механизмов, предотвращающих несанкционированный доступ. Впрочем,
интрасеть может вообще не иметь выхода в Интернет.
Преимущества интрасетей
Корпоративные интрасети обладают многими преимуществами. Относительно
низкая стоимость реализации и сопровождения обеспечивает компаниям очень
высокий уровень прибыли на инвестированный капитал. Среди основных
преимуществ интрасетей стоит выделить следующие:
О Интрасети просты в использовании. Пользовательский интерфейс
интрасетей основан на обычном web-браузере, поэтому затраты на обучение
персонала близки к нулю.
О Интрасети упрощают доступ работников к информации. Интрасети позволяют
чрезвычайно эффективно организовать доступ работников к необходимой
информации, будь то одностраничный служебный меморандум или 500-стра-
ничный телефонный справочник.
О Интрасети снижают затраты на подготовку печатных материалов.
Распространение информации в крупной компании или организации традиционно
считалось не только организационно сложной, но и очень дорогой задачей.
О Интрасети расширяют возможности традиционных документов. Найти имя
или название товара в бумажном справочнике или каталоге не так уж сложно,
однако этот процесс часто бывает утомительным и занимающим много
времени.
О Интрасети повышают актуальность данных. После вывода на печать
документ может устареть. Таким образом, возникает опасность распространения
копий устаревших и, возможно, — недостоверных документов.
Приведенный список не исчерпывает всех преимуществ интрасетей.
Компании, установившие у себя интрасети, открыли для себя гораздо больше новых
возможностей, чем перечислено выше. А при использовании таких
Интернет-технологий и служб, как браузеры и web-серверы с открытыми исходными текстами,
все эти преимущества удается реализовать с относительно низкими затратами.
Области применения интрасетей
Возможности применения интрасетей, повышающие эффективность и
производительность труда в организациях, практически безграничны. Ниже перечислены
некоторые популярные области применения интрасетевых технологий.
О Управление кадрами. Многие компании распространяют объявления о
вакансиях, ведут базы данных с информацией о сотрудниках, распространяют
всевозможные документы вроде анкет, табельных листков, отчетов о затратах
и даже уведомлений о перечислении зарплаты на счет — и все это делается
при помощи интрасетей.
О Управление проектами. Руководители проектов могут просматривать и
обновлять электронные таблицы и графики Гантта, опубликованные в интрасети.
Отчеты о состоянии проекта тоже могут публиковаться в интрасети для их
просмотра и рецензирования руководителями.
О Инвентаризационный учет. Публикация инвентарных баз данных в
электронном виде с доступом либо на уровне собственных форматов данных,
либо через специальные приложения.
О Управление файлами. После установки мощного сервера интрасети,
работающего на базе web-технологий, надобность в старом файловом сервере отпадет.
Интрасети удобны для корпоративных пользователей, однако предоставление
доступа к корпоративным интрасетям внешним клиентам тоже приносит пользу.
Так появились экстрасети, описанные в следующем разделе.
Предоставление внешнего доступа к интрасети
Интрасети предназначены для совместного использования информации в
рамках компании или организации. Следующим шагом в развитии этой идеи стали
экстрасети. Экстрасеть (extranet) представляет собой интрасеть,
предоставляющую контролируемый доступ определенной группе внешних пользователей. На
практике экстрасети используются для обмена информацией со стратегическими
партнерами (клиентами, поставщиками или службами доставки). Короче
говоря, экстрасети относятся к сетям класса «бизнес-бизнес».
Некоторые области применения экстрасетей:
О проведение деловых операций на базе EDI (Electronic Data Interchange) или
других технологий;
О взаимодействие с другими организациями в работе над совместными
проектами;
О обмен новостями или другой информацией с партнерами.
Пример: крупная компания, занимающаяся доставкой товаров, может
предоставить торговой компании доступ к своей интрасети, чтобы торговая компания
могла согласовать данные о сроках поставки со своими покупателями.
Будущее Интернета
По мере роста популярности и расширения областей практического применения
Интернета совершенствуются и интернет-технологии. В настоящее время
существует ряд проектов, направленных на улучшение этих технологий. Наиболее
перспективными являются следующие проекты:
О NGI (Next Generation Internet);
О vNBS (Very high-speed Backbone Network Service);
О Internet2 A2).
Все эти проекты более подробно рассматриваются в следующих подразделах.
NGI (Next Generation Internet)
Как сообщил президент Клинтон в своем докладе о положении страны в 1998 году,
инициатива Интернета следующего поколения NGI (Next Generation Internet)
обеспечивает финансирование и координацию работы академических и
федеральных учреждений, направленных на финансирование и построение
интернет-сервиса следующего поколения.
За дополнительной информацией об инициативе NGI обращайтесь на сайт
http://www.ngi.gov.
vBNS
Национальный научный фонд начал работу над созданием экспериментальной
опорной сети с огромной скоростью передачи данных. Этой опорной сети,
оператором которой является MCI WorldCom, было присвоено название vBNS (Very
high-speed Backbone Network Service). В ближайшем будущем vBNS послужит
платформой для тестирования новых, высокоскоростных интернет-технологий
и протоколов. В настоящее время сеть соединяет несколько суперкомпыотер-
ных центров и точек доступа к сети на скоростях ОС-12 F22 Мбит/с) и выше.
В феврале 1999 года компания MCI WorldCom объявила об установке канала
связи ОС-48 B,5 Гбит/с) между Лос-Анджелесом и Сан-Франциско.
Обращайтесь на сайт http://www.vbns.net за дополнительной информацией
о vBNS.
Internet2 A2)
Испытательная сеть Internet2 была создана для того, чтобы университеты,
правительственные и промышленные организации могли совместно разрабатывать
новые интернет-технологии. Партнерские организации связывались
высокоскоростной сетью Abilene (до 9,6 Гбит/с). В 12 также задействована сеть vBNS,
упомянутая в предыдущем разделе.
Обращайтесь на сайт http://www.internet2.edu за дополнительной информацией
о 12. Информация о сети Abilene находится по адресу http://www.ucaid.edu/abilene.
Так кто же главный в Интернете?
Огромные масштабы Интернета и множество высокотехнологичных инициатив,
направленных на его совершенствование, наводят на мысль, что группа,
ответственная за Интернет, трудится не покладая рук. Это не совсем так: никакой группы,
«ответственной» за Интернет, не существует. У Интернета нет директора,
главного администратора или даже президента. Оказывается, Интернет процветает
в условиях анархической, неофициальной культуры 1960-х, в которых он был
рожден. Тем не менее существует ряд групп, которые помогают следить за
развитием технологий Интернета, за процессами регистрации и общими проблемами,
связанными с управлением сетью таких огромных масштабов.
ISOC (Internet Society)
Общество Интернета ISOC (Internet Society) объединяет на профессиональной
основе свыше 150 организаций и 6000 физических лиц из более 100 стран мира.
Эти организации и лица совместно решают вопросы, от которых зависит
нормальная работа Интернета и его будущее. ISOC состоит из нескольких групп,
отвечающих за стандарты инфраструктуры Интернета, в том числе IAB (Internet
Architecture Board) и IETF (Internet Engineering Task Force).
Web-сайт ISOC находится по адресу http://www.isoc.org.
IAB (Internet Architecture Board)
Координационный совет по архитектуре Интернета IAB (Internet Architecture
Board) выполняет функции технического советника при Обществе Интернета.
Эта небольшая группа (кандидаты в члены IAB представляются IETF и
одобряются Советом попечителей ISOC) проводит регулярные заседания, на которых
рассматриваются и вносятся новые идеи и предложения для последующей
разработки в IETF и IESG.
Web-сайт IAB находится по адресу http://www.iab.org.
IETF (Internet Engineering Task Force)
Проблемная группа проектирования Интернета IETF (Internet Engineering Task
Force) является открытым сообществом сетевых проектировщиков,
поставщиков и ученых, работающих над развитием Интернета. IETF проводит заседания
только три раза в год, а большая часть работы выполняется через электронные
списки рассылки. IETF делится на несколько рабочих групп, каждая из которых
занимается определенной темой. К числу рабочих групп IESG принадлежат
группы разработчиков HTTP (Hypertext Transfer Protocol) и IPP (Internet
Printing Protocol).
Группа IETF открыта для всех желающих. Ее web-сайт находится по адресу
http://www.ietf.org.
IESG (Internet Engineering Steering Group)
Исполнительный комитет IETF — IESG (Internet Engineering Steering Group) —
отвечает за техническое руководство деятельностью IETF и процессом выработки
новых стандартов Интернета. IESG также следит за соблюдением правил ISOC
в деятельности IETF. Кроме того, IESG окончательно утверждает спецификации
перед тем, как они принимаются в качестве стандартов Интернета.
За дополнительной информацией о IESG обращайтесь по адресу http://www.
ietf.org/iesg.html.
IANA (Internet Assigned Numbers Authority)
Агентство по выделению имен и параметров протоколов Интернета IANA
(Internet Assigned Numbers Authority) отвечает за назначение IP-адресов и
управление пространством имен доменов. IANA также определяет номера портов
протокола IP и другие параметры. Деятельность IANA осуществляется под
патронажем ICANN.
Web-сайт IANA находится по адресу http://www.iana.org.
ICANN (Internet Corporation for Assigned
Names and Numbers)
Корпорация по выделению имен и параметров протоколов Интернета ICANN
(Internet Corporation for Assigned Names and Numbers) создавалась как часть
проекта по переводу администрирования доменных имен и пространства
IP-адресов на интернациональную основу. Основной целью ICANN является перевод
администрирования доменов и IP-адресов из правительственного в частный
сектор. В настоящее время ICANN участвует в работе над системой SRS (Shared
Registry System), благодаря которой процесс регистрации доменных имен
должен стать открытым для честной конкуренции. Дополнительная информация
о SRS приводится в следующем разделе.
За дополнительной информацией о ICANN обращайтесь по адресу http://
www.icann.org.
InterNIC и другие регистрирующие органы
Информационный центр Интернета InterNIC (Internet Network Information
Center), работающий под управлением Network Solutions, Inc., был основным
регистратором доменов верхнего уровня (.com, .org, .net, .edu) с 1993 года. Надзор
за деятельностью InterNIC осуществляется Национальной администрацией по
телекоммуникациям и информации NTIA (National Telecommunications &
Information Administration), подгруппой Министерства торговли. InterNIC передал
часть полномочий другим официальным регистрирующим органам (таким, как
информационные центры Министерства обороны и Азиатско-тихоокеанского
региона). В последнее время появились новые инициативы, направленные на
дальнейшее разделение полномочий InterNIC. Одна из таких инициатив, SRS
(Shared Registry System), направлена на внесение открытой и честной
конкуренции в процесс регистрации доменов. В настоящее время свыше 60 компаний
выполняют регистрирующие функции в рамках этой инициативы.
Основные регистрирующие органы перечислены в табл. 2.2.
Таблица 2.2. Основные регистрирующие органы Интернета
Имя URL
InterNIC http://www.jnternic.net/
Информационный центр Министерства обороны http://nic.mil
Федеральный регистр США http://nic.gov
Информационный центр Азиатско-тихоокеанского региона http://www.apnic.net
RIPE (Rftseaux IP Europeftns) http://www.ripe.net
Совет регистрирующих органов (CORE, Council of Registrars) http://www.corenic.org/
Register.com http://register.com
Редактор RFC
Запросы на комментарии (RFC) представляют собой серию документов,
которые, среди прочего, определяют стандарты Интернета. Дополнительная
информация о RFC приведена в разделе «RFC и процесс стандартизации» выше в этой
главе.
Редактором RFC называется лицо, публикующее RFC и отвечающее за
окончательное рецензирование документов.
За дополнительной информацией о редакторе RFC обращайтесь на сайт
http://www.rfc-editor.org/.
Поставщики услуг Интернета
Коммерциализация Интернета в 1990 году была радостно встречена
многочисленными поставщиками услуг Интернета, которые горели желанием приобщить
к Интернету миллионы домашних пользователей и организаций. Поставщиком
услуг Интернета, или ISP (Internet Service Provider), называется коммерческая
организация, которая устанавливает интернет-серверы в своих офисах или
машинных залах. Серверы оснащаются модемами и обеспечивают поддержку
протоколов РРР (Point-to-Point Protocol) или SLIP (Serial Line Internet Protocol),
при помощи которых удаленные пользователи подключаются со своих
персональных компьютеров к Интернету.
Поставщики услуг Интернета на коммерческой основе предоставляют
удаленным пользователям доступ к Интернету. Большинство поставщиков также
предоставляет учетную запись электронной почты на своем сервере, а некоторые
даже открывают доступ к командному процессору системы Unix.
Более крупные поставщики обеспечивают коммерческие организации и
других поставщиков высокоскоростными средствами связи (ISDN, усеченными
каналами Т-1 и даже выше).
Итоги
В этой главе рассматривалась история Интернета, путь его развития и другие
сопутствующие темы. Также она дает краткое представление о современном
использовании интернет-технологий, интрасетях и экстрасетях.
Описание процесса стандартизации на базе RFC сопровождается ссылками,
по которым вы найдете тексты RFC для дальнейшего изучения.
Также были описаны самые популярные службы Интернета со ссылками на
последующие главы книги, содержащие дополнительную информацию.
Вы познакомились с организациями, которые привели Интернет к его
современному состоянию и продолжают развивать его в соответствии с изменениями
в технологиях и потребностях пользователей. Трудно предсказать, что ждет
Интернет в будущем. Всего за несколько лет Интернет вырос из крошечной
экспериментальной сети, использовавшейся немногочисленными учеными, в
глобальную сеть с миллионами компьютеров и пользователей. Уверенно можно
сказать только одно: с такими проектами, как NGI, 12 и vBNS, мы еще только
начинаем видеть потенциальные возможности и области практического
применения этой пленительной технологии.
*J Общий обзор TCP/IP
Рима С. Регас (Rima S. Regas)
Протокол TCP/IP встречается повсеместно. Это семейство протоколов, благодаря
которым любой пользователь с компьютером, модемом и договором, заключенным
с поставщиком услуг Интернета, может получить доступ к информации по всему
Интернету. Пользователи служб AOL Instant Messenger и ICQ (также
принадлежащей AOL) получают и отправляют свыше 750 миллионов сообщений в день.
Большая часть этого немыслимого объема информации передается по Интернету.
Именно благодаря TCP/IP каждый день благополучно выполняются многие
миллионы операций — а возможно, и миллиарды, поскольку работа в Интернете
отнюдь не ограничивается электронной почтой и обменом сообщениями. Более
того, в ближайшее время TCP/IP не собирается сдавать свои позиции. Это
стабильное, хорошо проработанное и достаточно полное семейство протоколов,
и в этой главе мы познакомимся с основными принципами его работы.
Все рутинные операции по управлению общим перемещением пакетов
данных в Интернете выполняются TCP и IP — двумя разными протоколами,
работающими в едином комплексе. Оба протокола используют специальные
заголовки, определяющие содержимое каждого пакета, а если пакетов несколько —
сколько еще их следует ожидать. Протокол TCP ориентирован на обеспечение
связи с удаленными хостами. Протокол IP обеспечивает адресацию, чтобы
сообщения доставлялись в точности туда, куда они были адресованы. Преимущества
TCP/IP описаны в следующем разделе.
Преимущества TCP/IP
Протокол TCP/IP обеспечивает возможность межплатформенных сетевых
взаимодействий (то есть связи в разнородных сетях). Например, сеть под
управлением Windows NT/2000 может содержать рабочие станции Unix и Macintosh
и даже другие сети более низкого порядка. TCP/IP обладает следующими
характеристиками:
О Хорошие средства восстановления после сбоев.
О Возможность добавления новых сетей без прерывания текущей работы.
О Устойчивость к ошибкам.
О Независимость от платформы реализации.
О Низкие непроизводительные затраты на пересылку служебных данных.
Протокол TCP/IP изначально проектировался для задач Министерства
обороны, поэтому все перечисленные достоинства скорее относятся к постановке задачи
на проектирование. Например, наличие хороших средств восстановления после
сбоев означает, что в случае уничтожения части сети из-за вторжения или удара
противника ее оставшиеся компоненты должны сохранить полную
работоспособность. То же самое относится и к добавлению новых сетей без прерывания
текущей работы. Устойчивость к ошибкам была реализована таким образом, что в
случае потери информационного пакета на одном маршруте специальный механизм
должен был направить пакет к месту назначения по другому маршруту.
Независимость от платформы означает, что сети и клиенты могут работать под управлением
Windows, Unix, Macintosh, а также любой другой платформы или комбинации
платформ. Эффективность TCP/IP обусловлена главным образом с его низкими
непроизводительными затратами. Производительность играет основную роль
в любой сети, а протокол TCP/IP не имеет себе равных по скорости и простоте.
Уровни и протоколы TCP/IP
Протоколы TCP и IP совместно управляют потоками данных (как входящими, так
и исходящими) в сети. Но если протокол IP просто передает пакеты, не обращая
внимания на результат, TCP должен проследить за тем, чтобы пакеты прибыли
в положенное место. В частности, TCP отвечает за выполнение следующих задач:
О Открытие и закрытие сеанса.
О Управление пакетами.
О Управление потоком данных.
О Обнаружение и обработка ошибок.
Архитектура
Сетевая среда TCP/IP выполняет все операции, перечисленные выше, и
координирует их с удаленными хостами. Протокол TCP/IP проектировался по
модели Министерства обороны, которая состояла только из четырех уровней
вместо семи, как в модели OSI.
Главное различие между структурой уровней OSI и TCP/IP заключается
в том, что транспортный уровень не всегда обеспечивает гарантированную
доставку. На транспортном уровне TCP/IP также поддерживается более простой
протокол UDP (User Datagram Protocol).
Прикладной уровень
Прикладной уровень состоит из таких протоколов, как SMTP, FTP, NFS, NIS,
LPD, Telnet и Remote Login. Области применения этих протоколов хорошо
знакомы большинству пользователей Интернета.
Транспортный уровень
Транспортный уровень состоит из протоколов UDP и TCP. Первый доставляет
пакеты почти без проверки, а второй обеспечивает гарантию доставки.
Сетевой уровень
Сетевой уровень состоит из следующих протоколов: ICMP, IP, IGMP, RIP, OSPF,
EGP и BGP. Протокол ICMP (Internet Control Message Protocol) используется
для передачи информации о проблемах уровня IP и получения значений
параметров IP. Протокол IGMP (Internet Group Management Protocol) предназначен
для управления групповой рассылкой. Протоколы RIP, OSPF, EGP и BGP4
относятся к числу протоколов маршрутизации.
Канальный уровень
Канальный уровень состоит из протоколов ARP и RARP и подсистемы
формирования кадров, обеспечивающей пересылку пакетов.
TCP
Протокол управления передачей TCP (Transmission Control Protocol)
обеспечивает гарантированную доставку пакетов данных и предоставляет услуги связи
приложениям. TCP использует упорядоченное подтверждение приема и при
необходимости организует повторную передачу пакетов.
Заголовок TCP имеет следующую структуру:
16 бит 32 бит
Порт отправителя Порт получателя
Порядковый номер
Номер для подтверждения (АСК)
Смещение зарезервировано U A P R S F Окно
Контрольная сумма Указатель срочности
Параметры и заполнители
Смысл полей заголовка поясняется ниже.
Порт отправителя
Номер порта, с которого был отправлен пакет.
Порт получателя
Номер порта, которому отправлен пакет.
Порядковый номер
Порядковый номер первого октета данных в сегменте.
Номер для подтверждения (АСК)
При установленном бите АСК это поле содержит следующий порядковый
номер, который ожидает получить отправитель сегмента в подтверждение того,
что все предыдущие порядковые номера были переданы успешно. После
установления связи это значение передается всегда.
Смещение
Смещение начала данных (длина заголовка).
Зарезервировано
Поле зарезервировано и не используется, но должно быть обнулено.
Управляющие биты
Список управляющих битов приведен в следующей таблице.
U (URG) Указатель срочности содержит значимые данные
А (АСК) Номер для подтверждения содержит значимые данные
Р (PSH) Функция немедленной доставки
R (RST) Сброс соединения
S (SYN) Синхронизация порядковых номеров
F (FIN) Конец данных
Окно
Количество октетов данных (начиная с указанного в поле АСК), которые могут
быть отправлены без подтверждения успешного приема ранее переданных данных.
Контрольная сумма
16-разрядное дополнение суммы всех 16-разрядных слов заголовка и текста.
Если сегмент содержит нечетное число октетов, последний октет дополняется
нулями для формирования 16-разрядного слова, используемого при вычислении
контрольной суммы. Обратите внимание: заполнители не пересылаются вместе
с сегментом.
Указатель срочности
Управляющее поле, содержимое которого имеет смысл лишь при установленном
бите URG. Указатель срочности обозначает октет данных, связанный со
срочным вызовом отправителя.
Параметры
В конце заголовка могут пересылаться дополнительные параметры. Длина каждого
параметра должна быть кратна 8 битам. Существует два формата параметров:
О Тип параметра (один октет).
О Тип параметра (один октет), длина параметра (один октет) и собственно
данные параметра.
В поле длины параметра учитываются все три поля (то есть тип, длина и
данные). В поле данных содержится вся информация, пересылаемая в качестве
значения параметра. В табл. 3.1 приведены значения полей для трех основных типов
параметров. Параметры учитываются при вычислении контрольной суммы
заголовка IP. Длина списка параметров может быть меньше указанной в поле
смещения, в этом случае оставшаяся часть заголовка после параметра с типом О
заполняется нулями.
Таблица 3.1. Формат параметров
Тип Длина Описание
0 - Конец списка параметров
1 - Нет операции
2 4 Максимальный размер сегмента
Параметр типа 0 обозначает конец всего списка параметров (а не каждого
параметра по отдельности!). Его присутствие обязательно только в том случае,
если список параметров завершается раньше конца заголовка.
Параметр типа 1 предназначен для выравнивания следующего параметра по
границе слова. Никакой полезной информации он не несет.
Параметр типа 2 определяет максимальный размер принимаемых сегментов.
Если параметр не указан, размер сегмента не ограничивается.
IP
Протокол IP управляет доставкой пакетов между серверами и клиентами.
Заголовок IP имеет следующую структуру.
4 бит 8 бит 16 бит 32 бит
Версия Длина ^nlU'iL Общая длина
г заголовка службы -* «-
... ^ Смещение
Индетификатор Флаги фрагмента
СР°К Протокол Контрольная сумма
жизни
Адрес отправителя
Адрес получателя
Параметры и заполнители
Каждое поле содержит информацию о передаваемом пакете IP. Смысл полей
заголовка поясняется ниже.
Версия
Номер версии IP, используемой данным пакетом. В настоящее время повсеместно
используется протокол IP версии 4 (IPv4).
Длина заголовка
Общая длина заголовка. По содержимому этого поля получатель определяет,
когда нужно прекратить чтение заголовка и перейти к чтению данных.
Тип службы (сервиса)
Это редко используемое поле содержит ряд параметров, включая числовой
приоритет пакета. Более высокие значения указывают на необходимость
первоочередной обработки.
Общая длина
Общая длина пакета в октетах. Значение не может превышать 65 535; в
противном случае получатель считает, что содержимое пакета испорчено.
Идентификатор
Идентификатор, назначаемый отправителем для сборки пакета из фрагментов.
Флаги
Первый бит зарезервирован и игнорируется. При установленном флаге DF (Do
Not Fragment) пакет ни при каких условиях не должен фрагментироваться.
Установленный флаг MF (More Fragments) означает наличие других
фрагментов, а в последнем фрагменте этот флаг равен нулю.
Смещение фрагмента
При установленном флаге MF поле определяет позицию текущего фрагмента
в исходном пакете.
Срок жизни
Максимальная продолжительность пересылки пакета. Обычно срок жизни
составляет от 15 до 30 секунд. Если пакет будет отвергнут или потерян при
пересылке, отправитель оповещается об утрате и получает возможность отправить
пакет заново.
Протокол
Числовое обозначение протокола, который должен использоваться при
обработке пакета.
Контрольная сумма
Контрольная сумма, используемая для проверки целостности заголовка.
Адрес отправителя
Адрес хоста, отправившего пакет.
Адрес получателя
Адрес хоста, которому предназначен пакет.
Параметры и заполнители
Поле параметров не является обязательным. Если оно используется, в
параметрах передается информация об использовании защиты, жесткой или свободной
маршрутизации, отслеживания маршрута и временной пометки. Формат
поддерживаемых параметров описан в табл. 3.2. Заполнители обеспечивают
выравнивание конца заголовка по границе двойного слова.
Таблица 3.2. Формат параметров
Класс Номер Описание
О 9 Конец списка параметров
О 2 Защита данных по стандартам Министерства обороны
О 3 Свободная маршрутизация
О 7 Отслеживание маршрута
О 9 Маршрутизация только через заданные узлы
2 4 Временная пометка
Услуги протокола TCP/IP предоставляются через «стек» промежуточных
уровней. Поскольку TCP и IP — это два разных протокола, им нужна общая
среда для выполнения промежуточных преобразований. Как упоминалось ранее
в этой главе, в отличие от семиуровневой модели OSI стек TCP/IP состоит всего
из четырех уровней:
О Прикладной уровень.
О Транспортный уровень.
О Сетевой уровень.
О Канальный уровень.
Ниже кратко описаны основные задачи каждого уровня.
Прикладной уровень
Прикладной уровень объединяет несколько задач, разделенных в иерархии OSI
на три уровня. Все эти задачи (аутентификация, обработка и сжатие данных)
относятся к работе конечного пользователя. Именно на этом уровне
устанавливается связь в почтовых клиентах, браузерах, клиентах Telnet и другие
интернет-приложениях.
Транспортный уровень
Стоит еще раз напомнить, что в отличие от OSI этот уровень не отвечает за
гарантированную доставку пакетов. Его основной задачей является управление
передачей пакетов между отправителем и получателем. Модель OSI гарантирует
проверку пакетов и в случае нарушения их целостности — их повторный запрос
у отправителя.
Сетевой уровень
Сетевой уровень занимается исключительно управлением маршрутизацией
пакетов. На этом уровне принимаются решения о том, куда следует отправить
пакет на основании полученной информации.
Канальный уровень
Канальный уровень управляет сетевыми соединениями и обеспечивает пакетный
ввод/вывод на уровне сети, но не на уровне приложения.
Теперь, когда вы достаточно хорошо представляете, что такое TCP/IP и что
он может, мы переходим к следующей, более осязаемой теме — возможностям,
которые перед вами открывает TCP/IP.
Telnet
Термин «Telnet» (сокращение от «TELecommunications NETwork») обычно
используется для обозначения как приложения, так и самого протокола, что
наделяет его двойным смыслом. Telnet предоставляет в распоряжение пользователя
средства для удаленного входа и прямого выполнения терминальных операций
по сети. Иначе говоря, Telnet обеспечивает прямой доступ к удаленному
компьютеру. Telnet работает на порте 23.
На хосте должен работать сервер Telnet, ожидающий аутентифицированного
удаленного входа. В Windows 9x/NT/2000, BeOS, Linux и других операционных
системах на платформе х86 необходимо установить отдельный сервер Telnet,
настроить его и запустить на прием входящих запросов. Системы на базе MacOS
также требуют отдельного сервера Telnet. Только в системах семейства Unix
имеется собственный сервер Telnet, который обычно называется telnetd (буква
«d» означает «daemon», то есть «демон» — так называется серверное
приложение, работающее в фоновом режиме). На другом конце соединения работает
приложение Telnet, обеспечивающее текстовый или графический интерфейс
для пользовательского сеанса.
ПРИМЕЧАНИЕ
Вообще говоря, в Windows 2000 имеется встроенный сервер Telnet, который вызывается по ссылке
или вводом команды telnet в консоли. Таким образом, в Windows 2000 устанавливать внешний
сервер Telnet не нужно.
FTP
В отличие от протокола Telnet, позволяющего работать на удаленном хосте,
протокол FTP играет более пассивную роль и предназначается для приема и
отправки файлов на удаленный сервер. Такая возможность идеально подходит
для web-мастеров и вообще для всех, кому потребуется пересылать большие
файлы с одного компьютера на другой без прямого подключения. FTP
обычно используется в так называемом «пассивном» режиме, при котором клиент
загружает данные о дереве каталогов и отключается, но периодически
сигнализирует серверу о необходимости сохранять открытый порт.
ПРИМЕЧАНИЕ
Серверы FTP настраиваются по усмотрению web-мастера. Одни серверы предоставляют
анонимным пользователям доступ ко всем областям сервера без ограничений; другие ограничивают
доступ аутентифицированными пользователями; третьи ограничивают анонимный доступ очень
коротким тайм-аутом. Если пользователь не выполняет активных действий, сервер автоматически
разрывает соединение. Если пользователь пожелает продолжить работу на сервере, ему придется
подключиться заново.
В системах семейства Unix поддержка FTP обычно обеспечивается
программами ftpd (буква «d», как и в предыдущем случае, означает «демон») и ftp
(клиентское приложение). По умолчанию протокол FTP работает на портах 20
(пересылка данных) и 21 (пересылка команд). FTP отличается от всех остальных
протоколов TCP/IP тем, что команды могут передаваться одновременно с
передачей данных в реальном времени; у других протоколов подобная возможность
отсутствует.
Клиенты и серверы FTP в той или иной форме существуют во всех
операционных системах. Приложения FTP на базе MacOS имеют графический
интерфейс, как и большинство приложений для системы Windows. Преимущество
графических клиентов FTP заключается в том, что команды, обычно вводимые
вручную, теперь автоматически генерируются клиентом, что снижает
вероятность ошибок, упрощает и ускоряет работу. С другой стороны, серверы FTP
после первоначальной настройки не требуют дополнительного внимания, поэтому
графический интерфейс для них оказывается лишним.
TFTP
Название протокола TFTP (Trivial FTP) выбрано весьма удачно. TFTP является
«бедным родственником» FTP и поддерживает лишь малое подмножество его
функций. Он работает на базе протокола UDP, который в продолжение нашего
сравнения можно назвать «бедным родственником» TCP. TFTP не следить за
доставкой пакетов и практически не обладает средствами обработки ошибок.
С другой стороны, эти ограничения снижают непроизводительные затраты при
пересылке. TFTP не выполняет аутентификации; он просто устанавливает
соединение. В качестве защитной меры TFTP позволяет перемещать только
общедоступные файлы.
Применение TFTP создает серьезную угрозу для безопасности системы.
По этой причине TFTP обычно используется во встроенных приложениях, для
копирования конфигурационных файлов при настройке маршрутизатора, при
необходимости жесткой экономии ресурсов, а также в тех случаях, когда
безопасность обеспечивается другими средствами. Протокол TFTP также
используется в сетевых конфигурациях, в которых загрузка компьютеров производится
с удаленного сервера, а протокол TFTP может быть легко записан в ПЗУ сетевых
адаптеров.
SMTP
Протокол SMTP (Simple Mail Transfer Protocol) является фактическим
стандартом пересылки электронной почты в сетях, особенно в Интернете. Во всех
операционных системах имеются почтовые клиенты с поддержкой SMTP, а
большинство поставщиков услуг Интернета (если не все) использует SMTP для
работы с исходящей почтой. Серверы SMTP существуют для всех
операционных систем, включая Windows 9x/NT/2K, MacOS, семейство Unix, Linux, BeOS
и даже AmigaOS.
Протокол SMTP проектировался для транспортировки сообщений
электронной почты в разных сетевых средах. В сущности, SMTP не следит за тем, как
перемещается сообщение, а лишь за тем, чтобы оно было доставлено к месту
назначения.
SMTP обладает мощными средствами обработки почты, обеспечивающими
автоматическую маршрутизацию по определенным критериям. В частности,
SMTP может оповестить отправителя о том, что адрес не существует, и вернуть
ему сообщение, если почта остается недоставленной в течение определенного
периода времени (задаваемого системным администратором сервера, с которого
отправляется сообщение). SMTP использует порт TCP с номером 25.
NFS
Файловая система NFS (Network File System) создавалась компанией Sun
Microsystems, Inc. для решения проблем в сетях с несколькими операционными
системами. NFS поддерживает только совместный доступ к файлам и является
компонентом многих операционных систем семейства Unix. Кроме того, NFS
хорошо поддерживается большинством других операционных систем.
В NFS версий 1 и 2 в качестве основного транспортного протокола
использовался протокол UDP. Поскольку UDP не обеспечивает гарантированной
доставки, для ненадежных каналов эта задача должна решаться на уровне NFS, а не
на уровне протокола. Из-за этого в некоторых ранних реализациях NFS
существовали проблемы с порчей содержимого файлов.
Начиная с NFS версии 3, в качестве транспортного протокола может
использоваться TCP. Впрочем, появившаяся в NFS 3 поддержка TCP не
оптимизирована. При использовании TCP в качестве транспортного протокола NFS может
использовать надежность TCP для повышения качества доставки по ненадеж-
ным каналам. Соответственно, NFS версии 3 лучше работает в глобальных сетях
и в Интернете.
ПРИМЕЧАНИЕ
Был предложен стандарт NFS версии 4, но в большинстве коммерческих реализаций используется
NFS версий 2 и 3.
«Чистая» реализация NFS не может предотвратить одновременную запись
в файл со стороны нескольких пользователей, что легко приводит к порче
данных, если пользователи не знают о параллельном выполнении операций с файлом.
Тем не менее механизм блокировки файлов, реализованный протоколом NLM
(Network Lock Manager), может использоваться в сочетании с NFS для
организации совместного чтения и записи в файл.
Механизм доступа к файлам через NFS прямолинеен и прозрачен. После
монтирования том NFS становится частью системы конечного пользователя.
Никаких дополнительных шагов не требуется — естественно, не считая
процесса экспортирования, необходимого для синхронизации конфигурации NFS
на сервере и у клиентов. Впрочем, простота этой системы и удобство ее
администрирования оставляют желать лучшего.
SNMP
Протокол SNMP (Simple Network Management Protocol) реализует простые
средства сбора данных о работе маршрутизатора и управления им с
использованием различных протоколов — таких, как UDP, IPX и IP. При любом
обсуждении SNMP важно помнить, что первая буква в названии протокола означает
«Simple», то есть «простой». Действительно, SNMP — само воплощение
простоты. Во-первых, протокол поддерживает только четыре команды — GET,
GETNEXT, SET и TRAP. Первые две команды предоставляют доступ к
информации, а третья позволяет осуществлять удаленное управление некоторыми
функциями маршрутизаторов. Команда TRAP включает режим получения от
устройства информации о проблемах или происходящих событиях.
Сетевые устройства передают информацию о себе через базу управляющей
информации MIB (Management Information Base). Эти данные, описывающие
устройство, передаются станции управления SNMP (SNMP Management Station),
которая поочередно идентифицирует каждое устройство и сохраняет
информацию о нем. Станция управляет всеми SNMP-совместимыми устройствами.
Для каждого устройства запускается агент SNMP, представляющий клиентскую
сторону операций с устройствами. Когда станция управления запрашивает
информацию о порте командой GET, агент возвращает эту информацию.
Протокол SNMP не предназначен для управления всеми сетевыми
устройствами с возможностью точного описания операций. Это простой протокол для
повседневной работы, который позволяет получить нужную информацию без
загрузки 5—6 управляющих интерфейсов. Для отправки сообщений SNMP
использует транспортный протокол UDP.
Место TCP/IP в системе
Итак, теперь вы знаете, какие услуга предоставляет протокол TCP/IP, и
убедились в его гибкости и повсеместном распространении как промышленного
стандарта. TCP/IP используется в Интернете, поэтому в сетях на базе TCP/IP нет
очевидных ограничений на пропускную способность каналов или размер сети.
Вы знаете, какие факторы обусловили успех TCP/IP и какими достоинствами
обладает этот протокол.
Если вы работаете в сети на базе Windows или Unix, то с большой
вероятностью вы уже используете TCP/IP. В ранних версиях NetWare (таких, как
NetWare 2 и 3) используется протокол IPX/SPX. В NetWare 3 была добавлена
серверная поддержка TCP/IP и шлюз IPX-TCP/IP для подключения к
Интернету. В версии 4 появилась более качественная поддержка TCP/IP. NetWare
версий 5 и выше позволяет заменить IPX протоколом TCP/IP и обладает
полноценной поддержкой TCP/IP.
Также стоит рассмотреть возможность модернизации системы, использующей
AppleShare в сетях AppleTalk (версии менее 6.x). К AppleShare IP это не
относится, поскольку в этом серверном пакете протокол TCP/IP уже реализован,
однако в этом случае приходится учитывать фактор затрат. TCP/IP
предоставляет в ваше распоряжение широкий ассортимент возможностей, серверов, служб,
клиентов и т. д. бесплатно или за минимальные деньги.
На установку интрасети TCP/IP можно потратить огромную сумму, но того
же эффекта можно добиться и при гораздо меньших затратах. Начните с выбора
серверной операционной системы — например, Linux. Система распространяется
бесплатно или почти бесплатно, если вы купите один из комплектов поставки.
Наибольшей популярностью пользуются поставки Red Hat, Debian, Mandrake
и Caldera. Система Linux остается бесплатной, но при покупке
перечисленных поставок вы также приобретаете обслуживание и поддержку, специальные
установочные программы и другие дополнения, не входящие в стандартную
поставку Linux.
ПРИМЕЧАНИЕ
Если вы не захотите тратить $60, RedHat Linux можно загрузить бесплатно с сайта, но загрузка
по модему займет очень много времени — поставка RedHat занимает более 160 Мбайт. Быстрее
и проще купить готовую поставку.
Также можно использовать существующую операционную систему, поскольку
для MacOS, Windows 9x/NT/2000/XP написано немало серверов. Одни
распространяются бесплатно, другие стоят от $30 до $2500 в зависимости от
функций, выполняемых продуктом, и типа лицензии. Заодно можно сменить
коммуникационное оборудование, но и того, что у вас есть, должно хватить —
конечно, если вы не собираетесь переходить с текстовых приложений на
графические приложения с трехмерной анимацией, работающие в круглосуточном
режиме.
Концепция интрасети
Преимущественное использование протокола TCP/IP в современных интрасетях
объясняется тремя факторами: затратами на реализацию, скоростью и
возможностью расширения. Реализация TCP/IP может обойтись минимальными
затратами. TCP/IP может работать параллельно со старыми протоколами (AppleTalk,
IPX и т. д.) вплоть до полного завершения перехода; TCP/IP работает быстро
и эффективно, с использованием надежных и проверенных протоколов;
наконец, благодаря удобному механизму пакетной коммутации этот протокол можно
в любой момент расширить.
Кроме того, ваша компания или сеть получит доступ к огромным ресурсам
Интернета. В наше время самым распространенным применением Интернета
является электронная почта, которая по популярности превосходит даже
просмотр web-страниц. Ежедневно в Интернете передаются миллиарды сообщений,
а миллионы интернет-терминалов предоставляют пользователям доступ к
ресурсам, опубликованным в Интернете.
Существует много способов подключения к Интернету, но в настоящее время
чаще всего используется модемное подключение, а в некоторых регионах — DSL
(Digital Subscriber Line) и кабельные модемы. Любой пользователь с аналоговым
модемом может связаться с модемом поставщика услуг Интернета и
подключиться к Интернету, далее остается лишь использовать нужные ресурсы. Самый
популярный протокол канального уровня для модемного подключения
называется РРР (Point-to-Point Protocol). Старый протокол SLIP (Serial Line Interface
Protocol) позволяет создать последовательное подключение к Интернету из
клиентской программы. Позднее протокол SLIP был доработан для сжатия заголовков
TCP/IP; это привело к появлению новой разновидности SLIP, которая
называлась CSLIP (Compressed SLIP). В наше время оба протокола, SLIP и CSLIP,
в основном были вытеснены РРР.
Итоги
Как было показано в этой главе, при пересылке пакета между компьютерами
необходимо учитывать очень много факторов. Вот почему протоколы TCP и IP
работают в столь тесном взаимодействии. Оба протокола выполняют важные
операции, обеспечивающие успешное функционирование Интернета. Также вы
узнали, что стек TCP/IP состоит из нескольких уровней и что каждый уровень
выполняет определенную функцию. Если одно из звеньев этой цепочки даст
сбой, вся работа протокола будет парализована. К счастью, такое происходит
очень редко. Именно из-за своей надежности протокол TCP/IP в той или иной
форме доступен во всех операционных системах.
При этом протокол TCP/IP обладает хорошими характеристиками
масштабируемости и мобильности. Во многих ситуациях, в которых уместно применение
TCP/IP, часто выясняется, что соответствующая поддержка уже существует.
Главное — проанализируйте все активные протоколы, используемые сетевым
объединением, и убедитесь в том, что переход на TCP/IP не приведет к непоправимым
последствиям для пользовательского доступа. В остальном все проще простого.
4 И мена и адреса
в сетях IP
Марк А. Спортак (Mark A. Sportack)
Необходимым условием межсетевого обмена является наличие эффективной
схемы адресации, которая должна соблюдаться всеми участниками. Существует
множество разновидностей схем адресации. Сетевые адреса всегда имеют
числовую форму, но могут выражаться в двоичной, десятичной и даже шестнадцате-
ричной системе счисления. Схема адресации может быть закрытой
(запатентованной) или открытой, чтобы ее могли реализовать все желающие. Кроме того,
она может обеспечивать высокий уровень масштабируемости или намеренно
ограничиваться небольшим сообществом пользователей.
В этой главе рассматривается схема адресации, реализованная в протоколе
IP (Internet Protocol). За последние 20 лет протокол IP прошел серьезный путь
развития, и вместе с ним развивалась схема адресации. В этой главе описана
эволюция схемы адресации IP, а также объясняются ее важнейшие концепции,
в том числе классификация IP-адресов, бесклассовые адреса междоменной
маршрутизации (CIDR), маски и адреса подсетей, а также маски подсетей
переменной длины.
Адресация в протоколе IP
Проблемная группа проектирования Интернета (IETF), занимающаяся развитием
Интернета и IP, решила использовать для идентификации сетей и хостов IP
числовые адреса, удобные для машинной обработки. Таким образом, каждой
сети в Интернете присваивается уникальный числовой идентификатор.
Администратор этой сети должен позаботиться о том, чтобы каждому хосту в сети
также был присвоен уникальный идентификатор.
В исходном варианте — IP версии 4 (IPv4) — используются 32-разрядные
двоичные адреса. IP-адреса обычно записываются в виде четырех десятичных
чисел, разделенных точками (так называемая десятичная запись с точечным
разделением). Каждый компонент IP-адреса представляется одним октетом, то
есть 8-разрядным двоичным числом. Двоичная запись удобна для машинной
обработки, но не для пользователей, поэтому сетевые адреса обычно
записываются в более понятной десятичной форме. По этой причине необходимо хорошо
понимать различия между десятичной и двоичной системами счисления,
поскольку на них базируется вся схема адресации IP. Преобразования между
двоичной и десятичной системами счисления рассматриваются в разделе
«Двоичная и десятичная запись».
Исходная 32-разрядная схема адресации IPv4 означает, что в Интернете
может существовать не более 4 294 967 296 возможных IP-адресов — когда-то
это число B в 32 степени) казалось немыслимо огромным. Неэкономное
расходование адресов (резервирование больших адресных блоков без их
фактического использования, использование классовых адресов и неправильных
масок подсетей и т. д.) оказалось слишком расточительным. Возникла нехватка
адресов. Многие случаи неэкономного расходования, а также меры по
исправлению ситуации станут более понятными после знакомства со схемой
адресации IPv4.
ПРИМЕЧАНИЕ
Работа над новой версией IP близится к завершению. Новая версия, IPv6, использует
принципиально иную схему адресации и шестнадцатеричное представление компонентов, разделяемых
двоеточиями. В IPv6 длина адресов равна 128 байтам, а новая система классификации повышает
эффективность их использования. Учитывая, что на широкое распространение новой версии IP
потребуется несколько лет, в этой книге все примеры приводятся в схеме адресации IPv4.
Дополнительная информация о IPv6 приводится в главе 12.
Двоичная и десятичная запись
В двоичной системе счисления значение, представляемое единичным битом,
зависит от ее положения в числе. В этом отношении она похожа на
общепринятую десятичную систему, в которой крайняя правая цифра определяет
количество единиц в числе, вторая цифра справа — количество десятков, третья —
количество сотен и т. д. По своей значимости каждая цифра в 10 раз превышает
цифру, находящуюся справа от нее.
Но если в десятичной системе используются десять цифр, представляющих
разные значения разрядов (от 0 до 9), то в двоичной системе существует всего
две цифры: 0 и 1. Значение, представляемое этими цифрами, также зависит
от их позиции в числе. Крайняя правая позиция числа представляет значение 1
(в десятичном эквиваленте). Вторая цифра справа представляет значение 2,
третья — 4, четвертая — 8 и т. д. Значимость каждой позиции вдвое превышает
значимость позиции, находящейся справа.
Десятичное представление двоичного числа вычисляется суммированием
десятичных эквивалентов по всем разрядам, содержащим единицы. С
математической точки зрения максимальное значение каждого из четырех октетов адреса
IPv4 в десятичной системе равно 255. Двоичный эквивалент десятичного числа
255 состоит из 8 разрядов, заполненных единицами. Связь между двоичным
и десятичным представлением числа продемонстрирована в табл. 4.1.
Таблица 4.1. Двоичное A1111111) и десятичное B55) представление октетов
8 7 65 4321
Двоичная цифра 1 1 111111
Десятичное значение цифры 128 64 32 16 8 4 2 1
Как видно из таблицы, все биты двоичного адреса заполнены единицами,
поэтому десятичное представление двоичного числа определяется суммированием
десятичных значений, соответствующих восьми столбцам: 128+64+32+16+8+
+4+2+1 = 255.
В табл. 4.2 представлен другой пример преобразования из двоичной системы
в десятичную. На этот раз пятый разряд справа равен нулю, эта позиция
соответствует десятичному значению 16. Следовательно, полученное двоичное число
будет на 16 меньше 255: 128+64+32+8+4+2+1 = 255.
Таблица 4.2. Двоичное A1101111) и десятичное B39) представление октетов
8 7 65 4321
Двоичная цифра 11 101111
Десятичное значение цифры 128 64 32 16 8 4 2 1
Понимание многих аспектов схемы адресации IP, в том числе масок
подсетей, VLSM и CIDR, требует перехода от десятичной системы к двоичной.
Следовательно, для изучения различных вариантов адресации в сетях IP необходимо
хорошо разбираться в этих системах счисления.
Форматы адресов IPv4
Протокол IP был стандартизирован в сентябре 1981 года. В его схеме адресации
учитывалось текущее состояние дел в области информационных технологий, но
ее постарались по возможности ориентировать на будущее развитие. Базовый
IP-адрес представлял собой 32-разрядное двоичное число, разбитое на четыре
октета (8-разрядных двоичных числа).
Для удобства двоичные адреса обычно преобразуются в более знакомую
десятичную систему. Каждый из четырех октетов IP-адреса представляется
десятичным числом от 0 до 255, которые при записи разделяются точками
(десятичная запись с точечным разделением). Таким образом, наименьший адрес,
который может быть представлен в схеме IPv4, равен 0.0.0.0, а наибольший адрес
равен 255.255.255.255. Тем не менее оба эти значения зарезервированы и не
могут назначаться конечным системам. Причины становятся понятны лишь
после знакомства с особенностями реализации структуры этого базового адреса
в протоколе.
Адреса IPv4 делятся на классы в соответствии с размером сети (крупная,
средняя или мелкая). Классы различаются по количеству бит, выделенных для
идентификации сети и хоста. Существует пять классов IP-адресов,
обозначаемых одной буквой алфавита:
О Класс А.
О Класс В.
О Класс С.
О Класс D.
О Класс Е.
IP-адрес состоит из двух частей: идентификатора сети и идентификатора
хоста. Пять классов представляют разные степени компромисса между
количеством сетей и хостов, описываемых этими идентификаторами.
Класс А
Адреса IPv4 класса А предназначены для поддержки очень больших сетей.
Поскольку на момент стандартизации потребность в крупномасштабных сетях
считалась минимальной, структура этих адресов увеличивала до максимума
количество возможных адресов хостов, но существенно ограничивала количество
возможных сетей класса А.
В IP-адресах класса А для определения сети используется только первый октет.
Три оставшихся октета определяют хост. Первый бит адреса класса А всегда
равен 0, поэтому допустимые значения идентификаторов сетей класса А могут
лежать в интервале от 0 до 127 F4+32+16+8+4+2+1 — из суммы исключается
крайний левый разряд, представляющий число 128). Следовательно, в этой схеме
адресации возможно существование не более 127 сетей IP класса А.
Последние 24 бита (то есть три десятичных числа, разделенных точками)
в классе А представляют идентификатор хоста. Таким образом, IP-адреса класса А
лежат в интервале от 1.0.0.0 до 126.255.255.255.
Обратите внимание: идентификатор сети хранится только в первом октете,
а остальные три октета определяют уникальный идентификатор хоста в границах
сети. При определении адресных интервалов они обычно заполняются нулями.
ПРИМЕЧАНИЕ
С технической точки зрения адрес 127.0.0.0 также является адресом сети класса А, но он
зарезервирован для целей тестирования с обратной связью и не может быть присвоен конкретной сети.
Оглядываясь назад, следует признать это решение неудачным, поскольку оно исключает из
использования целую сеть класса А с огромным количеством IP-адресов.
Каждая сеть класса А может поддерживать до 16 777 214 уникальных хостов.
Эта величина была получена возведением 2 в 24 степень с последующим
вычитанием 2. Вычитание необходимо из-за того, что в IP адрес, состоящий из одних
нулей, используется для идентификации сети, а адрес из одних единиц — для
групповой рассылки в этой сети. Структура IP-адреса класса А с выделением
октетов, представляющих идентификаторы сети и хоста, представлена на
следующем рисунке.
Сеть Хост
Октет 12 3 4
ПРИМЕЧАНИЕ
Класс А обычно используется для очень больших сетей — таких, как исходная сеть ARPANET.
Большинство адресов класса А уже выделено, поэтому получить от InterNIC новый адрес сети класса А
очень трудно (если вообще возможно).
Класс В
Адреса класса В предназначены для поддержки средних и крупных сетей.
Допустимые адреса класса В лежат в интервале от 128.1.0.0 до 191.255.255.255.
Математическая логика, лежащая в основе адресации, довольно проста.
Первые два октета в IP-адресе класса В используются для представления
идентификатора сети, а два других октета содержат идентификатор хоста. Первые два
бита первого октета адреса класса В равны 10. Остальные шесть битов содержат
нули или единицы. На математическом уровне первый октет адреса класса В
должен быть меньше либо равен 191 (сумма 128+32+16+8+4+2+1).
Последние 16 бит B октета) определяют идентификатор хоста. Каждая сеть
класса В может содержать до 65 534 уникальных хостов. Эта величина была
получена возведением 2 в 16 степень с последующим вычитанием 2 (адреса,
зарезервированные IP для служебного использования). Данная схема позволяет
определить не более 16 382 сетей IP класса В.
Структура IP-адреса класса В представлена на следующем рисунке.
Сеть I Хост
Октет 12 3 4
ПРИМЕЧАНИЕ
Адреса класса В широко применяются в сетях средних размеров. Многие крупные организации
получили адреса класса В.
Классе
Адреса класса С предназначены для поддержки большого количества мелких
сетей. По своей структуре адреса этого класса противоположны адресам
класса А. Если в классе А сеть задается одним октетом, а остальные три октета
определяют хост, то в адресном пространстве класса С три октета используются для
идентификации сети, а хост задается всего одним октетом.
Первые три бита первого октета адреса класса С равны ПО, что соответствует
десятичному числу 192 A28+64). Таким образом, это число определяет нижнюю
границу адресного пространства класса С. Третий бит соответствует десятичному
числу 32. Равенство этого бита нулю определяет верхнюю границу адресного
пространства. После исключения третьего бита максимальное значение октета
остается равным 223, то есть 225-32. Таким образом, IP-адреса класса С лежат
в интервале от 192.0.0.0 до 223.255.255.255.
Последний октет используется для идентификации хоста. Теоретически
IP-адрес класса С способен поддерживать до 256 уникальных хостов (от 0 до 255), но
на практике остается всего 254 адреса, поскольку значения 0 и 255
зарезервированы. Максимальное количество сетей класса С равно 2 097 150.
ПРИМЕЧАНИЕ
В схеме адресации протокола IP идентификаторы хостов, все компоненты которых равны 0 или
255, зарезервированы. IP-адрес, у которого все биты идентификатора хоста равны 0, определяет
всю сеть. IP-адрес, у которого все биты адреса хоста равны 1, используется для групповой рассылки
по всем системам, входящим в заданную сеть.
Структура IP-адреса класса С представлена на следующем рисунке.
Сеть Хост
Октет 12 3 4
Класс D
Класс D создавался для поддержки групповой рассылки в сетях IP. Этот
механизм используется приложениями, построенными на основе активной рассылки
сообщений группам узлов. Групповой (multicast) адрес представляет собой
уникальный сетевой адрес, отправленные по которому пакеты направляются
заранее определенной группе IP-адресов. Таким образом, одна станция может
сгенерировать серию пакетов, которые будут маршрутизированы нескольким
получателям одновременно. Такой подход гораздо эффективнее, чем создание
отдельной серии пакетов для каждого получателя. Групповая рассылка в сетях IP
давно считается полезным средством из-за заметного снижения сетевого трафика.
Протокол IPv6 также использует групповую рассылку во многих аспектах своей
работы.
Адресное пространство класса D, как и остальные адресные пространства,
ограничено. Первые четыре бита адреса класса D должны быть равны 1110.
Установка первых трех бит первого октета означает, что адресное пространство
начинается с 128+64+32, то есть 224. Исключение четвертого бита означает,
что адреса класса D ограничиваются максимальным значением 128+64+32+8+
+4+2+1=239. Таким образом, IP-адреса класса D лежат в интервале от 224.0.0.0
до 239.255.255.255.
На первый взгляд этот интервал выглядит несколько странно, если учесть,
что верхняя граница задается всеми четырьмя октетами. В обычной
интерпретации это означало бы, что октеты, содержащие идентификаторы хоста и сети,
совместно определяют идентификатор сети. Однако для этого есть причины!
Адресное пространство класса D не используется для связи с отдельными
хостами или сетями.
Адреса класса D предназначены для доставки сообщений группе хостов с IP-
адресами в частных сетях. Следовательно, делить адрес на адреса сети и хоста
по октетам или битам нет смысла. Вместо этого все адресное пространство
используется для идентификации групп IP-адресов (классов А, В и С). В наши
дни предложено несколько новых схем, позволяющих выполнять групповую
рассылку в сетях IP без сложностей, связанных с использованием адресного
пространства класса D.
Структура IP-адреса класса D представлена на следующем рисунке.
Хост
Октет 12 3 4
Класс Е
Адреса класса Е были определены, но IETF зарезервировала их для
собственных исследований, поэтому в Интернете адреса класса Е не выделялись. Первые
четыре бита в адресе класса Е всегда содержат единицы; следовательно,
IP-адреса класса Е лежат в интервале от 240.0.0.0 до 255.255.255.255. Поскольку этот
класс был определен для исследовательских целей, а его использование
ограничивается рамками IETF, дальнейшее изучение этих адресов не обязательно.
Недостатки схемы адресации IPv4
В результате больших различий между количествами IP-адресов в классах
многие потенциальные адреса оставались неиспользованными. Для примера
рассмотрим компанию среднего размера, которой требуется 300 IP-адресов. Одной сети
касса С B54 адреса) недостаточно. В двух сетях класса С адресов более чем
достаточно, но это приводит к созданию двух отдельных сетей в компании и как
следствие — увеличению размеров таблиц маршрутизации в Интернете (для
каждого адресного пространства в таблице создается отдельная запись, даже
если они принадлежат одной организации).
Другой вариант: назначение сети класса В предоставляет все необходимые
адреса в одном домене, но при этом 65 234 адреса остаются неиспользуемыми.
Раньше адреса класса В слишком часто раздавались любым сетям, содержащим
более 254 хостов. Из-за этого адресное пространство класса В стало истощаться
быстрее, чем в других классах.
Возможно, наиболее расточительной практикой была раздача адресных
пространств по запросу. Любая организация, которой требовалось адресное
пространство, просто запрашивала его и заполняла анкету с указанием количества
сетей и хостов в сети. Никто не пытался проверять заявленные цифры, и
многие организации блокировали большие части адресного пространства IPv4
просто на случай, если в будущем возникнет какая-нибудь непредвиденная
потребность.
К счастью, сейчас эта проблема осталась в прошлом. Были разработаны
многочисленные расширения IP, специально предназначенные для повышения эффек-
тивности использования 32-разрядного адресного пространства. Самыми
важными являются следующие расширения:
О Маски подсетей.
О Маски подсетей переменной длины (VLSM, Variable Length Subnet Masks).
О CIDR.
Эти разные механизмы разрабатывались для решения разных проблем. Маски
подсетей фиксированной и переменной длины разрабатывались для того, чтобы
в одной физической сети, подключенной к Интернету, могли существовать
несколько логических сетей. Маски более подробно описаны ниже, в разделе «Маски
подсети переменной длины» этой главы.
Механизм CIDR (Classless InterDomain Routing) предназначался для того,
чтобы ликвидировать неэффективность исходной жесткой схемы разбиения
адресов на классы. Это позволило маршрутизаторам объединять несколько
разных сетевых адресов в одну запись таблицы маршрутизации.
Учтите, что эти два механизма не являются взаимоисключающими; они
могут и должны использоваться вместе.
ПРИМЕЧАНИЕ
Стабильная работа Интернета напрямую зависит от уникальности сетевых адресов, находящихся
в широком использовании. Следовательно, был необходим механизм, который бы гарантировал
эту уникальность. На первых порах ответственность за проверку была возложена на организацию
InterNIC (Internet Network Information Center). Затем эта организация прекратила существование,
а ее обязанности были переданы IANA. Потом агентство IANA также было ликвидировано, и новым
хранителем имен и адресов Интернета стала Корпорация по выделению имен и параметров
протоколов Интернета (ICANN). В настоящее время ICANN создает структуру конкурентной регистрации,
которая позволит коммерческим организациям конкурировать друг с другом за имена и адреса IP.
При этом очень важно проследить за тем, чтобы не происходило дублирование адресов массового
пользования. Дублирование нарушит нормальную работу Интернета и помешает доставке пакетов
по повторяющимся адресам.
Хотя сетевой администратор может произвольно выбрать незарегистрированный IP-адрес,
поступать подобным образом не рекомендуется. Нормальный доступ к хостам с фиктивными
IP-адресами будет возможен только в пределах сети, к которой принадлежат эти хосты. Подключение
к Интернету сетей, содержащих фиктивные адреса, создает потенциальную опасность конфликтов
с организациями, которым это адресное пространство принадлежит по праву. Дублирование
адресов создает проблемы с маршрутизацией и мешает доставке пакетов в правильную сеть.
При наличии брандмауэра в частных сетях могут использоваться дублирующиеся адреса, поскольку
в результате преобразования вместо адресов частной сети подставляется адрес открытого
интерфейса брандмауэра. В этом случае адрес частной сети может иметь дубликат в Интернете.
Некоторые адреса — а точнее, один адрес класса А A0.0.0.0), 16 адресов класса В A72.16.0.0- 172.31.0.0)
и 256 адресов класса С A92.168.0.0-192.168.255.0) — зарезервированы для закрытого
использования в частных сетях.
Специальные IP-адреса
В схеме адресации IP определено несколько специальных адресов. В RFC 1700
приводится специальная запись для представления специальных IP-адресов:
IP-адрес ::= { <идентификатор-сети>, <идентификатор-хоста> }
В этой записи IP-адрес определяется парой чисел: идентификатором сети
и идентификатором хоста.
Значение «-1» означает, что поле заполнено единицами, а значение «О»
указывает на то, что поле заполнено нулями.
Определены следующие специальные IP-адреса:
О { < идентификатор-сети >, 0 }
О { < идентификатор-сети>, -1 >
О { -1, -1 }
О { 0, 0 }
О { 0, <идентификатор-хоста > }
О { 127, < произвольно }
Адреса, в которых поле <идентификатор-хоста> заполнено только нулями или
единицами, не могут использоваться в качестве самостоятельных IP-адресов.
Следовательно, если номер хоста состоит из N бит, для назначения в сети
свободно только 2N - 2 IP-адресов.
Специальные адреса рассматриваются в нескольких ближайших подразделах.
Кроме специальных адресов, перечисленных выше, специальные адреса также
применяются при широковещательной рассылке в подсетях. В этой вводной главе,
содержащей общие сведения об адресации IP, подсети не рассматриваются.
Адресация сети
Хосту TCP/IP не может быть присвоен идентификатор, состоящий из одних
нулей. IP-адреса с нулевым идентификатором хоста обозначают всю сеть.
Специальные адреса этой категории обозначаются записью
{ <идентификатор-сети>, 0 }
Возьмем IP-адрес 137.53.0.0, принадлежащий сети класса В. Как говорилось
выше, в сетях класса В поле <идентификатор-сети> занимает 16 бит B байта, или
первые два десятичных числа в десятичной записи с точечным разделением),
а <идентификатор-хоста> — оставшиеся 16 бит адреса. Следовательно,
специальный адрес 137.53.0.0 определяет всю сеть класса В 137.53.
В адресах класса В 137.53.0.0 и 141.85.0.0 идентификатор хоста равен «0.0».
Таким образом, эти адреса определяют все узлы, входящие в сеть. Адреса {
<идентификатор-сети >, 0 } не могут использоваться в качестве адресов отправителя
или получателя.
Направленная широковещательная рассылка
Идентификатор хоста, заполненный единицами, является признаком адреса
направленной широковещательной рассылки. Такие адреса могут указываться в
дейтаграммах IP как адреса получателя, но ни при каких условиях — как адреса
отправителя. Этот специальный адрес обозначается записью
{ <идентификатор-сети>, -1 }
Адрес направленной широковещательной рассылки описывает все узлы,
входящие в заданную сеть. Таким образом, для сети 137.53 адрес
широковещательной рассылки имеет вид 137.53.255.255. Сеть 137.53 относится к классу В, поле
<идентификатор-хоста> в этом классе занимает 16 бит B байта, или два
последних десятичных числа в десятичной записи с точечным разделением). Если все
16 бит поля < идентификатор-хоста> заполняются единицами, результат
соответствует десятичному значению 255.255.
В примере с сетью 137.53 сетевое оборудование обеспечивает эффективное
выполнение рассылки на аппаратном уровне. В других сетях (например, типа
«точка-точка») эффективная аппаратная поддержка рассылки отсутствует. В этом
случае рассылка реализуется на уровне программных средств IP за счет
дублирования дейтаграммы IP по всем возможным получателям.
Данные направленной рассылки отправляются в сеть, заданную полем <иден-
тификатор-сети>. Если настройка маршрутизаторов разрешает пропускать
направленную рассылку, дейтаграмма IP передается последнему маршрутизатору,
подключенному к итоговой сети с заданным идентификатором. Маршрутизатор
обязан разослать дейтаграмму IP всем узлам сети. Если в итоговой сети
предусмотрена соответствующая аппаратная поддержка, она задействуется для
рассылки дейтаграммы IP.
Если рассылка в других сетях запрещена, маршрутизатор можно настроить
так, чтобы он не пропускал направленную рассылку.
Ограниченная рассылка
Адрес 255.255.255.255 представляет рассылку другого типа — так называемую
ограниченную, или локальную рассылку. Специальный адрес определяется записью
{ -1. -1 }
Ограниченная рассылка может применяться в локальных сетях, когда
рассылаемые дейтаграммы не выходят за пределы маршрутизатора.
При направленной рассылке отправитель должен задать идентификатор сети.
Если рассылка выполняется внутри локальной сети, можно воспользоваться
ограниченной рассылкой, для которой знать идентификатор не обязательно.
Адрес ограниченной рассылки никогда не может указываться как IP-адрес
отправителя; допускается только его использование вместо адреса получателя.
Нулевой IP-адрес
Нулевой IP-адрес представляет собой специальный адрес вида
{ 0. 0 }
Идентификатор сети равен нулю, что соответствует текущей сети. Нулевой
идентификатор хоста представляет текущий хост. Обычно этот специальный
адрес используется тогда, когда узел IP пытается определить собственный
IP-адрес. Например, узлы сети могут использовать протокол ВООТР для назначения
IP-адреса с центрального сервера ВООТР.
При отправке исходного запроса серверу ВООТР узел IP еще не знает свой
IP-адрес и поэтому указывает в адресе отправителя нулевые идентификаторы
узла и хоста. После того как узел узнает свой IP-адрес, он перестает
использовать адрес 0.0.0.0.
Адрес 0.0.0.0 также используется в таблицах маршрутизации для
обозначения IP-адреса маршрутизатора по умолчанию (часто называемого основным
шлюзом).
IP-адрес 0.0.0.0 может использоваться только как отправитель и никогда
не указывается в качестве получателя. Учтите, что в некоторых устаревших
системах адрес, состоящий из одних нулей, используется для локальной
рассылки.
IP-адрес хоста в текущей сети
Если идентификатор сети равен нулю, а идентификатор-хоста отличен от нуля,
адрес относится к заданному хосту в текущей сети.
{ 0, <идентификатор-хоста> }
Если узел сети получает пакет, у которого в IP-адресе получателя
идентификатор сети равен нулю, а идентификатор хоста совпадает с его собственным
идентификатором хоста, узел принимает этот пакет. В этом случае нулевой
идентификатор сети интерпретируется как признак текущей сети.
Обратная связь
Идентификатор сети 127 зарезервирован для адресов обратной связи. Адресом
обратной связи называется специальный адрес вида
{ 127, <произвольно> }
Любой пакет, отправленный приложением TCP/IP по адресу 127.ХХ.Х, где
X — число от 0 до 255, не достигает передающей среды и возвращается
приложению. Пакет копируется из буфера передачи в буфер приема на том же
компьютере, поэтому IP-адрес 127.ХХХ называется адресом обратной связи. Адрес
обратной связи позволяет быстро проверить правильность конфигурации
программных средств TCP/IP. Например, при помощи утилиты ping можно убедиться
в том, что программы уровня IP работают на некотором базовом уровне. Утилита
ping посылает эхо-пакет ICMP по заданному IP-адресу (в данном случае — по
адресу обратной связи). Уровень IP поэтому отвечает на входящий эхо-пакет
и отправляет ответный пакет ICMP.
Обратная связь бывает полезной и в других ситуациях — например, когда
клиент работает на одном компьютере со службой TCP/IP. В этом случае к службе
можно обратиться по адресу обратной связи. Например, типичные команды для
подключения к серверу Telnet или FTP, находящемся на одном компьютере с
клиентом, выглядят так:
telnet 127.0.0.1
ftp 127.0.0.1
Исключение в схеме адресации IP
Выше упоминалось о том, что идентификатор хоста, состоящий из одних
единиц, используется для широковещательной рассылки. Важным исключением
из этого правила составляют программные средства TCP/IP, произошедшие от
BSD 4.2. Многие коммерческие реализации создавались на базе BSD 4.2. При
использовании очень старых программ TCP/IP вы можете столкнуться с этим
исключением.
В BSD Unix для задания адреса широковещательной рассылки
идентификатор хоста заполнялся нулями. На момент написания BSD 4.2 в документах RFC
недостаточно четко определялись правила широковещательной адресации.
Недостаток был исправлен в более поздних RFC, где было сказано, что в адресах
широковещательной рассылки идентификатор хоста должен заполняться
единицами. Версия BSD 4.3 была модифицирована в соответствии с RFC. Программы,
написанные для BSD 4.2 и не исправленные впоследствии, могут использовать
схему с нулями. Если хосты, использующие нули в широковещательных
адресах, находятся в одной физической сети с хостами, использующими единицы,
механизм широковещательной рассылки может работать не так, как ожидается,
что приведет к ошибкам в работе приложений TCP/IP в этой сети.
Появление подсетей
Первоначально в Интернете использовалась двухуровневая иерархия, а адреса
состояли только из идентификаторов сети и хоста. На рис. 4.1 изображена
небольшая и простая двухуровневая сеть. Подобная иерархия предполагает, что
в каждом подразделении работает только одна сеть. Следовательно, для каждого
подразделения достаточно одного подключения к Интернету. На первых порах
эти предположения были вполне реальными, но постепенно сети развивались
и расширялись. В 1985 году уже нельзя было с уверенностью предполагать, что
организация использует только одну сеть или будет довольствоваться одним
подключением к Интернету.
По мере появления подразделений с несколькими сетями появилась очевидная
необходимость в механизме, который бы различал логические сети, создаваемые
в подразделениях второго уровня Интернета. Отсутствие такого механизма делало
невозможной эффективную маршрутизацию данных в подразделениях с
несколькими сетями. Ситуация продемонстрирована на рис. 4.2.
Одно из возможных решений заключалось в предоставлении каждой
логической сети (или подсети) отдельного диапазона IP-адресов. Такое решение
работает, но оно привело бы к чрезвычайно неэффективному использованию
адресного пространства IP. По прошествии некоторого времени все
нераспределенные адреса IP были бы полностью исчерпаны. Еще быстрее проявилось бы
другое последствие — увеличение объема таблиц на маршрутизаторах Интернета,
поскольку каждой сети потребовалась бы отдельная запись в таблице
маршрутизации. Очевидно, приходилось искать более удачное решение.
Маршрутизатор А. 1 Маршрутизатор В. 1
ВЯвЯЯ ИВВЯН ИшиВД ПЯ85И
ifiitiri I.! Щш А I' ЮЙ "I
„ ,-,.,L Ш1 Ш л^л
Сервер А.2 Сервер А.З Сервер В.2 Сервер В.З
Рис. 4.1. Первоначальная двухуровневая иерархия Интернета
Было решено произвести иерархическую группировку логических сетей и
организовать маршрутизацию между ними. С точки зрения Интернета
подразделение с несколькими логическими сетями интерпретируется как одна сеть, а
следовательно, использует единый диапазон IP-адресов. Тем не менее каждой сети
требовался свой уникальный диапазон адресов.
Подсети
В середине 1980-х годов были выпущены RFC 917 и 950. В этих документах
предлагалось решение постоянно нарастающих проблем, обусловленных
относительно плоской, двухуровневой иерархией IP-адресов. Таким решением стали
подсети (subnets). Концепция подсети была основана на необходимости третьего
уровня в иерархии Интернета. По мере развития межсетевые технологии
становились все более распространенными и использовались все чаще. В результате
наличие нескольких сетей в средних и крупных организациях стало обычным
явлением. Часто эти сети были локальными. Каждая локальная сеть может
интерпретироваться как подсеть.
В таких многосетевых средах каждая подсеть подключалась к Интернету
через общую точку — маршрутизатор. Подробности строения сетевой среды для
Интернета были несущественными. Суть оставалась неизменной: имеется
некоторая частная сеть, обеспечивающая доставку своих дейтаграмм. Таким образом,
Интернету оставалось позаботиться лишь о том, как связаться со шлюзовым
маршрутизатором этой сети через Интернет. Внутри частной сети хостовая часть
IP-адреса проходила дополнительное деление для идентификации подсети.
Маршрутизатор А. 1 Маршрутизатор В. 1
!• ш\ • в • и; • ш\ • ш\
Сервер А.2 Сервер А.З Сервер В.2 Сервер В.З / Сервер С.4
( Token-ring j
crgfl \
Сервер С.2 = 1
Сервер С.З
Рис. 4.2. Нарушение двухуровневой иерархии Интернета в многосетевых подразделениях
Как сказано в RFC 950, сеть любого из трех классов (А, В, С) может делиться
на подсети. IP-адрес хоста в подсети в действительности состоит из трех
компонентов:
О Идентификатор сети.
О Идентификатор подсети.
О Идентификатор хоста.
Идентификаторы подсети и хоста содержатся в идентификаторе хоста
исходного IP-адреса. Таким образом, возможность создания подсетей напрямую
зависит от типа IP-адреса. Чем больше бит содержит хостовая часть IP-адреса, тем
больше подсетей и хостов можно создать. Тем не менее создание подсетей
уменьшает количество адресуемых хостов. Фактически вы забираете часть битов хос-
тового идентификатора для идентификации подсети. При этом используется
специальный псевдоадрес IP, называемый маской подсети.
Маска подсети представляет собой 32-разрядное двоичное число, которое
может выражаться в десятичной записи с точечным разделением. Маска сообщает
конечным системам сети (включая маршрутизаторы и другие хосты), какие биты
IP-адреса используются для идентификации сети и подсети. Эти биты называются
расширенным сетевым префиксом. Остальные биты идентифицируют хосты в
подсети. Биты маски, идентифицирующие сеть, равны 1, а хостовые биты равны 0.
Например, маска 11111111.11111111.11111111.11000000 B55.255.255.192 в
десятичной записи) позволяет использовать 64 хостовых идентификатора в подсети.
Значения шести правых битов (нулевых битов маски) в десятичном
представлении равны 64. Следовательно, в этой подсети можно однозначно
идентифицировать не более 64 устройств. Реально использоваться могут лишь 62
идентификатора, два оставшихся зарезервированы. Первый идентификатор хоста в подсети
всегда резервируется для идентификации самой подсети. Последний
идентификатор тоже резервируется для использования в широковещательных рассылках.
Помните, что максимальное количество реально используемых идентификаторов
хостов в подсети всегда на два меньше максимального количества хостов.
Однако количество возможных подсетей зависит от класса адреса IP. В
разных классах для идентификатора сети резервируется разное количество битов,
поэтому количества битов, используемых для определения подсети, тоже
различаются. В табл. 4.3 продемонстрировано отношение между количеством подсетей
и количеством хостов в подсети для IP-адресов класса В. В адресах класса В 16 бит
определяют сеть, а другие 16 бит определяют хост. Из таблицы видно, что
наименьшее количество битов сетевого префикса равно 2, а наибольшее равно 14.
Причина проста: сетевой префикс из одного бита позволяет определить всего два
идентификатора подсети, 0 и 1. Исходные правила определения подсетей
запрещали использовать идентификаторы подсетей, состоящие только из одних
нулей или единиц. Тем не менее многие коммерческие маршрутизаторы разрешали
использовать такие идентификаторы подсетей. Один из последующих RFC A812)
внес ясность в этот вопрос. Сейчас использование идентификаторов подсетей,
состоящих только из нулей или единиц, разрешено, хотя во многих старых книгах
утверждается, что такие идентификаторы недопустимы.
Сетевой префикс из 2 битов позволяет определить четыре идентификатора
подсети: 00, 01, 10 и И.
Таблица 4.3. Определение подсетей в адресном пространстве класса В
Размер Маска Количество Количество
префикса подсети используемых используемых
в битах подсетей хостов в подсети
2 255.255.192.0 4 16 382
3 255.255.224.0 8 8190
Размер Маска Количество Количество
префикса подсети используемых используемых
в битах подсетей хостов в подсети
4 255.255.240.0 16 4094
5 255.255.248.0 32 2046
6 255.255.252.0 64 1022
7 255.255.254.0 128 510
8 255.255.255.0 256 254
9 255.255.255.128 512 126
10 255.255.255.192 1024 62
11 255.255.255.224 2048 30
12 255.255.255.240 4096 14
13 255.255.255.248 8192 6
14 255.255.255.252 16 384 2
Из таблицы ясно видно, что чем больше битов выделяется на
идентификацию подсети, тем меньше битов остается на идентификацию хоста, и наоборот.
В сетях класса С тоже могут создаваться подсети. Так как в адресах класса С
сеть идентифицируется 24 битами, на идентификацию подсети и хоста остается
всего 8 бит. Разные варианты распределения битов при идентификации подсети
и хоста в сети класса С представлены в табл. 4.4.
Таблица 4.4. Определение подсетей в адресном пространстве класса С
Размер Маска Количество Количество
префикса подсети используемых используемых
в битах подсетей хостов в подсети
2 255.255.255.192 4 62
3 255.255.255.224 8 30
4 255.255.255.240 16 14
5 255.255.255.248 32 6
6 255.255.255.252 64 2
Хотя табл. 4.3 и 4.4 показывают отношение между количеством возможных
подсетей и хостов в подсети, однако они не дают представления о том, как же
работают подсети. Работу механизма подсетей лучше всего продемонстрировать
на примере конкретного IP-адреса, как это сделано в следующем разделе.
Пример использования подсети
Из всех аспектов схемы адресации IP новичкам обычно бывает труднее всего
разобраться именно с подсетями. В основном это связано с тем, что работа под-
сети выглядит логично лишь в двоичном представлении, не особенно удобном
для человеческого восприятия. Допустим, вам потребовалось определить
подсеть для адреса класса С 193.168.125.0. Это базовый адрес, используемый при
построении маршрутов в Интернете. Если вы захотите разбить его на восемь
подсетей, по крайней мере три из 8 битов идентификатора хоста придется
выделить на создание уникального префикса для каждой из восьми подсетей: 000,
001, 010, 011, 100, 101, 110 и 111. Последний октет адреса разбивается на две
части: 3 бита добавляются к идентификатору сети и образуют расширенный
сетевой префикс, а оставшиеся 5 битов используются для идентификации хостов.
Формирование адресов подсетей продемонстрировано в табл. 4.5.
В табл. 4.5 расширенные сетевые префиксы (состоящие из идентификатора
сети IP и идентификатора подсети) выделены жирным шрифтом.
Идентификаторы подсети дополнительно оформлены курсивом. Идентификаторы хостов
выводятся нормальным шрифтом и отделяются от расширенного сетевого
префикса дефисом. Такая система обозначений помогает понять, как происходит
деление базовых сетевых IP-адресов на подсети.
Таблица 4.5. Формирование подсетей
Сеть Двоичный адрес Десятичный адрес
Базовая 11000001.10101000.01111101.00000000 193.168.125.0
Подсеть 0 11000001.10101000.01111101.000 00000 193.168.125.0
Подсеть 1 11000001.10101000.01111101.001 00000 193.168.125.32
Подсеть 2 11000001.10101000.01111101.010-00000 193.168.125.64
Подсеть 3 11000001.10101000.01111101.011-00000 193.168.125.96
Подсеть 4 11000001.10101000.01111101.100 00000 193.168.125.128
Подсеть 5 11000001.10101000.01111101.101-00000 193.168.125.160
Подсеть 6 11000001.10101000.01111101.110-00000 193.168.125.192
Подсеть 7 11000001.10101000.01111101.111 00000 193.168.125.224
Идентификатор подсети определяется первыми тремя битами последнего
октета. Десятичные представления этих цифр равны 128, 64 и 32 соответственно.
В третьем столбце приводятся начальные IP-адреса каждой подсети. Как и
следовало ожидать, они увеличиваются с приращением 32 (крайний правый бит в
идентификаторе подсети).
ПРИМЕЧАНИЕ
Подсети 0 и 7 возможны с математической точки зрения, но когда-то они были запрещены даже
при наличии соответствующих записей на маршрутизаторе. Сейчас такие идентификаторы
подсетей разрешены, их идентификаторы подсетей равны 000 и 111 соответственно.
Хосты в каждой подсети определяются оставшимися пятью битами
последнего октета. Существуют 32 возможные комбинации из пяти нулей и единиц;
минимальное и максимальное значения зарезервированы, для использования
остается до 30 хостов в каждой подсети. Устройство с IP-адресом 193.168.125.193
будет первым хостом, определенным в подсети 6. Дальше нумерация хостов
продолжается до 193.168.125.222, и на этом подсеть окончательно заполняется.
Дальнейшее включение хостов в нее становится невозможным.
Маски подсети переменной длины
Хотя механизм определения подсетей стал ценным усовершенствованием схемы
адресации в Интернете, ему был присущ один принципиальный недостаток: вся
сеть ограничивалась одной маской подсети. Таким образом, после выбора маски
подсети (определяющей количество хостов в подсети) вы уже не могли
организовать поддержку подсетей другого размера. Если размер подсети требовалось
увеличить, приходилось изменять маску для всей сети. Не стоит и говорить, что
это весьма сложная и длительная процедура.
Решение этой проблемы было предложено в 1987 году. IETF опубликовала
документ RFC 1009, в котором определялся механизм поддержки нескольких
масок в одной подсети. На первый взгляд эти маски подсетей имели разные
размеры, но их нельзя было считать разными масками — сетевые префиксы были
идентичны. Из-за этого новой методике определения подсетей было присвоено
название «масок подсетей переменной длины» VLSM (Variable Length Subnet
Masks).
VLSM повышает эффективность использования адресного пространства IP
в границах организации, поскольку сетевому администратору предоставляется
возможность настройки маски по конкретным требованиям каждой подсети.
Для наглядности предположим, что у нас имеется базовый IP-адрес 172.16.0.0.
Это адрес класса В, в котором используется 16-разрядный идентификатор
подсети. В результате расширения сетевого префикса на 6 бит создается
22-разрядный расширенный сетевой префикс. С математической точки зрения существует
64 идентификатора подсетей, каждая из которых содержит до 1022 хостов.
Подобная схема вполне разумна, если организации требуется более 30
подсетей с более чем 500 хостами в каждой. Тем не менее, если организация состоит
из нескольких больших филиалов, сети которых содержат более 500 хостов, и
множества мелких филиалов с 40-50 хостами, многие потенциально возможные
адреса останутся неиспользованными. Каждому филиалу независимо от его
потребностей будет выделена подсеть с 1022 хостами, и каждый мелкий филиал
будет попусту расходовать около 950 адресов. При использовании одной маски
подсети фиксированной и заранее определенной длины подобное расходование
адресов неизбежно.
Теоретически механизм определения подсетей был идеальным решением
серьезной проблемы быстрого истощения конечного адресного пространства IP.
Возможность разбиения идентификатора хоста в IP-адресе на идентификаторы
подсети и хоста значительно сократила бесполезное расходование IP-адресов.
К сожалению, в реальном мире потребности в подсетях носят неравномерный
характер. Нельзя ожидать, что организация или все ее сети будут делиться на
субкомпоненты равного размера. Гораздо более вероятна ситуация, при которой
потребуется создавать филиалы (и подсети) любых размеров, и применение
маски подсети фиксированной длины приведет к напрасному расходу
IP-адресов, как в предыдущем примере.
ПРИМЕЧАНИЕ
Размер расширенного сетевого префикса указывается после символа / в конце IP-адреса. Таким
образом, запись 193.168.125.0/27 обозначает адрес класса С, в котором расширенный сетевой
префикс занимает 27 битов.
Для решения этой проблемы было разрешено гибкое создание подсетей в
адресном пространстве IP с возможностью определения сетевых масок переменного
размера. Так, в предыдущем примере сетевой администратор может разбить
базовый IP-адрес на маски подсетей разного размера. Несколько крупных
филиалов могут продолжить использование 22-разрядных сетевых префиксов, а мелким
филиалам может быть назначен 25- или 26-разрядный префикс. 25-разрядный
префикс позволит создавать подсети, содержащие до 126 хостов, а 26-разрядный
префикс ограничивает размер сети 62 хостами. Методика, на которой основано
решение, называется VLSM.
CIDR
Механизм бесклассовой междоменной маршрутизации CIDR (Classless Interdomain
Routing) принадлежит к числу относительно новых дополнений схемы
адресации IP. Он был порожден кризисом, который сопровождал период бурного роста
Интернета в начале 1990-х годов.
Еще в 1992 году участники IETF были обеспокоены способностью Интернета
масштабироваться в соответствии с потребностью в его использовании. Особую
озабоченность вызывали следующие проблемы:
О Исчерпание резерва оставшихся сетевых адресов IPv4. Особенно серьезная
угроза исчерпания существовала для адресного пространства класса В.
О Быстрый и существенный рост размеров таблиц маршрутизации в результате
расширения Интернета.
Все признаки указывали на то, что по мере подключения новых коммерческих
предприятий быстрый рост Интернета продолжится.. Более того, некоторые члены
IETF даже предсказывали наступление «Судного дня» в марте 1994 года, когда
должно было произойти предполагаемое исчерпание адресного пространства
класса В. Отсутствие других механизмов адресации представляло серьезную угрозу
для масштабируемости Интернета. Еще более угрожающе выглядела
перспектива того, что механизмы маршрутизации в Интернете рухнут еще до наступления
«Судного дня» под весом постоянно увеличивающихся таблиц маршрутизации.
Интернет становился жертвой собственной популярности. В IETF решили,
что для предотвращения краха Интернета необходимы как краткосрочные, так
и долгосрочные меры. В перспективе единственным приемлемым решением была
абсолютно новая версия IP со значительно расширенным адресным пространством
и схемой адресации. В итоге это решение стало известно под названием IPng
(Internet Protocol: Next Generation) или более формально — IP версии 6 (IPv6).
Более неотложное, краткосрочное решение требовало замедлить раздачу
существующих свободных адресов. Оно было основано на исключении
неэффективных классов адресов в пользу более гибкой архитектуры адресации.
Результатом стал механизм CIDR. В сентябре 1993 года проект CIDR был опубликован
в документах RFC 1517, 1518, 1519 и 1520.
CIDR обладает рядом ключевых аспектов, которые оказались бесценными для
замедления процесса опустошения адресного пространства:
О Исключение классовой адресации.
О Расширенное агрегирование маршрутных данных.
О Суперсети.
Общим эффектом этих нововведений стало устаревание схемы классовой
адресации. Возможно, такие адреса все еще используются в отдельных местах, но
бесклассовые адреса (несмотря на негативные ассоциации!) обладают гораздо
большей эффективностью.
Бесклассовая адресация
С математической точки зрения адресное пространство IPv4 все еще содержало
значительное количество свободных адресов. К сожалению, многие из этих
потенциальных адресов оказались заблокированными в назначенных блоках (или
классах) назначаемых адресов. Ликвидация классов не обязательно приводит к
возвращению адресов, заблокированных в уже выделенных адресных
пространствах, но значительно повышает эффективность использования оставшихся
адресов. Ожидается, что эта временная мера обеспечит время, необходимое на
разработку и запуск в эксплуатацию протокола IPv6.
Расширенное агрегирование маршрутных данных
CIDR позволяет маршрутизаторам Интернета (а также любым CIDR-совмес-
тимым маршрутизаторам) более эффективно использовать агрегирование
маршрутных данных. Другими словами, одна запись в таблице маршрутизации
может представлять адресные пространства нескольких сетей. Это
обстоятельство существенно уменьшает объем таблиц маршрутизации в каждом
конкретном межсетевом образовании, что непосредственно способствует улучшению
масштабируемости.
Механизм CIDR был реализован в Интернете в 1994-1995 годах и
немедленно оказался эффективным средством против разрастания таблиц
маршрутизации. Если бы не CIDR, вряд ли Интернет продолжал бы расти прежними
темпами.
Суперсети
К числу преимуществ CIDR также относится возможность использования
суперсетей. Суперсеть представляет собой не что иное, как несколько смежных блоков
адресных пространств класса С, имитирующих одно адресное пространство
большего размера. Если вам удастся получить достаточно смежных блоков адресов
класса С, вы сможете переопределить распределение битов между
идентификаторами хоста и сети и имитировать сеть класса В.
Суперсети проектировались как временная мера борьбы с быстрым
исчерпанием адресного пространства класса В, которая предоставляла в распоряжение
пользователей более гибкую альтернативу. Использовавшаяся ранее классовая
схема адресации страдала от огромных различий в масштабах сетей классов В
и С. Если размер сети превышал ограничение в 254 хоста, установленное для
класса С, приходилось выбирать один из двух вариантов, каждый из которых
оставлял желать лучшего:
О Использование нескольких сетей класса С (с необходимостью
маршрутизации между сетевыми доменами).
О Переход на сеть класса В с 65 534 возможными хостами.
Чаще использовалось второе, более простое решение, несмотря на то, при нем
напрасно расходовались десятки тысяч IP-адресов.
Принцип работы CIDR
Механизм CIDR нарушил старые традиции и ознаменовал полный отказ от
жесткой схемы классовой адресации. В исходной схеме адресации IPv4 в адресах
класса А используется 8-разрядный идентификатор сети, в адресах класса В —
16-разрядный, а в адресах класса С — 24-разрядный идентификатор сети.
Механизм CIDR заменил эти категории обобщенным сетевым префиксом
произвольной длины, не обязательно кратной 8 битам. В результате появилась
возможность планировать адресные пространства сетей в соответствии с размерами
сети, вместо того чтобы принудительно подгонять сети под адресные
пространства заранее определенного размера.
Каждый CIDR-совместимый сетевой адрес описывается битовой маской,
определяющей длину сетевого префикса. Например, запись 192.125.61.8/20 обозначает
адрес CIDR с 20-разрядным идентификатором сети. Теперь допускается
использование любых IP-адресов независимо от того, к какому классу они принадлежали:
А, В и С! Маршрутизаторы с поддержкой CIDR определяют идентификатор сети
по числу, следующему за /. Таким образом, бывший адрес класса С 192.125.61.8
ранее состоял из идентификатора сети 192.125.61 и идентификатора хоста 8.
В сетях класса С можно было назначить адреса не более чем 254 хостам. При
использовании CIDR ограничения на выравнивание компонентов адреса по
8-разрядной границе снимаются. Чтобы лучше понять, как работает этот механизм,
необходимо преобразовать десятичное представление адреса в двоичную систему.
В двоичном виде сетевая часть этого адреса имеет вид 11000000.01111101.
00111101. Первые 20 бит этой последовательности определяют идентификатор
сети. Разбиение адреса на компоненты продемонстрировано в табл. 4.6.
Таблица 4.6. 20-разрядный идентификатор сети CIDR
Идентификатор сети Идентификатор хоста
Двоичное представление адреса 11000000.01111101.0011 1101.00001000
Обратите внимание: деление адреса на идентификаторы сети и хоста
проходит в середине третьего октета. Биты, не использованные для идентификации
сети, используются для идентификации хоста. Таким образом, в адресе IPv4
с 20-разрядным сетевым префиксом остается 12 бит на идентификацию хоста.
С математической точки зрения 12-разрядное двоичное число позволяет
представить 4094 пригодных к использованию хостов. Поскольку ни один бит в
левой части не должен принимать стандартные значения (ранее необходимые для
идентификации классов), в сети CIDR может использоваться практически весь
диапазон адресов. Следовательно, 20-разрядный сетевой префикс может
принимать значения, ранее зарезервированные для сетей класса А, В и С.
Открытые адресные пространства
Если глобальная сеть (WAN) не подключена напрямую к Интернету или к любой
другой сети, межсетевые адреса могут выбираться произвольно. Вообще говоря,
произвольный выбор межсетевых адресов считается вопиющим проявлением
близорукости и халатности. С учетом сказанного, в мае 1993 года был
опубликован документ RFC 1597, в котором был предложен выход из положения.
RFC 1597 и 1918
RFC 1597 был заменен RFC 1918 в феврале 1996 года. Тем не менее новый
документ ограничивался минимальными изменениями в исходной спецификации.
Самым существенным из этих изменений был отказ от алфавитных классов А,
В и С. Вместо этого в RFC 1919 было выдвинуто предложение об
использовании адресации по схеме CIDR. Как объяснялось в предыдущем разделе, CIDR
не использует классовые адреса. Вместо этого количество битов,
зарезервированных для идентификатора сети, указывается за символом /. Таким образом,
идентификатор 10 класса А записывается в виде 10/8, поскольку только 8 бит
используются для идентификации сети. Что еще важнее, хостовой
идентификатор может начинаться на границе любого бита, в отличие от существовавшей
ранее классовой адресации, при которой начало идентификатора хоста
обязательно выравнивалось по 8-битной границе.
Также были определены и зарезервированы три диапазона адресов, которые
могли использоваться только для внутренних целей, по одному от каждого из
классов IPv4 А, В и С:
О 10.0.0.0-10.255.255.255.
О 172.16.0.0-172.31.255.255.
О 192.168.0.0-192.168.255.255.
Эти диапазоны были зарезервированы IANA для частных сетей. Одно из
положений RFC 1597 гласило, что эти адреса не могут использоваться при
непосредственных обращениях к Интернету. Компании, использовавшие эти адреса
и впоследствии пожелавшие получить выход в Интернет, оказались в трудной
ситуации. Они могли перенумеровать все свои устройства в соответствии с
требованиями IANA или же установить между интрасетью и Интернетом промежуточ-
ное звено — прокси-сервер или преобразователь сетевых адресов NA T (Network
Address Translator). Применение подобных устройств позволило бы компании
продолжить работу с фиктивными адресами без ущерба для доступа к Интернету
(и из него).
Если вы захотите использовать зарезервированные адреса RFC 1597 в своей
интрасети, необходимо учитывать долгосрочные последствия этого решения.
Возможно, со временем вам понадобится подключиться к сетям других
компаний через экстрасеть или через Интернет. В любом из этих случаев уникальность
фиктивных адресов не гарантируется.
Наконец, при использовании адресов из диапазонов, зарезервированных для
частных сетей в RFC 1918, вы по-прежнему должны гарантировать уникальность
адресов устройств в рамках домена закрытой сети. Адреса ни будут уникальными
в глобальном отношении, но они должны быть уникальны хотя бы локально.
Адресация в частных сетях
Для снижения потребности в новых IP-адресах в марте 1994 года был
опубликован документ RFC 1597, посвященный назначению IP-адресов в частных
сетях. Частными (private) называются сети, не подключенные к другой сети или
содержащие хосты и службы с ограниченными возможностями взаимодействия
с Интернетом. Хосты частных сетей делятся на три категории:
О Хосты, не нуждающиеся в доступе к Интернету.
О Хосты, нуждающиеся в доступе к ограниченному набору внешних служб —
электронной почте, FTP, новостям, удаленному входу и т. д, которые могут
обрабатываться шлюзом прикладного уровня.
О Хосты, нуждающиеся во внешнем доступе сетевого уровня. Задача решается
средствами IP, и в ее решении должны быть задействованы маршрутизаторы
или хосты, видимые для внешних сетей.
Хостам первой категории могут назначаться IP-адреса, уникальные в
границах частной сети, но не уникальные в Интернете. Такие хосты не обмениваются
пакетами с хостами за пределами частной сети, поэтому проблема дублирования
IP-адресов не возникает.
Для хостов второй категории, изолированных от внешнего доступа в
Интернет шлюзом прикладного уроня, уникальность IP-адресов не обязательна. Это
объясняется тем, что шлюз прикладного уровня маскирует IP-адреса этих
хостов от внешней сети.
Только хостам третьей категории должны назначаться IP-адреса, глобально
уникальные в Интернете.
При ведении нормальной документации по сети идентификация хостов
категорий 1 и 2 выполняется относительно легко. Эти хосты не нуждаются в
подключениях сетевого уровня за пределами корпоративной сети.
В RFC 1597 приводятся следующие примеры хостов категорий 1 и 2:
О Крупный аэропорт с несколькими электронными табло, на которых
отображается время вылета/прибытия, адресуемыми через TCP/IP. Крайне
маловероятно, чтобы к этим табло потребовался прямой доступ из других сетей.
О Крупные организации (такие, как банки и сети розничной торговли)
переходят на TCP/IP в своих внутренних коммуникациях. Локальным рабочим
станциям — кассам, банкоматам и т. д. — внешний доступ обычно не нужен.
О По соображениям безопасности во многих организациях внутренние сети
подключаются к Интернету через шлюзы прикладного уровня (например,
через брандмауэры). Внутренняя сеть обычно не имеет прямого доступа к
Интернету, а из Интернета видны только хосты брандмауэров (один или более).
В этом случае во внутренней сети допускается использование не-уникаль-
ных IP-адресов.
О Если две организации общаются между собой по частному каналу, обычно
каждое из них имеет доступ к очень ограниченному набору хостов на другом
конце канала. Только этим хостам должны назначаться глобально
уникальные IP-адреса.
О Маршрутизаторы частной сети обычно не должны быть напрямую доступны
за пределами организации.
На основании запроса авторов RFC 1597 ICANN зарезервировала для
частных сетей следующие три блока адресного пространства IP, которые могут
назначаться хостам категорий 1 и 2:
О 10.0.0.0-10.255.255.255 - 1 сеть класса А.
О 172.16.0.0-172.31.255.255 - 16 сетей класса В.
О 192.168.0.0-192.168.255.255 - 256 сетей класса С.
Предприятие, желающее использовать IP-адреса из перечисленных адресных
пространствах, может делать это без координации с ICANN или реестра
Интернета. Таким образом, эти адресные пространства могут использоваться многими
предприятиями, что сокращает необходимость в выделении новых
идентификаторов сетей. Адреса в частных сетях уникальны в границах предприятия, но не
в границах сети.
Если предприятие нуждается в глобально-уникальных адресах для
приложений и устройств, подключенных на уровне IP, ему приходится получать такие
адреса от реестра Интернета. ICANN не распределяет IP-адреса из адресного
пространства частных сетей.
Поскольку частные адреса не имеют глобального смысла, маршрутные
данные частной сети не должны выходить за пределы организации.
Маршрутизаторы сетей, не использующих частное адресное пространство (например, сетей
поставщиков услуг Интернета), должны быть настроены таким образом, чтобы
они отвергали маршрутные данные частных сетей. Фильтрация этих данных не
должна сопроволсдаться сообщениями об ошибке протокола маршрутизации.
Чтобы использовать частное адресное пространство, предприятие должно
определить, какие хосты не нуждаются в связи на сетевом уровне. Если для
внешней сети потребуется изменение конфигурации хостов и средств связи
сетевого уровня, должны быть присвоены глобально-уникальные адреса. Иначе
говоря, IP-адреса этих хостов должны быть переведены из частного адресного
пространства в открытое адресное пространство. Если организация не будет
должным образом следить за изменением требований к хостам, она может
случайно создать ситуацию с дублированием IP-адресов. Возможно, по этой
и по некоторым другим причинам в июле 1994 года был выпущен документ
RFC 1627.
Авторы RFC 1627 указывают на то, что рекомендации RFC 1597 уменьшают
надежность и безопасность работы сети и слишком дорого обходятся из-за
множества возникающих проблем. Например, если двум организациям,
использующим частные адресные пространства, потребуется связаться напрямую, по
крайней мере одной из них придется изменить свои назначенные IP-адреса. В RFC
1627 утверждалось, что «RFC 1597 создает иллюзию решения проблемы за счет
формализации традиционно неформальной практики. На самом деле эта
формализация только отвлекает от необходимости решать насущные проблемы и даже
не предоставляет существенной помощи в краткосрочной перспективе». Кроме
того, в RFC 1627 утверждается, что ICANN превысила границы своих
полномочий, порекомендовав RFC 1597 без обычного открытого обсуждения и
одобрения со стороны IETF и IAB.
Так что же делать простому проектировщику сети, оказавшемуся в центре
противоречий, связанных с использованием частных адресов? Если вы
собираетесь последовать рекомендациям RFC 1597, будьте очень осторожны. Убедитесь
в том, что вы располагаете всей необходимой документацией и хорошо знаете,
какие службы видны или не видны для внешнего мира. Прочитайте RFC 1627
и разберитесь в сути выдвинутых возражений.
Назначение адресов класса С
Адреса класса С в диапазоне 192.0.0 до 223.255.245 были разделены на восемь
адресных блоков (табл. 4.7). За распределение адресов из этих блоков отвечают
региональные полномочные организации.
Таблица 4.7. Распределение адресов класса С
Диапазон адресов Регион
192.0.0-193.255.255 Внерегиональные адреса. Диапазон включает адреса, использовавшиеся
до появления схемы регионального назначения адресов
194.0.0-195.255.255 Европа
196.0.0-197.255.255 Используется при назначении IP-адресов независимо от региона
198.0.0-199.255.255 Северная Америка
200.0.0-201.255.255 Центральная и Южная Африка
202.0.0-203.255.255 Побережье Тихого океана
204.0.0-205.255.255 Используется при назначении IP-адресов независимо от региона
206.0.0-207.255.255 Используется при назначении IP-адресов независимо от региона
208.0.0-223.255.255 Доступные адреса
Информация, приведенная в табл. 4.7, может пригодиться в том случае, если
у вас имеется протокол трассировки пакетов, входящих в сеть, и вы хотите
определить, из какой географической зоны приходят пакеты.
Настройка IP-адресов
Настройка хостов в сетях TCP/IP должна производиться с использованием
правильных IP-адресов. Конкретная процедура настройки зависит от
операционной системы, но в целом процессы делятся на следующие категории:
О Настройка в командной строке.
О Настройка с использованием меню.
О Настройка с использованием графического интерфейса.
О Динамическое назначение адреса при загрузке хоста с центрального сервера.
В табл. 4.8 приведены примеры операционных систем, относящихся к
различным категориям.
Таблица 4.8. Настройка IP-адреса и других параметров хостов
Методика Операционная система/протокол
Режим командной строки Unix, VMS, устройства маршрутизации, MS-DOS
Меню Устройства маршрутизации, Unix, серверы NetWare, MS-DOS
Графический Интернет Unix, Microsoft Windows
Динамическое назначение Протоколы DHCP и ВООТР. Поддерживаются почти всеми
основными операционными системами
Во многих системах существуют команды модификации IP-адресов, часто
включаемые в стартовый сценарий операционной системы. Интерфейс меню
строится с использованием псевдографики из расширенного набора символов,
в нем вам предлагается ввести IP-адрес и другие параметры IP. Графический
интерфейс предназначен для систем, поддерживающих графический вывод на
уровне пикселов. Примерами таких систем являются X-Window и операционные
системы семейства Microsoft Windows. Динамическое назначение IP-адресов
используется в сочетании с протоколами ВООТР и DHCP. Устройство при
запуске запрашивает IP-адрес и другие параметры с центрального сервера,
который передает эти сведения по протоколу ВООТР и DHCP.
Информация об IP-адресе хоста регистрируется в нескольких местах.
Введенный IP-адрес кэшируется в памяти и остается доступным для использования
программным обеспечением TCP/IP. Кроме того, эти данные иногда
сохраняются в системных файлах операционной системы. Информация об IP-адресах
других систем может быть получена из специального файла, который обычно
называется hosts, или при помощи протокола DNS. Как правило, сервис DNS
используется для получения IP-адреса хоста по его символическому имени
DNS. В некоторых системах реализованы специальные запатентованные
протоколы для получения IP-адресов в сети (пример — служба WINS в
операционных системах Microsoft).
Адресация в IP версии 6
Как упоминалось выше в этой главе, по мере расширения Интернета
32-разрядное адресное пространство IP-адресов постепенно подходит к концу. Невзирая
на RFC 1597, для каждого сетевого подключения к Интернету нужен
уникальный IP-адрес. Некоторые устройства имеют несколько сетевых подключений,
что приводит к быстрому поглощению доступных IP-адресов.
Считается, что 32-разрядные IP-адреса (так называемая адресация по схеме IP
версии 4) могут обеспечить более 2 100 000 сетей, содержащих в общей
сложности 3720 миллионов хостов. Тем не менее схема распределения адресов IP
недостаточно эффективна, поскольку для соединения сетей через устройства
ретрансляции, работающие на сетевом уровне (в частности, маршрутизаторы), обычно
требуются новые сетевые адреса.
В результате стала быстро возникать нехватка IP-адресов. Для решения этой
проблемы группа IETF проанализировала методы решения проблемы адресного
пространства и внесла в протокол изменения, повышавшие эффективность его
работы в условиях новых сетевых технологий. После изучения различных
предложений по преодолению ограничений текущей версии протокола IP
(называемой IP версии 4, или IPv4), было решено перейти на протокол IP нового
поколения — «IP Next Generation», также называемый IPng или IPv6. Одной из
целей, поставленных при проектировании IPv6, должна была стать поддержка
минимум одного миллиарда сетей. Чтобы соответствовать этому критерию, IPv6
использует 128-разрядные адреса, длина которых вчетверо превышает длину
адресов IPv4. IPv6 тоже использует концепции идентификаторов сетей и
хостов, но расширяет ее на несколько уровней. Иерархическая адресация IPv6
обеспечивает более эффективную маршрутизацию. Адрес IPv6 может содержать
32-разрядный адрес IPv4, который размещается в младших 32 битах адреса IPv6
с заполнением 96 старших битов фиксированным префиксом из 80 нулевых битов,
за которыми следуют 16 единичных или нулевых битов.
IPv6 позволяет использовать незарегистрированные адреса IPv4; для этого
в адрес добавляется уникальный зарегистрированный модификатор, вследствие
чего весь адрес IPv6 становится уникальым.
Схема адресации IPv6 проектировалась с расчетом на взаимодействие с
системами на базе IPv4. Таким образом, становится возможным сосуществование двух
схем адресации IP в течение некоторого периода. Для передачи информации
между сетями, работающими на базе IPv4 и более нового протокола IPv6, могут
использоваться маршрутизаторы с поддержкой обоих протоколов, IPv4 и IPv6.
Протокол IPv6 включает поддержку мобильных портативных систем. В
частности, это позволяет пользователям портативных компьютеров и других устройств
подключаться к любой точке сети без ручной перенастройки. Мобильные системы
автоматически устанавливают связь при подключении к сети в другой точке.
Автоматическая настройка применяется не только для мобильных систем, но
и для обычных рабочих станций. IPv6 поддерживает шифрование данных и
обладает улучшенной поддержкой трафика в реальном времени (то есть обеспечивает
определенные гарантии максимальной задержки при передаче дейтаграмм по сети).
Адреса IPv6 имеют длину 128 байт, поэтому десятичная запись с точечным
разделением для них неудобна — представьте, что вам придется записывать
строку из 16 десятичных цифр, разделенных точками!
Рассмотрим следующее двоичное представление адреса IPv6:
01011000 00000000 00000000 11000000
11100011 11000011 11110001 10101010
01001000 11100011 11011001 00100111
11010100 10010101 10101010 11111110
Адрес IPv6 состоит из 128 бит и записывать его в двоичной системе крайне
неудобно. В десятичной записи с точечным разделением этот адрес выглядит так:
88.0.0.192.227.195.241.170.72.227.217.39.212.149.170.254
Такая запись получается недостаточно компактной. Для записи этих двоичных
последовательностей проектировщики остановились на шестиадцатеричпой записи
с разделением двоеточиями. Адрес разбивается на 16-разрядные группы,
разделенные символом «>. Так, адрес из предыдущего примера записывается в виде:
5800:00C0:E3C3:F1AA:48E3:D927:D495:AAFE
Использование этой формы записи уменьшает количество цифр и
символов-разделителей, но это не все: существует два приема сокращенной записи,
которые могут применяться для дальнейшего уменьшения количества символов.
Во-первых, начальные нули можно не указывать. Для примера возьмем
следующий адрес IPv6:
48А6:0000:0000:0000:0000:0DA3:003F:0001
С пропуском начальных нулей возможна следующая упрощенная форма
записи:
48А6:0:0:0:0:DA3:3F:1
Последовательность 0000 заменяется 0, 0DA3 заменяется на DA3, а 0001 —
на 1. Во всех перечисленных случаях исключение начальных нулей уменьшает
количество символов в адресе.
Во-вторых, правило сжатия нулей позволяет заменить последовательность
повторяющихся нулей двойным символом двоеточия (:: ). Так, в приведенном
выше адресе IPv6 присутствует последовательность из четырех нулей @:0:0:0),
которая может быть заменена на «::». Таким образом, предыдущий адрес IPv6
записывается в виде
48А6::DA3:3F:1
При расширении адреса, содержащего сжатые нули, часть адреса,
находящаяся слева от двоеточий, выравнивается по начальным 16-разрядным словам
адреса, а часть, находящаяся справа, выравнивается по конечным 16-разрядным
словам адреса. Оставшиеся 16-разрядные слова адреса заполняются нулями.
В качестве примера рассмотрим следующую запись:
5400:FD45::FFFF:3AFE
После расширения адрес принимает вид
5400:FD45:0:0:0:0:FFFF:3AFE
Последовательность «:> может встречаться в адресе только один раз, чтобы
обеспечить однозначную интерпретацию. Следующая запись IPv6 недопустима —
по ней невозможно определить, какое слово занимает последовательность 45А1:
5400::45А1::23Аб
Наконец, последовательность «:> может использоваться в качестве префикса
или суффикса. Рассмотрим следующее представление адреса IPv4 170.1.1.1
в формате IPv6:
0:0:0:0:0:0:АА01:101
Итоги
Хорошее знание схемы адресации IP абсолютно необходимо для понимания
основных принципов межсетевой связи на базе IP. Базовый материал,
представленный в настоящей главе, поможет вам лучше разобраться в этой теме. Многие
из упоминаемых архитектурных решений (CIDR, маски подсетей, VLSM)
используются настолько широко, что их недостаточное понимание сильно затруднит
вашу работу по поддержке и проектированию межсетевых образований. Кроме
того, в этой главе рассматриваются частные адреса и области их применения,
а также в общих чертах описана структура адресов IPv6.
В следующих главах этой части книги рассматриваются другие аспекты выбора
имен и адресов в сетях IP, в том числе механизм установления соответствия
между IP-адресами и аппаратными адресами локальных сетей, а также
преобразование удобных символических имен в IP-адреса.
|- ARP и RARP
IP-адреса являются общим средством идентификации хостов в TCP/IP, но для
того, чтобы дейтаграмма была доставлена получателю, одного IP-адреса
недостаточно. В доставке задействована сетевая система, поведение которой обычно
зависит от сетевой операционной системы и типа оборудования. Чтобы хорошо
понимать механизм маршрутизации данных от отправителя к получателю,
необходимо разобраться в том, как организовано взаимодействие компьютеров,
входящих в сеть. Глава начинается с общего обзора типичных сетевых архитектур
(в особенности Ethernet) и дает представление о том, как в TCP/IP происходит
преобразование IP-адресов в канальные адреса, используемые на уровне сети.
Преобразование IP-адреса в канальный адрес выполняется при помощи протокола
ARP (Address Resolution Protocol). Парный протокол RARP (Reverse Address
Resolution Protocol) решает обратную задачу — преобразование канальных
адресов в IP-адреса.
Механизмы адресации
IP-адреса используются TCP/IP для доставки дейтаграмм заданному получателю.
При описании механизмов адресации часто встречаются три стандартных
термина: имя, адрес и маршрут.
Имя представляет собой символическое обозначение компьютера, пользователя
или приложения. Обычно имена являются уникальными и обозначают
конечного получателя дейтаграммы. Адрес обычно определяет физическое или
логическое местонахождение получателя в сети. Маршрут содержит информацию
о том, каким образом дейтаграмма должна доставляться по нужному адресу. При
использовании термина «адрес» необходима осторожность, потому что этот
термин часто используется в коммуникационных протоколах для обозначения
множества разных понятий. В частности, он может обозначать хост, порт
компьютера, адрес памяти, приложение и многое другое. В общем случае каждый уровень
модели OSI использует собственные адреса. Например, в сети Ethernet адресом
канального уровня является аппаратный адрес Ethernet, уникальный для каждого
сетевого адаптера, а адресом сетевого уровня является IP-адрес
соответствующего узла TCP/IP.
В процессе доставки ключевую роль обычно играет регистрационное имя
получателя. Пакет сетевого программного обеспечения, называемый сервером имен,
строит адрес и маршрут по именам пользователя и компьютера, скрывая этот
аспект маршрутизации TCP/IP и доставки от приложения. Помимо
прозрачности адресации и маршрутизации с точки зрения приложений, серверы имен
обладают другим существенным преимуществом: они позволяют системному или
сетевому администратору достаточно свободно изменять параметры сети без
перенастройки каждого компьютера по отдельности. Пока в сети имеется
работающий сервер имен, приложения и пользователи могут игнорировать
изменения в маршруте.
Адресация в подсетях
Пересылка данных на другой компьютер обычно осуществляется по IP-адресу.
Хотя протокол TCP/IP проектировался для работы с IP-адресами, реальным
сетевым программным и аппаратным обеспечением эти адреса не
поддерживаются. Вместо этого сетевые программные средства идентифицируют
компьютеры по физическим адресам, которые кодируются в сетевых устройствах,
устанавливаемых на компьютерах. Установление соответствия между IP-адресом
и физическим адресом не входит в обычный круг задач протокола TCP/IP,
поэтому для решения этой задачи было разработано несколько специальных
протоколов. Эти протоколы будут рассмотрены в следующем разделе, но сначала
мы обсудим структуру физических адресов сети.
В отдельной локальной или глобальной сети для правильной доставки
дейтаграмм необходимо знать несколько атрибутов, прежде всего — физический
и канальный адрес получателя. Эти адреса достаточно важны и заслуживают
более внимательного рассмотрения.
Физические адреса
Каждое устройство в сети характеризуется уникальным физическим адресом,
который также называется аппаратным адресом. Физические адреса обычно
кодируются на уровне сетевого адаптера, иногда они могут настраиваться пользователем
при помощи переключателей или специальных программ. Но чаще физические
адреса жестко кодируются в ППЗУ адаптера; производители сетевого
оборудования часто совместно работают над тем, чтобы предотвратить возможное
дублирование физических адресов. В любой отдельной сети каждый физический
адрес может существовать только в одном экземпляре, иначе сервер имен не
сможет однозначно определить получателя. Длина физического адреса
изменяется в зависимости от сетевой архитектуры. Например, в Ethernet и ряде других
сетевых архитектур адреса имеют длину 48 бит. Обмен данными по сети требует
указания двух сетевых адресов: передающего и принимающего устройства.
В настоящее время назначением единых физических адресов подсетей
занимается IEEE (раньше этим занималась фирма Xerox, исходный разработчик
Ethernet). Для каждой подсети IEEE назначает 24-разрядный идентификатор
OUI (Organization Unique Identifier), остальные 24 бита адреса организация
может использовать по своему усмотрению. Вообще говоря, два из 24 битов
OUI являются управляющими, поэтому подсеть определяется только 22 битами.
Формат идентификатора OUI показан на рис. 5.1. Комбинация из 24 битов OUI
и 24 битов, присвоенных локально, называется адресом MAC (Media Access Control).
При сборке пакета данных для передачи в объединенной сети используются два
адреса MAC — по одному для отправителя и для получателя.
22 бита 24 бита
1бит 1бит| | |
И/Г У/Л Адрес подсети, назначенный IEEE Физический адрес, назначенный локально
0 = Индивидуальный 0 = Универсальный
1 = Групповой 1 = Локальный
Рис. 5.1. Структура идентификатора ОЮ
Крайний левый бит числа называется признаком индивидуального или
группового адреса (I/G). Если бит равен 0, то остальные биты определяют
индивидуальный адрес; значение 1 указывает на то, что остальные биты определяют
групповой адрес, нуждающийся в дальнейшей обработке. Если все 24 бита ОШ
заполнены единицами, то получателями являются все станции сети.
Второй бит структуры ОШ называется локальным или универсальным битом
(U/L). Если он равен 0, то значение OUI было задано административным органом
(именно этот вариант используется в OUI, назначаемых в IEEE). Если второй
бит равен 1, значит, идентификатор OUI был назначен локально, и его
интерпретация как адреса, присвоенного в IEEE, может вызвать проблемы. Обычно
применение структур, у которых второй бит равен 1, ограничивается локальными
и глобальными сетями и не передается в другие сети, которые могут следовать
формату адресации IEEE.
ПРИМЕЧАНИЕ
Некоторые старые протоколы (такие, как DECNet Phase IV) использовали локально
назначенные адреса, в которых биты локально назначенного физического адреса заполнялись сетевым
адресом DECNet.
Оставшиеся 22 бита структуры OUI содержат физический адрес подсети,
назначенный IEEE. Вторая группа из 24 бит идентифицирует адреса внутри
локальной сети и администрируется локально. 24 бита позволяют представить
около 16 миллионов адресов, но если физических адресов вдруг окажется
недостаточно, IEEE может выделить второй адрес подсети.
Адрес LLC
В стандартах IEEE Ethernet используется другой адрес, называемый адресом
канального уровня (обычно применяется сокращение LSAP от «link service access
point»). Канальный уровень в сетях IEEE делится на верхний подуровень LLC
(Logical Link Control) и нижний подуровень MAC (Media Access Control), на
котором реализуются аппаратные связи. Адреса протокола подуровня LLC
называются адресами SAP (Service Access Points) или LSAP (Logical Service Access
Points).
Адрес LSAP определяет тип протокола, используемого на канальном уровне.
Как и в случае физических адресов, дейтаграмма содержит адреса LSAP как
передающей, так и принимающей стороны.
Сетевые кадры
Структура информации в передаваемых пакетах данных зависит от протокола,
используемого сетью. Тем не менее будет поучительно проанализировать один
из вариантов структуризации и увидеть, как в дейтаграмму перед отправкой по
сети включаются упоминавшиеся выше адреса, а также другая дополнительная
информация. В качестве примера будет использована архитектура Ethernet,
широко используемая в сочетании с TCP/IP. С другими системами общий
принцип сохраняется, хотя конкретная структура заголовков может быть несколько
иной. Помните, что упаковка заголовков TCP/IP производится сетевыми
протоколами и не имеет отношения к уровню TCP/IP. Типичный кадр Ethernet
(этим термином обозначается дейтаграмма, готовая к пересылке по сети)
изображен на рис. 5.2.
| Преамбула |п^4я1отпХСеля1 Т™ [ **»»"* \ <*С [
64 бит 48 бит 48 бит 16 бит Переменная 32 бит
| I J длина
Рис. 5.2. Структура кадра Ethernet
64-разрядная преамбула предназначена в первую очередь для
синхронизации процесса и борьбы со случайным шумом в нескольких первых
отправляемых битах. В механизмах адресации и маршрутизации преамбула не
используется. В конце преамбулы находится последовательность битов SFD (Start Frame
Delimiter), после которой и начинается кадр.
Адреса получателя и отправителя в структуре кадра Ethernet хранятся в
48-разрядном формате IEEE. За ними следует 16-разрядный признак типа протокола.
После типа следуют фактические данные (дейтаграмма TCP/IP). Поле данных
в стандартной архитектуре Ethernet имеет длину от 64 до 1500 байт. Если длина
данных меньше 64 байт, они дополняются нулями. Дополнение до минимальной
длины 64 байта выполняется для того, чтобы упростить обнаружение коллизий.
В конце фрейма Ethernet находится контрольная сумма CRC (Cyclic
Redundancy Check), используемая для проверки того, что содержимое кадра не было
изменено в процессе пересылки. Каждый компьютер, входящий в маршрут
пересылки, вычисляет контрольную сумму кадра и сравнивает ее со значением
в конце кадра. Если два числа совпадают, данные кадра считаются
действительными и пересылаются дальше по сети или в подсеть. Если данные различаются,
значит, содержимое кадра было искажено, поэтому кадр отвергается, после чего
может быть послан запрос на повторную передачу.
В некоторых протоколах, имеющих отношение к Ethernet (например, IEEE
802.3), общее строение кадра остается прежним, но содержимое несколько
отличается. Так, в 802.3 16 бит, используемые в Ethernet для идентификации типа
протокола, заменяются 16-разрядной длиной блока данных. Кроме того, новое
поле следует непосредственно за областью данных.
ХР-адреса
Как упоминалось выше, в TCP/IP используются 32-разрядные адреса,
позволяющие идентифицировать любой компьютер сети и сеть, к которой он подключен.
IP-адрес определяет подключение компьютера к сети, а не сам компьютер; это
важное различие и о нем следует помнить. Изменение местонахождения
компьютера в сети иногда приводит к смене IP-адреса (в зависимости от настройки
сети). IP-адрес представляет собой набор чисел, однозначно определяющих
устройство; многие читатели часто видят эти обозначения вида 128.40.8.72 на
своих рабочих станциях и терминалах. IP-адрес состоит из четырех 8-разрядных
групп, его общая длина составляет 32 бита. IP-адреса назначаются центром NIC
(Network Information Center), хотя если сеть не подключена к Интернету, адреса
могут определяться произвольно. Общепринятый способ записи IP-адресов
называется десятичной записью с точечным разделением.
IP-адреса делятся на четыре категории в зависимости от размера сети.
Структура адресов разных категорий (от класса А до класса D) показана на рис. 5.3.
Класс определяется последовательностью начальных битов, содержащей от
одного (класс А) до четырех битов (класс D). Класс можно определить по первым
трем (старшим) битам. На практике обычно бывает достаточно двух битов,
поскольку адреса класса D используются редко.
Го | Сеть G бит) | Адрес B4 бит) |
По | Сеть A4 бит) | Адрес A6 бит) |
рГГо | Сеть B1 бит) I Адрес (8 бит) |
| 1110 | Групповой адрес B8 бит) |
Рис. 5.3. Структура четырех классов IP-адресов
Адреса класса А предназначены для крупных сетей с большим количеством
хостов. В них используется 24-разрядный локальный адрес (часто называемый
идентификатором хоста). Идентификатор сети ограничен 7 битами, что серьезно
ограничивает количество представляемых сетей.
Адреса класса В предназначены для средних сетей. В них используется
16-разрядный идентификатор хоста и 14-разрядный идентификатор сети.
В адресах класса В идентификатор хоста представлен всего 8 битами, поэтому
количество устройств ограничивается 256. Идентификатор сети содержит 21 бит.
Наконец, адреса класса D используются для групповой рассылки, когда
пакет передается нескольким устройствам.
По IP-адресу сетевой шлюз может определить, будут ли данные отправлены
в Интернет (или другое межсетевое образование) или останутся в локальной
сети. Если сетевая часть адреса получателя совпадает с идентификатором сети,
к которой подключен отправитель (пересылка в пределах сети), значит, получатель
находится в одной сети с отправителем и межсетевая пересылка не производится.
Все остальные сетевые адреса обрабатываются маршрутизатором (традиционно
называемым интернет-шлюзом), чтобы данные могли выйти за пределы
локальной сети.
Компьютер (а особенно маршрутизатор), подключенный к нескольким сетям,
может иметь несколько IP-адресов. Такие компьютеры называются
многоадресными, поскольку они имеют уникальный адрес в каждой сети, к которой он
подключен. Две сети, соединенные шлюзом, могут иметь одинаковый идентификатор,
что создает проблемы с адресацией, потому что шлюз должен быть способен
различить, к какой сети относится физический адрес. Проблема решается при
помощи специального протокола ARP (Address Resolution Protocol),
занимающегося только разрешением адресов.
Общие сведения о протоколе ARP
Чтобы отправить дейтаграмму с одного компьютера на другой в локальной или
глобальной сети, отправитель должен знать физический адрес получателя.
Должен существовать механизм преобразования IP-адресов, задаваемых
приложениями, в физические адреса устройств, соединяющих компьютеры с сетью.
Задачу преобразования IP-адресов в физические адреса можно решить
методом «грубой силы» и хранить таблицу преобразований на каждом компьютере.
Когда приложению потребуется отправить данные на другой компьютер,
программа просматривает таблицу преобразований и ищет в ней физический адрес.
Подобный метод создает множество проблем, потому им почти никто не
пользуется. Главным недостатком является необходимость постоянного обновления
таблицы адресов на каждом компьютере при внесении любых изменений.
Для решения этой проблемы был разработан протокол ARP. Этот протокол
преобразует IP-адреса в физические адреса (сетевые и локальные) и тем самым
избавляет приложения от необходимости знать что-либо о физических адресах.
Проще говоря, ARP ведет таблицу соответствия между IP-адресами и
физическими адресами, называемую таблицей ARP. Таблица ARP обычно строится
динамически, хотя существует возможность добавления статических записей для
диагностических целей и для исправления проблем с порчей данных.
Структура таблицы ARP изображена на рис. 5.4. Кроме того, ARP
поддерживает кэш записей, называемый кэшем ARP. Обычно поиск начинается с кэша
ARP, и только в случае неудачи данные ищутся в таблице ARP. Динамически
сгенерированные записи кэша ARP становятся недействительными при
истечении интервала тайм-аута, тогда как на статические записи тайм-аут не должен
распространяться. Уничтожение статических записей в результате тайм-аута
является признаком порчи данных в кэше ARP.
,^ Физический ID в„ЛЛЛ т
ИФ адрес IP-адрес Тип
Запись 1 I
Запись 2
Запись 3 1
Записи п
Рис. 5.4. Структура таблицы ARP. Каждая строка таблицы представляет одно устройство
KauiARP
Каждая строка кэша ARP соответствует одному устройству и содержит четыре
атрибута, хранящихся для каждого устройства:
О ИФ — физический порт (интерфейс).
О Физический адрес — физический адрес устройства.
О IP-адрес — IP-адрес, соответствующий физическому устройству.
О Тип — Тип записи.
Поле типа принимает четыре возможных значения:
О 2 — запись недействительна;
О 3 — соответствие устанавливается динамически (то есть запись может
измениться);
О 4 — статическое соответствие (запись не изменяется);
О 1 — ни один из перечисленных вариантов.
При получении IP-адреса, для которого нужно найти соответствующий
физический адрес, ARP просматривает кэш и таблицу ARP в поисках совпадения.
Если совпадение будет найдено, ARP возвращает физический адрес стороне, от
которой был получен IP-адрес. Если информация не обнаружена, в сеть отправ-
ляется запрос ARP — специальное широковещательное сообщение, получаемое
всеми устройствами локальной сети.
Запрос ARP содержит IP-адрес предполагаемого получателя. Если устройство
опознает IP-адрес как принадлежащий ему, оно отправляет ответное сообщение
со своим физическим адресом тому компьютеру, который сгенерировал запрос
ARP. Полученная информация сохраняется в таблице и кэше ARP для будущего
использования. Таким образом, ARP может определить физический адрес любого
компьютера на основании его IP-адреса.
Структура запросов и ответов ARP представлена на рис. 5.5. При отправке
запроса используются все поля структуры, кроме поля аппаратного адреса
получателя (который, собственно, и пытается определить этот запрос). В ответах
ARP используются все поля.
Тип оборудования A6 бит)
Тип протокола A6 бит)
Длина аппаратного Длина протокольного
адреса адреса
Код операции A6 бит)
Аппаратный адрес отправителя
IP-адрес отправителя
Аппаратный адрес получателя
IP-адрес получателя
Рис 5.5. Структура запросов и ответов ARP
Многие поля запросов и ответов ARP принимают значения из ограниченного
набора. В оставшейся части этого раздела мы более подробно рассмотрим каждое
поле и познакомимся с его назначением.
Тип оборудования
Первое поле определяет тип аппаратного интерфейса. Допустимые значения
перечислены в следующей таблице.
Значение Описание
1 Ethernet
2 Experimental Ethernet
3 Х.25
4 Proteon ProNET (Token Ring)
5 Chaos
6 IEEE 802.X
7 ARCnet
Значение Описание
8 Hyperchannel
9 Lanstar
10 Autonet Short Address
11 LocalTalk
12 LocalTalk
13 Ultra link
14 SMDS
15 Frame Relay
16 ATM (Asynchronous Transmission Mode)
17 HDLC
18 Оптоволоконная линия
19 ATM (Asynchronous Transmission Mode)
20 Последовательная линия
21 ATM (Asynchronous Transmission Mode)
Тип протокола
Второе поле определяет тип протокола, используемого
устройством-отправителем. В сочетании с TCP/IP обычно используется семейство EtherType, а
допустимые значения поля перечислены в следующей таблице.
Значение Описание
512 XEROX PUP
513 PUP Address Translation
1536 XEROX NS IDP
2048 IP (Internet Protocol)
2049 X.75
2050 NBS
2051 ECMA
2052 Chaosnet
2053 X.25 Level 3
2054 ARP (Address Resolution Protocol)
2055 XNS
4096 Berkeley Trailer
21000 BBN Simnet
24577 DEC MOP Dump/Load
Значение Описание
24578 DEC MOP Remote Console
24579 DEC DECnet Phase IV
24580 DEC LAT
24582 DEC
24583 DEC
32773 HP Probe
32784 Excelan
32821 RARP (Reverse ARP)
32823 AppleTalk
32824 DEC LANBridge
Если протокол не относится к семейству EtherType, допускаются другие
значения.
Длина аппаратного адреса (HLen)
Третье поле содержит длину каждого аппаратного адреса в дейтаграмме (в
байтах). Для сетей Ethernet это поле равно 4 байтам.
Длина протокольного адреса (PLen)
Четвертое поле содержит длину протокольного адреса в дейтаграмме (в байтах).
Для протокола IP это поле равно 4 байтам.
Код операции
Пятое поле определяет, является ли дейтаграмма запросом или ответом ARP. Для
запросов ARP его значение равно 1, а для ответов ARP используется значение 2.
Аппаратный адрес отправителя
Шестое поле определяет аппаратный адрес устройства-отправителя.
IP-адрес отправителя
Седьмое поле определяет IP-адрес устройства-отправителя.
Аппаратный адрес получателя
Восьмое поле определяет аппаратный адрес устройства-получателя.
IP-адрес получателя
Девятое поле определяет IP-адрес устройства-получателя.
Схема работы ARP
При отправке пакета IP через сетевые уровни узлов в объединенных сетях TCP/
IP компонент сетевого уровня, осуществляющий маршрутизацию, определяет
IP-адрес следующего маршрутизатора.
Маршрутизирующий компонент сетевого уровня проверяет, находится ли
хост, которому пересылается дейтаграмма IP, в локальной сети или в другом
сетевом сегменте.
Если хост-отправитель определяет, что получатель находится в локальной
сети, он должен получить аппаратный адрес получателя. Если получатель
находится в удаленной сети, то отправителю необходимо узнать аппаратный адрес
порта маршрутизатора, на который должна быть отправлена дейтаграмма IP.
В широковещательных сетях для получения аппаратных адресов,
принадлежащих локальной сети (как узлов-получателей, так и портов маршрутизатора),
применяется протокол ARP.
Протокол ARP реализуется в составе модуля IP в сетях, использующих сервис
разрешения адресов — таких, как широковещательные локальные сети (Ethernet,
Token Ring и т. д.) Протокол ARP инкапсулируется протоколом канального
уровня, но не протоколом IP. Таким образом, протокол ARP не может
маршрутизироваться, то есть никогда не выходит за граничный маршрутизатор.
Прежде чем отправлять запрос, модуль ARP пытается найти нужный адрес
в локальном кэше. Кэш ARP содержит пары, содержащие информацию о
соответствии IP-адресов и аппаратных адресов.
Если искомый IP-адрес присутствует в кэше ARP, протокол находит
соответствующий аппаратный адрес и возвращает его модулю ARP. Модуль ARP
возвращает аппаратный адрес сетевому драйверу, выдавшему заявку на определение
аппаратного адреса целевого узла. Затем сетевой драйвер передает кадр
канального уровня, содержащий дейтаграмму IP, в которой поле аппаратного адреса
получателя заполнено найденным адресом. В этом сценарии запрос ARP не
генерируется, поскольку нужные данные берутся из локального кэша.
Но что произойдет, если аппаратный адрес получателя отсутствует в кэше
ARP? В этом случае модуль ARP генерирует кадр канального уровня с
запросом ARP на получение аппаратного адреса заданного узла. Запрос ARP
рассылается на канальном уровне по всем узлам локального сетевого сегмента. Как
упоминалось выше, запросы/ответы ARP ограничиваются локальным сетевым
сегментом и не выходят за граничный маршрутизатор.
При получении запроса ARP канальный уровень искомого узла передает
пакет модулю разрешения адресов. Запрос ARP рассылается на канальном уровне,
поэтому его получают все узлы локальной сети. Тем не менее на запрос ARP
отвечает только тот узел, IP-адрес которого соответствует искомому IP-адресу.
Ниже описана последовательность действий модуля ARP на узле-получателе.
1. Сначала узел проверяет тип оборудования, указанный в соответствующем
поле запроса ARP. Если тип оборудования успешно опознан, производится
необязательная проверка поля длины аппаратного адреса в запросе ARP.
2. Узел решает, поддерживает ли он тип протокола, указанный в
соответствующем поле запроса ARP. Если ответ положителен, производится
необязательная проверка поля длины протокольного адреса в запросе ARP.
3. Флагу слияния присваивается значение false.
4. Если пара <тип протокола, протокольный адрес отправителя> уже
присутствует в кэше ARP узла, поле аппаратного адреса отправителя обновляется по
данным пакета, а флаг слияния устанавливается в положение true.
5. Затем узел решает, принадлежит ли ему указанный протокольный адрес. Иначе
говоря, он проверяет, соответствует ли его IP-адрес целевому IP-адресу,
указанному в запросе. Если ответ будет положительным, проверяется флаг
слияния, и если он равен false — триплет <тип протокола, протокольный адрес
отправителя, аппаратный адрес отправителя> добавляется в кэш ARP.
6. Наконец, узел проверяет поле кода операции и решает, является ли
полученный пакет запросом. Если ответ будет положительным, поля аппаратного
и протокольного адресов меняются местами, а в поля отправителя заносятся
локальные значения аппаратного и протокольного адресов (см. описание
поля «Код операции» в ответе ARP). Пакет отправляется по новому
аппаратному адресу с того устройства, на котором он был получен.
В описанном алгоритме перед анализом кода операции триплет <тип
протокола, протокольный адрес отправителя, аппаратный адрес отправителя>
включается в кэш ARP только в том случае, если IP-адрес отправителя отсутствует
в кэше ARP. Обновление производится только в кэшах ARP, содержащих
запись с IP-адресом отправителя.
Обновление или добавление записей в кэше ARP производится потому, что
отправителю запроса ARP с большой долей вероятности могут ответить верхние
уровни узла-получателя; когда получатель генерирует кадр канального уровня,
он обращается к кэшу ARP и обнаруживает, что аппаратный адрес отправителя
уже известен. В этом случае запрос ARP на получение аппаратного адреса
отправителя не требуется.
Если в кэше получателя уже присутствует запись для пары <тип протокола,
протокольный адрес отправителя^ то старый аппаратный адрес в кэше
заменяется новым. Это может произойти в следующих ситуациях:
О На узле, отправившем запрос ARP, произведена замена оборудования. В этом
случае изменяется аппаратный адрес того же узла.
О Произошло переназначение IP-адресов, и IP-адрес узла, отправившего запрос
ARP, отличен от того, который хранится в кэше ARP получателя.
Аппаратный адрес отправителя ARP изменяется потому, что это другой узел.
О В сети возникла проблема с дублированием адресов. Другой узел утверждает,
что он обладает тем же IP-адресом, который хранится в кэше получателя.
Первые два случая вполне обычны, но дублирование IP-адресов является
ошибкой и подробно рассматривается в соответствующем разделе этой главы.
Строение протокола ARP
Теоретически поля HLen и PLen в формате пакета ARP являются
избыточными, поскольку длина адресов, аппаратного и протокольного, определяется
значениями полей типа оборудования и типа протокола. Например, если поле
типа оборудования содержит значение 1 (признак кадра Ethernet), из этого
следует, что поле HLen должно содержать 6, поскольку длина адресов Ethernet равна
6 октетам. Аналогично, если во втором поле указан протокол IP, значение PLen
должно быть равно 4, поскольку IP-адреса состоят из 4 октетов.
Избыточные поля HLen и PLen включены для дополнительной проверки
целостности данных, а также для применения средств сетевого мониторинга.
Код операции определяет, является ли пакет запросом или ответом на
предыдущий запрос. Учитывая количество существующих кодов операций,
использование поля из двух октетов выглядит излишним. Вполне хватило бы и одного
октета.
Поля аппаратного адреса и IP-адреса отправителя нужны для их сохранения
в кэше ARP получателя. В запросе ARP поле аппаратного адреса получателя
остается пустым, поскольку именно эта величина возвращается в поле
аппаратного адреса отправителя в ответе ARP. Аппаратный адрес получателя
включается для полноты и для применения средств сетевого мониторинга.
Присутствие IP-адреса получателя в запросе ARP необходимо для того,
чтобы компьютер мог определить, является ли он получателем запроса и нужно ли
отправлять ответ. Поле IP-адреса получателя в ответе ARP в действительности
не обязательно, если предполагается, что ответ инициируется только при
получении запроса. Тем не менее это поле может использоваться при сетевом
мониторинге, а также для упрощения алгоритма обработки запросов/ответов в ARP.
Сетевой мониторинг с использованием ARP
Протокол ARP может использоваться устройством мониторинга для сбора
информации о протоколах более высокого уровня посредством простого анализа
заголовков кадров ARP. Например, анализируя поле типа протокола,
устройство сетевого мониторинга может определить, какие протоколы используются
в сети. Устройство мониторинга должно быть спроектировано с учетом
рекомендаций, приводимых в этом разделе.
При получении пакета ARP устройство мониторинга может сохранить в
таблице тип протокола, протокольный и аппаратный адреса отправителя. Кроме
того, оно может определить длину аппаратного и протокольного адреса по
содержимому полей HLen и PLen пакета ARP. Обратите внимание: пакеты ARP
пересылаются на канальном уровне, и монитор получает все запросы ARP.
Если код операции указывает на то, что пакет содержит запрос ARP, а
протокольный адрес получателя соответствует протокольному адресу монитора,
монитор отправляет ответ ARP точно так же, как бы это сделал любой другой
узел. Монитор не получает ответы ARP, так как они передаются
непосредственно хосту, отправившему запрос.
Тайм-аут в кэше ARP
В реализации кэша ARP часто поддерживается механизм тайм-аута, основанным
на временной пометке записей кэша. Ниже обсуждаются некоторые проблемы,
связанные с тайм-аутом в таблицах ARP.
При перемещении на узле обычно отключается питание, что приводит к
очистке кэша ARP и предотвращает конфликты со старыми записями. Другим
узлам сети обычно ничего не известно о перемещении или отключении
некоторого узла.
Если узел перемещается в пределах сегмента сети, информация об этом узле
в кэше ARP остается действительной, потому что аппаратный и IP-адрес
перемещенного узла остаются прежними.
Если узел отключается, другие узлы не смогут связаться с ним. Они
используют информацию из кэша ARP для обращения к узлу, но не смогут установить
связь. Неудача при установлении связи с узлом может использоваться
реализацией протокола для удаления сведений об узле Перед тем как принять решение
о неудаче, реализация может попытаться отправить еще несколько запросов ARP.
При перемещении в другой сегмент сети узел оказывается за граничным
маршрутизатором. Поскольку IP-адрес содержит информацию о сегменте сети,
к которому подключен узел, IP-адрес перемещенного узла должен измениться
даже в том случае, если его аппаратный адрес остается прежним. Вспомните,
что пересылка данных ARP не выходит за граничный маршрутизатор. На
практике можно считать, что узел был отключен или стал недоступен.
При использовании записи в кэше для пересылки пакетов узлу реализация
ARP обычно обновляет временную пометку этой записи. Пометки также
обновляются при получении запросов ARP от узла, для которого существует запись
в кэше ARP. Если в течение достаточно долгого времени, называемого интервалом
тайм-аута ARP, от узла не поступало ни одного пакета, запись удаляется из кэша.
Реализация ARP также может включать независимый процесс (так
называемый демон). Независимый процесс периодически проверяет кэш ARP и удаляет
старые записи по тайм-ауту. Во многих реализациях TCP/IP по умолчанию
используется интервал тайм-аута продолжительностью 15 минут, а в некоторых
реализациях это значение может задаваться системным администратором.
В усовершенствованном варианте этой схемы демон ARP сначала отправляет
запрос ARP узлу. Если после нескольких повторных попыток ответ ARP не
приходит, запись удаляется. В этом случае запрос ARP отправляется узлу
напрямую и не рассылается в сети, потому что аппаратный адрес узла известен из
кэша ARP. Данная схема стандартна в реализациях ARP для Linux.
Многие реализации TCP/IP позволяют вручную создавать записи в кэше
ARP. Обычно в ручном создании записей нет необходимости, поскольку связи
между IP-адресами и аппаратными адресами определяются протоколом ARP
в динамическом режиме. Записи, созданные вручную, не устаревают по тайм-ауту
и могут использоваться для решения проблем с ошибочными записями в таблице
ARP, возникающими из-за дублирования IP-адресов или неправильной работы
программ. В разных операционных системах для просмотра или внесения
изменений в кэш ARP используются разные программы — как графические, так
и работающие в режиме командной строки. В операционных системах Windows
NT/XP и Unix для этой цели используется утилита ARP. Ниже приведен
синтаксис команды ARP для Windows XP.
Отображение и изменение таблиц преобразования IP-адресов в физические,
используемые протоколом разрешения адресов (ARP)
ARP -s inet_addr eth_addr [if_addr]
ARP -d inet_addr [if_addr]
ARP -a [inet_addr] [-N if_addr]
-а Отображает текущие ARP-записи, опрашивая текущие данные
протокола. Если задан inet_addr, то будут отображены IP
и физический адреса только для заданного компьютера.
Если более одного сетевого интерфейса используют ARP,
то будут отображаться записи для каждой таблицы.
-g To же, что и ключ -а.
inet_addr Определяет IP-адрес
-N if_addr Отображает ARP-записи для заданного в i faddr сетевого
интерфейса.
-d Удаляет узел, задаваемый inet_addr. inet_addr может содержать
символ шаблона * для удаления всех узлов.
-s Добавляет узел и связывает internet адрес inet_addr
с физическим адресом eth_addr. Физический адрес задается
6 байтами (в шестнадцатеричном виде), разделенными дефисом.
Эта связь является постоянной.
eth_addr Определяет физический адрес.
if_addr Если параметр задан, он определяет интернет-адрес интерфейса,
чья таблица преобразования адресов должна измениться.
Если не задан, - будет использован первый доступный интерфейс.
Пример:
> агр -s 157.55.85.212 00-аа-00-62-с6-09 ... Добавляет статическую запись
> агр -а ... Выводит ARP-таблицу.
ARP в мостовых сетях
Сети соединяются при помощи мостовых устройств, работающих на уровне 2 OSI,
и маршрутизаторов, работающих на уровне 3. Мосты расширяют область
действия локальной сети. Работа ARP в локальных сетях требует особого
обсуждения, которое станет темой этого раздела.
Когда попытка установить связь TCP/IP завершается неудачей, протокол
TCP, отвечающий за надежную доставку, пытается переслать пакеты заново.
Если неудача была обусловлена физическим сбоем канала, а к получателю ведут
другие пути, дейтаграмма IP маршрутизируется в обход сбойного участка. Если
TCP не удается восстановить связь, восстановление продолжается на более
низких уровнях, где модуль ARP пытается восстановить связь, производя
широковещательную рассылку запросов ARP. Если получатель находится в локальном
сегменте сети, подобный способ восстановления приемлем. Впрочем, когда
несколько узлов начинают одновременно рассылать широковещательные запросы
ARP, возникают проблемы. Рассмотрим ситуацию, когда центральный хост
становится недоступным из-за сбоя канала или оборудования. Если 100 станций
подключены к центральному хосту в сети и связь с хостом вдруг прерывается,
все 100 станций начинают одновременно передавать широковещательные
запросы ARP. В некоторых системах запросы ARP отправляются каждую секунду;
следовательно, ежесекундно в системе будет генерироваться сто
широковещательных запросов. В результате создается значительный объем сетевого трафика,
который отрицательно влияет на доступность сети для других узлов.
Широковещательный трафик даже может замедлить работу узлов, которые
в настоящий момент не обращаются к сети. Дело в том, что сетевой адаптер и
связанный с ним программный драйвер должны анализировать каждый
широковещательный пакет. В случае с запросами ARP для каждого широковещательного
запроса также должен выполняться модуль ARP. Обработка даже 50 запросов
ARP в секунду требует заметных вычислительных мощностей и замедляет работу
узла. В результате возникает впечатление, что все узлы сети замедляются.
Повторение широковещательных запросов ARP создает дальнейшие
затруднения в мостовых сетях. Сетевые сегменты, разделенные мостами, считаются
частью одного домена MAC, а запросы/ответы ARP должны передаваться через
мосты. Распространение широковещательного трафика за границы мостов
приводит к дальнейшему нарастанию его объема. В таких условиях создание
больших или сложных сетевых топологий с использованием мостов нежелательно.
Дублирование адресов и ARP
IP-адреса в сети должны быть уникальными. Но как обеспечить эту
уникальность? За счет хорошо организованного документирования и правил назначения
IP-адресов. Но так как в назначении IP-адресов участвует человеческий фактор,
нельзя исключать появления в сети узлов с одинаковыми IP-адресами. Если это
произойдет, в сети возникает хаос; сетевые приложения начинают вести себя
непредсказуемо или вовсе прекращают работать.
Чтобы вы лучше поняли последствия от дублирования IP-адресов, в
следующих разделах будут рассмотрены два сценария:
О дублирование IP-адресов клиентов TCP/IP;
О дублирование IP-адресов серверов TCP/IP.
Дублирование IP-адресов клиентов TCP/IP
Предположим, два клиента TCP/IP (далее — «клиент 1» и «клиент 2»)
обращаются к центральному серверу TCP/IP по IP-адресу 144.19.74.102. Аппаратный
адрес сервера равен 080020021545.
Клиенты 1 и 2 используют один и тот же IP-адрес 144.19.74.1. Их
аппаратные адреса равны 0000С0085121 и 0000С0075106 соответственно.
Клиент 1 начинает сеанс FTP на сервере TCP/IP. Перед началом сеанса FTP
клиент 1 рассылает широковещательный запрос ARP для получения аппаратного
адреса сервера TCP/IP. При получении запроса ARP сервер TCP/IP добавляет
в кэш ARP запись для отправителя запроса (клиента 1) и отправляет ему ответ
ARP. При получении ответа ARP клиент 1 добавляет запись для сервера TCP/IP
в свой локальный кэш ARP. На этой стадии кэши ARP на сервере TCP/IP и на
клиенте 1 находятся в следующем состоянии.
Сервер TCP/IP:
IP-адрес Аппаратный адрес
144.19.74.1 0000С0085121
Клиент 1:
IP-адрес Аппаратный адрес
144.19.74.102 080020021545
Во второй фазе клиент 2 пытается открыть сеанс TCP/IP (например, другой
сеанс FTP) с тем же сервером TCP/IP.
Прежде чем устанавливать связь, клиент 2 должен узнать аппаратный адрес
сервера TCP/IP. Он пытается сделать это, отправляя запрос ARP. При
получении запроса ARP сервер TCP/IP должен занести информацию об отправителе
запроса (клиенте 2) в кэш ARP и вернуть ему ответ. Сервер TCP/IP
обнаруживает, что в кэше ARP уже имеется запись для адреса 144.19.74.1. В соответствии
с RFC 826 сервер TCP/IP должен заменить существующую запись новой.
Большинство реализаций TCP выполняет замену автоматически, без
предупреждения о возможности потенциального дублирования IP-адресов, хотя некоторые
реализации выдают такое предупреждение. Сервер TCP/IP отвечает на запрос
ARP от клиента 2. При получении ответа компьютер 2 добавляет запись с
данными сервера TCP/IP в свой локальный кэш ARP. На этой стадии кэши ARP
на сервере TCP/IP и на клиенте 2 находятся в следующем состоянии.
Сервер TCP/IP:
IP-адрес Аппаратный адрес
144.19.74.1 0000С0075106
Клиент 1:
IP-адрес Аппаратный адрес
144.19.74.102 080020021545
Когда сервер TCP/IP захочет отправить данные клиенту 1, он ищет
аппаратный адрес клиента 1 по IP-адресу 144.19.74.1 в локальном кэше ARP и
отправляет данные по найденному адресу. К сожалению, этот аппаратный адрес
принадлежит клиенту 2, поэтому данные будут отправлены клиенту 2. Клиент 1, не
получив ожидаемые данные, пытается повторить последний запрос, но сервер
TCP/IP снова отправит ответ клиенту 2. Клиент 1 «виснет» в ожидании ответа.
Со временем операция будет отменена по тайм-ауту, или компьютер придется
перезагрузить. Так или иначе, приложение, которое раньше благополучно
работало, вдруг перестает работать, к немалому удивлению пользователя и
системного администратора.
Клиент 2 неожиданно для себя получает данные, предназначенные для
клиента 1. Вероятно, он отвергнет эти данные, может быть сгенерирует сообщение
об ошибке и продолжит свой сеанс с сервером TCP/IP. Также не исключено,
что компьютер придет в замешательство и «зависнет».
Если пользователь клиента 1 перезагрузит «зависший» компьютер и
попытается снова подключиться к серверу TCP/IP, данные кэша клиента 2 на сервере
TCP/IP будут заменены данными клиента 1. Теперь «зависает» клиент 2, и
ситуация повторяется до тех пор, пока пользователи не оставят свои попытки.
Если пользователи клиентов 1 и 2 не обмениваются информацией о
возникающих проблемах, каждый пользователь видит происходящее лишь со своей
стороны — его клиент «виснет» на середине сеанса работы с сервером TCP/IP.
Если обращения к серверу происходят в разное время, не исключено, что
проблема не проявится, а дублирование IP-адресов останется незамеченным. Если
же пользователи будут сталкиваться с проблемой время от времени, они решат,
что происходящее вызвано какими-то сетевыми сбоями и не станут сообщать
о проблеме. Дублирование адресов снова останется незамеченным.
Дублирование IP-адресов на серверах TCP/IP
Теперь рассмотрим несколько иную ситуацию. Имеются два сервера TCP/IP
(далее — «сервер 1» и «сервер 2»), которым были присвоены одинаковые IP-адреса
144.19.74.102. Аппаратные адреса серверов равны 080020021545 и АА0004126750.
Клиент с IP-адресом 144.19.74.1 пытается обратиться к серверу TCP/IP по
адресу 144.19.74.102. Аппаратный адрес клиента равен 0000С0085121.
Клиент пытается соединиться с сервером 2. Прежде чем создать соединение
TCP/IP, клиент генерирует широковещательный запрос ARP для получения
аппаратного адреса сервера TCP/IP. Один и тот же аппаратный адрес 144.19.74.102
присвоен двум серверам TCP/IP. При получении запроса ARP оба сервера
создают записи для отправителя запроса ARP (клиента) в своих локальных кэшах
ARP и отправляют ему ответ ARP. Клиент принимает первый ответ ARP и молча
игнорирует второй ответ. Если ответ сервера 2 достигнет клиента первым,
клиент включит в локальный кэш запись для сервера 2. На этой стадии кэши ARP
на серверах и клиенте находятся в следующем состоянии.
Сервер 1:
IP-адрес Аппаратный адрес
144.19.74.1 0000С0085121
Сервер 2:
IP-адрес Аппаратный адрес
144.19.74.1 АА0003126750
Клиент 1:
IP-адрес Аппаратный адрес
144.19.74.102 080020021545
Клиент продолжает работать с сервером 2, а не с сервером 1, как
предполагалось изначально. Если нужная служба отсутствует на сервере 2, подключение
завершается неудачей, а пользователь неожиданно получает сообщение о том,
что служба не поддерживается сервером. Это сильно озадачит пользователя,
особенно если раньше он успешно пользовался услугами сервера 1.
Если на сервере 2 имеется нужная служба, пользователь пытается
подключиться к ней. Для таких служб, как Telnet и FTP, требуется ввести имя и пароль.
Только особенно внимательный пользователь заметит, что имя/номер версии
сервера FTP или Telnet, выводимый на экране, отличается от предполагаемого.
Если на сервере 2 не существует учетной записи с таким же именем и паролем,
как на сервере 1, попытка подключения будет отвергнута. Если имя и пароль
совпадают на обоих серверах, пользователь подключится не к тому серверу, к
которому он собирался подключиться. Возможны разные последствия — например,
пользователь может не найти нужных файлов или данных.
Если сервер является многоадресным (сервер с несколькими сетевыми
подключениями) и выполняет функции маршрутизатора, ситуация может оказаться
еще более запутанной — пакеты, предназначенные для внешней сети, могут
следовать по другому маршруту или не будут доставлены из-за того, что они будут
приняты не тем сервером.
Проверка дублирования адресов ARP
Многие реализации TCP/IP при запуске производят широковещательную
рассылку запроса ARP. В рассылаемом запросе поле IP-адреса получателя
заполняется IP-адресом запускаемого узла.
Исходный запрос ARP проверяет, имеются ли в сети узлы с одинаковым
IP-адресом. Если узел получит ответ ARP, значит, IP-адрес другого узла
(сгенерировавшего ответ ARP) совпадает с IP-адресом запускаемого узла.
Запускаемый узел должен сообщить о дублировании IP-адресов каким-либо подходящим
способом. Узел, отвечающий на запрос ARP, даже может дополнительно
проверить поле IP-адреса отправителя и сравнить его с собственным IP-адресом.
Если IP-адреса отправителя и получателя совпадают, то отвечающий узел может
сгенерировать сообщение о дублировании IP-адресов.
Кадр ARP, структура которого была описана выше, позволяет обнаруживать
только дублирующиеся IP-адреса в том же сегменте сети. Поскольку пакеты
ARP не выходят за маршрутизатор, они не позволяют обнаружить проблемы
с дублированием IP-адресов в сегментах сетей, соединенных маршрутизаторами.
Исходный широковещательный запрос ARP также предназначен для узлов,
приступающих к обновлению кэша ARP, у которых имеется запись для
запускаемого узла. Если аппаратный адрес запускаемого узла изменился (из-за смены
сетевого оборудования), то все узлы, получившие запрос, должны удалить старый
аппаратный адрес и обновить свои кэши ARP новым адресом.
Proxy ARP
Ранее в этой главе было показано, что две сети, соединенные через шлюз, могут
содержать одинаковые сетевые адреса. Шлюз должен определить, к какой из сетей
относится физический или IP-адрес входящей дейтаграммы. Для этого он
может воспользоваться модифицированной версией ARP, называемой Proxy ARP.
Proxy ARP строит кэш ARP, состоящий из записей обеих сетей. Шлюз должен
управлять запросами и ответами ARP, пересекающими границу между сетями.
Объединяя два кэша ARP, Proxy ARP вносит дополнительную гибкость в
процесс разрешения адресов и предотвращает появление лишних дейтаграмм с
запросами/ответами ARP, когда адрес находится за границей шлюза.
RARP
Если устройство не знает свой IP-адрес, оно не сможет сгенерировать запросы
и ответы ARP. Подобные ситуации характерны для таких устройств, как
бездисковые рабочие станции в сети. Единственный адрес, известный устройству, — это
физический адрес, установленный на сетевом адаптере.
Простейший выход из ситуации заключается в использовании протокола RARP
(Reverse Address Resolution Protocol), который по выполняемым функциям
противоположен ARP. Компьютер отправляет физический адрес и ожидает получить
обратно IP-адрес. Ответ, содержащий IP-адрес, отправляется сервером RARP —
хостом, который может предоставить эту информацию. Хотя
устройство-отправитель передает сообщение в широковещательном режиме, в правилах RARP
сказано, что только сервер RARP может сгенерировать ответ. Во многих сетях
используется несколько серверов RARP, как для распределения нагрузки, так
и для выполнения резервных функций при возникновении проблем.
RARP часто используется «бездисковыми станциями», не имеющими
локальных накопителей. На самом деле современные бездисковые станции часто
оснащаются локальным диском, но он используется только для ускорения работы
операционной системы, но не для хранения параметров TCP/IP, хранящихся на
удаленном сервере. Например, на локальном диске может храниться локальный
файл подкачки, необходимый для реализации виртуальной памяти в
операционной системе.
На бездисковых станциях также имеется копия операционной системы,
хранящейся на удаленном сервере. При запуске бездисковая станция загружает
копию операционной системы с удаленного сервера в память. Но чтобы станция
могла начать загрузку образа операционной системы с использованием
протоколов передачи файлов TCP/IP, ей нужно знать свой IP-адрес. Этот адрес не
может быть произвольной величиной; он должен быть уникальным и иметь тот же
префикс, что и IP-адреса других узлов сегмента сети. Например, если другие
станции сети имеют IP-адреса 199.245.180.1, 199.245.180.5 и 199.245.180.7, то
общий префикс имеет вид «199.245.180». Бездисковая станция тоже должна иметь
тот же префикс. Общий префикс необходим из-за того, что он определяет
маршрут пакета в сегменте сети.
Обычно бездисковые станции получают свой IP-адрес, отправляя запрос
серверам текущего сегмента сети. Поскольку информация об адресе удаленного
сервера тоже недоступна, запрос отправляется в виде широковещательной
рассылки канального уровня. Один из механизмов получения IP-адресов от
удаленных серверов основан на использовании протокола RARP (Reverse Address
Resolution Protocol). Этот протокол называется «обратным» (reverse), потому
что он выполняет преобразование адреса, обратное тому, которое выполняется
протоколом ARP.
Бездисковые станции используются для снижения стоимости оборудования,
упрощения конфигурации и обновления узлов за счет централизованного
хранения важнейшей информации, а также снижения вероятности проникновения
вирусов в систему, поскольку конечный пользователь не может легко установить
свою программу на бездисковую станцию.
Схема работы RARP
Узел, желающий узнать свой IP-адрес (клиент RARP), рассылает
широковещательный запрос, называемый запросом RARP. Запрос RARP рассылается на
канальном уровне, потому что клиент RARP не знает адрес (аппаратный или IP)
удаленного сервера. Удаленный сервер, обрабатывающий запрос RARP,
называется сервером RARP.
При наличии нескольких серверов RARP все серверы пытаются обработать
запрос RARP. Обычно клиент RARP принимает первый полученный ответ и
игнорирует остальные.
Сервер RARP содержит таблицу IP-адресов для узлов сегмента сети. Таблица
индексируется по идентификатору, уникальному для каждого компьютера. Этот
уникальный идентификатор передается в запросе RARP. Для бездисковых
станций этот уникальный идентификатор должен представлять собой некий
аппаратный и достаточно легко определяемый параметр. Идентификатор не может
храниться локально, на бездисковых станциях отсутствует локальный диск,
который бы мог использоваться для этой цели. Проектировщики RARP (см. STD 38,
RFC 903) решили использовать для идентификации аппаратные адреса, поскольку
они уникальны в границах сегмента сети и легкодоступны для сетевых драйверов.
Получая запрос RARP, сервер RARP просматривает таблицу ассоциаций
между IP-адресами и аппаратными адресами (рис. 5.6). Если в процессе просмотра
будет найдена запись, соответствующая аппаратному адресу в запросе RARP,
протокол возвращает найденный IP-адрес в ответе RARP. Ответ RARP не
рассылается в широковещательном режиме; сервер берет аппаратный адрес клиента
RARP из запроса RARP.
Пакеты запросов и ответов RARP имеют такую же структуру, как пакеты ARP.
ARP и RARP различаются по значениям, содержащимся в полях. Если пакет
RARP передается в кадре Ethernet, используется код EtherType 8035 (шести.).
Ниже перечислены значения отдельных полей в пакетах RARP.
Запрос RARP:
О Аппаратный адрес получателя = рассылка.
О Аппаратный адрес отправителя = аппаратный адрес клиента RARP.
О EtherType «= 8035 (шести.).
О Код операции = 3 (запрос RARP).
О Аппаратный адрес отправителя = аппаратный адрес клиента RARP.
О IP-адрес отправителя * не определен; обычно используется 0.0.0.0.
RARP Operation
Адрес отправителя = PA
Адрес получателя = рассылка
Ethertype = 8035 hex
С RARP ^^L
( daemon Д1
^—/"~*^ВЭ Сервер RARP
| Запрос RARP | Канал [—► Рассылка ШШ Г "Ч
Г ^ ^ л А
—£—У*—У* ;—°— /; \
<—| Канал | Ответ RARP \<r ! \
шШШШШШ ШИ | адрес | адрес |
Рис. 5.6. Схема работы RARP (с разрешения Learning Tree)
О Аппаратный адрес получателя = аппаратный адрес клиента RARP.
О IP-адрес отправителя = не определен.
Ответ RARP:
О Аппаратный адрес получателя = аппаратный адрес клиента RARP.
О Аппаратный адрес отправителя = аппаратный адрес сервера RARP.
О EtherType = 8035 (шести.).
О Код операции = 4 (ответ RARP).
О Аппаратный адрес отправителя = аппаратный адрес сервера RARP.
О IP-адрес отправителя = IP-адрес сервера RARP.
О Аппаратный адрес получателя = аппаратный адрес клиента RARP.
О IP-адрес отправителя = IP-адрес клиента RARP (возвращаемое значение).
Поле аппаратного адреса получателя в запросе заполняется аппаратным
адресом клиента RARP. Это делается для удобства сервера, чтобы ему не пришлось
заполнять это поле, которое должно содержать аппаратный адрес клиента RARP
в ответе.
Сетевой драйвер анализирует поле EtherType, определяет, что пакет является
пакетом RARP (EtherType - 8035 шести.) и отправляет запрос модулю RARP.
Запросам RARP соответствует код операции 3, а ответам RARP — код операции
4. Содержимое этих полей также может использоваться для того, чтобы отличить
пакеты RARP от пакетов ARP. Тем не менее такой подход недостаточно
эффективен. Модулю ARP пришлось бы анализировать поле кода операции в пакете,
и если код указывает на пакет RARP — передать пакет модулю RARP.
Использование поля EtherType позволяет более эффективно выполнить
демультиплексирование на низком уровне.
ПРИМЕЧАНИЕ
Во многих реализациях поддержка RARP не интегрируется в модулях ARP и IP. Ее необходимо
запускать в виде отдельного процесса (например, демона) на компьютере, выполняющем функции
сервера RARP.
Сбой сервера RARP
Если сервер RARP становится недоступным из-за сбоя сетевого соединения или
из-за выхода компьютера из строя, клиенты RARP не смогут нормально
загрузиться. Они будут снова и снова рассылать широковещательные запросы RARP.
Одновременная рассылка запросов многими клиентами RARP серьезно
увеличивает сетевой трафик.
Отсутствие ожидаемого ответа RARP приводит к более серьезным
последствиям, нежели для протокола ARP. Отсутствие ответа ARP означает лишь то, что
конкретный хост и его службы недоступны в настоящий момент — клиент ARP
может попытаться обратиться к другим узлам сети. Тем не менее при отсутствии
ответа RARP клиент не сможет загрузиться. Многие клиенты RARP продолжают
рассылать широковещательные запросы в течение неопределенно долгого времени
в надежде, что сервер RARP когда-нибудь снова станет доступным. Следовательно,
повторение широковещательных запросов RARP порождает больше проблем, чем
повторение запросов ARP, из-за возрастания сетевого трафика.
Основные и резервные серверы RARP
Чтобы сделать работу RARP более надежной, можно использовать несколько
серверов RARP. Если в сети работает несколько серверов RARP, при получении
широковещательного запроса каждый сервер попытается ответить на этот запрос.
Только один ответ используется клиентом RARP; все остальные ответы
игнорируются. Для предотвращения рассылки множественных ответов RARP
применяется схема, при которой один сервер RARP назначается основным, а все
остальные — резервными.
Получив запрос RARP, основной сервер отвечает на него. Резервные серверы
не отвечают, но регистрируют время прибытия запроса. Если основной сервер
не ответит в течение интервала тайм-аута, то резервный сервер RARP считает,
что основной сервер недоступен, и отвечает на запрос.
Если в сети работает несколько резервных серверов, все резервные серверы
попытаются ответить одновременно. В усовершенствованном варианте этой схемы
резервный сервер отвечает не сразу, а ожидает в течение случайного интервала
времени. При нормальной работе основного сервера дополнительных задержек
с отправкой ответа RARP не будет. Если основной сервер вышел из строя,
возможна небольшая случайная задержка перед тем, как ответит один из резервных
серверов RARP.
Команда ARP
Многие (но не все) реализации TCP/IP предоставляют средства для проверки
содержимого кэша. В Unix и Windows NT/2000/XP существует команда агр,
выводящая все содержимое кэша ARP. Для просмотра кэша команда вводится
с ключом -а:
$ агр -а
brutus <205.150.89.3> at 0:0:d2:03:08:10
В данном примере кэш содержит данные компьютера brutus с IP-адресом
205.150.89.3 и адресом MAC 0:0:d2:03:08:10.
Команда агр обычно используется только тогда, когда администратор сети
пытается решить проблемы с дублированием IP-адресов. Если в сети имеются
два компьютера с одинаковыми IP-адресами (но разными адресами MAC),
информация о них будет присутствовать в кэше ARP.
Итоги
В этой главе были рассмотрены самые распространенные протоколы
разрешения адресов: ARP, Proxy ARP и RARP. Глава начинается с описания того, как
дейтаграммы TCP/IP собираются в кадры Ethernet. После знакомства со всеми
иерархическими уровнями, задействованными в работе межсетевых объединений,
вы получили достаточно хорошее представление о том, как работает TCP/IP
и как происходит передача данных по сети заданному хосту.
fZ DNS
Рима С. Регас (Rima S. Regas)
Каранжит С. Сиян (Karanjit S. Siyan)
На ранней стадии развития ARPANET, когда сеть оставалась относительно
небольшой, пользователи сети должны были поддерживать конфигурационный
файл HOSTS с информацией о рабочих станциях, входящих в сеть. Файл был
необходим для взаимодействия с другими системами в сети. Тем не менее такое
решение создавало немало проблем, поскольку файл HOSTS приходилось
обновлять вручную на каждом компьютере. Автоматизация настройки конфигурации
практически отсутствовала, вследствие чего обновление файла было
утомительным и долгим процессом.
Файл HOSTS содержит информацию о том, какой IP-адрес связывается с тем
или иным именем. Когда компьютеру требовалось найти другой компьютер в сети,
он обращался к локальному файлу HOSTS. Компьютер, не имеющий записи в
файле HOSTS, фактически не существовал для сети. Служба DNS (Domain Name
System) кардинально изменила эту ситуацию. У системных администраторов
появляется возможность использования сервера в качестве хоста DNS.
Например, когда компьютеру в сети потребуется узнать данные другого сервера, он
обращается к файлу HOSTS.
В наше время файл HOSTS продолжает использоваться, но обычно только для
того, чтобы предотвратить поиск локальных компьютеров средствами DNS.
Выборка информации из файла происходит гораздо быстрее. Короче говоря,
сетевое программное обеспечение компьютера настроено таким образом, чтобы оно
просматривало локальный файл HOSTS перед тем, как обращаться к серверу DNS.
При обнаружении информации в файле клиентская программа продолжает
работать с удаленным хостом, что существенно уменьшает затраты времени по
сравнению с получением IP-адреса средствами DNS.
Система доменных имен: общие принципы
Как известно, имена запоминаются проще, чем числа. Многие люди обладают
феноменальной способностью запоминать телефонные номера, адреса,
денежные суммы и другие числа, но в настоящее время существует слишком много
IP-адресов, чтобы можно было запомнить хотя бы их малую часть. По этой
причине была разработана методика присваивания имен IP-адресам,
основанная на мнемоническом принципе. Например, C|Net было присвоено доменное имя
www.cnet.com (обратите внимание на отсутствие вертикальной черты и
прописных букв). По сравнению с именем сайта оно выглядит невыразительно, но тем
не менее оно работает и прекрасно ассоциируется с именем сайта. C|Net — один
из самых больших и посещаемых сайтов в мире.
Система DNS появилась из-за очевидной необходимости в системе, которая
бы транслировала символические имена в IP-адреса. В результате трансляции
или разрешения доменного имени сайта (например, www.cnet.com) возвращается
IP-адрес B04.162.80.181), который используется для обращения к данным. Именно
таким образом в ваш браузер доставляется запрашиваемая информация. Процесс
требовал создания сети систем, которые назывались серверами DNS (Domain
Name Service).
Частью работы по поддержанию системы DNS в Интернете является
поддержка первичных (корневых) доменных серверов, к которым остальные серверы
DNS обращаются для получения информации о доменах верхнего уровня,
зарегистрированных в Интернете. Информация DNS распределяется по
большому количеству серверов DNS. Если ваш сервер DNS не может преобразовать
доменное имя в IP-адрес, он обращается к другому серверу DNS, который, как
предполагается, обладает более полной информацией о преобразуемом имени.
Если этот сервер тоже не справляется с преобразованием имени, он может
вернуть ссылку на другой сервер DNS, который может знать ответ. Процесс
повторяется до тех пор, пока не произойдет тайм-аут. В этом случае исходному узлу
возвращается признак ошибки и выводится соответствующее сообщение (если
такая возможность поддерживается клиентом). Если поиски web-сайта
завершаются неудачей, браузер выводит сообщение о том, что сайт найти не удалось
или произошла ошибка DNS.
Ссылочный механизм, описанный выше, обычно используется серверами
DNS при обращении с запросами к другим серверам DNS. Подобный тип запроса
DNS называется итеративным. Резольвер DNS (другое название клиента DNS)
находится на узле, выдавшем запрос DNS. Резольвер не генерирует итеративные
запросы, вместо этого он выдает запрос другого типа — так называемый
рекурсивный запрос. Узел, отправивший рекурсивный запрос серверу DNS, ожидает,
что последний вернет окончательный ответ или информацию о том, что имя
разрешить не удалось. Получив рекурсивный запрос, сервер DNS не возвращает
ссылку на другой сервер DNS; он должен самостоятельно сгенерировать
итеративные запросы для получения окончательного ответа.
Система DNS начинается с корневых серверов DNS верхнего уровня, далее
информация об именах и IP-адресах распространяется по серверам DNS,
расположенным по всему миру. Иерархическое строение системы, непосредственно
обусловленное ее организационной структурой, наглядно демонстрирует
простой пример — отсутствие локальной информации о преобразовании на сервере
DNS. Если сервер не может найти нужный IP-адрес в собственной базе данных,
он обращается к другому серверу DNS; это продолжается до тех пор, пока
информация не будет найдена или не произойдет тайм-аут. В следующем разделе
приводится более подробное описание структуры DNS, поскольку
иерархическое строение системы имеет другой, очень важный аспект.
Иерархическое строение DNS
В исходном документе RFC 819, опубликованном в 1982 году, Зав-Синг Су
(Zaw-Sing Su) и Джон Постел (Jon Postel) изложили основные планы и
концепции DNS. Ниже приведен фрагмент, который дает представление об уровне
изложения.
«...Совокупность доменов формирует иерархию. Используя представление
из теории графов, эту иерархию можно смоделировать в виде направленного
графа. Направленный граф представляет собой набор узлов и ребер, при этом
ребра определяются упорядоченными парами узлов [1]. Каждый узел графа
представляет домен. Упорядоченная пара (В, А), то есть ребро, следующее от
В к А, означает, что В является субдоменом А, а В является простым именем,
уникальным в А».
Понять такой текст непросто, поэтому мы воспользуемся более простым
объяснением. Основной принцип прост: имеется некий домен верхнего уровня —
например, com или edu. Домены com и edu находятся на верхнем уровне и не
имеют вышестоящих доменов. Впрочем, существует одно исключение: на самом
деле после com должна стоять точка (com.). Она обозначает домен еще более
высокого уровня, чем com, который называется корневым доменом. Домены
верхнего уровня (такие, как com, edu и org) называются универсальным
множеством имен, потому что они содержат домены и субдомены, расположенные на
более низких уровнях иерархии.
После верхнего уровня следуют промежуточные домены, или домены второго
уровня. В качестве примеров промежуточных доменов можно привести домены
coke.com, whltehouse.gov и disney.com. Эти домены также могут регистрироваться,
но обычно это делается только для того, чтобы зарезервировать целый
диапазон логически связанных доменных имен. На практике чаще встречается
регистрация субдоменов, или конечных (endpoint) доменов, как их называли Су
и Постел. Примеры — www.coke.com, www.whitehouse.gov и www.disney.com.
Разумеется, все эти домены типичны для регистрационной системы InterNIC. В
других системах, находящихся за пределами Соединенных Штатов, используются
различные схемы обозначения направленности и страны, к которой относится
домен. Например, имя www.bbc.co.uk указывает на то, что сайт ВВС имеет
коммерческую направленность (со, аналог com) и находится в Соединенном
Королевстве (uk).
Имена субдоменов выбираются почти произвольно. Примеры — www.netscape.
com, home.netscape.com, wwwl.netscape.com. Они могут находиться в разных местах
Интернета и содержать разную информацию. Конечно, если web-мастер сочтет
нужным, несколько имен могут ссылаться на один сайт и одну страницу. Именно
так обстоит дело с сайтом Netscape; к нему можно обратиться по любому из
перечисленных URL.
U
III U: Универсальное множество имен
I E | I: Промежуточный домен
/\ Е: Конечный домен
Е Е I
Е Е Е
Рис. 6.1. Исходная иерархия доменов
ПРИМЕЧАНИЕ
Другой пример: Webopaedia также решила зарегистрировать субдомен webopedia.com, поскольку
у многих пользователей возникали проблемы с дифтонгом аэ.
Делегирование полномочий
Устройство системы DNS позволяет серверам, подчиненным по отношению к
корневым серверам имен, контролировать заданный домен. Хорошим примером
является локальный поставщик услуг Интернета, который обеспечивает хостинг
web-сайтов для отдельных лиц и организаций. Когда некая организация X
регистрирует в InterNIC свое доменное имя (www.companyx.com), она включает в заявку
первичный и вторичный серверы DNS своего поставщика. InterNIC заносит эту
информацию на свой корневой сервер .com и обеспечивает ее дальнейшее
распространение.
ПРИМЕЧАНИЕ
Серверы DNS периодически синхронизируют свои локальные базы данных с базами данных других
серверов DNS и проверяют, не появились ли новые записи на корневых серверах. Этот процесс
называется распространением (propagation). Регистрация доменных имен требует некоторого
времени, но зарегистрированное имя распространяется в Интернете в течение примерно трех-четы-
рех дней и становится доступным во всем мире.
Чтобы эта система нормально работала, возникла потребность в средствах
определения местонахождения компьютера в сети. Из этой потребности стала
развиваться иерархия систем и механизмы классификации компьютеров по
выполняемым функциям. Например, если компьютер находится в учебном
заведении, он принадлежит к домену верхнего уровня .edu. Сайты коммерческой
направленности принадлежат к домену верхнего уровня .com и т. д. Данная
концепция формирует основу логической иерархии DNS, но не определяет
структуру корневых серверов имен (вскоре мы вернемся к этой теме).
Распределенная база данных DNS
Архитектура распределенной базы данных, заложенная в основу DNS, обладает
большими возможностями. Как упоминалось выше, полномочия делегируются
другим серверам, местонахождение которых лучше подходит для обработки
трафика некоторого домена или субдомена. Распространение информации по
серверам происходит по хорошо продуманному плану.
Каждому домену назначается владелец. Информация о владельце
определяется как часть доменных данных SOA (Start of Authority), которые будут более
подробно рассмотрены ниже. Домен верхнего уровня — например, com. —
делегирует полномочия контроллера для некоторого доменного имени (скажем,
disney.com) серверам DNS, указанным в качестве первичных. Тем самым
контроллер домена верхнего уровня освобождается от необходимости обрабатывать
каждый запрос DNS в Интернете.
После того как с контроллером домена будут связаны данные SOA, он сможет
делегировать полномочия контроллера для субдоменов другим серверам DNS
и т. д. По этому принципу организуется делегирование полномочий в иерархии
серверов DNS от верхнего уровня до нижнего.
Домены и зоны
Домены и зоны часто работают вместе, но между ними существует тонкое
различие. Зоной (zone) называется первичный домен универсального множества имен,
делегированный другому серверу DNS для административных целей. Например,
Disney.com — это зона, а www.disney.com — хост, находящийся в этой зоне. Зона
может состоять из одного домена или нескольких субдоменов. Например, студия
Диснея может создать субдомены с именами east-coast.Disney.com и west-coast.
Disney.com. В случае делегирования эти субдомены образуют отдельные зоны
с именами east-coast.Disney.com и west-coast.Disney.com, которые будут иметь
собственные серверы DNS. Без делегирования эти субдомены останутся частью
зоны Disney.com и будут обслуживаться серверами DNS сервера Disney.com.
Административные обязанности делегируются первичному серверу DNS.
Первичный сервер DNS сайта Диснея, huey.disney.com, имеет IP-адрес 204.128.192.10.
Поскольку Huey назначается первичным сервером DNS для домена Disney, он
также является первичным сервером DNS для зоны Disney.com. Назначенный
владелец этого сервера имеет адрес root@huey.disney.com, который хранится в SOA
в виде root.huey.disney.com.
ПРИМЕЧАНИЕ
Учтите, что в правильно отформатированных данных SOA символ @ в адресе электронной почты
администратора заменяется точкой. В некоторых компаниях используются адреса электронной
почты, в которых перед @ стоит дополнительный разделитель. В этом случае возникнут проблемы,
потому что адрес вида host.admin@example.com будет храниться в SOA в виде host.admin.
example.com. Любая система, пытающаяся преобразовать этот адрес, интерпретирует его в виде
host@admin.example.com, что приводит к ошибке DNS (если ошибочно интерпретированный
адрес не существует).
Домены верхнего уровня в Интернете
Существует несколько доменов верхнего уровня, из которых наибольшей
известностью пользуются домены COM, EDU, GOV, MIL, NET и ORG. Тем не менее
существует множество других доменов, большинство из них находится в других странах.
Каждой стране присвоен домен верхнего уровня, имя которого состоит из двух
букв. Так, Великобритании присвоен домен UK (на самом деле официальный
домен верхнего уровня этой страны называется GB, но это имя используется
редко); Новой Зеландии — домен NZ, Японии — JP и т. д. Пример использования
национального домена верхнего уровня приводился выше — www.bbc.co.uk.
ПРИМЕЧАНИЕ
В адресах, находящихся за пределами США, используются и другие домены. Так, домен СО,
означающий коммерческую направленность, является близким аналогом домена InterNIC COM.
ВНИМАНИЕ
Ничто не мешает регистрировать домены в других странах, даже если сервер находится вдали
от страны, указанной в URL.
Выбор сервера имен
Серверы имен существуют на многих платформах, включая Windows NT/2000/
ХР, Unix, NetWare, Macintosh и т. д. В Windows NT/2000 имеется готовая
реализация сервера DNS. Для Apple существует бесплатный сервер DNS, который
называется MacDNS. В системах семейства Unix присутствует широко
распространенный и надежный сервер BIND. Тем не менее существует ряд мощных
серверов DNS, разработанных независимыми фирмами.
Оценку различных серверов DNS можно найти на таких сайтах, как Dave Central
(www.davecentral.com) и Tucows (www.tucows.com, также существует ряд местных
филиалов). Эти сайты рецензируют практически все программное обеспечение,
проходящее через них, и дают хорошее представление о различных реализациях.
Процесс разрешения имен
Когда клиент (например, браузер) выдает запрос к некоторому URL, этот
запрос передается локальному серверу DNS, который пытается преобразовать имя
в IP-адрес. Если преобразование проходит успешно, данные передаются дальше,
а сервер получает следующий запрос. Если сервер не находит адрес, у него есть
два варианта дальнейших действий в зависимости от настройки.
Рекурсивные запросы
Наиболее типичными являются рекурсивные запросы. Если запрос поступает
на сервер и в кэше сервера обнаруживается запись А (см. ниже), поиск на этом
останавливается. В противном случае сервер должен обратиться с запросом к
другому серверу, то есть передать запрос на более высокий уровень. При этом также
учитывается значение TTL (срока жизни) запроса. Если поиск записи А
занимает слишком много времени, запрос «умирает», а исходный сервер DNS
возвращает ошибку «address not found».
Итеративные запросы
Итеративные запросы должны оставаться локальными по нескольким
причинам, чаще всего из-за недоступности другого сервера DNS. Иногда рекурсия
отключается на сервере DNS, к которому вы обращаетесь, но это маловероятно.
Сервер прилагает все усилия к тому, чтобы найти в своем кэше лучшее возможное
совпадение. Но если данных нет — значит, их нет, и тогда возвращается ошибка.
Кэширование
По мере выполнения своих текущих задач сервер DNS собирает информацию
и сохраняет ее в виде ресурсных записей (RR, Resource Records), содержащих
сведения о запрашиваемых URL. При этом также учитывается значение TTL.
Сервер кэширует столько информации, сколько ему разрешено кэшировать,
и хранит ее, пока информация остается действительной.
Запросы на обратное разрешение
Типичный «прямой» запрос пытается найти IP-адрес по известному URL. При
обратном разрешении решается противоположная задача — поиск URL по
известному IP-адресу. В настоящее время существует несколько утилит,
выполняющих поиск подобного рода. Для системы Windows лучшей программой
такого рода является CyberKit Люка Ниенса (Luc Niejens) — бесплатная сетевая
утилита, которую можно загрузить по адресу www.ping.be/cyberkit.
Безопасность DNS
Клиенты могут производить безопасное обновление данных на динамическом
сервере DNS, чтобы их записи автоматически обновлялись без участия
администратора.
Ресурсные записи (RR)
Все типы ресурсных записей DNS имеют сходный формат. Хотя в файлах DNS
существует множество сокращенных обозначений и аббревиатур, в следующих
примерах для предотвращения путаницы и неоднозначной интерпретации
используется простейшая схема записи.
Первое поле в записи DNS всегда содержит IP-адрес или имя хоста. Если
данные отсутствуют, подразумевается имя или адрес из предыдущей записи.
Обратите внимание: все имена и адреса завершаются символом «точка» (.).
Это обозначение означает, что имя или адрес является абсолютным, а не
относительным. Абсолютные адреса, также называемые полностью определенными
доменными именами, задаются по отношению к корневому домену, тогда как
относительные адреса задаются по отношению к основному домену (который может
быть как корневой, так и иной домен). За этим полем может следовать
необязательное значение TTL, которое указывает, в течение какого промежутка времени
информация в этом поле должна считаться действительной.
Во втором поле указывается тип адреса. В современных базах данных DNS
обычно встречается строка «IN», признак интернет-адреса. Данное поле
присутствует по историческим причинам и для сохранения совместимости со старыми
системами.
Третье поле содержит строку, определяющую тип ресурсной записи. За ним
следуют необязательные параметры, специфические для данного типа записи.
Ресурсные записи типа SOA
Запись SO A (Start of Authority) означает, что сервер имен DNS является
лучшим источником информации для этого домена. Записи SOA также содержат
адрес электронной почты ответственного лица для зоны, признак модификации
зонного файла базы данных, а также используются для установки таймеров,
определяющих периодичность обновления копий зонной информации другими
серверами.
В записи хранится имя системы DNS и имя лица, ответственного за ее
работу. Ниже приведен пример записи SO А:
; Start of Authority (SOA) record
dns.com. IN SOA dnsl.dns.com. owner.dns.com. (
000000001 ; serial # (counter)
10800 ; refresh C hours)
3600 ; retry A hour)
604800 ; expire A week)
86400) ; TTL A day)
Обратите внимание: адрес владельца задается в формате owner.dns.com, что
следует читать как owner@dns.com. Строка завершается открывающей круглой
скобкой, парная закрывающая скобка находится в последней строке после
значения TTL. Запись может быть представлена в следующем формате, который
также вполне допустим:
Dns.com. IN SOA dnsl.dns.com. owner.dns.com.
@00001 10800 3600 604800 86400)
Точка с запятой (;) начинает комментарий. Все символы строки, следующие
после нее, игнорируются. Также следует заметить, что все числовые данные
задаются в секундах. Компоненты записи SOA рассматриваются в следующих
разделах.
Порядковый номер
Порядковый номер (serial number) определяет текущую версию базы данных
DNS. При обновлении базы данных ее порядковый номер должен увеличиваться,
чтобы вторичные серверы знали о том, что им также следует обновить базу
данных.
Порядковый номер управляет зонной пересылкой данных между первичным
и вторичным серверами имен DNS. Сервер вторичного имени периодически
связывается с первичным сервером и запрашивает порядковый номер зонных
данных первичного сервера. Если оказывается, что порядковый номер на
первичном сервере больше порядкового номера на вторичном сервере, значит,
зонные данные устарели и вторичный сервер принимает новую копию зонных
данных с первичного сервера. Пересылка информации с первичного сервера на
вторичный называется зонной пересылкой.
Порядковый номер может быть реализован в виде простого счетчика, но
чаще используется временная пометка, поскольку при внесении изменений в базу
данных на первичном сервере ее значение всегда увеличивается.
Период обновления
Период обновления (refresh) определяет интервал между последовательными
обновлениями информации на вторичных серверах имен A0 800 секунд
соответствуют трем часам).
Значение этого поля определяет, как часто вторичные серверы DNS должны
проверять зонные данные на первичных серверах DNS. По умолчанию период
обновления равен трем часам; если вторичные серверы принимают оповещения
об изменениях, вы можете смело увеличить продолжительность интервала (до
суток и более), чтобы снизить количество опросов. Такая возможность особенно
полезна при использовании медленных линий и при установлении связи по
требованию.
Период повтора
Если вторичному серверу имен не удается связаться с первичным сервером,
он пытается заново установить соединение через заданное количество секунд
C600 секунд соответствуют одному часу).
Значение поля определяет, как часто вторичный сервер будет пытаться
восстановить утраченное соединение. Период повтора обычно короче периода
обновления. По умолчанию период повтора равен 60 минутам.
Период актуальности
Если вторичному серверу имен не удается связаться с первичным сервером в
течение заданного промежутка времени (в секундах), вторичный сервер перестает
отвечать на запросы об этом домене. На какой-то стадии данные настолько
устаревают, что могут оказаться потенциально вредными, и даже полное отсутствие
информации лучше, чем дезинформация. 604 800 секунд в приведенном выше
примере соответствуют одной неделе.
Значение поля определяет период времени, в течение которого данные
вторичного сервера считаются достоверными. Если вторичному серверу DNS долго
не удается связаться с первичным сервером, его данные могут стать
недействительными. По умолчанию период актуальности равен трем дням, причем по
длительности он может превышать как минимальный срок жизни, так и период
повтора.
Срок жизни
Срок жизни данных, или TTL (Time to Live), возвращается при всех запросах
к базе данных и указывает запрашивающей стороне (или другим серверам),
в течение какого времени возможно безопасное кэширование информации
(86 400 секунд в приведенном примере соответствуют одному дню). Это
значение используется по умолчанию для всех записей файла, но оно может быть
переопределено на уровне отдельной ресурсной записи.
Минимальный срок жизни, используемый по умолчанию, оказывает
громадное воздействие на трафик DNS. Он указывает, в течение какого времени
сервер-получатель может квитировать данные. Каждый ответ на запрос возвращается
с определенным значением TTL, которое по умолчанию равно 24 часам. Если
вы собираетесь вносить существенные изменения в зонную информацию DNS,
временно установите более короткий срок жизни данных (например, один час),
но изменения следует вносить лишь по прошествии периода времени,
определяемого предыдущим значением TTL. После того как вы убедитесь в
правильности внесенных изменений, увеличьте TTL до предыдущей величины.
Соблюдение этого правила значительно повышает эффективность распространения
данных в Интернете и сокращает время, в течение которого устаревшие данные
могут оставаться в кэшах других серверов.
Ресурсные записи типа А
Ресурсная запись типа А содержит IP-адрес, ассоциируемый с именем хоста,
которое указывается в первом поле записи.
Записи типа А составляют самую распространенную разновидность
ресурсных записей, встречающихся в файлах данных.
Ресурсные записи типа NS
Запись NS содержит адрес сервера имен, обслуживающего домен. В нашем
примере используются два сервера имен с информацией DNS для домена foo.com.
Запись NS определяет уполномоченный сервер DNS для домена DNS.
Каждый домен должен иметь минимум два таких сервера. Запись NS состоит всего
из двух полей.
Ресурсные записи CNAME
Запись CNAME определяет псевдоним, ассоциируемый с именем хоста, которое
указывается в первом поле записи. Хотя одной системе может быть назначена
одна запись А с несколькими записями CNAME, при использовании записей
CNAME необходима осторожность. Например, некоторые почтовые программы
при попытке разрешения имени хоста MX, использующего запись CNAME
вместо записи А, ведут себя непредсказуемым образом.
Записи CNAME используются для маскировки подробностей реализации сети
от клиентов, которые к ней подключаются. В качестве псевдонимов могут исполь-
зоваться сокращенные формы имен. Скажем, хосту с именем publicl.business.com
можно назначить псевдоним www.business.com.
Ресурсные записи PTR
Записи PTR связывают IP-адрес с именем хоста в домене обратного поиска
(in-addr.arpa). Запись содержит IP-адрес и имя хоста, соответствующее этому
адресу. Имя хоста задается в формате полностью определенного доменного имени.
Многие сайты в качестве меры безопасности запрещают доступ со стороны
компьютеров, у которых существуют расхождения между записями А и PTR, поэтому
следите за тем, чтобы содержимое записей PTR синхронизировалось с записями А.
Запрос обратного поиска, иногда называемый запросом PTR, также может
использоваться для идентификации организации, ответственной за IP-адрес. Как
говорилось выше, результат запроса PTR включает полностью определенное
доменное имя, в котором присутствует имя домена.
Делегированные домены
Механизм делегирования снимает основную ответственность за
администрирование домена и передает ее от основного сервера другому, подчиненному. ICANN
осуществляет административный контроль над .com и делегирует права по
администрированию всех доменов следующего уровня их соответствующим доменам.
На практике большинство сайтов работает на базе хостинга, то есть серверное
пространство арендуется внешним пользователем, и владельцу сайта не приходится
следить за оборудованием — этим занимается техническая служба хостинга.
Для сайтов, работающих на базе хостинга, контроль над доменами часто
поручается администратору сервера DNS. Впрочем, вы также можете воспользоваться
бесплатным сервером DNS, доступным по адресу http://soa.granJtecanyon.com.
Ресурсные записи HINFO
Запись HINFO определяет тип оборудования и операционную систему хоста.
Стандартные сокращенные обозначения операционных систем опубликованы
в RFC 1700 (на момент написания книги), в разделе «System Names List».
Сокращенные обозначения типов оборудования, используемого на хостах,
определяются в этом же документе RFC. Идентификаторы типов процессора определяются
в разделе «Machine Names List». Небольшое подмножество типов, определенных
в RFC 1700, приведено в табл. 6.1.
Имена содержат до 40 символов, среди которых могут быть буквы и цифры,
а также символы - и / (дефис и косая черта). Имя начинается с буквы и
заканчивается буквой или цифрой. Некоторые администраторы предпочитают не
раскрывать эту информацию на общедоступных серверах DNS, поскольку она
упрощает несанкционированный доступ к системе — например, за счет
использования известных дефектов в средствах безопасности конкретного типа системы.
Если вы используете записи HINFO, позаботьтесь о том, чтобы ваша система
соответствовала рекомендациям CERT в области безопасности.
Таблица 6.1. Стандартные обозначения основных операционных систем
и типов процессора в RFC 1700
APOLLO OPENVMS TANDEM
AIX/370 OS/2 UNIX
DOMAIN PCDOS UNIX-BSD
DOS SCO-OPEN-DESKTOP-2.0 UNIX-PC
INTERLISP SCO-OPEN-DESKTOP-3.0 UNKNOWN
ITS SCO-UNIX-3.2V4.0 VM
LISP SCO-UNIX-3.2V4.1 VM/370
MSDOS SCO-UNIX-3.2V4.2 VMS
MULTICS SUN WANG
MVS SUN-OS-3.5 WIN32
NONSTOP SUN-OS-4.0 X11R3
OS86 IBM-RS/6000 SUN-4/200
APPLE-MACINTOSH INTEL-386 SUN-4/390
APPLE-POWERBOOK M68000 SYMBOLICS-3600
CRAY-2 MAC-II UNKNOWN
DECSTATION MAC-POWERBOOK VAX
DEC-VAX MACINTOSH VAX-11/725
DEC-VAXCLUSTER MICROVAX VAXCLUSTER
DEC-VAXSTATION PDP-11 VAXSTATION
IBM-PC/AT SILICON-GRAPHICS
IBM-PQ/XT SUN
Ресурсные записи ISDN
Записи ISDN связывают имя хоста с адресом ISDN. Номер ISDN также может
включать номер DDI (Direct Dial In). Субадрес ISDN не является обязательным.
Записи ISDN имеют несколько возможных применений. В частности, они
предоставляют простой механизм документирования адресов для использования
в статических конфигурациях приложений ISDN. Возможно, в дальнейшем они
будут автоматически использоваться маршрутизаторами Интернета.
Ресурсные записи MB
Запись MB (Mailbox) определяет почтовый ящик, ассоциируемый с хостом.
В полях записи должно быть указано имя почтового ящика и полностью
определенное доменное имя хоста, содержащего этот почтовый ящик. Пока данный
тип записи используется только в экспериментальных разработках.
Ресурсные записи MG
Запись MG определяет почтовый ящик, входящий в групповой список рассылки
для заданного доменного имени. Имя почтового ящика должно быть указано
в формате полностью определенного доменного имени. Пока данный тип записи
используется только в экспериментальных разработках.
Ресурсные записи MINFO
Запись MINFO содержит информацию о почтовом ящике или списке рассылки.
Она состоит из двух полей. Первое поле содержит полностью определенное до^
менное имя почтового ящика, ответственного за список рассылки, указанный
в ресурсной записи. Второе поле содержит полностью определенное доменное
имя почтового ящика, которому должны отправляться сообщения об ошибках,
связанных с ведением списка рассылки. Хотя эти записи могут быть связаны
с одним и тем же простым почтовым ящиком, они обычно используются для
списков рассылки, в которых задействованы разные почтовые адреса для
решения административных задач (например, подписки) и для оповещения об
ошибках типа «mail not deliverable».
Ресурсные записи MR
Запись MR используется для переименования почтового ящика. В поле замены
вводится полностью определенное доменное имя нового почтового ящика. Если
ящик перемещается с одного хоста на другой, можно использовать псевдоним.
Пока данный тип записи используется только в экспериментальных разработках.
Ресурсные записи MX
Запись MX (Mail eXchanger) определяет имя обработчика почты (сервера,
обрабатывающего или пересылающего почту) для данного домена или хоста. Имя
обработчика должно быть задано в формате полностью определенного доменного
имени. Запись MX состоит из следующих полей:
О Имя хоста или домена, обслуживаемого обработчиком почты.
О Полностью определенное доменное имя обработчика почты.
О Приоритет обработчика почты.
Приоритет представляет собой число от 0 до 65 535, которое определяет
очередность обработки почты для заданного хоста или домена. Высокий приоритет
соответствует минимальным числовым значениям, а наивысший приоритет
равен 0. Абсолютное значение приоритета несущественно, важна лишь его
относительная величина по сравнению с другими приоритетами. Доставка почты
начинается с обработчика, обладающего минимальным числовым кодом приоритета.
Если попытка оказывается неудачной, в следующей попытке участвует сервер
со следующим по возрастанию кодом приоритета. Если два или более
серверов-обработчиков почты обладают одинаковым приоритетом, почтовая
программа должна сама решить, какой из них следует опробовать в первую очередь.
Тем не менее переход к следующему уровню приоритета происходит лишь
после того, как будут опробованы все обработчики предыдущего уровня. Обычно
наиболее желательному серверу присваивается приоритет 10, следующему —
приоритет 20, затем 30 и т. д. Подобная схема позволяет при необходимости
легко включить новый обработчик почты в цепочку между действующими
обработчиками.
Поиск по записям MX не рекурсивен. После того как запись MX определит
наилучший приемник почты для хоста, дальнейшие поиски ограничиваются
выборкой записи А для обработчика почты. Записи MX, относящиеся к самому
обработчику почты, игнорируются, если только почта не была адресована
непосредственно ему.
Ресурсные записи RP
Запись RP (Responsible Person) определяет лицо, ответственное за устройство
с заданным именем DNS. Хотя запись SOA указывает, кто является
ответственным за зону, а также предоставляет контактные данные для решения проблем,
связанных с DNS, различными хостами внутри домена обычно управляют
разные люди. Запись RP позволяет указать, с кем следует связаться при
возникновении проблем с устройством, которому соответствует указанное имя DNS.
Типичные проблемы — недоступность важного сервера или подозрительные
действия хоста, замеченные с другого сайта.
Запись RP содержит адрес электронной почты и полностью определенное
доменное имя, по которому следует обращаться за дополнительной
информацией. Адрес электронной почты задается в стандартном формате доменных имен,
но символ @, встречающийся в большинстве адресов, заменяется точкой.
Ссылка на дополнительную информацию представляет собой доменное имя,
указывающее на ресурсную запись ТХТ. Эта запись может содержать контактные
данные (полное имя, номер телефона или пейджера) в произвольном формате.
Ресурсные записи RT
Запись RT (Route Through) определяет промежуточный хост, который
маршрутизирует пакеты для хоста, не имеющего собственного прямого
подключения. Имя промежуточного хоста, принимающего пакеты другого хоста, должно
быть представлено в формате полностью определенного доменного имени. Как
и в случае с обработчиком почты, при определении промежуточных хостов
допускается только один уровень косвенных ссылок; иначе говоря, путь к
промежуточному хосту не может проходить через другой промежуточный хост.
Ресурсные записи ТХТ
Запись ТХТ содержит информацию, представленную в форме простого текста.
Часто в этих записях хранятся сведения о контактных лицах, имена и телефоны
и другая информация такого рода. Длина строки текста должна быть менее
256 символов.
Ресурсные записи WKS
Запись WKS (Well-Known Service) описывают службы, предоставляемые
некоторым протоколом через некоторый интерфейс, по IP-адресу. К числу таких служб
относятся Telnet и FTP. Протокол определяется значением одного из полей
записи. На практике использовать эти записи не рекомендуется (RFC 1123).
Ресурсные записи типа Х25
Записи типа Х25 похожи на ресурсные записи А, но они связывают имя хоста
не с IP-адресом, а с адресом Х.121. Адреса Х.121 являются стандартной формой
адресации в сетях Х.25. Адрес PSDN (Public Switched Data Network) начинается
с кода DNIC (Data Network Identification Code), состоящего из четырех цифр.
Код определяется в рекомендациях по реализации X .121, разработанных
Международным консультативным комитетом по телеграфии и телефонии (CCITT).
Адрес не должен содержать национальных префиксов. Ресурсная запись Х25
проектировалась для использования в сочетании с ресурсной записью RT.
Итоги
В этой главе читатель познакомился с иерархической структурой системы
доменных имен (DNS) Интернета. Эта система была разработана для того, чтобы
основной формой адресации интернет-ресурсов были символические имена.
Также было показано, что DNS использует несколько способов определения
IP-адреса по доменному имени. Следует помнить, что эта система, как и любая
другая, может давать сбои. Если материал этой главы остался для вас
непонятным или вы запутались в его структуре, предоставьте эти хлопоты вашему
поставщику услуг Интернета. Кстати говоря, DNS используется при любом
обращении к web-сайтам или загрузке ресурсов по другим протоколам.
-"* WINS
Курт Хадсон (Kurt Hudson)
Служба имен Интернета для Windows WINS (Windows Internet Name Service)
также называется службой имен NetBIOS, поскольку она преобразует имена
NetBIOS в IP-адреса. Система NetBIOS (Network Basic Input/Output System)
является совместной разработкой IBM и Microsoft. Позднее фирма Microsoft
приобрела права на NetBIOS, чтобы использовать систему в своем продукте
LANManager (в настоящее время устаревшем). Сейчас NetBIOS существует в
сетевых операционных системах Microsoft, предшествующих Windows 2000 (то есть
NT 5.0). В сетях на базе Windows 3.x, Windows 95, Windows 98 и Windows NT 4.0
используются сетевые средства NetBIOS. Каждый администратор,
поддерживающий работу сети с этими операционными системами, должен быть знаком с
механизмом разрешения имен NetBIOS и особенно хорошо разбираться в WINS.
В этой главе рассматривается процесс настройки NetBIOS и ограничения,
присущие этому механизму. В частности, в ней описаны такие средства
разрешения имен NetBIOS, как файл LMHOSTS и WINS. Особое внимание уделяется
разрешению имен в WINS, клиентской и серверной конфигурации, а также
администрированию WINS.
ПРИМЕЧАНИЕ
Фирма Microsoft исключила NetBIOS семейства Windows 2000. По официальным данным,
будущие операционные системы будут поддерживать имена NetBIOS для сохранения совместимости,
но не будут зависеть от них. По этой причине WINS рассматривается в контексте Windows 9x и
Windows NT. Хотя сервер Windows 2000 может быть настроен на выполнение функций сервера
WINS, обычно это делается лишь для обеспечения совместимости.
NetBIOS
С точки зрения Microsoft, NetBIOS представляет собой интерфейс прикладного
программирования (API). В сущности, любой интерфейс такого рода может
рассматриваться как прослойка между компонентами. Уровень NetBIOS
располагается между прикладным и транспортным уровнями стека протоколов TCP/IP
от Microsoft (рис. 7.1).
Прикладной уровень
—■— NetBIOS —
Транспортный уровень
Межсетевой уровень
Сетевой интерфейс
Рис. 7.1. NetBIOS в стеке протоколов TCP/IP от Microsoft
Главная функция NetBIOS — обеспечение независимости между
прикладным и транспортным уровнями. Это делается для того, чтобы разработчик при-*
ложения мог написать программу с сетевой поддержкой, не разбираясь во всех
тонкостях базового протокола. Кроме того, наличие дополнительной прослойки
NetBIOS позволяет использовать приложение с разными транспортными
протоколами. Разработчик должен лишь написать приложение, работающее на уровне
NetBIOS и не рассчитанное на конкретный протокол.
ПРИМЕЧАНИЕ
В продуктах Microsoft также поддерживается интерфейс Windows Sockets (также называемый
WinSocks). Как и NetBIOS, этот интерфейс расположен между прикладным и транспортным
уровнями. NetBIOS и WinSocks не связаны друг с другом, это два разных пути реализации
коммуникаций. Microsoft мог использовать существующие средства Интернета, работающие с интерфейсом
сокетов (и написанные в основном для системы Unix).
При установке сетевых операционных систем Microsoft программа установки
требует ввести имя компьютера. Имя, вводимое на этой стадии, является
именем NetBIOS. Имена NetBIOS должны быть уникальны в пределах сети, то есть
имя не может использоваться ни одним из существующих компьютеров сети.
Имена NetBIOS имеют длину до 15 символов и не могут содержать следующие
символы:
О обратная косая черта (\);
О пробел ( );
О дефис (-);
О апостроф О;
О знак «at» (@);
О процент (%);
О восклицательный знак (!);
О амперсанд (&);
О точка (.).
Во всех сетевых операционных системах от Microsoft, использующих TCP/IP
(до Windows 2000), поддерживаются как имена NetBIOS, так и имена хостов.
Имя хоста настраивается в свойствах протокола TCP/IP. По умолчанию имя
хоста совпадает с именем компьютера в NetBIOS. Рекомендуется оставить эти
имена одинаковыми, иначе вы усложните процесс диагностики. Например, такие
утилиты, как ping, работают с именами хостов, а при отображении диска на
сервер Microsoft используется имя NetBIOS. В случае если имена различаются,
вам придется рассматривать каждое имя и каждое соединение по отдельности.
Но если компьютер будет использоваться в Интернете, для имен хостов TCP/
IP устанавливаются дополнительные ограничения, которые должны учитываться
при выборе имен компьютеров NetBIOS. Такие имена состоят только из
символов A-Z, a-z, 0-9 и дефисов (-), причем первый и последний символы имени
хоста TCP/IP должны быть алфавитно-цифровыми (то есть A-Z, a-z или 0-9).
В операционных системах Microsoft имя компьютера определяется именем
NetBIOS, как показано на рис. 7.2. На рисунке приведено имя NetBIOS в системе
Windows 98, но в системе Windows 95 дело обстоит аналогично.
ЦДЗДДД- - -щ^^^ш^^ШмШШ^^^^^щ^ i xij
k Idartificatior* |$«vicej| Protocols) Ad*tf*t] Ъг*$гф\ ч Л ] \
\k £311 Window* u$e*ttefo8ov^ II
vs ^S£i^ tfu$Ort^#otOier>afr*ofthe domain ihtf&mwjje* [j
U * D*put«N«n*y * JNTSERVEft • "^\ "*C:%vV * -> о '' * I
-. "^ f .»■» HiWHIHiH <W>llll*llW>Hl>im>*IU»^lll*ll>4l>M<l <A\
L 1УОпшч I j
L* II
OK I C»**i [1
Рис. 7.2. Имя компьютера является именем NetBIOS
Чтобы вызвать это диалоговое окно в Windows 95/98, щелкните правой
кнопкой мыши на значке Сетевое окружение (Network Neighborhood) и выберите в
контекстном меню команду Свойства (Properties). Затем откройте вкладку Идентификация
(Identification) в диалоговом окне Сеть (Network). В Windows NT 4 используется
аналогичная процедура, но вкладка называется Общие (General) и открывается
по умолчанию.
Имя хоста TCP/IP является частью конфигурации TCP/IP в
операционных системах Microsoft, как наглядно показывает диалоговое окно Microsoft
Windows NT, изображенное на рис. 7.3.
IP Address ONS | WINS Acttesi | DHCP Rel^ | Roufire | .. .
Domain Name System |ONS) II
£lost Name: . . Ogrodk -' II
jJSSZS | domain, com I 1
. "DNS Service Search Older * • ....:.,.^..v:.... J j
: j • /yl ; ti.' J,|
Add-: 1 ft**- 1 Remote I ; \ I-
- DomamSuffat Search Order •■-\ \\
\ " " _-—ii И
i>jjl!'''.^'.'l.'^J ;!.[
; . | OK | Cancel | Apply И
Рис. 7.3. Настройка имени хоста TCP/IP в Windows NT Server
NetBIOS является неотъемлемой частью сетевой конфигурации Microsoft,
поэтому реализация протокола TCP/IP в операционных системах Microsoft
обозначается специальными акронимами NBT и NetBT. Оба акронима обозначают
одно и то же — NetBIOS через TCP/IP. Удаление NetBIOS из системы
приведет к нарушению работы сетевых компонентов операционных систем Microsoft.
Разрешение имен в NetBIOS
Имена NetBIOS, как и имена хостов, должны быть преобразованы в IP-адреса
при использовании в сетях TCP/IP. Существует несколько способов
преобразования имен NetBIOS в IP-адреса. В операционных системах Microsoft
используются следующие способы разрешения имен NetBIOS (то есть их
преобразования в IP-адреса):
О Кэш имен — клиенты Microsoft поддерживают кэш имен NetBIOS с именами
компьютеров и IP-адресами, которые ранее были разрешены данным
клиентом. Чтобы просмотреть содержимое кэша имен, введите команду NBTSTAT -с
в режиме командной строки сетевой операционной системы Microsoft,
использующей TCP/IP.
О Сервер WINS — сервер WIN поддерживает базу данных с информацией о
связях имен компьютеров с IP-адресами. Чтобы преобразовать имя компьютера
в IP-адрес, клиент обращается к серверу WINS с запросом. Также
используется термин «сервер имен NetBIOS», или NBNS (NetBIOS Name Server).
О Широковещательная рассылка — клиент сети Microsoft может разослать
запрос в локальном сегменте сети, чтобы узнать, принадлежит ли разрешаемое
имя этому сегменту.
О Файл LMHOSTS — статический файл, публикуемый централизованно или на
уровне отдельной системы. Файл содержит список IP-адресов с
соответствующими им именами компьютеров.
О Файл HOSTS — другой статический файл, который также может
публиковаться централизованно или на уровне отдельной системы. Формат этого
текстового ASCII-файла соответствует формату файла UNIX\etc\hosts в BSD
(Berkeley Software Distribution) 4.2. Файл содержит список имен хостов
Интернета в формате полностью определенных доменных имен (FQDN, Fully
Qualified Domain Name) и соответствующих им IP-адресов.
О Сервер DNS — для разрешения имен WINS клиенты WINS могут
использовать сервер DNS. Этот вариант, настройка которого производится на уровне
клиентской системы, позволяет выполнять разрешение имен NetBIOS через
сервер DNS вместо сервера WINS.
Очередность, в которой клиентская система пытается разрешить имя NetBIOS,
зависит от типа узла NetBIOS. Существуют четыре типа узлов NetBIOS:
О В~узел — узлы этого типа называются широковещательными (Broadcast),
поскольку компьютер осуществляет разрешение имен NetBIOS только
посредством рассылки запросов в локальном сегменте. Вообще говоря, в системах
Microsoft используются расширенные В-узлы, которые ищут информацию
в файле LMHOSTS, если имя не было найдено в локальном сегменте.
О Р-узел — разрешение имен выполняется точечным (Point-to-point)
обращением к серверу WINS, широковещательная рассылка в локальном сегменте
не используется.
О М-узел — смешанные (Mixed) системы сначала рассылают запрос в
локальном сегменте, а затем обращаются за разрешением имени к серверу WINS.
О Н-узел — гибридные (Hybrid) системы сначала обращаются за разрешением
имени к серверу WINS. Если получить ответ не удается, Н-узел рассылает
запрос в локальном сегменте.
Прежде чем выполнять любые попытки разрешения имен в NetBIOS, все
клиенты Microsoft сначала проверяют содержимое кэша имен. По умолчанию в
операционных системах Microsoft используются узлы типов В и Н. Расширенные
В-узлы используются по умолчанию для всех компьютеров, на которых не задан
адрес сервера WINS. При наличии адреса сервера WINS по умолчанию
используется Н-узел. Процесс настройки клиента рассматривается ниже в этой главе.
ПРИМЕЧАНИЕ
Чтобы изменить тип узла NetBIOS на Р или М, необходимо отредактировать реестр Windows. За
дополнительной информацией о настройке TCP/IP в Windows NT (в том числе и о модификации
типа узла NetBIOS) обращайтесь на сайт Microsoft http://www.microsoft.com или найдите
компакт-диск TechNet от Microsoft. Статья, посвященная настройке TCP/IP в Windows 95/98,
называется «MS TCP/IP and Windows 95 Networking». Чтобы найти информацию о настройке TCP/IP
в Windows NT, проведите поиск по строке «Q120642». В этих статьях также описано множество
других параметров Microsoft TCP/IP.
Существует несколько типов имен NetBIOS, которые могут использоваться
во всех операционных системах Microsoft. Уникальность этих имен
обеспечивается присоединением к имени компьютера шестнадцатеричного идентификатора.
Каждое уникальное имя описывает уровень сервиса, поддерживаемого
компьютером. Например, во всех операционных системах Microsoft поддерживается имя
рабочей станции; этот уровень сервиса позволяет компьютерам
взаимодействовать по сети. Если операционная система также предоставляет другие виды
сетевого сервиса (например, совместный доступ к файлам или принтерам), ей также
будет присвоено серверное имя. В табл. 7.1 перечислены стандартные имена
NetBIOS, используемые в операционных системах Microsoft.
Таблица 7.1. Имена NetBIOS с шесгнадцатеричными идентификаторами
Имя NetBIOS Описание
и шестнадцатеричный
идентификатор
Имя компьютера[00п] Функциональность рабочей станции на клиенте WINS
Имя компьютера[03п] Функциональность передачи сообщений
на клиенте WINS
Имя компьютера[20п] Функциональность сервера на клиенте WINS
Имя пользователя[03п] Зарегистрированное имя текущего пользователя
Имя домена[1Вп] Функциональность главного контроллера домена (PDC,
Primary Domain Controller)
Как видно из табл. 7.1, каждая операционная система Microsoft в сети обычно
регистрирует несколько имен компьютеров. Существует два способа
регистрации имен: если система является клиентом WINS, она регистрирует все свои
имена NetBIOS на сервере WINS. Системы, являющиеся клиентами WINS,
рассылают имена в локальном сегменте сети. Если другая система не отвечает на
разосланные запросы, информируя о том, что запрашиваемые имена уже заняты,
имена считаются зарегистрированными. Если имена NetBIOS уже используются
другим компьютером локального сегмента, система, пытающаяся их
зарегистрировать, автоматически отключается от сети. Далее системный администратор
должен выбрать для одной из конфликтующих систем другое имя.
Динамическое разрешение имен в NetBIOS
Единственный динамический способ преобразования имен NetBIOS в IP-адреса
в сетях Microsoft TCP/IP основан на использовании WINS. Сервер WINS
получает запросы на регистрацию имен, отправляемые клиентами WINS при запуске.
При отключении клиенты отправляют серверу WINS запросы на освобождение
имен. Таким образом, содержимое базы данных WINS синхронизируется с
текущими именами активных компьютеров в сети.
Функциональность WINS реализуется службой, работающей на серверах
Windows NT. Для хранения регистрационных данных и разрешения имен служба
использует базу данных Microsoft Access.
Преимущества WINS
Применение серверов WINS для разрешения имен NetBIOS в сетях Microsoft
обладает рядом преимуществ, часть из которых перечислена ниже.
О WINS сокращает объем широковещательного трафика при разрешении имен.
Вместо того чтобы рассылать запросы в локальном сегменте, клиент WINS
напрямую связывается с сервером WINS.
О Клиенты WINS могут связываться с серверами WINS в удаленных сегментах.
Маршрутизаторы обычно фильтруют широковещательный трафик, поэтому
рассылка запросов на разрешение имен ограничивается локальной подсетью.
Клиенты WINS связываются с серверами WINS посредством направленного
запроса по IP-адресу сервера. Хотя маршрутизатору можно разрешить
пересылку широковещательных запросов на разрешение имен посредством
активизации портов UDP 137 и 138, делать это обычно не рекомендуется из-за
повышения объема трафика.
О WINS работает в динамическом режиме. Клиенты WINS автоматически
регистрируются на сервере WINS при запуске, администратору не приходится
вводить пары «IP-адрес — имя NetBIOS».
О WINS упрощает ведение списков просмотра (browse lists). Системы Microsoft
поддерживают большие списки ресурсов, доступных через сеть (например,
совместных файлов или принтеров), эти списки называются «списками
просмотра». Сервер WINS облегчает задачу документирования доступных
ресурсов за счет получения информации об именах NetBIOS на каждом компьютере.
Если бы сеть полагалась только на широковещательный трафик, в
многосегментных сетях списки были бы неполными.
Как работает WINS
Сервер WINS собирает данные и поддерживает централизованную базу данных
с активными именами NetBIOS. Сервер WINS обрабатывает заявки на
регистрацию/освобождение и разрешение имен, поступающие от клиентов WINS. Как
упоминалось выше, сервер WINS рассчитывает на то, что клиенты WINS
зарегистрируют свои имена на сервере WINS при запуске. Также предполагается,
что клиенты освобождают свои имена при отключении. Поскольку все клиенты
WINS регистрируют и освобождают свои имена через сервер WINS, последний
может обеспечить достоверное преобразование IP-адресов в имена NetBIOS по
запросу клиента.
Регистрация имен
При запуске клиент WINS должен зарегистрировать свое имя NetBIOS на
сервере WINS. Запросы на регистрацию имен отправляются непосредственно
серверу WINS, который либо регистрирует имя, либо отказывает в регистрации.
Если имя не используется другой системой, сервер WINS регистрирует имя
и посылает пакет подтверждения клиентской системе. Пакет подтверждения
содержит зарегистрированное имя и его срок жизни (TTL) — интервал времени,
зарезервированный для клиента, в течение которого имя должно быть
перерегистрировано. Если клиент WINS не перерегистрирует имя до истечения срока жизни,
имя удаляется из базы данных WINS и может быть зарегистрировано другой
системой. Ограничение срока жизни гарантирует, что системы,
зарегистрировавшие имена и затем отключенные вследствие аварийного завершения или сбоя
питания, не будут занима