Текст
                    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 и может быть зарегистрировано другой системой. Ограничение срока жизни гарантирует, что системы, зарегистрировавшие имена и затем отключенные вследствие аварийного завершения или сбоя питания, не будут занимать имена NetBIOS во время отключения от сети. Если клиент WINS пытается зарегистрировать имя NetBIOS, уже встречающееся в базе данных WINS, сервер возвращает клиенту пакет с приказом на ожидание. Далее сервер убеждается в том, что имя действительно используется в сети, для чего зарегистрированному владельцу имени отправляется пакет с запросом на подтверждение. Если сервер WINS получает ответ от системы, зарегистрировавшей имя, то запрос второго компьютера на регистрацию имени отвергается. Если ранее зарегистрированный владелец имени не отвечает, сервер WINS повторяет запрос еще два раза. Если предыдущий владелец не ответил ни на один запрос, сервер WINS освобождает имя и предоставляет его той системе, которая его запросила. ПРИМЕЧАНИЕ Если клиент WINS в процессе запуска не получает ответа от основного сервера WINS после трех попыток, он связывается с одним из альтернативных серверов WINS. Если оба сервера WINS, основной и альтернативный, не отвечают, клиент WINS регистрирует свое имя NetBIOS посредством широковещательной рассылки. Обновление имен По полученному значению TTL клиент WINS определяет, в течение какого срока имя NetBIOS должно быть обновлено на сервере WINS. По умолчанию срок жизни имен WINS равен шести дням, или 518 400 секундам. Клиенты WINS пытаются обновить свои имена после истечения одной восьмой срока. Если клиенту не удается связаться с основным сервером WINS в течение этого времени, он пытается обновить имя через альтернативный сервер. После того как имя будет обновлено, клиент ожидает истечения половины TTL и снова пытается обновить имя. Если все попытки обновления окажутся безуспешными, имя NetBIOS освобождается. Запросы и ответы Как объяснялось выше, клиентам WINS по умолчанию назначается гибридный тип узла, то есть когда клиенту потребуется разрешить некоторое имя, он обращается к серверу WINS. Например, если клиент WINS пытается связаться с компьютером HOSTX, он сначала ищет это имя в своем кэше имен. Если соответствие не найдено в локальном кэше, клиент обращается к серверу WINS за определением IP-адреса HOSTX. Если после трех повторных попыток ему не удастся найти основной сервер WINS, клиент пытается обратиться к альтернативному серверу. Если все серверы WINS недоступны или у ответивших серве-
ров отсутствует информация об указанном имени NetBIOS, клиент WINS рассылает в локальной подсети широковещательный запрос на разрешение имени. Освобождение имен Перед отключением клиент WINS обязательно должен выдать запрос на освобождение имени. Для каждого имени, зарегистрированного клиентом, серверу WINS передается непосредственный запрос. Пакет содержит освобождаемое имя NetBIOS и соответствующий ему IP-адрес. Сервер реагирует на полученный запрос и возвращает пакет, содержащий отрицательное или положительное подтверждение. Если сервер WINS обнаруживает конфликт в базе данных (например, если попытка освобождения имени выполняется не тем компьютером, которым это имя было зарегистрировано), ответ будет отрицательным. На отключение клиента WINS это никак не влияет, поскольку клиент игнорирует содержимое ответного пакета и отключается как при положительном, так и отрицательном ответе. Настройка клиентов WINS Настройка Windows NT или Windows 95 для использования WINS сводится к простому вводу IP-адреса сервера WINS. Настройка в обоих семействах операционных систем выполняется в диалоговом окне свойств протокола TCP/IP, на вкладке Конфигурация WINS (WINS Configuration) в Windows 95/98 или на вкладке WINS в Windows NT. На рис. 7.4 изображена конфигурация WINS в системе Windows 98. Чтобы активизировать разрешение имен через WINS на клиентском компьютере, достаточно ввести IP-адрес одного сервера WINS. Если клиент WINS будет работать с несколькими серверами WINS, в диалоговом окне конфигурации вводятся дополнительные IP-адреса. В системах семейства Windows NT адреса основного и альтернативных серверов WINS вводятся только через этот интерфейс. По умолчанию обращение к альтернативному серверу WINS происходит только в том случае, если клиент не находит основной сервер WINS в сети. Следующие операционные системы могут настраиваться как клиенты WINS: О Windows NT Server 4.0, 3.5х; О Windows NT Workstation 4.0, 3.5x; О Windows 95/98; О Windows for Workgroups 3.11 с Microsoft TCP/IP-32; О Microsoft Network Client 3.0 для MS-DOS; О LAN Manager 2.2c для MS-DOS. Как упоминалось выше, при настройке клиента на адрес WINS В-узлы автоматически преобразуются в Н-узлы. В этом можно убедиться, вводя команду ipconfig /all в режиме командной строки Windows NT. Чтобы проверить конфигурацию IP для систем Windows 95/98, введите в командной строке команду winipcfg. Для получения информации о типе узла щелкните в открывшемся окне на кнопке Сведения (More Info).
ррл-iffito&r-;:'t\;.. - ?;Actahced '■ :- J ' ' NetBIOS -. } :y DNS Con^^ J &rf*w*y ^NS Confi»»^ion } JP Address | : :^ j I ,;V configure^ jj • • Г S^&eWI^Resolution К r-^SSefvefc$^ch0^er: {'•.' [192.168. 1 .200 | &dd | j • ;.i::'Sfiopfjp:.'j j j ■■'. j OK I Caned j Рис. 7.4. Настройка WINS в Windows 98 Настройка WINS для прокси-агентов Системы Windows 95, Windows 98 и Windows NT также могут настраиваться на выполнение прокси-функций WINS. Клиент WINS, настроенный на выполнение прокси-функций, называется прокси-агентом WINS. Прокси-агент WINS связывается с сервером WINS для разрешения имен по поручению систем, находящихся в локальном сегменте и не являющихся клиентами WINS. Таким образом, системы, не являющиеся клиентами WINS, также могут пользоваться преимуществами разрешения имен NetBIOS, предоставляемыми WINS. Процесс настройки почти не отличается от обычного процесса разрешения имен WINS. Когда компьютер, не являющийся клиентом WINS, рассылает широковещательный запрос на разрешение имени в локальной подсети, прокси-агент WINS получает запрос и пересылает его серверу WINS. Если сервер WINS может преобразовать имя NetBIOS в IP-адрес, прокси-агент WINS пересылает ответ компьютеру, не являющемуся клиентом WINS. При настройке систем для выполнения функций прокси-агентов WINS следует помнить, что прокси-агенты могут увеличивать сетевой трафик из-за повторения запросов на разрешение имен. Microsoft не рекомендует использовать более двух прокси-агентов WINS в каждой подсети, содержащей компьютеры, которые не являются клиентами WINS. Если все компьютеры сети будут настроены как прокси-агенты, широковещательный запрос на разрешение имени будет продублирован на каждом компьютере в сети.
Настройка прокси-агента в NT 4 Настройка системы на базе Windows NT 4 для выполнения функций прокси- агента WINS производится следующим образом: 1. Запустите редактор реестра Windows NT 4 командой regeditexe или regedt32.exe. 2. Найдите подраздел Parameters в разделе HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\ Services\NetBT. 3. Дважды щелкните на параметре EnableProxy и задайте ему значение 1. 4. Закройте редактор реестра. 5. Перезапустите компьютер. Настройка прокси-агента в Windows 95/98 Настройка системы на базе Windows 95/98 для выполнения функций прокси- агента WINS производится следующим образом: 1. Запустите редактор реестра Windows 95/98 командой regedit.exe. 2. В разделе HKEY_LOCAL„MACHINE\SYSTEM\CurrentControlSet\Services\VxD найдите подраздел MSTCP. 3. Щелкните на подразделе MSTCP, чтобы выделить его. 4. Выполните команду меню Правка ► Создать ► Строковый параметр (Edit ► New ► String Value). 5. Введите имя нового параметра EnableProxy. 6. Дважды щелкните на строке EnableProxy; на экране появляется диалоговое окно Изменение строкового параметра (Edit String). 7. Введите 1 в поле Значение (Value) и щелкните на кнопке ОК. 8. Закройте редактор реестра и перезапустите систему. Настройка сервера WINS После того как служба сервера WINS будет установлена на сервере Windows NT, последний начинает выполнять функции сервера WINS. Программное обеспечение сервера WINS входит в комплект поставки Windows NT Server, но не устанавливается в стандартном варианте установки. Установка службы сервера WINS в системе на базе Windows NT 4 выполняется следующим образом: 1. Щелкните правой кнопкой мыши на значке Сетевое окружение (Network Neighborhood) и выберите в открывшемся контекстном меню команду Свойства (Properties). 2. Щелкните на вкладке Services. 3. Щелкните на кнопке Add.
4. Выберите в списке служб строку Windows Internet Name Service и нажмите кнопку ОК. 5. Вам будет предложено задать путь к исходным файлам Windows NT. Убедитесь в правильности введенного пути и щелкните на кнопке ОК. 6. После завершения установки службы щелкните на кнопке ОК и перезапустите компьютер, как будет предложено. После перезапуска системы: 1. Откройте панель управления, чтобы подтвердить установку. Для этого выполните команду Пуск ► Настройка ► Панель управления (Start ► Settings ► Control Panel). 2. Дважды щелкните на значке Службы (Services) на панели управления, чтобы просмотреть список установленных служб. Если служба WINS была успешно установлена, она будет находиться где-то в конце списка установленных служб. Из этого мини-приложения вы можете запускать и завершать WINS и многие другие службы, временно останавливать их работу, а также настраивать параметры запуска. Администрирование и сопровождение WINS После установки службы WINS в группе Administrative Tools меню Пуск (Start) Windows NT должно появиться приложение WINS Manager. Выполните команду Start ► Programs ► Administrative Tools и выберите строку WINS Manager. Диспетчер WINS предназначен для выполнения административных операций на сервере WINS. Например, вы можете включить в базу данных WINS статические отображения для компьютеров, не являющихся клиентами WINS. Кроме того, приложение позволяет заархивировать базу данных WINS, настроить партнеров по репликации WINS и просмотреть текущее содержимое базы. Добавление статических записей Если в сети работают компьютеры, не являющиеся клиентами WINS, и вы хотите, чтобы сервер WINS мог преобразовывать имена таких компьютеров в IP-адреса, следует произвести настройку статических отображений. Статические отображения вручную добавляются в базу данных WINS для того, чтобы сервер мог разрешать имена NetBIOS компьютеров, не являющихся клиентами WINS. Чтобы включить в базу данных статическое отображение, выполните следующее действие: 1. Запустите WINS Manager. 2. Откройте меню Mappings и выберите команду Static Mappings. 3. Щелкните на кнопке Add Mappings. 4. В диалоговом окне Add Static Mappings введите имя и IP-адрес компьютера, данные которого должны храниться в базе данных в статическом виде.
5. Выберите тип имени для компьютера. Предлагаются следующие варианты: □ Unique — используется для разрешения имени отдельного компьютера. □ Group — используется в качестве «обычного группового» имени. IP-адреса отдельных членов группы не хранятся в базе, поскольку обмен информацией в группах осуществляется посредством широковещательной рассылки пакетов. □ Domain Name — используется для ввода доменных имен. Этот вариант предназначен для ввода информации о доменных контроллерах Windows NT. □ Internet Group — позволяет группировать ресурсы (например, принтеры) для целей просмотра. □ Multihomed — используется для поддержки многоадресных компьютеров, имеющих несколько IP-адресов. Как правило, на таких компьютерах устанавливается несколько сетевых адаптеров, но используется только одно имя. Данный тип записи делает возможной такую конфигурацию, позволяя отобразить несколько IP-адресов на одно имя компьютера NetBIOS. □ Щелкните на кнопке Add. □ Повторите описанную процедуру для всех остальных записей. После завершения ввода статических данных щелкните на кнопке Close. Поскольку категории Domain Name, Internet Group и Multihomed состоят из нескольких записей, при их выборе появляется дополнительное диалоговое окно. В каждую категорию может входить до 25 записей. Клиентские компьютеры WINS не могут зарегистрировать имена, статически зарегистрированные на сервере WINS. Сопровождение базы данных WINS С базой данных WINS можно выполнять некоторые служебные операции, в том числе — архивацию, восстановление, сжатие и согласование записей. Для просмотра записей базы данных WINS используется программа WINS Manager. Чтобы просмотреть содержимое базы, откройте меню Mappings и выберите команду Show Database. Предусмотрены режимы просмотра как всех записей, так и записей, принадлежащих указанному владельцу (серверу WINS). Если несколько серверов WINS используются в качестве партнеров по репликации, каждый партнер может просматривать записи, хранящиеся в базах данных остальных партнеров. Настройка репликации WINS рассматривается ниже в этой главе. Отображаемые записи сортируются по IP-адресу, имени компьютера, сроку жизни, идентификатору версии и типу (рис. 7.5). Окно Mappings также позволяет узнать, является ли запись активной или статической. Для статических записей в столбце S присутствует пометка; для активных записей пометка имеется в столбце А. Записи, не помеченные как активные или статические, не проверяются и ожидают удаления.
С;- [r'^i^^ionJO •"•' .^i-'yvv'^ii^yv:;'::1.'!. : A•:€• •'?«? ty. TV№; ::;. •.••:. 7 J£:j-!-.- .•..'..' •- —: l .'МйЛо* • V:; -:- A! .$ V- Expeatoi Date . . • Vernon ID • • •• РзЯЯшШШшШмня I |MD0MAIN[1Bh] 19Z16&V1Q0 * Б/1/9910:04:37 AM Б '."j:: IMADMINISTRAT0R[03h] 192.168.1.100 * 6/1/9910:04:37 AM 1 l©COMPUTER1[00h] 192.168.1.10 * * 1Л 8/38 7:14:07 PM A IMcOMF4JTER1[03h] 192.168.1.10 « *> 1Л8/387:14:07PM В : |gCOMPUTER1[20hJ 192.168.1.10 * * 1/18/38 7:14:07PM С • »DOMAIN[00h] 192.168.1.100 * 6Л/9910:04:37 AM 8 -J |y^D0MAIN{1Ch) 192.168.1.100 « 6/1/9910:04:37 AM 7 |AD0MAIN[1Eh] 192.168.1.100 * 6/1/991004:37 AM 5 , ШЙмтсср^лгогппи .ncn ico lion * сл/адтгмгглм ^ JU.j Рис. 7.5. База данных WINS Чистка базы данных Если вы считаете, что содержимое базы данных не соответствует действительности, можно потребовать, чтобы сервер WINS произвел согласование записей. Например, если вы заметили, что в базе данных присутствуют имена компьютеров, отключенных от сети, запустите процесс чистки базы данных. После его завершения из базы данных должны пропасть освобожденные имена и записи, добавленные другими серверами WINS. Чистка базы данных запускается командой меню Mappings в приложении WINS Manager. Удаление записей из базы данных На практике возникают ситуации, когда в базе данных WINS хранятся записи, которые следовало бы удалить. Предполагается, что база данных будет удалять записи с истекшим сроком действия, но иногда такие записи остаются в базе. Если даже после чистки база данных содержит нежелательные записи, существует два основных способа ручного удаления записей. Во-первых, можно удалить все записи кнопкой Delete Owner в диалоговом окне Show Database. Выполните следующие действия: 1. Запустите приложение WINS Manager, перейдите на вкладку Mappings и щелкните на кнопке Show Database. На экране появляется диалоговое окно Show Database. 2. В диалоговом окне Show Database найдите список владельцев и щелкните на имени или IP-адресе компьютера WINS, записи которого требуется удалить из базы.
3. Щелкните на кнопке Delete Owner. 4. Подтвердите удаление, щелкнув на кнопке Yes в диалоговом окне с предупреждением. Следующее окно сообщает, что согласование записей с этой базой данных WINS невозможно до тех пор, пока записи не будут построены заново. После того как из базы данных будут удалены все записи, каждый клиент WINS должен заново зарегистрировать свое имя в базе данных WINS. При перегрузке компьютеров в сети это происходит автоматически. Во втором варианте удаление записей из базы данных WINS производится избирательно. При этом используется утилита winscl.exe из пакета Windows NT 4.0 Resource Kit. Выбор интервала для автоматического выполнения операций Сервер WINS автоматически выполняет многие операции по сопровождению базы данных с заданной частотой. Интервал выполнения этих автоматизированных операций задается в диалоговом окне WINS Server Configuration. Чтобы вызвать это окно, выполните команду Server ► Configuration в WINS Manager и выберите Configuration (рис. 7.6). Y^$$«uw$$^ j—jjz—j л.ф^?^^^^:. ^|ffi^;p|^g \ ]}———> 'Доорммод^, - ■. 1*рЭД»ЭСТ - | гУТ* ,1 I] Ч Л - \s ^v^""* i^^T,' V?, " j I I I rPuflPafametett-"-~:—k : -PutHP&wMtoi— ; J P InitialRepicafcry : ч Г Ij^^feeOort . | j RetiyCoMtf: [5 § . - Г Reflate on Addrw* Chang» | Рис. 7.6. Диалоговое окно WINS Server Configuration В окне WINS Server Configuration задаются следующие интервалы: О Renewal Interval — срок жизни зарегистрированного имени. Клиент WINS должен обновить имя до истечения заданного срока. По умолчанию значение равно 144 часам F суток). О Extinction Interval — промежуток (по умолчанию — 144 часа) между освобождением имени и моментом, когда оно становится недействительным. По истечении этого периода имя компьютера считается устаревшим. О Extinction Timeout — промежуток времени между устареванием имени и его фактическим удалением из базы данных. По умолчанию равен 144 часам. О Verify Interval — записи, поступающие с других серверов WINS, по умолчанию проверяются каждые 576 часов B4 дня). Подобной проверке подлежат только записи других серверов WINS.
Дополнительная настройка сервера WINS Кнопка Advanced в диалоговом окне WINS Server Configuration открывает диалоговое окно дополнительной настройки сервера WINS. Это окно управляет ведением журналов работы сервера, архивацией и другими служебными операциями. Ниже перечислены основные управляющие возможности этого окна. О Logging Enabled — журнал изменений в базе данных по умолчанию хранится в папке %system_root%/system32/wins. WINS использует этот файл для восстановления данных после сбоев. О Log Detailed Events — WINS сохраняет подробную информацию обо всех выполняемых операциях. Если у вас возникают трудности с регистрацией имен на сервере WINS, попробуйте включить этот режим. Поскольку сохранение подробной информации замедляет работу WINS, его рекомендуется включать только при диагностике проблем с регистрацией. Чтобы просмотреть подробную информацию, воспользуйтесь разделом System Log приложения Event Viewer. О Replicate Only With Partners — по умолчанию сервер WINS выполняет репликацию только с серверами WINS, указанными в качестве партнеров по репликации. Если снять этот флажок, сервер WINS можно настроить для обмена данными с серверами WINS, отсутствующими в списке партнеров. О Backup on Termination — база данных WINS архивируется при завершении работы WINS Manager. О Migrate On/Off — клиентам WINS разрешается перезаписывать статические данные. Эта возможность используется в ситуациях, когда для компьютеров, которые не являлись клиентами WINS, были созданы статические записи, после чего эти компьютеры были преобразованы в клиентов WINS. Перезапись статических данных позволяет новым клиентам WINS динамически регистрировать свои имена компьютеров (с перезаписью существующих статических записей). Включите этот режим при модернизации более старых систем до Windows NT. О Starting Version Count — значение, используемое для контроля версии базы данных. Если база данных WINS будет безвозвратно испорчена, введите нулевой номер версии, чтобы обновить базу данных. О Database Backup Path — каталог, в котором хранятся архивы базы данных. Архивы используются для восстановления данных в случае сбоя WINS или системного сбоя. Важная подробность: не используйте сетевые каталоги для архивации базы данных WINS! В случае нарушения работы сети вы не сможете обратиться к базе данных WINS или восстановить ее. Архивация базы данных WINS Каждые 24 часа база данных WINS автоматически архивируется. Тем не менее для этого необходимо задать каталог для хранения архивов. Выполните следующие действия: 1. Откройте меню Mappings и выберите команду Back Up Database. 2. Введите каталог для хранения архивов. 3. Щелкните на кнопке ОК.
Архивация данных реестра В процесс сопровождения WINS также может входить архивация данных реестра, относящихся к серверу WINS. Выполните следующие действия: 1. Запустите редактор реестра Windows NT 4 командой regeditexe или regedt32.exe. 2. Найдите подраздел WINS в разделе HKEYJXX^JW(>IINE^ Services\. 3. Откройте меню Реестр (Registry) и выберите команду Экспорт ветви реестра (Save Key). На экране появляется соответствующее диалоговое окно. 4. Введите каталог, используемый для архивации, и щелкните на кнопке Сохранить (Save). 5. Закройте редактор реестра Восстановление базы данных WINS Если WINS перестает нормально работать, вероятно, целостность данных в базе WINS была нарушена. При обнаружении порчи данных WINS автоматически восстанавливает базу данных. Также можно остановить и перезапустить службу WINS — возможно, сервер обнаружит и исправит ошибку. Это делается так: 1. Откройте панель управления. Для этого следует выполнить команду Пуск ► Настройка ► Панель управления (Start ► Settings ► Control Panel). 2. Дважды щелкните на значке Службы (Services). 3. Найдите в списке служб строку Windows Internet Name Service. 4. Щелкните на кнопке Stop. 5. Щелкните на кнопке Start. Если WINS обнаруживает порчу данных в базе, воспользуйтесь приложением Event Viewer и убедитесь в том, что восстановление прошло успешно. Если WINS не обнаруживает порчу данных и не восстанавливает базу после перезапуска, восстановление можно провести вручную. Это делается так: 1. Откройте меню Mappings и выберите команду Restore Database. 2. Введите каталог, в котором хранится архив. 3. Щелкните на кнопке ОК. Есл