1
Мониторинг
анализ сетей
Методы выявления неисправностей
реальные сценарии,
простые примеры,
I иллюстраций
1 производите.__.
¦ и поддержка новых \
;,| приложений *,
•ж Профессиональные
!* приемы мониторинга
! безопасности
I и защита
дательство
"Лори"
Эд Уилсх)н

Network Monitoring
and Analysis
Л Protocol Approach to Troubleshooting
Ed Wilson
Prentice Hall РКГ
Upper Saddle River, New Jersey 07458
www.phpir, com

V*
Мониторинг
и анализ сетей
Методы выявления неисправностей
Эд Уилсон
Издательство "ЛОРИ"

Network Monitoring and Analysis
A Protocol Approach to Troubleshooting
Ed Wilson
Copyright 2000 ; ,,. ; .. , v • ..
All rights reserved
Мониторинг и анализ сетей
Методы выявления неисправностей
Эд Уилсон
Переводчик О.Труфанов
Научный редактор А.Киселева
Корректор И.Гришина
Верстка Л.Федерякиной ,' {; '^
Copyright © 2000 by Prentice Hall PRT
Prentice Hall, Inc.
Upper Saddle River, New Jersey 07458
ISBN 0-13-026495-4
© Издательство "ЛОРИ", 2002
Изд. N : OAI @3)
ЛР N : 070612 30.09.97 г.
ISBN 5-85582-163-3
Подписано в печать 03.04.2002 Формат 70x100/16
Гарнитура Нью-Баскервиль Печать офсетная
Печ.л. 23 Тираж 3200 Заказ N 2138.
Цена договорная
Издательство "ЛОРИ". Москва, 123557 Б. Тишинский пер., д. 40, корп. 2
Телефон для оптовых покупателей: @95J59-01-62
www.lory-press.ru
Отпечатано с готовых диапозитивов в ФГУП Издательство «Известия»
Управления делами Президента РФ
101999, ГСП-9, г. Москва, К-6, Пушкинская пл., д. 5.

Посвящается моей жене и другу Терезе

Предисловие
Компания Full Service Networking продает и поддерживает компьютерные
сети для большого числа заказчиков. Основная часть нашего бизнеса со-
состоит в обслуживании критически важных LAN и WAN для растущей базы
заказчиков. Ключевым моментом в предоставлении этой службы является
возможность быстро реагировать на множество сетевых проблем — часто
с беспокойным пользователем, требующим немедленных ответов на
сложные вопросы.
Другим важным моментом являются постоянные изменения в базовой
сетевой технологии. Это требует как специализации, так и интенсивной
подготовки технического персонала для понимания особенностей новых
технологий.
Компания Microsoft, как и другие компании, работающие в этой отрас-
отрасли, регулярно обновляет свои сетевые продукты. Мы работаем в отрасли, в
которой постоянно выпускаются новые продукты. Их число растет экспо-
экспоненциально, так как технологии стремительно развиваются.
Как справиться с этой ситуацией и гарантировать высокий уровень об-
обслуживания пользователей сетей? Ответственность лежит на инженерах,
обслуживающих сеть на местах. Они должны работать более грамотно и
эффективно.
Сетевой инженер, хорошо понимающий процедуры и инструменты мо-
мониторинга и анализа сложной сети, способен идентифицировать и разре-
разрешить возникающие проблемы быстро и грамотно. Эти же инструменты
поистине бесценны при профилактической работе с сетью для обнаруже-
обнаружения потенциальных проблем, прежде чем они станут критическими. Книга
"Мониторинг и анализ сетей: методы выявления неисправностей" даст се-
сетевому инженеру возможность работать более эффективно.
Джеймс Нармор
Президент
Full Service Networking

Введение
¦ •' > ¦ ¦¦!..: . i|.
¦'-¦¦'' .'¦-¦ -л,
'¦- (,
Вы задумывались когда-нибудь, что происходит внутри сети? Почему она рабо-
работает медленно, что приводит к внезапному отказу задания печати или к неожи-
неожиданному останову программы? Приходилось ли вам слышать от пользователей,
что сервер работает медленно? Хотите ли вы получить лучшее представле-
представление о том, какой реально существует трафик? Если так, то эта книга для
вас, поскольку она посвящена сетевому мониторингу и анализу — возмож-
возможно, наименее понимаемым видам деятельности администраторов сетей.
Для многих вопрос состоит не в том, почему необходимо выполнять мо-
мониторинг сети; на самом деле это понятно интуитивно. Вопрос в том, где
найти для этого время? Прибавьте сюда тот факт, что потребуется время
на подготовку и обучение, прежде чем можно будет получить наиболее по-
полезную информацию. Возникает внутреннее сопротивление. В некотором
смысле это похоже на смену масла в автомобиле. Сделать это необходимо,
однако не хочется пачкаться.
Время для изучения рабочих инструментов наступает не тогда, когда
сеть не работает, а когда все идет хорошо. Мониторинг сети оставляет от-
открытой дверь для потока коммуникации данных, позволяя лучше понять
происходящие процессы. В книге дано множество советов и рекомендаций
о возможностях дальнейшего исследования. Фактически будет предложена
масса идей о настройке регулярного мониторинга и программы анализа.
Отдельными областями, для которых это будет наиболее полезно, являют-
являются поиск неисправностей, оптимизация и вопросы безопасности. Каждая
из них заслуживает существенного внимания.
В этой книге будут рассмотрены протоколы, которые, как правило, присут-
присутствуют в сети, и описаны источники трафика. Исходя из этого рассматривает-
рассматривается план тонкой настройки коммуникационных сценариев и предлагаются
решения, которые работают в реальной жизни. Когда трафик оценен, мож-
можно предсказать эффект добавления в сеть дополнительных служб или
компьютеров. Это позволяет избавиться от реагирующего режима поиска
фантомов и получить профилактический сбалансированный подход к
управлению сетью. Предсказывая трафик, можно определить требования
инфраструктуры и реализовать решения, прежде чем потребность в них
появится у пользователей. t ¦ ,; , . .¦
Зачем используется мониторинг сети
Сети — довольно шумное место. При рассмотрении сетевых записей преж-
прежде всего бросается в глаза огромный объем данных, который переносится
по проводам каждую секунду. Удивительно, что такое большое количество

viii Введение
данных не теряется. Мы рассмотрим несколько способов уменьшения этого
"шума". Однако при оптимизации сети правило: "Ничто не бывает бесплат-
бесплатно" остается как никогда справедливым. При настройке операционной сис-
системы необходимо проверить, от чего мы отказываемся, чтобы сократить
часть трафика. Во многих ситуациях можно сделать изменения, не отбрасы-
отбрасывая ничего существенного. В любом случае это должно быть тщательно взве-
взвешенным решением, опирающимся на полное понимание конкретной
сетевой конфигурации и функциональности, предоставленных специальной
службой или настройкой. Наши советы и рекомендации помогут вам создать
порядок из нематериального хаоса. Этот анализ и является нашей задачей
при оптимизации сети.
Оптимизация сети 1 • ^ .
Вооружившись исчерпывающим пониманием протоколов, можно выбрать
планы сокращения трафика. Одним из первых рассмотренных вопросов
является удаление лишних служб. Как мы узнаем в обзоре протоколов, тра-
трафик, связанный с дополнительными протоколами,— это не просто транс-
транспорт, но и службы, связанные с протоколом. Каждая служба общается с
другими, объявляя или другими способами сообщая о своем присутствии в
сети. При простом удалении одной или двух служб можно сократить трафик
в сети на 5-10 процентов.
Чтобы использовать только необходимые в сети протоколы, необходимо
знать, что такое протоколы, и где они используются. Поэтому в первом раз-
разделе книги исследуются наиболее часто используемые протоколы и рассмат-
рассматриваются их детали, чтобы понять, как они работают. С этими знаниями
можно разработать некоторые методологии оптимизации. Мы увидим, ка-
какие протоколы нам нужны, а какие нет. Мы получим уверенность при работе
только с одним протоколом и избежим стремления "держать один про за-
запас". Помимо потока излишнего трафика, сетевая коммуникация слишком
замедляется, когда программы делают многочисленные попытки найти
общий протокол.
Невозможно выполнить точную базовую оценку производительности с по-
помощью Сетевого монитора компании Microsoft (Microsoft Network Monitor)
(хотя некоторые другие продукты, доступные в настоящее время, могут это
сделать), но можно получить хорошее представление об использовании
сети и вручную определить подходящие статистики в электронной таблице
или базе данных. После отключения служб, сокращения числа протоколов
и оптимизации того, что остается, можно будет построить графики изме-
изменения производительности. Вы увидите, что процент использования, ши-
широковещание и ошибки CRC падают вниз, как осенние листья после
первого дождя. Вооружившись документами, полученными на этом этапе,
можно переходить к планированию расширения.
Планирование расширения • , .^л>/; ' . j Ц;>*>й
Всякий раз при добавлении к сети новых рабочих станций, принтеров, сер-
серверов или служб необходимо иметь четкое представление о том, как это по-
повлияет на вычислительную среду. При планировании расширения следует

Введение ix
представлять, где и какое влияние будет оказано на сеть. Бремя трафика,
скорее всего, будет значительно больше, чем при простом общении новой
машины с сервером. Если новая машина выполняет службы общего доступа
к файлам, то она тем или иным образом будет объявлять о своем присутст-
присутствии. Когда этот компьютер объявляет о готовности к работе, какое количе-
количество трафика будет создаваться? Какое влияние это окажет на остальную
часть сегмента? Если это единственный сегмент, то как насчет других ма-
машин, также использующих этот кабель? Каким будет действие на маршрути-
маршрутизатор или на коммутатор? Эти вещи необходимо рассмотреть, и именно о
них пойдет речь в данном разделе.
Вопросы безопасности
Мониторинг сети может быть очень полезен для борьбы с разбушевавшими-
разбушевавшимися хакерами. Хотя они и смогут проникнуть в сеть незамеченными — либо
украв пароли, либо обходя систему безопасности — они не смогут скрыть
свою деятельность, уже находясь внутри. Низкоуровневый сетевой монитор
может видеть все. Как же обнаружить хакеров в сетевом окружении?
Незаконный сервер DHCP является особенно неприятным. Сервер
DHCP располагается в сети, получает клиентский запрос IP-адреса, а затем
выдает свои собственные адреса. Они могут быть законными или незакон-
незаконными для сети или дублировать незаконные адреса, создавая в сети боль-
большие проблемы. В реальности мониторинг сети является лучшим способом
найти незаконный сервер DHCP. Сетевой монитор Microsoft версии 2
упрощает выполнение этой задачи.
Много лет назад высшие чины ВМФ США поняли, что самым лучшим
способом борьбы с подводными лодками являются собственные подводные
лодки. Эти молчаливые смертоносные устройства были намеренно созданы
так, чтобы их невозможно было обнаружить. Так был рожден класс подвод-
подводных лодок под названием "быстрая атака". Таким же образом единственным
способом обнаружить нелегальное прослушивание сети является использо-
использование сетевого монитора. Почти все инструменты в этом классе помогут в
обнаружении тайного прослушивания. Сетевой монитор версии 2 может
даже отключить неавторизованное прослушивание.
Имитация IP-адреса является любимым приемом хакеров, когда один
компьютер маскирует другой, используя IP-адрес другой машины и затем
отвечая на запросы, адресованные кому-то другому. Можно обнаружить
имитацию адреса, запуская утилиту сетевого мониторинга. Имитация IP-ад-
IP-адреса может происходить также при неправильной конфигурации маршру-
маршрутизаторов. В этом случае машина отвечает на запросы, направленные
другой машине с тем же IP-адресом. Это может вызвать большие проблемы,
прежде чем ошибка будет обнаружена.
Поиск неисправностей
Очевидно, что неработающую плату Ethernet обнаружить легко. Однако
карту, которая считает себя хорошей и реально передает и получает время
от времени информацию, найти значительно трудней. Это называется

Введение
нестабильной работой. Карта Ethernet заполняет сеть фиктивной ин-
информацией, приводя к замедлению всей коммуникации в сети. Это можно
обнаружить с помощью инструментов мониторинга сети.
Одно плохое приложение может повлиять на любую другую программу,
работающую в сети. Плохие приложения могут проявить себя множеством
различных способов. Они могут искать файлы, которые находятся не
здесь, вызывая излишнюю нагрузку поиска на сервере, или даже создавать
ненужный трафик. Мы рассмотрим несколько типичных сценариев и раз-
разработаем схему, которую можно использовать для поиска других проблем в
этой области.
Мониторинг сети превосходно помогает разрешить трудные проблемы
соединения. Очевидно, что если используется TCP/IP, то для тестирова-
тестирования основной коммуникации между машинами можно сделать эхо-запрос
(ping). Но это только первый шаг. Темой данного раздела является ситуация,
когда ping работает, а общение с сервером невозможно.
Аудитория >* ^
Эта книга предназначена прежде всего для сетевых администраторов, сис-
системных архитекторов, технического персонала и всех, кто поддерживает
Windows NT (хотя она будет полезна и тем, кто непосредственно не поддер-
поддерживает Windows NT, так как протоколы по сути являются одинаковыми, не-
независимо от платформы, на которой они используются). Книга также
пригодится тем, кто готовится к сдаче экзаменов на сертификат MCSE, Cisco
CCNA или Comptia Network Plus. Эта книга не покажется вам слишком слож-
сложной. Здесь не предполагается знание вами протоколов или опыт работы с
продуктами, поскольку они рассматриваются в ходе изложения материала.
Основные понятия TCP/IP, DHCP, DNS и WINS будут полезны, так как они
используются в некоторых из примеров. Если вы хотите выполнять мони-
мониторинг и анализ сети и/или стремитесь научиться искать неисправности и
оптимизировать сетевую коммуникацию, эта книга вам поможет.
Структура книги ..i.;<......
В этой книге мониторинг и анализ сети рассматриваются с точки зрения
протоколов. В примерах поиска неисправностей большей частью будет
использоваться сетевой монитор компании Microsoft (называемый иначе
Netmon). В настоящее время существуют четыре различные версии это-
этого инструмента, которые сравниваются в книге. Называвшийся вначале
bloodhound, Netmon немного изменился с момента своего появления. Еще
более усложняет ситуацию интерфейс, который не очень понятен интуитив-
интуитивно, а файлы оперативной помощи мало помогают разобраться в реальном
использовании продукта.
Мы закроем этот пробел и расскажем, как получить максимум пользы от
этого мощного инструмента. Будут показаны типичные сценарии использо-
использования, указаны потенциальные ловушки и рассмотрены реальные приме-
примеры. Затем, после обзора модели OSI и самих протоколов, мы используем

Введение xi
наши знания взаимосвязи протоколов для использования всей мощи сете-
сетевого монитора. В заключение рассматривается взаимодействие протоко-
протоколов друг с другом. Эта информация поможет понять, что мы разыскиваем в
полях кадров. Мы становимся единым целым с сетью, так как говорим на
языке наших машин.
Мы покажем, как использовать сетевой монитор для анализа трафика
сети и как искать неисправности с помощью этого инструмента. Мы рас-
рассмотрим различные сценарии оптимизации и дадим множество информа-
информации для размышлений. Прочитав эту книгу, вы увидите сеть в новом свете.
Окончательным результатом станет умение использовать существующие
инструменты для поиска неисправностей.
Наш подход в определенной степени управляется нашей задачей,
т.е. мы будем двигаться от общего к частному. Этот путь приведет нас в
бурное море, но имея фундамент, заложенный в первой части, мы сможем
уверенно в нем плавать.
Часть I. Анализ протоколов: участники взаимодействия
Чтобы правильно выполнить сетевой мониторинг и анализ, необходимб
знать, что именно мы ищем. Эта часть книги поможет понять, что удержива-
удерживает многих из нас от использования этих важных инструментов. Рассматри-
Рассматривая повседневные протоколы и изучая связанные с ними характеристики,
мы научимся более эффективно искать неисправности в сети.
Глава 1: "Основные сетевые модели" начинается с модели взаимодействия
открытых систем и модификаций, сделанных проектом IEEE 802. Мы рас-
рассмотрим, как формируются пакеты, а также и способ, которым протоколы
со всем этим работают. ,, . • .'• t: . : '
Глава 2: "Стек протоколов TCP/IP' представляет собой введение в этот про-
протокол. Большая часть книги будет посвящена работе с протоколом управле-
управления передачей, протоколу взаимодействия сетей и их "родственникам". <
В главе 3: "Стек протоколов IPX/SPX' изучается протокол пакетного обме-
обмена Интернета и протокол упорядоченного обмена пакетами. Мы рассмот-
рассмотрим, как формируются пакеты, а также роль протокола объявления службы
и как он осуществляет разрешение имени.
Глава 4: "Блоки сообщений cepeepd' является основой изучения коммуникации
сетевых компьютеров.
Часть II. Анализ сетевого трафика и оптимизация:
существующие проблемы
Во второй части книги мы рассмотрим трафик с четырех различных точек
зрения, а затем предложим рекомендации для сокращения трафика в каж-
каждом из случаев.
В главе 5: "Клиентский трафик" рассматриваются некоторые из источни-
источников трафика клиента, включая просмотр ресурсов сети и попытки разреше-
разрешения имени для коммуникации с другими машинами.

xii Введение
В главе 6: "Серверный трафик!' обсуждаются некоторые источники трафи-
трафика сервера, включая репликацию каталогов и ответы на запросы DNS.
Глава 7: "Трафик приложений" посвящена трафику, связанному непосред-
непосредственно с приложениями, такими как работа с файлами и печать, просмотр
Интернета и даже программы e-mail.
Часть III. Сетевые мониторы: инструменты работы
Теперь мы переходим к интересному материалу — инструментам работы.
Компания Microsoft предлагает несколько хороших, доступных и достаточ-
достаточно мощных инструментов.
В главе 8: "Семейство сетевых мониторов компании Microsoft' выделены как
минимум три различных инструментальных набора сетевого монитора
компании Microsoft. Здесь рассматриваются инструменты и связанные с
ними вопросы, а также приемы для получения максимума возможного из
этих недоработанных инструментов.
Часть IV. Сценарии поиска неисправностей: „ \
рассмотрение общих проблем
В данной части знания о протоколах и инструментах мониторинга сети
применяются к некоторым проблемам реального мира. Вооруженные мощ-
мощными инструментами мониторинга сети, мы сможем решать сложные
проблемы. ¦• - ¦ : ". , ....
В главе 9: "Проблемы соединения" рассматривается старый сценарий "Я не
могу войти в сеть!". Существует, конечно, много вариантов, и иногда случа-
случается видеть рабочую станцию, которая не может найти контроллер домена,
получить адрес от DHCP или соединиться с сервером. Возможно, это проб-
проблема пароля или другой вопрос регистрации. Эти проблемы просто не мо-
могут пройти незамеченными для хорошо настроенного сетевого монитора.
К сожалению, некоторые приложения не вполне отлажены к моменту свое-
своего выпуска и поступают в производство преждевременно. Во многих случа-
случаях не отловленные вовремя ошибки исправляются в последующих версиях.
Но как понять, что та или иная проблема решается установкой пакета исп-
исправлений? Чрезмерное широковещание, низкая сетевая производитель-
производительность и нераспределенные страницы являются кандидатами для проверки
с помощью Netmon.
Глава 10: "Вопросы безопасности" посвящена использованию анализатора
трафика. Здесь рассматриваются незаконные серверы DHCP, неавторизо-
неавторизованный просмотр пакетов и т.п.
На сайте издательства "ЛОРИ" (www.lory-press.ru) находятся копии
файлов примеров, упомянутых в книге, фильтры, которые можно загру-
загрузить в Microsoft Network Monitor для поиска неисправностей, а также
несколько примеров пакетных файлов, которые можно использовать для за-
запуска необслуживаемых сеансов Netmon с помощью службы планировщика
Microsoft Windows NT.

Благодарности
В реализации этого проекта помогали множество людей. В частности,
большую часть книги изучил и прокомментировал технический пер-
персонал Full Service Networking. Дэвид Мартин прочитал всю книгу не-
несколько раз и поделился отличными идеями. Марк Грос и Джейсон
Веббер потратили несколько выходных, чтобы создать почти все
файлы сетевых примеров. Тереза Вилсон сделала некоторые рисунки.
Об авторе
Эд Уилсон, MCSE + I, MCT, Master ASE, CCNA — старший специа-
специалист по компьютерным сетям в компании Full Service Networking
(Цинцинатти, штат Огайо), являющейся партнером Microsoft по
развертыванию решений. Он автор нескольких книг, посвященных
работе с сетями и подготовке к экзаменам MCSE.

Содержание
ЧАСТЬ I Анализ протоколов: участники взаимодействия 1
Глава 1 Базовые сетевые модели ¦ ¦ • ¦ ¦ 3
Модель 0SI 3
Уровень приложений 6
Уровень представлений 7
Сеансовый уровень 8
Транспортный уровень 9
Сетевой уровень 10
Канальный уровень 11
Физический уровень 12
Проект IEEE 802 13
Усовершенствования, сделанные в модели OSI 13
Подуровень управления логическим каналом (LLC) 13
Подуровень управления доступом к среде передачи (MAC) 15
Как данные перемещаются по проводам 15
Процесс создания пакета 16
Особенности коммуникации в сетях Ethernet 18
Какова во всем этом роль протоколов? 21
Стек протоколов 21
Иерархический подход 22
Как все это объединяется? 24
Прикладные протоколы 26
Транспортные протоколы 26
Сетевые протоколы 27
Сетевая служба с поддержкой соединения 27
Сетевая служба без поддержки соединения 28
Адресация на канальном уровне 29
Адресация на сетевом уровне 29
Инкапсуляция данных 30
Реализация IP поверх различных стандартов LAN 31
Управление потоком 35
Функции межсетевого обмена сетевого уровня OSI 36
Службы WAN 36
Обзор главы 41
В следующей главе 42
Глава 2 Стек протоколов TCP/IP 43
Протокол TCP 46
Заголовок TCP 47
Трехходовое квитирование 50
Концепция времени молчания TCP 52
Полуоткрытые соединения и другие аномалии 53
Генерация команды сброса 54
Обработка команды сброса 55
Сценарий 1: локальный пользователь инициирует закрытие 56
Сценарий 2: TCP получает FIN из сети 56

Содержание xv
Сценарий 3: оба пользователя закрывают соединение одновременно '57
Обмен срочной информацией 57
Управление окном 57
Интерфейс пользователь/TCP 59
Команды пользователя TCP 59
Send (Послать) 60
Receive (Получить) 62
Close (Закрыть) 62
Status Abort (Прервать) 63
TCP/Низкоуровневый интерфейс 63
Происходящие события: пользовательские вызовы 64
Состояние прослушивания 65
Вызов SEND (Послать) 65
Протокол IP 67
Заголовок IP ¦ 71
Обзор главы 84
В следующей главе • ¦ • 84
Глава 3 Стек протоколов SPX/IPX 85
Протокол SPX 85
Заголовок SPX 85
Протокол IPX 91
Протокол без соединения 91
Работа на сетевом уровне модели OSI 91
Структура пакета • • • 92
Адресация IPX 95
Сетевой номер 95
Зарезервированные сетевые номера 96
Внутренний сетевой номер 96
Номер узла 96
Номер сокета 97
Как работает маршрутизация IPX 98
Интерфейсы сеансов и дейтаграмм 100
Структуры заголовка сообщений 101
Обзор главы 103
В следующей главе 103
Глава 4 Блоки сообщений сервера 104
Обзор работы SMB 105
Определение имени сервера 105
Разрешение имени сервера 106
Транспорт сообщения 106
Пример потока сообщений 106
Согласование диалекта 108
Создание соединения 108
Обратная совместимость 109
Настройка сеанса 109
Управление соединением 109
Подпись SMB 110
Оппортунистические блокировки 110
Исключающая oplock ¦ • • 111
Пакетная блокировка oplock 112
Level II Oplocks 114

xvi Содержание
Модель безопасности 115
Пример доступа/общего ресурса 116
Аутентификация 117
Поддержка распределенной файловой системы (DFS) 118
Заголовок SMB 119
ПолеТЮ 120
ПолеШ) 120
ПолеРЮ 120
Поле MID 121
Поле флагов 121
ПолеНадэг 123
Поле состояния 123
Задержки 124
Буфер данных (SUFFER) и форматы строк 124
Кодирование режима доступа 125
Кодирование функции открытия (Open) 126
Кодирование действия открытия (Open) 126
Кодирование атрибутов файла 127
Кодирование расширенных атрибутов файла 127
Пакетные запросы (Сообщения "AndX") 128
Обзор главы 130
В следующей главе 130
ЧАСТЬ II Сетевой трафик
Анализ и оптимизация: взгляд на проблемы 131
Глава 5 Клиентский трафик 133
Инициализация клиента f4'+; . . 133
Трафик DHCP 134
Трафик клиента WINS 142
Регистрация имен и обновление 142
Трафик регистрации в системе 147
Поиск сервера регистрации 148
Оптимизация регистрации в сети 156
Просмотр 159
Объявления хостов броузеров 161
Где находятся резервные броузеры? 163
Оптимизация трафика броузера 165
Обзор главы 166
В следующей главе 166
Глава 6 Серверный трафик 167
DNS 167
Разрешение адреса « • •;¦"•"•¦. ; ... 167
Рекурсивный поиск 169
Объединение с WINS 170
Оптимизация DNS 170
Инициализация BDC 170
Где находится PDC? 171
Обновления в базе данных 184
Оптимизация трафика синхронизации учетных записей 186
Служба NetLogon 186

Содержание xvii
Обзор главы 190
В следующей главе 190
Глава 7 Трафик приложений 191
Работа с файлами и печать 191
Запрос WINS 191
Широковещание 192
ARP 193
Трехходовое квитирование 194
Сеанс NetBIOS 195
Согласование диалекта SMB 196
Просмотр Интернета 201
Страницы Web 201
Secure Sockets Layer ¦ • ¦ • 207
Оптимизация трафика броузера в интрасети 208
Обзор главы 209
В следующей главе 209
Глава 8 Exchange и почта Интернета 210
Exchange 210
Открытие и закрытие сеанса 213
Сервер Exchange в действии 214
Протокол РОРЗ 216
Общение Exchange с другим сервером 226
Обзор главы 229
В следующей главе 229
ЧАСТЬ III Сетевые мониторы:
инструментальные средства работы ¦ 231
Глава 9 Семейство сетевых мониторов компании Microsoft 233
Сетевой монитор 233
Создание перехвата 234
Перехват трафика вручную 236
Просмотр перехваченных данных 238
Сохранение перехваченных данных 239
Фильтрация данных перехвата 240
Анализ перехваченных данных 242
Система безопасности сетевого монитора 245
Защита с помощью пароля 246
Установка сетевого монитора: обнаружение других мониторов 247
Сетевой монитор Systems Management Server 1.2 249
Дополнительные свойства 249
Соединение с удаленными агентами 251
Мастера-помощники 252
Конфигурирование триггеров 254
Network Monitor 2.0 256
Новые свойства 256
А вот это не работает 259
Дополнительные свойства безопасности 259
Обзор главы 263
В следующей главе 264

xviii Содержание
ЧАСТЬ IV Сценарии поиска неисправностей:
распространенные проблемы 265
Глава 10 Вопросы поиска неисправностей 267
Рабочая станция не может зарегистрироваться 267
Можно ли сделать ping сервера? 267
Рассмотрим случай с портативным компьютером 272
Рабочая станция не может получить выделяемый DHCP адрес 272
Взгляд на диалог 273
Проанализируйте, что пропущено 273
Рабочая станция работает медленно 275
Можно ли точно определить понятие "медленная"? 275
Что является источником недовольства? 275
Проблемы с регистрацией 276
Я пытаюсь аутентифицироваться, но где? 277
Странные ошибки журнала событий 281
Метод поиска серверных проблем 281
Выполнение без сопровождения 283
Избыточное широковещание 285
Кто это делает? 285
Почему они это делают? 287
Обзор главы 288
В следующей главе 288
Глава 11 Вопросы безопасности 289
Нелегальные серверы DHCP 289
Есть ли у меня для вас адрес? 289
Итак, где вы? 294
Нелегальный анализ сети ("вынюхивание") 294
Прежде всего необходимо их найти 295
Как отбить нюх чужим ищейкам 295
Обзор главы 296
Приложение А Список общеизвестных номеров портов TCP и UDP 297
Приложение В Утилиты командной строки 310
Приложение С Общие NCP 312
Приложение D Поиск обычных сетевых ошибок 321
Приложение Е Суффиксы NetBIOS 323
Приложение F Запуск контроллера домена • ¦ • 325
Приложение G Открытие страницы Web 336
Глоссарий 347

ЧАСТЬ I
Анализ протоколов:
участники взаимодействия
. тобы правильно выполнить мониторинг и анализ сети, необходимо по-
понимать, что требуется найти. Недостаточное знакомство с принципами
работы сети часто удерживает многих от использования важных инстру-
инструментов. Однако при рассмотрении более общих протоколов невозможно
обойтись и без общих понятий, связанных с ними. Понимая, на что же
фактически нацелен поиск неисправностей, вы сможете более эффективно
осуществлять его в сети.

Глава 1
Базовые сетевые модели
В этой главе рассматривается модель взаимодействия открытых систем
(OSI) и приводятся примеры ее использования для мониторинга сети. Будут
также обсуждаться модификации, сделанные в модели OSI рабочей группой
IEEE 802. Затем остановимся на передаче данных по носителю в сети, а в
заключение рассмотрим роль протоколов в этом процессе.
_ Сетевые модели помогают нам представить себе способ, с помощью кото-
которого компьютеры общаются друг с другом, и проанализировать работу сети
с помощью инструментов мониторинга. Они очень важны для понимания
протоколов и потока данных, а также для изучения сетевой оптимизации и
сценариев поиска неисправностей.
Модель OSI ~ \
Первый шаг в изучении мониторинга сети состоит в рассмотрении модели
OSI. Эта модель создаст базовое понимание того, как работают протоколы.
Модель OSI была разработана в 1984 г. Международной организацией по
стандартизации (ISO) в качестве руководства по организации сетей переда-
передачи данных. Она заменила спецификацию ISO 1978 г., разработанную для
того, чтобы различные устройства могли обмениваться данными с помо-
помощью однотипных протоколов. Модель OSI 1984 г. является международной
"классикой", которой удовлетворяют практически все сетевые архитекту-
архитектуры. Большинство реализаций конкретных сетей не совпадает с моделью
OSI в точности, но в любой такой реализации функции, описанные моде-
моделью, должны некоторым образом выполняться (или по крайней мере при-
приниматься в расчет). Ценность модели OSI в качестве инструмента поиска
неисправностей состоит в описании видов деятельности, или функций. На-
Например, имея точное представление о том, что делает сценарий ("да, я могу
сделать это, это и еще это, а вот это уже не могу"), можно точно локализо-
локализовать проблему.

Глава 1
Модель OSI четко описывает функции и часто используется производи-
производителями оборудования в качестве руководства по реализации необходимых
свойств в своих конструкциях. Можно увидеть, как оборудование и про-
программное обеспечение совместно обеспечивают надежную и эффективную
коммуникацию между устройствами. В ходе изложения этой книги мы бу-
будем постоянно ссылаться на модель OSI.
Модель OSI представляет собой многоуровневый подход к коммуника-
коммуникации, и каждый ее уровень предоставляет службы для нижележащего и вы-
вышележащего уровня в иерархии. На рис. 1.1 изображены семь уровней
модели OSI.
Самый высокий уровень, седьмой, на схемах и рисунках обычно изобра-
изображается сверху, так как именно на этом уровне находятся приложения и по-
пользовательский интерфейс, если он вообще имеется. Два самых нижних
уровня, первый и второй, соответствуют кабелям и сетевым адаптерам.
7. Уровень приложений
6. Уровень представлений
5. Сеансовый уровень
4. Транспортный уровень
3. Сетевой уровень
2. Канальный уровень
1. Физический уровень
Рис. 1.1. Семиуровневая модель взаимодействия открытых систем является
основой для понимания работы современных компьютерных сетей и поиска
в них неисправностей

Базовые сетевые модели
Для иллюстрации того, как происходит коммуникация данных в сетевой
среде, можно рассмотреть аналогию с телефонной связью. Когда вы снимае-
снимаете трубку и набираете номер, используются службы, предоставляемые теле-
телефонной компанией. Телефон взаимодействует с проводами и другими
элементами инфраструктуры телефонной сети. Звоня по телефону, мы мо-
можем ничего не знать о проводах и другом оборудовании. Абоненты разгова-
разговаривают как будто непосредственно друг с другом, оставив технические
подробности оборудованию и специалистам. Модель OSI работает таким же
образом. Уровень приложений на одной машине вступает в виртуальный
диалог с уровнем приложений на другой машине, причем они ничего не
знают о том, какую работу выполняют другие уровни.
7. Уровень приложений
1?
1L
5. Сеансовый уровень
4. Транспортный уровень
3. Сетевой уровень
1?
2. Канальный уровень
1?
1. Физический уровень
6. Уровень представлений
7. Уровень приложений
1?
6. Уровень представлений
1?
5. Сеансовый уровень
4. Транспортный уровень
3. Сетевой уровень
2. Канальный уровень
1. Физический уровень
Рис. 1.2. Обмен данными с точки зрения каждого уровня модели 0SI
и фактический обмен данными

Глава 1
На рис. 1.2 показано, что каждый уровень модели OSI считает, что он об-
общается с тем же уровнем на другой машине. В реальности каждый уровень
взаимодействует только с уровнями выше и ниже его в иерархии. Каждый
уровень отвечает за выполнение определенных функций в соответствии
с используемыми протоколами.
Когда приложение хочет послать данные другому приложению, они пе-
передаются из уровня приложений в нижележащий и т.д. по всему стеку про-
протоколов. Каждый уровень будет добавлять заголовочную информацию,
которая помогает ему в выполнении его специфической функции. В неко-
некоторых случаях уровень может добавить не только заголовок, но и конце-
вик. Данные разбиваются на куски, чтобы облегчить их передачу по сети.
Данные, полученные из протокола TCP (транспортный уровень), называ-
называются сегментом, но когда к ним на сетевом уровне добавляется заголовоч-
заголовочная информация протокола IP, полученный блок данных становится
пакетом, или дейтаграммой. Когда блок данных перемещается по кабелю в
направлении своего места назначения, он называется кадром. Термины па-
пакет и кадр иногда (хотя технически неправильно) используются как сино-
синонимы. Чтобы быть полностью точными, пакет — это данные сетевого
уровня, а кадр — это данные, передаваемые по кабелю. Данные передаются
затем с уровня на уровень, и каждый уровень будет добавлять или убирать
что-то из пакета согласно тому, где это происходит. На принимающем кон-
конце линии связи происходит обратный процесс: данные поступают из кабе-
кабеля на физическом уровне и перемещаются вверх, пока не прибудут на
уровень приложений в том виде, в котором они были отправлены другим
приложением. Только физический уровень фактически обменивается дан-
данными со своим аналогом на другой машине. Взаимодействие между смеж-
смежными уровнями происходит через интерфейс, который определяет, какие
службы тот или иной уровень предоставляет уровню выше или ниже в
иерархии. Теперь более подробно рассмотрим с этой точки зрения службы,
предоставляемые каждым уровнем модели OSI.
Уровень приложений
Седьмой уровень, или уровень приложений, является самым верхним в моде-
модели OSI и служит в качестве окна для доступа приложений к сетевым службам.
Этот уровень непосредственно поддерживает приложения пользователя, но
здесь располагаются не такие приложения, как Word или Excel. Они не явля-
являются частью модели OSI. Приложениями, которые располагаются здесь, яв-
являются Telnet, FTP и т.п. Этот уровень отвечает за общий доступ к сети,
управление потоком и восстановление после ошибок.
Уровень приложений взаимодействует с программными приложения-
приложениями, которые реализуют или поддерживают коммуникационный компонент
сетевого приложения. Сетевые приложения — пересылка файлов, e-mail,
управление сетью, удаленный доступ и т.п. Функции уровня приложений
обычно включают:
• Идентификация коммуникационных партнеров — уровень приложе-
приложений идентифицирует и определяет доступность коммуникационных
партнеров для приложения, которое имеет данные для передачи.

Базовые сетевые модели
• Определение доступности ресурсов — уровень приложений должен
определить, достаточно ли доступных сетевых ресурсов для запро-
запрошенной коммуникации.
• Синхронизации коммуникации — коммуникация между приложениями
требует согласованности, за которую отвечает уровень приложений.
Уровень приложений является ближайшим к конечному пользователю
уровнем OSI. То есть как уровень приложений OSI, так и пользователь не-
непосредственно взаимодействуют с программным приложением. Несколько
примеров реализаций уровня приложений:
• Приложения TCP/IP — это такие протоколы из стека протоколов
Интернета, как Telnet, протокол передачи файлов FTP и почтовый
протокол SMTP.
• Приложения OSI — это такие протоколы из стека OSI, как FTAM, VTP
иСМ1Р. .
Уровень представлений .
Шестой уровень, уровень представлений, определяет формат, используе-
используемый для пересылки данных между компьютерами. Его можно назвать сете-
сетевым транслятором, так как он участвует в преобразовании данных из
формата, поступающего из уровня приложений, в принятый промежуточ-
промежуточный формат. На получающем компьютере уровень представлений преобра-
преобразует данные обратно в формат, в котором уровень приложений другого
компьютера их послал. Некоторыми из обычных видов деятельности, вы-
выполняемых уровнем представлений, являются преобразование протоколов,
трансляция данных, шифрование данных, изменение или преобразование
множества символов и расширение графических команд. Уровень представ-
представления управляет также сжатием данных для сокращения числа битов, необ-
необходимых для передачи данных. Редиректор, который отвечает за решение,
где получить данные для операций ввода или вывода ресурсов на сервере,
располагается в уровне представления.
Уровень представлений предоставляет множество функций кодирова-
кодирования и преобразования, которые применимы к данным уровня приложений.
Эти функции гарантируют, что информация, посланная из уровня прило-
приложений одной системы, будет читаема уровнем приложений другой систе-
системы. Некоторыми примерами схем кодирования и преобразования уровня
представлений являются следующие: . ..:¦•.¦
• Общие форматы представления данных — использование стандарт-
стандартных форматов изображений, звука и видео позволяет обмениваться
данными приложений между различными типами компьютерных
систем (JPEG, MPEG, GIF и т.д.).
• Преобразование форматов представления символов — схемы преоб-
преобразования используются для обмена информацией с системами, испо-
использующими различные представления текста и данных (например,
EBCDIC, ASCII и все более популярный язык разметки гипертекста

Глава 1
HTML, который описывает, как информация должна быть представ-
представлена при просмотре в Web-браузере, таком как Internet Explorer или
Opera).
• Общие схемы сжатия данных — использование стандартных схем сжа-
сжатия данных позволяет правильно восстановить в месте назначения
данные, которые сжаты на устройстве источника.
• Общие схемы шифрования данных — использование стандартных
схем шифрования данных позволяет правильно расшифровать в ме-
месте назначения данные, которые были зашифрованы на устройстве
источника.
Реализации уровня представлений обычно не связаны с определенным
стеком протоколов. Некоторыми хорошо известными стандартами являются:
• Данные: ASCII, EBCDIC, шифрование
• Визуальные изображения: PICT, TIFF, GIF, JPEG
• Аудио и видео: MIDI, MPEG, QuickTime " Ч ''"' '••
Сеансовый уровень
Пятый уровень, сеансовый, позволят приложениям на различных компью-
компьютерах настраивать, управлять и завершать общение, называемое сеансом.
Он предоставляет свойства, которые естественно считать необходимыми
на этом уровне, например распознавание имени и обеспечение безопасно-
безопасности. Обеспечение безопасности требуется, чтобы помешать посторонним
соединиться с компьютером через сеть. Другими свойствами, которые
можно увидеть на этом уровне, являются инструменты для управления ком-
коммуникацией машин во время сеанса. Здесь также находятся средства восста-
восстановления данных, например контрольные точки между общающимися
приложениями. Это позволяет машине знать, что было послано и когда.
Критически важно, чтобы эта функция выполнялась — в частности, в нена-
ненадежных сетях (таких как Интернет). При потере данных их придется по-
повторно передавать только с момента последней контрольной точки. Этот
уровень реализует также управление диалогом между общающимися про-
процессами. Он определяет, какая сторона передает, когда и как долго. Таким
образом, сеанс отвечает за управление запросами и ответами всех служб,
которые происходят между приложениями, выполняющимися на двух раз-
различных компьютерах.
Сеансовый уровень создает, управляет и прекращает коммуникацион-
коммуникационные сеансы между сущностями уровня представлений. Сеансы коммуни-
коммуникации состоят из запросов и ответов служб, которые происходят между
приложениями, расположенными в различных сетевых устройствах.
Эти запросы и ответы координируются протоколами, реализованными
на уровне сеанса. Некоторыми примерами реализаций уровня сеанса яв-
являются следующие: AppleTalk Session Protocol, DEC SCP, NFS, SQL, RPC
и реализации X Windows.

Базовые сетевые модели
Транспортный уровень
Четвертый уровень, транспортный, предоставляет дополнительный уро-
уровень соединения под уровнем сеанса и тем самым определяет двухточечное
соединение между приложениями хостов. Транспортный уровень отвечает
за обеспечение доставки пакетов без ошибок, в определенной последовате-
последовательности и без потерь и дублирования. На этом уровне перепаковываются со-
сообщения, полученные из верхних уровней, при необходимости разделяются
длинные сообщения на более мелкие пакеты, собираются вместе несколько
небольших сообщений и помещаются в большие пакеты. Эта перепаковка
позволяет передавать пакеты по сети более эффективно. В принимающей
системе транспортный уровень снова собирает первоначальные сообщения
и обычно посылает подтверждение отправителю.
Транспортный уровень отвечает за сквозную обработку. Это логическая
связь. Транспортный слой предоставляет функции управления потоком,
обработки ошибок и решения проблем, связанных с передачей и получени-
получением пакетов. Именно здесь находится протокол TCP (Transmission Control
Protocol - Протокол управления передачей) из стека TCP/IP. Транспорт-
Транспортный уровень реализует надежные службы транспортировки данных между
сетями. Эти службы являются прозрачными для верхних слоев. Функции
транспортного уровня обычно включают:
• Управление потоком — организует передачу данных между устройства-
устройствами, чтобы передающее устройство не посылало больше данных, чем
принимающее устройство может обработать. Это особенно важно в пе-
перегруженных сетях, где многие машины могут заполнить сеть инфор-
информацией, предназначенной для одного и того же хоста. Было бы очень
легко потерять пакеты, если бы не было некоторого способа управле-
управления перегрузкой. Прибывшие дейтаграммы хранятся в памяти в буфе-
буфере. Если он будет переполнен, прежде чем данные можно будет
обработать, TCP имеет возможность послать индикатор неготовности.
Он действует как красный свет, чтобы предоставить компьютеру время
наверстать упущенное. Когда получатель готов обрабатывать дополни-
дополнительные сегменты, он посылает индикатор готовности, и отправитель
может снова возобновить передачу.
• Мультиплексирование — позволяет передавать данные нескольких при-
приложений по одной физической линии. Это достигается за счет много-
многоуровневой структуры модели OSI. Различные приложения посылают
сегменты в том виде, в котором они получены, и они могут направлять-
направляться в одно или несколько мест назначения. Когда поток данных прибы-
прибывает на транспортный уровень хоста назначения, он восстанавливается
и передается наверх в соответствующее приложение. TCP использует
номера портов, чтобы реализовать мультиплексирование. Так как не-
несколько различных приложений могут использовать TCP (или UDP)
одновременно, протоколы транспортного уровня хранят в заголовке
идентификатор. Этот идентификатор является 16-битным номером
порта, хранящимся в заголовке. Как TCP, так и UDP используют его
для идентификации номера порта источника и номера порта места

10 Глава 1
назначения. Список общепринятых номеров портов содержится в
Приложении А. Эти общепринятые номера портов присвоены IANA
(Уполномоченным по присвоению номеров Интернета). Это номера
между 1 и 1023 для различных серверных служб, таких как telnet, FTP,
SMTP и т.п. Номера между 1024 и 5000 могут использоваться приложе-
приложениями, создающими временные порты (короткоживущие порты).
IPX/SPX использует аналогичную концепцию, хотя порты в этом стеке
называются сокетами.
• Управление виртуальными каналами — виртуальные каналы создают-
•...,, ся, поддерживаются и завершаются на транспортном уровне. Это се-
сеанс с поддержкой соединения. Чтобы произошла передача данных, в
процесс вовлечены как передающая, так и получающая машины. Не-
Невозможно послать данные на машину на этом уровне, не вовлекая обе
машины. Инициирующая машина пошлет сообщение синхронизации,
чтобы начать передачу, получающая машина подтвердит сообщение
синхронизации и включит запрос синхронизированной последователь-
последовательности. Когда он будет подтвержден, начнется передача данных.
• Контроль ошибок и восстановление — контроль ошибок включает
различные механизмы обнаружения ошибок передачи. Восстановле-
Восстановление включает выполнение действий (например, запроса на повтор-
. >; ную передачу данных) для разрешения любых возникающих ошибок.
TCP и SPX требуют положительного подтверждения получения пе-
, ' реданных данных. Когда данные передаются, запускается таймер.
,,. Если сигнал АСК (подтверждения) не получен до окончания времени
таймера, сегмент посылается повторно.
Сетевой уровень
Третий уровень, сетевой, отвечает за сообщения адресации и преобразова-
преобразование логических адресов и имен в физические адреса. Это уровень также вы-
выбирает маршрут от источника к компьютеру назначения. Он определяет,
какой путь должны пройти данные, чтобы прибыть на компьютер места на-
назначения, на основе таких факторов, как загруженность линий, приоритет
службы, маршрутизация и т.д. В дополнение к этим функциям, если сете-
сетевой адаптер на маршрутизаторе не может передать фрагмент данных такой
величины, который послан компьютером источником, то он будет компен-
компенсировать это, разбивая данные на меньшие блоки. В месте назначения по-
получающий компьютер будет соответствующим образом восстанавливать
данные. Сетевой уровень управляет адресацией устройств и отслеживает
расположение устройств в сети. В результате на этом уровне обычно нахо-
находятся маршрутизаторы. Протокол IP (Internetwork Protocol, протокол меж-
межсетевого обмена) относится к третьему уровню.
Сетевой уровень реализует маршрутизацию и связанные с ней функции,
которые позволяют нескольким каналам данных объединяться в общую сеть.
Это осуществляется с помощью логической адресации (в противополож-
противоположность физической адресации) устройств. Сетевой уровень поддерживает
как ориентированные на соединение службы, так и службы без соединения
из протоколов верхних уровней.

Базовые сетевые модели
11
Канальный уровень ь
Второй, канальный уровень отвечает за передачу кадров данных из сетево-
сетевого уровня в физический. На принимающей стороне соединения он преоб-
преобразует полученные от физического уровня биты в кадры данных. Кадр
данных является организованной, логической структурой, в которую мож-
можно поместить данные. На рис. 1.3 показан типичный кадр данных. В нем мы
видим адрес места назначения, адрес отправителя, тип кадра, длину кадра
и данных, а также объем еще не переданной информации.
Netwoik МопНм Г6Л0717'1018е<*.орЮе<.»Ш
Доюте
jjtH>
РгакеЩже. _ ISrc KAC_AddrJpst НАС Jkddr Proto.ro lTDcscripf.on
1091 }136 569TSyttopt64E^D6ISvnapt6Q0l60 SHIP IETYPE * x0112
1093 1136 597|Htf KM_DB
1094 1136 617 |Н1ГКН DB
-j '
•BROADCAST | SAP
•BROADCAST I SAP
iGeneral Svc
[General Svc
[HPS_445030 - Advertising Print
(HPS_445030-HTHX - Ucknora Servi"
I
«¦ETHERHET: 802 3 Length ¦ 60
•¦ETHERHET: Destination address 010081000101
ETHERHET: 1 • Group address
ETHERNET: 0. • Universally administered address ;.
•¦ETHERHET: Source address : 00008104EED6
ETHERHET: 0 ¦ Ho routing information present
ETHERHET: . . .0 • Universally administered address
ETHERHET: Frame length . 60 (ОхООЗС)
ETHERHET: Data Length 0x0013 A9)
ETHERHET: Ethernet Data: Humber o( data bytes remaining • 46 @«002E)
-LIT: 01 DSAP-OxAA SSAP-OxAA С
IXC DSAP ¦ OxAA INDIVIDUAL : Sub-Hetoork Access Protocol (SNAP)
LLC: SSAP - OxAA: COHHAHD : Sub-Net*ork Access Protocol (SNAP)
IXC. Frame Category: Unnumbered Frame
LLC Command - DI
IXC. IXC Data. Humber ol data bytes remaining • 43 (ОжОогВ)
?Ы1Р PTVpr nnut
I
«I
f
booooooo ""
00000010
оооооого
00O0003O
ill 00 SI 00 01 01 00 00 81 04 ЕЕ L'b 00 13 AA AA
03 00 00 81 01 «I UB 00 00 Cb 04 ЕЕ Ob 0) 1J OJ
00 00 30 01 00 40 iF 3b 53 30 04 S2 ПП n? П4 13
i? c0 S? CF 34 34 Л 30 33 30 00 21
0 9-tSO.F
Рг 4451140 II
Fi«ne
FS 1032^23?
Рис. 1.З. Типичный кадр данных включает информацию контроля ошибок
и информацию о месте назначения, добавленные на канальном уровне
Канальный уровень отвечает за безошибочную передачу этих кадров от
одного компьютера другому через физический уровень. Одним из использу-
используемых им методов является CRC (контроль с помощью циклического избы-
избыточного кода), который представляет информацию для исправления
ошибок и проверки, чтобы гарантировать правильность передачи кадра
данных. Это "магическое" число позволяет получающему компьютеру
знать, что пакет является допустимым. Это позволяет сетевому уровню осу-
осуществлять практически безошибочную передачу через сетевое соединение.
Обычно канальный уровень посылает кадр и затем ожидает подтвержде-
подтверждения от получателя. Канальный уровень получателя обнаруживает любые
проблемы с кадром, которые могут происходить во время передачи.

12 Глава 1
Кадры, получение которых не подтверждено, и кадры, поврежденные при
передаче, пересылаются повторно. Таким образом, канальный уровень
отвечает за уведомление, сетевую топологию и управление потоком.
Канальный уровень предоставляет доступ к физической среде и обеспечи-
обеспечивает надежный транзит данных через физический канал сети. Здесь определе-
определены методы доступа к среде передачи Ethernet, Token Ring и FDDI. Каждая
спецификация уровня канала данных определяет различные характеристики
сети и протокола, включая:
• Физическая адресация — в противоположность сетевой адресации
определяет адресацию устройств на канальном уровне.
• Сетевая топология — спецификации канального уровня часто опреде-
определяют, как должны быть физически соединены устройства (например,
по топологии "шина" или "кольцо"). ..,.•/ ¦-.' ".$.¦.•¦••.<¦¦. .vy-^ ^
• Уведомление об ошибках — в частности, сообщает протоколам верхних
уровней, что произошла ошибка передачи.
• Упорядочивание кадров — включает переупорядочивание кадров, пере-
переданных вне последовательности. *,., • ¦¦.
• Управление потоком — включает в себя замедление передачи данных,
чтобы получающее устройство не получило больше данных, чем оно
может обработать за один раз. ' '. .>-"»., s
Некоторыми из физических устройств, обычно действующими на
Этом уровне, являются мосты и коммутаторы (хотя некоторые из "интел-
"интеллектуальных" современных коммутаторов способны захватывать и третий
уровень). ¦ _¦ v
Физический уровень ^-'-^"'-¦"."• •••¦••-•*»>¦¦¦¦•-*-й
Первый, физический уровень передает поток данных между машинами.
Как предполагает название, этот уровень содержит средства для соедине-
соединения двух машин. Он связан с электрической, оптической, механической
средой передачи, процедурами или интерфейсами, требуемыми для созда-
создания соединения, будь то физический кабель, инфракрасное соединение, ла-
лазер или другие методы. Физический уровень отвечает за перенос данных,
которые создаются более высокими уровнями.
Этот уровень определяет также, например, как кабель соединяется с
картой сетевого адаптера, число используемых проводов и т.д. Он отвечает
за перенос битов (единиц и нулей) из одного компьютера в другой. Биты не
имеют никакого смысла на физическом уровне, они являются просто еди-
единицами и нулями, электрическими импульсами или вспышками света. Фи-
Физический уровень отвечает за обеспечение того, что когда передается
единица, она будет получена как единица, а не как ноль. Этот уровень опре-
определяет также, что такое единица, как долго длится импульс, какой длины
он должен быть, какой силы и т.п., и таким образом уделяет внимание уров-
уровню напряжения, частоте изменения напряжения, физическим скоростям
данных и максимальным расстояниям, на которые они могут перемещаться.
К этому уровню относятся такие устройства, как повторители (репитеры).

Базовые сетевые модели 13
Проект1ЕЕЕ802 - 7.1.
В то время как ISO работал над моделью OSI, Институт инженеров по элек-
электротехнике и электронике (IEEE) также разрабатывал стандарты LAN. Они
получили известность как проект 802, названный по году и месяцу начала
разработки (февраль 1980 г.). Поскольку эти модели возникли примерно в
одно время, и две организации обменивались между собой информацией,
два стандарта являются совместимыми. Проект 802 определяет стандарты
для физических компонентов сети — кабеля интерфейса и прокладки кабе-
кабеля — которые содержатся в двух первых уровнях модели OSI, физическом и
уровне канала данных. Эти стандарты содержат спецификации для сетевых
интерфейсных карт, компонентов глобальных сетей и компонентов, испо-
используемых для создания коаксиальных сетей и сетей на витой паре. В проек-
проекте 802 существуют двенадцать категорий, перечисленных в таблице 1.1.
Таблица 1.1. Проект 802
Подраздел 802 Название
802.1 Межсетевой обмен
802.2 Управление логическим каналом
802.3 Локальные сети типа CSMA/CD (Ethernet)
802.4 Локальные сети с топологией "шина" и передачей маркера
802.5 ¦ Локальные сети с топологией "кольцо" и передачей маркера
802.6 Городские сети (MAN — Metropolitan Area Network)
802.7 . Техническая консультативная группа по широкополосной сети
802.8 Техническая консультативная группа по волоконной оптике
802.9 Интегрированные сети для передачи голоса/данных
802.10 Обеспечение сетевой безопасности '"¦
802.11 Беспроводные сети ¦
802.12 LAN с доступом по приоритету запроса, 100BaseVg-AnyLan
Усовершенствования, сделанные в модели OSI
Проект 802 делит канальный уровень на две части: подуровень управления
логическим каналом (LLC) и подуровень управления доступом к среде
(MAC). На рис. 1.4 показано, что проект 802 обеспечивает более детальный
подход к стандартам, реализуя подразделы уровня канала данных.
Подуровень управления логическим каналом (LLC)
Подуровень LLC канального уровня управляет коммуникацией между
устройствами, подключенными к одному каналу сети. LLC определяет испо-
использование логических интерфейсных точек, называющихся служебными
точками доступа (Service Access Point, SAP), которые позволяют протоколам

н
Глава 1
7. Уровень приложений
6. Уровень представлений
5. Сеансовый уровень
V •¦ '
4. Транспортный уровень
3. Сетевой уровень
2. Канальный уровень
1. Физический уровень
Управление
логическим каналом
(LLC)
Управление
доступом к среде передачи
(MAC)
Рис. 1.4. Проект 802 IEEE делит канальный уровень на два подуровня,
чтобы предоставить более детальное определение методов доступа к среде передачи
более высокого уровня использовать канал данных. Другие компьютеры так-
также могут обращаться к SAP и использовать их для переноса информации
из подуровня LLC на верхние уровни модели OSI.
Поскольку JJLC находится выше других протоколов 802, он придает всему
стеку большую гибкость, так как протоколы более высокого уровня могут те-
теперь действовать независимо от типа среды передачи, которая расположена
ниже. Однако подуровень управления доступом к среде передачи зависит
от последней и связан со специальными типами протоколов 802.

Базовые сетевые модели 15
В стандарте 802.2 определены две служебные точки доступа (SAP): точка
доступа к службе места назначения (DSAP) и точка доступа к службе источ-
источника (SSAP). LLC обеспечивает поддержку между приложениями для управ-
управления потоком с помощью использования битов готовности/неготовности
и битов управления последовательностью. На рис. 1.5 показано, как эти две
служебные точки доступа выглядят в приложении трассировки Network
Monitor.
¦IXC: UI DSAP-OxEO SSAP=0xE0 С
¦IPX- SAP Packet - 3 0003C7B91A29.4058 -> 3.FFFFFFFFFFFF.452 - 0 Hops
SAP: General Svc Resn fJVH1364 - RPC Serverl
Рис. 1.5. Две служебные точки доступа, определенные в 802.2, отчетливо видны
в сетевом мониторе
Подуровень управления доступом к среде передачи (MAC)
Нижним из двух подуровней канального уровня является уровень MAC, кото-
который предоставляет для платы сетевого адаптера компьютера доступ к физи-
физическому уровню. Подуровень управления доступом к среде общается
непосредственно с картой сетевого адаптера и отвечает за доставку данных
без ошибок между компьютерами в сети. В этой книге мы сосредоточимся на
методе доступа, описанном в стандарте 802.3 — CSMA/CD (множественный
доступ с контролем несущей и обнаружением конфликтов), на котором
основана работа Ethernet.
Чтобы несколько машин могли эффективно организовать совместный
доступ к физическому уровню, они должны быть способны идентифициро-
идентифицировать друг друга с помощью уникальных адресов. Наиболее важной функцио-
функциональностью, предоставляемой уровнем MAC, является уникальный
аппаратный адрес, называемый адресом MAC. Каждый интерфейс LAN
должен иметь адрес MAC. Адрес MAC является 48-разрядным адресом, со-
состоящим из 12 шестнадцатеричных цифр. Первые шесть шестнадцатерич-
ных цифр представляют собой код поставщика (называемый также
уникальным идентификатором организации (OUI)). Эти номера распреде-
распределяются IEEE и могут быть очень полезны для сетевых администраторов,
пытающихся найти драйверы для сетевой карты Etnernet, или при анализе
сети. Последние шесть шестнадцатеричных цифр обычно присваиваются
производителем и часто жестко кодируются в ROM устройства.
Как данные перемещаются по проводам
Чтобы надежно передавать по сетям большие файлы, последние должны
быть разбиты на куски, называемые пакетами. Пакеты являются базовой
единицей сетевой коммуникации. Так как данные делятся на пакеты, то
перегрузка трафика сокращается, а скорость коммуникации возрастает,
поскольку больше компьютеров имеет возможность для доступа к кабе-
кабелю. В каждый пакет вносится специальная информация, которая позво-
позволяет компьютеру разделить данные на фрагменты, собрать их снова

16 Глава 1
вместе и после сборки проверить на наличие ошибок. Фактически пакеты
могут содержать множество различных типов данных, таких как сообщения,
файлы, управляющие данные, команды или запросы служб, управляющие
коды сеансов или сообщения об ошибках.
Все пакеты, независимо от протокола, однотипны и содержат следую-
следующую информацию: адрес источника (машины, отправляющей данные),
адрес назначения (адрес выделенного получателя или получателей),
сами данные, инструкции для различных сетевых компонентов, которые
могут встретиться в пути, служебная информация для контроля ошибок
и упорядочивания.
Поскольку все перечисленные виды информации обязательно должны
присутствовать во всех пакетах, последние состоят по крайней мере из
трех основных разделов. Это заголовок, данные и концевик. В заголовке
можно найти такую информацию, как адрес источника, адрес места назна-
назначения, тип кадра и количество содержащихся в нем данных. Следующий
раздел содержит сами передаваемые данные, количество которых зависит
от типа сети и используемых коммуникационных протоколов. Например,
кадр Ethernet может содержать полезную нагрузку (т.е. собственно данные)
не менее 46 байтов и не более 1500 байтов, но сюда же входит заголовок
TCP и заголовок IP. После удаления накладных расходов максимальный
размер данных оказывается равным 1460 байтам. Содержимое концевика
также зависит от используемого протокола и метода доступа; однако обыч-
обычно там располагается некоторая информация для контроля ошибок (напри-
(например, код CRC). CRC является одним из магических чисел, вычисляемых
при обработке размера пакета с помощью некоторого алгоритма. Эти вы-
вычисления можно воспроизвести, поэтому когда пакет прибывает в место
назначения, получающий компьютер считывает из него значение CRC, по-
повторно выполняет необходимые вычисления и сравнивает полученное зна-
значение CRC с числом, содержащимся в концевике пакета. Если они
совпадают, то пакет считается переданным безошибочно и передается на
следующий уровень модели OSI. Если вычисленное получающим компьюте-
компьютером число CRC не совпадает с числом, содержащимся в пакете, тогда про-
протокол сочтет пакет плохим и отправит запрос на повторную передачу
пакета.
Процесс создания пакета
Как рассматриваемые сетевые модели укладываются в этот процесс и ка-
какую роль они играют? Каждый уровень модели OSI вносит свой вклад в
формат пакета. Процесс создания пакета начинается на уровне приложе-
приложений. Когда созданные там данные необходимо передать на другую машину
в сети, уровень приложений добавляет небольшой объем заголовочной ин-
информации. Оттуда данные переходят на уровень представлений, который
добавит свою заголовочную информацию и затем перешлет пакет на сеан-
сеансовый уровень, также добавляющий свою заголовочную информацию. За-
Затем они переходят на транспортный уровень, где исходные данные
разбиваются на пакеты, которые и будут передаваться по сети. Поэтому ре-
реальный формат пакета зависит от типа используемого транспортного

Базовые сетевые модели 17
протокола. Например, транспортный протокол в составе стека протоколов
TCP/IP — это протокол TCP. В стеке протоколов IPX/SPX протокол транс-
транспортного уровня — это SPX. Каждый из этих транспортных протоколов
управляет пакетами по-своему (более подробно поговорим об этом в следу-
следующих главах). Однако после того как транспортный протокол разбивает
данные на пакеты, он должен снабдить пакеты последовательной нумера-
нумерацией, чтобы принимающий компьютер мог узнать, как собрать их снова,
чтобы восстановить данные. Это произойдет на транспортном уровне при-
принимающего компьютера.
После того как транспортный протокол разобьет данные на пакеты,
они передаются вниз на третий, сетевой уровень модели OSI. Здесь дейст-
действия снова зависят от используемого стека протоколов. В стеке TCP/IP се-
сетевым протоколом является протокол IP, а в IPX/SPX — протокол IPX. В
целом, однако, сетевой уровень добавляет информацию маршрутизации,
информацию об источнике и месте назначения в формате соответствующе-
соответствующего протокола, контрольную сумму, а также информацию о синхронизации.
Канальный уровень также будет добавлять свой заголовок и концевик
CRC. Наконец, пакет попадает на физический уровень, готовый выпол-
выполнить путешествие к месту назначения и содержащий не только полезную
нагрузку данными, но также заголовочную и концевую информацию, добав-
добавленную шестью верхними уровнями, чтобы гарантировать своевременную
и точную доставку данных.
На принимающей стороне пакет передается от физического уровня
вверх вплоть до седьмого уровня приложений, и при этом каждый уровень
удаляет информацию, добавленную соответствующим уровнем передающего
компьютера.
Пакеты адресуются специфическому месту назначения. В большинстве
случаев место назначения является определенным компьютером, серве-
сервером или клиентской машиной. Хотя весь трафик в кабеле виден каждой
карте сетевого адаптера, компьютер не извлекает данные из кабеля, если
они адресованы не ему. Иногда это не так. Например, существуют специа-
специальные виды кадров — широковещательные кадры, которые рассылаются
всем узлам в сети. В этом случае каждый сетевой адаптер будет извлекать
широковещательные сообщения из кабеля и просматривать пакеты. Это
одна из причин изучения способов контроля широковещательного трафика
в главах 5 и 6.
Бывают другие случаи, когда сетевой адаптер может извлекать из кабеля
не предназначенный для него трафик — например, так работают маршрути-
маршрутизаторы. В нашем исследовании сетевого трафика некоторые из файлов
примеров связаны с маршрутизаторами. В этих пакетах необходимо внима-
внимательно отслеживать, что в действительности является истинным источни-
источником и местом назначения. Конечно, все эти вопросы приобретают особую
важность в сети Ethernet, и это ведет нас к следующему разделу.

18
Глава 1
Особенности коммуникации в сетях Ethernet ::
Уровень MAC (нижний подуровень уровня 2 OSI) определяет, как компью-
компьютер будет получать доступ к кабелю и как он будет передавать и принимать
данные. Для этого он общается с физическим уровнем (уровень 1 OSI) че-
через общий интерфейс. Этот интерфейс состоит из базовых служб или фун-
функций, которые управляют обменом данными между подуровнями MAC на
двух различных машинах. При работе через эти интерфейсы подуровень
MAC независим от нижележащей физической среды. Это может быть мед-
медный или оптоволоконный кабель, радиопередача, лазерный или инфрак-
инфракрасный луч. Первым из этих вспомогательных интерфейсов является
сигнализация физической линии. Это подуровень уровня MAC, его основ-
основная функция состоит в управлении доступом к кабелю.
Так как мы рассматриваем Ethernet, используемым методом является
контроль несущей — т.е. компьютер будет следить, когда линия освободит-
освободится. Перед каждой передачей делается проверка, чтобы увидеть, не исполь-
используется ли в данный момент линия. Однако в сети Ethernet отсутствует
сигнал несущей. Как же проконтролировать деятельность? Выяснение
того, что линия не занята, делается с помощью механизма синхронизации
между кадрами данных. Вводится понятие межкадрового промежутка, кото-
который имеет длину 96 бит-периодов (9,6 микросекунды). Межкадровый про-
промежуток является поэтому наименьшим допустимым пробелом между
кадрами данных в сети Ethernet. Сигнализация физической линии будет
также обнаруживать, занята ли линия и имел ли место конфликт. Эти функ-
функции реализованы в части платы Ethernet, называемой трансивером. Рань-
Раньше трансивер был отдельным устройством, но он давно уже реализован как
микросхема на карте Ethernet. Иногда это устройство называют модулем
доступа к среде передачи (MAU — media access unit). Трансивер отвечает за
четыре основные функции. Это передача электрических сигналов по кабе-
кабелю, получение сигналов из кабеля, определение, свободен или занят кабель
и наблюдение за данными с целью обнаружения конфликтов.
Данные передаются в кабель с помощью так называемого манчестер-
манчестерского кодирования (Manchester code). В этом коде первая половина значе-
значения бита содержит дополнительное значение, в то время как вторая
половина содержит реальное значение. Таким образом, каждый посылае-
посылаемый в кабель сигнал является уникальным. Это работает, даже когда пере-
передаются несколько пакетов с идентичной информацией. На рис. 6.1
показан период времени, использованный для передачи информации в
кабель. Время, которое требуется для изменения в кабеле сигнала 1 в О,
называется бит-периодом.
1 бит-период = 100 наносекундам
0
0
0
0
t
0
0
0
Рис. 1.6. Бит-период для Ethernet равен 100 наносекундам

Базовые сетевые модели
19
Так как в сети Ethernet не существует внешнего тактового генератора,
манчестерское кодировние позволяет передатчикам и приемникам син-
синхронизироваться друг с другом. Напряжение в кабеле Ethernet изменяется
от -2.2 до О В, а сила тока — от -90 до 0 мА.
Соединение с физической средой выполняет несколько важных задач, на-
например передачу и получение данных, обнаружение конфликтов и контроль
за длительностью передачи данных. Мы кратко рассмотрим некоторые
из них.
Карта Ethernet должна быть способна принять параллельный поток
данных и передать его в кабель как последовательный поток данных. Это
похоже на ситуацию, когда многополосная скоростная магистраль перехо-
переходит в однополосный мост. Функция передачи не может потерять более
7. Уровень приложений
Взаимодействие сетевых
процессов и приложений
6. Уровень представлений
Представление данных
5. Сеансовый уровень
Коммуникация между хостами
4. Транспортный уровень
Двухточечное соединение
3. Сетевой уровень
Адресация
и оптимальный маршрут
2. Канальный уровень
Доступ к среде передачи
1.Физический уровень
Передача
двоичной информации
Рис. 1.7. Уровень MAC добавляет заголовочную информацию к пакету данных

20 " '"'*ч Глава 1
двух полных ячеек битов. Задержка между ячейками битов должна быть
менее 50 наносекунд. Когда соединение с физической средой получает по-
поток битов, оно не может потерять более пяти ячеек битов. Как же уровень
MAC передает данные? Рассмотрим это немного подробней.
Уровень MAC получает пакет от LLC. Затем он добавляет в пакет следу-
следующую информацию: преамбулу, начальный ограничитель кадра, адрес мес-
места назначения, адрес источника, поле типа (для Ethernet), поле длины и
поле данных с информацией протоколов более высоких уровней. Это пока-
показано на рис. 1.7. Если данные занимают меньше 48 байтов, то поле данных
дополняется нулями до минимальной длины.
После создания пакета данных модуль передачи вычисляет CRC и поме-
помещает ее в поле CRC. Весь пакет передается в модуль передачи MAC. В этом
месте проверяется активность кабеля. Если кабель свободен, то модуль
MAC выжидает межкадровый промежуток (9,6 микросекунд) и передает па-
пакет. Во время передачи модуль MAC проверяет наличие конфликта. Если
конфликтов нет, то передача завершается и можно посылать следующий
кадр. Если возник конфликт, то вызывается функция обработки конфликтов.
Функция обработки конфликтов используется для обнаружения конф-
конфликтов в кабеле. Когда два компьютера передают свои данные одновремен-
одновременно, общее напряжение возникающего конфликта превышает обычное
значение в кабеле, и обнаружившая это машина будет генерировать сигнал
конфликта. Это будет продолжаться в течение девяти бит-периодов, или
900 наносекунд. В течение этого времени машины, пытающиеся исполь-
использовать кабель, будут повторно посылать свои пакеты со случайным интер-
интервалом времени, чтобы избежать нового конфликта. Если отказ происходит
16 раз подряд, то протоколам верхних уровней возвращается ошибка.
Функция контроля длительности передачи данных была введена в стан-
стандарт 802.3, чтобы не давать одной машине возможность монополизировать
кабель. Каждая машина может использовать кабель не более 30 миллисекунд
за один раз и должна предоставить после этого другой машине возможность
использовать кабель. Если машина не прервет передачу в течение этого вре-
времени, то карта предполагает, что это слишком длинная передача, и должна
ее прекратить.
Уровень MAC отвечает также за получение данных из кабеля. Весь тра-
трафик виден в кабеле, но только пакеты, адресованные локальной машине,
обрабатываются уровнем MAC. Если пакет не адресован локальной маши-
машине, то она просто отбрасывает пакет данных. Однако когда пакет получен
из кабеля, то прежде всего необходимо проверить его на наличие ошибок.
Это делается модулем MAC, проверяющим значение CRC. Если пакет не
выдерживает этой начальной проверки, он отбрасывается как мусор. Когда
пакет прошел проверку CRC, уровень MAC начинает процесс удаления пре-
преамбулы, начального ограничителя пакета, адреса места назначения, адреса
источника, поля типа и заполнения, которое могло быть добавлено в поле
данных, чтобы он удовлетворял требованиям минимального размера. По-
После того, как это сделано, выполняются две дополнительные проверки па-
пакета. Уровень MAC будет проверять, имеет ли поле данных правильную
длину и является ли кратным восьми битам. Если обе эти дополнительные

Базовые сетевые модели 21
проверки проходят успешно, данные объявляются неповрежденными и пе-
передаются вверх по уровням протокола. Если пакет не выдерживает любую
из этих проверок, он объявляется мусором и отбрасывается, а процесс дол-
должен начинаться заново. . ,. j . ... .. ¦ .
Какова во всем этом роль протоколов? : .
Можно представлять себе протоколы как языки. Например, во Франции луч-
лучше говорить по-французски. Если вы, скажем, попытаетесь найти общий
язык с французом при помощи греческого языка, то у вас мало что получит-
получится. Разумеется, всегда есть небольшая вероятность, что ваш собеседник тоже
владеет греческим, но рассчитывать на это нельзя. Подобным же образом,
протоколы у двух компьютеров, которые собираются общаться, должны сов-
совпадать. Так же, как существуют правила функционирования языков — напри-
например, согласование подлежащего и сказуемого, существуют правила для
работы протоколов.
У каждого протокола свой набор поддерживаемых команд, каждая из
которых имеет определенное назначение. Подобно тому как в любом язы-
языке существует различие между устной и письменной речью, есть различия
в том, как функционируют протоколы. Так же, как существует много язы-
языков, есть много протоколов. На всех уровнях модели OSI работают раз-
различные протоколы, используемые для разных целей. Когда несколько
протоколов работают вместе на различных уровнях модели OSI, они на-
называются стеком протоколов. Сеть охватывает все уровни модели OSI. Та-
Таким же образом стек протоколов включает в себя протоколы, которые
работают на различных уровнях модели OSI.
Стек протоколов " .<•.¦¦ > ¦ < и ,г
Протоколы управляют коммуникацией между двумя или несколькими маши-
машинами в сети. Существует множество различных протоколов, которые могут
использоваться для управления обменом информацией между машинами в
сети. Протоколы определяют, как они собираются взаимодействовать, как и
когда пользователю разрешается передавать данные, как сообщается об
ошибках, сколько данных можно послать за один раз. Без этих правил комму-
коммуникация в сети была бы невозможна. В зависимости от того, на каком уровне
протокола OSI должен действовать протокол, он может быть связан с разби-
разбиением данных на достаточно маленькие фрагменты для передачи через ка-
кабель на другой компьютер. При этом он должен знать, на сколько частей
разбить данные, в каком порядке их передавать, как снова собрать их вместе
и убедиться, что они прибыли в правильном порядке и в том же виде, в ка-
каком передавались. Ему необходимо также знать расположение машины, куда
предположительно направляются данные, и путь к ней. Кроме того, он дол-
должен знать, как общаться с картой Ethernet, чтобы действительно передать
данные в кабель.
На принимающем компьютере протокол осуществляет некоторые из
тех же действий, что и передающий компьютер, только в обратном поряд-
порядке. Прежде всего, он должен распознать адресованный компьютеру пакет.
Затем он должен извлечь данные из кабеля и поместить их в компьютер

22 Глава 1
с помощью карты Ethernet. Протоколы должны восстановить данные в пер-
первоначальном порядке и, наконец, представить информацию приложению,
чтобы оно могло работать с содержимым пакта.
Как можно видеть из приведенного выше примера, в эту простую тран-
транзакцию вовлечено много уровней модели OSI. Протокол уровня приложе-
приложений общается с протоколом уровня приложений на другой машине, уровень
представлений общается с уровнем представлений на другой машине, сеан-
сеансовый уровень отвечает за установление соединения, транспортный уровень
отвечает за доставку на другую машину данных, а сетевой уровень находит
маршрут к месту назначения, уровню LLC и физическим уровням.
Таким образом, чтобы выполнить свои задачи, каждый уровень добавля-
добавляет информацию к основному пакету информации для целей отслеживания.
Посылающая машина добавляет служебную информацию, по мере того как
информация перемещается с уровня приложений на физический уровень.
Когда машина получает данные из кабеля на первом уровне, она удаляет до-
добавленную информацию на каждом уровне по мере ее перемещения на уро-
уровень приложений. Уровень представлений затем представляет собранные
данные уровню приложений в используемом формате.
Необходимо помнить, что протоколы должны поддерживать маршрути-
маршрутизацию. Хотя сегодня ситуация изменилась, в прошлом это было проблемой.
Например, NETBEUI является быстрым протоколом, подходящим для небо-
небольших рабочих групп, но он не маршрутизируется и поэтому не очень хоро-
хорошо подходит для решений уровня предприятия. Конечно, существуют и
другие причины, по которым можно отказаться от использования NETBEUI
в WAN, но они будут рассмотрены позже. Есть несколько способов перемес-
переместить данные из одной LAN в другую LAN через соединяющий их маршрути-
маршрутизатор. Определять, как это сделать — функция протоколов третьего уровня.
Иерархический подход ' "'' ; ^ 'ЧК! ; ^ ; s
Чтобы в сети была коммуникация необходимо решить много задач. Но
важно понимать, что происходит в сети, чтобы вести поиск неисправно-
неисправностей. Стек протоколов использует подход на основе иерархии уровней.
Есть по крайней мере четыре причины для использования такого подхода.
Это уменьшает сложность, стандартизует интерфейсы, облегчает модуль-
модульное проектирование и гарантирует взаимодействующую технологию.
Информация должна быть подготовлена, переслана, получена и обрабо-
обработана. Различные протоколы, выполняющие эту рутинную работу, являются
темой обсуждения оставшейся части главы. Способ, который они совместно
используют при обработке задачи пересылки данных из одной машины в
другую, называется иерархическим представлением сети. Стек протоколов
является комбинацией протоколов, и каждый уровень стека имеет свою фун-
функцию, которая реализуется отдельным протоколом и правилами, управляю-
управляющими тем, как он ведет себя в различных ситуациях. Каждый уровень имеет
свои собственные обязанности. Как мы видим на рис. 1.8, каждый уровень
выполняет определенные обязанности, задачи и обязательства.
Каждый уровень общается с протоколом на уровне выше и ниже его в
стеке, но не знает о других протоколах. Таким образом, протоколы способны

Базовые сетевые модели
23
7. Уровень приложений
6. Уровень представлений
Взаимодействие сетевых О.
процессов и приложений
:¦!¦• :¦''' .'(' ¦;'.". {,¦. ' ¦,..•''
Представление данных :"
5. Сеансовый уровень
Коммуникация между хостами
4. Транспортный уровень
Двухточечное соединение
3. Сетевой уровень
Адресация
и оптимальный маршрут
2. Канальный уровень
Доступ к среде передачи
1. Физический уровень
Передача
двоичной информации
Рис. 1.8. Каждый уровень выполняет свою работу, будто бы игнорируя
существование других протоколов
получить виртуальную коммуникацию между уровнями на различных
машинах. Например, приложение считает, что оно общается с уровнем
приложений на другой машине.
Нижние уровни модели определяют, как производители оборудования де-
делают возможным для своих продуктов соединяться с сетью и с компьютерами,
с которыми они связаны. Верхние уровни определяют, как приложения будут
общаться друг с другом, правила их коммуникации и исправление ошибок.
Чем больше уровней в стеке протоколов, тем более сложными становятся
задачи и протоколы.

Глава 1
Как все это объединяется? ^ s ^ , -: ]
Все эти вещи объединяются с помощью процесса, называемого связыванием.
Он предоставляет нам большую гибкость, так как теперь протокол и плата
сетевого адаптера являются независимыми, поэтому можно менять стек
протоколов без изменения драйвера сетевого адаптера. Можно также изме-
изменять методы доступа к среде, не изменяя при этом протокол. Поэтому мож-
можно использовать TCP/IP через Ethernet, token-ring или любой другой
метод, выбранный для реализации. Кроме того, если имеется несколько
сетевых адаптеров, то можно связать протокол с одним из них или со все-
всеми, как будет необходимо. Не имеет значения, как их связывать, по край-
крайней мере, на работу протокола это не влияет. Однако может понадобиться
уделить внимание порядку связывания протоколов (см. ниже).
Netwoik
Identification I Services 1 Protocols I Adapters Bindings
Network bindings are connections between network cards,
protocols, and services installed on this computer. You cart use this
page to disable netwoik bindings or arrange the order in which this
computer finds information on the network.
Show Bindings for: I all services
E S Microsoft DHCP Server
В S NetBIOS Interface
1 WINS Client(TCP/IP)
Ё S Network Monitor Agent
Щ} Я Remote Access Server Service
13 S Server 'гч-)>:,-
Й Я Workstation
Enable
Disable
Move Up Move Down
OK
Рис. 1.9. В операционной системе Windows NT для оптимальной производительности
порядок связывания можно сконфигурировать вручную

Базовые сетевые модели
Порядок связывания — это порядок, в котором компьютер будет исполь-
использовать протоколы при попытке коммуникации с другими машинами в сети
или в мире. Поэтому порядок, в котором протоколы связаны с платой сете-
сетевого адаптера, определяет порядок, в котором они будут пытаться общать-
общаться друг с другом. Этот порядок в Windows NT можно определить вручную,
как показано на рис. 1.9.
Процесс связывания применяется не только к стеку протоколов и сетево-
сетевому адаптеру; например, драйвер платы Ethernet должен быть связан с платой
Ethernet, а транспортный протокол также должен быть связан с уровнем
сеанса NetBIOS, расположенным выше него в стеке.
Существует несколько стеков протоколов, разработанных в течение
ряда лет. Некоторые из них перечислены ниже:
1. Стек протоколов ISO/OSI
2. IBM System Network Architecture (SNA) *
3. Digital DECnet : . .
4. Novel Netware
5. Apple AppleTalk
6. Стек протоколов Интернета, или TCP/IP
В каждом из этих стеков существуют собственные протоколы для раз-
различных уровней модели OSI. Отдельный протокол в составе стека может
охватывать один или несколько уровней, но полный набор протоколов вы-
выполняет все необходимые функции всех семи уровней. В данный момент
полезно сгруппировать некоторые из этих уровней функциональности по
областям обслуживания, как показано в таблице 1.2. Можно выделить три
области функций: приложения, транспорт и сеть.
Таблица 1.2. Модель 0SI предоставляет три важные службы
Уровень Уровень OSI
Предоставляемая функциональность
Семь
Шесть
Пять
Четыре
Три
Два
Один
Приложения
Уровень представлений
Сеансовый уровень
Транспортный уровень
Сетевой уровень
Канальный уровень
Физический уровень
Прикладные службы, сетевые службы
Прикладные службы, сетевые службы
Прикладные службы, сетевые службы
Транспортные службы
Сетевые службы
Сетевые службы
Сетевые службы

26 Глава 1
Прикладные протоколы *
Теперь можно поговорить о прикладных, транспортных и сетевых прото-
протоколах. Прикладные протоколы охватывают верхние три уровня модели
OSI, т.е. уровни приложений, представлений и сеансовый. Они обеспечи-
обеспечивают взаимодействие и обмен данными между приложениями. Некоторые
из распространенных прикладных протоколов перечислены ниже:
1. АРРС (Advanced Program-to-Program Communication), одноранговый
протокол из стека IBM SNA, используемый в основном для систем
AS/400.
2. FTAM (File Transfer Access and Management), протокол доступа к файлам
из стека OSI.
3. Х.400, протокол CCITT для международной передачи электронной
почты. ..-.-.*¦. ,.,.»¦>.,¦ -.; .. Л
4. Х.500, протокол ССПТ для служб файлов и каталогов на нескольких
системах.
5. SMTP (Simple Mail Transport Protocol), протокол пересылки
электронной почты из стека TCP/IP. ''v ¦
6. FTP (File Transfer Protocol), протокол пересылки файлов из стека
TCP/IP.
7. SNMP (Simple Network Management Protocol), протокол мониторинга
сетей и сетевых компонентов из стека TCP/IP.
8. Telnet, протокол Интернета для дистанционного подключения
к удаленным хостам и локальной обработки удаленных данных. . > ~
9. Microsoft SMB (Server Message Blocks) и клиентские оболочки
или редиректоры Microsoft.
10. NCP (Novell Netware Core Protocol) и клиентские оболочки
или редиректоры Novell.
11. AppleTalk и Appleshare компании Apple.
12. AFP, протокол AppleTalk удаленного доступа к файлам.
13. DAP (Data Access Protocol), протокол доступа к файлам DECnet.
Транспортные протоколы
Транспортные протоколы располагаются на четвертом, среднем уровне
модели OSI. Они предоставляют коммуникационные сеансы для обеспече-
обеспечения надежного перемещения данных между компьютерами. Популярные
транспортные протоколы перечислены ниже: . .. .......
1. TCP (Transmission Control Protocol), протокол TCP/IP
для гарантированной доставки последовательных данных.

Базовые сетевые модели 27
2. SPX (Sequential Packet Exchange), транспортная часть стека протоко-
протоколов IPX/SPX для передачи последовательных данных.
3. NWLink, реализация IPX/SPX от Microsoft.
4. NetBEUI (расширенный интерфейс пользователя NetBIOS) создает
коммуникационные сеансы между компьютерами и предоставляет
нижележащие службы транспорта данных. ., . .......
5. Протокол ATP (AppleTalk Transaction Protocol) из стека AppleTalk,
протокол связывания имен NBP и протоколы транспорта данных.
Сетевые протоколы
Сетевые протоколы предоставляют так называемые службы канала данных
и составляют нижние три уровня модели OSI. Эти протоколы обрабатыва-
обрабатывают информацию адресации и маршрутизации, контроль ошибок и запросы
повторной пересылки. Сетевые протоколы определяют также правила для
коммуникации в сетевом окружении, таком как Ethernet или Token Ring.
Наиболее популярные сетевые протоколы перечислены ниже:
1. IP (Internet Protocol), протокол TCP/IP для маршрутизации "¦
и пересылки пакетов. . .
2. IPX (Internetwork Packet Exchange), протокол NetWare для пересылки
пакетов и маршрутизации.
3. NWLink, реализация Microsoft протокола IPX/SPX.
4. NetBEUI, транспортный протокол, который предоставляет службы
транспорта данных для сеансов NetBIOS и приложений.
5. DDP (Datagram Delivery Protocol), протокол транспорта данных
AppleTalk. , . , .
Мы увидели, как эти протоколы укладываются в модель OSI, и получили
представление о функциях каждого из них. Теперь следует рассмотреть,
как все это отображается в совокупности, после чего можно исследовать
различия в поведении этих протоколов, как используется каждый из них,
а также различные уровни функциональности.
Сетевая служба с поддержкой соединения ',''""."'
Сетевая служба с поддержкой соединения включает три фазы:
• Создание соединения - во время фазы создания соединения опреде-
определяется единственный маршрут между исходной и целевой системами.
Сетевые ресурсы в это время обычно резервируются, чтобы гаранти-
гарантировать согласованный уровень службы (например, гарантированную
пропускную способность).

28 Глава 1
• Пересылка данных — во время фазы пересылки данные последовате-
последовательно передаются по определенному на предыдущем этапе маршруту.
Данные всегда приходят в целевую систему в том порядке, в котором
были посланы.
• Прекращение соединения — во время фазы прекращения соединения
созданное соединение, которое больше не требуется, прерывается.
Дальнейшая коммуникация между исходной и целевой системами тре-
требует создания нового соединения.
Служба с поддержкой соединения имеет два существенных недостатка
по сравнению с сетевыми службами без поддержки соединения:
• Статический выбор маршрута — так как весь трафик должен переме-
перемещаться по одному и тому же статическому маршруту, отказ в какой-либо
точке этого маршрута вызывает отказ соединения.
• Статическое резервирование сетевых ресурсов — гарантированный
уровень пропускной способности требует привлечения ресурсов, не
предназначенных для других пользователей сети. Если для коммуни-
коммуникации требуется полная непрерываемая пропускная способность, то
полоса пропускания используется неэффективно.
Службы с поддержкой соединения используются для передачи данных при-
приложений, которые нетерпимы к задержкам и переупорядочиванию пакетов.
Приложения для голоса и видео обычно используют службы с поддержкой
соединения.
ч
Сетевая служба без поддержки соединения
Сетевая служба без поддержки соединения не определяет заранее маршрут
от источника к системе назначения, упорядочивание пакетов, пропускную
способность канала данных и другие гарантированные сетевые ресурсы.
Каждый пакет должен быть снабжен полным адресом, так как для различ-
различных пакетов на основе множества факторов могут выбираться различные
пути доступа через сеть. Каждый пакет передается исходной системой неза-
независимо и независимо обрабатывается промежуточными сетевыми устрой-
устройствами. Служба без поддержки соединения предлагает два важных
преимущества относительно службы с поддержкой соединения:
• Динамический выбор маршрута — так как маршруты выбираются для
каждого пакета отдельно, трафик можно направить в обход сбойного
участка сети.
• Динамическое выделение полосы пропускания — полоса пропускания
используется более эффективно, поскольку сетевым ресурсам не выде-
выделяют полосу пропускания, которую они не собираются использовать.
Службы без поддержки соединения используются для передачи данных
приложений, которые могут выдержать некоторую задержку и переупоря-
переупорядочивание. Приложения, передающие данные, обычно используют службу
без поддержки соединения.

Базовые сетевые модели 29
Адресация на канальном уровне и? is? н г ./
Адрес канального уровня уникальным образом идентифицирует каждое фи-
физическое соединение сетевого устройства с сетью. Адреса канального уровня
иногда называются физическими или аппаратными адресами. Обычно они
образуют неиерархическое адресное пространство, задаются для каждого
устройства заранее и, как правило, жестко. Оконечные системы имеют
обычно только одно физическое сетевое соединение и, стало быть, только
один адрес канального уровня. Маршрутизаторы и другие устройства, под-
поддерживающие межсетевой обмен, обычно имеют несколько физических
сетевых соединений и несколько адресов канального уровня.
Адреса подуровня управления доступом к среде передачи (MAC) являют-
являются подмножеством адресов канального уровня. Адреса MAC идентифициру-
идентифицируют сетевые устройства в LAN, реализующие подуровень IEEE MAC
канального уровня. Как большинство адресов канального уровня, адреса
MAC являются уникальными для каждого интерфейса LAN. Адреса MAC
имеют 48 битов в длину и выражаются с помощью 12 шестнадцатеричных
цифр: первые шесть шестнадцатеричных цифр являются идентификацией
производителя (или кодом поставщика), называемым уникальным иденти-
идентификатором организации (ОШ). Эти шесть цифр устанавливаются IEEE.
Последние шесть шестнадцатеричных цифр являются серийным номером
интерфейса или другим значением, администрируемым определенным по-
поставщиком. Адреса MAC иногда называются аппаратными или "зашитыми"
адресами (Burned-in Address, BIA), так как они выжжены в постоянной па-
памяти (ROM) и копируются в оперативную память (RAM), когда инициали-
инициализируется плата интерфейса.
Адресация на сетевом уровне
Адрес сетевого уровня идентифицирует устройство сетевого уровня эталон-
эталонной модели OSI. Сетевые адреса существуют обычно в иерархическом адрес-
адресном пространстве. Иногда их называют виртуальными или логическими
адресами. Отношение сетевого адреса с устройством является логическим и
нефиксированным. Обычно адрес основывается либо на характеристиках
физической сети (устройство находится в определенном сетевом сегменте),
или на логическом объединении, которое не имеет физической основы
(устройство является частью зоны AppleTalk). Оконечным системам требу-
требуется один адрес сетевого уровня для каждого протокола сетевого уровня, ко-
который они поддерживают. (Это предполагает, что устройство имеет только
одно физическое сетевое соединение.) Маршрутизаторы и другие устройст-
устройства, поддерживающие межсетевой обмен, требуют один адрес сетевого уров-
уровня на каждое физическое соединение для каждого поддерживаемого
протокола сетевого уровня. Например, маршрутизатор с тремя интерфейса-
интерфейсами, каждый из которых поддерживает одновременно AppleTalk, TCP/IP и
OSI, должен иметь три адреса сетевого уровня для каждого интерфейса.
Поэтому маршрутизатор имеет девять адресов сетевого уровня.

30
Глава 1
Инкапсуляция данных ?н оцу &'"¦ hsn-> &* *n>
Каждый уровень модели OSI общается с нижележащим уровнем и зависит
от него в обеспечении специальных служб и функциональности. Так как
каждый уровень предоставляет службу, он добавляет информацию к дан-
данным приложения, чтобы можно было транспортировать информацию к
машине места назначения. Конечно, добавленная специальная информация
зависит от используемого стека протоколов, но, следуя общей модели, мы
видим, что каждый уровень добавляет к данным заголовочную информацию,
а в отдельных случаях также и концевик после данных, пока не будет полу-
получен аккуратно сформированный пакет, который отправляется в кабель.
7. Уровень приложений
6. Уровень представлений
5. Сеансовый уровень
4. Транспортный уровень
3. Сетевой уровень
2. Канальный уровень
1. Физический уровень
Заголовок уровня приложений - данные
'¦I.K.- . •¦,!.!¦ ¦ I, ' ,-Us' I ';•¦.'( Г V
Заголовок уровня представлений - данные
¦:¦¦ ;., ' . uiiil--! 1 ,;,.:,: ,.
Заголовок сеансового уровня - данные
Заголовок транспортного уровня -данные
;¦!.*,-¦ 1( I'.' ¦ ,¦ )¦ •!¦¦/¦"! ..-.¦¦¦ т.... ¦
Заголовок пакета - данные
Заголовок кадра - данные
0101101010110001
ч
7. Уровень приложений
•Л.. ¦-:.; ^ ^
6. Уровень представлений
5. Сеансовый уровень
4. Транспортный уровень
N.
3. Сетевой уровень
\ \
2. Канальный уровень
1. Физический уровень
Ч N
Рис. 1.10. Заголовочная информация, добавленная на передающем компьютере,
удаляется на том же уровне на принимающем компьютере

Базовые сетевые модели 31
Как показано на рис. 1.10, каждый уровень добавляет заголовочную ин-
информацию, чтобы выполнить службу, требуемую приложению. Когда дан-
данные перемещаются вниз по модели OSI на посылающем компьютере, эта
информация добавляется. На получающем компьютере заголовочная и
концевая информация отбрасываются, когда данные перемещаются вверх
по модели OSI.
Можно насчитать пять шагов, связанных с процессом инкапсуляции
данных, когда они готовятся транспортным уровнем для отправки в кабель.
Они перечислены ниже:
1. С верхних уровней получена информация от пользователя, напри-
например запрос регистрации на сервере, задание печати или поиск в Web.
Информация преобразуется в данные, чтобы ее можно было транс-
транспортировать к месту назначения.
2. Данные подготовлены для транспортировки на целевой компьютер.
В случае TCP к данным добавляется заголовок TCP, содержащий ин-
информацию об упорядочивании, помогающую сохранить все в порядке
при преобразовании в сегменты. - ч •
3. На третьем уровне модели OSI находится протокол IP. Здесь будет
добавлен заголовок IP, так как сегмент TCP преобразуется в пакет IP.
Заголовок IP включает IP-адреса источника и места назначения, что
поможет при маршрутизации (выполняемой на этом уровне модели
OSI) пакета в соответствующее место назначения.
4. На уровне канала данных в нашем примере пакеты IP преобразуются
в кадры Ethernet. Чтобы сетевое устройство могло общаться через
локальный интерфейс с другим интерфейсом в сети, оно должно по-
поместить пакет в кадр. Тип кадра должен совпадать, иначе устройства
не смогут общаться. В примерах трассировок мы увидим, что кадры
Ethernet создаются вокруг пакетов IP.
5. Теперь кадр Ethernet превращается в единицы и нули. Как говорилось
ранее, эти биты перемещаются по сети особым образом, определен-
определенным методами доступа, пока не достигнут своего места назначения.
Реализация IP поверх различных стандартов LAN
По мере совершенствования нашего мастерства в поиске неисправно-
неисправностей нам понадобится понимание инкапсуляции LAN. Технологии LAN
охватывают такие технологии настольных компьютеров, как Ethernet,
Token Ring и Arcnet, и технологии MAN, например FDDI. В таких техно-
технологиях, как Ethernet могут существовать несколько типов инкапсуляции,
что вызывает некоторые проблемы взаимодействия. В каждой из этих
технологий дейтаграммы IP необходимо разграничивать, адресовать и
идентифицировать как дейтаграммы IP.

32
Глава 1
Ethernet II При пересылке через сеть Ethernet дейтаграммы IP испо-
используют либо инкапсуляцию Ethernet II, либо IEEE 802.3 SNAP. Инкапсуля-
Инкапсуляция Ethernet II использует двухбайтовое поле типа для обозначения
протокола верхнего уровня. У этого поля два значения: 0x08-00 соответст-
соответствует IP, a 0x08-06 соответствует ARP.
Дейтаграммы IP, посылаемые в составе кадров Ethernet II, имеют макси-
максимальный размер 1500 байтов и минимальный размер 46 байтов. Дейтаграм-
Дейтаграммы IP размером меньше 46 байтов дополняются нулями до 46 байтов,
чтобы сохранить минимальный размер кадра Ethernet, равный 64 байтам
(не включая преамбулу).
Как можно видеть на рис. 1.11, кадр Ethernet II состоит из преамбулы,
за которой следует адрес места назначения, адрес источника, поле типа,
полезная нагрузка и, наконец, контрольная последовательность кадра.
Netwmt Menu» ¦ |G:\ch«t<foelwork cap IDetatfll
Fra»e
1 0?S
I 076
1 076
1 077
1 073
Src «AC Add
Д1Н_В"ГИГ"
3COM CBDC4
JWH_B* EX
3COM CBDC4
JKH ЗА EX
Dst MAC Add:
ЗСбМ "CBOCV
J«H_BA_EX
3COM CBDC4
JVH_BA_EX
3CCM CBDC4
Protect, ,^_- -„
ARP RAHAR? Reply. Taxget IP
SKB С close file. FID
SXB
SHB
SXB
Я close file
С tree disconnect
disconn
11.0.0 49 Target Hdvr Addr
0xd802
loTcJ
J
-ETHERNET Destination address 00805FA63A32
ETHERNET 0 • Individual address
ETHEHHET 0 ¦ universally ad»lnistered address
-ETHERNET Source address 00608ССЮС4 3 \
ETHERNET 0 • No routing information present
ETHERNET 0 ¦ Universally edmnistered address
ETHERNET Fra»e length 60 (ОхООЗС)
ETHERNET Ethernet Type 0x0800 (I? COD Internet Protocol)
ETHERNET Ethernet Data Kuxber of data bytes returning • 46 @x002E)
¦ IP ID - 0xH9; Proto ¦ TCP. len 40
¦TCP A . len 0. seq 16SS72S-USS72S. ack 3143336. vin 8613. src 1025 dst 13»
00000000 liliMiM*T.Wcbai|l»:tiM:b»:Bfr»MiT«Iil4 5 00
00009010 00 28 01 69 40 00 20 06 42 6? 0B 00 60 31 0B 00
00000020 00 C9 04 01 00 68 00 19 43 AD 00 2F F6 A8 SO 10
00000030 21 AS 38 ОС 00 00 00 00 00 00 00 00
f
K8
Bn
a
|FB. 11/78
JOll 0(«0|
Рис. 1.11. Кадр Ethernet II инкапсулирует дейтаграмму IP
IEEE 802.3 SNAP Инкапсуляция IEEE 802.3 SNAP также начинается с
преамбулы, адреса места назначения и адреса источника, однако дальше
SNAP 802.3 расходится с инкапсуляцией Ethernet П. На рис. 1.12 показано,
что для инкапсуляции дейтаграммы IP имеется поле длины и заголовок
протокола доступа к подсети (SNAP), чтобы его можно было послать по
сети, поддерживающей IEEE 802.3. Заголовок IEEE 802.3 использует опре-
определенное значение ОхАА для полей точки доступа службы места назначения

Базовые сетевые модели
33
Nelmxk Monilot - |6:\clu№metMMk.cap (Sunaajfll
?? Ffe ?d< С:'=Р'ЗД loci; рКют Wind»»
10 072 13COM CC0B5l«BRQADCAST IARP. RAfiUR? Request Targe
IP
11 0 0 205
0 932 JVH1364 «BROADCAST
0 970
1 001
1 075
1 0?S
00609777CB6
JVH BA_EX
3COX CBDC4
JUH BA EX
BROADCAST
•BROADCAST
•BROADCAST
3COM C8DC4
ГОР
ARP RAFJAEP
ARP~RAS ARP
ARP RAH ARP
FJWH1364 - RPC Serverl
3
4
5
6
,| ^ ,,,„,., ,.-,,.„4, .„¦,...,'.. ..HTf*. у,
¦FRAHE Base Sra«e properties
-ETHERKET 802.3 length • 114
"•ETHERNET Destination address FFFFFFFFFFFF
ETHERNET . 1 • Group address
ETHERKET 1 • locally administered address
-ETHERNET. Source address 0006C7B91A29
ETHERKET 0 " No routing inforMation present !
ETHERNET 0 ¦ Universally ad»inistered address
ETHERKET Fra»e Leagth ¦ 114 @x0072)
ETHERHET Data Length 0x0064 A00)
ETKERKET Ethernet Data Kuiber of data bytes remaining • 100 @x0060
¦ L1C UI DSAP-.lxEO SSAP-OxED С
¦IPX SAP Packet - 3 0008С7Э91Д29 4056 -> 3 FFFFFFFFFFFF 452 - 0 Hops
Dst Port
IP Multicast Src Port Unknown. B301)
Request Target IP 11 0 1 3
Request Target IP 11 0 0 201
Reply Target IP 11 0 0 49 Target Hdvr Addr 006C
«I
00000000
00000010
00000020
00000030
00000040
00000050
00000060
00000070
FF FF FF FF FF FF 00 08 C7 B9 11 29 00 64 E0 E0
03 FF FF 00 60 00 04 00 00 00 03
FF 04 52 00 00 00 03 00 08 C7 Ё9
FF FF FF FF FF
29 40 е
II ) da»
0! 06 J0 4k 57 48 3J 33 3b 34 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 03 00 08 C7 B9 1A 29 E3 85 00
L 67 ИЗ)
Рис. 1.12. Инкапсуляция SNAP IEEE 802.3 включает немного больше накладных
расходов, чем кадр Ethernet II
(DSAP) и точки доступа службы источника (SSAP), чтобы выделить кадр
SNAP. Управляющий код 0x03 идентифицирует ненумерованный кадр.
Поле кода организации задается равным 0x00-00-00, а дальше следует поле
типа: 0x08-00 для IP и 0x08-06 для ARP — такое же, как в типе кадра Ethernet П.
Дейтаграммы IP, посланные в составе кадров SNAP IEEE 802.3, имеют
максимальный размер 1492 и минимальный размер 38 байтов. Это слегка
отличается от ограничений размера Ethernet II и отражает больший раз-
размер накладных расходов инкапсуляции 802.3 SNAP. Дейтаграммы IP мень-
меньше 38 байтов в длину дополняются нулями, чтобы сохранить минимальный
размер кадра Ethernet, равный 64 байтам (не включая преамбулу и начальный
ограничитель).
Сравнение Ethernet II и IEEE 802.3 В нормальной повседневной сети
действительно возможно присутствие Ethernet II и IEEE 802.3. Дело в том,
что стандарты TCP/IP требуют, чтобы все хосты могли посылать и полу-
получать инкапсулированные кадры Ethernet II. Кроме того, большинство хос-
хостов могут получать инкапсулированные пакеты IEEE 802.3. Некоторые
хосты в сети могут одновременно посылать и получать пакеты IEEE 802.3.
В таком случае, однако, по умолчанию должен использоваться тип Ethernet П.
На рис. 1.13 одновременно показаны пакеты IEEE 802.3 и Ethernet II, поэтому
можно получить хорошее представление о различиях между двумя методами
инкапсуляции.

34
Глава 1
dtp* E* СОД Xoob 2«иге tfndow
¦FRAME: Base frame properties
-ETHERNET Destination address FFFFFFFFFFrT
ETHERNET 1 - Group address
ETHERHET .1 ¦ Locally administered address ' .
-ETHERNET Source address 0008C7B9U29 •
ETHERHET . . 0 • No routing information present
ETHERNET 0 • Universally administered address
ETHERNET Frame length : 114 @x0072)
ETHERHET Data length 0x0064 A00)
ETHERNET Ethernet Data Number of data bytes remaining ¦ 100 @x00D)
¦LLC UI DSAP-0xE0 SSAP-OxEO С
¦ IPX SAP Packet - 3. 0008C7B«A?9 4058 -> 3. FFFFFFFFFFFF 452 - 0 Hops
¦SAP General Svc Sesp (ЛИНПЫ - RPC Server)
Nelmxk Hondo)
¦FRAME: Base fraxe properties
ETHERHET ETYPE • 0x0800 Protocol
POP Internet Protocol
-ETHERNET: Destination address a0B0SFAb3A32
ETHERNET D • Individual address
ETHERNET: 0 ¦ Universally administered address
i -ETHERNET Source address : 00608CCBDC43
I ETHERHET' 0 • Ho routing information present '-' -*' -. - '
i ETHERHET: . . .. 0 • Universally administered address
. ETHERHET- Frame length : 60 (ОхООЗС)
ETHERHET Ethernet Type : 0x0800 (IP: DOD Internet Protocol)
; ETHERHET Ethernet Data: Number of data bytes remaining ¦ 46 @x002E)
¦IP: ID ¦ 0x169. Proto - TCP. Ian «0
¦TCP A . len 0. seq 16SS72S-16SS725. ack 3143336. »in 8613. »rc: 1025
F»: \
тощ
\
i
dst 139
I
Е1Ь«тМ/вО2 3 MAC Laua
вьош
Рис. 1.13. Сравнение IEEE 802.3 и Ethernet II
Ethernet II используется по умолчанию для большинства сетей. Как мож-
можно видеть на рис. 1.13, оба формата кадров имеют шестибайтовые D8 битов)
адреса места назначения и источника. Это адрес MAC, адрес Ethernet или ап-
аппаратный адрес хоста, который физически соединен с сетью. Эти адреса
преобразуются в четырехбайтовые C2 бита) IP-адреса с помощью протокола
преобразования адресов ARP, который будет рассмотрен в следующей главе.
В заголовке Ethernet II следующие два байта используются для указания
типа @x08-00 для IP, 0x08-06 для ARP). Это то же самое поле, которое позже
встретится в кадре 802.3 точно перед началом части данных в кадре. Кадр
IEEE 802.3 имеет вместо типа двухбайтовое поле длины. Оно не имеет соот-
соответствия в кадре Ethernet II, позволяя тем самым отличить эти два метода
инкапсуляции кадра. За полем типа в заголовке Ethernet II следует часть
кадра с данными с размером от 46 до 1500 байтов.
В методе инкапсуляции IEEE 802.3 после адресов места назначения и ис-
источника находится двухбайтовое поле длины. Это поле используется для
указания, сколько дальше следует байтов, но не включая CRC в конце кад-
кадра. После поля длины следует раздел, определенный главой 802.2 проекта
IEEE. Первые три поля в этом разделе являются полями LLC. Поля DSAP и
SSAP всегда заданы как АА, а контрольное поле всегда задано как 03. В сле-
следующих пяти байтах данных SNAP код организации задан как 0x00-00-00,

Базовые сетевые модели 35
что требует трех байтов. Следующие два байта формируют поле типа, кото-
которое является таким же, как поле типа, имеющееся в Ethernet П. Это будет
0x08-00 для IP, 0x08-06 для ARP или 0x08-35 для кадра RARP. Другие типы
перечислены в Приложении В.
Поле циклического избыточного кода (CRC) содержит контрольную
сумму, которая используется для обнаружения в кадре ошибок. Иногда его
называют также контрольной последовательностью кадра (FRC).
Минимальный размер инкапсулированных кадров IEEE 802.3 и кадров
Ethernet II одинаков. Но в связи с дополнительными полями, вставленны-
вставленными перед данными в кадре типа IEEE 802.3 (которые занимают восемь бай-
байтов), минимальный и максимальный объемы данных на восемь байтов
меньше, чем для кадров типа Ethernet П.
Управление потоком
Управление потоком является функцией, которая предотвращает перегруз-
перегрузку сети, не позволяя передающему устройству перегружать принимающие
устройства данными. Существует ряд возможных причин сетевой перегруз-
перегрузки. Например, высокоскоростной компьютер может создавать трафик бы-
быстрее, чем сеть может его передавать, или быстрее, чем устройство
назначения может его получить и обработать. Существуют три обычно ис-
используемых метода обработки сетевой перегрузки:
1. Буферизация используется сетевыми устройствами для временного
хранения всплесков избыточных данных в памяти, пока их нельзя
будет обработать. Случайные всплески данных легко обрабатывают-
обрабатываются с помощью буферизации. Однако избыточные всплески данных
могут переполнить память, заставляя устройство отбрасывать все
прибывающие дополнительные дейтаграммы.
2. Принимающие устройства направляют источникам сообщения по-
подавления передачи, чтобы предотвратить переполнение своих буфе-
буферов. Получающее устройство посылает сообщение подавления
передачи, чтобы источник уменьшил текущую скорость передачи
данных по нескольким причинам. Возможно, наиболее общая причи-
причина возникает, когда получающее устройство начинает отбрасывать
полученные данные в связи с переполнением буферов. Когда это про-
происходит, получающее устройство начинает посылать подавляющие
источник сообщения передающему устройству со скоростью одного
сообщения на каждый отброшенный пакет. Когда они начинают при-
приходить на устройство источника, оно снижает скорость данных, пока
не перестанет получать сообщения. Как только принимающее
устройство прекратит посылать сообщения подавления передачи,
устройство-источник станет постепенно увеличивать скорость данных
до тех пор, пока снова не получит запросов подавления.

36 Глава 1
3. Создание окна является схемой управления потоком, при которой
устройство-источник требует от устройства-приемника подтверждения
¦'¦ приема после передачи определенного числа пакетов. При размере
окна, равном трем, источник требует подтверждения после отправки
трех пакетов. Посмотрим, как это работает. Устройство-источник посы-
посылает три пакета устройству назначения. После получения трех пакетов
устройство назначения посылает источнику подтверждение. Источник
получает подтверждение и посылает еще три пакета. Если устройство
назначения не получает один или большее число пакетов по какой-то
причине (например, из-за переполнения буферов), у него нет достаточ-
достаточного количества пакетов, чтобы послать подтверждение. Источник, не
получив подтверждения, повторно посылает пакеты с уменьшенной
скоростью передачи.
Функции межсетевого обмена сетевого уровня 0SI
Функции межсетевого обмена сетевого уровня отвечают за выбор лучшего
маршрута передачи пакетов в сети, создание сетевых адресов и коммуника-
коммуникационных маршрутов.
Маршрутизаторы используют протокол маршрутизации для обмена слу-
служебной информацией между собой, используют маршрутизируемый прото-
протокол для передачи пакетов пользователя, настраивают и поддерживают
таблицы маршрутизации, находят сети, адаптируют изменения межсетевой
топологии, используют адрес из двух частей и ограничивают распростране-
распространение широковещательных рассылок.
Службы WAN
Х.25 Протокол Х.25 первоначально был разработан в 1970-х гг. для
предоставления неинтеллектуальному терминалу соединения WAN через
общедоступные сети данных (PDN — public data network). Однако благода-
благодаря своей гибкости и надежности он стал международным стандартом для
пересылки данных через PDN.
Ориентированный на соединение интерфейс сети коммутации пакетов
(PSN) предоставляет контроль ошибок и гарантированную доставку паке-
пакетов с помощью коммутируемых или виртуальных цепей. Благодаря своей
надежности он используется для приложений, которые требуют надежной
передачи. Маршрутизатор будет соединяться с ассемблером/дизассембле-
ассемблером/дизассемблером пакетов (PAD) в сети Х.25. PAD отвечает за разбиение сообщений на
пакеты и соответствующую их адресацию.
Спецификация Х.25 соответствует физическому, канальному и сетевому
уровням модели OSI. Однако, так как спецификация Х.25 предшествовала
модели OSI, названия уровней отличаются. Например, физический уровень
называется Х.21 и определяет электрические и физические интерфейсы, ко-
которые могут использоваться. Второй уровень называется протоколом сба-
сбалансированной процедуры доступа к каналу (LAPB, Link Access Procedure
Balanced), который заботится о создании кадра, управлении потоком и конт-
контроле ошибок. Уровень пакета соответствует сетевому уровню и отвечает
за настройку и адресацию виртуальной цепи.

Базовые сетевые модели 37
Frame Relay Отраслевой стандартный коммутируемый Протокол Frame
Relay действует на канальном уровне. Он обрабатывает множество виртуа-
виртуальных каналов с помощью инкапсуляции HDLC между соединенными
устройствами. Frame Relay использует высококачественную цифровую тех-
технику, делая методы контроля ошибок и управления потоком ненужными.
Поэтому он является более эффективным и быстрым, чем протокол Х.25, в
качестве замены которого он чаще всего рассматривается. Используя упро-
упрощенное кадрирование без исправления ошибок, Frame Relay может очень
быстро посылать информацию своего уровня. Первоначально он зарождал-
зарождался как протокол для работы с интерфейсами ISDN, поэтому был разработан
как независимый протокол.
Внутри Frame Relay коммутация PDN реализуется с помощью статистиче-
статистического метода мультиплексирования, а не с помощью временного разделения.
При статистическом мультиплексировании доступные цепи формируются
из устройств, которые в данный момент ничему не поставлены в соответст-
соответствие. В связи с этими динамическими характеристиками сети реального вре-
времени, которые пульсируют по своей природе, являются идеальными
кандидатами для Frame Relay.
Управление каналом осуществляется с помощью интерфейса локально-
локального управления (Local Management Interface, LMI). LMI отвечает за создание
постоянного виртуального канала (PVC, Permanent Virtual Circuit) и мони-
мониторинг PVC. Так как цифровые каналы менее подвержены ошибкам, Frame
Relay использует только алгоритм CRC для обнаружения плохих данных, но
не использует никакого механизма для их исправления. Для управления по-
потоком в канале Frame Relay полагается на верхние протоколы.
ATM Технология ATM (Asynchronous Transfer Mode, асинхронный ре-
режим передачи) является службой с поддержкой соединения и с негаранти-
негарантированной доставкой. Он хорошо масштабируется и используется в LAN и
WAN. ATM отличается от Frame Relay тем, что вместо разбиения сообще-
сообщений на кадры переменного размера все сообщения разбиваются на ячейки
одинакового размера. Каждая ячейка имеет пятибайтовый заголовок и
48-байтовое поле данных. Так как все ячейки имеют одинаковый размер,
коммутация может быть сделана очень быстрой, и поэтому необходимость
в буферизации исчезает.
Поскольку это асинхронный метод, нет необходимости в технике TDM.
При использовании ATM станция может посылать ячейки, когда ей это по-
понадобится, а не ожидать очереди передачи, как в случае TDM.
Хотя ATM не соответствует точно модели OSI, большинство его функ-
функций можно соотнести с канальным и сетевым уровнями. Поэтому он мо-
может действовать во множестве различных физических сред передачи,
включая SONET и FDDI. Уровень адаптации ATM соответствует сеансово-
сеансовому и транспортному уровням модели OSI. Он отвечает за получение дан-
данных для протоколов более высокого уровня, такого как IP, и сегментирует
данные в 48-байтовые ячейки для передачи через сеть ATM.

38 Глава 1
ISDN Это коммуникационный протокол, предложенный телефонны-
телефонными компаниями, который позволяет телефонным сетям передавать дан-
данные, голос и другие источника трафика по телефонным линиям. ISDN
построен на двух основных типах коммуникационных каналов. Первым яв-
является канал-носитель, или В-канал (Bearer), который может переносить
голос, данные или изображения со скоростью 64 Кбит/сек, а вторым являет-
является канал данных, или D-канал (Data), который имеет скорость 16 Кбит/сек и
используется для контрольной информации, передачи сигналов и данных
управления линией. ISDN реализуется обычно в двух версиях: ISDN Basic
Rate Interface (BRI) с двумя каналами В и одним каналом D и ISDN Primary
Rate Interface (PRI) с 23 каналами В и каналом D.
HDLC Синхронный бит-ориентированный протокол канального уров-
уровня, разработанный ISO. Производный от SDLC, HDLC определяет метод
инкапсуляции данных на синхронных последовательных линиях, исполь-
используя символы обрамления кадра и контрольные суммы. Данные переносятся
в кадрах, которые могут содержать переменный объем данных.
SLIP Используется как метод инкапсуляции последовательного кана-
канала, поэтому является простым протоколом кадрирования пакетов. SLIP
определяет несколько символов, которые обрамляют пакеты IP в последо-
последовательном канале. Это техника с минимальными накладными расходами,
которая не предоставляет согласования адресации, идентификации прото-
протокола, обнаружения ошибок или механизма сжатия. Созданный для исполь-
использования на медленных последовательных линиях связи (например,
модемах), он определяет два специальных символа, которые применяются
для обрамления кадра.
Первый — символ END (OxCO), который используется для определения
конца дейтаграммы IP. Второй символ — ESC (OxDB) используется для ука-
указания, когда символ ОхСО встречается внутри дейтаграммы IP. ESC-символ
SLIP отличается от ESC-символа ASCII (OxlB).
SLIP использует технику, называемую символьным заполнением, для
предотвращения появления символа END в середине дейтаграммы IP. Если
символ END (OxCO) встречается внутри исходной дейтаграммы IP, то он за-
заменяется последовательностью OxDB-DC. Если символ ESC (OxDB) встреча-
встречается внутри дейтаграммы IP, то он заменяется последовательностью
OxDB-DD. Это предотвращает зависание модема в середине передачи.
Максимальный размер дейтаграммы IP для SLIP обычно ограничен 1500
байтами на более новых системах или 1006 байтами на реализациях Berkley
UNIX версии 4.2. Однако эта распространенная практика не определена
в стандартах.
Чтобы сократить объем накладных расходов на потенциально медлен-
медленных последовательных линиях связи, в RFC 1144 определен метод сжатия
заголовков IP и TCP в заголовок размером от 3-х до 5-ти байтов, который
известен как C-SLIP или Compressed SLIP.

Базовые сетевые модели
39
РРР Протокол РРР — наследник SLIP. РРР предоставляет соединения
маршрутизатор-маршрутизатор и хост-сеть через синхронные последовате-
последовательные линии связи, такие как ISDN или SONET, а также асинхронные кана-
каналы, например типичные телефонные коммутируемые линии. Он исправляет
недостатки SLIP.
РРР является семейством протоколов, которые предоставляют мульти-
протокольную инкапсуляцию, протокол контроля линии (LCP) для созда-
создания, конфигурирования и тестирования соединения канала данных, и
семейство протоколов управления сетью (NCP) для создания и конфигури-
конфигурирования протоколов различных сетевых уровней.
Как можно видеть на рис. 1.14, РРР устанавливает флаг как 0х7Е
@1111110), чтобы указать начало и конец кадра РРР. В последовательных
кадрах РРР будет задан только один символ флага. Поле адреса использует-
используется для адресации пакета для узла места назначения. В двухточечной линии
связи узел назначения адресовать не нужно. Поэтому в РРР поле адреса
задается как OxFF, т.е. как адрес широковещания.
В среде HDLC контрольное поле используется для функции подтвержде-
подтверждения и упорядочивания уровня канала данных; однако в РРР контрольное
поле задано как 0x03 для указания кадра ненумерованной информации
(UI). Это то же самое, что и бит, который задается в методах кадрирования
Ethernet.
Netmxfc Monti» ¦ (GAvpnZcap (Detain
I* Q"Pto» 1°°!'
Wndow Help
mm rw
мел i
ш
Frame|T
1429
Time |Src НАС AddjDst MACAdcilproToccjDescription
292 6HPROX IJVH BA EX SMB 1С transact2
30 292 6.6FROX 9E32EAO0O10 PPP lrst Choice Co
Findfirst. File
431
432
«33
«34
292.92PROX
292 92PROX
292.939E32EA00010
292 93JVH_BA_?X
JVR_BA EX
9ЕЭ2ЕА0!
PROX
PROX
0D10
SHB
PPP
PPP
SMB
С transacts Findfirst. File • 4*
lrst Choice Compression Frame (OxFD)
lrst Choice Compression Frame (OxFD)
R transact2 Findfirst (response to frame 431)
M
+FRAHE1 Base frame properties
¦ETHERMET: ETYPE • 0x0800 Protocol - IP: DOD Internet Protocol
¦IP ID - 0x«76F; Proto - 0x2F Len 148
¦C-RE KS A . length: 112. Call ID 0
"•PPP lrst Choice Connression Fre*e (OxFC l
s
_Г"
00000000
00000010
00000020
00000030
00000040
00000050
00000060
00000070
00000080
00000090
000000A0
9E 32
00 94
07 8A
00 33
01 A3
Ы SB
56 BF
89 «0
«0 Fl
E5 40
00 00
EA 00
«7 6F
30 81
ДЛЕО
6A Cl
B0 03
A9 A6
A2 К
DE 1С
BO 04
01 01
00 00
86 0B
4E 00
60 00
2E 16
Al 19
0В 20
80 00
A8 00
00 01
80 2F
00 70
21 45
12 CF
CS 01
79 20
11 02
04 00
10 00
90 DD
78 F0
00 00
ЭС 00
11 49
82 00
01 80
00 18
22 79
10 07
66 SO
CE 70
00 00
81 23
05 B4
A8 ?3
38 04
78 97
52 02
CC 85
08 00 45 00
CB C9 D8 17
00 SA 00 00
37 A0 00 40
00 «2 CO 00
90 00 07 84
12 07 E« C7
АО 0А 00 00
00 02 00 2B
CO 02 A0 00
Р20.
oGo.
eOue
3fiaH
lie-'
fdC
e#d*.
s4>! i.
EjfC. E.
- I | B+.
+.*.tpE..a
У .Св...S|
...xua...
"yR . +
Protocol Identf* o> E ncaptijaled Oata
0№50(«32|
Рис. 1.14. Протокол РРР инкапсулирует IP для улучшенной передачи
через синхронные и асинхронные каналы

40
Глава 1
Поле протокола имеет два байта и используется для идентификации
протокола в полезной нагрузке РРР. Если поле задано как 0x00-21, то оно
указывает на дейтаграмму IP. Контрольная последовательность кадра (FCS)
является двухбайтовой CRC, аналогичной тому, что используется для ин-
инкапсуляции Ethernet.
Как и SLIP, РРР имеет метод, предотвращающий появление символа
флага в середине данных. В синхронной линии связи, такой как ISDN, ис-
используется заполнение битами для вставки дополнительных битов, чтобы
отметить, когда появляется символ флага. Закодированное представление
байтов может содержать более 8 битов, но дополнительные биты добавля-
добавляются и удаляются аппаратурой синхронной линии связи.
РРР использует также заполнение символами (подобно SLIP) на асинх-
асинхронных линиях для предотвращения появления флага внутри кадра РРР.
Если символ 0х7Е появляется в исходной дейтаграмме IP, то он заменяется
строкой символов 0x7D-5D. Если символ ESC @x7D) возникает в исходной
дейтаграмме, то он заменяется последовательностью 0x7D-5D снова в 0x7D.
Символы меньше 0x20 также модифицируются, чтобы последователь-
последовательные драйверы не интерпретировали их как управляющие символы, посы-
посылая 0x7D, а затем исходный символ с дополненным шестым битом.
Максимальная получаемая единица данных (MRU) равна 1500 байтам.
Nrfwut МопКя - (G:\vpn2 cap (DetailII
?1 fie ?4
IP DOD Internet Protocol
vFRAHE Base frame properties
¦ETHERNET: ETYPE - 0x0800 Protocol
-IP ID - 0x4D6F: Proto ¦ 0x2F. Len 3?
IP: Version ¦ 4 @x4)
IP- Header Length - 20 @x14) ." ''*' .' ""."'
¦IP Service Type ¦ 0 @x0)
IP: Total Length ¦ 32 @x20)
IP: Identification • 19823 @x4D6F)
¦IP' Flags Summary ¦ 0 @x0)
IP. Fragment Offset • 0 @x0) bytes
IP Time to Live • 128 @x80)
IP: Protocol ¦ Generic Routing Encapsulation
IP Checksum - 0x7364
IP: Source Address ¦ J06 112.203 201
IP Destination Address ¦ 216 23 7 138
IP: Data: Humber at data bytes remaining • 12 (OxOOOC)
-GRE К I l-r.qnh С Call I DO
jJL
GRE: 0
GRE: .0
GRE ..I
GRE .0
GRE 0
GRE 1
GRE: Recursion Control
GRE Ver ¦ 1 @x1)
GRE: Protocol Type ¦ ОхвЗОВ
GRE. Key length • 0 @x0)
GRE: Key Call ID • 0 @x0)
Checksum Absent
Routing Absent
Key Present
Sequence Number Absent
Strict Source Route Absent
Acknowledge Sequence Humber Present
0 @x0)
V.
00000000 9E 32 EA 00 01 01 00 01 90 DD 66 80 08 00 45 00 P20
00000010 00 20 4D6F 00 00 80 2F 73 64 CE 70 CB О D8 17 Ho
00000020 07 8A НЯЕП 88 0B 00 00 00 00 00 00 00 36 К
EKC E.
d
¦>]
|Ft «41/491
[L2fx2|
Рис. 1.15. Кадр РРТР имеет несколько заголовков перед информацией
заголовка GRE

Базовые сетевые модели 41
РРТР Протокол РРТР является способом взять существующий кадр
РРР и инкапсулировать его через межсетевой обмен IP. РРТР позволяет со-
создать в Интернете защищенные виртуальные частные сети (VPN). РРТР мо-
может использоваться независимо от того, поддерживает VPN провайдер
услуг Интернета (ISP) или нет. Требуется только сервер, поддерживающий
РРТР, и клиент, который может создать соединение РРТР.
Инкапсуляция кадров РРР реализуется с помощью протокола инкапсуля-
инкапсуляции базовой маршрутизации (GRE), который использует ID протокола IP,
равный 47 @x2F). Для использования его с РРТР протокол GRE был усовер-
усовершенствован, чтобы предоставить поле подтверждения.
Как показано на рис. 1.15, кадр РРТР имеет заголовок среды и заголовок
IP, прежде чем добраться до заголовка GRE. После заголовка GRE следует
заголовок РРР, а затем полезная нагрузка РРР.
Заголовок GRE начинается с двух байтов для флагов. Эти флаги указыва-
указывают, присутствует ли полезная нагрузка GRE и номера последовательности и
подтверждения. Поле типа протокола содержит значение Ethernet, которое
соответствует РРР @х88-0В). Длина полезной нагрузки равна размеру полез-
полезной нагрузки GRE в байтах. Идентификатор (ID) вызова является информа-
информацией идентификации сеанса для этого пакета РРТР, за которым следуют
номера последовательности и номер подтверждения — самый большой но-
номер последовательности, полученный посылающим узлом этого сеанса.
Номер последовательности используется для управления потоком, а не
для повторной передачи потерянных кадров РРТР.
Обзор главы
В этой главе был охвачен большой материал. Она началась с рассмотрения
модели OSI, где был показан уровень функциональности, предоставляемый
каждым уровнем модели. Затем мы остановились на изменениях, сделанных
в модели OSI проектом IEEE 802, и увидели, что канальный уровень был раз-
разделен на две части: подуровень управления логическим каналом и подуро-
подуровень управления доступом к среде передачи. Эти изменения предоставили
немного больше контроля над нижними уровнями, позволяя управлению
логического канала быть независимым от среды, так как он расположен
поверх уровня MAC.
Рассматривая формирование пакетов, мы познакомились с используемой
терминологией (дейтаграммы IP, сегменты TCP, а также кадры Ethernet).
После этого мы подробно рассмотрели реальную работу Ethernet, контроль
несущей, обработку множественного доступа. Были обсуждены методы
обнаружения конфликтов.
Затем была исследована роль протоколов, концепция стека протоколов
и иерархического подхода к сетевой коммуникации. Мы увидели, как рабо-
работает связывание, позволяющее менять протоколы, не меняя при этом драй-
драйверы сетевых адаптеров, а также ознакомились с концепцией порядка
связывания протоколов.

42 Глава 1
Наконец, мы обратились к инкапсуляции данных и исследовали многие
распространенные методы инкапсуляции, которые используются в насто-
настоящее время. Мы обсудили роль заголовков и рассмотрели каждое из полей
в наиболее популярных протоколах уровня сетевого интерфейса.
В следующей главе - *
Глава начинается с изучения стека протоколов TCP/IP. Мы увидим, как па-
пакет протоколов отображается на различные уровни модели OSI, и исследу-
исследуем некоторые из протоколов, обычно реализуемых в стандартном стеке
протоколов TCP/IP.
Затем мы рассмотрим протокол TCP и методы, которые он использует
для обеспечения надежной передачи с поддержкой соединения. Мы обсудим
методы управления потоком и упорядочивающие номера. Затем перейдем
к протоколу IP.
При обсуждении IP достаточно подробно исследуется способ инкапсу-
инкапсуляции данных, заголовок IP и т.п. Будут рассмотрены наиболее общие
команды, используемые с IP, и приведены рекомендации, которые помогут
в дальнейшем при поиске неисправностей.

Глава 2
Стек протоколов TCP/IP
Как упоминалось в предыдущей главе, TCP/IP — это не просто один-два
протокола; обычно реализуется сразу целый набор протоколов, или, как
иногда называют, стек протоколов. В предыдущей главе мы познакомились
с соответствием между протоколами из стека TCP/IP и эталонной моделью
OSI, но теперь рассмотрим этот стек более подробно. Как можно видеть на
рис. 2.1, стек TCP/IP состоит из четырех уровней: уровень приложений,
транспортный уровень, уровень Интернета и сетевой уровень. В совокуп-
совокупности эти четыре уровня охватывают все функции модели OSI.
Внизу стека находится уровень сетевого интерфейса, который соответ-
соответствует физическому уровню модели OSI. Этот уровень отвечает за перенос
кадров в среду передачи и за извлечение кадров из среды передачи. Необ-
Необходимо отметить, что это независимый от среды передачи уровень. Не
имеет значения, будет ли это медный провод, волоконно-оптический ка-
кабель, лазер, инфракрасные лучи или радио. Кроме того, он не зависит от
метода доступа к среде. Поэтому в локальной вычислительной сети (LAN)
стек TCP/IP можно использовать поверх Ethernet, Token Ring или FDDI, и,
конечно, можно использовать TCP/IP совместно с различными технологи-
технологиями глобальных сетей (WAN), таких как последовательный канал, исполь-
использующий старый протокол SLIP, или протокол РРР, который был создан как
усовершенствование старого стандарта SLIP. РРР предоставляет службы ка-
канального уровня, которые включают обнаружение ошибок, управление
конфигурацией, а также методы безопасности. Другим типом технологий
WAN является коммутация пакетов, например Frame Relay или ATM.
Следующим уровнем снизу является уровень Интернета, который предо-
предоставляет функции, соответствующие второму (канальному) и третьему (сете-
(сетевому) уровням модели OSI. Уровень Интернета отвечает за инкапсуляцию
пакетов в дейтаграммы IP и выполняет все необходимые алгоритмы маршру-
маршрутизации. Здесь имеются четыре протокола IP: протокол управляющих сооб-
сообщений Интернета (Internet Control Message Protocol, ICMP), протокол
управления группами Интернет (Internet Group Management Protocol,

44
Глава 2
7. Уровень приложений
6. Уровень представлений
5. Сеансовый уровень
Приложение
Транспорт
Интернет
Сеть
Рис. 2.1. Пакет протоколов TCP/IP состоит из четырех уровней, приблизительно
соответствующих модели 0SI
IGMP), протокол Интернет (Internet Protocol, IP) и протокол преобразова-
преобразования адресов (Address Resolution Protocol, ARP). Протокол ICMP использу-
используется для отправки сообщений и сообщений об ошибках относительно
доставки пакетов. Он осуществляет это от имени IP. ICMP не делает IP "на-
"надежным" протоколом, но он может предоставить определенный уровень
обратной связи по специальным условиям. Сами сообщения ICMP перено-
переносятся как дейтаграммы, т.е. без обеспечения надежности. Следующим про-
протоколом, представленным на этом уровне, является IGMP. Он используется
компьютерами для сообщения о своем членстве в определенной группе,

Стек протоколов TCP/IP 45
чтобы получать широковещательные рассылки от маршрутизаторов, кото-
которые поддерживают широковещание. Эти рассылки передаются как дейтаг-
дейтаграммы, т.е. являются ненадежной формой коммуникации. Последними
двумя протоколами Интернета, о которых необходимо сказать, являются
IP и ARP. В связи с важностью сетевой коммуникации мы рассмотрим их
более детально. Остановимся сначала на протоколе IP.
IP отвечает за адресацию и маршрутизацию пакетов между компьютера-
компьютерами и сетями. (Каждое устройство в сети IP, имеющее IP-адрес, называется
хостом; иногда хостами называют компьютеры, маршрутизаторы, принте-
принтеры и даже управляемые концентраторы.) Именно поэтому адрес, присвоен-
присвоенный хосту, поддерживающему стек TCP/IP, называется IP-адресом. Это
протокол без поддержки соединения, т.е. он не создает сеанс перед переда-
передачей данных. В этом отношении он является ненадежным протоколом, так
как не гарантирует доставку, не требуя подтверждения, что данные получе-
получены в месте назначения. Следующим протоколом уровня Интернета является
протокол ARP.
ARP используется для поиска аппаратного адреса машины в сети. Этот ад-
адрес, называемый иногда адресом MAC или адресом платы Ethernet, требует-
требуется, если два компьютера собираются общаться друг с другом. Адрес MAC
должен быть преобразован в адрес IP, чтобы хосты общались с помощью
протокола IP. ARP преобразует адрес с помощью широковещательной рас-
рассылки для всех хостов в локальной сети. Компьютер места назначения будет
отвечать пакетом, который содержит IP-адрес и адрес MAC. Эта информа-
информация будет затем храниться в кэше ARP на локальной машине. Последующая
информация предназначена для удаленного хоста; сначала будет проверя-
проверяться кэш ARP, а затем посылаться другое широковещательное сообщение.
Второй уровень сверху является транспортным уровнем, отвечающим за
обеспечение сеансов коммуникации между компьютерами. В стеке сущест-
существуют два транспортных протокола. Это протокол управления передачей
(Transmission Control Protocol, TCP) и протокол пользовательских дейтаг-
дейтаграмм (User Datagram Protocol, UDP). Для наличия двух транспортных про-
протоколов в стеке есть серьезная причина, так как они работают по-разному.
TCP является протоколом с поддержкой соединения, т.е. сначала он созда-
создает соединение с другой машиной. Используемый, когда требуется надежное
соединение, он обеспечивает подтверждение доставки каждого пакета.
Если подтверждение не получено, то посылающий компьютер пошлет ин-
информацию повторно. С другой стороны, UDP является протоколом без
поддержки соединения, он не требует соединения и не гарантирует достав-
доставку пакета. Это протокол, работающий без гарантии доставки: он оставляет
задачу отслеживания пакетов и управление потоком данных приложению,
которое обращается к транспортному уровню.
Вверху модели находится уровень приложений. В стандартной реализа-
реализации стека протоколов TCP/IP на этом уровне существует множество утилит.
Такие протоколы, как FTP (File Transfer Protocol, протокол передачи фай-
файлов), Telnet, SNMP (Simple Network Management Protocol, простой протокол
управления сетью), DNS (служба имен доменов) находятся на этом уровне,
так как именно здесь приложения получают доступ к сети. В реализации

46 Глава 2
TCP/IP компании Microsoft есть два способа, которыми приложения могут
получить доступ к сети: либо через NetBIOS, либо через Windows Sockets.
Интерфейс NetBIOS позволяет протоколам TCP/IP или NetBEUI использо-
использовать службы именования и сообщений, используя соглашение об именах
NetBIOS, в то время как служба Windows Sockets предоставляет интерфейс
прикладного программирования (API) для транспортных протоколов,
таких как TCP/IP или IPX.
Протокол TCP
Протокол управления передачей (протокол TCP) может выполнять базовую
пересылку данных, используя непрерывный поток данных размером в байт.
Данные упаковываются в сегменты для передачи протоколом Интернета. В
общем TCP сам выполняет управление потоком и сам решает, когда переда-
передавать и когда задержать данные, если потребуется. Определена функция push,
которая позволяет пользователю узнать, когда TCP успешно передал все дан-
данные, предоставленные ему приложением. Посылающий TCP может соби-
собирать данные от посылающих пользователей и посылать эти данные в
сегментах по своему собственному усмотрению, пока не будет вызвана функ-
функция push, после чего он должен послать все не отосланные данные. Когда
принимающий TCP видит флаг PUSH, он не должен ждать дополнительные
данные от посылающего TCP, прежде чем передать данные в получающий
процесс. Push заставляет TCP переслать и доставить полученные до этого
момента данные прямо получателю. Мы увидим флаг push в некоторых
примерах.
Чтобы восстановить поврежденные, потерянные, пришедшие в непра-
неправильном порядке или как-нибудь иначе поврежденные данные, TCP присва-
присваивает порядковый номер каждому передаваемому октету. Это позволяет
уровню TCP на получающей машине знать, в каком порядке должны прий-
прийти пакеты, чтобы правильно их собрать. В дополнение к порядковым номе-
номерам, каждый правильно полученный пакет должен также подтверждаться
(путем передачи служебного сообщения АСК) получающим TCP. Если АСК
не получен в течение периода ожидания, данные будут посланы повторно.
Для определения, что пакет был поврежден, используется контрольная
сумма. Она добавляется к каждому сегменту, передаваемому посылающей
машиной, и проверяется получателем.
Управление потоком обеспечивается с помощью "окна", которое посы-
посылается назад с каждым АСК. Это окно является диапазоном порядковых но-
номеров, которые могут быть переданы в следующем раунде коммуникации.
Они находятся за последним успешно полученным сегментом. Окно указы-
указывает число октетов, которое может послать отправитель, прежде чем полу-
получить следующее разрешение. Чтобы хост разрешал общаться через TCP в
одно время нескольким процессам, используются порты. Добавление номе-
номера порта в конце адреса IP (например: 123.123.123.123:29) формирует со-
кет. Пара сокетов используется для идентификации соединения, поэтому
сокет можно использовать для переноса данных в обоих направлениях
в одно время, т.е. это "дуплексная передача".

Стек протоколов TCP/IP 47
Хотя каждый хост отвечает за номера портов, которые он использует для
этих соединений, некоторые функции были присвоены "хорошо известным
портам". Эти службы доступны по известным адресам. Список этих хорошо
известных портов находится в Приложении А. Комбинация сокетов, номе-
номеров последовательности и размеров окон называется соединением. Два про-
процесса общаются, устанавливая сначала соединение. Когда коммуникация
заканчивается, соединение закрывается, чтобы освободить ресурсы.
Есть два интерфейса, поддерживаемые протоколом управления переда-
передачей. Это интерфейс пользователя и интерфейс Интернета. Интерфейс по-
пользователя позволяет вызвать пять основных функций протокола. Этими
функциями являются: Открыть соединение, Закрыть соединение, Пере-
Передать данные, Получить данные и Статус. Функция "Статус" выдает инфор-
информацию о соединении. Эти пять вызовов действуют так же, как их аналоги в
любой другой программе. Например, можно открыть или закрыть файл
таким же образом, как TCP выполняет функции аналогичного типа. Пассив-
Пассивный запрос OPEN (открыть) означает, что процесс хочет принять входящие
запросы соединения, а не пытается инициировать соединение.
Часто процесс, запрашивающий пассивный OPEN, будет принимать за-
запрос соединения от любого вызывающего абонента. В этом случае для обо-
обозначения неуказанного сокета будет использоваться внешний сокет только
из нулей. Неопределенные внешние сокеты допускаются только на пас-
пассивных OPEN. Процесс службы, которая желает предоставлять услуги
для других неизвестных процессов, будет создавать пассивный запрос OPEN
с неопределенным внешним сокетом. Затем можно будет создать соедине-
соединение с любым процессом, который запрашивает соединение с этим локаль-
локальным сокетом. Это полезно, если известно, что этот локальный сокет связан
с данной службой.
Хорошо известные сокеты являются удобным механизмом связывания
адреса сокета со стандартной службой. Например, процесс "TelnetServer"
постоянно присвоен определенному сокету, а другие сокеты зарезервиро-
зарезервированы для передачи файлов. Интерфейс Интернета, поддерживаемый TCP,
предоставляет только два вызова. Он может посылать или получать дейтаг-
дейтаграммы, адресованные модулям TCP на других хостах. Эти вызовы имеют
ряд параметров, которые можно задавать. Они задаются как флаги в кадре,
как мы увидим в примерах трассировок. Эти параметры включают тип
службы, приоритеты, безопасность и другую управляющую информацию.
Заголовок TCP
Поля источника и места назначения Рассмотрим структуру заголов-
заголовка TCP. Для этого обратимся к рис. 2.2 и разберем сегмент TCP, перехвачен-
перехваченный сетевым монитором. Первое поле, которое встречается в заголовке
TCP,— это порт источника, 16-разрядное поле, используемое для идентифи-
идентификации процесса на исходном компьютере, посылающем сегмент TCP целево-
целевому компьютеру. На рис. 2.2 это 0x04-05 (десятичное 1029). Следующее поле
(очевидно) является портом места назначения. Как и порт источника, это
также 16-разрядное поле, которое используется для идентификации
процесса на принимающей машине. На рисунке это порт telnet 0x17 B3).

48
Глава 2
Netwoik Morale» - IFAbookcap«\98 logmi.cap (DetalH
ЙКЮП» Vndow
ISIB1 \
Щ Щ isi
Src MAC Add
Dst ИАС Add
Description
_|,
а
561 KEHMV
S71KEHNY
081 KEHHY
096 KEHHY
09t TERESA
PROX
PROX
•BROADCAST
•BROADCAST
KEHHY
HBT
HBT
HBT
HBT
HBT
NS Registration req. for HGROCE <03>
HS. Query req. for TERESA
HS. Registration req for MGROCE <03>
HS: Query req. for TERESA
HS Query (Hode Status) rasp, for TERESA. Success
5091-45098. ack
12 09?TERESA
KEHHY
TERESA
TCP
TCP
s..
len:
lsn:
4. seq:
4S092-45052. ack.
797246C"*
¦FRAME Base frane properties
¦ETHERHET: ETYPE • 0x0800 : Protocol - IP: DOD Internet Protocol
¦IP ID • 0x3100; Proto - TCP. len: 46
•цТСР: S.. len: 8. seq: 45091-45098. ack.
l^TCP: Source Port - 0x0401
Destination Port ¦ NETBIOS Session Service
Sequence Hunoer - 45091 @x8023)
AcknovledgeMent Humber ¦ 0 @x0)
Data Offset • 28 (OxlC)
Reserved • 0 @x0000) ' -
Flags ¦ 0x02 : .. S.
¦ Ho urgent data
* Acknowledgement field not significant
•• Ho Push function
¦ Ho Reset
* Synchronize sequence numbers
Ho Fin
0. «in: 8192. src: 1025 dst: 139 (НГУ
TCP:
TCP:
TCP:
TCP:
TCP:
-TCP
TCP: . .0.
TCP: . .0.. .
TCP: 0 ..
TCP: 0
TCP: 1.
TCP: 0
TCP: «indov ¦ 8192 @x2000)
TCP: Checksu» ¦ 0x9A19
TCP: Urgent Pointer ¦ 0 @x0)
TCP Option Kind (HaxiauM Segment bize)
TCP: Option Length ¦ 4 @x4)
TCP: Option Value ¦ 1460 @x5B4)
г @x2)
•-¦-¦г
Packet options
IF* 14/S3
Рис. 2.2. Типичный заголовок TCP в сетевом мониторе ^
Поле порядкового номера Теперь мы переходим к порядковому номе-
номеру. 32-разрядное поле используется для идентификации порядкового номе-
номера, который соответствует первому байту в этом сегменте. Упорядочивание
TCP использует смещение байта в потоке данных для указания, где в потоке
находятся данные. Когда флаг SYN (синхронизации) задается во время уста-
установления соединения, номер последовательности становится начальным
порядковым номером (ISN). Когда данные посылаются, ISN увеличивается
на 1. Это сообщает посылающей и принимающей машинам, где в потоке
данных они работают.
Поле подтверждения Следующие 32 бита являются полем подтверж-
подтверждения, которое указывает посылающей машине, что предыдущий сегмент
был получен без изменений. Это поле имеет значение, только если задан
флаг АСК (подтверждение). Это поле очень важно для установленного
соединения.
Поле смещения данных Это четырехразрядное поле используется
для указания, где начинается полезная нагрузка TCP. Оно называется также
полем длины заголовка, так как после вычисления, где начинаются данные
TCP, мы знаем длину заголовка. Длина заголовка TCP (включая параметры)
всегда кратна 32 битам и не превосходит 60 байтов. Шесть битов, следую-
следующих за полем сдвига данных, зарезервированы и должны быть заданы как 0.

Стек протоколов TCP/IP 49
Шесть флагов TCP В заголовке TCP можно установить шесть флагов
(см. ниже). Они устанавливаются с помощью одноразрядного поля для каж-
каждого из доступных флагов. Поэтому поле флагов занимает в заголовке всего
шесть битов. Если флаг не установлен (т.е. сброшен), то в соответствующем
поле стоит значение 0.
1. Поле срочности (URG) существенно. При заданном флаге в поле ука-
указателя срочности содержатся важные данные. Срочные данные не
являются частью обычного потока данных и будут обрабатываться до
о любых других данных. Срочные данные могут использоваться для
¦ '• '< прерывания программ и уведомления приложения о событиях десин-
.¦''¦¦ хронизации. Они используются также для передачи по сети приложе-
\.'- нию сообщения, которое не является частью текущего потока
данных (данные вне полосы). .
2. Поле подтверждения (АСК) существенно, когда задан этот флаг.
Когда создано нормальное соединение, флаг АСК будет постоянно в
работе.
3. Флаг выталкивания (PSH) указывает, что данные в сегменте и другие
полученные данные, которые находятся в буфере получения, немедлен-
немедленно должны быть переданы в приложение. TCP часто будет держать вхо-
входящие данные в буфере получения, когда буфер заполняется, он
передает данные приложению. Это может вызывать проблемы в неко-
некоторых приложениях, таких как Telnet, которому необходимо иметь воз-
возможность передать клавишный ввод на другую машину. Выталкиваемые
данные не должны подтверждаться немедленно, это может произойти
при следующей нормальной передаче данных.
4. Флаг сброса (RST) используется для прекращения соединения. Когда
на активном соединении получен флаг сброса, это означает, что про-
произошла ошибка, и соединение должно быть принудительно закрыто.
Получение сброса при попытке установления соединения означает
отказ.
5. Флаг синхронизированного порядкового номера (SYN) используется в
начале настройки соединения для создания порядковых номеров и
подтверждения. До создания соединения ни одна из машин не знает о
порядковых номерах другой машины. В начале общения используется
трехходовое квитирование для передачи информации о порядковых
номерах. Флаг SYN используется для согласования порядковых
номеров.
6. Флаг завершения отправки данных (FIN) "культурно" завершает сое-
;. .. динение TCP. Когда одна машина хочет прекратить соединение, она
посылает сегмент с установленным флагом FIN. Если обе машины
послали сегменты с установленным FIN и подтвердили флаг, соеди-
соединение завершается. . ' ,

50 """" Глава 2
Поле окна Поле окна содержит 16 битов и используется для указания
числа байтов, которое готов принять отправитель сегмента TCP. Эти дан-
данные должны начинаться с октета, указанного в поле подтверждения, иначе
они будут отвергнуты. Это окно является явным указанием размера буфера
TCP на посылающем хосте. Оно также используется для определения мак-
максимального порядкового номера, который может быть подтвержден из это-
этого сегмента добавлением номера текущего подтверждения к номеру поля
окна.
Контрольная сумма Контрольная сумма является 16-битным числом,
представляющим собой двоичное дополнение суммы дополнений до едини-
единицы всех 16-битных слов в заголовке TCP и тексте. Если сегмент имеет не-
нечетное число октетов текста и заголовка, то последний октет дополняется
справа нулями, пока не будет сформировано 16-битное слово для использо-
использования при вычислении контрольной суммы. Важно отметить, что дополне-
дополнение нулями не передается. Пока контрольная сумма вычисляется, поле
контрольной суммы заполняется нулями.
Указатель срочности Поле указателя срочности является 16-битным
полем, которое задается равным порядковому номеру последнего октета
срочных данных. Оно используется, только когда передаются сегменты
с битом URG (срочный). Иначе это поле задается равным нулю @x0).
Заполнение кадра и параметры Поле параметров является набо-
набором из 32 битов, которые используются для хранения параметров TCP.
Если параметры не используют все 32-битное поле, оно заполняется нулями.
Трехходовое квитирование
Процедура создания соединений использует флаг управления синхрониза-
синхронизацией (SYN) и включает обмен тремя сообщениями. Этот обмен был назван
трехходовым квитированием. Соединение инициируется при встрече при-
прибывающего сегмента, содержащего SYN, и ожидающего входа TCN, кото-
которые создаются командой пользователя OPEN. Соответствие локального и
внешнего сокетов определяет, когда соединение было инициировано. Сое-
Соединение становится "установленным", когда номера последовательности
синхронизированы в обоих направлениях. Очистка соединения также
включает обмен сегментами, несущими в этом случае управляющий флаг
FIN.
Протокол не делает никаких ограничений на повторное использова-
использование определенного соединения. Соединение определяется парой сокетов.
Новые экземпляры соединения будут называться инкарнациями соедине-
соединения. При этом возникает проблема: "Как TCP идентифицирует сегменты
дубликаты из предыдущих инкарнаций соединения?" Эта проблема стано-
становится очевидной, если соединение открывается и закрывается в быстрой
последовательности или прерывается в связи с нехваткой памяти, а затем
восстанавливается.
Чтобы избежать путаницы, необходимо воспрепятствовать использова-
использованию сегментов из одной инкарнации соединения, в то время как те же самые
номера последовательности от предыдущей инкарнации могут по-прежнему

Стек протоколов TCP/IP 51
присутствовать в сети. Мы хотим гарантировать это, даже если TCP преры-
прерывает работу и теряет всю информацию о номерах последовательности, ко-
которые он использует. Когда создается новое соединение, используется
генератор начального порядкового номера (ISN), который выбирает но-
новый 32- разрядный ISN. Генератор связан с 32-битными часами (возможно,
фиктивными), младший бит которых увеличивается каждые четыре милли-
миллисекунды. Таким образом, ISN циклически повторяется примерно каждые
4,55 часов. Так как мы предполагаем, что сегменты будут оставаться в сети
не дольше, чем максимальное время жизни сегмента (MSL), и что MSL
меньше 4,55 часов, то можно считать, что ISN будет уникальным.
Для каждого соединения существует номер посылаемой последователь-
последовательности и номер получаемой последовательности. Начальный номер посыла-
посылаемой последовательности (ISS) выбирается посылающим данные TCP, a
начальный номер принимаемой последовательности (IRS) узнается во
время процедуры создания соединения. Чтобы соединение было установле-
установлено или инициализировано, два TCP должны синхронизировать друг с дру-
другом начальные номера последовательностей. Это делается при обмене
устанавливающими соединение сегментами, несущими управляющий бит,
называемый "SYN" (от слова синхронизация), и начальные номера последо-
последовательностей. В качестве сокращения сегменты, переносящие бит SYN,
также называются "SYN". Следовательно, решение требует подходящего ме-
механизма для выбора начального номера последовательности и небольшого
привлечения квитирования для обмена ISN.
Синхронизация требует, чтобы каждая сторона посылала свой собствен-
собственный начальный номер последовательности и получала подтверждение от
другой стороны. Каждая сторона должна также получить начальный номер
последовательности другой стороны и послать об этом подтверждение.
1. А—> В SYN мой номер последовательности X . . . .
2. А <--В АСК ваш номер последовательности X
3. А<—В SYN мой номер последовательности Y , i
4. А—> В АСК ваш номер последовательности Y
Так как шаги 2 и 3 обычно объединяются в одном сообщении, то после-
последовательность называется трехходовым квитированием. На рис. 2.3 показа-
показано, как это выглядит в реальной жизни.
Трехходовое квитирование необходимо в связи с тем, что номера после-
последовательности не связаны с глобальными часами сети, и TCP может иметь
другие механизмы для выбора ISN. Получатель первого SYN не может уз-
узнать, является ли сегмент задержавшимся старым или нет, если он не по-
помнит последний номер последовательности, использованный соединением
(что не всегда возможно). Поэтому он должен запросить отправителя про-
проверить, что TCP не создал сегмент, несущий номер последовательности,
который может дублироваться старым сегментом, остающимся в сети. TCP
должен оставаться спокойным в течение максимального периода жизни
(MSL), прежде чем присваивать какие-либо номера последовательности

NeOratk Молям ¦ IF:Vboolccsps\3Harfundslu*B.cap Ше1аЛ1
l<3) |g|e>l5|Q| 111 * \\?Щ iiaf
ISic HJC AddlDst НАС Add)Fro
1 0 650 KEHHY TERESA TCP
59059-59059. ack: 1816821
16 328 IKEHNY
16.329 ITERESA
TERESA
IKEWHY
TCP
TCP
len
len
18356770-18356773. ack
¦FRAHE Ease frame properties
¦ETHERNET ETYPE ¦ 0x0800 Protocol
¦ IP ID ¦ 0x4900. Proto • TCP. len
IP DOD Internet Protocol
59059-59059 ack 18168214. win;
TCP
TCP
TCP
TCP.
¦TCP.
TCP
TCP
TCP
TCP
Source Port ¦ 0x0401
Destination Port - NETBIOS Session Service
Sequence Number - 59059 (ОхЕбВЗ)
Acknowledgement Number ¦ 18168214 @xllS3996)
Data Offset - 20 @x14)
Reserved • 0 @x0000)
Flags ¦ 0x10 . A.
Vindov • 8590 @x218E)
Checksum ¦ 0x5405
Urgent Pointer ¦ 0 @x0)
Frame Padding
I
iL
00000000 00 80 SF OF C8 4i 00 10"ТВ EC~8D В2"8 0 TS 00
00000010 00 28 49 00 40 00 80 06 9D 79 0A 00 00 4C 0A 00
00000020 00 0B СД|Щ|||Ю:Щ|||М|Т|Щз(Д1:кИ||ИЬШЬЖ.1:».Ч1»11^
00000030 w:i«f Д|1Д|Т|Ж111моо ПД 00 DO 00 00
g+J MifT
(I.» <; ?y 1
trfr
±L
.TCP protocol «j»m*y
" frSTT/3
!О(Г34 |х22)
Рис. 2.З. Для создания надежного соединения TCP использует трехходовое
квитирование
при запуске или восстановлении после ошибки, при которой память исполь-
используемых номеров последовательности была стерта. Для этой спецификации
MSL задается равным двум минутам. Это инженерный выбор, который мо-
может быть изменен, если опыт покажет такую необходимость. Отметим, что
если TCP повторно инициализирован, но сохранил в памяти номера после-
последовательности, ему вообще не нужно ждать, он должен лишь использовать
номера последовательности, превышающие использованные ранее.
Концепция времени молчания TCP
Если при аварийном прекращении работы хост не сохраняет никакой ин-
информации о последних номерах последовательности, переданных во время
активного (т.е. не закрытого) соединения, при отправке любых сегментов
TCP будет происходить задержка на период не менее согласованного вре-
времени MSL внутренней системы, частью которой является хост. Реализато-
Реализаторы TCP могут нарушать ограничение "времени молчания", но они рискуют
тем, что некоторые получатели в Интернете старые данные будут прини-
принимать как новые, или отвергать новые данные как старые дубликаты.
TCP использует пространство номеров последовательности всякий
раз, когда сегмент формируется и вводится в очередь сетевого вывода на
хосте источника. Обнаружение дубликатов и алгоритм упорядочивания

Стек протоколов TCP/IP 53
в протоколе TCP опирается на уникальное связывание данных сегмента
с пространством последовательности, при условии, что номера последо-
последовательности не переберут все 2гг значения, прежде чем данные сегмента,
связанные с этими номерами последовательности, будут доставлены и
подтверждены получателем, и все двойные копии сегментов "исчезнут"
из Интернета. Без такого предположения двум различным сегментам
TCP могли бы быть присвоены одинаковые или перекрывающиеся номе-
номера последовательности, вызывая путаницу у получателя в определении,
какие данные являются новыми, а какие старыми. Помните, что каждый
сегмент связан с числом порядковых номеров последовательности, равным
числу октетов данных в сегменте.
При обычных условиях TCP отслеживает следующий номер последова-
последовательности для отправки и самый старый, ожидающий подтверждения, что-
чтобы избежать ошибочного использования номера последовательности,
прежде чем первое использование было подтверждено. Однако это не га-
гарантирует, что старые дублирующие данные удаляются из сети. Поэтому
пространство последовательности сделано достаточно большим, чтобы со-
сократить вероятность возникновения проблем из-за блуждающего дублика-
дубликата. При двух Мбит/сек потребуется 4,5 часа для использования 23i октетов
пространства последовательности. Так как максимальное время жизни сег-
сегмента в сети, скорее всего, не превышает нескольких десятков секунд, это
считается достаточной защитой для будущих сетей, даже если скорости пе-
передачи данных вырастут до десятков Мбит/сек. При 100 Мбит/сек время
цикла равно 5,4 мин, что, возможно, коротковато, но все еще в пределах
разумного.
Однако базовый механизм обнаружения дубликатов и алгоритм упорядо-
упорядочивания в TCP может не сработать, если TCP источника не сохраняет номе-
номера последовательности, которые он использовал в последнее время на
данном соединении. Например, если бы TCP должен был запускать все сое-
соединения с порядкового номера 0, то после аварийного завершения и переза-
перезапуска TCP мог бы переформатировать предыдущее соединение (возможно,
после разрешения полуоткрытого соединения) и послать пакеты с номерами
последовательности, идентичными или перекрывающимися пакетами, все
еще находящимися в сети, которые были посланы предыдущей инкарнацией
того же соединения. При отсутствии информации о номерах последователь-
последовательности, использованных определенным соединением, спецификация TCP ре-
рекомендует, чтобы источник делал задержку на MSL секунд, прежде чем
посылать в соединение сегменты, чтобы дать время сегментам, остающимся
в сети от предыдущей инкарнации соединения, исчезнуть из системы. Даже
те хосты, которые могут запоминать время дня и использовать его для выбо-
выбора значений начального номера последовательности, не защищены от этой
проблемы (т.е. даже если учитывается время дня для выбора начального
номера последовательности в каждой новой инкарнации соединения).
Полуоткрытые соединения и другие аномалии
Созданное соединение называют "полуоткрытым", если один из TCP за-
закрыл или прервал соединение на своем конце в одностороннем порядке,

54 Глава 2
или если два конца соединения стали десинхронизированными в связи с
аварийным отключением, которое привело к потере памяти. Такие соеди-
соединения будут автоматически восстанавливаться при пытке послать данные в
любом направлении. Однако полуоткрытые соединения считаются анома-
аномальными, и постепенно включается процедура восстановления. Если соеди-
соединение узла А больше не существует, то попытка пользователя узла В
послать ему какие-либо данные приведет к тому, что TCP узла В получит
управляющее сообщение сброса в исходное состояние (reset). Такое сообще-
сообщение указывает TCP узла В на ошибку, и ожидается прерывание соединения.
Предположим, что два пользовательских процесса А и В общаются друг с
другом, когда происходит авария, вызывая потерю памяти TCP процесса А.
В зависимости от операционной системы, поддерживающей TCP процесса
А, скорее всего, существует некоторый механизм восстановления ошибок.
Когда TCP снова включен, А начнет соединение заново или с точки восста-
восстановления. В результате А будет пытаться снова открыть (OPEN) соединение
или послать (SEND) в соединение, которое он считает открытым. В послед-
последнем случае он получает от локального (A) TCP сообщение "соединение не от-
открыто". При попытке создать соединение TCP процесса А пошлет сегмент,
содержащий SYN.
>:.¦¦. ¦. ¦ ¦¦¦ >. ... цс.'Л1. ¦¦¦ ¦
Генерация команды сброса
Как общее правило, команда сброса (RST) должна посылаться всякий раз,
когда приходит сегмент, который, очевидно, не предназначен для текуще-
текущего соединения. Команда сброса не должна посылаться, если неясно, что это
именно тот случай. Ниже описаны три существующие группы состояний.
1. Если соединение не существует (CLOSED), то команда сброса (reset)
посылается в ответ на любой входящий сегмент, за исключением дру-
другой команды сброса. В частности, SYN, адресованный несуществую-
несуществующему соединению, отбрасывается этими средствами. Если входящий
сегмент имеет поле АСК, то команда сброса берет свой номер после-
последовательности из поля сегмента АСК, иначе команда сброса имеет
номер последовательности равный нулю, а поле АСК задается как
сумма номера последовательности и длины входящего сегмента.
Соединение остается в состоянии CLOSED.
2. Если соединение находится в любом не синхронизированном состоя-
состоянии (LISTEN, SYN-SENT, SYN-RECEIVED), и входящий сегмент под-
подтверждает что-то еще не посланное (сегмент несет неприемлемое
АСК), или если входящий сегмент имеет уровень защиты или ячейку,
которые не точно соответствуют уровню и ячейке, запрошенным со-
соединением, то посылается команда сброса. Если посланный SYN еще
не был подтвержден и уровень приоритета входящего сегмента
выше, чем запрошенный уровень приоритета, то либо поднимается
уровень локального приоритета (если допускается пользователем и
системой), либо посылается команда сброса. Если уровень приорите-
приоритета входящего сегмента меньше, чем запрошенный уровень приорите-
приоритета, то процесс продолжается, как если бы приоритет соответствовал

Стек протоколов TCP/IP 55
точно (если удаленный TCP не может поднять уровень приоритета,
чтобы соответствовать точно, это будет обнаружено в следующем
сегменте, который он посылает, и соединение будет прекращено).
Если посланный сигнал SYN был подтвержден (возможно, в этом вхо-
входящем сегменте), то уровень приоритета входящего сегмента должен
точно соответствовать уровню локального приоритета. Если это не
так, должна быть послана команда сброса. Если входящий сегмент
имеет поле АСК, то команда сброса берет номер последовательности
из поля сегмента АСК; иначе команда сброса имеет номер последова-
последовательности ноль, а поле АСК задается как сумма номера последовате-
последовательности и длины входящего сегмента. Соединение остается в том же
СОСТОЯНИИ. ¦ ... • ¦ Ч' -I..
3. Если соединение находится в синхронизированном состоянии
(ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING,
LAST АСК, TIME-WAIT), то любой неприемлемый сегмент (номер по-
последовательности вне окна или неприемлемый номер подтвержде-
подтверждения) должен извлекать только пустой сегмент подтверждения,
содержащий текущий посланный номер последовательности и под-
подтверждение, указывающее следующий ожидаемый к получению но-
номер последовательности, и соединение остается в том же состоянии.
Если входящий сегмент имеет уровень защиты, ячейку или приори-
приоритет, которые не точно соответствуют уровню, ячейке и приоритету,
запрошенным для соединения, посылается команда сброса и соеди-
соединение переходит в состояние CLOSED. Команда сброса берет свой
номер последовательности из поля АСК входящего сегмента.
Обработка команды сброса .
Во всех состояниях, кроме SYN-SENT, все сегменты сброса (RST) конт-
контролируются проверкой их полей SEQ. Сброс будет признан действитель-
действительным, если его номер последовательности находится в пределах окна. В со-
состоянии SYN-SENT (RST получен в ответ на начальный SYN) RST является
приемлемым, если поле АСК подтверждает SYN.
Получатель RST сначала проверяет его, а затем изменяет состояние.
Если получатель был в состоянии LISTEN, то он его игнорирует. Если полу-
получатель был в состоянии SYN-RECEIVED, а ранее — в состоянии LISTEN, то
получатель возвращается в состояние LISTEN; иначе получатель прерыва-
прерывает соединение и переходит в состояние CLOSED. Если получатель был в
другом состоянии, он прерывает соединение, уведомляет пользователя и
переходит в состояние CLOSED. Закрытие соединения (CLOSE) является
операцией, означающей: "У меня больше нет данных для пересылки". По-
Понятие закрытия дуплексного соединения часто неверно интерпретируется,
так как может быть не очевидно, как интерпретировать получающую сто-
сторону соединения. Мы выбрали одностороннюю интерпретацию CLOSE.
Пользователи, которые делают CLOSE, могут продолжать RECEIVE (полу-
(получать), пока они не получат сообщение о том, что другая сторона также

56 Глава 2
CLOSED (закрыта). Таким образом, программа могла бы инициировать не-
несколько команд SEND (послать) после команды CLOSE (закрыть), и затем
продолжить получать, пока не будет получен сигнал, что команда RECEIVE
(получить) не сработала, так как другая сторона закрылась (CLOSED). Мы
предполагаем, что TCP будет сигнализировать пользователю, даже если
нет никаких ожидающих RECEIVE и другая сторона закрыта, поэтому поль-
пользователь сможет аккуратно завершить свою работу. TCP надежно доставит
все буферы, посланные до того, как соединение было закрыто, поэтому
пользователю, который не ожидает возврата никаких данных, необходимо
только подождать сообщения, что соединение успешно закрыто, следовате-
следовательно, все его данные были получены TCP местом назначения. Пользователи
должны продолжать считывание соединений, которые они закрыли для
отправки, пока TCP не сообщит об отсутствии данных. Рассмотрим три
существующих сценария:
1. Закрытие инициирует пользователь, приказывая TCP закрыть
соединение.
2. Закрытие инициирует удаленный TCP, посылая управляющий
сигнал FIN.
3. Оба пользователя закрывают соединение одновременно.
Сценарий 1: локальный пользователь инициирует закрытие
В этом случае может быть создан сегмент FIN и помещен в очередь исходя-
исходящих сегментов. Никакие другие команды SEND пользователя TCP не при-
принимает и входит в состояние FIN-WAIT-1. В этом состоянии допускаются
команды RECEIVE (получить). Все сегменты, предшествующие и включаю-
включающие FIN, будут посылаться повторно, пока не будет подтверждено их полу-
получение. Когда другой TCP подтвердит FIN и пошлет свою собственную
команду FIN, первый TCP может подтвердить (АСК) этот FIN. Отметим,
что TCP, получающий FIN, будет подтверждать (АСК), но не посылать свой
собственный FIN, пока его пользователь также не закроет соединение.
Сценарий 2: TCP получает FIN из сети
Если из сети прибывает не вынужденный FIN, то получающий TCP может
подтвердить его и сообщить пользователю, что соединение закрывается.
Пользователь ответит командой CLOSE, затем TCP может послать FIN дру-
другому TCP после отправки всех оставшихся данных. Затем TCP ожидает,
пока его собственный FIN не будет подтвержден, после чего удаляет соеди-
соединение. Если подтверждение АСК не поступает после периода ожидания по-
пользователя, соединение прерывается и об этом сообщается пользователю.

Стек протоколов TCP/IP 57
Сценарий 3: оба пользователя закрывают соединение
одновременно
Одновременное закрытие пользователями на обоих концах соединения вы-
вызывает обмен сегментами FIN. Когда все сегменты, предшествующие FIN,
обработаны и подтверждены, каждый TCP может подтвердить полученный
FIN. После получения этих АСК оба удалят соединение.
Обмен срочной информацией
Цель механизма срочной доставки TCP состоит в том, чтобы посылающий
пользователь мог стимулировать получателя принять некоторые срочные
данные и разрешить получающему TCP указать получателю, что все известные
в данный момент срочные данные получены пользователем.
Этот механизм позволяет в потоке данных обозначить точку как конец
срочной информации. Всякий раз, когда эта точка у получающего TCP воз-
возникает перед номером получаемой последовательности (RCV.NXT), TCP
должен приказать пользователю перейти в "режим срочности". Когда но-
номер получаемой последовательности сталкивается с указателем срочности,
TCP должен приказать пользователю перейти в "нормальный режим". Если
указатель срочности обновляется, когда пользователь находится в "режи-
"режиме срочности", обновление будет для пользователя невидимым. Метод ис-
использует поле срочности, которое переносится во всех передаваемых
сегментах. Управляющий флаг URG указывает, что поле срочности имеет
смысл и должно быть добавлено к номеру последовательности сегмента,
чтобы породить указатель срочности. Отсутствие этого флага указывает,
что ожидающих срочных данных нет.
Чтобы послать указание о срочности, пользователь должен послать так-
также по крайней мере один октет данных. Если посылающий пользователь
указывает путь доступа, то своевременность доставки срочной информации
в процесс места назначения улучшается.
Управление окном
Окно, посылаемое в каждом сегменте, указывает диапазон номеров после-
последовательности, которые готов принять в данный момент отправитель окна
(получатель данных). Существует допущение, что это связано с доступным
в этот момент пространством буфера данных для соединения.
Указание большого окна ускоряет передачу. Если поступает больше дан-
данных, чем может быть принято, они будут отбрасываться. Это приведет к из-
излишним повторным передачам, создающим дополнительную нагрузку на
сеть и TCP. Указание маленького окна может ограничить передачу данных
до появления задержки прохода туда и обратно перед передачей каждого
нового сегмента.
Предоставленные механизмы позволяют TCP объявлять большое окно,
а потом сообщать, что оно значительно меньше, не принимая слишком
много данных. Это так называемое "сжатие окна", очень обескураживает.
Принцип надежности диктует, что TCP не будет сжимать окно самостояте-
самостоятельно, но будет готов к такому поведение со стороны другого TCP.

58 Глава 2
Посылающий TCP должен быть готов принять от пользователя и по-
послать по крайней мере один октет новых данных, даже если окно отправки
равно нулю. Посылающий TCP должен регулярно повторно посылать кад-
кадры получающему TCP, даже когда окно равно нулю. Для интервала повтор-
повторной передачи рекомендуется использовать две минуты, когда размер окна
равен нулю. Эта повторная передача является существенной для гарантии,
что в том случае, когда оба TCP имеют нулевое окно, повторное открытие
окна будет обязательно сообщено другому.
Если сегмент прибывает, когда получающий TCP имеет нулевое окно, он
все равно должен послать подтверждение, показывающее его следующий
ожидаемый номер последовательности и текущее окно (ноль). Посылающий
TCP упаковывает данные для передачи в сегменты, которые соответствуют
текущему окну, и может перепаковывать сегменты в очереди повторной пе-
передачи. Такая перепаковка не обязательна, но может оказаться полезной.
При соединении с однонаправленным потоком данных информация об
окне будет переноситься в сегментах подтверждения, которые все имеют
одинаковый номер, поэтому не существует способа переупорядочить их,
если они приходят в беспорядке. Это не является серьезной, но позволит ин-
информации окна при случае временно основываться на старых отчетах полу-
получателя данных. Избежать этой проблемы можно, действуя на основе
информации окна из сегментов, которые несут самые большие номера под-
подтверждения (т.е. сегменты с номером подтверждения, равным или большим,
чем самый большой из полученных ранее).
Процедура управления окном имеет существенное влияние на производи-
производительность коммуникации. Следующие комментарии являются предложениями
для реализации.
Предложения по управлению окном Выделение очень маленького
окна приводит к тому, что данные будут передаваться во множестве мелких
сегментов, в то время как лучшая производительность достигается с помощью
меньшего числа больших сегментов.
Одним из предложений по избавлению от маленьких окон для получате-
получателя является задержка обновления окна, пока дополнительное выделение не
составит по крайней мере X процентов максимально возможного выделения
для соединения (где X может быть от 20 до 40).
Другое предложение для отправителя с целью избежать отправки малень-
маленьких сегментов состоит в ожидании, пока окно не станет достаточно большим,
прежде чем посылать данные. Если пользователь дает сигнал функции push,
то данные должны быть отправлены, даже если это маленький сегмент.
Отметим, что подтверждения не должны задерживаться, так как это может
привести к ненужным повторным передачам. Одной из стратегий является
отправка подтверждения, когда прибывает маленький сегмент (не обновляя
информацию об окне), и затем отправка другого подтверждения с новой
информацией об окне, когда окно станет больше. Сегмент, посылаемый
для проверки нулевого окна, может также начать разбиение передаваемых
данных в сегменты все меньшего' размера. Если сегмент, содержащий единст-
единственный октет данных, посланный для проверки нулевого окна, принимается,
он поглощает один октет доступного в данный момент окна.

Стек протоколов TCP/IP 59
Если посылающий TCP просто посылает столько, сколько может, когда
окно ненулевое, то передаваемые данные будут разбиты на чередующиеся
большие и маленькие сегменты. Со временем случайные паузы у получате-
получателя, делающие доступным распределение окна, приведут к разбиению боль-
больших сегментов на более мелкие. Через какое-то время передача данных
будет осуществляться в основном маленькими сегментами.
Суть вышеизложенного в том, что реализации TCP активно пытаются
комбинировать выделение маленьких окон с большими окнами, так как ме-
механизмы управления окном ведут к появлению множества маленьких окон
в простейших реализациях.
Интерфейс пользователь/ТСР
Следующее ниже функциональное описание команд TCP является в ка-
какой-то степени общим, однако весь TCP должен предоставить некоторый
минимальный набор служб для гарантии, что все реализации TCP могут
поддерживать одну и ту же иерархию протоколов. Этот раздел определяет
функциональные интерфейсы, встречающиеся во всех реализациях TCP.
Команды пользователя TCP
Следующие разделы объясняют, как работают некоторые из наиболее об-
общих команд TCP, и дают значительно лучшее понимание ситуации при по-
- иске неисправностей. Описанные ниже пользовательские команды
определяют базовые функции, которые будет выполнять TCP для поддер-
I жки коммуникации между процессами. Хотя эти команды не обязательно
[ будут видны, мы найдем признаки их работы в рассматриваемых приме-
| pax трассировки. Различные реализации могут изменять точный формат
| или предоставлять комбинации или подмножества базовых функций в
[ одиночных вызовах. В частности, некоторые реализации могут захотеть
;' открывать соединение автоматически при получении команды пользова-
', теля SEND (послать) или RECEIVE (получить) для данного соединения.
[ При предоставлении средств коммуникации между процессами TCP дол-
должен не только принимать команды, но также и возвращать информацию
процессам, которые он обслуживает. Она представляет собой общую ин-
информацию о соединении (т.е. прерывания, удаленное закрытие, связыва-
связывание неопределенного внешнего сокета). Ответы на специальные команды
пользователя указывают успех или различные виды отказов.
Мы предполагаем, что локальный TCP знает идентичность процессов,
которые он обслуживает, и будет проверять полномочия процесса на ис-
использование указанного соединения. В зависимости от реализации TCP
идентификаторы локальной сети и TCP для адреса источника будут по-
поставляться либо TCP, либо протоколом нижнего уровня (например, IP).
Эти свойства являются результатом рассмотрения вопросов безопасно-
безопасности, чтобы один TCP не смог маскировать другой, и т.д. Аналогичным об-
образом, ни один процесс не может маскировать другой без возникновения
конфликта TCP.

60 Глава 2
Если флаг "активный/пассивный" (Active/Passive) задан как пассивный,
то он представляет собой вызов LISTEN для входящего соединения. Пассив-
Пассивное открытие может иметь либо полностью специфицированный внешний
сокет, ожидающий определенное соединение, либо не специфицированный
внешний сокет, ожидающий любой вызов. Полностью специфицированный
пассивный вызов можно сделать активным последующим выполнением
команды SEND. Блок управления передачей (ТСВ) создается и частично за-
заполняется данными из параметров команды OPEN. На активной команде
OPEN TCP сразу начнет процедуру синхронизации (т.е. создания) соединения.
Параметр задержки (если присутствует) позволяет вызывающей сторо-
стороне установить задержку для всех данных, переданных TCP. Если данные не
будут доставлены в место назначения в течение времени задержки, TCP
прервет соединение. По умолчанию в настоящее время используется пять
МИНуТ. .¦;.;¦.¦<>¦
TCP или некоторый компонент операционной системы будет проверять
полномочия пользователя на открытие соединения с указанным приорите-
приоритетом или защитой/ячейкой. Отсутствие приоритета или спецификации за-
защиты/ячейки в вызове OPEN указывает, что должны использоваться
значения по умолчанию.
TCP будет принимать входящие запросы как подходящие только в том
Случае, если информация защиты/ячейки в точности совпадает и если
приоритет равен или выше приоритета, запрошенного в вызове OPEN.
Приоритет соединения равен большему из значений, запрошенному в
вызове OPEN и полученному из входящего запроса, и фиксируется на этом
значении в течение жизни соединения. Реализации могут захотеть предо-
предоставить пользователю управление этим согласованием приоритета. Напри-
Например, пользователь может определять, что приоритет должен точно
совпадать, или что любая попытка увеличить приоритет подтверждается
пользователем.
TCP будет возвращать пользователю имя локального соединения. Имя
локального соединения может затем использоваться в качестве сокращен-
сокращенного термина для соединения, определенного парой <локальный сокет,
внешний сокетх
Send (Послать)
Этот вызов заставляет послать данные, содержащиеся в указанном пользова-
пользователем буфере, в указанное соединение. Если соединение еще не было откры-
открыто, то SEND рассматривается как ошибка. Некоторые реализации могут
позволять пользователю сделать вызов SEND и в такой ситуации. В этом слу-
случае будет автоматически выполняться команда OPEN. Если вызывающий
процесс не уполномочен использовать это соединение, то возвращается
ошибка.
Если задан флаг PUSH, данные должны сразу передаваться получателю,
и бит PUSH будет установлен в последнем сегменте, созданном из буфера.
Если флаг PUSH не установлен, данные могут комбинироваться с данными
из последующих команд SEND для эффективности передачи.

Стек протоколов TCP/IP 61
Если установлен флаг URGENT, то в сегментах, посланных TCP назна-
назначения, будет задан указатель срочности. Получающий TCP будет сигнализи-
сигнализировать об условии срочности получающему процессу, если указатель
срочности показывает, что данные, предшествующие указателю срочно-
срочности, не были получены получающим процессом. Назначение срочности со-
состоит в стимуляции получателя к обработке срочных данных и для
указания получателю, когда все известные в данный момент срочные дан-
данные будут получены. Число раз, которое TCP посылающего пользователя
сигнализирует о срочности, не обязательно будет равно числу уведомлений
получающего пользователя о присутствии срочных данных.
Если в OPEN не был определен никакой внешний сокет, но соединение
установлено (например, потому что прослушиваемое соединение стало
определенным в связи с получением внешнего сегмента на локальном соке-
те), то обозначенный буфер посылается на подразумеваемый внешний со-
сокет. Пользователи, которые применяют SEND с не указанным внешним
сокетом, могут делать это, даже не зная точно адрес внешнего сокета.
Однако если SEND выполняется до того, как был определен внешний со-
сокет, то будет возвращаться ошибка. Пользователи могут применять вызов
STATUS для определения статуса соединения. В некоторых реализациях
TCP может уведомлять пользователя, когда связывается неопределенный
сокет.
Если определяется задержка, то задержка текущего пользователя этого
соединения изменяется на новое значение. В простейшей реализации
SEND не будет возвращать управление посылающему процессу, пока либо
передача не будет завершена, либо не истечет время задержки. Однако
этот простой метод может приводить к блокированию (например, обе сто-
стороны соединения могут пытаться выполнить SEND, не выполнив ни одной
команды RECEIVE) и реализует плохую производительность, поэтому он не
рекомендуется. Более сложная и современная реализация будет немедлен-
немедленно возвращать управление, чтобы следующий процесс выполнялся одно-
одновременно с сетевым вводом-выводом, и, более того, чтобы реализовать
несколько выполняющихся SEND. Несколько SEND обслуживаются в по-
порядке простой очереди, поэтому TCP будет создавать очередь из тех, кого
он не может обслужить немедленно.
Здесь неявно предполагается асинхронный интерфейс пользователя,
где SEND в дальнейшем вызывает появление некоторого вида SIGNAL (сиг-
(сигнала) или псевдопрерывания от обслуживающего TCP. Альтернативой яв-
является немедленный возврат ответа. Например, SEND мог бы немедленно
вернуть локальное подтверждение, даже если посланный сегмент не был
подтвержден удаленным TCP. Можно было бы оптимистично предполагать
конечный успех. Если мы ошиблись, то соединение будет закрыто в любом
случае в связи с истечением времени ожидания. В реализациях такого рода
(синхронных) все равно будут некоторые асинхронные сигналы, но они бу-
будут иметь дело с самим соединением, а не со специфическими сегментами
или буферами. ,

62 Глава 2
Чтобы процесс различал индикаторы успеха/неудачи для различных
SEND, может оказаться удобным возвращать адрес буфера вместе с кодиро-
кодированным ответом на запрос SEND. Сигналы TCP пользователю обсуждаются
ниже с указанием информации, которая должна быть возвращена вызываю-
вызывающему процессу.
Receive (Получить)
Эта команда выделяет буфер получения, связанный с указанным соедине-
соединением. Если этой команде не предшествует команда OPEN, или вызываю-
вызывающий процесс не уполномочен использовать это соединение, возвращается
ошибка.
В простейшей реализации управление не будет возвращаться вызываю-
вызывающей программе, пока не заполнится буфер или не произойдет какая-нибудь
ошибка, но эта схема существенно подвержена блокированию. Более разви-
развитая реализация будет позволять нескольким командам RECEIVE ожидать
выполнения одновременно. Они будут выполняться по мере поступления
сегментов. Эта стратегия позволяет увеличить пропускную способность за
счет более развитой схемы (возможно, асинхронной) уведомления вызыва-
вызывающей программы, что был получен PUSH или заполнен буфер. Если при-
прибывает количество данных, достаточное для заполнения буфера до
появления PUSH, флаг PUSH в ответ на RECEIVE задаваться не будет. Бу-
Буфер будет заполнен таким количеством данных, сколько он может вмес-
вместить. Если до заполнения буфера появляется PUSH, буфер возвращается
частично заполненным и с указанием PUSH.
При наличии срочных данных пользователь будет проинформирован об
этом, как только они появятся, с помощью сигнала TCP пользователю. Полу-
Получающий пользователь должен поэтому находиться в "срочном режиме". Если
установлен флаг URGENT, остаются дополнительные срочные данные. Если
флаг URGENT сброшен, то этот вызов RECEIVE вернул все срочные данные,
и пользователь может теперь покинуть "срочный режим". Отметим, что дан-
данные, следующие за указателем срочности (несрочные данные), нельзя доста-
доставить пользователю в тот же буфер с предшествующими срочными данными,
если только граница для пользователя четко не обозначена.
Чтобы различить несколько ожидающих RECEIVE и компенсировать бу-
буфер, который не полностью заполнен, код возврата сопровождается указате-
указателем буфера и счетчиком байтов, указывающим реальную длину полученных
данных.
Альтернативные реализации RECEIVE могут иметь TCP, который выделя-
выделяет буферную память, или TCP может совместно с пользователем использовать
кольцевой буфер.
Close (Закрыть)
Эта команда вызывает закрытие указанного соединения. Если соединение
не открыто, или же вызывающий процесс не уполномочен использовать
это соединение, возвращается ошибка. Закрытие соединения предназначе-
предназначено для элегантной работы в том смысле, что ожидающие SEND будут пере-
переданы (и переданы повторно), когда позволит управление потоком, пока все

Стек протоколов TCP/IP 63
не будет обслужено. Таким образом, допустимо выполнить несколько вызо-
вызовов SEND, за которыми следует CLOSE, и ожидать, что все данные будут по-
посланы в место назначения. Также должно быть ясно, что пользователи
могли бы продолжать RECEIVE (получать) на закрытых соединениях, так
как другая сторона могла бы пытаться передавать свои завершающие дан-
данные. Фактически CLOSE означает: "У меня для передачи больше ничего
нет", а не "Я больше ничего не буду принимать". Может случиться (если
протокол на уровне пользователя не очень хорошо проработан), что сто-
сторона не сможет избавиться от всех своих данных до того, как закончится вы-
выделенное время. В этом случае CLOSE превратится в ABORT, и закрываю-
закрывающий TCP прервется. Пользователь может закрыть соединение в любое
время по своей собственной инициативе или в ответ на различные пред-
предложения от TCP (например, выполнено удаленное закрытие, превышена
задержка передачи, место назначения недоступно).
Так как закрытие соединения требует коммуникации с внешним TCP,
соединение может оставаться в закрытом состоянии в течение некоторого
времени. Попытки повторно открыть соединение, прежде чем TCP отве-
ответит на команду CLOSE, будет приводить к сообщению об ошибке. CLOSE
также подразумевает вызов функции push (выталкивания данных).
Status Abort (Прервать)
Эта команда вызывает прерывание всех ожидающих SEND и RECEIVE, уда-
удаление ТСВ и отправку специального сообщения RESET для TCP на другой
стороне соединения. В зависимости от реализации пользователи могут по-
получать указания о прерывании для каждой ожидающей команды SEND или
RECEIVE или просто получить подтверждение команды ABORT.
TCP/Низкоуровневый интерфейс
TCP вызывает модуль низкоуровневого протокола для реальной отправки
и получения информации через сеть. Одним из случаев является система
взаимодействия сетей ARPA, где низкоуровневым протоколом будет IP.
Если низкоуровневым протоколом является IP, он предоставляет аргумен-
аргументы для типа службы и для времени жизни. TCP использует следующие на-
настройки для этих параметров: Type of service = precedence: routine; Delay:
normal; Throughput: normal; Reliability: normal; или 00000000. Время жизни
= одна минута, или 00111100. Отметим, что предполагаемое максимальное
время жизни сегмента равно двум минутам. Здесь мы явно указываем, что
сегмент будет уничтожен, если его окажется невозможно доставить по Ин-
Интернету в течение одной минуты. Если нижним уровнем является IP (или
другой протокол, который предоставляет это свойство) и используется
маршрутизация источника, интерфейс должен разрешать передавать ин-
информацию о маршруте. Особенно важно, чтобы адреса источника и места
назначения, используемые в контрольной сумме TCP, принадлежали исход-
исходному источнику и конечному месту назначения. Также важно сохранить
маршрут возврата для ответа на запросы соединения.

64 Глава 2
Любой низкоуровневый протокол должен предоставлять адрес источни-
источника, адрес места назначения, поля протокола и некоторый способ определе-
определения "длины TCP" одновременно для предоставления функционально
эквивалентной службы IP и для использования в контрольной сумме TCP.
Обработка, показанная в этом разделе, является примером одной возмож-
возможной реализации. Другие реализации могут иметь иную последовательность
обработки, но они должны отличаться от приведенной в данном разделе
только в деталях, а не по существу. Активность TCP можно охарактеризо-
охарактеризовать как реакцию на события. Происходящие события можно разделить на
три категории: пользовательские вызовы, прибывающие сегменты и исте-
истечение времени ожидания. Этот раздел описывает обработку, которую вы-
выполняет TCP в ответ на каждое из этих событий. Во многих случаях
требуемая обработка зависит от состояния соединения.
Происходящие события: пользовательские вызовы
Модель TCP/интерфейс пользователя является моделью, где команды по-
пользователя получают немедленный ответ и, возможно, ответ с задержкой с
помощью события или псевдопрерывания. В следующих описаниях термин
"сигнал" означает "причина задержанного ответа". Ответы об ошибках пре-
предоставляются как строки символов. Например, пользовательские команды,
обращающиеся к соединениям, которые не существуют, получают в ответ
сообщение "Ошибка: соединение не открыто" ("error: connection not open").
Отметим, что в последующем все арифметические операции с номерами
последовательности, номерами подтверждений, окнами и т.д. выполняются
по модулю 2s2', так как это размер пространства номеров последовательно-
последовательности. Отметим также, что "=<" означает "меньше или равно (по модулю 232)".
Обработка входящих сегментов состоит в том, что они сначала проверяются
на правильный номер последовательности (т.е. содержатся в диапазоне ожи-
ожидаемого "окна получения" в пространстве номеров последовательности), а
затем обычно выстраиваются в очередь и обрабатываются в порядке номе-
номеров последовательности. Когда сегмент перекрывает другие уже полученные
сегменты, он реконструируется, чтобы содержать только новые данные, и
соответствующим образом изменяются поля заголовка. Обратите внимание,
что если не упомянуто никакое изменение, TCP остается в том же состоянии
(т.е. ТСВ не существует). Создайте новый блок управления передачей (ТСВ)
для хранения информации о состоянии соединения. Запишите информа-
информацию об идентификаторе локального сокета, внешнем сокете, приоритете,
безопасности/ячейке и времени ожидания пользователя. Некоторые час-
части внешнего сокета могут быть не определены при пассивном OPEN и дол-
должны заполняться параметрами входящего сегмента SYN. Проверьте, что
запрошенные безопасность и приоритет допустимы для этого пользовате-
пользователя; если нет, верните "ошибка: приоритет недопустим" или "ошибка: защи-
защита/ячейка недопустимы". Если соединение активно, введите состояние
LISTEN и вернитесь. Если в активном состоянии и определен внешний сокет,
пошлите сегмент SYN. Выбирается начальный номер посылаемой последова-
последовательности (ISS). Сегмент SYN посылается в форме <SEQ=ISSxCTL=SYN>. За-
Задайте SND.UNA как ISS, SND.NXT как ISS+1, введите состояние SYN-SENT и

Стек протоколов TCP/IP 65
вернитесь. Если вызывающая сторона не имеет доступа к указанному лока-
локальному сокету, возвращается "ошибка: соединение недопустимо для этого
процесса". Если нет места для создания нового соединения, возвращается
"ошибка: недостаточно ресурсов".
Состояние прослушивания
Если текущее состояние соединения ACTIV и определен внешний сокет, то
измените состояние на активное и выберите ISS. Пошлите сегмент SYN, за-
задайте SND.UNA как ISS, SND.NXT как ISS+1-Введите состояние SYN-SENT.
Данные, связанные с SEND, могут быть посланы с сегментом SYN или вы-
выстроены в очередь для передачи после ввода состояния ESTABLISHED. Бит
срочности (если запрошен в команде) должен посылаться с сегментами
данных, посланными в результате этой команды. Если для занесения запро-
запроса в очередь нет места, возвращается сообщение "ошибка: недостаточно ре-
ресурсов". Если внешний сокет не определен, возвращается сообщение
"ошибка: внешний сокет не определен".
Вызов SEND (Послать)
• CLOSED STATE (закрытое состояние, т.е. ТСВ не существует). Если
пользователь не имеет доступа к такому соединению, возвращается
сообщение "ошибка: соединение незаконно для этого процесса". Иначе
возвращается сообщение "ошибка: соединение не существует".
• LISTEN STATE (состояние прослушивания). Если определен внешний
сокет, измените соединение из пассивного в активное и выберите ISS.
Пошлите сегмент SYN и задайте SND.UNA как ISS, SND.NXT как ISS+1.
Введите состояние SYN-SENT. Данные, связанные с SEND, могут посы-
посылаться с сегментом SYN или ставиться в очередь для передачи после
ввода состояния ESTABLISHED. Бит срочности (если запрошен в
команде) должен посылаться с сегментами данных, посланными в резу-
результате этой команды. Если для постановки этого запроса в очередь нет
места, то возвращается сообщение "ошибка: недостаточно ресурсов".
Если внешний сокет не был определен, то возвращается сообщение
"ошибка: внешний сокет не определен".
• SYN-SENT STATE SYN-RECETVED STATE. Создать очередь данных для пе-
передачи после ввода состояния ESTABLISHMENT. Если для очереди нет
пространства, возвращается сообщение "ошибка: недостаточно ресурсов".
• ESTABLISHED STATE CLOSE-WAIT STATE. Сегментировать буфер и
послать его с комбинированным подтверждением (значение подтвер-
подтверждения = RCV.NXT). Если пространства для запоминания этого буфе-
буфера недостаточно, возвращается сообщение "ошибка: недостаточно
ресурсов". Если задан флаг срочности, то SND.UP <- SND.NXT-1 и в ис-
исходящих сегментах задается указатель срочности. Вызовите CLOSED
STATE (т.е. ТСВ не существует). Если пользователь не имеет доступа к
такому соединению, возвращается сообщение "ошибка: соединение
недопустимо для этого процесса". Иначе возвращается сообщение
"ошибка: соединение не существует".

66 ¦" '"" Глава 2
. LISTEN STATE SYN-SENT STATE SYN-RECEIVED STATE. Создайте
очередь для обработки после ввода состояния ESTABLISHED. Если
для занесения этого запроса в очередь нет пространства, возвращается
сообщение "ошибка: недостаточно ресурсов".
ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 STATE. Если в
очереди для удовлетворения запроса недостаточное количество вхо-
входящих сегментов, то запрос ставится в очередь. Если пространства
очереди не хватает, чтобы запомнить RECEIVE, возвращается сооб-
сообщение "ошибка: недостаточно ресурсов". Переберите входящие сег-
сегменты в очереди в буфере получения и верните пользователю.
Сделайте отметку "присутствует push" (PUSH), если имеется соответ-
соответствующий флаг. Если RCV.UP предшествует данным, передаваемым в
этот момент пользователю, уведомите его о присутствии срочных
данных. Когда TCP берет на себя ответственность по доставке данных
пользователю, этот факт должен быть сообщен отправителю с помо-
помощью подтверждения. Формирование такого подтверждения описано
ниже при обсуждении обработки входящих сегментов.
Вызов RECEIVE: CLOSE-WAIT STATE. Так как удаленная сторона уже
послала FIN, команды RECEIVE должны быть удовлетворены уже по-
полученным текстом, но еще не доставленным пользователю. Если ника-
никакой текст не ожидает доставки, то RECEIVE получит сообщение
"ошибка: соединение закрыто". Иначе весь оставшийся текст может
использоваться для удовлетворения RECEIVE.
CLOSING STATE LAST-ACK STATE TIME-WAIT STATE. Возвращает
"ошибка: соединение закрыто". Вызовите CLOSED STATE (т.е. ТСВ не
существует). Если пользователь не должен иметь доступ к такому сое-
соединению, возвращается сообщение "ошибка: соединение недопусти-
недопустимо для этого процесса". Иначе возвращается сообщение "ошибка:
соединение не существует".
LISTEN STATE. Все ожидающие команды RECEIVE должны быть воз-
возвращены с сообщением "ошибка: сброс соединения". Удалите ТСВ,
введите состояние CLOSED и вернитесь.
SYB-SENT STATE. Всем ожидающим в очереди командам SEND и
RECEIVE должно быть выдано уведомление "сброс соединения", затем
удалите ТСВ, введите состояние CLOSED и вернитесь.
SYN-RECEIVED STATE ESTABLISHED STATE FIN WAIT-1 STATE
FINWAIT-2 STATE CLOSE-WAIT STATE. Пошлите сегмент сброса:
<SEQSND.NXTxCTL=RST>. Всем ожидающим в очереди командам
SEND и RECEIVE должно быть выдано уведомление "сброс соедине-
соединения"; все сегменты, ожидающие в очереди передачи (за исключением
формы RST) или повторной передачи, должны быть сброшены,
удалите ТСВ, введите состояние CLOSED и вернитесь.
CLOSING STATE LAST-ACK STATE TIME-WAIT STATE. Верните сооб-
сообщение "ok" и удалите ТСВ, введите состояние CLOSED и вернитесь.

Стек протоколов TCP/IP 67
Протокол IP
Протокол IP создан для использования в связанных системах компьютер-
компьютерных коммуникационных сетей с коммутацией пакетов. Протокол IP обраба-
обрабатывает передаваемые от источника к месту назначения блоки данных,
называемые дейтаграммами, где источниками и местами назначения явля-
являются хосты, идентифицированные адресами фиксированной длины. Про-
Протокол IP предусматривает также фрагментацию и повторную сборку
длинных дейтаграмм.
Функции IP ограничены доставкой пакетов битов (дейтаграмм Интерне-
Интернета) от источника к месту назначения через связанную систему сетей. В нем
не существует механизмов для обеспечения надежности двухточечной пере-
передачи данных, управления потоком, упорядочивания или других служб, при-
присутствующих обычно в протоколах взаимодействия хостов. Протокол IP
может использовать службы поддерживающих его сетей для предоставления
служб различных типов и качества.
Этот протокол вызывается протоколами взаимодействия хостов в среде
Интернета. Он вызывает протоколы локальных сетей для переноса дейтаг-
дейтаграмм Интернета к следующему шлюзу или хосту места назначения. Напри-
Например, модуль TCP будет вызывать модуль IP, чтобы получить сегмент TCP
(включая заголовок TCP и данные пользователя) как часть с данными дей-
дейтаграммы IP. Модуль TCP будет предоставлять адреса и другие параметры в
заголовке IP модулю IP как аргументы вызова. Модуль IP будет затем созда-
создавать дейтаграмму IP и вызывать интерфейс локальной сети для передачи
дейтаграммы.
Протокол IP реализует две базовые функции: адресацию и фрагмента-
фрагментацию. Модули IP используют адреса, передаваемые в заголовке IP, для пере-
передачи дейтаграмм IP в направлении их места назначения. Выбор пути
доступа для передачи называется маршрутизацией. Модули IP используют
поля заголовка IP в случае необходимости для фрагментации и повторной
сборки дейтаграмм IP.
Модель работы состоит в том, что модуль IP располагается на каждом
хосте, вовлеченном в коммуникацию Интернета, и на каждом шлюзе, кото-
который соединяет сети. Эти модули используют общие правила для интерпре-
интерпретации полей адреса и для фрагментации и сборки дейтаграмм IP. Кроме
того, эти модули (особенно на шлюзах) имеют процедуры для принятия
решений о маршрутизации и другие функции.
Протокол IP интерпретирует каждую дейтаграмму IP как независимую
сущность, не связанную с другой дейтаграммой IP. He существует никаких
соединений или логических связей (виртуальных или каких-либо других).
Протокол IP использует четыре ключевых механизма при предоставле-
предоставлении своих служб: тип службы, время жизни, параметры и контрольная сумма
заголовка. Тип службы используется для указания качества желательной
службы. Тип службы является абстрактным или обобщенным множеством
параметров, характеризующих варианты служб, предоставляемых в сетях, из
которых состоит Интернет. Это указание типа службы должно использовать-
использоваться шлюзами для выбора параметров реальной передачи для определенной

68
Глава 2
сети, которая будет применяться для следующего перехода или для следую-
следующего шлюза при маршрутизации дейтаграммы IP. Время жизни является
указанием верхней границы времени жизни дейтаграммы IP. Оно задается
отправителем дейтаграммы и уменьшается в точках вдоль маршрута, где
оно обрабатывается. Если время жизни достигает нуля до того, как дей-
дейтаграмма Интернета достигает своего места назначения, дейтаграмма IP раз-
разрушается. Время жизни можно считать пределом времени саморазрушения.
Параметры, предоставляемые для управляющих функций, необходимы
или полезны в некоторых ситуациях, но для большинства обычных коммуни-
коммуникаций не нужны. Параметры включают обеспечение отметок времени, безо-
безопасности и специальной маршрутизации. Контрольная сумма заголовка
предоставляет проверку того, что информация, используемая при обработке
дейтаграмм IP, была передана правильно. Данные могут содержать ошибки.
Если контрольная сумма заголовка неправильная, дейтаграмма IP тотчас от-
отбрасывается сущностью, которая обнаружила ошибку. Протокол IP не предо-
предоставляет надежного средства коммуникации. Не существует подтверждений
между конечными точками или точками перехода. Отсутствует контроль
ошибок данных, только контрольная сумма заголовка. Не существует по-
повтора передачи и управления потоком. Обнаруженные ошибки могут сообщаться
через протокол ICMP, который реализован в модуле протокола IP.
Протокол IP, с одной стороны, общается с протоколами коммуникации
хостов более высокого уровня, а с другой стороны, с протоколом локальной
сети. Это проиллюстрировано на рис. 2.4.
NeUrak Montn ¦ (F:\bookcopi\38 loon cap (S
Frame
5
:6
,7
: TiBe
7.559
560
560
.560
7 561
Src MAC Add
TERESA
Ш
TERESA
КЕШ?
Dst MAC Aid:
«BROADCAST
•BROADCAST
TERESA
KENHV
PROX
Frotocc Description
NETLOCC 1И1 0/2 0 LOGON Request ?ro« client
ARP RAKARP Request. Tarset IP 10 0.0 76
ARPlRASARP Reply Target IP 10 0 0 11 Target Hdwx Addr 008Г
KETLOGC LH2 0 Response to LOGON Request
b'BT US Registration re; for KCSOCE <0 3-
J
¦FRAME. Base frame properties
¦ETHERNET ETYPE - 0xG8Q0 Protocol
¦ГР ID • 0x2A00, Proto • UDP: Len
¦ IP DOD Internet Protocol
HBT HS Ou^rw
00000020 00 0A 00 99 00 89 00 ЗА А0
0О00ООЭ0
00000040
00000050
00 18 01 00 00 01
JO 00 00 00 00 00 21) 46 45 45 46 46 43 45 46 46
44 45 42 43 41 43 41 43 41 43 41 43 41 43 41 43
41 !'< 41 1! 41 41 41 00 0A ?0 00 01 ¦
. FEEFFCEFF
DEBCACACtCACACAi'
Рис. 2.4. Протокол IP общается с протоколом TCP более высокого уровня,
а также с сетевыми протоколами более низкого уровня

Стек протоколов TCP/IP 69
Модель работы при передаче дейтаграмм из одной прикладной про-
программы в другую иллюстрирует следующий сценарий. Предположим, что
эта передача будет включать один промежуточный шлюз. Передающая
прикладная программа готовит свои данные, вызывает свой локальный
модуль IP для отправки этих данных в виде дейтаграммы и передает адрес
места назначения и другие параметры в качестве аргументов вызова. Мо-
Модуль IP готовит заголовок дейтаграммы и присоединяет к нему данные.
Модуль определяет адрес локальной сети для этого адреса IP; в данном
случае это адрес шлюза. Он посылает эту дейтаграмму и адрес локальной
сети в локальный сетевой интерфейс. Локальный сетевой интерфейс со-
создает локальный сетевой заголовок и присоединяет к нему дейтаграмму, а
затем посылает результат через локальную сеть. Дейтаграмма прибывает
на хост шлюза в оболочке заголовка локальной сети, интерфейс локаль-
локальной сети удаляет этот заголовок и передает дейтаграмму модулю IP. Мо-
Модуль определяет из адреса IP, что дейтаграмма должна быть передана на
другой хост во второй сети. Модуль определяет адрес локальной сети для
хоста назначения. Он обращается к интерфейсу локальной сети, чтобы
послать ей дейтаграмму. Интерфейс локальной сети создает заголовок ло-
локальной сети и присоединяет дейтаграмму, посылая результат хосту на-
назначения. На хосте назначения дейтаграмма освобождается от заголовка
локальной сети интерфейсом локальной сети и передается модулю IP.
Модуль IP определяет, что дейтаграмма предназначена для прикладной
программы на этом хосте. Он передает данные прикладной программе в от-
ответ на системный вызов, передавая адрес источника и другие параметры,
как результат вызова.
Функция или назначение протокола IP состоит в переносе дейтаграмм в
пределах объединенной сети, или сетевого комплекса. Это реализуется пу-
путем передачи дейтаграмм из одного модуля IP в другой, пока не будет до-
достигнуто место назначения. Модули IP располагаются на хостах и шлюзах в
системе Интернет. Дейтаграммы маршрутизируются из одного модуля IP
в другой через отдельные сети на основе интерпретации адреса IP. Таким
образом, одним из важных механизмов протокола IP является IP-адрес.
При маршрутизации сообщений из одного модуля IP в другой дейтаг-
дейтаграммам может понадобиться пересекать сеть, максимальный размер пакета
в которой меньше размера дейтаграммы. Чтобы преодолеть эту трудность,
в протоколе IP предоставлен механизм фрагментации.
Существует различие между именами, адресами и маршрутами. Имя
указывает, что мы ищем. Адрес указывает, где это находится. Маршрут
указывает, как туда попасть. Протокол IP имеет дело прежде всего с адре-
адресами. Задача протоколов высокого уровня (т.е. протокола хост-хост или
приложения) — выполнить отображение из имен в адреса. Модуль IP ото-
отображает IP-адреса в адреса локальной сети. Задача низкоуровневых проце-
процедур (т.е. локальной сети или шлюзов) — выполнить отображение из адресов
локальной сети или маршрутов.
Адреса имеют фиксированную длину из четырех октетов C2 бита). Ад-
Адрес начинается с номера сети, за которым следует локальный адрес (на-
(называемый "собственным" полем). Есть три формата классов адресов IP:

70 Глава 2
в классе (а) старший бит равен нулю, следующие семь битов определяют
сеть, а последние 24 бита являются локальным адресом; в классе (Ь) стар-
старшими двумя битами будут один-ноль, следующие 14 битов определяют сеть,
а последние 16 битов являются локальным адресом; в классе (с) старшими
тремя битами будут один-один-ноль, следующие 21 бита определяют сеть, а
последние восемь битов являются локальным адресом.
При отображении адресов IP в адреса локальной сети должна быть прояв-
проявлена осторожность; в ряде случаев единственный физический хост должен
действовать как несколько различных хостов за счет использования несколь-
нескольких различных адресов IP. Некоторые хосты будут также иметь несколько фи-
физических интерфейсов (мультихост). Должно быть предусмотрено
существование хоста с несколькими физическими сетевыми интерфейсами,
каждый из которых может иметь несколько логических адресов IP.
Фрагментация дейтаграммы IP необходима, когда она создается в лока-
локальной сети, которая допускает большой размер пакета, и, чтобы достичь
места назначения, должна пересекать локальную сеть, ограничивающую
пакеты до меньшего размера.
Дейтаграмма IP может быть помечена как "не фрагментировать". Любая
помеченная таким образом дейтаграмма IP не будет фрагментироваться ни
при каких обстоятельствах. Если дейтаграмма IP, помеченная "не фрагмен-
фрагментировать", не может быть доставлена к своему месту назначения без фраг-
фрагментации, она будет отбрасываться. Фрагментация, передача и сборка в
локальной сети, которые не видны для модуля протокола IP, называются
фрагментацией интрасети.
Фрагментация IP и процедура сборки должны иметь возможность раз-
разбить дейтаграмму на произвольное число фрагментов, которые можно в да-
дальнейшем собрать снова. Получатель фрагментов использует поле
идентификации для обеспечения того, что фрагменты различных дейтаг-
дейтаграмм не смешиваются. Поле сдвига фрагмента и длина определяют часть
исходной дейтаграммы, содержащейся в этом фрагменте. Флаг "дополните-
"дополнительные фрагменты" указывает (будучи сброшенным) последний фрагмент.
Эти поля предоставляют достаточно информации для сборки дейтаграмм.
Поле идентификации используется для различения фрагментов одной
дейтаграммы от фрагментов другой. Модуль исходного протокола дейтаг-
дейтаграммы IP задает в поле идентификации значение, которое должно быть
уникальным для этой пары источник-место назначения и протокола, пока
дейтаграмма будет активной в системе Интернет. Модуль исходного прото-
протокола всей дейтаграммы задает флаг "дополнительные фрагменты" равным
нулю и сдвиг фрагмента как ноль.
Чтобы фрагментировать длинную дейтаграмму IP, модуль протокола IP
(например, в шлюзе) создает две новые дейтаграммы IP и копирует содер-
содержимое полей заголовка IP из длинной дейтаграммы в оба новых заголовка
IP. Данные длинной дейтаграммы делятся на две части по границе восьми
октетов F4 бита) (вторая часть, в отличие от первой, может не быть це-
целым, кратным восьми октетам). Вызовите число восьмиоктетных блоков в
первой части NFB (для числа блоков фрагментов). Первая часть данных
размещается в первой новой дейтаграмме IP, и поле общей длины задается

Стек протоколов TCP/IP 71
равным длине первой дейтаграммы. Флаг "дополнительные фрагменты" за-
задается равным единице. Вторая часть данных помещается во второй новой
дейтаграмме IP, и поле общей длины задается равным длине второй дейтаг-
дейтаграммы. Флаг "дополнительные фрагменты" имеет то же самое значение,
что и длинная дейтаграмма. Поле сдвига фрагмента второй новой дейтаг-
дейтаграммы IP задается равным значению этого поля в длинной дейтаграмме
плюс NFB.
Эта процедура может быть обобщена для разбиения на п частей. Чтобы
собрать фрагменты дейтаграммы IP, модуль протокола IP (например, на хо-
хосте назначения) объединяет дейтаграммы IP, которые имеют одно и то же
значение для четырех полей: идентификации, источника, места назначе-
назначения и протокола. Сборка осуществляется помещением порции данных каж-
каждого фрагмента в относительную позицию, указанную сдвигом фрагмента в
заголовке IP этого фрагмента. Сдвиг фрагмента равен нулю, а флаг "допол-
"дополнительные фрагменты" последнего фрагмента будет сброшен в ноль.
Заголовок IP
На рис. 2.5 показан пример заголовка IP, как он определен в сети Windows
NT. Первое поле в заголовке IP предназначено для версии, которая имеет в
длину четыре бита. Поле версии указывает формат заголовка IP и поэтому
сообщает другим машинам, как интерпретировать данные. Здесь показана
версия 4. Следующим полем является поле длины заголовка IP. Для этой
информации выделены четыре бита. Это число является длиной заголовка
Nctwoik МопИи - |G:\0717-O92CEDT cap IDelalll
О» ?<*
¦FRAME Base (rame properties ~jj
¦ETHERNET ETYPE - 0x0800 . Protocol " IP: DOD Internet Protocol "P
-IP. ID - 0xEE8. Proto - TCP. Len 40 '?
IP Version • 4 @x4) • < ¦ Л
IP Header Length • 20 @x14) .**
«IP Service Type • 0 @x0) «^
IP. Precedence ¦ Routine .. ' ¦ A."
IP: .. 0 • Normal Delay "y
IP 0. . . ¦ Normal Throughput - '*>
IP: 0 - Normal Reliability *••
IP Total Length ¦ 40 @«28)
r, - 3816 <0xEE8>
"IP Flags Summary • 2 @x2;
IP 0 " Last fragment in datagram
IP Is Cannot fragment datagram
IP Fragment Offset • 0 @x0) bytes
IP Time to Live ¦ 128 @x80)
IP Protocol • TCP - Transmission Control
IP Checksum • OxDtS?
IP Source Address • 11 0.0 205
IP Destination Address -11.0 0.201
IP Data Number of data bytes remaining " 20 @x0014)
¦TCP A . len 0. seq 910?643-5107643. ack: 1312110836. »m 7376. src. 1062 dst: 1S« r\
oooooooo oo ed'sF «У за зг'оо'бо s? ii ев бс'ов"оо~1ГоТ ^ТГг'Г'еГу-ТТТГ"
00000010 00 28 D14ip<A 00 80 06 D4 52 0B 00 00 CD 0B 00 (И* С +R -
00000020 00 C9 04 26 06 1A 00 Si F8 BB 4E 35 39 30 SO 10 + 4.. e'*N590P
00000030 1С 00 F0 83 00 00 --a.
'ItfenacatoncrteMedlahagmOememblyi FO 1«й/ИO ОН 18(»12) и2(«2|
Рис. 2.5. Структура заголовка IP

72
Глава 2
IP в 32-битных словах и поэтому указывает на начало данных. Отметим, что
минимальное значение для правильного заголовка равно пяти, что состав-
составляет 20 байтов. В шестнадцатеричной панели внизу рис. 2.5 выделенная об-
область является заголовком IP. Первое число равно 45. Это означает, что
это заголовок IP версии 4, имеющий длину 5x32 битов.
Следующее поле использует восемь битов для типа службы, чтобы за-
задать значения абстрактных параметров желаемого качества службы. Эти
параметры должны использоваться при выборе параметров реальной служ-
службы во время передачи дейтаграммы через определенную сеть. Несколько
сетей предлагают приоритет службы, которая считает трафик с высоким
приоритетом более важным, чем остальной трафик (обычно принимая тра-
трафик только выше определенного приоритета во время высокой нагрузки).
Основным выбором является трехсторонний компромисс между низкой
задержкой, высокой надежностью и высокой пропускной способностью.
В таблице 2.1 показано, как эти биты используются.
• Бит 3: 0 = обычная задержка, 1 = низкая задержка
• Бит 4: 0 = обычная пропускная способность, 1 = высокая пропускная
способность
• Бит 5: 0 = обычная надежность, 1 = высокая надежность
• Биты 6-7: зарезервированы для будущего использования
Таблица 2.1. Биты типа службы
Двоичное
представление
И100000
11000000
10100000
10000000
01100000 •*
01000000
00100000
00000000
00100000
00010000
00001000
00000100
000000[00]
Десятичное
представление
224
192
160
128
96
64
32
0
32
16
8
4
Значение * .<
Сетевой контроль
Межсетевой контроль
Critic/ECP
Переопределение групповой записи
Групповая запись
Немедленно
Приоритет
Маршрутизация
Приоритет
Низкая задержка
Высокая пропускная способность
Высокая надежность
Зарезервировано для будущего
использования

Стек протоколов TCP/IP 73
Использование параметров задержки, пропускной способности и надеж-
надежности может увеличить стоимость службы. Во многих сетях наилучшие пока-
показатели для одного из этих параметров сочетаются с наихудшими для другого.
Почти во всех случаях по крайней мере два из этих трех указателей должны
быть заданы. Тип службы используется для определения обработки дейтаг-
дейтаграммы во время ее передачи через систему Интернет. Рассмотрим каждый
из этих вариантов подробнее.
Задержка Если задать поле задержки как 1, то маршрутизатор IP будет
выбирать тот маршрут к месту назначения, который имеет наименьшую за-
задержку. Например, маршрутизатор IP выберет низкоскоростную наземную
линию, а не спутниковую линию с более высокой задержкой, даже если по-
последняя имеет большую полосу пропускания. Интерактивные сеансы, такие
как telnet, могут требовать этот тип обслуживания.
Пропускная способность Когда бит пропускной способности задан
как 1, маршрутизатор IP будет выбирать маршрут с наибольшей пропускной
способностью. В этом случае будет выбрана спутниковая, а не наземная ли-
линия с более низкой скоростью из предыдущего примера, так как она ее про-
пропускная способность выше. Если для загрузки большого файла используется
такое приложение, как FTP, оно много выиграет от такой службы.
Надежность Здесь также имеются две возможности, нормальная и
высокая. Если задать это поле как 1, то маршрутизатор IP будет принимать
решение первыми во время периодов перегрузки отбрасывать дейтаграммы
с нормальной надежностью.
Поле полной длины Следующее поле (длиной 16 битов) использует-
используется для указания общей длины дейтаграммы. Она измеряется в октетах и
включает заголовок IP и данные. Размер поля позволяет длине дейтаграм-
дейтаграммы доходить до 65635 октетов. Такие длинные дейтаграммы являются не-
непрактичными для большинства хостов и сетей. Все хосты должны быть
готовы принять дейтаграммы до 576 байтов (целые или фрагментирован-
ные). Рекомендуется, чтобы хосты посылали дейтаграммы больше 576 бай-
байтов, только если есть уверенность, что место назначения готово принять
дейтаграммы большего размера.
Число 576 выбрано для того, чтобы предоставить возможность передать
блок данных разумного размера в дополнение к требуемой информации за-
заголовка. Например, этот размер позволяет поместить в дейтаграмме блок
данных в 512 октетов плюс 64 октета заголовка. Максимальный заголовок
IP имеет 60 байтов, а типичный заголовок IP — 20 байтов, не учитывая ва-
вариантов, предоставляющих резерв для заголовков протоколов более высо-
высокого уровня.
Фрагментация и повторная сборка Если пакет IP с определенным
размером максимального блока передачи (Maximum Transmission Unit,
MTU) пересылается в сеть с размером MTU, который меньше, чем размер
текущей дейтаграммы IP, дейтаграмма должна быть фрагментирована.
Фрагментация не будет происходить, если размер дейтаграммы равен или
меньше MTU сети, через которую передается пакет.

74
Глава 2
Фрагментация может происходить на посылающем хосте или на марш-
маршрутизаторе. Каждый фрагмент посылается со своим собственным заголов-
заголовком IP с достаточной информацией для выполнения повторной сборки в
конечном месте назначения. Инструкции по сборке содержатся в иденти-
идентификации, флаге фрагментации и полях сдвига фрагмента заголовка IP.
На рис. 2.5 можно видеть, что следующим является поле идентифика-
идентификации, занимающее два байта. Это идентифицирующее значение присваива-
присваивается отправителем, чтобы помочь собрать фрагменты дейтаграммы. Оно
используется в конечном месте назначения для рекомбинации всех фраг-
фрагментов первоначальной дейтаграммы IP. Оно используется для группиров-
группировки фрагментов. Поле идентификации выбирается посылающим узлом и
помещается в исходную дейтаграмму IP вне зависимости от того, будет ли
использоваться фрагментация.
Следующим полем является поле флагов, для которого выделено три
бита. Первый бит зарезервирован и должен быть равен нулю. Следующие
два бита сообщают о фрагментации дейтаграммы. Если этот бит равен О
(флаг сброшен), дейтаграмма может быть фрагментирована, если требует-
требуется при передаче через маршрутизатор. Если этот бит равен 1, фрагмента-
фрагментация запрещена. В этом случае маршрутизатор IP будет отбрасывать
дейтаграмму и посылать источнику сообщение ICMP о том, что место на-
назначения недоступно. Этот механизм используется при поиске маршрута
MTU. Это делается с помощью PING, как показано на рис. 2.6.
Второй бит является флагом дополнительных фрагментов, сообщающим,
остались ли дополнительные фрагменты для передачи. Если он сброшен в О,
то это означает, что это последний фрагмент; если он установлен в 1, то су-
существуют дополнительные фрагменты для передачи. Флаг дополнительных
фрагментов всегда установлен в 1 в первом фрагменте и во всех срединных
фрагментах. Он сброшен в 0 в последнем фрагменте. . •.>,-,.,..
MS DOS Prompt
¦^'¦vMNOOWSsP^ktopj-ping prox -1 1<4СЮ -f -n 2
ring-ing PF.OX [10.0.0.10] with 1400 byte; of data:
Reply from 10.0.0.10: bytes«1400 tiroe=dm; TTl=128
Peply from 10.0.0.10: fcyt«5=U00 time=lm? TTl=12S
Ping ftatistici for 10.0.0.10:
Pacl-etis Sent = 2, Received » 2, Last ш 0 (OX loss),
Minimum = lmst Maximum a Ims, Average в lm;
•:i\UINCOIsSvJDaiktop>pinfl pro-: -I 1S00 -f -n 2
Fingvra FP.OX [10.0.0.10] with 1500 bytes of data:
'packet needs to be fragmented but Offset.
'Packet needs to be fragmented but OF set.
Pinj statistics for 10.0.0.10:
Packet;: Stnt = 2, Fecev'«) = 0. tort = 2 A00* loss),
'A^proxiinate round trip time* in milii-recondr:
Minimum a Cm?, Maximum » Oms, Average « Oms
Рис. 2.6. Флаг "не фрагментировать" установлен в PING

I Стек протоколов TCP/IP 75
Поле сдвига фрагмента имеет в длину 13 битов и указывает, где в дей-
дейтаграмме расположен этот фрагмент. Сдвиг фрагмента измеряется в еди-
| ницах по восемь байтов F4 бита). Первый фрагмент имеет сдвиг ноль.
Это используется для правильной сборки первоначальной полезной на-
нагрузки IP. Полезная нагрузка фрагментируется по восьмибайтовым грани-
| цам, называемым блоками фрагмента, и значение сдвига фрагмента
является блоком фрагмента, где фрагмент начинается. 13 битов в поле
сдвига фрагмента и каждое число в счетчике, представляющее восемь ок-
октетов, допускают общую нагрузку 65536 октетов, фрагментированных на
8192 фрагментов. На практике полезная нагрузка IP может иметь максималь-
максимальный размер только 65515 (IP MTU, равное 65535 байтов, минус минимальный
размер заголовка IP, равного 20 байтам.)
1. Предположим, что имеется пакет IP в 1500 байтов с 20-байтовым за-
заголовком IP и 1480-байтовой полезной нагрузкой. При фрагментиро-
вании для переноса по 576-байтовой сети каждый фрагмент будет
иметь свой собственный 20-байтовый заголовок IP и максимальную
нагрузку IP в 522 байта (что соответствует 69 блокам фрагментов).
f. При создании фрагментов первоначальный заголовок IP копируется
(хотя не все параметры обязательно будут скопированы), и затем из-
изменяются следующие поля: длина заголовка, TTL, общая длина, MF,
сдвиг фрагмента и контрольная сумма заголовка.
2. В приведенном выше примере нагрузка в 1480 байтов делится на
три фрагмента. Первый фрагмент состоит из 69 блоков фрагментов,
! второй — из 69 блоков фрагментов, а последний имеет 47 блоков
фрагментов.
3. Заголовки IP для трех фрагментов будут содержать следующую ин-
информацию: фрагмент 1 будет иметь общую длину 572, флаг MF будет
установлен в 1 и сдвиг фрагмента будет установлен в 0. Фрагмент 2 бу-
•;'| дет иметь общую длину 572, флаг MF будет установлен в 1 и сдвиг
фрагмента будет равен 69. Фрагмент 3 будет иметь общую длину 396,
флаг MF будет сброшен в 0 и сдвиг фрагмента будет задан как 138.
Повторная сборка Фрагменты передаются промежуточным маршру-
маршрутизатором IP по IP-адресу места назначения. Фрагменты могут следовать
различными маршрутами к месту назначения и прибывать в порядке, от-
отличном от того, в котором они были посланы. Сами фрагменты могут быть
фрагментированы во время их перемещения к конечному пункту назначе-
назначения. Для повторной сборки фрагментов в исходный вид IP использует поля
идентификации и адрес IP источника.
Когда узел места назначения получает фрагменты, он выделяет ресурсы
для повторной сборки. Ресурсы повторной сборки состоят из буфера дан-
данных, буфера заголовка, таблицы битов блоков фрагментов, поля общей
длины данных и таймера. Если это первый фрагмент (со сдвигом фрагмен-
фрагмента, равным 0), то его заголовок помещается в буфер заголовка. Если это по-
последний фрагмент (с флагом MF, равным 0), то вычисляется общая длина
данных.

76 Глава 2
Стандарты IP задают по умолчанию таймер повторной сборки на 15 се-
секунд. Если все фрагменты не будут получены в течение этого времени, они
будут отброшены и источнику может быть послано сообщение ICMP о пре-
превышении времени ожидания. При получении фрагментов таймер задается
как максимум текущего значения времени таймера и значения поля време-
времени жизни из полученного фрагмента.
Прибывающие дополнительные фрагменты помещаются в буфер дан-
данных в порядке, согласно сдвигу фрагмента и длине, и соответствующие
биты задаются в таблице битов блоков фрагментов. Когда приходит по-
последний фрагмент (если все фрагменты в таблице битов блоков заданы как
1 для общей длины первоначальной нагрузки), повторная сборка заверше-
завершена и полученная реконструированная полезная нагрузка доставляется соот-
соответствующему протоколу верхнего уровня.
Вопросы фрагментации при трансляционном переносе Трансля-
Трансляционный перенос (translational bridging) используется для соединения се-
сетей со смешанной средой передачи, таких как сеть Token Ring и Ethernet.
При этом может возникнуть проблема, связанная с тем, что MTU двух се-
сетей существенно различаются. В сегменте Token Ring допустимо MTU от
4464 до 17914, в то время как в сегменте Ethernet MTU ограничено 1500.
Если два сегмента соединены мостом, то может возникнуть ситуация, когда
пакеты отбрасываются, потому что мост не может фрагментировать дан-
данные, как это делает маршрутизатор. Одно из решений — задать MTU на сер-
серверах NT, соединенных с сетью Token Ring, равным 1500, для гарантии,
что пакеты не будут отброшены в связи с чрезмерным размером. Конечно,
прежде чем это сделать, необходимо выполнить мониторинг сети, чтобы уви-
увидеть, были ли отброшены пакеты. Если это так, то может помочь следующая
запись в реестре.
В Реестре:
HKEY LOCAL
MACHINE\SYSTEM\CurrentCotrolSet\Services\adapter\Tcipip\
parameters
Добавьте REG DWORD для MTU •- . .
Принимает значения от 68 до значения MTU сети.
Поле времени жизни (TTL — time-to-live) имеет восемь битов в длину и
следует за полем сдвига фрагмента. Это поле указывает максимальное время,
в течение которого дейтаграмма может оставаться в Интернете. Если это
поле содержит значение ноль, то дейтаграмма должна быть разрушена. Это
поле изменяется при обработке заголовка IP. Время измеряется в единицах
секунд, но так как каждый модуль, обрабатывающий дейтаграмму, должен
уменьшить TTL по крайней мере на единицу, даже если он занят этим менее
секунды, TTL должно рассматриваться только как верхняя граница времени,
в течение которого сможет существовать дейтаграмма. Цель состоит в том,
чтобы отбрасывать дейтаграммы, которые невозможно доставить, связав

Стек протоколов TCP/IP 77
это с максимальным временем жизни дейтаграммы. По умолчанию TTL в
Windows NT версии 3.5Х равно 32 секундам; в Windows NT 4.0 оно было
поднято до 128 секунд. Это значение по сути является пределом того, ско-
сколько маршрутизаторов может пройти дейтаграмма IP, прежде чем будет от-
отброшена. Это значение можно изменить в реестре, как показано дальше:
В Реестре:
HKEY LOCAL
MACHINE\SYSTEM\CurrentControlSet\Services\Tcipip\parameters
Добавьте REG DWORD для DefaultTTL
Принимает значения от 1 до 255
Далее следует поле протокола, указывающее на протокол следующего
уровня, используемый данными дейтаграммы IP. Для переноса этой инфор-
информации используется восемь битов. Значения для различных протоколов
определены в "Assigned Numbers" (Присвоенных номерах).
Потом идет поле контрольной суммы заголовка с 16 битами, выделенны-
выделенными для контрольной суммы только заголовка. Так как некоторые поля заго-
заголовка изменяются (например, время жизни), то она вычисляется повторно
и проверяется в каждой точке, в которой обрабатывается заголовок IP. Для
вычисления контрольной суммы суммируются дополнения до единиц всех
16-битных слов в заголовке, и к полученной сумме применяется операция
16-битного дополнения до единиц. Значение поля контрольной суммы
задается равным нулю.
Следующие два поля являются адресом IP источника и адресом IP места
назначения. Каждое из них имеет четыре октета. Именно здесь адреса IP
включаются в обмен данными. Хотя это и важное поле, мы не собираемся
тратить на него много времени, так как это может легко привести к обсужде-
обсуждению маршрутизации, широковещания и т.п. Эти вопросы будут рассмотрены
позже, при обсуждении сетевого трафика.
Затем следует поле параметров, которое может появиться или не появи-
появиться в дейтаграммах. Они должны быть реализованы всеми модулями IP
(хостом и шлюзами). Необязательным моментом является их передача в
каждой конкретной дейтаграмме, а не их реализация. В некоторых средах
параметр безопасности может потребоваться во всех дейтаграммах. Поле
параметров имеет переменную длину. Параметры IP будут иметь размер от
одного до 40 октетов. Это будет давать максимальный размер заголовка IP в
60 байтов. Может быть ноль или большее количество параметров. Каждый
параметр начинается с кода типа параметра. Этот код делится на три поля,
первое из которых является полем копирования. Если это поле задано как 1,
то параметр должен быть скопирован во все фрагменты. Если оно задано как
0, то он используется только в первом фрагменте. Следующие два бита в ок-
октете кода параметра используются для указания класса используемого пара-
параметра. Если он задан как 0, то это управление дейтаграммой или сетью, если
как 2, то он используется для отладки или измерения. Другие являются заре-
зарезервированными. Следующие пять битов используются для указания номера
параметра в классе параметров.

78
Глава 2
Второй октет является длиной параметра, которая включает код типа
параметра и октет длины, октет указателя и длину трех байтов данных о
маршруте. Третий октет является указателем на данные о маршруте, ука-
указывающим октет, где начинается адрес следующего источника, который
будет обрабатываться. Указатель связан с этим параметром, наименьшее
законное значение для него равно 4. Некоторые из этих параметров пере-
перечислены в таблице 2.2.
Таблица 2.2. Классы параметров и номера
Класс
параметра
Номер
параметра
Значение параметра
Class 0 Option 0 Однооктетный параметр, который используется
для указания конца списка параметров.
Он копируется в каждый фрагмент.
Class 0 Option 1 Однооктетный параметр, который используется
для выравнивания октетов в списке параметров.
Он копируется в каждый фрагмент.
Class 0 Option 3 Неопределенная маршрутизация от источника.
Параметр переменной длины, используемый для
,. . ¦. маршрутизации дейтаграммы через указанный
путь, где можно использовать альтернативные
маршруты. Он копируется в каждый фрагмент.
Class 0 Option 7 Записать маршрут. Параметр переменной
длины, используемый для трассировки
fI • ¦ маршрута в сети IP. Он не копируется в каждый
фрагмент.
Class 0 Option 9 Точная маршрутизация от источника. Параметр
переменной длины, используемый для
маршрутизации дейтаграммы через указанный
путь, где нельзя использовать альтернативные
" маршруты (противопоставление Option 3
выше). Он копируется в каждый фрагмент.
Class 2 Option 4 Отметка времени Интернета. Параметр
переменной длины, используемый для записи
ряда отметок времени при каждом переходе.
Он не копируется в каждый фрагмент.
Параметр записи маршрута Параметр записи маршрута позволяет
посылающей стороне создать заголовок IP с рядом пустых адресов IP в ка-
качестве параметров IP. Когда дейтаграмма IP перемещается по сети, каждый
встреченный маршрутизатор добавляет в список свой адрес IP, тем самым
записывая пройденный к месту назначения маршрут. В параметре записи
маршрута IP должно быть выделено достаточно места для хранения адре-
адресов IP. Размер каждого поля определяется посылающим компьютером. Как

Стек протоколов TCP/IP 79
можно видеть в списке ниже, посылающий компьютер задает поле пара-
параметров как 0x7, что указывает на использование параметра записи маршру-
маршрута. Следующее поле - это поле длины параметра, которое является полем
переменной длины, заданной в октетах посылающей машиной. Затем сле-
следует поле указателя следующего слота, которое используется для указания
сдвига октета в поле параметра записи маршрута, где начинается следующий
доступный слот для записи адресов IP маршрута.
IP: ID = 0xl3D; Proto = ICMP; Len: 92
IP: Version = 4 @x4)
IP: Header Length = 52 @x34)
¦¦ ;> . + IP: Service Type = 0 @x0) ,
: . IP: Total Length = 92 @x5C) ..,./, : ¦• . '
IP: Identification = 7997 @xlF3D) ' "'
+ IP: Flags Summary = 0 @x0)
IP: Fragment Offset = 0 @x0) bytes . -,•<-:,
IP: Time to Live = 32 @x20) ¦ ...
...,;...' . ¦ IP: Protocol = ICMP - Internet Control Message
.. .. . IP: Checksum = 0x3 63 9
IP: Source Address = 206.112.203.201
IP: Destination Address = 206.112.201.97 ' :
IP: Option Fields = 7 @x7)
IP: Record Route Option = 7 @x7)
' •¦' IP: Option Length = 31 (OxlF)
IP: Next Slot Pointer = 4 @x4) .-,-..- ч
IP: Route Traveled = 0 @x0)
¦•'¦•¦¦ IP: End of Options = 0 @x0) ¦, ;
IP: Data: Number of data bytes remaining = 40 @x0028)
Теперь посмотрим на ответ, который приходит из места назначения. Как
можно видеть в приведенной ниже распечатке, большая часть информации
выглядит точно так же, однако теперь она дополнена некоторой дополните-
дополнительной информацией. Мы в наибольшей степени заинтересованы в маршруте
к месту назначения. Мы видим адреса IP, которые были использованы для
записи информации маршрутизатора, когда дейтаграмма IP перемещалась
к своему месту назначения. Существуют максимум девять доступных слотов,
которые могут распределяться посылающим компьютером. В этом примере
использованы три из них.
IP: ID = 0xFC5; Proto = ICMP; Len: 92
IP: Version = 4 @x4)
IP: Header Length = 52 @x34)
+ IP: Service Type = 0 @x0)
IP: Total Length = 92 @x5C)
IP: Identification = 4037 @xFC5)
+ IP: Flags Summary = 0 @x0)
IP: Fragment Offset = 0 @x0) bytes
IP: Time to Live = 125 @x7D)
IP: Protocol = ICMP - Internet Control Message
IP: Checksum = 0x56EE
IP: Source Address = 206.112.201.97

80 Глава 2
IP: Destination Address = 206.112.203.201
•..,.¦> IP: Option Fields = 7 @x7) -.,-...
-, .. ,. IP: Record Route Option = 7 @x7)
IP: Option Length =31 (OxlF)
IP: Next Slot Pointer = 16 @x10)
'" ' '¦'¦' >!-' * IP: Route Traveled = 206 (OxCE) ' '
;" ' ' •'r IP: Gateway = 206.112.201.126
IP: Gateway = 206.112.201.97
IP: Gateway = 206.112.196.82
IP: End of Options = 0 @x0)
IP: Data: Number of data bytes remaining =40 @x0028)
Приведенные выше листинги были сделаны с помощью команды PING
Windows NT с параметром команды -г. Она посылает сообщение с запросом
Echo ICMP, который записывает маршрут.
Неопределенная маршрутизация от источника Обычно маршру-
маршрутизаторам и Windows NT разрешается принимать решения о маршрутиза-
маршрутизации на основе таблиц маршрутизации. Однако иногда при поиске
неисправностей, тестировании и отладке сетей необходимо определить
маршрут к месту назначения, не беспокоясь о модификации таблиц марш-
маршрутизации. Когда мы переопределяем путь доступа, который будет обычно
использоваться, мы вмешиваемся в маршрутизацию IP от источника. IP
поддерживает два вида маршрутизации от источника: неопределенную и
точную. Сначала рассмотрим неопределенную маршрутизацию от источника.
При неопределенной маршрутизации от источника IP-дейтаграмма ад-
адресуется следующему маршрутизатору с помощью IP-адреса места назначе-
назначения из заголовка IP. При неопределенном источнике маршрута хорошо то,
что можно определить маршрутизатор, который находится в нескольких
переходах. Посмотрим на поле параметров при использовании неопреде-
неопределенной маршрутизации от источника. В распечатке ниже можно видеть,
что поле кода параметра задано равным 131. Это значит, что используется
параметр неопределенной маршрутизации от источника (см. рис. 2.7).
IP: ID = 0xA32E; Proto = ICMP; Len: 68
IP: Version = 4 @x4)
IP: Header Length = 28 (OxlC)
+ IP: Service Type = 0 @x0)
IP: Total Length = 68 @x44)
IP: Identification = 41774 @xA32E)
+ IP: Flags Summary = 0 @x0)
IP: Fragment Offset = 0 @x0) bytes
IP: Time to Live = 32 @x20)
IP: Protocol = ICMP - Internet Control Message
IP: Checksum = 0xlE34
IP: Source Address = 10.0.0.60
IP: Destination Address = 10.0.0.10
IP: Option Fields = 131 @x83)
IP: Loose Source Routing Option = 131 @x83)
IP: Option Length = 7 @x7)
IP: Routing Pointer = 4 @x4)

Стек протоколов TCP/IP
81
Network Молим - (EAooukcapiUxite s
.U*J_xJ
[Tin» jgtc ШС Addr Igft KAC Addr brococol|l>«gctipci
|2. elS|00902764H8r 1»»0X TCP I. A. . .., !
10.00.00.60 To 10.00.00.10
I?: He»dtr Ltngrth - ?8 (OsclC)
¦4>X?: Service Type - 0 @x0)
IP-. Total Length « 68 @x44)
I»: Identification - 41774 <0xA32I)
^II»: tlmgs SuiMiy ¦ 0 @x0)
IP: Fragment Olfc«c ¦ 0 @x0) bytes
IP: Time to Live • 32 @x20)
IP: Protocol ¦ ICUP - Internet Control !
IP: Checkrum ¦ 0x1134
IP: Source A4dre*a - 10.0.0.«0
IP: Destination Addxtst ¦ 10.0.0.10
Pi.liU о 131 @*S3)
¦IP: Loot* Source Boucing Option
IP: Option L«a9Ch • 7 @x7)
. -II:. Rout* Го Co • 10 (OxJJ
J ¦"-¦'"' *"-
00000000 00 90 Zt 64 Ti, »« 00 90 27 64 FI BF 06 00 47 00
00000010 00 44 А.Э 21 00 00 ZO 01 II 34 0A 00 00 ЭС OA 00
00000020 00 0A fcb»TiУМЛЦЗДJfr|'flf«flP|tfiflfiTflJQ9 00 ZT SC 01 00
000000Э0 II» 00 61 «2 S3 C4 65 66 67 68 69 6A €B 6C 6D 61
00000040 67 70 71 72 73 74 ?$ ?6 77 61 $Z «Э ?4 «5 66 67
00000050 66 69
•^anoui octiens for W» IP packet
if A.22E4
|l№3»(»22)
Рис. 2.7. Выделен параметр неопределенной маршрутизации от источника
IP: Route To Go = 10 (ОхА)
IP: Gateway = 10.0.0.60
IP: End of Options = 0 @x0)
IP: Data: Number of data bytes remaining = 40 @x0028)
Поле длины параметра, приведенное выше, равно длине в байтах, полу-
полученной 131 параметром. Это поле задается посылающей машиной. В дан-
данном случае используется семь байтов для параметра неопределенной
маршрутизации источника. Указатель маршрутизации используется для
определения сдвига октета в полях параметра 131 для указания, где начина-
начинаются данные маршрутизатора. Здесь мы пропускаем четыре байта с начала
поля параметра и видим IP-адрес первого маршрутизатора в шестнадцате-
ричном представлении. Это выделено на рис. 2.7. Если посмотреть на шест-
надцатеричную панель (внизу экрана), можно увидеть, что поле параметра
начинается с 83 (шестнадцатеричного значения 131, кода параметра неоп-
неопределенной маршрутизации источника). Теперь сдвиг определен как 04,
что сообщает, где в данных расположен IP-адрес первого маршрутизатора.
Отсчитывая от 83 четыре числа, мы получаем ОА A0 в шестнадцатеричном
представлении), что будет первым октетом IP-адреса маршрутизатора.
Можно заставить PING использовать неопределенный маршрут от ис-
источника, применяя параметр -j. Команда будет выглядеть как PING -j
10.0.0.10 10.0.0.60. Первый адрес определяет место назначения, а второй и

82
Глава 2
"i C:\WINNT\Suslem32\cmd еке
::S>pin» -j 207.78.244.6 imu.JHharris.com
inging juliarris.con B16.23.2.1401 with 32 bytes of data:
equest tined out.
equest tined out.
equest tined out.
equest tined out.
Рис. 2.8. Параметр неопределенной маршрутизации от источника определяет
маршрут к месту назначения
следующие адреса являются маршрутизаторами для использования в на-
направлении к месту назначения. Это показано на рис. 2.8.
Параметр точной маршрутизации от источника Этот параметр очень
похож на неопределенный маршрут от источника. Как можно видеть в рас-
распечатке ниже, поля выглядят почти идентично параметру неопределенной
маршрутизации. Имеется поле кода параметра, который в данном случае
содержит 137. Это код параметра точной маршрутизации от источника. Он
равен 0x89 в шестнадцатеричном представлении, что видно в распечатке.
Следующее поле определяет длину параметра, которая в данном случае так-
также равна семи. Она будет меняться в зависимости от числа переходов, ко-
которое будет определено для места назначения. Это задается посылающей
машиной так же, как и прежде. Указатель маршрутизации используется для
отметки начала данных для первого маршрутизатора, как было и в случае
параметра неопределенной маршрутизации от источника.
Можно использовать точную маршрутизацию от источника с целью тес-
тестирования, используя команду PING с параметром -к. Например, можно
ввести PING -к 10.0.0.10 10.0.0.60. Первый адрес определяет место назначе-
назначения, а второй и последующие адреса являются маршрутизаторами для ис-
использования в направлении места назначения. Что-нибудь подобное нельзя
сделать с помощью команды TRACERT.
IP: ID = 0XA32E; Proto = ICMP; Len: 68
IP: Version = 4 @x4)
IP: Header Length = 28 (OxlC)
+ IP: Service Type = 0 @x0)
IP: Total Length = 68 @x44)
IP: Identification = 41774 @xA32E)
+ IP: Flags Summary = 0 @x0)

Стек протоколов TCP/IP 83
IP: Fragment Offset = 0 @x0) bytes ,
IP: Time to Live = 32 @x20)
IP: Protocol = ICMP - Internet Control Message
IP: Checksum = 0xlE34
IP: Source Address = 10.0.0.60
IP: Destination Address = 10.0.0.10
IP: Option Fields = 131 @x83)
IP: Loose Source Routing Option = 131 @x83)
IP: Option Length = 7 @x7)
IP: Routing Pointer = 4 @x4)
IP: Route To Go = 10 (OxA)
. . IP: Gateway = 10.0.0.60
IP: End of Options = 0 @x0)
IP: Data: Number of data bytes remaining = 40 @x0028)
Параметр отметки времени Интернета Этот параметр работает ана-
аналогично параметру записи маршрута в том смысле, что посылающий узел со-
создает последовательность пустых пробелов, которые заполняются
маршрутизаторами на пути к месту назначения. Записи являются IP-адресом
маршрутизатора и отметкой времени. Отметка времени — это 32-битное це-
целое число, которое является числом миллисекунд, прошедших с полуночи
универсального (т.е. гринвичского) времени. Если универсальное время не-
недоступно маршрутизатору, то он может использовать что-то другое, но дол-
должен указать, что используется не универсальное время, задавая старший бит
в поле отметки времени равным 1. Код параметра равен 68 @x44). Он сооб-
сообщает, что используется параметр отметки времени Интернета. Поле длины
параметра задается посылающей машиной, но оно имеет максимальную дли-
длину 40 октетов, включая поля типа параметра, длины, указателя и флага пере-
переполнения. Как можно видеть в листинге, поле указателя времени сообщает,
где начинается отметка времени. Это смещение от начала поля параметра
68. Наименьшее законное значение для этого поля равно пяти, что показано
в приведенной ниже распечатке.
Следующее поле — это поле флага, использующее 0 для записи только
отметки времени без IP-адресов, 1 для записи отметки времени с IP-адре-
IP-адресом и 3 для определения посылающего узла и отметки времени, если он со-
соответствует IP-адресу следующего маршрутизатора. В распечатке ниже
задан флаг 1, это значение используется чаще всего.
Размер этого параметра не изменяется с числом собранных отметок
времени. Если выделенная для отметок времени область будет исчерпана,
то будет увеличиваться поле пропущенных станций. Поля шлюза и точки
времени используются для хранения IP-адреса и отметки времени. Они за-
заполняются маршрутизатором при ответе на дейтаграмму.
IP: ID = 0xC4BA; Proto = ICMP; Len: 72
IP: Version = 4 @x4)
IP: Header Length = 32 @x2 0)
+ IP: Service Type = 0 @x0)
IP: Total Length = 72 @x48)
IP: Identification = 50362 @xC4BA)

84 Глава 2
+ IP: Flags Summary = 0 @x0)
IP: Fragment Offset = 0 @x0) bytes ¦ ..
' . IP: Time to Live = 32 @x20)
¦,..'.-¦ ;.'¦ IP: Protocol = ICMP - Internet Control Message
IP: Checksum = 0x57El
¦¦•'¦ " :• IP: Source Address = 206.112.203.201
IP: Destination Address = 206.112.201.97
IP: Option Fields = 68 @x44) ';'
¦ IP: Internet Timestamp Option = 68 @x44)
IP: Option Length = 12 (OxC)
¦ ¦ , . ; . IP: Time pointer = 5 @x5)
..,'-¦- IP: . . 0001 = Одновременно отметки времени
• ¦ '..- ¦;' ... ' и адреса IP
:,:.';-¦- IP: Missed stations = 0 @x0)
; . ; •:, IP: Time Route = 0 @x0) :
¦';"''- . v" ' ¦¦'¦¦'-¦¦'¦¦¦ IP: Gateway = 0.0.0.0 ' ¦/"'-.:¦¦
T^~"~7>~+— IP. Time point = о @x0) ¦ -
IP: Gateway = 8:0:88:91
IP: Time Point = 50393600 (Ox300F200)
IP: Data: Number of data bytes remaining = 40 @x0028)
Обзор главы
В этой главе был рассмотрен большой материал, значительная часть кото-
которого обсуждалась достаточно подробно. Время, затраченное на изучение
этой главы, окупится сторицей при попытке найти причину возникшей
проблемы или настроить сеть. Знание протоколов, определяющих части
кадра, пакета или дейтаграммы, является критически важным в любой
ситуации.
В следующей главе
В следующей главе будет рассмотрен стек протоколов SPX/IPX. Подробно
будет обсуждаться структура заголовков обоих протоколов. Будет проана-
проанализирована функция сетевых номеров и зарезервированные сетевые номе-
номера, а также номера сокетов и маршрутизация IPX. Завершится глава
изучением структур заголовков сообщений.

Глава 3
Стек протоколов SPX/IPX
Стек протоколов SPX/IPX все еще широко распространен во многих кор-
корпоративных сетях. Это быстродействующий компактный набор протоко-
протоколов для операционной системы Novell NetWare. Довольно эффективный,
этот протокол может выполнять маршрутизацию. Мы собираемся рассмот-
рассмотреть его и некоторые связанные с ним вопросы. Сначала познакомимся с
такой важной частью стека SPX/IPX, как протокол SPX (Sequenced Packet
Exchange — Протокол последовательного обмена пакетами).
Протокол SPX ,
Протокол SPX — это протокол с поддержкой соединения, который обычно
действует поверх протокола IPX (Internetwork Packet Exchange — Протокол
межсетевого обмена пакетами). Он похож по функциональности на прото-
протокол TCP из стека TCP/IP. SPX предоставляет управление соединением для
двусторонней коммуникации, обеспечивая тем самым устойчивый поток
данных. Он имеет возможность устанавливать соединение с одноранговым
узлом на другой машине, согласовывать размер буфера и обеспечивать прави-
правильную доставку и получение данных. Для этого он использует номера последо-
последовательности и комбинацию подтверждений (ACKS) и не подтверждений
(NAKS). Он не выполняет, однако, согласования размера пакета, как это де-
делает TCP (хотя SPXII способен выполнять согласование размера пакета).
Заголовок SPX
Рассмотрим теперь 12-байтовый заголовок SPX. Трассировка сетевого мо-
монитора на рис. 3.1 показывает, где находится SPX. По сути, здесь имеется
заголовок Ethernet, заголовок IPX и заголовок SPX.

86
Глава 3
?drt
ОЛсар lde>\616l cap Не»!
Tods Qptoa Wr«ta*
*!ff^jj
!¦?
ЕЛ1Г
J37
46
41
!48
3S6. 3d!
3S6.38!
354.Э9<
356.40(
3S6.«0(
356.40E
3S6.40!
3S6.40!
0Q609720F46D
C0MPAQA63A32
ЭСОН 3FA631
0060972GM6D
C0HPAQA63A32
00S09720F46D
00609777C86C
COKPAQA63A32
006097207460
C0hPAQA63A32
C0KPAQA63A32
00609720F46D
СОИРА0А63А32
00€0S7Z0F<6D
С0КРАОА6ЭА32
ЗРХ
SHB
SHB
SHB
SHB
MBIPX
FID • 0x7001, P-e*d 0x4 «t ОхОООООЗХА
OzOO, 0X6DA2 ~> 0x5374,
FID - 0x7001, B»*d 0x4 at 0x00000311
FII> * 0x7001, R*a
P«*d 0x4 ot 0x4
&»t.*, K««p Allv*
0x4 *t 0>000003FZ
У
J
(tiu prop«rci*c
802.3 L«n«th - «0
.4001 -> 1.000000300001.600S - 0 Hop*
SPX: Connection conceal
128 (OxBO)
SPX: 1 - 2у*г«а Packet
SPX: .0 * Acknovl«do*»*nt. Hoc ft*quired
SPX: . .0 • Ho Attention
SPX: ...0.... * Not. Ind o( !I«ff*gi
SPX: 0 .. «Hoc *л SPX IX P«ck«t.
SPX: Хялл 9Х.Х9ШШ сур* • 0x00
SPX: Source Connection * 27298 @«6AA2)
SPX: D**cin*CLon Connection - 21361 (OxS371)
SPX: Secfucnce number « 2 <OxZ)
SPX: Ackno«i«dij# тшЬег ¦ 2 @x2)
SPX: Allocation number ¦ 5 {OxSI
SPX: &*t»: Mu*kb*r of dexa by^es
i.nlna ¦ 4 @x0004)
а&^гужяу*екжк*й
00000000 00 80 SI k6 3k 32 00 20 AF 3F A6 31 00 2A FF FF
00000010 00 2A 00 05 00 00 00 01 00 00 00 00 00 OWO 05
00000020 00 00 30 01 00 20 AF 3F A< Э1 40 01
ооооооэо ИЖ1ЖЛ^Ш|ТЛ|НМ
oo 07 oo
Рис. 3.1. Заголовок SPX следует за заголовками Ethernet и IPX ; \ * ¦ ¦ ¦
Заголовок SPX состоит из следующих семи полей: . •-,.¦¦¦'¦¦
• Управление соединением — 1 байт
• Тип потока данных — 1 байт " '
• Идентификатор соединения источника — 2 байта
• Идентификатор соединения места назначения — 2 байта
• Номер последовательности - 2 байта ., .
• Номер подтверждения — 2 байта ¦ ¦¦:¦
• Номер размещения — 2 байта
Управление соединением Остановимся на некоторых функциях,
предоставляемых полем управления соединением. Эквивалент флагов TCP,
которые были показаны в главе 2, управление соединением предоставляет
механизм двунаправленного потока данных, управления перегрузкой и дру-
другие связанные с этим возможности. Поле управления соединением указыва-
указывает три типа пакетов управления соединением. Эти значения могут быть
либо логическими, либо могут быть заданы вместе с несколькими флагами.
Сначала рассмотрим флаг конца сообщения.

Стек протоколов SPX/IPX 87
• Флаг "Конец сообщения" (End-of-message). Этот флаг устанавливается,
когда в поле управления соединением появляется 0x10. Он использу-
используется для указания конца сообщения партнеру по передаче. Так как
SPX является транспортным протоколом на основе сообщений, посы-
посылающая сторона задает этот флаг для указания, что сообщение завер-
завершено. После того как получающая сторона получит этот пакет, она
передаст данные в буфер сообщения вышележащего приложения. Это
не запрос конца соединения, но скорее указание, что текущий обмен
сообщениями закончился.
• Флаг "Требуется подтверждение" (Acknowledgment-Required). Флаг
требования подтверждения устанавливается, когда в поле управления
соединением появляется 0x40. Он используется для указания, что дан-
данные были посланы партнеру по передаче и требуется подтверждение.
Прежде чем будут отправлены новые данные, должно быть получено
подтверждение для этого пакета.
• SPX требует подтверждения посланных данных; когда они получены,
устанавливает флаг, сигнализирующий "конец сообщения" для парт-
партнера. Число является комбинацией 0x40 и 0x10 и равно 0x50.
• Флаг "Системный пакет" (System-Packet). Флаг системного пакета уста-
устанавливается, когда в поле управления соединением появляется 0x80.
Это пакет подтверждения, используемый внутренне протоколом SPX
для подтверждения, что партнер по сеансу работает и соединение
существует. Это сообщение типа "Я здесь".
• Флаг "Комбинация системных пакетов" (System-Packet combination).
Флаг комбинации системных пакетов устанавливается, когда в поле
'¦;' управления соединением появляется ОхСО. ОхСО является суммой
0x80 и 0x40. Он используется внутренне протоколом SPX, показывая,
что соединение все еще существует, требуя подтверждения (АСК) от
партнера по коммуникации. Это пакет типа "Вы еще здесь?".
Тип потока данных Тип потока данных (DataStream) сообщает, какой
тип данных переносится внутри пакета. Он может быть задан как специаль-
специальное число, определенное приложением через Winsock. Самой важной фун-
функцией этого поля является обеспечение аккуратного разъединения сеанса.
По умолчанию это будет одно из двух следующих сообщений:
• Конец соединения (End-of-Connection). Если тип потока данных задан
как OxFE, то партнер по сеансу хочет прекратить сеанс.
• Конец соединения (End-of-Connection). Если тип потока данных за-
задан как OxFF, то пакет передается, так как был получен запрос конца
соединения.
Некоторые из других записей, встречающиеся в этом поле, включают
числа, перечисленные в таблице 3.1.

88 Глава 3
Таблица 3.1. Употребительные типы полей потока данных
Номер поля Значение
0 Часть данных пакета содержит информацию, которую
необходимо распечатать.
1 .¦•... Остановить печать и очистить буферы.
2' Остановить печать, но сохранить текущие данные
и подождать дополнительных инструкций.
'3 "¦'¦ Перезапустить задание печати, используя буферы
данных.
4 Остановить печать из буферов данных и использовать
данные, зарегистрированные в боковой полосе. Поле
данных боковой полосы имеет три функции: (а) счетчик,
(Ь) символ для печати и (с) конечный символ.
5 Начало нового пакета задания печати.
6 Передает управление процессу, а не серверу печати.
7 Извлекает принтер из процесса и возвращает его
.., серверу печати.
8 ¦''• Конец задания. ; '. ,,.
254 Конец соединения.
255 АСК конца соединения.
Идентификатор соединения источника и места назначения Это тре-
третье и четвертое поля из семи полей заголовка SPX. Поля идентификаторов сое-
соединения источника и места назначения занимают два байта и используются для
демультиплексирования сеансов SPX через единственный сокет на уровне IPX.
Если идентификатор соединения места назначения задан как 0XFFFF, значит,
это пакет начального соединения.
Порядковый номер Пятое поле в заголовке SPX является полем по-
порядкового номера. Это двухбайтовое поле, содержащее счетчик передан-
переданных пакетов данных. Это число будет увеличиваться после получения
подтверждения о передаче пакета данных.
Номер подтверждения Шестое поле является полем номера под-
подтверждения, сообщающим номер последовательности следующего пакета
SPX, который ожидается от партнера SPX.
Номер размещения Последнее поле заголовка SPX является полем
номера размещения. Это поле сообщает номер буфера получения, который
доступен на рабочей станции. Этот номер почти всегда больше, чем номер
подтверждения. Доступность свободных буферов вычисляется, как размер
окна, который равен номеру размещения минус номер подтверждения
плюс один. Это поле используется как механизм управления потоком. Он
работает следующим образом. Когда получающая сторона посылает номер

Стек протоколов SPX/IPX 89
размещения меньше номера подтверждения, отправитель не будет больше
посылать данные, пока получающая сторона не пошлет пакет с номером
размещения больше номера подтверждения.
Пример создания соединения Трассировка сетевого монитора, при-
приведенная ниже, показывает последовательность успешной инициализации
сеанса. Отметим, что идентификатор соединения места назначения задан
как OxFFFF, а номер размещения как OxFFFF. Эта последовательность пакетов
называется квитированием SPX.
SPX: ConCtrl = OxCO, DtaStrm = 0x00, 0хЕ8А2 -> OxFFFF, Seq = 0,
Ack = 0, Alloc = 65535
SPX: ConCtrl = 0x80, DtaStrm = 0x00, 0x9774 -> 0xE8A2, Seq = 0,
Ack = 0, Alloc = 3
Пример обычного потока данных Трассировка сетевого монитора,
приведенная ниже, показывает успешную передачу данных. Отметим, как
связаны Seq и АСК, и что номер размещения (Alloc) всегда больше АСК.
SPX: ConCtrl = 0x80, DtaStrm = 0x00, 0x9774 -> OxFFFF, Seq = 7,
Ack = 8, Alloc = 9
SPX: ConCtrl = 0x50, DtaStrm = 0x00, 0x9774 -> 0xE8A2, Seq = 8,
Ack = 7, Alloc = 10
SPX: ConCtrl = 0x80, DtaStrm = 0x00, 0xE8A2 -> 0x9774, Seq = 7,
Ack = 9, Alloc = 10
SPX: ConCtrl = OxCO, DtaStrm = 0x00, 0x9774 -> 0xE8A2, Seq = 9,
Ack = 7, Alloc = 10
Пример "культурного" закрытия сеанса Трассировка сетевого мо-
монитора, приведенная ниже, показывает успешную последовательность пре-
прекращения сеанса. Отметим, что задается поле DtaStrm для указания конца
запроса соединения и ответа.
SPX: ConCtrl = 0x50, DtaStrm = End of Connection Req., 0xE8A2 ->
0x9774, Seq = 10, Ack = 10, Alloc = 12
SPX: ConCtrl = 0x00, DtaStrm = End of Connection Resp., 0x9774 ->
0xE8A2, Seq = 10, Ack = 11, Alloc = 14
Общие рекомендации по чтению трассировок SPX Следующие ре-
рекомендации могут оказаться полезными при выделении проблемы.
• Можно видеть несколько идентификаторов сеансов, приходящих с од-
одного компьютера. Попробуйте изолировать трассировку для опреде-
определенного идентификатора сеанса, чтобы проверить его правильность.
• Посмотрите на число переходов и сравните физический уровень
Ethernet с Token Ring. Проблема может быть связана с промежуточ-
промежуточными маршрутизаторами или с размером пакета. Помните, что SPX
не выполняет согласования пакетов.
• Обратите внимание на номер размещения и проверьте, что он боль-
больше номера подтверждения. Это проверка того, что отсутствует ка-
какая-либо проблема, связанная с переполнением буфера. В основном
это происходит с 16-разрядными клиентами в реальном режиме.

90 Глава 3
• Проверьте все повторные передачи пакетов данных. Обычно пробле-
проблема повторной передачи проявляется как вопрос производительности.
Проверьте интервал времени между отправкой данных и получением
пакета АСК, чтобы проверить наличие временной задержки.
Ограничения протокола SPX Хотя SPX предоставляет транспорт
с поддержкой соединения, SPX имеет несколько ограничений.
• Только один пакет может ожидать в любой момент времени. ! ¦'
• Коммуникация на основе SPX не делает никакого согласования пакета.
ВНИМАНИЕ! Приведенные выше ограничения применимы только к про-
протоколу SPX. SPX П является усовершенствованной версией SPX
со следующими изменениями:
• SPX II использует максимальный размер пакета, допустимый сетью.
Пример: 1518 байтов для Ethernet (SPX имеет максимум 576 байтов).
• Окна SPX II допускают несколько ожидающих пакетов и позволяют
передавать отрицательное подтверждение (NAK), чтобы указать, что
некоторые пакеты не были получены.
• SPX II допускает согласование пакетов. Пакет запроса согласования
размера может посылаться в любое время в процессе коммуникации,
если пакеты не доходят до места назначения.
Идентификатор соединения с источником Это поле содержит двух-
двухбайтовый номер соединения SPX, присвоенный станцией источника SPX и
используемый для отслеживания различных виртуальных соединений SPX,
которые может поддерживать сокет. Этот номер появится в идентификаторе
соединения места назначения, когда прибудут пакеты от партнера по соеди-
соединению для этой станции.
Идентификатор соединения с местом назначения Это поле содер-
содержит двухбайтовый номер соединения SPX, присвоенный станции места на-
назначения SPX. Он используется для отслеживания различных виртуальных
соединений SPX, которые может поддерживать сокет. Этот номер появит-
появится в идентификаторе соединения источника, когда пакеты посылаются
партнеру по соединению.
Порядковый номер SPX присваивает порядковый номер каждому
пакету данных, посланных партнеру по соединению. Этот номер увеличива-
увеличивается, когда пакет данных подтверждается, что обеспечивает упорядоченную
передачу пакетов из источника в место назначения партнера по соедине-
соединению. Это поле не увеличивается для пакетов, которые не содержат данных
(системных пакетов).
Номер подтверждения Это ожидаемый номер последовательности
для следующего пакета данных от партнера по соединению в месте назначе-
назначения. Это поле не увеличивается для пакетов, которые не содержат данных
(системных пакетов).

Стек протоколов SPX/IPX 91
Номер размещения Этот номер используется для вычисления количе-
количества доступных для получения пакетов буферов, посланных из места назна-
назначения соединения. Он соответствует номеру последовательности пакета,
который подготовлен для отправки, но еще не послан. Источник соедине-
соединения не может превысить номер размещения. Когда источник соединения ге-
генерирует ЕСВ (блок управления событиями) приема, SPX увеличивает
номер размещения. Это поле не увеличивается для пакетов, которые не
содержат данных (системных пакетов).
Данные Запись данных (если они присутствуют) содержит любые
данные или коды, которые посылаются на сервер и с сервера.
Поле сокета указывает пакет SPX, посылаемый клиентом на сервер. Со-
кет клиента сервера будет 8060. Пакет содержит также некоторые имею-
имеющие отношение к SPX данные для целей соединения. Запись управления
соединением в заголовке SPX показывает код COh, означающий, что пакет
является системным пакетом, который требует подтверждения от сервера
при получении.
,; t--:-X "Ъ'-'^-f . *й. ¦"-,-"•...¦¦¦•¦.¦¦•- .*>¦¦¦«¦. -.-¦¦ •¦•. г- ¦¦;--р|<":«11 ¦'»•-'?
Протокол IPX
Протокол IPX является протоколом третьего уровня без поддержки соеди-
соединения, предназначенным для передачи дейтаграмм. Компания Novell адап-
адаптировала его из старого протокола межсетевых дейтаграмм (протокол IDP)
-стека Xerox (XNS).
Протокол без соединения
Поскольку он является протоколом без поддержки соединения, то когда
процесс, выполняющийся на определенном узле, использует IPX для комму-
коммуникации с процессом на другом узле, между двумя узлами не устанавливает-
устанавливается соединение. Таким образом, пакеты IPX адресуются и посылаются к
своему месту назначения, но нет гарантии или проверки успешной достав-
доставки. Любое подтверждение пакета или управление соединением обеспечива-
обеспечиваются протоколами выше IPX, такими как SPX. Термин дейтаграмма
означает, что каждый пакет интерпретируется как отдельная сущность, не
имеющая логической или последовательной связи с любым другим пакетом.
Работа на сетевом уровне модели 0SI
Как протокол сетевого уровня IPX адресует и маршрутизирует пакеты из од-
одного местоположения в другое при межсетевом обмене IPX. IPX принимает
решения о маршрутизации, просматривая поля адресов заголовка и на осно-
основе информации, которую он получает из RIP или NLSP. IPX использует эту
информацию для пересылки пакетов в их узел назначения или следующему
маршрутизатору, предоставляющему путь к узлу назначения.

92
Глава 3
Структура пакета .
Так как протокол IPX был адаптирован из старого протокола XNS ГОР, не
удивительно, что их структуры похожи. Пакет IPX состоит из двух частей.
Первая часть является 30-байтовым заголовком, который содержит адре-
адреса сети, узла и сокета для машин источника и места назначения. Вторая
часть является разделом данных, который иногда содержит заголовок
протокола более высокого уровня, такого как SPX. Минимальный пакет IPX
имеет 30 байтов (не считая заголовок MAC). Максимальный размер маршру-
маршрутизированных пакетов IPX обычно имеет только 576 байтов, включая заго-
заголовок IPX и нагрузку данных. Однако при использовании IPX II это число
возрастает до 1500 байтов.
Как было отмечено в главе 2 о TCP, сетевой уровень следует за заголов-
заголовком MAC, поэтому IPX помещается после заголовка MAC и перед полезной
нагрузкой. На рис. 3.2 показано, что заголовок IPX помещается внутри про-
протокола MAC таким же образом, как описано в главе 2. ... ,
Network Momloi IDVcap lilet\61G1
?* B«P<« I«* fiptont Window Help
jafii \
|_|е|х|
Vrema
3?
эв
iTiat Src НАС Addt
356. 383QQ$Q9?2OM6D
Ь«. MAC Addr IProe
C0JlPAQAb3A32 I SUB
00*09?20F46D |sHB
read, ПС - 0x7001, *e»d 0x4 *t Ox000003U.
r«*d, Head 0x4 ot 0x4
Base 1х*мт properties
«•ITHIRMIT: вОг.Э Length - 60
-ITHI1UT1T. D.*tiu.cion Kd4r«*s : 0080SFA63A3Z
BTHIBKST: 0 - XndLvidukl *ddr*s.
1ТИЖВКЖТ: 0, • Univet««lly iMlmiaixtered *ddr*ct
-17Н1Ы1П: Souxc* »ddr«»» ; QQZ0Xt3Tk63i '
1ТН11ШЖТ: 0 <• No routine infor»*cion pr**#nc
ITHIRJfIT: 0. ¦ Universally »4»lnJ.*c*r*d addr*s*
«rHIRjfIT: Гхтшш L*n«ch : 60 <OsOO3C)
XTHIAirtT: D»t» L«ugcb : 0i002A D2 >
JTHIWflT: lch*rn«c I>»c»: Vu»b*r o( d*t.s byt-** tcuiiung - -tfi (OxO0ZI>
•IPX; SpX P»ck#c - 3001.00г0АГЭГА631.4001 -> I.000000000001.600S - 0 Hop*
IPX: Ch»cksuxi - «5&Э5 (.QxTttt)
IPX: IDP t«Mjrch - 42 @x2A)
IPX: Transport, control • 0 @x0)
IPX: P*ck*b cyp* * SPX .'
•-IPX: DiftlMdon Addr«fi Зихшагу 1.000000000001.6005
IPX: IPX Addr«ss ¦ 00000001.000000000001
IPX: D«ebin*tion V*c »uab*r - 1 @x1)
IPX: D«*cin*t.lDn Sock»c Hu«b«r - 0x6005
IPX: Source Net Kumber - 12Z8S @x3001)
IPX: Source Socket Number ¦ 0x4001
IPX: L>*c»: llukbex of d*te. bycis re»kinlag - 12 @«0O0C)
lL _ ;._
30000000 00 80 SF кб ЗА 32 00 20 AF 3F k€ 31 00 ZX ft ?F
10000010 00 2A 00 05 00 00 00 01 00 QO 00 00 00 01 60 OS
$_»:2. »?*!.•
irF»:"l/23330
4
Рис. 3.2. Заголовок IPX помещен внутри протокола MAC
Рассмотрим структуру заголовка IPX. Он состоит из следующих полей:
• контрольная сумма (checksum)
• длина пакета (packet length)

Стек протоколов SPX/IPX
93
• управление транспортом (transport control) ••- •¦¦¦•:...
• тип пакета (packet type) :
• сеть назначения (destination network) .^
• узел назначения (destination node) •¦ ¦¦
• сокет назначения (destination socket)
• сеть источника (source network)
• узел источника (source node) • : '¦ •
• сокет источника (source socket)
Контрольная сумма Поле контрольной суммы используется для обес-
обеспечения целостности пакета. Контрольная сумма используется новыми вер-
версиями Netware, так как 3.x и более ранние версии задают поле как OxFFFF и
не используют контрольную сумму.
Длина пакета Поле длины пакета является длиной заголовка IPX
плюс длина данных в байтах. Длина пакета должна быть не менее 30 байтов,
чтобы предоставить достаточно места для заголовка IPX.
Управление транспортом Управление транспортом является числом
маршрутизаторов, которые пересек пакет на пути к месту назначения. Посы-
Посылающие узлы при создании пакета IPX всегда задают это поле как ноль. Ког-
Когда маршрутизатор получает пакет, требующий дальнейшей маршрутизации
для достижения конечного места назначения, значение поля увеличивается
на единицу и пакет передается дальше.
Тип пакета Поле типа пакета указывает вид службы, которая либо
предлагается, либо требуется пакету. В таблице 3.2 перечислены некоторые
часто используемые типы пакетов, которые могут встретиться в трассиров-
трассировках сетей.
Таблица 3.2. Типы пакетов IPX/SPX
Тип пакета
NLSP
Информация
маршрутизации
Объявление службы
Упорядоченный
NCP
Распространенный
Значение поля
(шестнадцатеричное)
0x00
0x01
0x04
0x05
0x11
0x14
Назначение
Пакеты NLSP
Пакеты RIP
Пакеты SAP ¦<<¦.''
Пакеты SPX
Пакеты NCP
NetBIOS и другие
распространяемые пакеты

94 ' Глава 3
Сеть назначения Сеть назначения является номером сети, к которой
присоединен узел назначения. Когда посылающий компьютер задает это поле
как 0x0, предполагается, что узел назначения находится в том же сетевом
сегменте, что и посылающий узел.
Существует особый случай, когда рабочая станция посылает широковеща-
широковещательные запросы протоколов маршрутизации SAP — Get Neareast Server
(Найти ближайший сервер) и RIP — Get Local Target (Найти локального по-
получателя) (или Route Request — Запрос маршрута) во время инициализации.
Так как рабочая станция еще не знает, к какой сети принадлежит, она задает
поля сети источника и сети назначения как 0 для этих запросов. Когда марш-
маршрутизатор получает один из этих запросов, он посылает ответ непосредст-
непосредственно посылающей рабочей станции, заполняя поля сети источника и сети
назначения соответствующими сетевыми номерами.
¦ ¦ f , . . ¦. ¦ ' , '
ВНИМАНИЕ! IPX не имеет номера сети широковещания (такого как
OxFFFFFFFF).
В дополнение к сетевому номеру 0 номера OxFFFFFFFF и OxFFFFFFFE
зарезервированы для специальных целей. В связи с этим они не должны
назначаться никакой сети IPX. Дополнительную информацию о зарезер-
зарезервированных сетевых номерах можно найти ниже в разделе о зарезервиро-
зарезервированных номерах. ¦"'¦ ¦ ¦'
Узел назначения Поле узла назначения содержит физический адрес
узла назначения. Узел в сети Ethernet будет использовать все шесть байтов
этого поля для определения своего адреса. Некоторые другие методы до-
доступа к сети могут использовать здесь меньше шести байтов. Адрес узла
OxFFFFFFFFFFFF (т.е. шесть байтов по OxFF) посылает пакет всем узлам в
сети назначения. . • ¦ • ¦ . .
Сокет назначения Поле сокета назначения является адресом сокета
процесса назначения пакета. Эти сокеты будут направлять пакеты в различ-
различные процессы внутри одной машины. _ . . .¦
Л" f . . I"
ВНИМАНИЕ! IPX не имеет широковещательного номера сокета
(например, OxFFFF).
Сеть источника Поле сети источника является номером сети, к кото-
которой присоединен узел источника. Если посылающий узел задает это поле
равным нулю, это означает, что локальная сеть машины источника неизве-
неизвестна. Для маршрутизаторов правила, применяемые к полю сети назначе-
назначения, также применимы к полю сети источника, за исключением того, что
маршрутизаторы могут пересылать полученные пакеты, у которых это поле
задано как ноль.
Узел источника Поле узла источника — это адрес MAC узла источника.
Адреса широковещания недопустимы.

Стек протоколов SPX/IPX 95
Сокет источника Сокет источника — это адрес процесса, передающе-
передающего пакет. Процессам, общающимся при равноправном соединении узлов,
не требуется посылать и получать один и тот же номер сокета. В сети рабо-
рабочих станций и серверов сервер обычно "ожидает" на определенном сокете
запросы на обслуживание. В таком случае сокет источника не обязательно
тот же самый или вообще имеет значение. Важно только, чтобы сервер от-
ответил сокету источника. Например, все файловые серверы NetWare имеют
один и тот же адрес сокета, но запрос к ним может исходить из сокета с лю-
любым номером.
Номера сокетов источников следуют тем же соглашениям, что и сокеты
места назначения.
Заголовки протоколов более высокого уровня Заголовки протоко-
протоколов более высокого уровня принадлежат таким Протоколам, как NCP или
SPX. Они часто встречаются в части данных пакета IPX.
Адресация IPX
Теперь рассмотрим адресацию IPX. Как показано в таблице 3.3, IPX имеет
свою собственную адресацию узлов (для внутрисетевой работы) и внутриуз-
ловую адресацию. Для адресации узла IPX использует адрес MAC, который
был присвоен карте сетевого интерфейса производителем самой карты.
Таблица 3.3. Структура
Сетевой номер
00000001
адреса
IPX
Адрес MAC
006008A1D4B4
Номер
435
сокета обработки
Сетевой адрес IPX уникальным образом идентифицирует сервер IPX в
сети IPX и отдельные процессы внутри сервера. Адрес IPX является 12-бай-
12-байтовым шестнадцатеричным числом, которое можно разделить на три части.
Первая часть адреса IPX — самая длинная, это шестибайтовый аппаратный
адрес сетевого адаптера. Последняя часть является двухбайтным номером
сокета, который используется для ссылки на реальный выполняющийся
на машине процесс. В таблице 3.3 показано, как выглядит этот адрес.
Каждый номер в адресе IPX содержится в поле в заголовке IPX и представ-
представляет сеть источника или места назначения, узел или сокет. Сетевой номер ис-
используется только для операций сетевого уровня, а именно, маршрутизации.
Номер узла используется для локальной (или в том же сегменте) передачи
пакетов. Номер сокета направляет пакет в процесс, действующий внутри
узла.
Каждый адресный компонент описывается в следующих разделах.
Сетевой номер
Четырехбайтовый шестнадцатеричный адресный сетевой номер IPX испо-
используется для маршрутизации пакетов IPX. Каждому сегменту присваивается
уникальный сетевой номер, используемый маршрутизатороми для пере-
пересылки пакетов к их конечному месту назначения в сети.

96 Глава 3
Сетевой номер IPX может содержать до восьми цифр, включая нули,
хотя ведущие нули обычно не выводятся. Например, 0x00003001,
0x12345678 и 0хВ9 являются действительными сетевыми номерами.
Зарезервированные сетевые номера
Сеть назначения пакета IPX является обычно сетью IPX, которой был при-
присвоен уникальный сетевой номер. Однако три сетевых номера: 0x0,
OxFFFFFFFF и OxFFFFFFFE зарезервированы, так как они имеют специальные
значения. В таблице 3.4 перечислены эти номера.
Таблица 3.4. Зарезервированные сетевые номера
Номер Значение
0x00000000 Локальный сетевой сегмент. Когда маршрутизатор получает
.. .. пакет с идентификатором сети назначения равным О,
то источник и место назначения считаются находящимися
в одном сегменте.
OxFFFFFFFF Это пакет запроса всех маршрутов. Когда маршрутизатор
получает пакет с идентификатором сети назначения равным
FFFFFFFF, он сообщает все маршруты, о которых знает.
OxFFFFFFFE Это используемый по умолчанию маршрут, который является
местом назначения для всех пакетов IPX, которые имеют
неизвестную сеть назначения.
RIP и NLSP распознают OxFFFFFFFE как используемый по умолчанию
маршрут. В сети RIP маршрутизатор RIP, который соединяет LAN с большей
сетевой инфраструктурой, такой как корпоративная магистраль, обычно
объявляет используемый по умолчанию маршрут.
Внутренний сетевой номер
Службы Microsoft для NetWare, а также серверы NetWare 3.x и 4.x использу-
используют внутренний сетевой номер. Этот шестнадцатеричный номер должен
быть длиной от одной до восьми цифр. Обычно он присваивается при уста-
установке. Внутренний сетевой номер используется для служб и маршрутизации
пакетов IPX в физических сетях.
Номер узла
Номер узла является шестибайтовым шестнадцатеричным числом, исполь-
используемым для уникальной идентификации устройства в среде IPX. Это число
идентично физическому адресу платы сетевого интерфейса, который сое-
соединяет устройство с сетью.
Заголовок IPX содержит поля узла назначения и узла источника. Посколь-
Поскольку номера узлов являются такими же, как адреса сетевой интерфейсной пла-
платы, эти поля содержат такие же адреса места назначения и источника, как
находящиеся в заголовке MAC. Например, рабочая станция, выполняющая
IPX/SPX, использует адрес узла назначения для определения места и пере-
пересылки пакетов другой рабочей станции в том же сетевом сегменте.

Стек протоколов SPX/IPX 97
Номер узла IPX должен быть уникальным в том же сетевом сегменте. На-
Например, узел в сети 3001 может использовать номер 006008A1D4B4, а узел в
сети 3002 также может использовать номер 006008АШ4В4. Это действует
так же, как протокол IP, потому что адрес хоста может совпадать в различ-
различных сетях IP. Поскольку каждый узел имеет отличный сетевой номер, IPX
распознает каждый узел, как имеющий законный уникальный адрес.
Номер сокета •
Двухбайтовый шестнадцатеричный номер сокета идентифицирует место
назначения процесса внутри узла. Это может быть нечто вроде маршрути-
маршрутизации (RIP) или объявления (внутри устройства SAP). Так как обычно одно-
одновременно действуют несколько процессов, номер сокета обеспечивает
что-то вроде "почтового ящика", используемого каждым процессом для
идентификации себя для IPX.
Когда процессу требуется коммуникация в сети, он запрашивает номер
сокета. Все пакеты, полученные IPX и адресованные сокету, пересылаются
затем процессу. Номера сокетов предоставляют быстрый метод маршрути-
маршрутизации пакетов в узле. Это работает таким же образом, как сокеты Windows
или номера портов TCP/IP. Они являются логическими местами назначе-
назначения на удаленной машине для межпроцессной коммуникации. В таблице 3.5
перечислены некоторые номера сокетов и процессы, встречающиеся
обычно в достаточно активных сетях.
Таблица 3.5. Общеупотребительные номера сокетов IPX/SPX и процессы
Номер сокета
0x451
0x452
0x453
0x455
0x456
0x9001
0x9004
Процесс
NCP
SAP
RIP
Novell NetBIOS
Диагностика
NLSP
Протокол IPXWAN
Сокеты под номерами между 0x4000 и 0x7FFF являются динамическими;
они создаются в ходе работы, когда рабочей станции понадобится коммуни-
коммуникация с файловым сервером или другими сетевыми устройствами. Сокеты
под номерами между 0x8000 и OxFFFF являются общеупотребительными;
Novell присваивает их определенным процессам. Например, 0x9001 является
номером сокета, который идентифицирует NLSP. Разработчики програм-
программного обеспечения, пишущие приложения NetWare, могут контактировать
с Novell для выяснения общеупотребительных сокетов.

98 >¦ - ••<¦¦ Глава 3
Как работает маршрутизация IPX "''.;'!
Когда соединяются различные сетевые сегменты IPX, инструкции для мар-
маршрутизации пакетов между этими сегментами приходят из протокола IPX.
IPX выполняет эти функции уровня 3 с помощью RIP, SAP и NLSP.
Если две рабочие станции находятся в одном сетевом сегменте, посыла-
посылающая рабочая станция посылает пакеты прямо по физическому адресу ра-
рабочей станции назначения (т.е. по адресу MAC). Если две рабочие станции
находятся в двух различных сетевых сегментах, то первая рабочая станция
должна найти маршрутизатор в своем собственном сегменте, который зна-
знает, как переслать пакеты внешнему сегменту.
Чтобы найти этот крайне важный маршрутизатор, рабочая станция бу-
будет посылать широковещательный пакет RIP, запрашивающий самый быст-
быстрый маршрут к сегменту назначения. Маршрутизатор того же сегмента с
самым коротким путем к сегменту назначения ответит на запрос. В пакете
ответа маршрутизатор включит в заголовок IPX свой собственный сетевой
и узловой адрес.
Очевидно, что если посылающим узлом является маршрутизатор, а не ра-
рабочая станция, то ему не нужно будет посылать широковещательное сообще-
сообщение RIP, чтобы получить эту информацию. Вместо этого маршрутизатор
берет информацию из внутренней таблицы маршрутизации.
Когда посылающая рабочая станция получит адрес маршрутизатора, она
посылает пакеты рабочей станции назначения, помещая полный адрес IPX
места назначения (т.е. сеть, узел и номер сокета) в поле места назначения
заголовка IPX, как это было показано ранее в этой главе.
Затем посылающая рабочая станция помещает свой собственный полный
адрес IPX в соответствующее поле источника заголовка IPX. Посылающая
рабочая станция заполнит также все другие поля в заголовке. Например, она
поместит адрес узла маршрутизатора, который ответил на запрос RIP в поле
адреса места назначения заголовка MAC. Она поместит свой собственный
адрес в поле адреса источника заголовка MAC.
Посылающая рабочая станция отправляет, наконец, пакет маршрутиза-
маршрутизатору, который должен теперь выполнить несколько задач. В первую оче-
очередь маршрутизатор просматривает поле контроля транспорта заголовка
пакета IPX. Маршрутизатор RIP будет отбрасывать пакет, если это поле бо-
больше 16. Маршрутизатор NLSP будет отбрасывать полученный пакет, если
это число больше, чем ограничение числа переходов.
После этого маршрутизатор проверяет поле типа пакета заголовка IPX.
Если он видит в этом поле 20 @x14), это указывает на пакет NetBIOS. Он
должен также посмотреть поле контроля транспорта. Если это значение
равно восьми или больше, маршрутизатор отбрасывает пакет, так как пакет
NetBIOS ограничен восьмью переходами (или сетями).
Затем маршрутизатор сравнивает сетевой номер в пакете с сетевым но-
номером сегмента, в который прибыл пакет. Если маршрутизатор обнаружит
совпадение, то он отбрасывает пакет, чтобы избежать зацикливания. Если
сетевой номер не совпадает, то он помещает сетевой адрес в следующее до-
доступное поле сетевого номера. Он увеличивает поле контроля транспорта
и посылает пакет всем напрямую соединенным сетевым сегментам, кото-
которые не присутствуют в полях сетевых номеров.

Стек протоколов SPX/IPX 99
Теперь маршрутизатор проверяет поля адреса назначения, чтобы опреде-
определить, как направить пакет. Если пакет адресован маршрутизатору, соответст-
соответствующий процесс сокета обработает его внутренне; иначе маршрутизатор
пересылает пакет. В дополнение к пакетам, непосредственно адресованным
маршрутизатору, он должен также иметь дело с OxFFFFFFFFFFFF, которые
обычно являются пакетами RIP, SAP или диагностики.
Если пакет необходимо переслать, маршрутизатор помещает адрес мес-
места назначения из заголовка IPX в поле адреса места назначения заголовка
MAC. Затем маршрутизатор помещает свой собственный адрес в поле адре-
адреса источника заголовка MAC, увеличивает поле контроля транспорта заго-
заголовка IPX и пересылает пакет в сегмент назначения. Если, однако, поле
контроля транспорта равно максимально допустимому числу переходов до
того, как поле будет увеличено, маршрутизатор отбрасывает пакет. Для
маршрутизаторов RIP это число равно 16, для маршрутизаторов NLSP это
ограничение задается в диапазоне от 8 до 127.
Широковещательные пакеты никогда повторно не посылаются в сетевые
Сегменты, из которых они были получены. Если маршрутизатор не связан
напрямую с сегментом, в котором находится узел конечного места назначе-
назначения, он посылает пакет следующему маршрутизатору на пути к узлу назначе-
назначения, помещая адрес узла следующего маршрутизатора в поле адреса места
назначения заголовка MAC. Маршрутизатор берет эту информацию в своей
информационной таблице маршрутизации и затем помещает адрес своего
собственного узла в поле адреса источника заголовка MAC, увеличивает
поле контроля транспорта в заголовке IPX и пересылает пакет следующему
маршрутизатору. " ' ¦--,<¦-¦-¦•
NCP Каждый NCP известен прежде всего по своему номеру, который
состоит из трех полей. Например, номер для изменения пароля объекта
связывания равен 0x2222 23 64.
• Первое двухбайтовое поле x2222" является полем категории службы.
• Второе число 3" является номером функции, который идентифицирует,
где в таблице коммутации существует базовая функция.
• Третье поле 4" идентифицирует специальную функцию NCP, которая
выполняется.
Номера NCP делятся на широкие функциональные категории. Напри-
Например, большинство функций номера 23 являются NCP учета, связывания, со-
соединения или файлового сервера. В таблице 3.6 перечислены некоторые
из категорий служб NCP.
Категория NCP запроса службы @x2222) и категория NCP ответа служ-
службы @x3333) используются наиболее часто. Существуют две категории
служб, которые не требуют создания пакетов ответа службы @x3333). Это
разрушение служебного соединения @x5555) и запрос разбиения пакета
@x7777). •

100 Глава 3
Таблица З.б. Категории служб NCP
Номер NCP Категория службы
0x1111 , Создать служебное соединение
0x2222 Запрос службы . . ,;
0x3333 Ответ службы
0x5555 Разрушить служебное соединение
0x7777 ; - ¦ Запрос разбиения пакета
0x9999 Предыдущий запрос все еще обрабатывается (занят)
Если клиенту посылается сообщение, что предыдущий запрос все еще
обрабатывается @x9999), это означает, что клиент сделал другой запрос
или снова послал тот же запрос, в то время как сервер все еще обрабатывает
последний, сделанный тем же клиентом, запрос.
Клиент посылает через соединение с сервером сообщение, которое со-
содержит все параметры NCP, используя сетевой протокол, например IPX.
Сервер выполняет процедуру и возвращает результаты клиенту. Каждое до-
дополнительное сообщение увеличивает идентификационные номера в паке-
пакете. Когда от клиента получен запрос NCP, создается ответ NCP. Это
протокол, действующий по принципу один запрос — один ответ.
Интерфейсы сеансов и дейтаграмм
NCP разрешает клиенту общаться с сервером с помощью системы доставки
сообщений, например IPX или SPX. SPX имеет преимущество, поддерживая
упорядочивание и гарантированную доставку сообщений. Если понадобится,
то может запрашиваться IPX, с целью улучшения производительности. Он
предлагает преимущество использования низкоуровневого ненадежного ин-
интерфейса дейтаграмм, такого как IPX. Кроме того, дейтаграммы предлагают
перенос NCP в сети, где стандартные интерфейсы сеанса не существуют.
В настоящее время большинство клиентов ограничены не более чем од-
одним ожидающим запросом NCP для каждого соединения. Однако между
двумя компьютерами может существовать несколько соединений. Если кли-
клиент пользуется мультипользовательской системой, каждый пользователь
может иметь отдельное соединение с сервером, а каждому соединению
разрешено иметь ожидающий запрос NCP.
Так как система безопасности доступа к серверу определяется на основе
каждого соединения, то для нескольких задач принято использовать общее
единственное соединение. При необходимости для каждой задачи могут
быть созданы новые соединения в мультизадачной среде. Каждое новое со-
соединение интерпретируется как отдельная сущность, несмотря на физиче-
физическую машину, которая осуществляет соединение. Таким образом, клиент
может поддерживать столько соединений с различными серверами, сколько
потребуется.

Стек протоколов SPX/IPX
101
Структуры заголовка сообщений
Посмотрим теперь на сообщение NCP. Сообщение NCP содержит семи-
байтный заголовок запроса, за которым следует восьмибайтный заголовок
ответа. Заголовок запроса содержит общую статусную информацию о те-
текущем состоянии соединения и указывает требуемую службу, как показано
в таблице 3.7.
Таблица 3.7. Заголовок запроса сообщения NCP
. Смещение Тип Содержимое Описание
0
Слово
Байт
Байт
Байт
Байт
Requesttype @x2222) -
Тип запроса
Sequencenumber
(последний номер
последовательности +1)
Порядковый номер
ConnectionNumberLow
(служебное_соединение) ¦
Номер соединения —
меньший
TaskNumber
(текущий_номер_задачи)
Номер задачи
ConnectionNum-
berHigh(oiy}Ke6Hoe_
соединение) — Номер
соединения — больший
Поле категории службы
Порядковый номер
охватывающего сообщения.
Когда посылается запрос
создания служебного соединения,
это поле задается равным нулю.
Последующие запросы его
увеличивают.
Служебное соединение,
возвращаемое сервером
при ответе на запрос создания
служебного соединения. Это -*
поле равно нулю при первом
запросе.
Это клиентская задача, которая
запрашивает службу. Сервер
отслеживает, какие задачи
открывают файлы, и блокирует
данные, чтобы освободить эти
ресурсы, когда задача завершается.
255 задач могут совместно
использовать одно соединение.
Задача 0 зарезервирована для
конца задачи.
Возвращается сервером в ответ
на создание запроса служебного
соединения. При первом запросе
равно 0.
Заголовок ответа содержит требуемые параметры для удаленного
выполнения процедур. Его структура показана в таблице 3.8.
Проверяйте флаги состояния соединения всякий раз, когда получен от-
ответ службы. Если бит 4 задан как 1, то соединение службы было, вероятно,
прекращено на стороне сервера.

102
Таблица 3.8.
Смещение
Параметры,требуемые для
Тип Содержимое
удаленного выполнения
Описание
Глава 3
процедур
Слово ReplyType@x3333) — Поле категории службы
Тип ответа
Байт
Байт
Байт
Байт
Sequencenumber
(номер_последовате-
льности_запроса) —
Номер
последовательности
ConnectionNumber-
Ьо-Цслужебное соеди-
соединение) — Номер
соединения —
меньший
Байт Sequencenumber Номер последовательности охватыва-
охватывающего сообщения. Когда посылается
запрос создания служебного соедине-
соединения, это поле задается равным нулю.
Последующие запросы его увеличивают.
Служебное соединение, возвращаемое
сервером при ответе на запрос создания
служебного соединения. Это поле равно
нулю при первом запросе.
Это клиентская задача, которая запра-
запрашивает службу. Сервер отслеживает,
какие задачи открывают файлы, и бло-
блокирует данные, чтобы освободить эти
ресурсы, когда задача завершается.
255 задач могут совместно использовать
одно соединение. Задача 0 зарезерви-
зарезервирована для конца задачи.
ConnectionNumber- Возвращается сервером в ответ
High(oi}OKe6Hoe на создание запроса служебного
соединение) — Номер соединения. При первом запросе
соединения — больший равно 0.
Байт CompletionCode(KOfl) — Код завершения, возвращаемый
номер задачи) —
Номер задачи
Код завершения
ConnectionStatusFlags
(Флаги_состояния) —
Флаги состояния
соединения
сервером. Он является частью ответа
на запрос службы клиентскими
машинами. Любое число, отличное от 0,
указывает на ошибку, произошедшую во
время обслуживания запроса. Когда
это происходит, остальная часть ответа
сервера не возвращается.
Битовое поле, возвращаемое сервером
как часть заголовка его ответа на запрос
службы клиентом. Биты имеют
следующие значения:
0 Плохое служебное соединение
2 Нет доступного соединения
4 Сервер выключен
6 Сервер хранит широковещательное
сообщение

Стек протоколов SPX/IPX 103
Обзор главы , „1
В этой главе был рассмотрен пакет протоколов IPX/SPX и показано, где он
действует в модели OSI. Обсуждалась структура пакета, адресация IPX и
проведено сравнение со структурой TCP/IP и Ethernet. Была рассмотрена
роль сетевого номера и зарезервированного сетевого номера. Были иссле-
исследованы номера узлов и номера сокетов, а также выполнение маршрутиза-
маршрутизации в IPX. В завершение мы рассмотрели структуру заголовков сообщений.
В следующей главе
В следующей главе будут рассмотрены блоки сообщений сервера. Мы уви-
увидим, как они действуют, как определяются имена серверов и как они разре-
разрешаются. Будет проанализировано согласование диалекта, создание
соединения и исследовано, как они работают с клиентами нижнего уровня.
Подробно рассмотрим настройки сеанса, управления соединением, а также
блокировки. .

Глава 4
Блоки сообщений сервера
Протокол блоков сообщений сервера (SMB — Server Message Blocks) являет-
является рабочей лошадкой мира Windows NT и Windows 2000. Он используется
между компьютерами для общего доступа к файлам, принтерам, последова-
последовательным портам и для коммуникационных абстракций, таких как имено-
именованные каналы и почтовые ящики. SMB является клиент-серверным
протоколом типа запрос-ответ.
Протокол SMB превратился в общую файловую систему Интернета
(Common Internet File System, CIFS). CIFS предоставляет межплатформен-
межплатформенный механизм клиентских систем для запроса служб файлов и печати на
серверных системах. Он поддерживает файлы и печать, используя коман-
команды доступа open (открыть), close (закрыть), read (читать), write (писать) и
seek (искать). Кроме того, он поддерживает доступ к файлам и записям как
в блокированном, так и в неблокированном режиме. Когда приложение
блокирует файл, ему не могут помешать другие приложения. Блокированные
файл или запись недоступны не блокирующим приложениям.
SMB предоставляет кэширование с опережающим чтением и с обратной
записью. Это безопасные операции до тех пор, пока только один клиент
имеет доступ к файлу. Кэширование чтения и оптимизация упреждающего
чтения являются безопасными при доступе к файлу или в режиме только
чтения. Если несколько клиентов пытаются одновременно записывать в
файл, то ничто не будет безопасным; поэтому все файловые операции дол-
должны управляться на сервере. SMB уведомляет обращающегося к файлу кли-
клиента об изменениях в режиме доступа, чтобы клиент мог использовать
оптимальный метод доступа.
Приложения регистрируются для уведомления сервером об изменениях
содержимого файла или каталога. Это позволяет приложению знать, когда
обновить изображение, не требуя от него постоянно запрашивать сервер.
Существует почти столько же различных версий протокола SMB, сколь-
сколько и поставщиков программного обеспечения. Каждая версия предоставля-
предоставляет дополнительные функции, свойства и средства. Чтобы справиться с

Блоки сообщений сервера 105
этим изобилием, SMB выполняет так называемое согласование диалектов.
Когда два компьютера вступают в контакт, они согласовывают диалект или
версию SMB, которая будет использоваться при их общении. Это критиче-
критический шаг в терминах как производительности, так и безошибочной комму-
коммуникации, так как каждый диалект может предоставлять различные
сообщения, а также изменения в полях и семантике существующих сообще-
сообщений других диалектов. В дополнение к обычным атрибутам файлов, напри-
например, времени создания и модификации, такими приложениями, как Word
могут добавляться другие элементы, чтобы включить, например, имя автора
или описание содержимого.
Протокол может поддерживать виртуальные тома, используя файловую
систему, которая может охватывать несколько томов и серверов, но выгля-
выглядеть при этом для клиентской машины как находящаяся на одном сервере.
| Файлы и каталоги поддерева могут перемещаться на другие серверы, имена
при этом изменять не придется. В этом случае не нужно будет делать изме-
изменения на настольном компьютере, когда делаются изменения на сервере.
Эти поддеревья могут также реплицироваться для выравнивания нагрузки
и устойчивости к ошибкам. Когда клиент запрашивает файл, SMB использует
направления для пересылки клиента на сервер, который содержит данные.
Все это происходит за сценой без вмешательства клиента.
SMB позволяет клиенту преобразовывать имена серверов с помощью
DNS, WINS, LMHOSTS или любого другого механизма преобразования
имен. Это перемещает нас из неструктурированного, "плоского" простран-
пространства серверных имен в иерархически организованное пространство, под-
поддерживающее более широкий диапазон взаимодействия. Чтобы сберечь
полосу пропускания, SMB может пакетировать запросы в одном сообщении
для минимизации задержки перемещения туда и обратно, даже когда более
поздние запросы зависят от результатов предыдущих; он поддерживает также
имена файлов в кодировке Unicode.
Обзор работы SMB
Для получения доступа к файлу на сервере клиентское приложение должно
разобрать полное имя файла, чтобы определить имя сервера и относитель-
относительное имя на этом сервере, разрешить имя сервера в адрес транспортировки,
создать соединение с сервером и затем обменяться сообщениями. Если имя
сервера было ранее разрешено, то оно может находиться в кэше, поэтому
разрешение имени может не понадобиться. Кроме того, если предыдущее
соединение все еще доступно, то новое соединение тогда не потребуется.
Этот процесс повторяется множество раз в течение нормального рабочего
дня. Если соединение простаивало в течение некоторого времени, оно будет
разорвано.
Определение имени сервера
SMB достаточно развит, чтобы преобразовывать имя сервера множеством
различных методов. Например, в URL file://prox/users/teresa/movies.xls
клиент возьмет часть между двумя наклонными чертами и следующей

106 Глава 4
наклонной чертой в качестве имени сервера, а остальное будет интерпре-
интерпретировано как относительное имя. В примере именем сервера будет PROX,
а относительным именем USERS/TERESA/MOVIES.XLS.
В имени пути доступа \\prox\users\ed\booksbymred.ppt клиент возьмет
часть между ведущими двумя обратными наклонными чертами и следую-
следующей обратной наклонной чертой в качестве имени сервера, а остальное как
относительное имя. В этом примере именем сервера является PROX, а отно-
относительным именем будет USERS\ED\BOOKSBYMRED.PPT.
В пути доступа h:\booksbymred.ppt, клиент будет использовать "h" в ка-
качестве индекса в таблице, которая содержит имя сервера и префикс имени
файла. Если содержимое таблицы для h будет PROX и пользователь \ed, то
имя сервера и относительное имя будут такими же, как и в предыдущем
примере.
Разрешение имени сервера
Когда имя сервера было определено, следующий шаг состоит в разрешении
имени. Должны существовать некоторые средства для разрешения имени
сервера SMB в транспортный адрес. Сервер должен также регистрировать
свое имя в службе разрешения имен, известной его клиентам. Это обычно
либо WINS, либо DNS.
Имя сервера можно также определить как строковую форму адреса IP в
обычной десятичной нотации с точками, например 10.0.0.10. В этом случае
"разрешение" состоит в преобразовании в 32-разрядный адрес IP.
Тип используемого разрешения имени может накладывать ограничения
на форму имени сервера. Например, для NETBIOS имя сервера должно
быть меньше 15 символов верхнего регистра.
Транспорт сообщения ; <;.<.•¦ рт
Когда SMB использует надежный транспорт с поддержкой соединения, ему
не нужно гарантировать упорядоченную доставку сообщений между клиен-
клиентом и сервером. В этом вопросе он полагается на четвертый уровень
(транспортный). Однако транспорт должен обнаруживать ошибки либо на
клиентском, либо на серверном узле и сообщать о них программному обес-
обеспечению, чтобы можно было сделать исправления. Когда надежное транс-
транспортное соединение с клиентской стороны завершается, выполняющаяся
работа и все открытые клиентом ресурсы закрываются. Транспорт сообще-
сообщений выполняется с помощью службы сеанса NETBIOS. . ¦ .-_•
' ¦ 11' • ¦ ' ¦
Пример потока сообщений
Типичная последовательность обмена сообщениями для клиента, соединен-
соединенного с сервером уровня пользователя включает открытие файла, чтение из
него данных, закрытие файла и разъединение с сервером (см. таблицу 4.1).
Механизм пакетирования запросов CIFS (называемый механизмом "AndX")
дополнительно позволяет объединять в одно до шести сообщений в этой по-
последовательности, поэтому в действительности в этой последовательности
существуют только три перехода туда и обратно, и последнее из них клиент
может сделать асинхронно.

Блоки сообщений сервера
Таблица 4.1. Поток сообщений SMB
Клиентская команда
107
Ответ сервера
SMB COM NEGOTIATE
-г ¦¦¦:¦*•
¦Г ¦
Это первое сообщение, посылаемое
клиентской машиной на сервер. Оно
будет включать список диалектов SMB,
поддерживаемых клиентской машиной.
Когда сервер отвечает, он указывает,
какой диалект SMB должен использоваться.
SMB_COM_SESSION_SETUP_ANDX Передает серверу для проверки имя
пользователя и полномочия.
...-•¦ ¦ Успешный ответ от сервера включает
.. , идентификатор пользователя UID,
который будет использоваться
в последующих SMB от пользователя.
SMB COM TREE CONNECT
SMB COM OPEN
SMB COM READ
[ SMB_COM_CLOSE
I SMB_COM_TREE_DISCONNECT
Это имя общего диска, доступ к которому
хочет получить клиент. Ответ сервера
включает поле идентификатор тома TID,
которое будет использоваться
в последующих запросах.
Этот кадр будет передавать имя файла,
относительно TID, который хочет
открыть клиент. Успех этой команды
будет включать идентификатор файла
FID, который должен использоваться
для последующих операций на файле.
Здесь клиент предоставляет TID, FID,
смещение файла и число байтов для
чтения. Когда эта команда успешно
выполняется, сервер, очевидно,
возвращает запрошенные данные.
Клиент закрывает файл, представленный
в кадре с помощью TID и FID. Сервер
отвечает кодом успеха.
Клиент разъединяется с ресурсом,
представленным TID.
Основная функция редиректора клиентской машины — форматирова-
форматирование удаленных запросов таким образом, который будет понятен машине
места назначения, и отправка их по сети. Редиректор использует структуру
SMB в качестве стандартного средства перемещения для отправки и ответа
на запросы редиректора. Каждый заголовок SMB содержит код команды
(определяющий задачу, выполнение которой редиректор хочет поручить
удаленной станции) и несколько полей окружения и параметров (которые

108 Глава 4
определяют, как команда должна выполняться). Кроме того, в заголовке
SMB последнее поле в SMB может содержать до 64Кбайт данных, посылаемых
на удаленную станцию.
Read SMB (запрос) Команда read SMB (иногда называемая командой
чтения диапазона байтов) приказывает серверу прочитать определенный
диапазон байтов из дискового файла. Она также включает дескриптор фай-
файла, число байтов для чтения и т.д. Сдвиг файла основывается на "указателе
поиска", который хранится редиректором локально для файла. Серверный
указатель поиска для этого дескриптора файла недействителен в данном
случае, так как множество процессов удаленных рабочих станций могут
обращаться к одному серверу, используя системный дескриптор файла.
Параметр "est'd total" (оценка общего числа байтов для чтения, включая
прочитанные этим запросом) является необязательным. Сервер может испо-
использовать эту информацию для упреждающего чтения или для оптимизации
выделения буферов.
Read SMB (ответ) Ответ на Read SMB несет с собой запрошенные данные.
Мультиплексный идентификатор (MID) помечает ответ SMB для соответст-
соответствующего запроса SMB. . ,
Вот как работает этот процесс:
• Программа посылает запрос ввода-вывода операционной системе
через вызов интерфейса прикладного программирования (API).
• Операционная система (или редиректор с помощью прерывания
"int21") определяет, что запрос предназначен для удаленного ресурса,
и передает его редиректору.
• Редиректор форматирует запрос ввода-вывода как запрос SMB и посылает
его по сети на сервер.
• Сервер получает SMB и посылает запрос ввода-вывода локальной
операционной системе сервера.
• Сервер форматирует данные ответа SMB. Данные возвращаются,
если выполнена операция чтения, или возвращается код, если выпол-
выполнена операция записи. Сервер посылает их по сети запрашивающей
рабочей станции. .
• Редиректор передает ответ в операционную систему.
• Операционная система передает ответ вызывающему приложению.
Согласование диалекта
Создание соединения
После разрешения имени сервера в адрес IP необходимо создать соедине-
соединение с сервером. Создание соединения делается с помощью примитива call
служебного сеанса NETBIOS, который требует, чтобы клиент предоставил
"вызывающее имя" и "вызываемое имя". Вызывающее имя не существенно в
CIFS, за исключением того, что идентичное имя из того же транспортного

Блоки сообщений сервера 109
адреса считается принадлежащим тому же клиенту; вызываемое имя всегда
равно "SMBSERVER". Через TCP примитив call приводит к отправке пакета
"запрос сеанса" на порт 139.
Обратная совместимость
Если клиент CIFS хочет взаимодействовать с более старыми серверами
SMB, он может повторить запрос с новым вызываемым именем, если вызов
был отклонен сервером. Выбор нового имени зависит от типа используемо-
используемого разрешения имени. Например, если используется DNS, вызываемое имя
будет создаваться из первого компонента имени DNS сервера и затем об-
обрезаться до 15 символов, если потребуется. Затем он будет дополнен до
16 символов с помощью символов пробела B0 hex). Если используется
NETBIOS, то вызываемым именем является имя NETBIOS. Если это не ра-
работает, то можно сделать запрос NETBIOS "Состояние адаптера", чтобы
получить имя NETBIOS на сервере и повторить создание соединения.
Настройка сеанса
Сервер CIFS ДОЛЖЕН зарегистрировать NETBIOS Listen, который прини-
принимает все вызывающие имена имени "*SMBSERVER". Кроме того, если он хо-
хочет поддерживать более старых клиентов SMB, он может иметь имя
NETBIOS и зарегистрировать также порт 139 для прослушивания этого
имени.
Управление соединением
Правила для прекращения надежного транспортного соединения пере-
перечислены ниже:
• Если сервер получает от клиента запрос создания транспорта, с ко-
которым он уже общается, сервер может прекратить все другие транс-
транспортные соединения с этим клиентом. Это позволяет серверу
восстановиться из ситуации, когда клиент внезапно перезагружается
и не может аккуратно прекратить свои действия по использованию
общих ресурсов сервера.
• Сервер может прервать транспортное соединение с клиентом в лю-
любое время, если клиент создает неправильно сформированные или
нелогичные запросы. Однако по возможности сервер будет сначала
возвращать клиенту код ошибки, указывая причину прерывания.
• Если сервер получает тяжелую ошибку на транспорте (например, от-
отказ передачи), то транспортное соединение с этим клиентом может
быть прервано.
• Сервер может прекратить транспортное соединение, если клиент не
имеет на сервере открытых ресурсов.

110 Глава 4
Подпись SMB
Windows NT 4 с Service Pack 3 включает усовершенствованную версию про-
протокола аутентификации SMB, известную также как протокол совместного
использования файлов общей системы файлов Интернета (CIFS). Мо-
Модернизированный протокол имеет два основных усовершенствования. Он
поддерживает взаимную аутентификацию, которая препятствует использо-
использованию атаки "человек в середине", и поддерживает аутентификацию сообще-
сообщений, что препятствует использованию атак активных сообщений. Механизм
подписи SMB обеспечивает эту аутентификацию, помещая цифровую
подпись безопасности в каждый SMB. Затем она проверяется клиентом и
сервером.
Чтобы использовать механизм подписи SMB, имеется две возможности:
сделать возможным или потребовать ее использование на клиенте и на сер-
сервере. Если подпись SMB сделана возможной на сервере, то имеющие воз-
возможность клиенты будут использовать CIFS во время всех последующих
сеансов. Преимущество такого подхода состоит в том, что клиенты, не име-
имеющие возможности подписи SMB, смогут использовать более старый про-
протокол SMB. Если на сервере требуется подпись SMB, то клиент не сможет
создать сеанс, не будучи был специально инициирован для подписи SMB.
Подпись SMB отключена по умолчанию на серверной системе при установ-
установке служебного пакета (service pack). Она, однако, инициирована по умолча-
умолчанию, когда служебный пакет устанавливается на системе рабочей станции.
Примечание. Подпись SMB не будет работать с прямым протоколом хоста
IPX. Это связано с тем, что прямой протокол хоста IPX изменяет SMB спо-
способом, который несовместим с поддерживающим подпись SMB. Эта несо-
несовместимость наиболее очевидна, когда используются прямые клиенты
хоста IPX, и на сервере требуется подпись SMB. Требование на сервере
подписей SMB не позволит серверу связываться с прямым интерфейсом хо-
хоста IPX, что заставит подписать все соединения с сервером. Если отклю-
отключить связывание NWLink с сервером, то можно будет использовать
подпись SMB.
Кроме того, подпись SMB будет снижать производительность системы.
Хотя она не потребляет дополнительную полосу пропускания, но использует
центральный процессор на клиенте и на сервере. .¦ .
Оппортунистические блокировки
Сетевая производительность увеличивается, если клиент может локально
буферизовать данные файла. Это связано с тем, что клиент не должен запи-
записывать информацию в файл на сервере, если знает, что никакой другой
процесс не получает доступа к данным. Таким же образом клиент может бу-
буферизовать данные опережающего считывания из файла, если знает, что
никакой другой процесс не записывает данные.
Оппортунистические блокировки, или oplocks, позволяют клиентам ди-
динамически изменять их стратегию буферизации согласованным образом.
Все версии SMB из LAN-MAN 1.0 способствуют поддержке oplocks.

Блоки сообщений сервера 111
Три различных вида оппортунистических блокировок перечислены
ниже.
1. Исключающая oplock позволяет клиенту открыть файл для своего
собственного персонального использования, чтобы выполнить
произвольную буферизацию.
2. Пакетная oplock позволяет клиенту держать на сервере открытый
файл, даже если локальное средство доступа (accessor) на клиентской
машине закрыло файл. ., ,^.,кГ
3. Level II oplock позволяет нескольким машинам читать файл, если сре-
среди них нет записывающих клиентов. Level II oplock поддерживаются
в том случае, если согласованный диалект будет LM 0.12 или больше.
Открыв файл, клиент запрашивает сервер задать на файле определен-
определенную oplock. Ответ сервера указывает тип oplock, предоставленный клиен-
клиенту, позволяя ему соответствующим образом настроить свою политику
буферизации.
SMB_COM_LOCKING_ANDX SMB используется для передачи информа-
информации ответа и прерывания oplock. Рассмотрим каждый из этих механизмов
блокирования более подробно. ..:( . ( .; ¦ • •,; •.-..,¦¦ ..ч-. .±j ,>ж .»; j; л .•
¦ ¦;;.¦ ¦:•:.¦• '¦. ¦ ¦ ¦ . ¦ /.. ¦¦ ¦ n.j.-l'i. -~i -,
Исключающая oplock , ,;,¦ ., .. ¦ Л•.-!•¦.,.,[..¦ .„¦¦;>:•,;¦.¦
Когда клиенту предоставляется исключающая oplock, он может буферизи-
ровать блокированную информацию, выполнять опережающее чтение и
записывать данные на клиентской стороне общения, так как знает, что к
файлу не будет других средств доступа. Это происходит следующим обра-
образом. Редиректор на клиенте открывает файл, запрашивая для клиента
oplock. Если файл открыт кем-то другим, клиенту отказывают в oplock, и на
локальном клиенте никакой локальной буферизации выполняться не мо-
может. Это означает также, что на файле не может выполняться никакого
опережающего чтения, если только редиректор не знает, что он имеет бло-
блокированный диапазон опережающего чтения. Если сервер предоставляет
исключающую oplock, клиент может выполнить некоторую оптимизацию
для файла, например блокирование буферизации, чтение и запись данных.
Протокол исключающей блокировки oplock показан в таблице 4.2.
Таблица 4.2. Работа исключающей блокировки oplock
Клиент А Клиент В Сервер
Открыть (Open) \\
coolfile-> -т-.i.:--.. ¦' *
*>•'.-¦ '¦ '•¦ • ' • <-Открытие успешно. ¦
'¦¦'¦ •¦ : : i • Предоставлена исключающая
¦ • ¦ ¦¦¦¦.:¦¦ ' блокировка oplock
Открыть (Open) \\ .' ' •;.""•'
coolffle-> ' . ' ' ' Г. : ;lli~''¦ •¦'¦¦:'¦¦•'¦'•

112
Таблица 4.2.
Клиент А
Работа
исключающей блокировки
Клиент В
oplock (продолжение)
Сервер
Глава 4
: [lfj; rj ,, .. .. ;> ,!,,.- Исключающая блокировка для
клиента А не разрешает запись
Блокировать (Locks)->
, ¦¦-., л!1.«.ч.-. ?'„ . . ¦.. , ¦, 4И ,.-..•¦¦,, <-ответ на блокировку
Записать (Writes) -> . ' '•
""'.J:'.'-'' - Р ¦¦'¦ •(¦•'•¦¦¦: ; f''j i' » <-ответ на запись
Закрыть или сделано-> ....,.-
<- открыть ответ клиенту В
Как можно видеть, когда клиент А открывает файл, он может запросить
исключительную блокировку oplocks. Если больше никто не открыл этот
файл на сервере, то oplock предоставляется клиенту А. Если в некоторый
момент в будущем другой клиент, например клиент В, запрашивает откры-
открытие того же самого файла, то серверу необходимо, чтобы клиент А прервал
свою блокировку oplock. Прерывание oplock включает отправку клиентом
А на сервер любых данных для записи или блокировки, которые он буфери-
зировал, и затем уведомление сервера, что подтверждается отмена блоки-
блокировки. Это синхронизирующее сообщение информирует сервер, что теперь
допустимо разрешить клиенту В завершить открытие файла.
Клиент А должен также стереть все буферы опережающего чтения,
которые он имел для файла.
.'А"!Г. :'. , ••¦!'¦¦ :. \<Y't- ¦ ' ' •¦¦'¦•
Пакетная блокировка oplock
Пакетная блокировка oplock используются там, где обычные программы на
клиенте ведут себя таким образом, что объем сетевого трафика растет выше
приемлемого уровня для предоставляемой программой функциональности.
Например, командный процессор выполняет команды из командной
процедуры, делая следующие шаги:
• Открывает командную процедуру
• Ищет "следующую строку" в файле <"
• Считывает строку из файла ,
• Закрывает файл
• Выполняет команду
Этот процесс повторяется для каждой команды, выполняемой из файла
командной процедуры. Очевидно, что это приводит к обработке множест-
множества файлов, создавая тем самым сетевой трафик, который можно было бы
сократить, если бы программа просто оставляла файл открытым, считывала
строку, выполняла команду и затем считывала новую строку.

Блоки сообщений сервера
113
Пакетное блокирование действует именно так, позволяя клиентам про-
пропускать излишние запросы открытия и закрытия (см. таблицу 4.3). Когда
командный процессор запрашивает следующую строку в файле, клиент
либо запрашивает сервер, либо уже имеет эти данные в кэше опережающе-
опережающего чтения. В любом случае объем сетевого трафика клиента существенно
сокращается.
Если сервер получает запрос для переименования или удаления файла,
который имеет пакетную блокировку oplock, он информирует клиента,
что необходимо удалить oplock. Клиент затем переходит в режим открыть
и закрыть, описанный ранее.
Клиент А открывает файл и запрашивает oplock. Если никто не откры-
открывал этот файл на сервере, то клиенту А предоставляется oplock. В приве-
приведенном выше случае клиент А сохраняет файл открытым для своей
вызывающей программы для нескольких операций открыть/закрыть. Дан-
Данные могут читаться для вызывающей программы с опережением; может
также использоваться и другая оптимизация, например буферизированная
блокировка.
Таблица 4.3. Работа протокола пакетной блокировки oplock
Клиент А
Клиент В
Сервер
Открыть \\coolfile ->
i .
Прочитать ->
Закрыть
Открыть
Искать
Закр
Закрыть ->
<- открытие успешно.
Предоставлена пакетная
блокировка oplock.
<- данные
Открыть \\coolfile ->
Прочитать
<- данные
<- удаление блокировки
oplock для клиента А
<- закрытие успешно
для клиента А *
<- закрытие успешно
для клиента В

If* ' ••¦ Глава4
Однако когда другой клиент запрашивает на сервере операцию откры-
открытия, переименования или удаления файла, клиент А должен очистить свои
буферизированные данные и синхронизироваться с сервером. В большин-
большинстве случаев это включает закрытие файла при условии, что вызывающая
программа клиента А считает, что она закрыла файл. Когда файл закрыт,
может быть завершен запрос клиента В на открытие. ' v'¦'-'¦ :^{'~
Level II Oplocks ; ; '- <¦¦¦¦ ^ ;ч
Блокировки Level П oplock позволяют нескольким клиентам иметь открытым
один файл при условии, что ни один клиент не выполняет операций записи в
файл. Это важно для сред со старыми машинами. Большинство открытий в
режиме совместимости этих клиентов отображается в запрос открытия для
совместно используемого доступа к файлу для чтения/записи. Однако помни-
помните, что это может также отменять блокировки oplock для других клиентов,
даже если ни один из клиентов в действительности не намерен писать в файл.
Последовательность действий почти такая же, как у исключающей блоки-
блокировки oplock (см. таблицу 4.4). Основное различие состоит в том, что сервер
информирует клиента, что он должен прекратить блокировку Level II oplock,
когда никто не пишет в файл. То есть клиент А, например, может открыть
файл для желательного доступа READ и общего доступа READ/WRITE. Это
означает, что клиент А не будет выполнять никаких записей в файл.
Когда клиент В открывает файл, сервер должен синхронизироваться с
клиентом А, если последний имеет какие-либо буферизованные блокиров-
блокировки. Когда он синхронизируется, запрос клиента В на открытие может быть
завершен. Клиент В, однако, информируется, что он имеет Level II oplock,
а не исключающую блокировку oplock для файла. . .,.
Таблица 4.4. Протокол Level II oplock
Клиент А Клиент В Сервер
Открыть \\coolfile ->
<- открытие успешно. '
. .f¦ ¦.,.,Ki Исключающая блокировка
oplock предоставлена.
Прочитать ->
<- данные
Открыть \\coolfile ->
<- прервать на Level II oplock
для клиента А
Блокировки ->
' ¦ ¦ <- ответ блокировок
Сделано->
<-открытие успешно. Oplock II
' предоставлена клиенту В

Блоки сообщений сервера 115
В этом случае ни один клиент с блокировкой level II oplock на файле не
сможет буферизировать какую-либо информацию блокирования на локаль-
локальной клиентской машине. Это позволяет серверу гарантировать, что если вы-
выполняется какая-либо операция записи, то ему необходимо только уведомить
клиентов level II, что блокировка должна быть прервана, без необходимости
синхронизации всех аксессоров (средств доступа) файла.
Level II oplock может быть ПРЕРВАНА В НИКУДА (BROKEN TO NONE),
означая, что некоторый клиент, открывший файл, выполнил теперь опера-
операцию записи в файл. Так как ни один клиент level II не может создать ситуа-
ситуацию блокирования буфера, то информация на сервере остается в
согласованном состоянии. Записывающий клиент, например, не сможет за-
записать в заблокированный диапазон по определению. Однако данные опере-
опережающего чтения могут буферизироваться на клиентской машине, снижая
тем самым объем сетевого трафика, требуемого файлу. Когда прерывается
блокировка level II oplock, буферизирующий клиент должен очистить свои
буферы и прекратить выполнение всех операций на файле через сеть. Ника-
Никакого ответа на прерывание oplock от клиента не ожидается, когда сервер
прерывает его из LEVEL II в NONE.
Модель безопасности
Каждый сервер делает доступными для клиентов в сети множество ресур-
ресурсов. Ресурсом может быть дерево каталогов, именованный канал, принтер
и т.д. Клиентская машина видит сервер как единственного поставщика
файла или другого доступного ресурса, поэтому она не знает о каких-либо
зависимостях от хранения или службы.
Протокол CIFS требует аутентификации сервера пользователей, прежде
чем будет разрешен доступ к файлу, и каждый сервер аутентифицирует сво-
своих собственных пользователей. Клиентская система должна посылать ин-
информацию аутентификации на сервер, прежде чем сервер разрешит доступ
к своим ресурсам.
Протокол CIFS определяет два метода, которые могут быть выбраны
сервером для безопасности: общий уровень и уровень пользователя.
Сервер общего уровня делает доступным некоторый каталог на дисковом
устройстве (или другой ресурс). Для доступа может потребоваться допол-
дополнительный пароль. Таким образом, любой пользователь в сети, знающий
имя сервера, имя ресурса и пароль, получает доступ к ресурсу. Серверы с
безопасностью общего уровня могут использовать различные пароли для
одного и того же общего ресурса, где различные пароли предоставляют
различный уровень доступа.
Сервер уровня пользователя делает некоторый каталог на дисковом
устройстве (или другой ресурс) доступным, но требует дополнительно, что-
чтобы клиент предоставил имя и соответствующий пароль пользователя для
получения доступа. Серверы уровня пользователя могут применить имя
учетной записи и пароль, предоставленные клиентом. Серверы уровня
пользователя предпочтительнее серверов общего уровня для любой новой
серверной реализации, так как организации обычно считают, что сервер
уровня пользователя легче администрировать. Серверы уровня пользователя

116
могут применять имя учетной записи для проверки списков контроля досту-
доступа на отдельных файлах или иметь один список контроля доступа, который
применяется ко всем файлам в каталоге.
Когда сервер уровня пользователя проверяет имя учетной записи и па-
пароль, предоставленные клиентом, идентификатор, представляющий этот
аутентифицированный экземпляр пользователя, возвращается клиенту в
поле Идентификатор пользователя (UID) ответного SMB. Этот UID дол-
должен включаться во все последующие запросы, сделанные от имени пользо-
пользователя с этого клиента. Сервер общего уровня не возвращает в поле UID
никакой полезной информации.
Модель безопасности на уровне пользователя была добавлена после вы-
выпуска первоначального диалекта протокола CIFS, и, следовательно, некото-
некоторые клиенты могут оказаться неспособными послать имена учетных
записей и пароли на сервер. Сервер в режиме безопасности на уровне поль-
пользователя, общающийся с одним из таких клиентов, будет позволять клиенту
соединяться с ресурсами, даже если клиент не прислал информацию об
имени учетной записи и пароле: .'",..' '' '"'¦
1. Если имя компьютера клиента идентично имени учетной записи, из-
известной на сервере, и если предоставленный пароль для соединения
с общим ресурсом совпадает с паролем этой учетной записи, неявно
будет выполнен "вход пользователя в систему" с помощью этих значе-
значений. Если это не сработает, то сервер может отказать в запросе или
присвоить используемое по умолчанию имя учетной записи по своему
выбору.
2. Значение UID в последующих запросах клиента будет игнорировать-
игнорироваться, и весь доступ будет проверяться в предположении имени учетной
записи, выбранной выше. ' .•?¦;-.. ь :> ,.ч
Пример доступа/общего ресурса
Следующие примеры показывают интерфейс командной строки, позволяющий
серверу предлагать дисковый ресурс, а клиенту соединяться и использовать
этот ресурс.
a) NETSHARE , . .
Команда NET SHARE при выполнении на сервере определяет имя ка-
каталога, который будет сделан доступным для клиентов в сети. Дол-
Должно быть задано общее имя, которое предоставляется клиентам,
желающим получить доступ к каталогу.
Примеры:
NET SHARE docs=c:\dirl\
¦¦¦*' Делает общедоступными все файлы в каталоге C:\DIR1 и его подкаталогах
с общим именем docs в качестве имени, используемого для соединения
с этим ресурсом.

Блоки сообщений сервера 117
Ь) NET USE
Клиенты могут получить доступ к одному или нескольким предлагае-
предлагаемым каталогам с помощью команды NET USE. Когда посылается
. команда NET USE, пользователь может свободно получить доступ к
файлам без дополнительных специальных требований.
Примеры:
: NET USE: d: \\SERVER1\DOCS отображает диск d: в общедоступный
каталог DOCS на сервере Server 1. Пользователь может теперь обраща-
''*¦" ться к файлам на SERVER! C:\DIR1, используя d:. Например, dir d: *.*
выдаст список всех файлов на SERVER1 c:\dirl.
NET USE * \\SERVER1\DOCS mycoolpwd отображает следующий
доступный диск, который использует DOCS на serverl, защищенный
*'>'-' паролем mycoolpwd.
Для серверов уровня пользователя клиент обычно не должен предостав-
предоставлять пароль с помощью команды NET USE. Если пользователю предлагается
ввести пароль, обычно это указывает на сетевую проблему (например, он не
может контактировать с контроллером домена, чтобы проверить полномо-
полномочия). Этот сценарий предоставляет хорошую возможность проверить инст-
инструменты сетевого мониторинга (см. часть IV). Сейчас можно попробовать
проверить, существует ли проблема безопасности:
NET USE * \\SERVERl\DOCS/USER:domainname\username password
Клиентское программное обеспечение должно помнить идентификатор
диска, поставляемый вместе с запросом NET USE, и связать его со значени-
значением идентификатора дерева (TID), возвращаемого сервером в заголовке
SMB. Последующие запросы, использующие этот TID, должны включать то-
только имя пути доступа относительно присоединенного поддерева, так как
сервер интерпретирует поддерево как корневой каталог (виртуальный ко-
корень). Когда пользователь ссылается на один из удаленных дисков, клиент-
клиентское программное обеспечение просматривает свой список дисков для
этого узла и включает идентификатор дерева, связываемый с этим диском
в поле TID каждого запроса.
Отметим, что когда каталог объявляется общедоступным, будут затро-
затронуты все файлы, лежащие под этим каталогом. Если определенный файл
находится внутри области нескольких общих ресурсов, то соединение с
любой из областей общих ресурсов получает доступ к файлу с полномочи-
полномочиями, определенными для предложения, поименованного в NET USE. Сер-
Сервер не будет проверять вложенные каталоги с более ограничительными
полномочиями.
Аутентификация
Сервер CIFS хранит зашифрованную форму пароля клиента. Чтобы полу-
получить аутентифицированный доступ к серверным ресурсам, сервер посыла-
посылает вызов клиенту, на который клиент отвечает подтверждением, что он
знает пароль клиента.

118 ' ' Глава 4
Аутентификация использует шифрование DES в блочном режиме. Функ-
Функция шифрования DES, обозначенная как Е(К, D), получает семибайтный
ключ (К) и восьмибайтный блок данных (D) и создает восьмибайтный за-
зашифрованный блок данных в качестве своего значения. Если данные для
шифрования длиннее восьми байтов, функция шифрования применяется к
каждому блоку из восьми последующих байтов и результаты соединяются
вместе. Если ключ длиннее семи байтов, то данные сначала полностью
шифруются с помощью первых семи байтов ключа, затем следующие семь
байтов и т.д., соединяя каждый раз результаты. Другими словами, чтобы за-
зашифровать 16-байтовую величину D0D1 с помощью 14-байтового ключа
К0К1:
1 '-;' Е(К0К1, D0D1) = Е(К0, DO)E(KO,D1)E(K1, DO)E(K1, Dl)
Поле EnayptionKey (Ключ Шифрования) в ответе SMB_COM_NEGPROT со-
содержит восьмибайтный вызов, обозначенный ниже как "С8", выбираемый
уникальным, чтобы предотвратить атаки повторного воспроизведения. Кли-
Клиент отвечает 24-байтовым ответом, обозначенным "Р24" и вычисляемым, как
описано ниже. (Примечание. Имя "EncryptionKey" является историческим — оно
на самом деле не содержит ключа шифрования.)
Клиент посылает ответ на вызов в запросе SMB_COM_TREE_CONNECT,
SMB_COM_TREE_CONNECT_ANDX и/или SMB_COM_SESSION_SETUP_ANDX,
который следует за обменом сообщением SMB_COM_NEGPROT. Сервер дол-
должен проверить ответ, выполняя те же вычисления, которые делает клиент
при его создании, и проверить, что строки совпадают.
Если строки не совпадают, то, возможно, клиентская система неспособ-
неспособна шифровать; если это так, то строка может быть паролем пользователя
открытым текстом. Сервер должен попробовать проверить строку, как
если бы это был незашифрованный пароль. • vj
Поле SMB, используемое для хранения ответа, зависит от ответа: ,,.,
Password ъ SMB_COM_TREE_CONNECT .-.- >у
Password в SMB_COM_TREE_CONNECT_ANDX' ,,-., ..,. . ..,-. ,. ',_
Account Password в SMB_COM_SESSION_SETUP_ANDX
(Примечание. Здесь имена также являются историческими и не отража-
отражают это использование.)
Содержимое ответа на вызов зависит от диалекта CIFS, как показано в
следующих разделах.
Поддержка распределенной файловой системы (DFS)
Диалекты протокола NT LM 0.12 и более поздние версии поддерживают опе-
операции распределенной файловой системы (DFS — Distributed File System).
DFS предоставляет для этого протокола способ использования единствен-
единственной согласованной схемы именования файлов, которая может охватывать
совокупность различных серверов и ресурсов общего доступа. Модель DFS
использует модель на основе направлений. Этот протокол определяет
способ, которым клиенты получают направления. ¦

Блоки сообщений сервера < 119
Клиент может установить в заголовке запроса SMB флаг, указывающий,
что клиент хочет, чтобы сервер разрешил в DFS пути доступа SMB, кото-
которые известны серверу. Сервер пытается разрешить запрошенное имя в
файл, содержащийся внутри локального дерева каталогов, указанного TID
запроса, и затем нормально продолжить. Если путь доступа запроса раз-
разрешается в файл на другой системе, то сервер возвращает следующую ошибку.
STATUS_DFS_PATH_NOT_COVERED — сервер не поддерживает часть
пространства DFS, требуемую для разрешения пути доступа в запросе.
Клиент должен запросить на этом сервере направление для дополнительной
информации.
Клиент запрашивает направление с помощью запроса TRANS2-DFS-
GETREFERRAL, содержащего интересующий путь доступа DFS. Ответ с
сервера указывает, как клиент должен продолжить.
Метод, с помощью которого топологическое представление DFS хранится
и поддерживается серверами, не определен этим протоколом. г
ЗаголовокБМВ ,а,:.,.,,_Л1,,,.., ..iiifI, ls, ,.^ZZ^
Хотя каждая команда SMB имеет определенное кодирование, в заголовке
SMB есть несколько полей, которые имеют значение для всех SMB. Как
можно увидеть в распечатке ниже, протокол SMB выполняется поверх
NetBIOS, который переносится поверх TCP, реализованный поверх IP, ко-
который реализован поверх метода доступ к среде Ethernet. Эти поля описаны
в последующих разделах. ¦,:--¦ •-: '.;-¦..¦¦, у ' ¦¦' г-,-
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0x414; Proto = TCP; Len: 82
+ TCP: .AP len: 42, seq: 365595-354636, ack: 13582702, win:
8760, src: 1032 dst: 139 (NBT Session)
+ NBT SS: Session Message, Len: 38 .., ...,,¦.'
SMB: С get attributes, File = ... ..',,,' " ' . '. { ' \
SMB: SMB Status = Error Success r,\ ; '
SMB: Error class = No error
SMB: Error code = No error : :
SMB: Header: PID = 0x2011 TID = 0x1002 MID = 0xC502 UID = 0x1003
SMB: Tree ID (TID) = 4098 @x1002)
SMB: Process ID (PID) = 8209 @x2011) "' '
: SMB: User ID (UID) = 4099 @x1003) „ : ..-...•
SMB: Multiplex ID (MID) = 50434 @xC502) '
SMB: Flags Summary = 0 @x0)
SMB: 0 = Lock & Read and Write & Unlock not supported
SMB: 0. = Send No Ack not supported
SMB: ....0... = Using case sensetive pathnames '¦
SMB: . . .0. . . . = No canonicalized pathnames ¦' ! ':!'
SMB: ..0 = No Opportunistic lock •'¦¦¦ ¦'•' •
SMB: .0 = No Change Notify : "*¦ ..'•¦.¦¦•„\<]
SMB: 0 = Client command -¦'¦¦'"]/{>. I -.¦¦'¦
SMB: flags2 Summary = 32768 @x8000)
SMB: 0 = Understands only DOS 8.3 filenames
SMB: 0. = Does not understand extended
attributes

120 Глава 4
;.;.,,. SMB: ... О = No DFS capabilities ,, ..
SMB: ..0 = No paging of 10 ,..
SMB: .0 = Using SMB status codes
' SMB: 1 = Using UNICODE strings
SMB: Commnad = С get attributes ' ' ' .-.¦¦.-
SMB: Word count = 0 ¦' ' ;'¦'¦ .'¦'¦ •** •' ;: :' •• '
SMB: Byte count = 3 i"-':^'' ' •'¦¦¦'¦ '-''¦'- : ' ¦¦•¦'• ¦ ; '¦'
' SMB: Byte parameters ;•.....! ¦/ - ¦
SMB: File name = ,' • : ¦¦¦ ¦¦> ¦ ¦-" '•¦; i • ¦¦ •¦¦ .?cf-.
Поле TID
TID представляет экземпляр аутентифицированного соединения с сервер-
серверным ресурсом. TID возвращается сервером клиенту, когда тот успешно сое-
соединяется с ресурсом, и клиент использует TID в последующих запросах,
ссылающихся на ресурс.
Если сервер выполняется в режиме безопасности общего доступа, TID яв-
является единственным объектом, используемым для разрешения доступа к об-
общему ресурсу. Если пользователь способен выполнить успешное соединение
с сервером, определяя подходящее сетевое имя и пароль (если требуется),
ресурс может быть доступен согласно правам доступа, связанным с общим
ресурсом (одинаковыми для всех, кто получает доступ таким образом).
Полеию -i-.-- .-.:.¦ -• ¦ ¦••¦ ¦•¦.-..¦ '•:. • .¦-.<,.¦!•,;..¦.;,¦-.
Если, однако, сервер выполняется в режиме безопасности на уровне поль-
пользователя, доступ к ресурсу основывается на UID (проверяемом в запросе
SMB_COM_SESSION_SETUP_ANDX), и TID НЕ связан с контролем доступа,
но просто определяет ресурс (такой как общее дерево каталогов).
В большинстве запросов SMB TID должен содержать допустимое зна-
значение. Исключения до получения созданного TID включают SMB_COM_
NEGOTIATE, SMB_COM_TREE_CONNECT, SMB_COM_ECHO и
SMB_COM_SESSION_SETUP_ANDX, где в таких ситуациях для TID должно
использоваться значение OxFFFF. Сервер всегда отвечает за обеспечение
использования действительного TID, где допустимо.
ПолеРГО
Идентификатор процесса (PID) уникальным образом определяет процесс
клиента. Клиенты информируют серверы о создании нового процесса,
просто вводя новое значение PID в диалог о новых процессах.
В базовом протоколе использовалось сообщение SMB SMB_COM_
PROCESS_EXIT для указания катастрофического завершения процесса на
клиенте. В однозадачной системе DOS было возможно возникновение тя-
тяжелых ошибок, вызываемых разрушением процесса, с остающимися от-
открытыми файлами. Поэтому в таком случае посылается сообщение SMB
SMB_COM_PROCESS_EXIT, чтобы позволить серверу закрыть все файлы,
открытые этим процессом.
В LANMAN 1.0 и более новых диалектах не посылается никаких сообще-
сообщений SMB SMB_COM_PROCESS_EXIT. Операционная система клиента

Блоки сообщений сервера 121
должна гарантировать, что будет послано соответствующее сообщение
SMB закрытия и очистки, когда последний процесс, обращающийся к фай-
файлу, его закроет. С точки зрения сервера не существует понятия идентифи-
идентификатора файла (FID), принадлежащего процессу. FID, возвращаемый
сервером одному процессу, может использоваться любым другим процес-
процессом, использующим то же транспортное соединение и TID. Не существует
SMB создания процесса, посылаемого серверу; клиент должен гарантиро-
гарантировать, что только допустимые клиентские процессы получают доступ к FID
(и TID). При получении SMB_COM_TREE_DISCONNECT (или когда сеанс
сервера и клиента прекращается) сервер будет делать недействительными
все файлы, открытые процессом на этом клиенте.
Поле MID
Клиенты, использующие LANMAN 1.0 и более новые диалекты, обычно яв-
являются мультизадачными и допускают несколько асинхронных запросов
ввода/вывода на задачу. Поэтому вместе с PID используется мультиплекс-
мультиплексный идентификатор (MID), чтобы разрешить мультиплексирование одно-
одного соединения клиента и сервера среди нескольких клиентских процессов,
потоков управления и запросов потоков управления.
Несмотря на согласованный диалект, сервер отвечает за обеспечение
того, что каждый ответ содержит те же самые значения MID и PID, которые
они запрашивают. Клиент может затем использовать значения MID и PID
для связывания запросов и ответов и иметь в любое время согласованное
количество ожидающих запросов для определенного сервера.
Поле флагов
Внимательнее рассмотрим первое из двух полей флагов, как показано в таб-
таблице 4.5. Это поле содержит восемь отдельных флагов (используются толь-
только семь), которые пронумерованы от самого младшего до самого старшего
и имеют следующие значения:
SMB: Flags Summary = 0 @x0)
SMB: 0 = Lock & Read и Write & Unlock
не поддерживаются
SMB: 0. = Send No Ack не поддерживается
SMB: ....0... = Использование имен путей доступа
с учетом регистра символов
SMB: . . .0. . . . = Отсутствие канонизированных имен путей доступа
SMB: . .0 = Нет оппортунистической блокировки
SMB: .0 = Нет Change Notify
SMB: 0 = Клиентская команда ' :

122
Таблица
Номер
бита
4.5. Сводная таблица
Значение
первого поля флагов SMB
Глава 4
Самый ранний
диалект
0 Когда этот бит устанавливается на сервере в ответе LANMAN 1.0
SMB_COM_NEGOTIATE, он указывает, что сервер
поддерживает Lock and Read; Write and Unlock.
1 Когда установлен этот флаг, клиент гарантирует, что
существует объявленный получающий буфер, который ¦¦:' ¦
будет поддерживать Send без подтверждения. . .
2 Зарезервирован. Должен быть равен нулю.
3 Когда установлен этот флаг, имена путей доступа LANMAN 1.0
должны интерпретироваться с учетом регистра
символов. Когда флаг сброшен, имена путей доступа
не зависят от регистра символов.
4 Когда этот бит сброшен в ноль, не используется LANMAN 1.0
никаких канонизированных имен путей доступа. ¦¦;>, ;... .
Когда этот флаг установлен в 1, имена файлов/ ,-....., .,, -¦-,,,
v ; каталогов заданы в верхнем регистре, являются : , ......
т< допустимыми символами, и удалены; в качестве
, 1 разделителей используются одиночные обратные
косые черты. ...,^_Р^ _ тт,,,.г тт -.
5 Оппортунистическая блокировка — когда флаг LANMAN 1.0
установлен, клиент запрашивает, чтобы файл был
оппортунистически заблокирован, если этот процесс у- ¦; •¦¦ ,;<ф \::^,,
.-,. ¦ открывает файл только во время запроса открытия.
Если сервер "удовлетворяет" запрос этой oplock, этот г
бит должен оставаться заданным в соответствующем
ответе SMB для указания клиенту, что запрос oplock
был удовлетворен.
6 Change Notify указывает, что сервер должен LANMAN 1.0
уведомить клиента о любом действии другого
клиента, которое может изменить файл (удалить,
задать атрибут, переименовать и т.д.). Если этот бит
не задан, то сервер должен уведомить клиента только
о запросе другого клиента на открытие файла.
7 Client Command — установленный бит свидетельствует, PC Network
что этот SMB послан с сервера в ответ на запрос program 1.0
клиента. Поле команды содержит обычно то же
самое значение в запросе клиентом протокола
у сервера, как и в соответствующем ответе от сервера
клиенту. Это бит однозначно отличает запрос
команды от ответа команды.

Блоки сообщений сервера
123
Поле Flags2
Это поле содержит шесть отдельных флагов, которые пронумерованы от
самого младшего к самому старшему биту и определены в таблице 4.6. Фла-
Флаги, которые не определены, должны быть заданы нулем.
SMB: flags2 Summary = 32768 @x8000)
SMB: 0 = Понимает только имена файлов DOS 8.3
SMB: 0. = Не понимает расширенные атрибуты
: SMB: ... 0 = Не поддерживает DFS
SMB: . . 0 = Без подкачки ввода-вывода
SMB: .0 = Использует коды состояния SMB
SMB: 1 = Использует строки UNICODE
Таблица 4.6. Раздел SMB flags2
Биты Значение Самый
ранний диалект
0 Если установлен в запросе, сервер может
возвращать в ответе длинные компоненты
в именах путей доступа.
1 Если установлен, то клиент знает
о расширенных атрибутах.
12 ¦¦!. Если установлен, то запрос любого имени NTLM0.12
v ¦ I пути доступа должен быть разрешен
в распределенной файловой системе. '•,•,,¦'.*¦'¦¦
13 Если установлен, то этот флаг указывает, что
чтение будет разрешено, если клиент не имеет . _
полномочия на чтение, но выполнил полномочие. . .,.,,.-.,.,.
Имеет смысл только для запроса чтения.
14 Если установлен, то этот флаг определяет, что NT LM 0.12
возвращаемый код ошибки является 32-битным
кодом ошибки в status.status. Иначе используется ¦•'¦¦ "•'¦
класс состояния doserror. Этот флаг должен
устанавливаться при использовании кодов .
состояния NT. , _. '_
15 Когда этот флаг задан, поля STRING NT LM 0.12
записываются в кодировке UNICODE. Когда
не задан, то поля STRING кодируются в ASCII.
Поле состояния
SMB возвращает клиенту информацию об ошибке в поле состояния, как
показано ниже. Диалекты протокола до NT LM 0.12 возвращают клиенту
состояние, используя комбинацию Status.DosError.ErrorClass и Status.DosEr-
ror.Error. Начиная с NT LM 0.12 CIFS, серверы могут возвращать клиентам

124 Глава 4
32-битную информацию об ошибках с помощью Status.Status, если входящее
сообщение клиента SMB в поле Flags2 заголовка SMB имеет заданным бит
14. Содержимое параметров ответа не гарантировано в случае возвраще-
возвращения ошибки и должно игнорироваться. Последующая запись или закрытие
файла могут возвращать сообщение о том, что предыдущая запись не про-
прошла. Обычно отказ обратной записи ограничен ошибками жесткого диска
и отсутствием свободной памяти устройства.
SMB: SMB Status = Error Success
SMB: Error class = No error
SMB: Error code = No error
Задержки
Обычно блокирование сообщений SMB на сервере не ожидается, они дол-
должны возвращаться "немедленно". Но некоторые запросы SMB указывают на
периоды задержки для завершения запроса на сервере. Если реализация
сервера не может поддерживать задержки, то сразу после запроса будет
возвращаться ошибка, как если бы произошла задержка, потому что ресурс
был недоступен. у.--.-*-.. .-:..,,,, <
Буфер данных (BUFFER) и форматы строк
Часть данных SMB обычно содержит данные, которые прочитаны или за-
записаны, пути доступа файлов или пути доступа каталогов. Формат порции
данных зависит от сообщения. Все поля в порции данных имеют один формат.
В каждом случае оно состоит из байта идентификации, за которым следуют
данные (см. таблицу 4.7).
Таблица 4.7. Буфер данных и форматы строк
Идентификатор Описание Значение
Блок данных 1
Диалект ' ' Строка, заканчивающаяся нулем 2 ;
Имя пути доступа Строка, заканчивающаяся нулем 3 ,.
ASCII Строка, заканчивающаяся нулем 4
Блок переменной 5
Когда идентификатор указывает на блок данных или блок переменной,
формат является словом, указывающим длину последующих данных.
Во всех диалектах до NT LM 0.12 все строки кодируются в ASCII. Если
согласованный диалект — NT LM 0.12 или более поздний, то может проис-
происходить обмен строками в кодировке Unicode. Строки Unicode включают
имена файлов, имена ресурсов и имена пользователей. Они применимы к
строкам, заканчивающимся нулем, строкам, определяющим длину, и к стро-
строкам с префиксом типа. Во всех случаях, где строка передается в формате
Unicode, она должна быть выровнена по границе слова относительно нача-
начала SMB. Если строка не попадает естественным образом на двухбайтовую

Блоки сообщений сервера 125
границу, то вставляется нулевой байт дополнения, а строка Unicode будет
начинаться со следующего адреса. В описании SMB элементы, которые мо-
могут кодироваться в Unicode или ASCII, помечены как STRING. Если исполь-
используется кодирование ASCII, даже если согласованной строкой является
Unicode, величина помечается как UCHAR.
Для строк Unicode с префиксом типа дополнительный байт находится
после байта типа. Байт типа равен четырем (указывая SMB_FORMAT_ASCH),
независимо от того, является строка ASCII или Unicode. Для строк, началь-
начальные адреса которых находят с помощью смещения внутри фиксированной
части SMB (в противоположность просто находимым в байте, следующем
за предшествующим полем), гарантируется, что смещение будет правильно
выровнено.
Строками, которые никогда не передаются в Unicode, являются:
Строки протокола в запросе Negative SMB.
Строки имени службы в Tree Connect And X SMB.
В поле FLAGS2 каждого заголовка SMB должен быть установлен в 15 бит.
Несмотря на гибкую схему кодирования, ни одна часть порции данных
не может быть опущена или вставлена в не принятом порядке. Кроме того,
нельзя опустить ни WORDCOUNT, ни BYTECOUNT со значением 0 в конце
сообщения.
Кодирование режима доступа
Различные клиентские запросы и ответы сервера, такие как SMB_COM_OPEN,
передают режимы доступа к файлу закодированными в USHORT. Кодирование
осуществляется следующим образом:
1111 11 -;ii ' ¦'-¦' ¦''¦>'¦ <¦¦ ¦ '
54321098 7654 3210 ' - " •
rWrC rLLL rSSS rAAA •
где: ¦ ¦ • '• - ' :'-' -i> ¦ ¦¦' ¦ :
• W — Режим сквозной записи. Никакого опережающего чтения или по-
последующей записи не допускается на этом файле или устройстве. Ког-
Когда возвращается ответ, ожидается, что данные будут на диске или
устройстве.
• S — Режим общего доступа:
0 — Режим совместимости
1 — Отказ чтения/записи/выполнения (исключающий) .,.
2 — Отказ записи
3 — Отказ чтения/выполнения
4 — Отказа нет
• А — Режим доступа •. , ......
0 — Открыт для чтения , . . . , ,:
1 — Открыт для записи
2 — Открыт для чтения и записи
3 — Открыт для выполнения
{ rSSSrAAA =11111111 (hex FF) указывает, что FCB открыт (???)

126 "> Глава 4
¦ :. ¦¦•' С — Режим кэширования > :< .. • у« ¦; >
•¦¦'¦¦¦ - ¦'<! О — Обычный файл ¦ il .<. ищ•.¦ ..
¦ в 1 — Не кэшировать этот файл .'>--;•'• .и; 'Ьо.дг
• L — Локальность ссылки ' '
0 — Локальность ссылки неизвестна '"''**¦
1 — В основном последовательный доступ *> ''
2 — В основном случайный доступ
3 — Случайный доступ с некоторой локальностью
от 4 до 7 — В настоящее время не определены
Кодирование функции открытия (Open)
Функция открытия (Open) определяет действие, которое будет выполнено,
в зависимости от того, существует файл или нет. Это слово имеет следующий
формат:
биты: * —" •?¦— -^-~-;V- -;-',: • :i.-.:::.'.': ': ¦.:.. '';v->.;:-? "гл ' ";
ПИП ¦' t^*-r.i- l-''S-i-лп: ¦;¦,.,¦№,о.\,i л,,..¦, $?...i/.i I ¦¦•;->-\п
5432 1098 7654 3210 г .ч-¦,.'.•;«...••u(«*;.o.- ¦< ->г.ъ <>, Kli $H, ,i; .<>; о .и I
ГГГГ ГГГГ ГГГС ГГОО "¦"' ¦''' ' I' '''' '¦ ¦'•'>•• '¦¦ '< >¦' .Я/'.Л .П I ,o ". -..is. ;.;
где:
• С — Create (Создать) (действие, которое будет выполнено, если файл
не существует). , ... -. ,..
О — Отказ
J.UI
i ,
г
>v
til
1/
s"i«
!
'ч 1.Т!
.'. ул1
I M
•¦' 1 ' ' '¦
• >»''»!
¦..¦¦ 1
' R :
СИ[.
. H
Mi,;
.1-,
¦ /U.
11!(.
(¦.:>;
л.-. •.;.
1 — Создать файл >.¦ м.-„и. .-
i,u . , г _ Зарезервировано (должен быть ноль) : ': •¦•'"• -- "
• О — Open (Открыть) (действие, которое будет выполнено, если файл
существует).
0 —Отказ А- /•••¦['*•. '/¦"•¦
1 — Открыть файл ¦
2 — Отрезать файл
¦¦1!: . i«;i . : •!.-. /Ч -
Кодирование действия открытия (Open)
Действие в ответе на запрос открытия или создания описывает действие,
предпринимаемое в результате этого запроса. Оно имеет следующий формат:
биты:
ЦП И . .. . ¦ .1.1 VMM, ..,:,-„.,,„.,.Г., ! • О
5432 1098 7654 3210 г>../,¦¦••,!¦ /ж .. ,; ->мш> «.:ч-т ;,...:¦¦ :
Lrrr rrrr rrrr rrOO *'»:'": (
• L — Lock (Блокировка) (состояние блокировки одним пользователем
всего файла).
0 — Файл открыт другим пользователем (или режим не поддерживает-
поддерживается сервером)
1 — Файл в настоящее время открыт только этим пользователем
г — Зарезервировано (должно быть ноль)

Блоки сообщений сервера 127
• О — Открыть (действие, предпринимаемое при открытии) . i^!....,;
1 — Файл существовал и был открыт
2 — Файл не существовал, но был создан ; - . " ''".'
3 — Файл существовал и был обрезан ; J А \'< • i
Кодирование атрибутов файла ,<
Когда сообщения SMB передают информацию об атрибутах файлов, она
кодируется в 16 битах, как показано в таблице 4.8.
Таблица 4.8. Атрибуты файлов
Значение Описание
0x01 Файл только для чтения
0x02 , , ¦ • ¦. Скрытый файл ' ¦ ' ¦ ;
0x04 , ь . Системный файл
0x08 • ~ -Том- :--•• ¦¦-r-
0x10 Каталог ^^-'¦¦>¦ ?' .о}1 •< • -¦¦; j\¦. ,¦-^
0x20 ., ¦':'.-¦,. Архивный файл
Другие Зарезервированы. Должны быть заданы в 0
Кодирование расширенных атрибутов файла
Расширенные атрибуты файла являются 32-битным значением, составленным
из атрибутов и флагов.
Допустима любая комбинация атрибутов, перечисленных в таблице 4.9,
за исключением того, что все остальные атрибуты файла переопределяют
FILE_ATTRIBUTE_NORMAL.
Допустима любая комбинация флагов, перечисленных в таблице 4.10.
Таблица 4.9. Расширенные атрибуты файла
Атрибут Обозначение Описание
FILE_ATTRIBUTE_ 0x020 Файл не был архивирован с момента
ARCHIVE последней модификации. Используется
прежде всего для целей резервного
копирования.
FILE_ATTRIBUTE_ 0x800 Файл или каталог являются сжатыми.
COMPRESSED Для файла это означает, что данные
в файле сжаты. Для каталога это означает,
• ¦ • что атрибут сжатия установлен по
умолчанию. Новые файлы будут сжаты.
FILE_ATTRIBUTE_ 0x080 Никаких специальных атрибутов.
NORMAL Действителен, только если
используется один.

128 Глава 4
Таблица 4.9. Расширенные атрибуты файла (продолжение)
Атрибут Обозначение Описание
FILE_ATTRUBUTE_ 0x002 Файл является скрытым и не включается
HIDDEN в обычный листинг каталога.
FILE_ATTRIBUTE_ 0x001 Файл предназначен только для чтения.
READONLY ¦ ¦ . <~ ¦ - Приложения могут читать, но не могут
писать в файл или удалять файл.
FIILE_ATTRIBUTE_ 0x100 Файл является временным файлом.
TEMPORARY .,_ ....
FILE_ATTRIBUTE_ 0x010 Идентифицирует каталог. Не является
DIRECTORY файлом по существу.
FILE_ATTRIBUTE_ 0x004 Файл является частью операционной
SYSTEM системы или используется исключительно
операционной системой.
Пакетные запросы (Сообщения "AndX")
LANMAN 1. 0 и более поздние диалекты протокола CIFS допускают переда-
передачу на сервер нескольких запросов SMB в одном сообщении. Сообщения
этого типа называются AndX SMB, они подчиняются следующим правилам:
• Вложенные команды не повторяют информацию заголовка SMB. Вме-
Вместо этого следующее сообщение SMB начинается на поле WordCount.
• Все множественные (сцепленные) запросы должны соответствовать
согласованному размеру передачи. Например, если было послано со-
сообщение SMB_COM_TREE_CONNECT_ANDX, включающее
SMB_COM_OPEN_ANDX, которое включает SMB_COM_WRITE, то
все они должны соответствовать согласованному размеру буфера. Это
будет ограничивать размер записи.
• Существует одно посылаемое сообщение, содержащее сцепленные за-
запросы, и одно сообщение ответа на сцепленные запросы. Сервер может
НЕ посылать отдельные ответы на каждый из сцепленных запросов.
• Все сцепленные ответы должны соответствовать согласованному раз-
размеру передачи. Это ограничивает, например, максимальное значение
вложенного SMB_COM_READ. Клиент не должен запрашивать больше
байтов, чем может поместиться во множественном ответе.
• Сервер неявно будет использовать результат первой команды в
команде "X". Например, TID, полученный через SMB_COM_TREE_
CONNECT_ANDX, мог бы использоваться во вложенном SMB_COM_
OPEN_ANDX, a FID, полученный в SMB_COM_OPEN_ANDX, мог бы
использоваться во вложенном SMB COM READ.

Блоки сообщений сервера
129
• Каждый сцепленный запрос может ссылаться только на тот же FID и
TID, что и другие команды в комбинированном запросе. Сцепленные
запросы могут рассматриваться как выполняющие одну (из нескольких
частей) операцию на одном ресурсе. ,
• Первая КОМАНДА, встретившая ошибку, будет останавливать всю да-
дальнейшую обработку встроенных команд. Сервер не будет возвращать
команды, которые выполнились успешно. Поэтому, если сцепленный
запрос содержал SMB_COM_OPEN_ANDX и SMB_COM_READ, и сер-
н' вер смог успешно открыть файл, но чтение встретило ошибку, то по-
после этого файл остался бы открытым. Это в точности то же самое, как
* L если бы запросы были посланы раздельно.
Таблица 4.10. Дополнительные флаги
Атрибут
Определение Описание
FILE_FLAG_WRITE 0x80000000
JTHROUGH
FILE_FLAG_NO_BU 0x20000000
FFERING
FILE_FLAG_RAND 0x10000000
ОМ ACCESS
FILE_FLAG_SEQUE 0x08000000
NTIAL SCAN
FILE_FLAG_DELET 0x04000000
E_ON_CLOSE
FILE_FLAG_BACKU 0x02000000
P_SEMANTICS
I
FILE_FLAG_POSIX_ 0x01000000
SEMANTICS
Приказывает ОС выполнить сквозную
запись всего промежуточного кэша
и перейти вместо этого прямо к файлу.
Не разрешает отложенную запись.
Запрашивает сервер открыть файл
без промежуточной буферизации.
Это запрос, который сервер не обязан
принять.
Указывает, что приложение будет
использовать файл в режиме случайного
доступа. Сервер может использовать эту
информацию для оптимизации
кэширования файла.
Указывает, что приложение будет
получать доступ к файлу
в последовательном режиме. Сервер
может использовать этот флаг для
оптимизации кэширования.
Приказывает серверу удалить файл ,|,,,
немедленно после того, как все ,,-¦ ;,'
дескрипторы будут закрыты.
Файл открывается для резервного
копирования или операции
восстановления. Сервер должен
позволить переопределить параметры
безопасности файла, если были получены
соответствующие полномочия.
Использовать правила Posix (допускают
имена, зависимые от регистра символов).

130 " ' " Глава 4
Если при обработке сцепленных запросов возникает ошибка, то послед-
последним (из сцепленных запросов в буфере) будет запрос, встретивший ошиб-
ошибку. Другие необработанные сцепленные запросы будет проигнорированы,
когда сервер встретит ошибку, и не будут представлены в сцепленном отве-
ответе. В действительности последняя допустимая команда ANDXCOMMAND
(если существует) будет представлять SMB, на котором встретилась ошиб-
ошибка. Если нет действительной команды ANDXCOMMAND, то возникшая при
первом запросе/ответе ошибка и COMMAND содержат отказавшую коман-
команду. Во всех случаях информация об ошибке возвращается в заголовке SMB
в начале буфера ответа.
Каждый сцепленный запрос и ответ содержит смещение (с начала заго-
заголовка SMB) к следующему сцепленному запросу/ответу (в поле AndXOffset в
различных протоколах "and X", например, SMB_COM_OPEN_ANDX). Это
позволяет создавать запросы распакованными. Между концом предыдуще-
предыдущего запроса (как определено WordCount и ByteCount) и началом следующего
сцепленного запроса может быть пробел. Это упрощает создание сцеплен-
сцепленных запросов протокола. Отметим, что так как клиент должен знать размер
возвращаемых данных, чтобы послать правильное число получений (на-
(например, SMB_COM_TRANSACTION, SMB_COM_READ_MPX), данные в
каждом ответе SMP ожидаются обрезанными до максимального числа
512-байтных блоков (секторов), которые будут соответствовать (начиная с
32-битной границы) согласованному размеру буфера с нечетным числом
байтов, остающихся (если остаются) в конечном буфере. _
Обзор главы
В этой главе был рассмотрен протокол SMB. Глава началась с обзора его ра-
работы; было показано, как определяется имя сервера. Далее мы обсудили
разрешения имен серверов и функцию транспортных сообщений. Подроб-
Подробно было изучено согласование диалекта, создание соединения и способы,
которые использует SMB для обратной совместимости.
Затем обсуждались вопросы настройки сеанса, управления соединением
и подпись SMB. Мы познакомились со всеми видами блокировок: исключа-
исключающими блокировками oplocks, пакетными блокировками и блокировками
oplocks level II. Затем была рассмотрена модель безопасности и пример, ис-
использующий доступ к ресурсу и общий доступ.
Затем мы рассмотрели реальную структуру заголовка SMB. Были показа-
показаны MID, TID, PID, UID и FID, рассмотрены задержки, буферы данных и ко-
кодирование режима доступа. Конец главы был посвящен созданию пакетов
запросов в SMB.
¦¦;.v>-. y.iUK^-r.u ¦ ."км-Я1л<
В следующей главе п Л
Мы переходим ко второй части книги, посвященной сетевому трафику.
Начнем обзор на клиентской стороне, а затем перейдем на серверную сто-
сторону трафика.

ЧАСТЬ II
Сетевой трафик
Анализ и оптимизация:
взгляд на проблемы
G
существует множество вещей, вовлеченных в выполнение анализа и опти-
оптимизации сетевого трафика. Необходимо рассмотреть общение между маши-
машинами, а также общий поток информации. В этом разделе мы "подслушаем "
общение между компьютерами. Сначала будет рассмотрена коммуникация
между клиентами и серверами. Затем мы послушаем, что говорят сами серве-
серверы. Наконец, перейдем к методам, которые помогут нам выявить максимум
полезной информации из этого "шума".

Глава 5
Клиентский трафик
Этот раздел книги начинается с изучения клиентского трафика. В этой главе
будут рассмотрены различные его источники: трафик, связанный с протоко-
протоколами, трафик, связанный с поиском различных объектов в сети, и т.п. Затем
обсудим способы сокращения трафика, которые обычно применяются
в сетях. Мы приступим к анализу с момента первого включения клиентской
машины, т.е. с того, где начинается клиентский трафик.
Инициализация клиента i i
Клиентские машины начинают генерацию трафика с того момента, как то-
только они включаются, и они не прекращают создавать трафик, пока не бу-
будут выключены физически. Так как задача состоит в оптимизации сети,
необходимо просто определить, сколько трафика создают эти машины, и
до какой степени можно было бы сократить этот трафик, если это вообще
возможно. Итак, откуда поступает трафик, когда включают машину? Это за-
зависит прежде всего от протокола, который выполняется на данной маши-
машине. Для начала необходимо взглянуть на "типичную машину Windows 98",
которая использует DHCP для присвоения адреса IP, WINS для разрешения
имен NetBIOS и DNS для работы в Интернете. Сама машина не реализует
никакого общего доступа к файлам или печати. Она конфигурируется для
регистрации в домене Windows NT и не использует никаких политик или
профилей. Короче говоря, это может быть любой работающий ПК. Какой
же вид трафика этот обычный компьютер собирается создавать, когда он
регистрируется в сети? При загрузке машины и регистрации пользователя
сети создаются по крайней мере четыре различных вида трафика. Эти
типы трафика перечислены в таблице 5.1.

134
Глава 5
Таблица 5.1. Трафик при инициализации клиента
Тип трафика Описание трафика Число кадров Число байтов
DHCP
WINS
Проверка
регистрации
Общий трафик
инициализации
Получение IP-адреса 4 кадра
от сервера DHCP
Регистрация имени
NetBIOS
По крайней мере
4 кадра '
Проверка регистрации По крайней мере
контроллером домена 24 кадра
По крайней мере
32 кадра
По крайней мере
1368 байтов
По крайней мере
428 байтов ^ $.
По крайней мере
3105 байтов
По крайней мере
4901 байтов
Трафик DHCP
При использовании в сети TCP/IP существует вероятность, что в сети при-
применяется DHCP для раздачи IP-адресов клиентским машинам и, возможно,
некоторым принтерам. Нечего и говорить, что если TCP/IP является един-
единственным протоколом в сети, то клиентская машина должна иметь допусти-
допустимый IP-адрес, чтобы общаться с другими устройствами в сети, например
компьютерами, маршрутизаторами, принтерами и серверами. Этот IP-ад-
IP-адрес должен иметь подходящий сетевой адрес, адрес хоста и маску подсети,
иначе коммуникация просто не будет происходить. Если имеется несколько
сегментов, то требуется также используемый по умолчанию шлюз.
DHCP может управлять этими простыми задачами, и даже сделать бо-
больше. В действительности это четкий и эффективный протокол, которо-
которому требуются только четыре кадра для выдачи адреса и два кадра для
обновления этого адреса позже. Рассмотрим это подробнее.
Процесс получения адреса Когда загружается клиент DHCP, первое,
что он должен сделать, это найти сервер DHCP, выдающий IP-адреса для
подсети, к которой он присоединен. Для этого устройство пошлет сообще-
сообщение поиска DHCP, указывающее, что оно хотело бы получить IP-адрес. Сер-
Сервер DHCP, получив сообщение поиска, ответит предложением DHCP. Оно
говорит: "Я получил ваш запрос и вот адрес, который у меня есть". Клиент-
Клиентская машина может получить несколько предложений DHCP от нескольких
серверов, которые могут услышать сообщение поиска DHCP. Клиент выбе-
выберет первое полученное им предложение DHCP и ответит серверу DHCP,
что он хочет получить предложенный IP-адрес. Это называется запросом
DHCP. Сервер DHCP при получении запроса ответит подтверждением
(АСК): "Можете начинать использовать IP-адрес". Таблица 5.2 резюмирует
этот процесс.
Как можно видеть в таблице 5.2, DHCP использует широковещание в те-
течение всего процесса. Это позволяет другим машинам в сети знать о том, что
происходит. Рассмотрим этот процесс подробнее. В приведенной ниже рас-
распечатке заголовка Ethernet можно видеть, что адресом назначения является
FFFFFFFFFFFF. Это широковещательный адрес для уровня доступа к среде
передачи. Все устройства в сегменте Ethernet должны будут обрабатывать

Клиентский трафик
135
этот кадр, пока не дойдут до раздела UDP (порта дейтаграмм пользователя)
и не обнаружат, что они не имеют указанного порта UDP. В распечатке так-
также видно, что размер кадра Ethernet равен 342 байтам. Это размер данного
кадра Ethernet, включая заголовок. Число остающихся байтов равно 328,
что является полезной нагрузкой минус 14-байтовый заголовок Ethernet.
ETHERNET: ЕТУРЕ = 0x800 : Protocol = IP: DOD Internet Protocol
ETHERNET: Destination address: FFFFFFFFFFFF
ETHERNET: 1 = Group address
ETHERNET: 1. = Locally administered address
ETHERNET: Source address : 00104BEC8DB2
ETHERNET: 0 = No routing information present
ETHERNET: 0. = Universally administered address
ETHERNET: Frame Length : 342 @x0156)
ETHERNET: Ethernet Type : 0x0800 (IP: DOD Internet Protocol)
ETHERNET: Ethernet Data: Number of data bytes remaining = 328
@X0148) Г, ¦¦ .;•. .... ., ,,. ,--,.,. :¦•.;¦, . ,,¦. : .... Г •.,.:.;¦
Часть с заголовком IP разбирается в распечатке, которая следует за этим
параграфом. Прежде всего отметим, что полезная нагрузка использует
протокол UDP (протокол пользовательских дейтаграмм). Это компактный
эффективный протокол, который идеально подходит для процесса DHCP.
Таблица 5.2. Процесс получения IP
Тип Место назначения Описание
DHCP Discover Широковещание Клиент ищет сервер DHCP.
DHCP Offer Широковещание Сервер DHCP, услышав сообщение
DHCP Discover, отвечает адресом IP.
DHCP Широковещание Клиент DHCP отвечает согласием
принять предложение адреса IP.
DHCP ACK Широковещание Сервер DHCP подтверждает выделение
адреса.
Отметим затем адрес IP источника 0.0.0.0. Это в действительности име-
имеет смысл, так как машина еще не получила адрес IP, и поэтому значения
0.0.0.0 являются просто пустыми позициями. Адрес места назначения
255.255.255.255 указывает на сообщение широковещания. Это означает,
что оно приходит на каждое устройство в определенной подсети. Если мар-
маршрутизаторы сконфигурированы для пересылки широковещательных со-
сообщений DHCP, то они будут также попадать в другие подсети. После
завершения заголовка остается еще 308 байтов. Вычитание этих байтов из
первоначальных 328 байтов дает длину заголовка IP, равную 20 байтам.
IP: ID = 0x0; Proto = UDP; Len: 328 ; :
IP: Version = 4 @x4) '¦..,; . i ¦ • •¦-•¦.¦
IP: Header Length = 20 @x14)
IP: Service Type = 0 @x0) . .
IP: Precedence = Routine

136 Глава 5
. . /.'..д.:.u IP: . . .0. . . . = Normal Delay ; ¦•• . ¦ :¦ ¦
..,-.¦¦¦•¦¦'-•¦••¦¦ IP: ....0... = Normal Troughput •¦••¦-. :. ,..,.¦ ^ .,'.¦'¦ .; ,
IP: 0.. = Normal Reliability '¦¦¦¦>}' ,imi '¦¦"¦¦<¦';
IP: Total Length = 328 @x148) ,^, ,. , i v. .....
IP: Identification = 0 @x0) , .
IP: Flags Summary = 0 @x0)
IP: 0 = Last fragment in datagram •
IP: 0. = May fragment datagram if necessary
IP: Fragment Offset = 0 @x0) bytes
IP: Time to Live = 128 @x80)
IP: Protocol = UDP-User Datagram ' ":-:
IP: Checksum = 0x39A6 •
IP: Source Address =0.0.0.0
IP: Destination Address = 255.255.255.255 -.' • ¦ "•
IP: Data: Number of data bytes remaining = 308 @x0134)
Перейдем теперь к разделу UDP сообщения поиска DHCP. Отметим в
приведенной ниже распечатке, что используется мультивещание IP
(Multicast), и что порт источника UDP равен 68. Этот порт используется
для запросов клиента ВООТР, в то время как порт назначения UDP равен 67,
порту сервера ВООТР. Если маршрутизатор не позволяет пересылать на
эти два порта UDP, а сервер DHCP находится в другой подсети, то эти за-
запросы останутся без ответа, если не будет сконфигурирован отдельный
агент пересылки ВООТР.
UDP: IP Multicast: Src Port: BOOTP Client, F8); Dst Port:
BOOTP Server F7): Length = 308 @x134) ¦
UDP: Source Port = BOOTP Client ..... y/, .., ¦ .-s. j
. . п; UDP: Destination Port = BOOTP Server
UDP: Total Length = 308 @x134) bytes
":/ UDP: UDP Checksum = 0x78C3
UDP: Data: Number of data bytes remaining = 300 @x012C)
Последний раздел сообщения поиска DHCP является самым главным
разделом кадра. Отметим, что это кадр поиска и таким идентифицируется.
Затем мы видим несколько параметров, которые сообщают получающему
компьютеру, как прочитать сообщение. Например, длина аппаратного ад-
адреса равна шести байтам. Он прошел через 0 переходов и не имеет задан-
заданных флагов. Задание флагов позволяет получающим машинам обработать
сообщение более эффективным образом, не требуя чтения раздела флагов.
Перейдем к разделу адреса. Можно видеть, что все задано как .0.0.0". За-
Затем идет реальный адрес MAC машины клиента. В данном случае это
00104BEC8DB2. В запрошенном поле адреса мы видим, что машина "Kenny"
(машина клиента Windows 98 DHCP) имела раньше IP-адрес в этой сети
и запрашивает тот же адрес. Эта информация хранится в реестре и извле-
извлекается при создании сообщения поиска DHCP. Если запрошенный адрес
недоступен в сети, то запрашивающей машине будет послан NAK.
DHCP: Dicover (xid=05D105Dl)
DHCP: Op Code (op) = 1 @x1)
DHCP: Hardware Type (htype) = 1 @x1) 10 Mb

Клиентский трафик
137
Ethernet
DHCP: Harware Address Length (hlen) = 6
@x6)
DHCP: Hops (hops)
DHCP: Transaction ID (xid) =
DHCP: Seconds (sees)
DHCP: Flags (flags) =
DHCP: 0 =
Client IP Address (ciaddr) =
Your IP Address (yiaddr) =
Server IP Address (siaddr) =
Relay IP Address (giaddr) =
Client Ethernet Address (chaddr)
Server Host Name (sname) =
Boot File Name (file)
Magic Cookie = [OK]
Option Field (options)
DHCP Message Type =
Client-identifier =
DHCP
DHCP
DHCP
DHCP
DHCP
DHCP
DHCP
DHCP
DHCP
DHCP
DHCP
8d b2
DHCP
DHCP
DHCP
0 @x0)
97584593 @x5Dl05Dl)
0 @x0)
0 @x0)
No Broadcast
0.0.0.0
0.0.0.0
0.0.0.0
o.o.o.o ' ;•';¦
= 00104BEC8DB2 ' ' "'- '
<Blank>
<Blank> '¦ '
DHCP Discover
(Type: 1) 00 10 4b ex
Requested Address
Host Name
Parameter Request List
Of 2c2e 2f 39
DHCP: End of this option field
10.0.0.76
kenny
(Length: 8)
01 03 06
Теперь мы переходим к серверному кадру DHCP Offer. Этот заголовок
Ethernet имеет такие же свойства, как и заголовок из кадра DHCP Discover,
поэтому нет необходимости повторять его здесь. Интересный момент от-
относительно IP-заголовка показан в приведенной ниже распечатке. Адрес
источника является IP-адресом сервера DHCP, и мы видим, что он по-преж-
по-прежнему использует широковещание. Вспомните, в данный момент процесса
клиентская машина не имеет адреса IP. Остающиеся данные равны 308 байтам,
что идентично пакету предложения DHCP в конце заголовка IP.
IP: Protocol = UDP - User Datagram
IP: Checksum = 0x787B
IP: Source Address = 10.0.0.11
IP: Destination Address = 255.255.255.255
IP: Data: Numberr of data bytes remaining = 308 @x0134)
Раздел UDP выглядит точно так же, как заголовок UDP сообщения
DHCP Discover, за исключением того, что порты источника и места назна-
назначения переключаются, как показано ниже.
UDP: IP Multicast: Src Port: BOOTP Server, F7); Dst Port:
BOOTP Client F8); Length = 308 @x134)
u' UDP: Source Port = BOOTP Server ¦>¦•¦'•*¦•'¦!
¦;v:' UDP: Destination Port = BOOTP Client ' ' '
¦i! ¦ UDP: Total length = 308 @x134) bytes '"'
>•'¦¦¦ UDP: UDP Checksum = 0x6D2F
i ¦ UDP: Data: Number of data, bytes remaining = 300
@x012C) ¦ '

138
Глава 5
Теперь мы подошли к разделу DHCP пакета предложения DHCP. Отме-
Отметим, что разделы предложения, Ethernet и флагов выглядят аналогично па-
пакету запроса DHCP. Однако теперь IP-адрес заполнен с помощью точного
IP-адреса, который был предоставлен в запросе DHCP. Это, очевидно, не
всегда так, но происходит довольно часто в небольших сетях, имеющих
в своем распоряжении большие адресные пулы.
Раздел DHCP Options теперь заполнен. Клиентская машина имеет все,
что ей нужно, чтобы правильно оценить предложение сервера. В данном
случае маска подсети равна 255.0.0.0, выделенный адрес действителен в те-
течение трех дней, делающий это предложение сервер DHCP имеет адрес
10.0.0.11, а адрес маршрутизатора 10.0.0.15. Кроме того, сервер DNS имеет
адрес 10.0.0.10. Тот же самый сервер обеспечивает также службы разрешения
имен NetBIOS с используемым по умолчанию методом 0x08.
DHCP: Offer (xid = 05D105D1) '
DHCP: Op Code (op) = 2 @x2)
•" "*""* DHCP: Hardware Type (htype) = 1 @x1) 10Mb
Ethernet
Hardware Address Length (hlen) = 6 @x6)
(hops) = 0 @x0)
(xid) = 97584593
ID
DHCP:
DHsCP: Hops
DHCP: Transaction
@x5D105Dl)
DHCP: Seconds (sees)
DHCP: Flag (flags)
DHCP: 0 = No
Client IP Address (ciaddr)
Your IP Address (yiaddr)
Server IP Address (siaddr)
Relay IP Address (giaddr)
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
= 0 @x0)
= 0 @x0) '
Broadcast
= 0.0.0.0 ч
= 10.0.0.76 :"v'
= 0.0.0.0
= 0.0.0.0
= 00104BEC8DB2
<Blank>
<Blank>
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
i4aur.'
DHCP Offer
255.0.0.0
1 Day, 12:00:00
2 Days, 15:00:00
00:00
Client Ethernet Address (chaddr)
Server Host Name (sname) =
Boot File Name (file)
Magic Cookie = [OK]
Option Field (options)
DHCP: DHCP Message Type
Subnet Mask =
Renewal Time Value (Tl) =
Rebinding Time Value (T2) =
IP Address Lease Time
Server Identifier
Router
Domain Name Server
NetBIOS Name Service
NetBIOS Node Type
End of option field
Если все вышеприведенное выглядит хорошо на клиентской машине, то
она посылает сообщение запроса DHCP, как показано в распечатке ниже.
Здесь опущен заголовок Ethernet, заголовок IP и заголовок UDP, так как
они выглядят аналогично. Кое-что интересное можно увидеть в нижней
части кадра запроса DHCP, где присутствуют поля запрошенного адреса и
имени хоста, заполненные на клиентской машине.
3 Days,
10.0.0.
10.0.0.
10.0.0.
10.0.0.
о
11
15
10
10
= (Length: 1) 08

Клиентский трафик
139
DHCP: Request (xid = 05D105D1)
DHCP: Op Code (op) = 1 (Oxl)
DHCP: Hardware Type (htype) = 1 @x1) 10 Mb
Ethernet
DHCP: Hardware Address Length (hlen) = 6 @x6)
.. ; DHCP
¦'¦• VJb'-- DHCP
@x5D105Dl)
DHCP: Seconds
DHCP: Flags
Hops
Transaction ID
(hops)
(xid)
(sees)
(flags)
0 @x0)
97584593
0 @x0)
0 @x0)
DHCP: 0 = No Broadcast
. , DHCP: Client IP Address
; DHCP: Your IP Address
' ' " DHCP: Server IP Address
DHCP: Relay IP Address
DHCP: Client Ethernet Address
DHCP: Server Host Name
Boot File Name
Magic Cookie = [OK]
Option Field (options)
DHCP: DHCP Message Type
Client-Identifier
DHCP:
DHCP:
DHCP:
(ciaddr)
(yiaddr)
(siaddr)
(giaddr)
(chaddr)
(sname)
(file)
DHCP:
8d b2
DHCP: Requested Address . ,.,...
DHCP: Server Identifier
DHCP: Host Name
DHCP: Parameter Request List
Of 2c 2e 2f 39
DHCP: End of this option field
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
00104BEC8DB2
<Blank>
<Blank>
DHCP Request
(Type: 1) 00 10 4b ec
10.0.0.76
10.0.0.11
kenny
(Length: 8) 01 03 06
Теперь мы переходим к конечному кадру в этом общении, который явля-
является кадром подтверждения DHCP ACK, посылаемым сервером. Здесь так-
также опущены все заголовки, кроме части DHCP кадра. Можно видеть, что
этот кадр выглядит очень похоже на предложение DHCP, предложенное
сервером DHCP во втором кадре. Мы видим, что клиенту на самом деле раз-
разрешено использовать запрошенный машиной IP-адрес, и что все парамет-
параметры остались такими же. Здесь снова всем машинам в подсети посылается
широковещательное сообщение. Получив пакет, клиентская машина начнет
использовать этот адрес. .- '-i1 , ' ¦¦:¦¦¦
DHCP: ACK
(xid = 05D105D1)
(op) = 2 @x2)
(htype) = 1 @x1) 10 Mb
DHCP: Op Code
DHCP: Hardware Type
Ethernet
DHCP: Hardware Address Length (hlen) = 6 @x6)
¦ г.... DHCP: Hops (hops) = 0 @x0)
Transaction ID (xid) = 97584593
DHCP:
@x5D105Dl)
DHCP: Seconds
(sees) = 0 @x0)

140
Глава 5
DHCP: Flags
DHCP: 0.
DHCP: Client
Your
Server
Relay
Client
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
IP Address
IP Address
IP Address
IP Address
(flags) = 0 @x0)
. = No Broadcast
(ciaddr) = 0.0.0.0
(yiaddr) = 0.0.0.76
(siaddr) = 0.0.0.0
(giaddr) = 0.0.0.0
Ethernet Address (chaddr) = 00104BEC8DB2
Server Host Name (sname) = <Blank> . .
Boot File Name (file) = <Blank>
Magic Cookie = [OK] ' ,j...;or, ¦:
Option Field (options)
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP Message Type = DHCP ACK
Renewal Time Value (Tl) 1 Days, 12:00:00
Rebinding Time Value (T2) =2 Days, 15:00:00
= 3 Days,
0:00:00
10.0.0.11
255.0.0.0 -~- -
10.0.0.15 •".
10.0.0.10
10.0.0.10
(Length: 1)
08
IP Address Lease Time
Server Identifier
Subnet Mask
Router
Domain Name Server
NetBIOS Name Service
NetBIOS Node Type
End of this option field
Обновление выделенного адреса DHCP Выделенный IP-адрес дол-
должен обновляться до истечения срока своей службы. Как можно видеть в
распечатке выше, когда выделенный адрес подтверждается, одновременно
задается время обновления. Процесс обновления требует только двух кад-
кадров: запроса DHCP и последующего АСК.
Клиент DHCP будет запрашивать обновление дважды — при запуске и
при истечение половины выделенного времени. В каждом из этих случаев,
если запрос успешен, он будет использовать только два кадра. Эти два кад-
кадра выглядят точно так же, как кадры запроса и подтверждения, показанные
в предыдущем разделе. Единственное различие состоит в том, что при за-
запросе во время истечения половины выделенного времени это будет на-
направленная дейтаграмма, а не широковещательное сообщение, как в случае
обновления при запуске.
Эти два кадра имеют размер всего 684 байта и требуют только 100 мил-
миллисекунд для завершения. Если клиентской машине DHCP не удалось полу-
получить обновление после двух попыток, она будет ждать до следующего
периода обновления. Если срок выделенного адреса истекает, то машина
возвращается к описанному ранее процессу из четырех кадров, как если бы
она пыталась получить адрес в первый раз.
Оптимизация трафика DHCP В действительности трафик DHCP
имеет минимальное влияние на объем создаваемого сетевого трафика. Су-
Существуют только шесть случаев, когда трафик будет присутствовать вооб-
вообще. Они перечислены ниже:
• Клиенту DHCP требуется адрес в первый раз — четыре кадра.
• Автоматическое обновление при истечении половины выделенного
времени — два кадра.

Клиентский трафик
141
• Перезапуск клиентской машины DHCP — два кадра. .
• Машина перемещается в новую подсеть. Это будет создавать два кадра
обновления, которые получат отрицательное подтверждение, затем
четыре кадра для получения адреса — всего шесть кадров.
• Замена NIC на машине — четыре кадра. „• ¦»¦,... ^ . f.t.
• Адрес IP освобождается или обновляется вручную, с помощью либо
ipconfig, либо winipcfg.
Одним из основных способов сокращения объема трафика DHCP явля-
является настройка длительности времени выделения. Это делается менедже-
менеджером DHCP, как показано на рис. 5.1. Если длительность выделения адреса
изменяется с используемых по умолчанию трех дней до тридцати дней, то
сокращение трафика может быть существенным — 13684 байта на каждую
машину. Такое изменение имеет смысл, когда область адресов значительно
больше, чем число хостов, которые необходимо адресовать. Если это не так,
то придется либо использовать длительность выделения по умолчанию,
либо сделать длительность еще короче. Другой сценарий при настройке дли-
длительности выделения номера может возникать в ситуации, когда существует
Frsie
3
4
•1
I*
'11
Ti»
it
1*
e
167
211
Src ИАС
КИШУ
TESESA
fceim
|sie
Addr
t4t НАС Addr
• BROADCAST
•BROADCAST
||У|в|:
Protocol
08CP
DHCP
MJ»|hJ[?J
Request
ACK
(s
О
id
id
•aSDlOSDI)
-05D105D1)
айзмаи
00 iO 08
TERESA
Al D4
It'M
i25S
Otbnr Jlddr
255 255
255 255
25S
255
Type
IP
IP
Othej
ODP Data Ku»fae:
-и»:.:
DHCP Op Code
DHCP Hardware Tjrpe
ot data bytes rexai
BHffl
e)
DHCP Hardware Addrese length (Ы.
1 @x1)
1 @«l) 10«b Ethernet
ea) • i @»6)
0 @0)
DHCP Hope (bops) - 0 (OkO)
DHCP Transaction ID Isid) ¦ 97S94593 (OsSDIOSDt)
DHCP Seconds - - -.
-ПЯСР Flaas
DHCP 0
DHCP Client IP Address (ctadd:
DHCP Tour IP Addicts (ymiil
DHCP Server IP Address (sieddrl
DHCP Belay IP Address (giaddr) ....
DHCP Client Ethernet Address (cbsddr) • 00104BECtDB2
DHCP Server Host Hue <sns*e
DHCP Boot File Haae Ifile)
DHCP Hajic Cookie - [OJC)
•DHCP Optior. Field (optu
DKCP DHCP Henaje Type
DHCP Ciiect-identiiier
DHCP Requested Address
. DECP Sost Ka«5
»> -0 @>0)
. . 0 @«0)
Ho Bro»dca.i
lll.l
oo o.o
0 0 0 0
0 0 0 0
- DHCP Discover
- <Tvpe. 1) 00 10 tb ec
• 10.0 0 '•
¦ kenr.v
00000000
ooooooio
00000020
00000030
00000040
30000050
OOOOOOiO
00000070
QOOOOOeo
00000030
0000OOAO
3UG0O0B0
JO0Q0OC0
0O00OODO
0O0O0OEO
000000F0
00000100
»0 00 00 Ofi Oil
DO 00 00 00 П0
1H 00 DO 00 00
00 00 00 00 00
>H 00 CO 00 00
00 GO 00 00 00
ДО 00 00 0U 00
jo oo со ас oo
00 00 \jQ 00 00
Ю 00 00 00 00
¦1С 00 00 00 00
00 00 10 4? ТУ.
00 00 00 CO ЛП
00 00 00 CO 00
00 1.0 00 Г0 (fO
00 00 П0 CO 0ft
Oft 00 00 CO Ofl
0<) 00 00 CJt П0
00 00 00 CO 00 i
0U 00 00 CO 00 i
00 00 00 CO 00 i
00 00 00 CO 00 i
oo oo ou со до -
00 30 00 CO 00 i
: oq oo m oo
i 00 00 00 00
I 00 00 CO 00 <
i oo oo o<> oo ;
I 00 00 00 00
I 00 00 0П CO
I 00 00 00 00
i 00 00 00 CO '
i 00 00 OU 00
| 00 00 00 00
1 00 00 00 00
i 00 00 00 00
1 00 00 00 00
Рис. 5.1. Трафик DHCP можно сократить, настраивая используемую по умолчанию
длительность выделения адреса

142 - Глава 5
большое количество переносных компьютеров, которые соединяются
с сетью на регулярной основе. Если пользователи не обучены освобождать
свои IP-адреса при выходе из сети, они могут получать несколько адресов,
требуя тем самым большего пространства адресов, чем необходимо.
Трафик клиента WINS * ¦• .
Получив подходящий IP-адрес, клиентский компьютер должен зарегистри-
зарегистрировать в сети свое имя NetBIOS. В большинстве ситуаций эта регистрация
будет вовлекать WINS. Большинство ресурсов, доступных в сети, включает
некоторый вид компьютерного имени. Компьютеры в сети должны регист-
регистрировать по крайней мере одно имя. Как правило они будут регистриро-
регистрировать более одного имени, чтобы обеспечить в сети коммуникацию по
имени. В мире Windows NT имя хоста и имя NetBIOS обычно совпадают
(они не являются одним и тем же по сути, но обозначаются одним и тем же
словом или комбинацией символов). В мире Unix имя хоста и имя NetBIOS
могут быть различаться.
В главе 1 говорилось, что NetBIOS (сетевая базовая система ввода-выво-
ввода-вывода) не то же самое, что NetBEUI. NetBIOS является протоколом, используе-
используемым различными приложениями. Он может переноситься через TCP/IP,
IPX/SPX и, конечно, NetBEUI. Мы рассмотрим NetBIOS, потому что она
используется через TCP/IP.
Чтобы приложения могли общаться, имя NetBIOS должно быть преоб-
преобразовано в адрес IP. Способ, которым это обычно делается, состоит в испо-
использовании либо широковещания b-узлов, либо сервера имен NetBIOS,
например WINS. Есть несколько преимуществ использования сервера
WINS, а не просто широковещания. Первое состоит в том, что широкове-
широковещание является очень дорогим предложением, когда речь идет о сетевой
производительности. Каждое одиночное устройство в сегменте должно
остановить и проверить каждый одиночный кадр широковещания, чтобы
определить, не может ли он обслужить запрос. В большой сети широкове-
широковещание NetBIOS может буквально заполнить всю сеть. С этим надо как-то бо-
бороться. К счастью, компания Microsoft разработала для этой цели WINS.
WINS полностью соответствует реализации сервера имен NetBIOS на
основе RFC. С помощью WINS хосты могут отбрасывать кадр, как только
они видят адрес MAC места назначения. Все функции службы имен NetBIOS
через TCP/IP используют UDP порт 137. Рассмотрим регистрацию имен
и процесс обновления.
Регистрация имен и обновление
Имена NetBIOS должны быть зарегистрированы для каждой службы или
приложения, которые хотят использовать их коммуникационный меха-
механизм. Примерами таких регистрируемых служб являются служба рабочей
станции и служба сервера. Другие имена указывают специальные роли, ко-
которые выполняются в сети, такие как основной, или первичный, контрол-
контроллер домена (Primary Domain Controller, PDC) или резервный контроллер
домена (Backup Domain Controller, BDC). Регистрируется само имя домена,
а также имена пользователей, регистрирующихся в домене. Эти имена

Клиентский трафик 143
нужны для некоторых функций сообщений и коммуникации. Например,
если необходимо послать сообщение, используя сетевую команду send (по-
(послать) некому Джейсону, он должен иметь зарегистрированное имя пользо-
пользователя, иначе ничего не получится. Общее число зарегистрированных
имен зависит, очевидно, от числа запущенных служб. Каждое зарегистри-
зарегистрированное имя будет использовать всего 214 байтов — ПО байтов для запро-
запроса регистрации имени и 104 байта для ответа. Посмотрим теперь на такую
транзакцию на листинге ниже:
+ FRAME: Base frame properties
ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ ETHERNET: Destination address : 00805FA63A32
+ ETHERNET: Source address : 00609788CF96
ETHERNET: Frame length : 110 (ОхООбЕ) " '-: '
ETHERNET: Ethernet Type : 0x0800 (IP: DOD Internet Protocol)
ETHERNET: Ethernet Data: Number of data bytes remaining = 96
@x0060)
+ IP: ID = 0x1501; Proto = UDP; Len: 96
UDP: Src Port: NETBIOS Name Service, A37); Dst Port: NETBIOS
Name Service A37); Length = 76 @x4C)
UDP: Source Port = NETBIOS Name Service ;rT'' ' «»'> ¦ ¦ ¦ ¦ ¦
UDP: Destination Port = NETBIOS Name Service .. .. ; ,;-м1ч<'--
UDP: Total length =76 @x4C) bytes
UDP: UDP Checksum = 0x3D0F
UDP: Data: Number of data bytes remaining = 68 @x0044)
В приведенном выше листинге можно видеть, что размер кадра равен
ПО байтам. Порт места назначения является UDP портом 137 службы имен
NetBIOS. Эта информация свидетельствует, что это, возможно, кадр запроса.
Обратимся к следующему разделу.
.)¦ »: «,.;¦-.-' ;.М|- ¦¦ >' '¦¦> ' ¦ ¦"
NBT: NS: Registration req. for ED <03>
NT: Transaction ID = 32894 @x807E) С ч'т; ;.. П».;— ?..>.; tU"•'¦Г-Ж :
NBT: FlagBs Summary = 0x2900 - Req.; Registration; Success
NBT: 0 = Request
NBT: . 0101 = Registration -:
NBT: 0 = Non-authoritative Answer
NBT: 0 = Datagram not truncated
NBT: 1 = Recursion desired
NBT: 0 = Recursion not available
NBT: 0 = Reserved
NBT: 0 = Reserved
NBT: 0.... = Not a broadcast packet
NBT: 0000 = Success
NBT: Question Count = 1 @x1)
NBT: Answer Count = 0 @x0)
NBT: Name Service Count = 0 @x0) :
NBT: Additional Record Count = 1 @x1)
NBT: Question Name = ED <03>
NBT: Question Type = General Name Service
NBT: Question Class = Internet Class .
NBT: Resource Record Name = ED <03>

144 Глава 5
NBT: Resource Record Type = NetBIOS General Name Service
NBT: Resource Record Class = Internet Class
NBT: Time To Live = 300000 @x493E0)
'' NBT: RDATA Length = 6 @x6) • . ¦ .... . ,¦,
NBT: Resource Record Flags = 24576 @x6000)
•'¦'¦ NBT: 0 = Unique NetBIOS Name
' :' •'"' NBT: .11 = Reserved -'*
: .. NBT: ...0000000000000 = Reserved . ••;
NBT: Owner IP Address = 11.0.0.190
В некоторых, отношениях пакет службы имен NetBIOS выглядит как
структура типа QNS. В распечатке выше заголовок состоит из идентифика-
идентификатора транзакции; раздела флагов, счетчика ответов, счетчика службы имен
и счетчика дополнительных записей. Каждый из этих пунктов рассмотрен
ниже. .&¦?.¦¦¦.. .
-,,^ ¦ -. - ¦•¦. 1.- ¦¦ _ • -
Идентификатор транзакции Поле идентификатора транзакции ис-
использует 16 битов B байта) для отслеживания сообщений. Инициатор со-
сообщения выбирает уникальный номер для каждой активной транзакции.
Машина, которая отвечает на сообщение, будет использовать тот же самый
идентификатор транзакции.
Флаги Поле флагов также использует 16 битов. Они представлены в
распечатке выше. Список ниже объясняет, что эти флаги означают.
• Запрос/ответ (Request/response). Запрос/ответ является однобито-
однобитовым флагом. Он устанавливается в ", чтобы указать запрос, или в ",
чтобы указать ответ. • «•••- ¦- ¦¦¦¦ ¦ ¦¦• *
• Код операции (Opcode). Флаг кода операции использует четыре бита,
чтобы указать определенную операцию NetBIOS. Коды операций,
обычно встречающиеся в этом флаге, перечислены в таблице 5.3.
Таблица 5.3. Флаги кодов операций NetBIOS
Шестнадцатеричный Значение
код операции
0x0 ¦, Запрос имени
0x5 , Регистрация имени
0x6 Освобождение имени
0x7 . WACK (wait for acknowledgment — ждать
подтверждения). Посылается, когда WINS слишком
занят, чтобы ответить. Но по крайней мере позволяет
посылающей машине знать, что пакет был получен
(тем самым предотвращая повторную передачу).
0x8 Обновить имя
F Регистрация группового имени

Клиентский трафик 145
NBT: Flags Summary = 0xAD80-Resp.; Registration; Success
NBT: 1 = Response
. . NBT: .0101 = Registration ' '
•¦¦¦•'•• ¦• nbT: 1 = Authoritative Answer
NBT: 0 = Datagram not truncated
.. NBT: 1 = Recursion desired
, ,. . NBT: 1 = Recursion available
NBT: 0 = Reserved
NBT: 0 = Reserved
NBT: 0.... = Not a broadcast packet
NBT: 0000 = Success
• Официальный ответ (Authoritative answer). Этот флаг использует
один бит и устанавливается в 1, если отвечающая машина является
уполномоченной для этого домена. Он всегда сбрасывается в 0 в запросе.
В распечатке выше показана часть пакета ответа, и флаг установлен в 1.
• Обрезание (Truncation). Этот однобитовый флаг устанавливается в 1,
если сообщение должно быть сделано короче, в связи с размером
пакета.
• Желательна рекурсия (Recursion desired). Флаг желательности рекур-
рекурсии задается как 1, если клиентская машина хочет, чтобы WINS повто-
повторял на основе запроса, регистрации или выпуска. WINS будет также
устанавливать этот флаг в пакете ответа.
• Рекурсия доступна (Recursion available). Этот однобитовый флаг
устанавливается в 1 только в ответах WINS, чтобы указать, что он
поддерживает рекурсивный запрос, регистрацию и выпуск.
• Широковещание (Broadcast). Еще один однобитовый флаг задаваемый
как 1, если пакет передается в режиме широковещания или мульти-
вещания. Он задается как 0, если пакет передается однонаправленно.
Пакет в распечатке выше не был отправлен в режиме широковещания.
• Возвращаемый код (Return code). Это последний флаг с четырьмя вы-
выделенными для его использования битами. Возвращаемый код равен
0x0 для всех запросов, и он также равен 0x0 для положительного ответа.
Другие значения указывают на ошибочные условия.
Счетчик запросов Для использования счетчика запросов выделено
16 битов. Счетчик запросов всегда равен 0 для ответов. Для правильно
сформатированного запроса, однако, это поле должно иметь число, как 0x1
в предыдущей распечатке. В распечатке ниже приведен пакет ответа, и
счетчик запросов сброшен в 0x0.
NBT: Question Count = 0 @x0)
NBT: Answer Count = 1 @x1)
NBT: Name Service Count = 0 @x0) . ...

146 ' Глава 5
Счетчик ответов Разделу счетчика ответов выделено 16 битов, он ис-
используется для указания числа записей ресурса, содержащихся в разделе от-
ответа пакета. Ответ, приведенный выше, имеет только одну запись в разделе
ответа.
Счетчик службы имен Раздел счетчика службы имен также имеет 16 би-
битов и указывает число записей ресурсов, содержащихся в разделе полномочий
пакета. .
NBT: Additional Record Count = 0 @x0)
Счетчик дополнительных записей Поле счетчика дополнительных
записей является последним полем в заголовке службы имен и также испо-
использует 16 битов. Используется дополнительный счетчик записей для указа-
указания числа записей ресурсов в разделе пакета дополнительных записей
ресурсов. В распечатке выше нет дополнительных записей.
После информации заголовка мы переходим к записи запроса. Этот раз-
раздел состоит из трех полей. Первое поле — имя запроса, которое является
именем ресурса NetBIOS. Для имени NetBIOS без идентификатора области
действия это поле имеет в длину 34 бита. Второе поле является типом за-
запроса. Он задается как 0x00-20 для указания, что это имя NetBIOS. Третье
поле является классом запроса, который задается как 0x00-01, указывая,
что это класс запроса Интернета (IN). Эти числа не показаны в разделе ана-
анализа сетевого монитора, они приведены в шестнадцатеричном виде ниже.
NBT: Question Name = SERVERPDC <00>
NBT: Question Type = General Name Service
NBT: Question Class = Internet Class
00000: 00 08 C7 33 F3 E2 08 00 02 IB 35 B0 08 00 45 00
...3 5...E.
00010: 00 4E 04 06 00 00 IE 11 IF 1С 0A 03 01 02 0A 01
.N
00020: 64 78 00 89 00 89 00 ЗА 30 AD 00 D2 01 00 00 01
dx :0
00030: 00 00 00 00 00 00 20 46 44 45 46 46 43 46 47 45
FDEFFCFGE
00040: 46 46 43 46 41 45 45 45 44 43 41 43 41 43 41 43
FFCFAEEEDCACACA
00050: 41 43 41 43 41 41 41 00 00 20 00 01
ACACAAA....
Имя записи ресурса Это следующее поле пакета NetBIOS.
NBT: Resource Record Name = ORCO <1D>
NBT: Resource Record Type = NetBIOS General Name Service
NBT: Resource Record Class = Internet Class
Тип записи ресурса Следующее поле является типом записи. Как видно
в распечатке выше, это имя NetBIOS. Оно показано как 0x00-20 в шестнад-
цатеричной трассировке.

Клиентский трафик 147
Класс записи ресурса Класс записи ресурса задается как 0x00-01, что
указывает на класс имени Интернета (IN).
NBT: Time To Live = 518400 @х7Е900)
Время жизни Поле времени жизни является 32-битным полем, кото-
которое используется для указания времени существования имени. В пакете ре-
регистрации имени, обновления или запросе выпуска эта величина не имеет
значения. Это поле задается как 0х04-93-Е0 C00000 секунд).
Длина RDATA Это поле содержит 16 битов и используется для указа-
указания числа байтов данных ресурса для этой записи. Оно задается как
0x00-06, как показано ниже.
NBT: RDATE Length = б @x6) ' ¦
Флаги записей ресурсов Для двух специальных флагов записей ре-
ресурсов выделено 16 битов. Старший бит используется для определения, яв-
является ли регистрируемое, восстанавливаемое или обновляемое имя
уникальным именем NetBIOS, или это групповое имя NetBIOS. Если этот
флаг задан как 1, то это групповое имя. Если флаг задан как 0, то это уника-
уникальное имя NetBIOS. В распечатке ниже зарегистрировано групповое имя.
Следующие два бита указывают тип узла владельца. Он задается как 00 для
В-узла, 01 для Р-узла, 10 для М-узла и 11 для Н-узла. Как можно видеть ниже,
мы имеем владельца Н-узла.
NBT: Resource Record Name = ORCO <1D>
NBT: Resource Record Type = NetBIOS General Name Service
NBT: Resource Record Class = Internet Class
NBT: Time To Live = 518400 @x7E900)
NBT: RDATA Length = 6 @x6) >:
NBT: Resource Record Flags = 24576 @x6000)
NBT: 0 = Unique NetBIOS Name
NBT: .11 = Reserved
NBT: ...0000000000000 = Reserved
NBT: Owner IP Address = 192.168.2.2
IP-адрес владельца Последнее поле является IP-адресом владельца,
которое соответствует регистрируемому, восстанавливаемому или осво-
освобождаемому имени. В данном случае это машина 192.168.2.2.
Трафик регистрации в системе
После того как клиентский компьютер был включен и получил IP-адрес,
следующий шаг состоит в регистрации в домене. Это происходит, когда
пользователь вводит имя пользователя и пароль и затем нажимает ОК. Конт-
Контроллер домена (либо первичный, либо один из резервных) будет проверять
запрос.
Клиентская машина должна найти сервер регистрации, инициировать
переговоры для аутентификации пользователя и осуществить другие вещи,
такие как выполнение регистрационных сценариев, копирование профилей
и т.п. Как можно видеть в таблице 5.4, во время процесса регистрации
создается значительный объем трафика.

148
Глава 5
Таблица 5.4. Трафик регистрации
Шаг
Тип трафика
Объем трафика
Найти сервер регистрации Широковещание
или WINS
Подготовка сеанса
Проверка
Прекращение сеанса
,... TCP.NBT.SMB
SMB
SMB
i Общее число кадров
Общее число байтов
4+кадра ,.
700+ байтов
11 кадров
1280 байтов для win95
1370 байта для winnt
4-20 кадров
765-3725 байтов
5 кадров 360 байтов
24+ кадров ,
3105+ байтов
Поиск сервера регистрации
Прежде чем клиентская машина сможет зарегистрироваться в домене, пер-
первый шаг состоит в поиске сервера регистрации. Обычно используются два
способа: просто послать широковещательный запрос в почтовый ящик ре-
регистрации в сети или запросить у WINS список контроллеров доменов, ко-
которые зарегистрировались в службе разрешения имен. Второй метод
является прямым запросом, если клиент имеет используемый по умолча-
умолчанию тип разрешения имени Н-узла. Рассмотрим каждый из этих методов
более подробно.
Широковещательный метод
ETHERNET: ETYPE = 0x0800
Protocol = IP: DOD Internet Protocol
+ ETHERNET:
+ ETHERNET:
ETHERNET:
ETHERNET:
ETHERNET:
@x00F6)
Destination address : FFFFFFFFFFFF
Source address : 00104BEC8DB2
Frame Length: 260 @x0104)
Ethernet Type : 0x0800 (IP: DOD Internet Protocol)
Ethernet Data: Number of data bytes remaining = 246
Широковещательный кадр адресуется в FFFFFFFFFFFF, имеет длину
260 байтов (включая 14 байтов заголовка Ethernet) и использует тип
0x0800, который соответствует IP.
Затем мы видим адрес источника A0.0.0.76) и адрес назначения,
равный 10.255.255.255, который является адресом широковещания для
сети 10. В качестве транспортного протокола используется UDP. В разделе
UDP мы видим, что оба порта, источника и места назначения, заданы как
138, это соответствует службе дейтаграмм NetBIOS.
IP: ID = 0x2800; Proto = UDP; Len: 246 ...
IP: Version = 4 @x4)
IP: Header Length = 20 @x14)
+ IP: Service Type = 0 @x0)

Клиентский трафик 149
IP: Total Length = 246 @xF6)
IP: Identification = 10240 @x2800)
+ IP: Flags Summary = 0 @x0)
IP: Fragment Offset = 0 @x0) bytes
IP: Time to Live = 128 @x80)
IP: Protocol = UDP — User Datagram
IP: Checksum = OxFCAC
IP: Source Address =10.0.0.76
IP: Destination Address = 10.255.255.255
IP: Data: Number of data bytes remaining = 226
(OxOOE2)
UDP: Src Port: NETBIOS Datagram Service, A38); Dst Port:
NETBIOS Datagram Service A38); Length = 226 @xE2)
UDP: Source Port = NETBIOS Datagram Service
UDP: Destination Port = NETBIOS Datagram Service
UDP: Total length 226 @xE2) bytes
UDP: UDP Checksum = 0x17 02
UDP: Data: Number of data bytes remaining = 218
(OxOODA) ' ¦
Рассмотрим следующий раздел NetBIOS. На распечатке ниже эта дейтаг-
дейтаграмма направляется группе. Здесь снова перечислены IP-адрес источника и
порт UDP. В этот раз, однако, мы видим, что используется имя NetBIOS ма-
машины. Эта машина называется KENNY, а имя места назначения NETMON —
это желательный домен регистрации. Важно отметить, что оба эти имени
NetBIOS имеют связанный с ними тип <00>. Это означает, что они являются
уникальными именами.
NBT: DS: Туре = 17 (DIRECT GROUP)
NBT: Datagram Packet Type = DIRECT GROUP
+ NBT: Datagram Flags = 2 @x2) . . ¦ ,
NBT: Datagram ID = 20 @x14) ¦ .
NBT: Source IP Address = 10.0.0.76
NBT: Source Port = 138 @x8A) :
NBT: Datagram Length = 204 (OxCC) ...
NBT: Packet Offset = 0 @x0) ;-.
NBT: Source Name = KENNY <00>
NBT: Destination Name = NETMON <00>
NBT: DS Data: Number of data bytes remaining =13 6
@x0088)
Перейдем к разделу SMB кадра. Самое важное в этом разделе, что он ис-
использует SMB С Transact. Заголовок не раскрыт в этом представлении, но
он имеет TID, PID, UID и MID, которые можно было бы ожидать для любой
коммуникации SMB. Так как это достаточно длинная распечатка, были вы-
выделены наиболее важные разделы. Отметим, что это запись в почтовый
ящик с помощью ненадежного класса. Он хочет использовать имя файла
\mailslot\net\netlogon.
SMB: С transact, File = \MAILSLOT\NET\NETLOGON
+ SMB: SMB Status = Error Success ¦ ••!

150 Глава 5
+ SMB: Header: PID = 0xl52F TID = OxFFFF MID = 0x0081
UID = OxFFFF
SMB: Command = С transact -. ; -. , ,.
SMB: Word count = 17 •, -• ¦
SMB: Word parameters , > .,;;
SMB: Total parm bytes =0
SMB: Total data bytes = 44
SMB: Max parm bytes =0 - ;
SMB: Max data bytes =0
SMB: Max setup words = 0 @x0)
+ SMB: Transact Flags Summary = 2 @x2)
SMB: Transact timeout = 0 @x0)
SMB: Parameter bytes = 0 @x0)
SMB: Parameter offset = 92 @x5C)
SMB: Data bytes = 44 @x2c)
SMB: Data offset = 92 @x5c)
SMB: Max setup words = 3 > ••i.;
SMB: Setup words
SMB: Mailslot opcode = Write mailslot
SMB: Transaction priority = 0
1 ,.' ': SMB: Mailslot class = Unreliable (broadcast)
'• " ¦•¦* -'< SMB: Byte count = 67 . ...
¦ ¦"'¦'¦<'¦.'-¦¦¦ SMB: Byte parameters ¦ "'.,..
• ' ;.•!'•' ¦ SMB: File name = \MAILSLOT\NET\NETLOGON и _,иш
--, , SMB: Transaction data , , ,¦
SMB: Number of data bytes remaining = 44 (Ox002C) ;,
Теперь мы переходим к разделу трассировки регистрации в сети (netlo-
gon). Здесь мы видим запрос от пользователя MGROCE на машине KENNY.
Кадр указывает, что он может использовать тип регистрации LM1.0 или
LM2.0. Отметим также, что счетчик запросов равен 1, т.е. клиент пытается
зарегистрироваться в этом сеансе впервые.
NETLOGON: LM1.0/2.0 LOGON Request from client
NETLOGON: Opcode = LM1.0/2.0 LOGON Request from client
NETLOGON: Computer Name = KENNY
NETLOGON: User Name = MGROCE
NETLOGON: Mailslot Name = \MAILSLOT\TEMP\NETLOGON
NETLOGON: Request Count = 1 @x1)
NETLOGON: LM20 Token = OS/2 LAN Manager 2.0 (or later)
Networking
Интересным моментом в этой конкретной трассировке является то, что
сразу за ней следует ARP_RARP от Teresa (контроллера домена). Предполо-
Предположим, что можно извлечь адрес MAC из только что рассмотренного кадра.
Эта информация там присутствовала. Это действительно так. Когда ма-
машина Kenny отвечает на ARP Teresa, мы получаем кадр ответа netlogon, кото-
который очень похож на предыдущий кадр, рассмотренный достаточно подроб-
подробно. Существенная часть, однако, находится ниже. В этом разделе мы видим,
что код команды является ответом (response) на запрос LOGON, а имя сер-
сервера регистрации \\teresa. Контроллер домена teresa будет принимать тип
регистрации LM2.0.

Клиентский трафик 151
NETLOGON LM2.0 Response to LOGON Request
NETLOGON: Opcode = LM2.0 Response to LOGON Request
NETLOGON: Logon Server Name = \\TERESA
NETLOGON: LM20 Token = OS/2 LAN Manager 2.0 (or later) Networking
Использование WINS Клиент Н-узла будет использовать WINS при
поиске контроллера домена для обслуживания запроса регистрации. Это
стандартный запрос WINS из 92 байтов, направленный в порт UDP 137.
Как можно видеть в распечатке ниже, запрос NBT (имя запроса) предназна-
предназначен для <1С>, что технически означает запрос WINS для первых 25 конт-
контроллеров доменов, которые имеют зарегистрированное имя домена.
Локально зарегистрированные контроллеры доменов получают приоритет
в ответном сообщении. Первая запись в ответе всегда будет PDC. В рас-
распечатке ниже отметим, что официальных ответов 0, счетчик запросов равен 1,
а счетчик ответов равен 0. Это говорит нам, что это пакет запроса.
NBT: NS: Query req for NETMON <1C>
NBT: Transaction ID = 32774 @x8006)
NBT: Flags Summary = 0x0110 - Req.; Query; Success
NBT: 0 = Request ..
NBT: .0000 = Query
NBT: 0 = Non-authoritative Answer
NBT: 0 = Datagram not truncated
NBT: 1 = Recursion desired •
• NBT: 0 = Recursion not available
NBT: 0 .' = Reserved
'. . NBT: 0 = Reserved
NBT: 1.... = Broadcast pasket
NBT: 0000 = Success
NBT: Question Count = 1 @x1)
NBT: Answer Count = 0 @x0) -!l ' ' :
NBT: Name Service Count = 0 @x0) " ' ¦ '¦
NBT: Additional Record Count = 0 @x0) ' :¦
NBT: Question Name = NETMON <1C> ¦ •'
NBT: Question Type = General Name Service
NBT: Question Class = Internet Class
Возвращаемый ответ утверждает, что это официальный ответ. Отме-
Отметим, что счетчик запросов в этот раз равен 0, а счетчик ответов равен 1.
Когда сервер регистрации идентифицирован, описанный выше процесс
продолжается, посылая широковещательное сообщение в почтовый ящик
регистрации в сети на сервере регистрации. Он должен получить ответ от
сервера регистрации, сообщающий тип поддерживаемой регистрации.
NBT: NS: Query (Node Status) resp. for NETMON <1C>,
Success
NBT: Transaction ID = 32774 @x8006)
NBT: Flags Summary = 0x8500 - Resp.; Query; Success
NBT: 1 = Response
NBT: .0000 = Query
NBT: 1 = Authoritative Answer

152 Глава 5
NBT: О = Datagram not truncated
NBT: 1 = Recursion desired
NBT: 0 = Recursion not available
NBT: 0 = Reserved
NBT: 0 = Reserved
' NBT: 0.... = Not a broadcast packet
NBT: 0000 = Success
: NBT: Question Count = 0 @x0) . ...
NBT: Answer Count = 1 @x1)
NBT: Name Service Count = 0 @x0)
NBT: Additional Record Count = 0 @x0)
NBT: Resource Record Name = NETMON <1C>
NBT: Resource Record Type = NetBIOS General Name
Service
NBT: Resource Record Class = Internet Class
NBT: Time To Live = 300000 @x493E0)
NBT: RDATA Length = 6 @x6)
+ NBT: Resource Record Flags = 32768 @x8000)
NBT: Owner IP Address = 10.0.0.11
Создание сеанса и проверка регистрации После того как сервер ре-
регистрации был найден и на запрос регистрации послан ответ, следующий
шаг состоит в создании сеанса.
Создание сеанса TCP Первый шаг в создании сеанса состоит в вы-
выполнении трехходового квитирования. Этот процесс требует трех кадров и
180 байтов. В первом кадре ниже мы видим S, который является флагом син-
синхронизации, и диапазон последовательности 45091 — 45098. Обратите вни-
внимание, что местом назначения является порт 139, т.е. порт сеанса NBT.
Следующий кадр поступает с сервера Teresa; в этом кадре заданы оба флага А
и S. Флаг А подтверждает предыдущий кадр машины Кеппу. Флаг S, флаг син-
синхронизации номера машины Teresa, предлагает диапазон 7972459 — 7972462.
Отметим здесь, что порт источника будет 139, а порт назначения — 1025, ко-
который был портом источника предыдущего кадра с машины Кеппу. Важно
также отметить, что номер подтверждения АСК 45092 находится в диапазо-
диапазоне последовательности с машины Кеппу. Последняя часть трехходового
квитирования состоит в подтверждении машиной Кеппу предыдущего кад-
кадра с машины Teresa. Отметим еще раз, что порт назначения 139, и подтвер-
подтверждение находится в диапазоне машины Teresa. В данном случае АСК
(подтверждение) является номером последовательности 792460.
FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet
Protocol
+ IP: ID: = 0x3100; Proto = TCP; Len: 48
+ TCP: S., len: 8, seq: 45091-45098, ack:
0, win: 8192, src: 1025 dst: 139 (NBT Session)
+ FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet
Protocol
+ IP: ID = ОхВЮб; Proto = TCP; Len: 44

Клиентский трафик 153
+ TCP: .A..S., len: 4, seq: 7972459-7972462, ack:
45092, win: 8760, src: 139 (NBT Session) dst: 1025
+ FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet
Protocol
+ IP: ID = 0x3200; Proto = TCP; Len: 40
+ TCP: .A...., len: 0, seq: 45092-45092, ack:
7972460, win: 8760, src: 1025 dst: 139 (NBT Session)
Когда сеанс TCP создан, следующий шаг состоит в создании сеанса NetBIOS
с сервером регистрации.
Создание сеанса NetBIOS Это достаточно прямолинейный процесс,
требующий только двух кадров и 182 байтов. Кадр запроса состоит из 126 бай-
байтов, а ответ только из 56 байтов. Отметим, что вызываемое имя будет Teresa,
а вызывающее имя — Kenny. Так как эти два имени были ранее разрешены,
сеанс должен работать.
NBT: SS: Session Request, Dest: TERESA, Source: KENNY
<00>, Len: 68
NBT: Packet Type = Session Request
NBT: Packet Flags = 0 @x0)
NBT: 0 = Add 0 to Length
NBT: Packet Length = 68 @x44)
NBT: Called Name = TERESA
NBT: Calling Name = KENNY <00>
Ниже находится положительный ответ на запрос Kenny о создании се-
сеанса NetBIOS с сервером регистрации Teresa. Мы опустили здесь раздел
TCP этих распечаток, но если взглянуть на него, то можно заметить, что
кадр с машины Kenny приходит из порта 1025 с местом назначения на пор-
порте 139, как мы видели выше в трехходовом квитировании. Очевидно, что
приведенный ниже кадр ответа приходит из порта 139 в порт 1025.
NBT: SS: Positive Session Response, Len: 0
NBT: Packet Type = Positive Session Response
NBT: Packet Flags = 0 @x0)
NBT: 0 = Add 0 to Length
NBT: Packet Length = 0 @x0)
После создания сеанса NetBIOS необходимо согласовать протокол SMB,
а затем создать сеанс SMB.
Согласование диалекта SMB и настройка сеанса Теперь необходи-
необходимо решить, какой диалект SMB мы собираемся использовать. Это должно
быть согласовано до настройки сеанса. Потребуются два кадра в 212 байтов
и 149 байтов соответственно. Машина Kenny посылает кадр SMB с коман-
командой согласования С, перечисляющей допустимые строки диалектов. Это
посылается из порта 1025 машины Kenny и приходит в порт 139 на машине
Teresa.

154 Глава 5
SMB: С negotiate, Dialect = NT LM 0.12
+ SMB: SMB Status = Error Success
SMB: Header: PID = 0xl52F TID: = 0x0000 MID = 0x0101
UID = 0x0000
SMB: Tree ID (TID) = 0 @x0)
SMB: Process ID (PID) = 5423 @xl52F)
SMB: User ID (UID) = 0 @x0)
SMB: Multiplex ID (MID) = 257 @x101)
+ SMB: Flags Summary = 0 @x0)
+ SMB: flags2 Summary = 0 @x0)
' SMB: Command = С negotiate
SMB: Word count = 0 •'¦'•
SMB: Byte count = 119 • ; .
., , . SMB: Byte parameters
.;¦ . SMB: Dialect Strings Understood
SMB: Dialect String = PC NETWORK PROGRAM 1.0
SMB: Dialect String = MICROSOFT NETWORKS 3.0
SMB: Dialect String = DOS LM1.2X002
SMB: Dialect String = DOS LANMAN2.1
SMB: Dialect String = Windows for Workgroups 3.1a
SMB: Dialect String = NT LM 0.12
Ниже мы видим ответ от машины Teresa. Она посылает ответ, выбирая
протокол с индексом 5, который соответствует диалекту NT LM 0.12.
SMB: R negotiate. Dialect # = 5 ..
+ SMB: SMB Status = Error Success
SMB: Header: PID = 0xl52F TID = 0x0000 MID = 0x0101
UID = 0x0000
SMB: Tree ID (TID) = 0 @x0)
SMB: Process ID (PID) = 5423 @xl52F)
¦'" ' SMB: User ID (UID) = 0 @x0)
SMB: Multiplex ID (MID) = 257 @x101)
+ SMB: Flags Summary = 128 @x80) .: ... , ,
+ SMB: flags2 Summary = 0 @x0)
SMB: Command С negotiate
SMB: Word count = 17
SMB: Word parameters
SMB: Protocol Index = 5
Теперь мы подошли к настройке сеанса SMB, которая также потребует
два кадра из 207 байтов и 154 байтов соответственно. В первом кадре ниже
мы видим две команды: С session set-up & X, передающую имя пользователя
MGROCE, и С tree connect & X, которая сообщает нам, что машина Kenny
пытается соединиться со скрытым общим ресурсом 1РС$ на машине Teresa.
Это используется для межпроцессной коммуникации. Второй листинг соот-
соответствует кадру с машины Teresa на машине Kenny, и он является ответом
на обе команды, которые были переданы в предыдущем пакете. Отметим,
что здесь нет ошибок, поэтому сеанс SMB был успешно создан.

Клиентский трафик 155
SMB: С session setup & X, Username = MGROCE, and С tree
connect & X, Share = \\TERESA\IPC$
+ SMB: SMB Status = Error Success
+ SMB: Header: PID = 0xl52F TID = 0x0000 MID = 0x0101
UID = 0x0001
+ SMB: Command = С session setup & X
+ SMB: Command = С tree connect & X
SMB: Command = No secondary command
SMB: R session setup & X, and R tree connect & X, Type = IPC
+ SMB: SMB Status = Error Success
+ SMB: Header: PID = 0xl52F TID = 0x0801 MID = 0x0101
UID = 0x0801
+ SMB: Command = С session setup & X
+ SMB: Command = С tree connect & X •
'-' SMB: Command = No secondary command :, ¦ '•¦
Теперь машина Windows 98 (Kenny) начинает диалог с сервером (Tere-
(Teresa) , направляя две регистрации удаленных вызовов API для проверки реги-
регистрации. Эта API вызываются с помощью команды SMB С transact
удаленной командой API. Первым вызывается API с именем NetWkstaUser-
Logon, который делает запрос на проверку регистрации. Машина Teresa
отвечает сообщением об успехе, которое приведено во втором фрагменте
ниже.
SMB: С transact -
+ SMB: Command = С transact
+ SMB: SMB Status = Error Success
+ SMB Header: PID = 0xl52F TID = 0x0801 MID = 0x0201
UID = 0x0801
+ SMB Data: Number of data bytes remaining = 94 @x005E)
SMB: R transact
+ SMB: SMB Status = Error Success
+ SMB Header: PID = 0xl52F TID = 0x0801 MID = 0x0201
UID = 0x0801
+ SMB Command = С transact
SMB: Data: Number of data bytes remaining = 103
@x0067)
Вторым вызовом API является NetRemoteTOD. Этот вызов API извлека-
извлекает информацию о времени сервера, чтобы определить смещение часового
пояса для вычисления отметки времени и даты временного файла. Сервер
сообщает время контроллера домена.
SMB: С transact, Remote API
+ SMB: SMB status = Error Success
+ SMB: Header: PID = 0xl52F TID = 0x0801 MID = 0x0281
UID = 0x0801
+ SMB: Command = С transact
SMB: Data: Number of data bytes remaining =20
@x0014)
SMB: R transact, Remote API (response to frame 25)

156
Глава 5
+ SMB: SMB status = Error Success
+ SMB: Header: PID = 0xl52F TID = 0x0801 MID = 0x0281
UID = 0x0801
+ SMB: Command = С transact
SMB: Data: Number of data bytes remaining =25
@x0019)
Оставшиеся шаги в этом месте включают соединение с общим ресурсом
\\teresa\netlogon и выполнение регистрационных сценариев, профилей
пользователя или системных политик. Это будет создавать дополнитель-
дополнительный трафик. Когда все будет сделано, останется только "культурно" завер-
завершить сеансы, которые были созданы во время процесса регистрации в
системе. Это включает закрытие сеанса 1РС$, сеанса NetBIOS и сеанса TCP.
При этом будет создаваться дополнительно пять кадров и 360 байтов тра-
трафика. Можно обратиться к файлу 98_logon.cap на сайте издательства
"ЛОРИ" (www.lory-press.ru), чтобы увидеть некоторые из этих шагов.
Оптимизация регистрации в сети
Использование LMHOSTS Начнем этот раздел с обсуждения двух
способов, с помощью которых рабочая станция находит машину регистра-
регистрации — с помощью широковещания и с помощью WINS. Существует и третий
способ: использование файла lmhosts. Обратимся к этому файлу.
10.0.0.25 NTS1
10.0.0.26 NTS2
10.0.0.10 EXCHANGE
#PRE #DOM:DOMAIN
#PRE #DOM:DOMAIN
#PRE
#DOMAIN PDC
#DOMAIN BDC
#EXCHANGE SERVER
Scope Properties - (Local)
• IP Address Pool
Start Addcet*
End Address
10
10
0
0
. 0
. 0
. 50
. 254
| Subnet Masts: B55 00
i
\ Exclusion Range
Start Addless:
End Address
Lease Duration
<~ Untmrted
<? Limited To:
Name:
Comment: |
Excluded Addresses:
) [tTgHouris) (o~^
Cancel
Heip
Рис. 5.2. Команда nbtstat -с предоставляет способ увидеть кэш имен NetBIOS

Клиентский трафик 157
Используя запись #PRE, мы приказываем машине сделать предваритель-
предварительную загрузку записи в кэш имен NetBIOS. Она будет найдена, когда мы вве-
введем nbtstat -с, как показано на рис. 5.2. Задав #DOM с именем домена, мы
сообщаем машине, что это контроллер домена, и поэтому получаем допол-
дополнительные записи, такие как <1С>, также показанные на рис. 5.2.
Используя файл LMHOSTS, мы ускоряем процесс регистрации, не вы-
выполняя при этом ни широковещательного запроса, ни запроса WINS, и,
кроме того, сокращаем сетевой трафик. Стандартная проблема с реализа-
реализацией LMHOSTS состоит в размещении его на всех клиентских машинах.
Выход простой: поместите LMHOSTS в сценарий регистрации, и он сам
скомпонуется на клиентские машины. На машине WIN NT он помещается
в каталоге \\system32\drivers\etc. На машине Windows 9.x он помещается
в каталог \\windows.
Нужно ли иметь больше контроллеров доменов? Обычно процесс реги-
регистрации происходит между 8 и 9 часами утра. Сколько реально необходимо
иметь серверов регистрации? Помните, что добавление дополнительных
резервных контроллеров доменов увеличивает сетевой трафик, как мы уви-
увидим в следующей главе. Это означает, что было бы плохой идеей сделать
каждый сервер в сети резервным контроллером домена (что встречается
достаточно часто).
Используя очень консервативную оценку, один контроллер домена мо-
может легко управлять 2000 пользователей. Если вернуться к нашему окну ре-
регистрации, можно видеть, что в течение одного часа C600 секунд),
происходит в среднем меньше двух регистрации в секунду (если запросы
регистрации распределены равномерно). Что делать в такой ситуации?
Прежде всего, необходимо использовать монитор производительности для
создания протокола утренней деятельности по регистрации. Как можно ви-
видеть на рис. 5.3, лучшим способом это сделать является создание протокола
(log) монитора производительности и протокола использования памяти,
процессора и серверного объекта. Для этого надо перейти во view\log и вы-
выбрать соответствующие режимы. В меню режимов выбирается тип прото-
протокола (log), а затем вводится имя протокола. Можно использовать,
например, logon.log или добавить дату. Выберите хорошее место для разме-
размещения протокола (не в корне), интервал обновления и нажмите save (со-
(сохранить). Теперь необходимо добавить некоторые показатели, нажимая
кнопку "плюс", как показано на рис. 5.3.
Когда показатели будут добавлены, необходимо вернуться в меню ре-
режимов, выбрать тип протокола (log) и запустить протокол, как показано
на рис. 5.4. Это будет достаточно большой протокол, так как записи в нем
появляются каждую секунду.
Если после создания протокола будут замечены периоды, когда происходит
множество попыток регистрации в секунду, необходимо сделать несколько
дополнительных изменений.

158
Глава 5
зд Perfoimance Momior
Ete ?* У»« Qpiioru H*
|C4.0G0Nlog
SWtur
Object
S«vm
Мепюу
Coreuiei
пяйсГ
VVPROX
Рис. 5.З. Создание представления протокола для мониторинга трафика регистрации
Log Options
Savejn:
(С:)
 Ц] й1 li^il
m
I 3comiq
lavery
I Catalog, wci
I HPFonts
I InetPub
I Multimedia Files C] Winzip
Щ mpsselup.bg
CJ Progtam Files
СИ Recycler
i_J Temp
File дате:
Save
Save as type: | Log Files ("log)
: Update Time
Cancel
Interval (seconds):
Start Log
? Periodic Update A.000
С Manual Update
Рис. 5.4. Созданный протокол должен быть запущен

Клиентский трафик 159
г Optimization:—
1 f \4\rirme Memory Used
; С fjalance
(• Maximize Throughput lot File Sharing
<~ Мдатйге Throughput foi Network Applications
Г Make Browser Broadcasts to UN Manager 2.x Clients
Рис. 5.5. При правильной конфигурации службы сервера можно улучшить
проверку регистрации
Увеличение объема одновременной проверки регистрации Когда
создается контроллер домена, служба сервера оптимизирована для совме-
совместного использования файлов и принтеров. Это хорошо для серверов фай-
файлов и печати, но создает не оптимальную производительность для серверов
регистрации. Чтобы изменить это, обратимся к сетевому апплету в панели
управления (или сделаем щелчок правой кнопкой мыши по пиктограмме
сети на рабочем столе), выберем сервер из закладок служб и щелкнем мы-
мышью по свойствам. Как можно видеть на рис. 5.5, мы хотим выбрать макси-
максимальную производительность для сетевых приложений. Затем нажмем ОК.
Примечание. Необходимо перезагрузить машину, чтобы получить какой-то
эффект. Делая такие изменения, контроллер домена может утроить число
одновременных регистрации — от шести до почти 20 регистрации в секунду.
Размещение сервера регистрации Когда речь идет о регистрации,
чем ближе пользователь находится к контроллеру домена, тем лучше. Когда
имеется удаленный сайт, не обязательно бездумно помещать BDC на другой
стороне медленного соединения и надеяться на лучшее. Существуют также
и другие ситуации. Должно быть рассмотрено влияние трафика WAN в свя-
связи с синхронизацией служб каталогов. В дополнение к этому, что произой-
произойдет, если линия WAN будет выключена, и службы каталогов устареют? Это
только часть вопросов, которые должны быть рассмотрены до реализации.
Дополнительно, скорее всего, понадобится реализовать WINS и DHCP и
сконфигурировать для них репликацию, чтобы сократить этот вид трафи-
трафика. Мы поговорим об этом в следующей главе, а сейчас, вероятно, лучше
всего поместить BDC на другой стороне медленного соединения WAN, но
это должна быть хорошо продуманная реализация. . v
Просмотр
Я ненавижу просмотр. Как правило, это долгий и утомительный процесс, а
если и есть на свете что-то еще более отвратительное, чем неправильно ра-
работающий компьютер, то это медленный компьютер. Несколько часов си-
сидеть и наблюдать за тем, как на экране вспыхивают цифры... волей-неволей
задумаешься о том, можно ли как-то рационализировать этот процесс.

160 Глава 5
Если просмотр не оптимизирован, то программа просмотра создает до-
дополнительный трафик всякий раз, когда кто-то регистрируется в сети.
Хотя автор предполагает, что читатели знакомы с концепцией просмот-
просмотра, необходимо рассмотреть несколько терминов, чтобы убедиться, что
речь идет об одном и том же. В системе просмотра есть пять ролей про-
просмотра. При чтении следующего далее списка помните, что один компью-
компьютер может выполнять более одной роли. Компьютер, выполняющий любую
из этих ролей, называется броузером (browser).
1. Мастер-броузер домена. Это всегда основной контроллер домена. Он
отвечает за сбор объявлений для всего домена, включая все подсети
сети TCP и сетевые сегменты. Когда этот список собран, мастер-броу-
мастер-броузер домена предоставляет список ресурсов всем мастер-броузерам в
сети. Мастер-броузер домена может также быть мастер-броузером для
своего сегмента.
2. Мастер-броузер. Мастер-броузер отвечает за сбор информации для
создания и поддержания списка просмотра, который включает все
серверы в домене или рабочей группе мастер-броузера, а также все
домены в сети. Сервер будет делать объявление сервера для мас-
мастер-броузера домена или рабочей группы, посылая направленную
дейтаграмму. Это объявление сервера перечисляет все доступные на
компьютере службы, и поэтому, помимо серверов NT, такие сервер-
_. . ные объявления будут также делаться рабочими станциями NT, ма-
машинами Windows 9.x и компьютерами Windows for Workgroup,
которые предоставляют какую-либо форму совместного использова-
использования файлов и печати. Мастер-броузер получает это объявление и до-
добавляет компьютер в список просмотра. Если домен включает более
одной подсети TCP, то мастер-броузер будет отвечать только за свой
сегмент, но будет поддерживать также список резервных броузеров
локальной подсети.
3. Резервный броузер. Резервный броузер получает копию списка про-
просмотра от мастер-броузера и передает список по запросу компьютерам
в домене. Все контроллеры домена автоматически конфигурируются
либо как мастер-броузер, либо как резервный броузер. Рабочие стан-
станции Windows NT, компьютеры Windows 9.x и Windows for Workgroup
могут быть резервными броузерами, если в домене существует мень-
меньше трех серверов NT, выполняющих функции резервного броузера.
Резервные броузеры вызывают мастер^эроузер каждые 15 минут, что-
чтобы получить самую последнюю копию списка просмотра, а также те-
текущий список доменов в сети. Если мастерброузер недоступен, то
резервный броузер будет инициировать выборы.
4. Потенциальный броузер. Потенциальным броузером является
компьютер, который может поддерживать список просмотра сетевых
ресурсов, но еще не имеет списка. Он будет поддерживать список про-
просмотра только в том случае, если мастер-броузер прикажет это делать.
В этом случае потенциальный броузер становится резервным.

Клиентский трафик 161
5. Не-броузер. He-броузер может быть специально сконфигурирован
так, чтобы не поддерживать список просмотра. Не будучи сконфигури-
сконфигурирован как не-броузер, компьютер будет потенциальным броузером,
если он имеет активные серверные компоненты.
Объявления хостов броузеров
Компьютер, который предоставляет ресурсы в сети, делает объявления хо-
хостов каждые 12 минут (хотя эта частота выше во время инициализации кли-
клиента) для гарантии, что он правильно добавлен в список просмотра. Это
объявление имеет 243 байта, как видно на распечатке ниже. Отметим, что
адрес FFFFFFFFFFFF места назначения Ethernet указывает, что это широко-
широковещательное сообщение. В разделе IP можно видеть, что транспортным
протоколом служит UDP. Местом назначения для IP здесь также является
адрес широковещания, в данном случае 10.255.255.255. Если отнять 14 бай-
байтов заголовка Ethernet, то нам останется 209 байтов полезной нагрузки IP.
ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet
Protocol
+ ETHERNET: Destination address : FFFFFFFFFFFF
+ ETHERNET: Source address : 00902764FEBF
ETHERNET: Frame Length : 243 @x00F3)
ETHERNET: Ethernet Type: 0x0800 (IP: DOD Internet
Protocol)
ETHERNET: Ethernet Data: Number of data byters remaining =
229 <0x00E5)
IP: ID = 0x8004; Proto = UDP; Len: 229
IP: Version = 4 @x4)
IP: Header Length = 20 @x14) ,;
+ IP: Service Type = 0 @x0) . ¦ .. •
IP: Total Length = 229 @xE5)
IP: Identification = 32772 @x8004)
+ IP: Flags Summary = 0 @x0)
IP: Fragment Offset = 0 @x0) bytes
IP: Time to Live = 128 @x80)
IP: Protocol = UDP - User Datagram
IP: Checksum = 0xA4C9
IP: Source Address = 10.0.0.60
IP: Destination Address = 10.255.255.255
IP: Data: Number of data bytes remaining = 209
(OxOODl)
Можно заметить, что объявление хоста использует порт UDP 138, кото-
который является портом службы дейтаграмм NetBIOS. Хотя броузер использует
направленную дейтаграмму, она по-прежнему является широковещательной
A0.255.255.255). В данном случае местом назначения является домен MRED.
Отметим также, что объявление броузера использует службы протокола
SMB, выполняющие транзакцию С в \mailslot\browse.
+ UDP: Src Port: NETBIOS Datagram Service, A38); Dst Port:
NETBIOS Datagram Service A38); Length = 209 (OxDl)

162 Глава 5
NBT: DS: Туре = 17 (DIRECT GROUP) ,:/..щ<5 ... ;
NBT: Datagram Packet Type = DIRECT TYPE ,,,..'
+ NBT: Datagram Flags = 26 (OxlA) ,.- . ,..,
NBT: Datagram ID = 32892 @x807C)
NBT: Source IP Address = 10.0.0.60 ' "' '
NBT: Source Port = 138 @x8A)
NBT: Datagram Length = 187 (OxBB) -СЛ RWH9ft*t . ,•
.••..¦ NBT: Packet Offset = 0 @x0) , . .,< . .
¦•..." NBT: Source Name = 2400
NBT: Destination Name = MRED <1D>
NBT: DS Data: Number of data bytes remaining = 119
@x0077) ' '
SMB: С transact, File = \MAILSLOT\BROWSE
+ SMB: SMB Status = Error Success
+ SMB: Header: PID = 0x0000 TID = 0x0000 MID = 0x0000
UID =0x0000
.'". ;. + SMB: Command = С transact
SMB: Data: Number of data bytes remaining = 33
@x0021) ¦.-...-
Посмотрим теперь на сам формат реального объявления хоста. Прежде
всего, мы видим интервал объявления, равный 12 минутам, и имя броузера,
которое определено как 2400. Сводка типа сервера сообщает службы, кото-
которые выполняются на машине. Сервер 2400 выполняет как серверные ком-
компоненты, так и компоненты рабочей станции, и является резервным
контроллером. Сложным моментом при чтении этого раздела является то,
что одни поля используют 1 для "да", а другие для "нет". Отметим, что пере-
перечисленные поля не принадлежат серверу NT. Здесь мы имеем 0, означаю-
означающий, что это сервер NT. Значение I в поле резервного броузера говорит,
что это резервный броузер.
BROWSER: Host Announcement [0x01] 2400
BROWSER: Command = Host Announcement [0x01]
BROWSER: Update Count = 0 @x0)
BROWSER: Announcement Interval [minutes] = 12
BROWSER: Name = 2400
BROWSER: Major Version = 4 @x4)
BROWSER: Minor Version = 0 @x0)
BROWSER: Server Type Summary = 13 5187 @x21013)
BROWSER: 1 = Workstation
BROWSER: 1. = Server
BROWSER: 0 . . = Not SQL Server
BROWSER: 0... = Not Domain Controller
BROWSER: 1.... = Backup Controller
BROWSER: 0 = Not Time Source
BROWSER: 0 = Not Apple Server
BROWSER: 0 = Not Novel 1
BROWSER: = Not Domain Member Server
BROWSER: 0 = Not Print Queue Server
BROWSER: 0 = Not Dialing Server
BROWSER: 0 = Not Xenix Server
BROWSER: . . 1. . . . : = Windows NT Workstation

Клиентский трафик 163
BROWSER: О = Not WFW System .
..•I.. . .. BROWSER: 0 = Not NT Server
BROWSER: ...0 = Not Potential Browser ¦ i
BROWSER: 1 = Backup Browser Server
BROWSER: ... 0 = Not Master Server
BROWSER: 0. . . . = Not Domain Master Browser :
BROWSER: 0 = Not OSF
BROWSER: 0 = Not VMS
BROWSER: 0 = Not Windows 95 or above
BROWSER: .0 = Not Local List Only
BROWSER: 0 = Not Domain Enum
BROWSER: Browser Election Version = 271 (OxlOF)
BROWSER: Browser Constant = 43605 @xAA55)
Где находятся резервные броузеры?
Когда клиентской машине необходимо просмотреть сеть, прежде всего не-
необходимо найти резервный броузер, который предоставит ей список сете-
сетевых ресурсов. Чтобы получить список резервных броузеров, необходимо
найти мастер-броузер, который, как мы знаем, хранит список резервных
броузеров. Когда это сделано, она сможет обратиться к резервному броузе-
броузеру и получить список просмотра.
Теоретически требуются только два кадра, чтобы получить список ре-
резервных броузеров. Сначала посылается простое широковещательное со-
сообщение с 216-байтовым кадром, содержащим команду броузера 0x09,
являющуюся запросом для получения резервного списка.
BROWSER: Get Backup List Request [0x09]
BROWSER: Command = Get Backup List Request [0x09]
BROWSER: Get Backup List Requested Count = 4 @x4)
BROWSER: Backup Request Token = 1 @x1)
За ним будет следовать 226-байтовый кадр ответа, в зависимости, конеч-
конечно, от числа пронумерованных серверов. Как можно видеть ниже, команда
броузера ОхОа создает ответный резервный список, в котором перечислены
только два резервных броузера, PROX и 2400.
BROWSER: Get Backup List Response [0x0a] 2 Servers
BROWSER: Command = Get Backup List Response [OxOa]
BROWSER: Backup Server Count = 2 @x2)
BROWSER: Backup Response Token = 1 @x1)
BROSWER: Backup Servers = PROX
BROWSER: Backup Servers = 2400
Когда клиентский компьютер получил список резервных серверов, мож-
можно обратиться к резервному броузеру и получить список просмотра. В таб-
таблице 5.5 последовательность событий для рабочей станции Windows NT
требует 16 кадров. Она начинается с создания соединения SMB с \srvsvc на
машине Teresa. Если это успешно завершилось, то edit делает вызов RPC
функции удаленного API NetServerGetlnfo. Здесь снова работает SMB,
доставляя информацию, а затем машина edit закрывает соединение.

164
Глава 5
Таблица 5.5. Процедура для получения списка просмотра
Источник Место назначения Протокол Описание
EDLT
TERESA
EDLT
TERESA
EDLT
TERESA
SMB
SMB
MSRPC
С NT create & X, File = \srvsvc
R NT create & X, FID = 0x1007
c/o RPC Bind: UUID
4B324FC8-1670-01D3-1278-5A4
7BF6EE188 ca
TERESA
EDLT
MSRPC c/o RPC Bind Ack: call 0x3
assoc grp 0x7931 xmit 0x1630
recv
EDLT
TERESA
EDLT
TERESA
EDLT
TERESA
EDLT
TERESA
EDLT
TERESA
EDLT
TERESA
TERESA
EDLT
TERESA
EDLT
TERESA
EDLT ,',i.j _u
TERESA
EDLT
TERESA
EDLT
TERESA
EDLT
R_SRVSVC
R_SRVSVC
SMB
SMB
SMB
SMB
MSRPC
MSRPC
MSRPC
MSRPC
SMB
SMB
RPC Client call srvsvc:
NetrServerGetInfo(..)
RPC Server response srvsvc:
NetrServerGetlnfo (..)
С close file, FID = 0x1007
R close file
С NT create & X, File = \wkssvc
R NT create & X, FID = 0x1008
c/o RPC Bind: UUID
6BFFD098-A112-3610-9833-46C
3F87E345A ca
c/o RPC Nbind Ack: call 0x1
assoc grp 0x7932 xmit 0x1630
recv
c/o RPC Request: call 0x1 op-
num 0x0 contex 0x0 hint 0x28
c/o RPC Response: call 0x1
context 0x0 hint 0x58 cancels
0x0
С close file, FID = 0x1008
R close file
После завершения этой процедуры, когда клиентская машина получает
список резервных броузеров, компьютер может выбрать сервер и получить
список общих ресурсов. Это может потребовать еще 18 или 19 кадров и
около 2000 байтов трафика сервера для девяти перечисленных общих ре-
ресурсов. Общий объем трафика зависит, конечно, от числа перечисленных
на сервере общих ресурсов.

Клиентский трафик 165
Оптимизация трафика броузера
Хотя просмотр сети делает достаточно удобным для некоторых пользовате-
пользователей исследование ресурсов LAN/WAN, это обеспечивается за счет доста-
достаточно высокой цены в терминах использования трафика. Как мы видели в
этом разделе, трафик броузера с необходимыми накладными расходами и
сопровождением может потребовать много байтов из доступной полосы
пропускания сети. Помня об этом, нам необходимо иметь возможность со-
сохранить ресурсы и найти им лучшее применение. Рассмотрим некоторые
идеи.
Отключение серверных служб на рабочих станциях Отключите на
машинах Windows 9.x общий доступ к файлам и печати, если они в действи-
действительности не предоставляют службы файлов и печати. Это поможет убрать
объявления и сократит объем списка просмотра. Даже не предоставляя ни-
никаких ресурсов, эти машины будут требовать записи в списке просмотра, ко-
которая занимает как минимум 27 байтов. Дополнительные серверные
комментарии занимают лишнее место в списке просмотра и часто не пред-
представляют особой ценности. Например, сервер с именем exchange не нужда-
нуждается в действительности в каком-либо дополнительном комментарии. На
рабочей станции или сервере Windows NT для того, чтобы отключить сер-
серверную службу, достаточно обратиться к апплету служб в панели управления,
выбрать серверную службу и задать ее как manual (ручное управление).
Ограничьте число потенциальных броузеров Чтобы контролиро-
контролировать число выборов броузеров, появление и удаление резервных броузеров
и весь связанный с этим трафик, можно ограничить количество машин в
иерархии броузеров. Это требует внесения изменений в каждую машину,
которые перечислены ниже.
• На машине Windows NT существует настройка реестра, которую необ-
необходимо изменить: HKEY_LOCAL_MACHINE\SYSTEM\CurrentCont-
rolSet\Services\Browser\ Parameters\MaintainServerList должен задан
как по (нет).
• На машине Windows 9.x в сетевом апплете в панели управления выбе-
выберите службу общего использования файлов и печати. Выберите свой-
свойства (properties) и отключите параметр "browse master".
• На компьютере Windows for Workgroups необходимо отредактировать
файл system.ini. В разделе network добавьте MaintainServerList = no.
Удалите ненужные протоколы Просмотр выполняется для каждого
протокола. Если компьютер имеет четыре установленных протокола, объ-
объявления броузера и выборы будут повторяться для каждого из них. Если
исключить два из этих протоколов, то можно существенно сократить объем
трафика броузера.
Используйте ярлыки для обращения к сетевым ресурсам Удобно
использовать ярлыки для обращения к часто используемым сетевым ресур-
ресурсам. Они значительно быстрее и существенно сокращают сетевой трафик.
Использование редактора политик и отключения сетевого окружения для

166 Глава 5
большинства пользователей поможет реально сократить сетевой трафик.
Создайте папку с ярлыками для ресурсов, которые им нужны, и сделайте ее
общей группой значков рабочего стола.
Обзор главы
,;г
В этой главе был рассмотрен трафик клиента. Мы начали с исследования
источников клиентского трафика с момента включения машины. Был рас-
рассмотрен DHCP при запросе машиной IP-адреса. Затем обсуждался трафик
клиента WINS в ситуациях, когда компьютер пытается зарегистрировать
свое имя в сети или ищет другие компьютеры для коммуникации.
Мы тщательно проанализировали трафик регистрации и процесс, во-
вовлеченный в поиск сервера регистрации. За этим последовали некоторые
предложения по сокращению трафика. Перейдя к просмотру ресурсов, мы
исследовали процесс просмотра, увидели, как работают объявления хос-
хостов, как выбираются, идентифицируются и используются резервные броу-
броузеры. В завершение мы узнали некоторые способы сокращения этого
трафика.
,!Г.*1: '." •' • ¦>..,"!
В следующей главе *
В следующей главе рассматривается трафик сервера. Она начинается с ис-
исследования DNS. Мы увидим, как DNS разрешает имена и использует рекур-
рекурсивный поиск. Мы узнаем, как DNS интегрируется с WINS и поговорим о
способах оптимизации трафика DNS.
Вслед за обсуждением WINS рассматривается трафик инициализации
BDC. Мы увидим, как он находит PDC и обновляет свою базу данных, и по-
познакомимся со способами оптимизации трафика синхронизации учетной
записи и службы NetLogon. ,,.. „ , ,,; j •
¦ I1!
-л..
¦ ¦ <U : •'.(

Глава б
Серверный трафик
Серверы порождают очень большой объем трафика. При этом речь идет не
об обычном трафике, связанном с пересылкой файлов, службами печати и т.д.
Речь идет о стоимости наличия сервера в сети.
DNS
Система имен доменов (DNS) является относительно эффективным прото-
| колом, созданным для помощи компьютерам в преобразовании имени хоста
в IP-адрес. Это старший брат WINS, который, как мы знаем из предыдущей
главы, преобразует имя NetBIOS в IP-адрес. В этом загадочном мире сетей
различные приложения общаются по-разному. Например, когда вводится
команда net use, используется команда, которая общается с NetBIOS. Когда
вводится команда ping, используется команда с именем хоста. Другой
способ: DNS является файлом hosts, a WINS является файлом lmhosts.
Так как DNS создан эффективным протоколом, большая часть трафика
создается, когда клиентская машина запрашивает сервер DNS и получает
его ответ. Определение того, как часто это происходит, поможет при оцен-
оценке влияния DNS на сеть. Различаются все и все пользователи (хотя иногда
они обладают раздражающе похожими характеристиками).
Одним из факторов, который имеет существенное влияние на сеть, яв-
является рекурсивный поиск DNS. Рекурсивный поиск происходит, когда сер-
сервер DNS не может самостоятельно разрешить имя и поэтому запрашивает
другой сервер DNS или даже сервер WINS. Полученный ответ передается
затем клиенту в ответ на запрос. Здесь есть потенциальная возможность
удвоения объема трафика, связанного с DNS. , ¦¦ ¦ ¦
Разрешение адреса
Поиск DNS является простым разговором между клиентской машиной и
сервером DNS. Запрос равен приблизительно 81 байту, а ответ — 97 байтам,
в зависимости от количества перечисленных имен серверов. Отметим, что

168 Глава 6
DNS является направленным протоколом, и адрес MAC места назначения
является реальным адресом сервера DNS, а не широковещательным адре-
адресом, как в других протоколах. Кроме того, мы видим в разделе IP, что место
назначения является реальным IP-адресом сервера DNS в этой сети.
+ ETHERNET Destination address : 0008C733F3E2
ETHERNET: Source address : 00805F36CA55
ETHERNET: 0 = No routing information present
ETHERNET: ...0. = Universally administered address
ETHERNET: Frame Length : 81 @x0051)
ETHERNET: Ethernet Type : 0x0800 (IP: DOD Internet
Protocol)
ETHERNET: Ethernet Data: Number of data bytes
remaining = 67 @x0043)
IP: ID = OxBOEE; Proto = UDP; Len: 67
IP: Version = 4 @x4)
IP: Header Length = 20 @x14)
+ IP: Service Type = 0 @x0)
IP: Total Length = 67 @x43)
IP: Identification = 45294 (OxBOEE) i
+ IP: Flags Summary = 0 @x0) ''
IP: Fragment Offset = 0 @x0) bytes
IP: Time to Live = 128 @x80)
IP: Protocol = UDP - User Datagram
IP: Checksum = OxlOlE '¦¦'•
, IP: Source Address = 10.1.1.36
IP: Destination Address 10.1.100.120
IP: Data: Number od data bytes remaining = 47 @x002F)
DNS использует протокол UDP для повышения скорости и эффективно-
эффективности. В распечатке ниже отметим, что порт источника является портом, вы-
выбранным клиентской машиной. В данном случае это порт 1185. Клиентская
машина, однако, не выбирает порт назначения, это будет общеизвестный
порт 53.
UDP: Src Port: Unknown, A185); Dst Port: DNS E3); Length =
47 @x2F)
UDP: Source Port = OxO4Al
UDP: Destination Port = DNS
UDP: Total length = 47 @x2F) bytes
UDP: UDP Checksum = 0x4FFl
UDP: Data: Number of data bytes remaining =39 @x0027)
В распечатке ниже отметим, что счетчик запросов равен 1 @x1), а счет-
счетчик ответов равен 0 @x0). Это позволяет понять, что это кадр запроса. В
разделе запроса мы видим вопрос: "Где находится Donald.Duck.Com?" Это
запрос адреса хоста класса адреса Интернета. Это типичный клиентский
запрос DNS.
DNS: OxlrStd Qry for Donald.Duck.Com. of type Host Addr on
class INET addr.
. DNS: Query Identifier = 1 @x1)

Серверный трафик 169
. . + DNS: DNS Flags = Query, OpCode - Std Qry, RD Bits Set,
RCode - No error
DNS: Question Entry Count = 1 (Oxl)
DNS: Answer Entry Count = 0 @x0)
DNS: Name Server Count = 0 @x0)
DNS: Additional Records Count = 0 @x0)
DNS: Question Section: Donald.Duck.Com. of type Host
Addr on class INET addr.
DNS: Question Name: Donald.Duck.Com.
DNS: Question Type = Host Address
DNS: Querstion Class = Internet address class
Ответ возвращается от сервера DNS в следующем формате. Отметим,
что теперь счетчик ответов задан как 1 @x1), а к разделу запроса (кото-
(который был перенесен из предыдущего кадра) теперь добавлен раздел отве-
ответа. В разделе ответа имеется поле времени жизни, которое задается по
умолчанию как 3600 секунд, длина данных из четырех байтов и IP-адрес
Donald.Duck.Com.
DNS: 0x1:Std Qry Resp. for Donald.Duck.Com. of type Host
Addr on class INET addr.
DNS: Query Identifier = 1 @x1)
+ DNS: DNS Flags = Response, OpCode - Std Qry, AA RD RA
Bits Set, RCode - No error
DNS: Question Entry Count = 1 @x1)
DNS: Answer Entry Count = 1 @x1) ; '
'"*"¦ DNS: Name Server Count = 0 @x0) . . •
DNS: Additional Records Count = 0 @x0)
DNS: Question Section: Donald.Duck.Com. of type Host
Addr on class INET addr.
DNS: Question Name: Donald.Duck.Com.
DNS: Question Type = Host Address
DNS: Question Class = Internet address class
:,. DNS: Answer section: Donald.Duck.Com. of type Host
Addr on class INET addr.
DNS: Resource Name: Donald.Duck.Com.
DNS: Resourse Type = Host Address
DNS: Resourse Class = Internet address class
Y •. DNS: Time To Live = 3 600 (OxElO)
,. DNS: Resource Data Length = 4 @x4)
- DNS: IP address = 10.1.100.3
Рекурсивный поиск
Если запрошенный сервер DNS не имеет информации для удовлетворения
клиентского запроса, есть две возможности: сообщить клиенту, что имя не
существует, или запросить запись у другого сервера DNS, если разрешен ре-
рекурсивный поиск.
Клиент делает запрос серверу DNS таким же образом, как в предыдущем
примере. Когда сервер проверяет свою базу данных и не находит записи,
он пересылает запрос своему рекурсивному партнеру. Это, по сути, тот же
кадр, за исключением того, что первый сервер DNS изменяет адрес

170 Глава б
назначения со своего на адрес рекурсивного партнера. Второй сервер DNS
получает запрос, как любой другой запрос DNS, ищет информацию в своей
базе данных и посылает ответ первому серверу. Этот ответ выглядит как
кадр ответа на распечатке выше. Первый сервер DNS получает теперь от-
ответ от второго сервера DNS, изменяет адрес места назначения со своего на
адрес первоначальной запрашивающей клиентской машины и посылает от-
ответ клиенту. Таким образом, клиент не знает, что поиск был рекурсивным.
Объединение с WINS
Так же, как сервер DNS может запрашивать рекурсивный поиск у другого
сервера DNS, он может запрашивать информацию у сервера WINS, если за-
запись не находится в системе DNS. Это позволяет DNS содержать статиче-
статические записи DNS и использовать возможности динамической регистрации
имен WINS. Это происходит аналогично рекурсивному поиску DNS. Сервер
DNS получает запрос с клиентской машины. Если сервер DNS не имеет ин-
информации, он запросит ее у сервера WINS. Когда от сервера WINS будет по-
получена запись, адрес места назначения изменяется на адрес клиента, и кадр
пересылается на клиентскую машину, как если бы информация поступила с
сервера DNS.
Оптимизация DNS
Поиск DNS требует только двух относительно небольших кадров, если инфор-
информация находится на сервере. Ниже перечислены три метода сокращения
трафика DNS.
• Не активизируйте рекурсию. Конечно, это может ограничить функ-
функциональность DNS. В таком случае обеспечьте, чтобы все хосты были
помещены в DNS, но это станет проблемой при использовании
DHCP, который выдает IP-адреса динамически.
• Настройте рекурсию, но убедитесь, что наиболее часто используемые
серверы помещены в сервер DNS. Это сократит необходимость рекур-
рекурсивного поиска.
• Увеличьте TTL (время жизни) кэшированных записей. Выполняя
рекурсивный поиск, сервер DNS будет кэшировать запись в течение
60 минут. Имя NetBIOS, найденное с помощью WINS, будет кэширова-
ться в течение 10 минут. С помощью менеджера DNS можно увели-
увеличить эти используемые по умолчанию значения, выбирая свойства
DNS для зоны, как показано на рис. 6.1.
Инициализация BDC
Когда BDC подключается к сети после перезагрузки, он может создавать зна-
значительный объем трафика и требует в результате достаточно много внима-
внимания со стороны PDC. Ему необходимо найти PDC и синхронизировать базу
данных учетных записей и секретную базу данных LSA. Необходимо сделать
различные объявления, например регистрацию имени и выборы броузера.

Серверный трафик
171
Zone Properties - u.in-addi.aipa
General SOA Record j Notify | WINS Reverse Lookup |
г- Record Type | r Value -
I
Г
f Description 1
The first entry in each гопй
file is «he SOA (Start of |
Authority) record. It '
indicates that the specified
name server is
authoritative for the
domain.
Primary Name Server DNS Name
|prox.mted
Responsible Peison Mailbox DNS Name
|admin.mred.
Serial Number |2
Refresh Interval |60
Retry Interval
Expire Time |24
Minimum Default TTL |8
| Minutes _^J:
I Minutes ж |
| Hours 3
lours
TTL [60 3 |Minutes jj
OK
Cancel
Рис. 6.1. Изменение кэша TTL в менеджере DNS для сокращения трафика
В примере файла запуска BDC инициализация занимает 123 кадра. Что же
делает BDC? Рассмотрим деятельность BDC в этом процессе.
Административные изменения происходят на PDC. Они могут быть сде-
сделаны где угодно, но PDC поддерживает базу данных учетных записей реаль-
реальных пользователей. BDC имеет только копию, с которой работает.
Поэтому важно, чтобы эта копия была актуальной. Процесс, который это
гарантирует, называется синхронизацией базы данных учетных записей.
Синхронизировать необходимо три отдельные базы данных: SAM (менед-
(менеджер безопасности учетных записей), встроенная база данных SAM (которая
содержит встроенные локальные группы, такие как administrators и users) и
база данных секретных паролей LSA (уполномоченный по локальной безо-
безопасности), содержащая пароли учетных записей компьютера контроллера
домена и информацию о доверительных отношениях.
Где находится PDC?
После выполнения обычных широковещательных сообщений броузера, за-
запросов ARP, регистрации имен и регистрации хостов BDC пытается найти
первичный контроллер домена. Для этого он пошлет широковещательное
сообщение NBT, используя порт UDP 137 (службы имен NetBIOS) в качестве
порта источника и места назначения, и запросит <1В>, связанный с именем
домена. Кадр запроса занимает 92 байта, а ответ — 104 байта, как отмечено

172 Глава 6
в распечатке ниже. В нашем примере отметим, что запрос предназначен
для MRED, являющегося именем домена. <1В> зарегистрирован только
первичным контроллером домена. Отметим, что счетчик запросов в этом
кадре задан как 1, а счетчик ответов как 0, указывая, что это кадр запроса.
NBT: NS: Query reg. for MRED <1B> ......,;....;;
NBT: Transaction ID = 32782 @x800E) ' '; '' "' ;
NBT: Flags Summary = 0x0110 - Req.; Query; Success
NBT: 0 = Request
NBT: .0000 = Query
NBT: 0 = Non-authoritative Answer
NBT: 0 = Datagram not truncated
NBT: 1 = Recursion desired
. NBT: 0 = Recursion not available
NBT: 0 = Reserved
' NBT: 0 = Reserved
, NBT: 1.... = Broadcast packet
NBT: 0000 = Success
NBT: Question Count = 1 @x1)
NBT: Answer Count = 0 @x0) •:
NBT: Name Service Count = 0 @x0) ""' , ¦
NBT: Additional Record Count = 0 @x0)
NBT: Question Name = MRED <1B>
NBT: Question Type = General Name Service
NBT: Question Class = Internet Class
Ответ возвращается немедленно с помощью кадра, приведенного ниже.
Отметим, что флаги в ответе изменились, причем оба флага официального
ответа изменились на противоположные. Раздел счетчика ответов задан те-
теперь как 1, а счетчик запросов как 0. В самом конце кадра владелец связыва-
связывается с именем MRED <1B>, предоставляя нам IP-адрес владельца 10.0.0.10.
NBT: NS: Query (Node Status) resp. for MRED .....,, <1B>,
Success
NBT: Transaction ID = 32782 @x800E)
NBT: Flags Summary = 0x8500 - Resp.; Query; Success
NBT: 1 = Response
NBT: .0000 = Query
NBT: 1 = Authoritative Answer
NBT: 0 = Datagram not truncated
NBT: 1 = Recursion desired
NBT: 0 = Recursion not available
NBT: 0 = Reserved
NBT: 0 = Reserved
NBT: 0.... = Not a broadcast packet
NBT: 0000 = Success
NBT: Question count = 0 @x0)
NBT: Answer Count = 1 @x0) ; •. ¦
NBT: Name Service Count = 0 @x0) •:..
NBT: Additional Record Count = 0 @x0)
NBT: Resource Record Name = MRED <1B>
NBT: Resource Record Type = NetBIOS General Name Service

Серверный трафик 173
NBT: Resource Record Class = Internet Class
NBT: Time to Live 300000 @x493E0)
NBT: RDATA Length = 6 @x6)
NBT: Resource Record Flags = 24576 @x6000)
NBT: 0 = Unique NetBIOS Name
NBT: .00 = В Node
NBT: ...0000000000000 = Reserved
NBT: Owner IP Address = 10.0.0.10
После обмена этими кадрами BDC пошлет дейтаграмму UDP на порт
138 службы дейтаграмм NetBIOS. Она посылается как ненадежное почто-
почтовое сообщение в \mailslot\net\netlogon на машине, IP-адрес которой вер-
вернулся в предыдущем запросе. Это делается для того, чтобы извлечь имя
первичного контроллера домена. Отметим, что в разделе NetLogon кадра
указано имя запрашивающего компьютера, имя почтового ящика, а также
различные поддерживаемые версии Lanman. Этот раздел не должен повто-
повторять перечисленную выше информацию, так как кадр посылается прямо
указанной машине.
NETLOGON: Query for Primary DC
NETLOGON: Opcode = Query for Primary DC
NETLOGON: Computer name = 2400
NETLOGON: Mailslot Name = \MAILSLOT\NET\GETDC116
NETLOGON: Unicode Computer Name = 2400
NETLOGON: NT Version = 1 @x1)
NETLOGON: LMNT Token = WindowsNT Networking
NETLOGON: LM20 Token = OS/2 LAN Manager 2.0 (or later)
Networking
Ответ возвращается из PDC. Отметим, что формат этого раздела изме-
изменился незначительно. В поле opcode, которое говорит нам, что это ответ
на первичный запрос, мы видим имя PDC, в данном случае PROX. Имя PDC
в формате Unicode также PROX, а имя домена MRED.
NETLOGON: Response to Primary Query
NETLOGON: Opcode = Response to Primary Query
NETLOGON: Primary PC Name = PROX
NETLOGON: Pad = 0 @x0)
NETLOGON: Unicode Primary DC Name = PROX
NETLOGON: Unicode Domain Name = MRED
NETLOGON: NT Version = 1 @x1)
NETLOGON: LMNT Token = WindowsNT Nerworking
NETLOGON: LM20 Token = OS/2 LAN Manager 2.0 (or later)
Networking
Теперь, когда основной контроллер домена найден, необходимо создать
сеанс. Для этого сначала выполняется трехходовое квитирование (допол-
(дополнительную информацию о трехходовом квитировании см. в главе 2). Затем
мы создаем сеанс NetBIOS, как показано на распечатке ниже. Это кадр за-
запроса сеанса NTB (показанный как packet type = session request) 0x81 из
BDC. Вызывающее имя 2400 является именем BDC; в данном случае он

174 Глава б
направляется PDC (вызванное имя PROX является в этом случае именем
PDC). Это маленький кадр, длиной только 126 байтов, содержащий заголо-
заголовок Ethernet. Портом источника в данном случае является порт 1025, кото-
который можно увидеть в трассировке (BDC initialize.cap) на сайте издательства
"ЛОРИ" (www.lory-press.ru). Порт места назначения — это общеизвестный
порт 139 (сеанс NBT 0х8В).
NBT: SS: Session Request, Dest: PROX , Source:
2400 <00>, Len: 68
NBT: Packet Type = Session Request ( . :, ,,.-.
NBT: Packet Flags = 0 @x0) ". ' !.,,.,
; NBT: 0 = Add 0 to Length " ";
NBT: Packet Length = 68 @x44) ''"''' i;; ''i!l "'
¦¦ ! NBT: Called Name = PROX ¦ ' ;il" ' '"", ! :':'
NBT: Calling Name = 2400 ¦ <0Q> ':''¦• '• ." Г>Щ
Рассмотрим кадр ответа. Сетевой монитор подробно разбирает кадр, и в
разделе NBT кадра можно видеть, что это "тип пакета = положительный от-
ответ на сеанс @x82)". Этот кадр, который еще меньше кадра запроса NetBIOS
(только 58 байтов составляют заголовок Ethernet), посылается от PDC
(PROX) в BDC B400). В данном случае портом источника будет 139, а портом
места назначения будет 1025 на BDC.
NBT: SS: Positive Session Response, Len: 0
NBT: Packet Type = Positive Session Response
NBT: Packet Flags = 0 @x0)
NBT: 0 = Add 0 to Length \ .
NBT: Packet Length = 0 @x0)
Требуются только два кадра и 184 байта, чтобы создать сеанс NetBIOS
между BDC и PDC. Теперь необходимо выполнить согласование протокола
SMB. Для этого нужны два кадра и дополнительно 373 байта трафика в
сети. Эти кадры используют те же порты, что и при предыдущем обмене;
т.е. на BDC они приходят из порта 1025, а на PDC направляются в порт 139.
Посмотрим на эти кадры в распечатке ниже. (Подробнее о согласовании
диалекта SMB см. в главе 4.) Мы видим раздел SMB кадра из BDC, когда он
пытается согласовать с PDC диалект, который будет использоваться при
коммуникации. Мы видим, что TID, UID и MID заданы как 0x0; однако PID
задан как OxCAFE. Разделы flags и flags2 аналогичны соответствующим раз-
разделам, которые были подробно рассмотрены в главе 4, поэтому здесь не об-
обсуждаются. Мы видим команду SMB С negotiate и строки диалектов,
понятные BDC. Если начать считать с 0 (как практически всегда делает
компьютер), можно заметить, что диалект #7 - это NT LM 0.12.
SMB: С negotiate. Dialect = NT LM 0.12
SMB: SMB Status = Error Success
SMB: Error class = No Error ''
SMB: Error code = No Error
SMB: Header: PID = OxCAFE TID = 0x0000 MID = 0x0000
UID = 0x0000
SMB: Tree ID (TID) = 0 @x0)

Серверный трафик
175
SMB: Process IP (PID) = 51966 (OxCAFE)
SMB: User ID (UID) = 0 @x0)
SMB: Multiplex ID (MID) = 0 @x0)
SMB: Flags Summary = 24 @x18)
SMB: flags2 Summary = 3 @x3) :
SMB: Command = С negotiate
SMB: Word count = 0
SMB: Byte count = 135 -(,-
SMB: Byte parameters
SMB: Dialect Strings Understood
3.1а
4', j.\
,':К:
SMB: Dialect String:
SMB: Dialect String:
SMB: Dialect String:
SMB: Dialect String:
SMB: Dialect String:
SMB: Dialect String:
SMB: Dialect String:
PC NETWORK PROGRAM 1.0
XENIX CORE
MICROSOFT NETWORK 1.03
LANMAN1.0
Windows for Workgroups
LM1.2X002
LANMAN2.1 ' "¦¦ ~""'v
SMB: Dialect String: NT LM 0.12
Теперь рассмотрим ответ от PDC для BDC, чтобы понять, как они разре-
разрешают свои коммуникационные вопросы. Это 145-байтовый кадр (включая
14-байтовый заголовок Ethernet), который выходит из порта 139 на сторо-
стороне PDC и идет в порт 1025 на стороне BDC. Отметим в распечатке ниже,
что статус SMB определен как error success, что означает отсутствие оши-
ошибок в этом разделе. Здесь снова нет TID, UID или MID, но имеется PID
(OxCAFE), который совпадает с PID в предыдущем кадре. Командой SMB яв-
является С negotiate. Отметим, что Protocol Index был выбран равным 7, что
соответствует диалекту NT LM 0.12 из предыдущего кадра. Другие интере-
интересующие моменты здесь также согласованы. Это NT Max Buffer Size D356) и
Max Row Size F5636), которые обсуждаются в главе 4. Интерес вызывает
имя домена, обозначенное как ???. Это связано с тем, что канал 1РС$ не был
создан. Это следующее, что нужно сделать.
SMB: R negotiate, Dialect # = 7 • .
SMB: SMB Status = Error Success :;
SMB: Error class = No error
SMB: Error code = No error
SMB: Header: PID = OxCAFE TID = 0x0000 MID = 0x0000
UID = 0x0000
SMB:
SMB:
Tree ID
Process ID
SMB: User ID
SMB: Multiplex ID
(TID) = 0 @x0)
(PID) = 51966 (OxCAFE)
(UID) = 0 @x0)
(MID) = 0 @x0)
SMB: Flags Summary = 152 @x98)
SMB: flags2 Summary = 3 @x3) -
SMB: Command = С negotiate
SMB: Word count =17
SMB: Word parameters
SMB: Protocol Index = 7
+ SMB: Security Mode Summary (NT) = 3 @x3)

176 Глава б
SMB: Max MPX requests =50
SMB: Max VCs = 1 @x1)
SMB: NT Max Buffer Size = 4356 @x1104) .
SMB: Max Row Size = 65536 @x10000)
SMB: Session Key = 0
+ SMB: Capabilities = 17405 @x43FD)
SMB: Server Time = Aug 21, 1999 19:6:3.84
SMB: Server time zone = 240 (OxFO)
SMB: Encryption key length = 8 @x8)
SMB: Byte count = 18
SMB: Byte parameters
SMB.- Domain name = ???
Теперь нам необходимо создать соединение с общим ресурсом 1РС$. Это
используемый по умолчанию общий ресурс, созданный Windows NT (ино-
(иногда называемый одним из административных общих ресурсов) для межпро-
межпроцессной коммуникации. Он использует NetBIOS, и в этом случае NetBIOS
перемещается поверх TCP, перемещающегося, в свою очередь, поверх IP,
который перемещается поверх Ethernet. Этот кадр, содержащий 230 бай-
байтов, поступает в порт 139 службы сеанса NetBIOS. Этот кадр содержит две
команды SMB. Первая — С session service & X — используется для настройки
сеанса. Вторая — С tree connect & X — сообщает нам, что BDC желает соеди-
соединиться с общим ресурсом 1РС$. Этот раздел всегда сообщает имя файла, но
существуют другие флаги, означающие, что это в действительности не
файл, но просто способ, которым SMB ссылается на объекты в этой области.
SMB: С session setup & X, Username = , and C tree connect &
X, Share = \\PROX\IPC$
+ SMB: SMB Status = Error Success ¦-• -'.
+ SMB: Header: PID = OxCAFE TID = 0x0000 MID = 0x0000
UID = 0x0000
: ..¦-. SMB: Command = С session setup & X
SMB: Word count =13
SMB: Word parameters
SMB: Next offset = 0x0084
SMB: Max Buffer Size = 4356 @x1104) ••'
SMB: Max MPX requests =50 . .,
SMB: VC number =0 ¦ •
-¦ SMB: Session Key = 0 .
SMB: Password length = 1 @x1)
SMB: Unicode Password length = 0 @x0)
+ SMB: Capabilities = 212 @xD4)
SMB: Byte count =71
SMB: Byte parameters
SMB: Account name =
SMB: Domain name =
SMB: Native OS = Windows NT 13 81
SMB: Native Lanman = Windows NT 4.0
SMB: Command С tree connect & X
SMB: Word count = 4
SMB: Word paramters

Серверный трафик 177
¦ SMB: Next offset = 0x0000
" SMB: Discount flag = 0x0000
\'' '"'' SMB: Password length = 1 @x1) •' ¦ ' :
SMB: Byte count = 29 -- ¦.: . ¦ ;
' ¦¦¦¦¦''' . SMB: Byte paramters • ¦ ¦•_¦•¦ ¦ ¦
¦ :'• 'л ; SMB: Password = i .' " : .
.-¦¦ - SMB: File name = \\PROX\IPC$ . . :
SMB: Service Name = IPC
SMB: Command = No secondary command
Теперь мы подошли к ответу от PDC для BDC. Этот ответ, представлен-
представленный в распечатке ниже, сообщает, что мы соединились с общим ресурсом
1РС$. Мы видим, что ошибок нет (error success), и первой командой SMB яв-
является С session setup & X с именем домена MRED, который является на-
нашим доменом. Следующей командой является С tree connect 8c X для
службы имен IPC. Этот кадр имеет размер 194 байта. Таким образом, это
взаимодействие требует двух кадров и 424 байта для создания соединения с
общим ресурсом 1РС$.
+ SMB: SMB Status = Error Success
+ SMB: Header: PID = OxCAFE TID = Ox 7807 MID = 0x0000
UID = 0xC803
SMB: Command = С session setup & X
SMB: Word count = 3
SMB: Word parameters
SMB: Next offset = 0x0078
+ SMB: Setup action = 0x0000
SMB: Byte count =79
SMB: Byte parameters
SMB: Native OS = Windows NT 4.0
SMB: Native Lanman = NT LAN Manager 4.0
SMB: Domain name = MRED
SMB: Command = С tree connect & X
SMB: Word count = 3
SMB: Word parameters . .
SMB: Next offset = 0x0088
+ SMB: Optional Support = 1 @x1)
SMB: Byte count = 7
SMB: Byte parameters
SMB: Service Name = IPC
SMB: Native FS = L?i?? '
SMB: Command = No secondary command
Процесс создания сеанса с PDC потребовал девять кадров и использовал
около 1200 байтов трафика. Конечный шаг синхронизации базы данных
SAM состоит в создании защищенного канала с первичным контроллером
домена. Этот трафик будет происходить только во время инициализации
системы, так как защищенный канал всегда существует, если только одна из
машин не выключена. Это позволяет создавать новые сеансы, когда истека-
истекает срок действия, и сразу выполнять проверку и обновление, не требуя со-
создания нового защищенного канала. Все это сберегает сетевую полосу
пропускания и ускоряет время доступа.

178 Глава 6
Первый шаг в установлении защищенного канала с PDC состоит в созда-
создании запроса на открытие именованного канала с NetLogon, для некоторых
вызовов API (прикладного программного интерфейса) службы NetLogon.
Посмотрим на распечатку ниже. В этом кадре мы видим только одну команду
SMB — команду С NT create & X, направленную в файл \NetLogon. Флаги со-
сообщают тип требуемого доступа, и если этот файл не существует, то команда
откажет. Create Flags DWord 0x00000006 сообщает, что она запрашивает
одновременно Oplock и OpBatch.
SMB: С NT create & X, File = \NETLOGON '¦ ' ' : :' *: • '*''
+ SMB: SMB Status = Error Success
SMB: Header: PID = 0.0x5020 TID = 0x7807 MID = 0x0040
1 • UID = 0xC803
SMB: Tree ID (TID) = 30727 @x7807)
; t-, ... ", SMB: Process ID (PID) = 20512 @x5020) [
,..-...:--»----. SMB: User ID (UID) = 51203 @xC803)
SMB: Multiplex ID (MID) = 64 @x40) ' '
+ SMB: Flags Summary = 24 @x18)
+ SMB: flags2 Summary = 32771 @x8003)
SMB: Command = R NT create & X ¦ ,• ,:
SMB: Word count = 24 ' .-,:
SMB: Word parameters
SMB: Next offset = 0x0000
SMB: Word count =24
SMB: Word parameters
SMB: Name Length (NT) = 18 @x12)
SMB: Create Flags DWord = 0x00000006
SMB: Root Dir FID = 0x00000000
SMB: Desired Access = 0x0002019F
SMB: File Allocation Size = 0x0000000000000000
+ SMB: NT File Attributes = 0x00000000
SMB: File Share Access = 0x00000003
SMB: Create Disposition = Open: If exist, Open,
else fail
+ SMB: Create Options = 0 @x0)
SMB: Impersonation Level = 0x00000002
SMB: Security Flags = 0x01
SMB: 1 = dynamic tracking
SMB: 0. = effective only bit not set
SMB: Byte count = 21
SMB: File name = \NETLOGON - .:. ¦ ¦
Рассмотрим ответ PDC на предыдущий кадр. Прежде всего мы видим, что
состояние SMB говорит об отсутствии ошибок. Используется команда R NT
create & X, которая сообщает нам ответ. Отметим, что TID, PID, UID и MID
совпадают с предыдущим кадром. Интересный момент здесь состоит в том,
что в предыдущем кадре, хотя он запрашивает Oplock, текущий уровень
Oplock отсутствует. Мы видим также, что действие по созданию является
файлом, который был открыт. От�