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 отсутствует. Мы видим также, что действие по созданию является
файлом, который был открыт. Отметим также, что тип файла является
именованным каналом в режиме сообщения, который и предполагалось
увидеть.

Серверный трафик 179
SMB: R NT create & X, FID = 0x802
+ SMB: SMB Status = Error Success
SMB: Header: PID = 0x5020 TID = 0x7807 MID = 0x0040
UID = 0xC803
SMB: Tree ID (TID) = 30727 @x7807)
SMB: Process ID (PID) = 20512 @x5020)
SMB: User ID (UID) = 51203 @xC803)
SMB: Multiplex ID (MID) = 64 @x40)
+ SMB: Flags Summary = 152 @x98)
+ SMB: flags2 Summary = 32771 @x8003)
SMB: Command = R NT create & X ;
SMB: Word count =34
SMB: Word parameters
SMB: Next offset = 0x0067
SMB: Word count =34
SMB: Word parameters
SMB: Oplock Level = NONE
SMB: File ID (FID) = 2050 @x802)
SMB: File name = \NETLOGON
SMB: Create Action = File Opened
SMB: Creation Time = Jan 1, 1601 0:0:0.0
SMB: NT Last Access Time = Jan 1, 1601 0:0:0.0
SMB: Last Write Time = Jan 1, 1601 0:0:0.0
SMB: Change Time = Jan 1, 1601 0:0:0.0
+ SMB: NT File Attributes = 0x00000080
SMB: File Allocation Size = 0x0000000000001000
SMB: End of File = 0x0000000000000000
SMB: Device state 0x05FF
SMB: Boolean Is Directory = 0 @x0)
В двух предыдущих кадрах мы успешно создали именованный канал со
службой NetLogon, чтобы можно было сделать RPC (вызов удаленной про-
процедуры) вызовов API. Для этого потребуются два кадра и 323 байта. Теперь
необходимо создать соединение RPC между PDC и BDC. Это происходит с
помощью кадров RPC связывания и подтверждения связывания. Взгляните
на первый из этих двух кадров на распечатке ниже. Первый кадр будет ис-
использовать команду SMB С transact TransactNmPipe в файл NetLogon. Та-
Таким образом, в этом кадре теперь используются протоколы MSRPC
(удаленный вызов процедур Microsoft), SMB, TCP, IP и Ethernet. Распечатка
ниже создана из 214-байтового кадра. Это тип пакета связывания RPC, где
не задано никаких флагов. Параметры флагов раскрыты ниже, но обратите
внимание, что каждый имеет значение 0, указывая, что флаг не задейст-
задействован. Абстрактный интерфейс использует UUID (универсальный уникаль-
уникальный идентификатор), который является строкой уникальной идентифика-
идентификации, связанной с интерфейсом вызова удаленной процедуры. Он иногда
называется также GUID (глобальный уникальный идентификатор). В кадре
ниже UUID задан как 12345678-1234-ABCD-EF00- 01234567CFFB.
MSRPC: с/о RPC Bind: UUID 12345678-1234-ABCD-EF00-
01234567CFFB call 0x1 assoc grp 0x0 xmit 0x1630 recv 0x1630
MSRPC: Version = 5 @x5)

180 Глава б
MSRPC: Version (Minor) = 0 @x0) ¦ • ¦
MSRPC: Packet Type = Bind ' ' '
MSRPC: Flags 1=0 @x0)
MSRPC: 0 = Reserved -or- Not the first
fragmrnt (AES/DC)
MSRPC: 0. = Not a last fragment -or- No
cancel pending
MSRPC: 0.. = Not a fragment -or- No cancel
pending (AES/DC)
MSRPC: ....0... = Receiver to respond with a fack
PDU -or- Reserved (AES/DC)
MSRPC: ...0.... = Not used -or- Does not support
concurrent multiplexing (AES/DC)
MSRPC: ..0 = Not for an idempotent request
-or- Did not execute guaranteed call (Fault PDU only)
(AES/DC)
MSRPC: .0 = Not for a broadcast request -or-
"Maybe1 call semantics not requested (AES/DC)
MSRPC: 0 = Reserved -or- No object UUID
specified in the optional object field (AES/DC)
MSRPC: Packet Data Representation
MSRPC: Fragment Length = 72 @x48)
MSRPC: Authentication Length = 0 @x0)
MSRPC: Call Identifier = 1 @x1)
MSRPC: Max Trans Frag Size = 5680 @x1630)
MSRPC: Max Recv Frag Size = 5680 @x1630)
MSRPC: Assoc Group Identifier = 0 @x0)
MSRPC: Presentation Context List
MSRPC: Number of Context Elements = 1 @x1)
MSRPC: Presentation Context Identifier = 0 @x0)
MSRPC: Number of Transfer Syntaxs = 1 @x1)
MSRPC: Abstract Interface UUID = 12345678-1234-
ABCD-EF00-01234567CFFB
..¦ • . MSRPC: Abstract Interface Version = 1 @x1)
MSRPC: Transfer Interface UIID = 8A885D04-1CEB-
11C9-9FE8-08002B104860
MSRPC: Transfer Interface Version = 2 @x2)
Ответ приходит из PDC. Это кадр подтверждения связывания RPC, как
видно в распечатке ниже. В нем заданы два флага @x3). Это те же поля фла-
флагов, которые мы видели в кадре выше, и первая позиция сообщает нам, что
это первый фрагмент, а вторая позиция — что это последний фрагмент
@x3). Связанным идентификатором группы, который используется для от-
отслеживания, будет 106023 @х19Е27). Отметим, что UUID интерфейса пере-
передачи является таким же, как и в предыдущем кадре. Этот интерфейс RPC
используется для передачи команд туда и обратно. ;
MSRPC: с/о RPC Bind Ack: call 0x1 assoc grp 0xl9E27
xmit 0x1630 recv 0x1630
MSRPC: Version = 5 @x5) ' ' ''
MSRPC: Version (Minor) = 0 @x0)
MSRPC: Packet Type = Bind Ack
MSRPC: Flags 1=3 @x3)

Серверный трафик 181
: MSRPC: Packet Data Representation
.. ;.. MSRPC: Fragment Length = 68 @x44) , ... ¦;
MSRPC: Authentication Length = 0 @x0)
MSRPC: Call Identifier = 1 @x1)
MSRPC: Max Trans Frag Size = 5680 @x1630)
MSRPC: Max Recv Frag Size = 5680 @x1630)
MSRPC: Assoc Group Identifier = 106023 @xl9E27)
MSRPC: Secondary Address
MSRPC: Secondary Address Length = 12 (OxC)
MSRPC: Secondary Address Port ; :
MSRPC: Padding Byte(s)
MSRPC: Result List
MSRPC: Number of Results = 1 @x1)
MSRPC: Reserved = 0 @x0)
MSRPC: Reserved 2
MSRPC: Presentatuion Context Results
MSRPC: Result = Acceptance
MSRPC: Reason = Reason not specified
MSRPC: Transfer Syntax
MSRPC: Transfer Interface UUID = 8A885D04-
1CEB-11C9-9FE8-08002B104860
MSRPC: Transfer Interface Version = 2 @x2)
Теперь, когда соединение RPC между двумя контроллерами доменов со-
создано (с помощью двух кадров и 396 байтов), BDC должен создать защищен-
защищенный канал. Это будет сделано после проверки полномочий BDC. Для этого
потребуются четыре кадра. В распечатке ниже можно видеть, что резерв-
резервный контроллер домена посылает NetrServerReqChallenge, чтобы запро-
запросить проверку имени учетной записи BDC, которая существует на
первичном контроллере домена. Этот вызов NetrServerReqChallenge дела-
делается службе NetLogon с помощью RPC. Отметим также, что в разделе пол-
полномочий (credential) он сообщает Client-Challenge. Это указывает, что
запрос идет с клиентской машины.
R_LOGON: RPC Client call logon:NetrServerReqChallenge(..)
R_LOGON: LOGONSRV_HANDLE PrimaryName = WPROX
R_LOGON: wchar_t ComputerName = 2400
R_LOGON: PNETLOGON_CREDENTIAL ClientChallenge {..}
R_LOGON: CHAR data [..] = 9A 53 AC F4 00 FF B2 01
Ответ возвращается из PDC, как показано ниже. Мы по-прежнему испо-
используем в этом месте вызов NetrServerReqChallenge. Этот кадр приходит из
порта 139 на PDC и поступает в порт 1025 на BDC, как и все остальные кадры,
которые до сих пор рассматривались в этом разделе. Отметим, что раздел
полномочий содержит ServerChallenge, что указывает на сообщение с сер-
серверной машины.
R_LOGON: RPC Server response logon: NetrServerReqChallenge(..)
+ R_LOGON: PNETLOGON_CREDENTIAL ServerChallenge (..)
R_LOGON: Return Value = 0 @x0)

182 Глава 6
Теперь мы подошли к третьему кадру в этом обмене. BDC проверяет па-
пароль учетной записи на PDC, используя вызов API NetrServerAuthenticate2.
В распечатке ниже мы видим имя сервера регистрации \\prox и имя учет-
учетной записи 2400$. Знак $ в конце имени учетной записи указывает, что это
"скрытое" имя учетной записи, используемое прежде всего для администра-
административных целей. В данном случае это учетная запись, которая использовалась
для создания защищенного канала. Мы видим также имя компьютера 2400
и ClientCredential, это является указанием на то, что кадр с клиентской
машины. •
R_LOGON: RPC Client call logon: NetrServerAuthenticate2(..)
R_LOGON: LOGONSRV_HANDLE PrimaryName = WPROX
R_LOGON: wchar_t AccoutName = 2400$
R_LOGON: NETLOGON_SECURE_CHANNEL_TYPE AccountType = 6 @x6)
R_LOGON: wchar_t ComputerName = 2400
+ R_LOGON: PNETLOGON_CREDENTIAL ClientCredential {..}
R_LOGON: PULONG NegotiateFlags = 1073742335 @x400001FF)
Мы пришли к последнему кадру в этом разделе. Наконец, все сеансы и
защищенный канал созданы. Теперь мы имеет ответ сервера RPC. Он снова
использует вызов API NetrServerAuthenticate2. Отметим раздел полномо-
полномочий, который утверждает, что это ServerCredential, указывая на то, что он
прибыл с машины сервера. . : ¦ • =.• ., т¦•¦¦, .-, ..
R_LOGON: RPC Server response logon: NetServerAuthenticate2(..)
+ R_LOGON: PNETLOGON_CREDENTIAL ServerCredential {..}
R_LOGON: PULONG NegotiateFlags = 1073742335 @x400001FF)
R_LOGON: Return Value = 0 @x0)
Для создания защищенного канала требуются четыре кадра и 794 байта.
Теперь мы готовы проверить базу данных учетных записей пользователей.
Как было указано ранее, необходимо проверить три базы данных. Это база
данных учетных записей SAM, которая содержит учетные записи пользова-
пользователя и группы, созданные администратором; встроенная база данных SAM,
которая имеет стандартные группы и учетные записи NT; и секретная база
данных LSA, которая содержит пароли учетных записей компьютера, а так-
также пароли для доверительных отношений. Для каждой из этих баз данных
будет делаться клиентский вызов RPC, когда начнется процесс проверки
базы данных учетных записей пользователей. Каждый из этих клиентских
вызовов будет извлекать соответствующий ответ из PDC. Мы знаем, что с
этим процессом связано шесть кадров, но не знаем, сколько реального тра-
трафика будет создано, так как это зависит в некоторой степени от числа тре-
требуемых обменов. Если желательно рассмотреть эти кадры более подробно,
обратитесь к кадрам 59-64 в файле ВВС initizize.cap на сайте издательства
"ЛОРИ" (www.lory-press.ru)
Первый кадр содержит одну команду: NetrDatabaseDeltas. Конечно,
эта команда направлена в IP-адрес PDC в общеизвестный порт 139, свя-
связанный со службой сеанса NetBIOS. Мы по-прежнему начинаем на BDC
из порта 1025.

Серверный трафик 183
R_LOGON: RPC Client call logon:NetrDatabaseDeltas(..)
Второй кадр содержит ответ на вызов NetrDatabaseDeltas, который
был послан BDC. Этот кадр является ответом PDC для BDC, и он содер-
содержит все изменения, которые необходимо сделать в первой базе данных.
Эти изменения перечислены в последнем разделе кадра.
R_LOGON: RPC Server response logon:NetrDatabaseDeltas(..)
+ R_LOGON: PNETLOGON_AUTHENTICATOR ret_auth {..}
+ R_LOGON: PNLPR_MODIFIED_COUNT DomainModifiedCount {..}
R_LOGON: PNETLOGON_DELTA_ENUM_ARRAY DeltaArray {..}
R_LOGON: DWORD CountReturned = 1352648495
@x509FC72F)
R_LOGON: PNETLOGON_DELTA_ENUM Deltas = 3072610600
@xB72451128)
R_LOGON: PNETLOGON_DELTA_ENUM Deltas [..]
+ R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..}
+ R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..}
+ R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..}
+ R__LOGON: PNETLOGON_DELTA_ENUM Deltas {..} :
+ R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..}
+ R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..} '"
BDC снова посылает команду NetrDatabaseDeltas, чтобы начать процесс
верификации для второй базы данных.
R_LOGON: RPC Client call logon:NetrDatabaseDeltas(..) ' ¦¦¦¦'¦¦
Ответ приходит от PDC с изменениями, перечисленными ниже.
R_LOGON: RPC Server response logon:NetrDatabaseDeltas(..)
+ R_LOGON: PNETLOGON_AUTHENTICATOR ret_auth {..}
+ R_LOGON: PNLPR_MODIFIED_COUNT DomainModifiedCount {..} '
R_LOGON: PNETLOGON_DELTA_ENUM_ARRAY DeltaArray {..}
R_LOGON: DWORD CountReturned = 1607628464
@x5FD276B0)
R_LOGON: PNETLOGON_DELTA_ENUM Deltas = 3144190501
@xBB688A25)
R_LOGON: PNETLOGON_DELTA_ENUM Deltas [..]
+ R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..}
+ R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..}
+ R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..}'
+ R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..}
+ R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..} ., .
• + R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..} \
BDC посылает команду NetrDatabaseDeltas в третий раз.
R_LOGON: RPC Client call logon:NetrDatabaseDeltas(..)
Последний кадр в этом диалоге приходит из PDC в ответ на команду Ne-
NetrDatabaseDeltas. Каждый из разделов RJLogon имеет рядом с собой знак +, указы-
указывающий, что под заголовком находится дополнительная информация. Для
более подробного рассмотрения ее можно найти на сайте издательства
"ЛОРИ" (www.lory-press.ru).

184 '""" Глава 6
R_LOGON: RPC Server response logon:NetrDatabaseDeltas(..)
+ R_LOGON: PNETLOGON_AUTHENTICATOR ret_auth {..}
¦ ¦ + R_LOGON: PNLPR_MODIFIED_COUNT DomainModifiedCount {..}
R_LOGON: PNETLOGON_DELTA_ENUM_ARRAY DeltaArray {..}
R_LOGON: DWORD CountReturned =69777434 :
@x428B8lA)
R_LOGON: PNETLOGON_DELTA_ENUM Deltas = 3587951417
@xD5DBCB39)
R_LOGON: PNETLOGON_DELTA_ENUM Deltas [..]
+ R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..}
+ R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..}
+ R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..}
+ R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..}
+ R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..}
+ R_LOGON: PNETLOGON_DELTA_ENUM Deltas {..}
Здесь потребовалось шесть кадров и 1584 байта (включая заголовки
Ethernet) для проверки базы данных учетных записей пользователей. Эти
кадры включают очень немного, что приводит к весьма незначительной
синхронизации учетной записи. Если бы было много изменений, то могло бы
потребоваться больше шести кадров и было бы создано более 1584 байтов
трафика.
Обновления в базе данных
PDC по умолчанию будет проверять свою базу данных каждые пять ми-
минут. Если будут обнаружены изменения в любой из трех баз данных, то
он пошлет сообщение всем резервным контроллерам домена, указывая
изменение в SAM. PDC имеет таблицу каждого BDC, которая содержит
идентификатор версии каждой из его баз данных. Если BDC имеет актуа-
актуальную базу данных и не требуется никаких изменений, то она не будет
модифицироваться.
Windows NT 4.0 будет посылать объявление обновления одновременно
максимум десяти BDC, чтобы не перегружать полосу пропускания сети. Эту
величину можно, конечно, изменить для ситуаций, где полоса пропускания
не является проблемой. Преимущество управления обновлениями состоит
в сокращении использования полосы пропускания сети. Обратной стороной
этого будет увеличение времени для изменения всех BDC.
Как можно видеть на распечатке ниже, PDC выполняет команду "Announce
Change to UAS or SAM". Отметим, что кадр включает имя PDC и имя доме-
домена. Он содержит также порядковый номер, используемый для сравнения
версий базы данных. Этот кадр посылается из PDC прямо в BDC. Это не
широковещательный кадр; он посылается в порт UDP 138, который являет-
является портом службы дейтаграмм NetBIOS. Это дейтаграмма, направленная
в \mailslot\net\NetLogon.
NETLOGON: Announce Change to UAS or SAM
NETLOGON: Opcode = Announce Change to UAS or SAM
NETLOGON: Low Serial Number = 210 @xD2)
NETLOGON: Data and Time = 909938475 @x363C8F2B)

Серверный трафик
185
NETLOGON:
NETLOGON:
NETLOGON:
NETLOGON:
NETLOGON:
NETLOGON:
NETLOGON:
+ NETLOGON:
+ NETLOGON:
+ NETLOGON:
NETLOGON:
NETLOGON:
00 00 5D 5B 3F
NETLOGON:
¦(
Pulse = 7200 @xlC20) : .<( 7,v,.-,
Random = 1 @x1) ''" r'- ¦ ¦ "ч
Primary DC Name = PROX ; . .
Domain Name = MRED
Unicode Primary DC Name = PROX
Unicode Domain Name = MRED
DB Count = 3 @x3)
DBChange Info Structure, DB Info = 0x0000
DBChange Info Structure, DB Info = 0x0001
DBChange Info Structure, DB Info = 0x0002
Domain SID Size = 24 @x18)
Domain SID = 01 04 00 00 00 00 00 05 15 00
41 El 24 ЗС ЗА c7 . . .
NT Version = 1 @x1)
В таблице 6.1 содержится оставшаяся часть общения, требуемая для об-
обновления базы данных. Отметим, что вслед за кадром объявления PDC мы
видим такие же вещи, которые были подробно рассмотрены ранее в этой
главе. BDC делает соединение именованным каналом с NetLogon, создает
сеанс RPC и затем обновляет базу данных, используя RPC для вызова API
NetrDatabaseDeltas. После обновления базы данных она использует SMB
для разъединения и выхода из системы.
Таблица 6.1. Последовательность периодических обновлений контроллера домена
Источник
Ргох
2400
Ргох
2400
Ргох
2400
Ргох
2400
2400
Ргох
2400
Ргох
Место
назначения
2400
Ргох
2400
Ргох
2400 '
Ргох
2400
Ргох
Ргох
2400
Ргох ;
2400
Протокол
NETLOGON
SMB
SMB
MSRPC
MSRPC
R_LOGON
R_LOGON
TCP
SMB
SMB
SMB
SMB
Описание
Announce Change to UAS or SAM
С NT Create & X, File = \NETLOGON
R NT create & X, FID = Ox 100a
c/o RPC Bind: UUID
12345678-1234-ABCDEF00-01234567C
FFB call 0x1 assoc grp 0x0 xm
c/o RPC Bind Ack: call 0x1 assoc grp
0x2A0A2 xmit 0x1630 recv 0x1630
RPC Client call logon:NetrDatabase-
Deltas(..)
RPC Server response logon:NetrData-
baseDeltas(..)
.A...., len: 0; seq: 15861295-15861295,
ack: 235568, win: 8760, src: 1072 dst: 139
С tree disconnect
R tree disconnect ..¦¦¦'.
Clogoff&X
R logoff &X

186 Глава б
Оптимизация трафика синхронизации учетных записей
Можно сделать кое-что для оптимизации трафика синхронизации учетных
записей пользователей в базах данных. Эта оптимизация включает редакти-
редактирование реестра и настройку параметров, связанных со службой NetLogon.
В обычном реестре эти ключи даже не присутствуют — они должны быть
добавлены вручную. На рис. 6.2 показан контроллер домена, в котором до-
добавлены эти дополнительные параметры для ключа NetLogon. Как мож-
можно видеть внизу рисунка, эти параметры расположены в HKEY_LOCAL_
MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\parameters.
На сайте издательства "ЛОРИ" (www.lory-press.ru) находятся эти записи,
сохраненные как файл с расширением .REG. Делая по нему двойной щел-
щелчок мышью, можно внести их в реестр на используемой машине, однако,
НЕ делайте это добавление на рабочей машине. Также убедитесь, что ис-
исходный реестр сохранен, прежде чем делать какие-либо изменения. По
крайней мере, сохраните этот ключ, прежде чем делать изменение. Преж-
Прежде чем реализовывать, необходимо рассмотреть каждое из этих значений с
его достоинствами и недостатками. Кроме того, НЕОБХОДИМО знать, ка-
каким будет влияние каждого из них, прежде чем они будут добавлены. Когда
они будут добавлены, нужно перезагрузить машину.
Служба NetLogon H s , ^n^f, лл: ;; v;
Служба NetLogon используется для синхронизации базы данных учетных
записей пользователей между BDC и PDC. Помимо этой функции, NetLogon
выполняет также и другие функции. Они перечислены ниже.
1. NetLogon обеспечивает для пользователей проверку регистрации.
2. NetLogon предоставляет поддержку для доверительных отношений
между доменами.
3. NetLogon обеспечивает членство компьютеров в домене.
Очевидно, что если служба NetLogon отказывает, то ничего из выше-
вышеприведенного не произойдет. Давайте посмотрим на некоторые записи ре-
реестра, которые могут оптимизировать службу NetLogon и сократить часть
трафика, рассмотренного в этой главе. Каждую из этих записей можно
увидеть на рис. 6.2. Они расположены в ключе \NetLogon\parameters.
ChangeLogSize используется для определения размера журнала измене-
изменений в байтах. Так как журнал изменений находится как в памяти, так и на
жестком диске (\\winnt\netlogon.chg), то при увеличении размера будет
использоваться больше памяти и дискового пространства. Но если ресурсы
на PDC настолько ограничены, то модернизация требуется в любом случае.
По умолчанию используется 64 Кбайта, что является также минимальным
допустимым значением. Этого достаточно приблизительно для 2000 изме-
изменений (изменение требует примерно 32 байта), что может показаться до-
достаточно большой величиной, если не рассматривать всех паролей,
паролей учетных записей машины, прав, разрешений, членства в группах,
новых членов и т.п. В большой организации это количество может быстро

Серверный трафик
187
Reoiiliy tdito!
fiegislry Edit
' r
\
¦ j
\ j
i
: i
: |
I
i
i
View Help
?fl О N<taWin2
Ш ?l NdaWan?
Ш ?] NalSIOS
ffi О NatBIOSInfoiMlun
ffl S3 NacDDEd«b
Й (Si NaDogon
i ;-¦ (Si Enum
! :- ?j Sectrty ^ 1
Й C3 «negert
a) CJ NnipSvc . ¦ ,|
2 Cl Nph
S) О Nil»
s> Cl p«*i -V
a Cl PDOunp Jd
! лГ
Name
!JDGFl4
^{ PulieConcursncy
OPuiteM«x>r»m
Pii3«Tineout1
i Data
lvalue not tel)
ОЛО40ОО0О D134304)
OxOOOOOOOOlO)
0>«OOO«!013603)
0«000(ХШП5)
0<00015180186400)
0x00000073112I
o«oaooo2S3i60o)
OnO0OO0OS4AO0|
4e 45 54 4d 414*0000
-no-
.My C«-jJ«WKTt'.l.OCAl..MACHlNE\SYSTEK\Cwi«vC-W;cfiel .<
Рис. 6.2. Служба NetLogon управляется с помощью дополнений в реестре
исчерпаться, приводя к тому, что новые записи станут перезаписывать еще
не синхронизированные изменения. При этом запускается полная синхро-
синхронизация, создавая ненужный трафик.
Это одно из самых безопасных изменений, которое можно сделать для
службы NetLogon. Максимальное значение равно 4194304 D мегабайта),
что будет поддерживать 131072 изменения в журнале. Это не ухудшит про-
производительность контроллера домена. Увеличение размера сократит число
полных синхронизации с BDC. Другая причина для увеличения этого числа
возникнет в том случае, когда ожидается, что BDC не синхронизируется
с PDC с помощью выделенных 2000 изменений.
DisablePasswordChange по умолчанию равно 0. Это означает, что пароль
учетной записи машины должен изменяться каждые три дня и синхронизиро-
синхронизироваться с одним из PDC. Если машина Windows NT не получает доступа к PDC
после изменения пароля, то PDC будет кэшировать существующий пароль
для следующих трех дней. Через шесть дней, когда компьютер Windows NT
попытается аутентифицировать учетную запись машины, пароль не будет
совпадать с паролем в базе данных системы безопасности. Это не должно
меняться, если только не будут полностью оценены последствия такого
изменения. Пароль учетной записи машины используется для защиты
против подделки учетной записи компьютера и является поэтому составной
частью системы безопасности NT.

188 Глава 6
Pulse используется для контроля частоты, с которой PDC будет просматри-
просматривать изменения в базе данных служб каталогов и посылать сообщения "anno-
"announce change to UAS or SAM" для BDC о том, что требуется обновление. По
умолчанию используется значение pulse равное 300 секундам E минутам); оно
может, однако, принимать максимальное значение 17200 секунд D8 часов).
Служба NetLogon собирает изменения SAM и LSA, сделанные во время перио-
периода pulse, и посылает сообщение "announce change to UAS or SAM" тем BDC, ко-
которым необходимы изменения. Когда служба NetLogon запускается впервые,
PDC посылает pulse каждому BDC с учетной записью машины. Кроме того,
по достижении значения PulseMaximum PDC будет посылать pulse всем
BDC, несмотря на то, нуждаются они в каких-либо изменениях или нет.
В среде, где сетевой трафик следует всемерно экономить, использова-
использование pulse каждые пять минут является лишним. Однако изменение этого
значения на два дня будет чрезмерным, за исключением очень устойчивых
сред. Если увеличить это значение до 172800 секунд, возникает риск исте-
истечения срока действия пароля учетной записи машины. Конечно, можно за-
задать ключ DisablePasswordChange, но это риск для системы безопасности, с
которым большинство людей не согласятся. Если задать это значение
слишком большим, это может привести к полной синхронизации и возник-
возникновению трафика, которого пытались избежать. Задание pulse около значе-
значения 3600 (один час) или даже 7200 (два часа) приводит к соответствующему
сокращению трафика относительно безопасным образом. BDC удаленного
офиса можно даже увеличить до 86400 секунд (один день).
PulseConcurrency используется для управления количеством импульсов
(pulses), которые будут одновременно посылаться BDC. То есть он управляет
количеством BDC, контактирующих одновременно с PDC для проверки базы
данных. Если PDC посылает одновременно 10 импульсов (значение по умол-
умолчанию для Windows NT 4.0), то одновременно могут соединиться 10 BDC
для обновления своей базы данных каталогов. Проблема здесь с полосой
пропускания сети и с возможностью PDC обработать множество одновре-
одновременных RPC, не создавая чрезмерной нагрузки на машину.
Обычно это значение можно увеличивать, не создавая больших проб-
проблем. Конечно, если имеются только три или четыре BDC, то можно сокра-
сократить это число и освободить некоторые ресурсы на сервере. Увеличение
PulseConcurrency будет увеличивать нагрузку на PDC, но обычно современные
серверы легко справляются с такой нагрузкой. Уменьшение PulseConcurrency
увеличит время, которое потребуется домену для распространения всех
изменений SAM и LSA на BDC. В большом домене можно сократить это до
такой степени, что домен никогда не будет синхронизирован.
PulseMaximum используется для управления частотой, с которой PDC
будет посылать сообщения pulse своим BDC, даже если базы данных явля-
являются актуальными. По умолчанию используется 7200 секунд (два часа), а
максимальное значение PulseMaximum равно 172800 секундам (два дня).
Это значение можно задавать для гарантии, что PDC не всегда контактиру-
контактирует с BDC при изменениях. Если PulseMaximum задан как максимум в два
дня, возникает риск истечения срока действия пароля учетной записи. За-
Задание его как один день выглядит достаточно безопасным для сети с боль-
большим числом BDC в удаленных WAN.

Серверный трафик 189
PulseTimeoutl контролирует время ожидания PDC ответа от BDC, когда
было послано сообщение "announce change to UAS or SAM". Если BDC не
отвечает в течение этого периода, то он считается не реагирующим. Не ре-
реагирующий BDC не учитывается числом PulseConcurrency, что позволит
соединиться дополнительному BDC. Он сможет затем обновить изменения
в базе данных, если кто-то превысит предел PulseTimeoutl. Если, однако,
значение PulseConcurrency было увеличено, чтобы включить все BDC, то
это не будет иметь никакого значения. По умолчанию на ответ на сообщение
pulse дается 10 секунд.
В WAN с медленными каналами связи значение по умолчанию Pulse-
PulseTimeoutl может вызвать проблему, поэтому оно должно быть увеличено до
максимума в 120 секунд. Прежде чем делать это, необходимо рассмотреть
следующие вопросы. Если имеется большое число BDC, которые необходи-
необходимо синхронизировать, и PDC должен ждать по две минуты, чтобы объявить
каждый из них не реагирующим, то потребуется очень много времени, что-
чтобы закончить частичную синхронизацию. Если число задано слишком мале-
маленьким (минимум равен одной секунде), то PDC может считать BDC не
реагирующим, когда фактически это не так. Это приведет к возрастанию
нагрузки на PDC, когда BDC, наконец, ответит и начнет процесс частичной
синхронизации.
PulseTimeout2 определяет время, в течение которого PDC будет ожи-
ожидать, пока BDC завершит частичную репликацию после ответа на сообще-
сообщение "announce change to UAS or SAM" от PDC. Если число изменений
возрастает (например, в связи с изменениями ChangeLogSize), то BDC бу-
будет считаться не реагирующим, пока не продолжит контактировать с PDC
для получения дополнительных изменений. По умолчанию используется
300 секунд. Это означает, что когда BDC контактирует с PDC, ему дается до-
дополнительно пять минут, чтобы снова вступить в контакт, иначе он счита-
считается не реагирующим.
Если значение PulseTimeout2 задано слишком большим (максимум
3600 секунд), то медленный BDC будет занимать один из слотов PulseCon-
PulseConcurrency в течение длительного времени (два часа), увеличивая тем самым
время выполнения частичной синхронизации. Если это значение слиш-
слишком маленькое (минимум равен 60 секундам), то нагрузка на PDC будет
увеличиваться в связи с большим числом BDC, выполняющих частичные
синхронизации.
ReplicationGoverner применяется для управления долей полосы пропу-
пропускания, которую может использовать служба NetLogon, при выполнении
проверки базы данных. По умолчанию используется значение 100 процен-
процентов сетевой полосы пропускания при использовании буфера размером
128 Кбайт данных. Это легко может поглотить весь канал на медленной
линии связи между удаленными сайтами WAN. Задавая этот ключ как 50 про-
процентов, тем самым изменяют две вещи. Теперь служба NetLogon будет обла-
обладать буфером в 64 Кбайта данных и иметь для сообщений синхронизации
50 процентов полосы пропускания.

190 Глава 6
Это значение не должно задаваться меньше 25, иначе синхронизация
может никогда не закончиться. Однако можно использовать команду AT
планировщика команд, чтобы задавать для этого параметра различные зна-
значения в течение дня. Например, можно задавать ReplicationGaverner рав-
равным 25 днем и равным 100 ночью. Конечно, это следует делать на каждом
BDC, но проблема невелика.' 땦>• ¦ : ч. . т.н:/ ¦ -
Обзор главы
В этой главе был рассмотрен серверный трафик. Начав с подробного ана-
анализа трафика DNS, мы увидели, как DNS преобразует адрес, выполняет
рекурсивный поиск и соединяется с WINS.
Вслед за обсуждением DNS была рассмотрена инициализация BDC. В
этом разделе мы исследовали, как BDC находит PDC и обновляет свою базу
данных. Были изучены некоторые настройки реестра для оптимизации
трафика синхронизации учетных записей, а также способы оптимизации
службы NetLogon. ;"' '; ¦¦•¦¦'• '*•'»¦ .->., ^ >.-.:>..•.<
В следующей главе
тмч
В следующей главе обратимся к трафику приложений. Будет рассмотрен
трафик файлов и печати, квитирование TCP и трафик просмотра Интернета,
а также почта Интернета. , ..
'¦•;/¦ ХМ'
'"' ¦ 7HV"
¦¦¦MV1 ¦• ¦ : ¦:.' •:.¦.! •

Глава 7
"! I.;,.1 У: :,. ':<^..-; '" i dr. : :ч,;Ц :-.«: UUvj. .г
Трафик приложений
Трафик, связанный с приложениями, является темой этой главы. Существу-
Существует так много различных видов приложений, что было бы невозможно рас-
рассмотреть их все в рамках одной главы, поэтому материал носит характер
обзора. Мы собираемся предложить несколько полезных идей, которые
помогут вам справиться со сложными реальными проблемами.
Работа с файлами и печать
Когда на сервере открывается файл или документ посылается на сетевой
принтер, создается сеанс между клиентской машиной и сервером. Трафик,
связанный с созданием этого сеанса, небольшой, и мало что можно сде-
сделать, чтобы его оптимизировать. Как в большинстве транзакций, прежде
всего необходимо найти машину. Это может вовлечь WINS, широковещание
и ARP. Рассмотрим этот трафик на распечатке ниже. ¦ ¦¦ '-
Запрос WINS ¦¦- *¦¦¦¦¦г>*
Это стандартный запрос WINS. Он направляется в порт UDP 137, который
является портом службы имен NetBIOS. Имя запроса находится там, где
присутствует ED1750. Отметим, что счетчик запросов задан как 1, указывая,
ЧТО ЭТО кадр запроса. -:,ii,-,i:w ;»i<> '¦. •: ¦->. ¦¦¦•. ., (, -i. !!¦!¦¦;... << .¦;..!;•/'
+ UDP: Src Port: NETBIOS Name Service, A37); Dst Port: "'
NETBIOS Name Service A37); Length = 58 (ОхЗА) J-' '
NBT: NS: Query req. for ED1750 • ¦¦>¦¦•¦¦ ¦ ' ::
NBT: Trnsaction ID = 33696 (Ox83A0) :
+ NBT: Flags Summary = 0x0100 - Req.; Query; 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 = ED1750

192 Глава 7
NBT: Question Type = General Name Service
NBT: Question Class = Internet Class '•¦¦--
Приведенный выше запрос повторяется три раза, прежде чем клиентская
машина перестанет запрашивать WINS и обратится к широковещанию.
Широковещание
В широковещательном кадре ниже мы видим, что он направляется в адрес
10.255.255.255, который является сетевым адресом широковещания для
этой подсети. Остальная часть пакета выглядит как запрос WINS. Он
по-прежнему адресуется в порт службы имен NetBIOS и содержит тот же
запрос для машины ED1750.
IP: ID = 0хб02С; Proto = UDP; Len: 78
IP: Version = 4 @x4)
IP: Header Length = 20 @x14)
+ IP: Service Type = 0 @x0)
IP: Total Lengh = 78 @x4E)
' IP: Identification = 24620 @x602C)
+ IP: Flags Summary = 0 @x0)
'.'•''.'..¦. IP: Fragment Offset = 0 @x0) bytes '¦'••;¦ ; • :
!'1'Л";:-'|К ' IP: Time to Live = 128 @x80) ¦¦[ ' :' '¦ ""'
''-¦¦'•''¦¦'- '¦-¦'¦ '¦ IP: Protocol = UDP - User Datagram '¦.»..•. •<'¦•'.
¦, . IP: Checksum = 0xC538 \.'. ¦ ;
IP: Source Address 10.0.0.60
IP: Destination Address = 10.255.255.255
IP: Data: Number of data bytes remaining = 58 @x003A)
+ UDP: Src Port: NETBIOS Name Service, A37); Dst Port:
NETBIOS Name Service A37); Length = 58 (ОхЗА)
NBT: NS: Query req. for ED 1750
- > iil; NBT: Transaction ID = 33696 @x83A0) ' • ¦<¦ '
¦•¦•< '•... + NBT: Flags Summary = 0x0110 - Req.; Query; Success
:¦ :;..-. NBT: Question Count = 1 @x1)
NBT: Answer Count = 0 @x0) , • . ¦ .. ¦ -,
NBT: Name Service Count = 0 @x0)
NBT: Additional Record Count = 0 @x0) .'',.',V >; ¦
NBT: Question Name = ED1750
' '¦ '' NBT: Question Type = General Name Service ; '
NBT: Question Class = Internet Class , ;¦;•.<•¦
Когда был сделан широковещательный запрос, искомая машина слышит
запрос NBT для ED1750 и отвечает клиентской машине. Это будет направ-
направленная дейтограмма UDP, а не широковещательный кадр. Он идет непо-
непосредственно запрашивающей машине в порт 137 с IP-адресом машины в
поле ответа.
IP: ID = 0x7530; Proto = UDP; Len: 90
IP: Version = 4 @x4)
IP: Header Length = 20 @x14)
+ IP: Service Type = 0 @x0)
IP: Total Length = 90 @x5A)

Трафик приложений
193
IP: Identification = 30000 @x7530)
+ IP: Flags Summary = 0 @x0)
IP: Fragment Offset = 0 @x0) bytes
IP: Time to Live = 128 @x80)
IP: Protocol = UDP - User Datagram . ,r
IP: Checksum = ОхВОСЗ
IP: Source Address =10.0.0.100
IP: Destination Address = 10.0.0.60
IP: Data: Number of data bytes remaining = 70 @x0046)
+ UDP: Src Port: NETBIOS Name Service, A37); Dst Port:
NETBIOS Name Service A37); Length = 70 @x46)
NBT: NS: Query (Node Status) resp. for ED1750, Success
NBT: Transaction ID = 33696 @x83A0)
+ NBT: Flags Summary = 0x8500 - Resp.; Query; 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 = ED17 50
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: Owner IP Address = 10.0.0.100
Когда клиентская машина получит IP-адрес от искомого компьютера,
следующий шаг состоит в преобразовании IP-адреса в аппаратный адрес.
ARP
Чтобы преобразовать IP-адрес в аппаратный адрес, будет использоваться
протокол ARP, как показано на распечатке ниже. Отметим, что указанный
искомый аппаратный адрес состоит полностью из нулей, поскольку в данный
момент клиентская машина не знает, каким является адрес MAC. Opcode,
равный 1, указывает, что это запрос ARP.
ARP_RARP: ARP:
ARP_RARP:
ARP_RARP:
ARP_RARP:
ARP_RARP:
ARP_RARP:
ARP_RARP:
ARP_RARP:
ARP_RARP:
ARP RARP:
Request, Target IP: 10.0.0.100
Hardware Address Space = 1 @x1)
Protocol Address Space = 2048 @x800)
Hardware Address Length = 6 @x6)
Protocol Address Length = 4 @x4)
Opcode = 1 @x1)
Sender's Hardware Address = 00902764FEBF
Sender's Protocol Address = 10.0.0.60
Target's Hardware Address = 000000000000
Target's Protocol Address = 10.0.0.100
Ответ приходит из искомой машины, как показано ниже. При получении
запроса ARP искомая машина отвечает с вписанным аппаратным адресом.
Это не широковещательный кадр. Это кадр, специально направленный
на адрес MAC запрашивающий машины.

194
Глава 7
ARP_RARP: ARP:
00902764FEBF
ARP_RARP:
ARP_RARP:
ARP_RARP:
ARP_RARP:
ARP_RARP:
ARP_RARP:
ARP_RARP:
ARP_RARP:
ARP_RARP:
ARP RARP:
Reply, Target IP: 10.0.0.100 Target Hdwr Addr:
Hardware Address Space = 1 @x1)
Protocol Address Space = 2048 @x800)
Hardware Address Length = 6 @x6)
Protocol Address Length = 4 @x4)
Opcode = 2 @x2)
Sender's Hardware Address = 00609788CF96
Sender's Protocol Address = 10.0.0.100
Target's Hardware Address = 00902764FEBF
Target's Protocol Address = 10.0.0.60
Frame Padding -¦-¦•¦ ¦ ¦ ¦•
Потребовалось семь кадров и 547 байтов для нахождения IP-адреса и ад-
адреса MAC искомой машины. Если бы использовался WINS, то можно было
бы сократить этот трафик на несколько кадров. Если бы существовали файлы
LMHOSTS, то трафик можно было бы сократить еще больше.
Трехходовое квитирование
Следующим шагом является создание сеанса TCP. Это влечет за собой трех-
трехходовое квитирование, которое создаст еще 172 байта трафика. Первый из
этих кадров приходит с клиентской машины. Отметим, что флаги заданы
как S @x02), чтобы синхронизировать номера.
аск: 0, win:
Session Service
@x28BD70A)
@x0)
.1.>Г I.'.i
TCP: S., len: 4, seq: 42718986-42718989,
8192, src: 1164 dst: 139 (NBT Session)
TCP: Source Port = 0x048C
TCP: Destination Port = NETBIOS
TCP: Sequence Number = 42718986
TCP: Acknowledgement Number = 0
''• •¦•¦'"¦¦ TCP: Data Offset = 24 @x18)
•¦¦'¦ TCP: Reserved: 0 @x0000) •
+ TCP: Flags = 0x02 : S. "
¦ • • ¦ ' TCP: Window = 8192 @x2000)
TCP: Checksum = 0x84DA '>¦ > . :¦¦! ir.r.i. .} ¦:.'::> ¦
TCP: Urgent Pointer = 0 @x0)
+ TCP: Options " ""'"'• ' '
Ответ на этот кадр приходит с искомой машины. Он имеет два флага
@x12), А и S. Флаг А говорит, что поле подтверждения значимо и подтвер-
подтверждает последнюю передачу. Кроме того, флаг S говорит, что передается
порядковый номер.
TCP: .A..S., len: 4, seq: 141140299-141140302, ack:
42718987, win: 8760, src: 139 (NBT Session) dst: 1164
TCP: Source Port = NETBIOS Session Service
TCP: Destination Port = 0x048C
; •¦'¦'¦'"¦ TCP: Sequence Number = 141140299 @x869A14B) ' ;
-':'-. ... TCP: Acknowledgement Number = 42718987 @x28BD70B) ¦
:,: ;. . .,. TCP: Data Offset = 24 @x18) . ¦
TCP: Reserved: 0 @x0000)

Трафик приложений 195
+ TCP: Flags = 0x12 : .A..S.
TCP: Window = 8760 @x2238) ¦"
... ..,,.. TCP: Checksum = 0xD8DC ..;)-•:&;.- ,-¦>;„. - . . !
.vtr. TCP: Urgent Pointer = 0 @x0), ч,-. * ., .,. .,. . ,
+ TCP: Options м--*'-»--- ¦¦•¦' ¦ ,-• ' •¦• ¦.¦•¦-..¦
TCP: Frame Padding
Третий кадр в трехходовом квитировании содержит флаг А @x10), сооб-
сообщающий, что поле подтверждения значимо. Оно подтверждает порядковый
номер. Теперь сеанс TCP создан.
TCP: .А , len: 0, seq: 42718987-42718987, ack:
141140300, win: 8760, src: 1164 dst: 139 (NBT Session)
TCP: Source Port = 0x048C
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 42718987 @x28BD70B)
TCP: Acknowledgement Number = 141140299 @x869A14C)
TCP: Data Offset = 20 @x14)
'. ;1 • TCP: Reserved: 0 @x0000) . ,, ,, A , , . ...
•''¦'¦• + TCP: Flags = 0x10 : .A. . . . ' ' : ' lf ¦ ' т" д '; :<
TCP: Window = 8760 @x2238) :l': " ' '"' '''"' :'ч'"ь;' '"¦ '
TCP: Checksum = 0xF099
TCP: Urgent Pointer = 0 @x0)
Сеанс NetBIOS
Когда сеанс TCP создан, следующий шаг состоит в создании сеанса NetBIOS.
Сеанс должен быть создан между двумя машинами, прежде чем начнет про-
происходить какая-либо дальнейшая коммуникация. Для этого потребуется два
кадра и 186 байтов. Важный момент здесь состоит в том, что вызываемое
имя и вызывающее имя являются правильными. ; ¦,-....¦
NBT: SS: Session Request, Dest: ED1750 ''¦''" , Source
2400 <00> Len: 68 :
&l NBT: Packet Type = Session Request ¦• .......
+ NBT: Packet Flags = 0 @x0) . ¦¦¦:....••¦
NBT: Packet Length = 68 @x44) .. . ..- • .-•:.•¦ >
NBT: Called Name = ED1750
NBT: Calling Name = 2400 <00> . .
Второй кадр меньше размером и идет прямо на клиентскую машину.
Чтобы был создан сеанс NetBIOS, тип пакета должен сообщать, что это
положительный ответ сеанса.
:.. NBT: SS: Positive Session Response, Len: 0 :
NBT: Packet Type = Positive Session Response
+ NBT: Packet Flags = 0 @x0)
NBT: Packet Length = 0 @x0) ' .
NBT: Frame Padding

Глава 7
Согласование диалекта SMB
Теперь, после создания сеанса TCP и сеанса NetBIOS, задача состоит в со-
согласовании диалекта SMB. Два компьютера выберут самый высокий уро-
уровень диалекта, который понятен обеим машинам. В примере ниже самым
старшим высоким диалектом является NT LM 0.12, и мы видим команду
SMB "С negotiate".
: if SMB: С negitiate, 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: Command = С negotiate
Ответ с серверной машины сообщает, что статус успешный и имеется от-
ответ SMB на команду согласования. Кроме того, сервер поддерживает прото-
протокол SMB NT LM 0.12, указанный позицией в первом сообщении с номером 7.
Эти два кадра требуют в сети 371 байт.
SMB: R negotiate, Dialect # = 7
SMB: SMB Status = Error Success
SMB: Error class = No error ,Л .,., . ._ ( ..
SMB: Error code = No error .<.«:»< -,'•< ,\n$J
+ SMB: Header: PID = OxCAFE TID = 0x0000 MID = 0x0000
UID = 0x0000
+ SMB: Command = С negotiate J.^ . . . M
После согласования диалекта SMB возникает реальное соединение с об-
общим сетевым каталогом. Когда происходит соединение, каталог общего ре-
ресурса или диска копируется по сети на клиентскую машину. Однако прежде
чем это произойдет, нам необходимо согласовать соединение с реальным
ресурсом. В этом месте два компьютера будет проверять безопасность. Да-
Давайте посмотрим, как это происходит. Клиентская машина использует
команду SMB "session setup & X" для настройки сеанса SMB. В этом кадре мы
видим имя учетной записи и имя домена, указанные в качестве полномо-
полномочий, которые передаются на серверную машину. В данном случае это поль-
пользователь с именем ed из домена MRED. Мы видим также, что это машина
Lanman Windows NT 4.0. Так как это развитая версия диалекта SMB, она мо-
может обрабатывать несколько команд в одном кадре. Поэтому второй коман-
командой SMB является "С tree connect & X". Она используется для создания
соединения с общим ресурсом, которым в данном случае является общий
ресурс 1РС$ на машине BIGGUY (рабочая станция Windows 98).
SMB: С session setup & X, Username = ed, and С tree connect
& X, Share = \\BIGGUY\IPC$
+ SMB: SMB Status = Error Success
+ SMB: Header: PID = OxCAFE TID = 0x0000 MID = 0x0000
UID = 0x0000
SMB: Command = С session setup & X

Трафик приложений 197
SMB: Word count = 13 ¦ ''-¦'¦ *
SMB: Word parameters 7 -i-Л '
SMB: Next offset = 0x0096
SMB: Max Buffer Size = 2920 @xB68)
SMB: Max MPX requests = 2
SMB: VC number = 0
• ¦ ¦•'V->-- ¦¦' SMB: Session Key = -2147483587 ¦'¦ ;'^':-!" >i;!
; ;''¦'¦"• ; SMB: Password length = 24 @x18) ;:v
¦ SMB: Unicode Password length = 24 @x18) ''>**'¦ '
¦¦¦ ¦¦. + SMB: Capabilities = 212 @xD4) - ¦ ¦¦¦ ¦¦• >- ¦ : Л
¦¦; SMB: Byte count = 89 . .; ;
SMB: Byte parameters •;<». •;;•, _ у .•¦ .• ...
SMB: Account name = ed , ¦>¦ . ( ( ,, .. ls... ; ..•.;,
. , SMB: Domain name = MRED . • ( ,,;, ..j,!.-; ,-•
SMB: Native OS = Windows NT 1381 " .", , './ ¦'
SMB: Native Lanman = Windows NT 4.0
SMB: Command = С tree connect & X ¦• ; ; .
SMB: Word count =4 •
SMB: Word parameters •¦¦ : -.-. .;..
SMB: Next offset = 0x0000
SMB: Disconnect flag = 0x0000
SMB: Password length = 1 @x1)
SMB: Byte count =19 :
SMB: Byte parameters - , ,.t.:: .-Л';
SMB: Password = -.'.'•¦
SMB: File name = \\BIGGUY\IPC$
SMB: Service Name = IPC :<;
SMB: Command = No secondary command
Рассмотрим ответ на команду "С session setup & X". В этом кадре мы
смотрим прежде всего на состояние SMB, указывающее на отсутствие оши-
ошибок (error success). Мы хотим также дважды проверить полномочия, кото-
которые используются для создания этого сеанса, и возможности данного
сеанса. ¦ . ¦ ;•< • =¦¦
SMB: С session setup & X, Username = ed
+ SMB: SMB Status = Error Success
+ SMB: Header: PID = 0x0000 TID = 0x0800 MID = 0xAA82
UID = 0x0002
SMB: Command = С session setup & X
SMB: Word count =13
SMB: Word parameters
SMB: Next offset = 0x0075
SMB: Max Buffer Size = 2920 @xB68)
SMB: Max MPX requests = 50 ! -'
SMB: VC number = 1
SMB: Session Key =0
SMB: Password length = 24 @x18)
SMB: Unicode Password length = 0 @x0)
+ SMB: Capabilities = 5 @x5)
SMB: Byte count = 56
SMB: Byte parameters

198 Глава 7
- . и . SMB: Account name = ed ,, ..-;.
SMB: Domain name = MRED •¦
¦¦-' SMB: Native OS = Windows 4.0 ,x- .
' SMB: Native Lanman = Windows 4.0 .-,\ „
SMB: Command = No secondary command _¦,;¦> .
После того как все согласования были выполнены, данные пересылают-
пересылаются на машину клиента. Первый шаг состоит в поиске файла для пересылки
на клиентскую машину с помощью команды "transact2 Findfirst". Эта коман-
команда будет использовать функцию Findfirst для поиска определенного файла
(в нашем случае утилиты Browstat.exe). Для этой операции задаются два
флага. Один закроет дескриптор поиска после завершения, а второй будет
продолжать после каждой найденной записи. Они могут считываться как
двоичные числа. Флаг закрытия дескриптора поиска находится в первой
позиции, а флаг ключа продолжения находится в четвертой позиции @101).
SMB: Command = R transact2 чи ; -; 1.:?ыа:м,*: :?."-.?
. ... . SMB: Word count = 15 ' ' ' ;'•¦ ¦ Vv
SMB: Word parameters * : r- '- ''y v';k
SMB: Total parm bytes = 58 :'¦'"¦
SMB: Total data bytes = 0 '- ¦ ''¦¦¦¦
SMB: Max parm bytes = 10 "¦'*' '
SMB: Max data bytes = 608 :'
SMB: Max setup words = 0 @x0)
+ SMB: Transact Flags Summary = 0 @x0)
SMB: Transact timeout = 0 @x0)
SMB: Parameter bytes = 58 @x3A)
SMB: Parameter offset = 68 @x44) |Л"-
SMB: Data bytes = 0 @x0)
"¦•"¦ '¦-•¦"• ¦' "' SMB: Data offset = 0 @x0) ;1Jir'' :' r<; "/'> '
¦'•'•г ..<¦<; SMB: Max setup words = 1 '" >"':' '¦'^¦'"¦' •'¦':и("-1--
••¦ l . .' ' SMB: Setup words ' :H
С :.. :•!• :¦;.; SMB: Transact2 function = Findfirst ! ,;¦.¦: -.-..г;
SMB: Byte count = 61 ¦ . -, ¦
SMB: Byte parameters
SMB: Transaction parameters
+ SMB: Search attributes = 0x0016 !
> ", SMB: Find count = 6 '
SMB: Find Flags = 5 @x5)
SMB: 1 = Close search handle
upon completing request
SMB: 0 . = Keep search handle
open if end of search reached
SMB: 1. . = Resume key is required
for each entry found
SMB: 0... = Start search from the
beginning
SMB: Info Level = Both Directory Info (NT)
SMB: File name = \NTRESKIT\BROWSTAT.EXE

Трафик приложений 199
Получив ответ от сервера, клиентская машина посылает команду "R NT
create & X". Параметр "Create flags Dword", равный 0x00000006, запрашивает
как Oplock, так и Opbatch. Параметр "file share access", равный 0x00000001,
запрашивает доступ к файлу на чтение.
SMB: Command = R NT create & X
¦<¦;•¦.' SMB: Word count = 24 ¦<•..:. ¦¦:¦¦.¦,¦.:¦¦ .>-.гм,: ¦ > огуЛ!
. ¦: '¦'/ j!-. L"¦•¦•>! ¦ SMB: Word parameters -hv ;¦ •• cprurri .; ..-.;<iin л v
.,;,,-;, ),.;::,-/,<!, SMB: Next offset = 0x0000. ;>';:". ¦.w'v-.'-.t;:.•¦>-<• (¦;¦¦:*¦¦>¦¦
O!-, ,,f )U,. ;¦:¦., SMB: Word count = 24 -¦..•...: .-4-. ..: -^-но) f-lr ; i '_¦:¦¦ ¦>¦- i
. j f П; ... .• •• SMB: Word parameters , , -,, та<..<' ,!•¦¦
.,.',"'¦.'..,,'.. ". / ¦¦' SMB: Name Length (NT) = 44 @x2C) ¦,-.-, i\/-\ r,,;i, ,-
'"' ' ^ ' "¦ + SMB: Create Flags DWord = 0x00000006 ' -" '•.
SMB: Root Dir FID = 0x00000000
+ SMB: Desired Access = 0x00020089
SMB: File Allocation Size = 0x0000000000000000
+ SMB: NT File Attributes = 0x00000000
+ SMB: File Share Access = 0x00000001
SMB: Create Disposition = Open: If exist. Open,
else fail
+ SMB: Create Options = 68 @x44)
SMB: Impersonation Level = 0x00000002
+ SMB: Security Flags = 0x03
SMB: Byte count = 47
SMB: File name = \NTRESKIT\BROWSTAT.EXE
Теперь компьютер начинает процесс определения, как передать файл и
что с ним делать после получения. В этом процессе снова задействована
команда "R NT create & X" и Batch Oplock. В распечатке ниже содержится
вся обычная информация, которую можно увидеть в подробном списке ка-
каталога. Параметр "file allocation size" равен 0х000000000000А800, что соот-
соответствует 4308 байтам в десятичных числах. Если это значение разделить
на 1024, получится 42 Кбайта — размер browstat.exe. Здесь также присутству-
присутствует "File ID". FID используется для мониторинга транзакции и отслеживания
файла. .. , . .
SMB: Command = R NT create & X -, - • iv ' .
SMB: Word count = 34 , ' ..
SMB: Word parameters ,
SMB: Next offset = 0x0067
SMB: Word count = 34
;, : • , SMB: Word parameters ..- . i . ,¦ . •¦ . , ,, '.'
¦ .-'.. ( , , SMB: Oplock Level = Batch . ' , .., ,-. ¦-. _,. .-,• :..
SMB: File ID (FID) = 6157 @xl80D) -j ,ri. :,, ,. :.
" ' , , SMB: File Name = \NTRESKIT\BROWSTAT.EXE ' ,/
1 i!" : ' SMB: Create Action = File Opened
¦¦¦' '; • SMB: Creation Time = Jul 26, 1996 5:0:0.0 ' >H!
c SMB: NT Last Access Time = Aug 15, 1999 20:59:1.79
SMB: Last Write Time = Jul 26, 1996 5:0:0.0
SMB: Change Time = Auf 24, 1999 1:33:11.25
+ SMB: NT File Attributes = 0x00000020

200 i. ^'...-..... Глава 7
: ¦ :¦' /j.^,; ¦ . SMB: File Allocation Size = 0x00000000O0O0A800
. ,,..;¦ ; ,,lr. ,;i SMB: End of File = 0xOOOOOOO0OO0OA51O
(|.,,iV,;:i ;¦, .,, SMB: File type = Disk file or directory ¦ ,•
SMB: Device state = 0x0000 . .,.,,,,..,,..
SMB: Boolean Is Directory = 0 @x0)
Несколькими кадрами дальше протокол SMB начинает реальную переда-
передачу данных с сервера на клиентскую машину. Команда SMB "С read & X" на-
начинает копирование данных по кабелю. Это полноразмерный кадр
Ethernet A514 байтов, включая заголовок Erthernet), но он несет полезную
нагрузку только в 1397 байтов — т.е. 117 байтов накладных расходов из заго-
заголовка Ethernet, заголовка IP, заголовка TCP, заголовка NBT и, наконец,
команды SMB. ., / ;,:
SMB: Command =
SMB:
SMB:
SMB:
'"¦¦ SMB:
SMB:
SMB:
SMB:
SMB:
SMB:
SMB: Data
@x0575)
С read & X
Word
Word
Next
File
count :
= 12 ': "¦" ¦
parameters
offset
name =
Bytes left =
Data
Data
Byte
Byte
length
offset
count =
= 0x0000
\NTRESKIT\BROWSTAT.EXE
= 65535
= 32768 @x8000)
= 59 (ОхЗВ)
= 32768 :
parameters
: Number of
data bytes remaining =
1397
Когда данные начнут перемещаться, SMB на некоторое время выпадает
из картины и позволяет NBT переносить нагрузку, используя TCP, чтобы
гарантировать безопасную доставку данных. Наша полезная нагрузка воз-
возросла теперь до 1460 байтов, такой она будет оставаться для передачи.
+ FRAME: Base frame properties :.-,. , ,. ... , ¦. :•;
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet .: .
Protocol
+ IP: ID = 0xl91C; Proto = TCP; Len: 1500 '''
+ TCP: .A...., len: 1460, seq: 2012325-2013784, ack:
8796927, win: 7328, src: 139 (NBT Session) dst: 1073
NBT: SS: Session Message Cont., 1460 Bytes
NBT: SS Data: Number of data bytes remaining = 1460
@x05B4)
Когда данные будут переданы, наступает время закрыть сеанс. Для это-
этого будет использоваться команда SMB "С tree disconnect". Команда "С tree
disconnect" не использует имя файла (такое, как при передаче данных);
вместо этого клиент использует идентификатор дерева (TID) удаленного
диска, который будет отсоединяться. Сервер присваивает TID, когда
впервые создается соединение.
SMB: С tree disconnect
+ SMB: SMB Status = Error Success

.Трафик приложений 201
SMB:
= 0x6802
+
+
SMB:
Header: PID = OxCAFE TID = 0xD002 MID 0xB2C0 UID
SMB:
SMB:
SMB:
SMB:
SMB:
SMB:
Tree ID (TID) = 53250
Process ID (PID) = 51966
User ID (UID) = 26626
Multiplex ID (MID) = 45760
Flags Summary = 24 @x18)
@xD002)
(OxCAFE)
@x6802)
@xB2C0)
flags2 Summary = 32771 @x8003)
Command = С tree disconnect
SMB:
SMB:
Word count =0
Byte count = 0
Ответ возвращается с сервера со значением статуса "error success" и со-
соответствующим номером TID. Когда эта команда завершается, сеанс SMB
разъединяется. Для разъединения сеанса требуются два маленьких кадра
по 93 байта каждый.
1 " SMB: R tree disconnect ' •.¦¦•••••¦
' ; ¦ + SMB: SMB Status = Error Success
"?'¦' SMB: Header: PID = OxCAFE TID = 0xD002 MID 0xB2C0 UID
= 0x6802
SMB :
SMB:
SMB:
SMB:
+ SMB:
+ SMB:
Tree ID (TID) =
Process ID (PID) =
User ID (UID) =
Multiplex ID (MID) =
Flags Summary = 152
= 53250
= 51966
= 26626
= 45760
@x98)
@xD002)
(OxCAFE)
@x6802)
@xB2C0)
flags2 Summary = 32771 @x8003)
SMB: Command = С tree disconnect
SMB:
SMB:
Word count = 0
Byte count =0
росмотр Интернета
Трафик просмотра Интернета все в большей степени оказывает влияние
на корпоративные сети с точки зрения как интрасетей, так и Интернета.
Оба типа трафика имеют аналогичные схемы поведения, однако интрасети
часто используют графику более интенсивно и требуют более широкую по-
полосу пропускания. Посмотрим, что происходит, когда загружается одна
страница Web.
Страницы Web
Для нашего примера рассмотрим, что происходит, когда запускается броу-
броузер Microsoft Internet Explorer и открывается используемая по умолчанию
начальная страница на сайте MSN. Как можно видеть на распечатке ниже,
броузер начинает со стандартного запроса DNS. Это небольшая дейтаграм-
дейтаграмма UDP, направленная в порт 53 сервера DNS. Она использует 78 байтов,
включая заголовок Ethernet для этого кадра. Этот кадр повторяется, пока
не придет ответ в третьем кадре трассировки (файл open msn page.cap на
сайте издательства "ЛОРИ" (www.lory-press.ru)).

202 Глава 7
DNS: Oxl: Std Qry for home.microsoft.com of type Host Addr
on class INET addr.
DNS: Query Identifier = 1 (Oxl)
+ 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: home.microsoft.com. of type
Host Addr on class INET addr.
.» - DNS: Question Name: home.microsoft.com.
,. , .¦¦._. DNS: Question Type = Host Address
' * '..''.' ' DNS: Question Class = Internet address class
Ответ на запрос, где находится home.Microsoft.com, возвращается в
380- байтовом кадре. Полезная нагрузка UDP состоит из 264 байтов данных
DNS. Для ясности кадр был слегка сокращен. Счетчик запросов (question
entry count) равен единице, указывая, что имеется один запрос, который по-
повторяется из предыдущего кадра. Счетчик ответов (answer entry count) равен
четырем, что говорит о наличии четырех ответов на запрос, где находится
home.Microsoft.com. Первая возвращаемая запись ресурса предоставляет
клиентской машине IP-адрес.
DNS: Oxl: Std Qry Resp. for home.microsoft.com. of type Host
Addr on class INET addr.
DNS: Query Identifier = 1 (Oxl)
+ DNS: DNS Flags = Response, OpCode - Std Qry, RD RA
Bits Set, RCode - No error
DNS: Question Entry Count = 1 (Oxl)
DNS: Answer Entry Count = 4 @x4)
DNS: Name Server Count = 4 @x4)
DNS: Additional Records Count = 4 @x4) ;>'¦• •.
DNS: Question Section: home.microsoft.com. of type
. i:i, Host Addr on class INET addr.
.;.-,. DNS: Question Name: home.microsoft.com.
.,.., . DNS: Question Type = Host Address -. .
DNS: Question Class = Internet address class
DNS: Answer section: home.microsoft.com. of type Host
i;' Addr on class INET addr. D records present)
DNS: Resource Record: home.microsoft.com. of type
Host Addr on class INET addr.
DNS: Resource Name: home.microsoft.com. .?••'.?:
. -( DNS: Resource Type = Host Address .
DNS: Resource Class Internet address class
DNS: Time To Live = 95 @x5F) if
• '¦ ¦'' "' DNS: Resource Data Length = 4 @x4) ^ -t
' DNS: IP address = 207.46.176.13 : '' '-'^'
Когда имя будет преобразовано, можно инициировать контакт с помо-
помощью трехходового квитирования. Оно направляется в порт 80, который яв-
является портом, используемым для HTTP. Флаги 0x02 (здесь задано два

Трафик приложений 203
флага) говорят нам, что требуется синхронизировать номера последователь-
последовательностей. Клиентская машина выбирает порт источника как 3488 (OxODAO).
•
TCP: ....S., len: 4, seq: 241730-241733, ack: 0,
win: 8192, src: 3488 dst: 80 ¦-,.,.;¦¦
TCP: Source Port = OxODAO
TCP: Destination Port = Hypertext Transfer Protocol
TCP: Sequence Number = 241730 @x3B042)
' TCP: Acknowledgement Number = 0 @x0) ¦'•' . • • ''¦¦¦•¦••
TCP: Data Offset = 24 @x18) ........ • •,.,¦¦ >•": • : ¦
TCP: Reserved = 0 @x0000)
+ TCP: Flags = 0x02 : ....S. .'. • , . .
Второй кадр квитирования возвращается с флагами, заданными как
0x12, означающими, что поле подтверждения значимо и заданы номера
синхронизированной последовательности. Источником является порт 80,
кадр посылается в порт 3488 на клиентской машине. Номер подтверждения
на единицу больше, чем порядковый номер из клиентской машины. Кроме
того, сервер передает свой собственный порядковый номер, как видно на
распечатке ниже. ¦ ¦ - ¦ ¦ •* ¦ ¦ ¦
TCP: .A..S., len: 4, seq: 142002582-142002585, ack:
241731, win: 8760, src: 80 dst: 3488
TCP: Source Port = Hypertext Transfer Protocol
TCP: Destination Port = OxODAO
TCP: Sequence Number = 142002582 @x876C996)
TCP: Acknowledgement Number = 241731 @x3B043)
TCP: Data Offset = 24 @x18)
TCP: Reserved = 0 @x0000) . . ,.
+ TCP: Flags = 0x12 : .A..S.
В третьем кадре поле подтверждения является значимым, и можно срав-
сравнить АСК с порядковым номером в предыдущем кадре. Здесь снова ис-
используются те же порты места назначения и источника. Флаги 0x10 @10000 в
двоичном виде равно 16 в десятичном и 10 в шестнадцатеричном) указывают
на кадр АСК.
TCP: .А , len: 0, seq: 241731-241731, ack:
142002583, win: 8760, src: 3488 dst: 80
TCP: Source Port = OxODAO
TCP: Destination Port = Hypertext Transfer Protocol
TCP: Sequence Number = 241731 @x3B043)
TCP: Acknowledgement Number = 142002583 @x876C997)
TCP: Data Offset = 20 @x14)
TCP: Reserved = 0 @x0000)
+ TCP: Flags = 0x10 : .A....
Этот кадр завершает трехходовое квитирование, и мы готовы к загрузке
страницы Web.
Давайте посмотрим на кадр 9 в нашем файле "open msn page.cap" на сайте
издательства "ЛОРИ" (www.lory-press.ru). Часть TCP кадра выглядит анало-
аналогично другим, которые мы уже встречали. Она по-прежнему направляется в

204 Глава 7
порт 80. Здесь имеются два флага, но в этот раз они являются флагами АСК
и Push. Если сравнить номер подтверждения с номером из предыдущего
кадра, то легко видеть, что они подтверждают один и тот же кадр. Флаг
push приказывает серверу продолжать и послать данные, которые имеются
в буфере.
Раздел HTTP посылает команду GET из home.Microsoft.com с помощью
протокола HTTP/1.1. Недокументированный заголовок содержит данные
cookie с информацией о городе, штате и zip-коде, которая может использоваться
для персонализации начальной страницы MSN. ¦:;> ..
TCP: .АР..., len: 577, seq: 241731-241307, ack:
142002583, win: 8760, src: 3488 dst: 80
TCP: Source Port = OxODAO
TCP: Destination Port = Hypertext Transfer Protocol
¦'-¦•-'¦¦¦ TCP: Sequence Number = 241731 @x3B043)
; ' v TCP: Acknowledgement Number = 142002583 @x876C997)
•^•"-¦"r TCP: Data Offset = 20 @x14)
•<,f"A TCP: Reserved = 0 @x0000) ->¦- ¦',:•¦¦• *¦¦ .,.-•*¦ ' -
,.v •,.¦. TCP: Flags = 0x18 : .AP. . . "
TCP: ..0 = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....1... = Push function
TCP: 0. . = No Reset
TCP: 0. = No Synchronize
TCP: 0 = No Fin
TCP: Window = 8760 @x2238)
TCP: Checksum = 0xF9B5
TCP: Urgent Pointer = 0 @x0)
TCP: Data: Number of data bytes remaining = 577
@x0241)
HTTP: GET Request (from client using port 3488)
HTTP: Request Method = GET ¦¦¦••¦¦¦
HTTP: Uniform Resource Identifier = /
;. ¦¦ •. HTTP: Protocol Version = HTTP/1.1
HTTP: Accept = image/gif, image/x-xbitmap, image/jpeg,
image/pjpeg, */*
HTTP: Accept-Language = en-us
HTTP: Accept-Encoding = gzip, deflate
HTTP: User-Agent = Mozilla/4.0 (compatible; MSIE 4.01;
Windows NT)
HTTP: Host = home.microsoft.com
HTTP: Connection = Keep-Alive
HTTP: Undocumented Header = Cookie:
HMCMISC=FCDEG=F&CITYCODE=OH%5FHamilton&LN=RTCI&CITYGU
IDE=gCINC&VCARD%5FPOSTALCODE=45011&MINDIF=ll&P=t;
CATEGORIES=MAIL%2CNEWS%2C
HTTP: Undocumented Header Fieldname = Cookie
HTTP: Undocumented Header Value =
HMCMISC=FCDEG=F&CITYCODE=OH%5FHamilton&LN=RTCI&CIT
В распечатке выше броузер говорит, что он хочет получить (GET) стра-
страницу с сайта home.Microsoft.com и предоставляет свой cookie. Кадр ниже

Трафик приложений 205
является ответом с сервера. Страница указана в параметре "Undocumented
header location" и будет выведена в адресном окне броузера. Мы видим теги
HTML, которые указывают броузеру, как форматировать текст. Эта конк-
конкретная страница никогда не выводится в броузере, а является страницей
перенаправления, создающей достаточно интересный ответ, который можно
увидеть в следующем кадре. ¦ . .., - ' ' .
HTTP: Response (to client using port 3488)
HTTP: Protocol Version = HTTP/1.1 ¦
HTTP: Status Code = Found
HTTP: Reason = Object moved
HTTP: Server = Microsoft-IIS/4.0
HTTP: Date = Tue, 24 Aug 1999 03:02:35 GMT
HTTP: Undocumented Header = Location:
http://www.msn.com/default.asp?HMC2MSN=l
HTTP: Undocumented Header Fieldname = Location
HTTP: Undocumented Header Value =
http://www.msn.com/default.asp?HMC2MSN=l
HTTP: Content-Type = text/html
HTTP: Undocumented Header = <headxtitle>Object
moved</titlex/head>
HTTP: Undocumented Header Fieldname = , '--¦. > r.t
<headxtitle>Object ,
HTTP: Undocumented Header Value =
moved< /tit 1 ex /head>
HTTP: Undocumented Header = <bodyxhl>0bject '
Moved</hl>This object may be found <a
HREF="http://www.msn.com/default.asp?HMC2MSN=l">here</a>.</body>
HTTP: Undocumented Header Fieldname =
<bodyxhl>0bject
HTTP: Undocumented Header Value = Moved</hl>This
object may be found <a HREF="http:/
Сервер задает два флага: АСК, который мы могли бы ожидать, и флаг
FIN (больше данных от отправителя нет 0x01). Сервер msn.com закрывает
соединение.
TCP: .A...F, len: 0, seq: 142002909-142002909, ack:
242308, win: 8183, src: 80 dst: 3488
TCP: Source Port = Hypertext Transfer Protocol
TCP: Destination Port = OxODAO
TCP: Sequence Number = 142002909 @x876CADD)
: TCP: Acknowledgement Number = 242308 @x3B284)
TCP: Data Offset = 20 @x14)
TCP: Reserved = 0 @x0000) .''
TCP: Flags = 0x11 : .A...F '
TCP: ..0 = No urgent data
TCP: ...1.... = Acknowledgement field significant
: TCP: ....0... = No Push function
TCP: 0. . = No Reset ...
TCP: 0. = No Synchronize
TCP: 1 = No more data from sender

206 ""'"""'¦'¦'"' Глава 7
Когда клиентский компьютер получает флаг FIN с сервера MSN, он не име-
имеет другого варианта, кроме как заново создать соединение. Это указывается
в разделе флагов @x04). J '. »¦*¦<•"' ''Л г*
TCP: ...R.., len: 0, seq: 242308 - 242308, ack: ...„„,„,„
142002583, win: 0, src: 3488 dst: 80 : ^
TCP: Source Port = OxODAO j'*»«^"«^ >••.,.!•*№«
TCP: Destination Port = Hypertext Transfer Protocol
TCP: Sequence Number = 242308 @x3B284)
TCP: Acknowledgement Number = 142002583 @x876C997)
TCP: Data Offset = 20 @x14)
TCP: Reserved = 0 @x0000) ..¦¦;<-: tv
TCP: Flags = 0x04 : ...R..
TCP: ..0 = No urgent data ,, . ,->¦¦¦ ;
TCP: ...0.... = Acknowledgement field not significant
... TCP: ....0... = No Push function
TCP: 1.. = Reset the connection
TCP: 0. = No Synchronize
TCP: 0 = NO Fin ¦•.' ;-."Г •
В этом месте клиентская машина решает, что предыдущий ответ от DNS
был не вполне точным, поэтому она пытается сделать повтор с помощью
другого запроса DNS, как показано на распечатке ниже.
UDP: Src Port: Unknown, C489); Dst Port: DNS E3); Length =
37 @x25)
DNS: 0xl:Std Qry for www.msn.com. of type Host Addr on
class INET addr.
DNS: Query Identifier = 1 @x1)
+ DNS: DNS Flags = Query, OpCode - Std Qry, RD Bits Set,
RCode - No error
DNS: Question Entry Count = 1 @x1) " " '--"¦¦'
DNS: Answer Entry Count = 0 @x0) ...л т .-t
"'¦¦"'' DNS: Name Server Count = 0 @x0) "''¦' ' "*'' ' '' ''" * "
1 •>r''1' DNS: Additional Records Count = 0 @x0)
DNS: Question Section: www.msn.com. of type Host Addr
on class INET addr.
DNS: Question Name: www.msn.com.
DNS: Question Type: Host Address
DNS: Question Class = Internet address class
После другого запроса DNS мы успешно получаем нужный адрес и про-
проходим также через трехходовый процесс квитирования. Посылается за-
запрос GET, и страница Web начинает загружаться, как видно на распечатке
ниже. Первый кадр, который начинает транспортировать данные, имеет
дополнительную информацию заголовка HTTP и поэтому ограничен по-
полезной нагрузкой в 1263 байта. Последующим кадрам не требуется дубли-
дублировать всю информацию заголовка, поэтому они смогут переносить до
1460 байтов данных, как показано в следующем кадре.
HTTP: Response (to client using port 3491)
HTTP: Protocol Version = HTTP/1.1

Трафик приложений 207
HTTP: Status Code = OK
HTTP: Reason = OK •¦• •• т ¦ ¦
HTTP: Server = Microsoft-IIS/4.0
HTTP: Date = Tue, 24 Aug 1999 03:02:37 GMT
HTTP: Content-Length = 35376
HTTP: Content-Type = text/html
HTTP: Expires = Tue, 24 Aug 1999 03:02:37 GMT
HTTP: Undocumented Header = Cache-control: private
HTTP: Undocumented Header Filedname = Cache-control
HTTP: Undocumented Header Value = private
HTTP: Data: Number of data bytes remaining = 1263
@x04EF)
Как можно видеть в заголовке HTTP ниже, пакет максимизируется для
транспортировки данных, полагаясь на TCP в вопросах обработки ошибок
и упорядочивания данных.
HTTP: Response (to client using port 3491)
HTTP: Data: Number of data bytes remaining = 1460
@x05B4) :
Когда данные начинают передаваться по каналу, это происходит как лю-
любая другая передача данных с помощью TCP/IP. В трассировке мы видим
пару кадров HTTP, за которыми следует пара кадров АСК TCP.
:.. .; I.
Secure Sockets Layer
Реализация Secure Sockets Layer (SSL) является существенной для успеш-
успешной электронной коммерции и бизнеса в Интернете. Она начинается
обычно с соединения с портом 80, как показано в трассировках. Когда
клиентская машина попадает на страницу, которая требует SSL, сервер
вернет FIN из порта 80 в порт назначения на клиентской машине.
TCP: .A...F, len: 0, seg: 2958296-2958296, ack:
256976, win: 8092, src: 80 dst: 4346
TCP: Source Port = Hypertext Transfer Protocol
TCP: Destination Port = OxlOFA
TCP: Sequence Number = 2958296 @x2D23D8)
TCP: Acknowledgement Number = 256976 (ОхЗЕВОО)
TCP: Data Offset = 20 @x14)
TCP: Reserved = 0 @x0000)
TCP: Flags = 0x11 : .A...F
TCP: ..0 = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: 0. . = No Reset
TCP: 0. = No Synchronize "
;i • .¦: v TCP: 1 = No more data from sender
Клиентская машина подтверждает FIN, по-прежнему используя тот же
порт источника и приходя в порт HTTP 80 на сервере.

208 Глава 7
TCP: .A , len: 0, seq: 256976-256976, аск:
2958297, win: 7885, src: 4346 dst: 80
TCP: Source Port = OxlOFA
TCP: Destination Port = Hypertext Transfer Protocol
TCP: Sequence Number = 2 56976 @x3EBD0)
TCP: Acknowledgement Number = 2958297 @x2D23D9)
TCP: Data Offset = 20 @x14)
TCP: Reserved = 0 @x0000)
TCP: Flags = 0x10 : .A....
TCP: ..0 = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: 0.. = No Reset
" ' ' TCP: 0. = No Synchronize '¦ /s
' TCP: 0 = No FIN .- ; !; ' • ¦." ¦:'"< ]':
Теперь на сервере происходит интересная вещь: он переключает порты
на клиентской машине. Порт источника на сервере изменяется на 443 — об-
общеизвестный порт для коммуникации SSL, и также изменяется порт назна-
назначения на клиентской машине. В данном случае порт назначения
изменяется на 4347, на единицу больше, чем было в последнем соединении.
Сервер также подтверждает предыдущий кадр с клиентской машины и по-
посылает запрос для синхронизации номеров последовательности на запра-
запрашивающую машину. Когда все это будет выполнено, между двумя машинами
начнут перемещаться данные. —¦-•, :—: ~-г. — .-„. ^-ч-.
TCP: .A..S., len: 4, seq: 2913904-2913907, ack:
252920, win 8760, src: 443 dst: 4347
TCP: Source Port = 0x0IBB , . ¦ • ..
, TCP: Destination Port = OxlOFB
TCP: Sequence Number = 2913904 @x2C7670)
TCP: Acknowledgement Number = 252920 @x3DBF8)
TCP: Data Offset = 24 @x18)
TCP: Reserved = 0 @x0000)
TCP: Flags = 0x12 : .A..S
TCP: ..0 = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: 0. . = No Reset
TCP: 1. = Synchronize sequence numbers
TCP: 0 = No FIN
Оптимизация трафика броузера в интрасети
Лучшее, что можно сделать для оптимизации трафика броузера в интрасе-
интрасети,— это небольшие, эффективные страницы Web, где создается большая
часть трафика. Чтобы реализовать эту оптимизацию, можно предпринять
следующее:

Трафик приложений 209
1. Сократите число графических изображений, используемых на стра-
странице Web, так как они составляют существенную часть сетевого тра-
трафика. При использовании графики проверьте, что графический
формат оптимизирован для Web (т.е. не используйте файлы .bmp или
.tiff, так как с ними связан большой объем дополнительных накладных
расходов).
2. Ограничьте использование фреймов, так как использование несколь-
нескольких фреймов может приводить к нескольким загрузкам для каждой
страницы.
3. Сократите необходимость прокручивания страницы. Чтобы сделать
это, разбейте страницу на меньшие куски. Таким образом, если
клиент не заинтересован во всей странице, не будет затрачиваться
дополнительное время для загрузки ненужной информации.
4. Разместите серверы прокси в удаленных местах и разрешите активное
кэширование. Это позволит сократить количество повторных
загрузок одной и той же информации.
5. Увеличьте размер кэша на локальной машине. Кэширование данных
на локальной машине ускорит для пользователя процесс просмотра и
сократит сетевой трафик. Все это уменьшает для компьютера необходи-
необходимость загружать одну и ту же информацию при повторном посещении
страниц Web.
6. Тщательно оцените необходимость защищенности (как узлов, защи-
защищенных паролем, так и SSL), поскольку слишком слабая защищенность
вызывает дополнительный сетевой трафик.
Обзор главы
В этой главе были рассмотрены различные типы трафика приложений. Мы
начали с трафика пересылки файлов и печати. Помимо трафика, вовлечен-
вовлеченного в пересылку данных, мы оценили также накладные расходы, связан-
связанные с методами разрешения имен, созданием соединения и согласованием
диалекта SMB. После просмотра трафика файлов и печати мы перешли к
изучению трафика Интернета и показали взаимодействия, происходящие
при просмотре Web. Здесь мы снова встретили трафик разрешения имени
и трафик создания соединения. Накладные расходы здесь меньше, чем для
трафика файлов и печати, так как протоколы оптимизированы для работы
в среде с узкой полосой пропускания.
В следующей главе
В следующей главе мы рассмотрим трафик сервера Microsoft Exchange и
сравним его с РОРЗ Интернета. Мы обсудим последовательность опера-
операций, когда Exchange открывает и закрывает соединение, а также вопросы
разрешения имен.

Глава 8
Exchange и почта Интернета
При установке новые приложения загружают и автоматически запускают
некоторые службы. Если приложение хорошее, то это будет одна или две
службы. Однако многие приложения сегодня загружают множество служб,
которые объявляют всем о своем существовании.
Exchange ¦ ¦ - ¦¦¦»»¦; ¦¦¦*;¦¦ ¦¦> .-. >.-.-гв»--••¦:.-.¦. . ¦.¦- ¦¦ 1
Протокол SMTP (Simple Mail Transfer Protocol, простой протокол передачи
почты) используется для получения почты из Интернета. Когда адрес сер-
сервера преобразован (с помощью DNS), создается соединение с портом 25.
Команды SMTP используются для управления потоком почты из одной ма-
машины в другую. Каждая из этих команд заканчивается нажатием клавиши
Enter или Return. Команды SMTP не зависят от регистра символов, хотя
SMTP будет сохранять регистр при адресации, так как некоторые реализа-
реализации могут иметь имена пользователей, зависящие от регистра символов.
Как видно на рис. 8.1, для создания соединения может использоваться Telnet,
а также другой сервер SMTP. Это часто делается для тестирования соединения
Connect
Host Name: |exchange.fullservjj
Port: Ш 71
I }
lerrnType: |vt100
Connect Cancel
Рис. 8.1. Telnet может использоваться для тестирования соединения с Exchange

Exchange и почта Интернета 211
почты Интернета с Exchange. Процесс начинается с команды mail, посылаемой
отправителем с помощью from: в форме <имя_пользователя>@<имя_^цомена>.
From: является полем, которое сообщает серверу SMTP имя пользователя.
<имя_пользователя>@<имя_^цомена> также станет ответом для адреса.
Команда HELO (HELLO в некоторых реализациях) позволяет узнать,
общаются ли две машины. В то время как приветствие при соединении
идентифицирует сервер получателя, HELO используется для идентифика-
идентификации отправителя на сервере SMTP. HELO и сопровождающий 250 ОК по-
позволяют узнать, что отправитель и получатель находятся в состоянии
начального соединения без выполняющихся транзакций и с пустыми буфе-
буферами. Команда mail сообщает серверу SMTP, что начинается новая транзак-
транзакция. Если все правильно, то вернется ответ 250 ОК. from: называется также
адресом обратного пути. Он может содержать более одного почтового ящика,
а также список хостов для обратной маршрутизации источника.
Следующей командой MAIL используется для начала почтовой транзак-
транзакции. Эта строка также будет содержать from:, что называется обратным пу-
путем доступа и используется для извещений о недоставке. Эта информация
хранится сервером SMTP отправителя в буфере обратных путей доступа,
который будет обрабатываться после ввода всех данных.
RCPT идентифицирует получателя сообщения и является командой,
вводимой после команды mail. Если эта команда mail получена сервером
SMTP правильно, то будет возвращаться ответ 250-ОК. Если получатель не-
неизвестен, то с сервера вернется ошибка 550. Если получатель введен непра-
неправильно, то будет порождаться ошибка 553 неправильно сформированного
адреса. Протокол позволит в этом месте ввести в процесс несколько полу-
получателей. Нажатие клавиши Return в конце строки RCPT и ввод другой
команды RCPR вводит дополнительных получателей. Кроме почтового
ящика в поле RCPT можно также поместить список маршрутов хостов
источников. Данные RCPT хранятся в буфере путей доступа пересылки
столько, сколько нужно серверу.
Третьим шагом является команда DATA, за которой следует нажатие
клавиши Enter или отправка возврата каретки и перевода строки (<CRLF>)
(несколько анахронический термин). Когда сервер получит эту команду,
протокол SMTP рассматривает весь последующий трафик как данные для
этого поля, пока не получит строку, содержащую только одну точку. Други-
Другими словами, раздел данных завершается, когда получающий сервер полу-
получит строку символов геШгп-точка-return (<CRLF>.<CRLF>). Индикатор
конца данных подтверждает транзакцию и приказывает серверу SMTP об-
обработать данные в буфере обратного пути доступа и буфере пути доступа
пересылки. Когда обработка закончена, сервер вернет ОК. Приняв сообще-
сообщение, сервер вставляет отметку времени в начале строки почтовых данных,
которая указывает идентичность посылающего и получающего хостов. При
конечной доставке сообщения также вставляется строка пути возврата, ко-
которая содержит информацию из обратного пути, введенного вместе с
командой mail. Поле данных почты может также содержать, если потребу-
потребуется, тему данных, строки to, ее и from. На рис. 8.2 показано использование
этих команд в сеансе Telnet, созданном с сервером Exchange. Это хороший
способ протестировать соединение Exchange и почты Интернета.

212
Глава 8
Telnet-208 112.201.97
¦-IN
:l Jdi Ieinmal Hdp j
220 taconic.fullservice.net ESMTP Seruer (Microsoft Exchange Internet Kail Serui
ce $.5.2232.9) ready
helo ; ¦, . - . , , .,,. ¦, ..
J50 OK - .. .....
Mil fron: billgSraicrosoft.con
250 OK - nail fron <billgGnicrosoft.con>
rcpt to: eduafullseruice.net
258 OK - Recipient <edwefullseruice.net>
data ¦ .,¦ -.: , - • .
JS4 Send data. End with CRLF.CRLF
subject: looking forward to seeing your book
Ed, just heard about your new book. An really looking forward to reading it.
В SO OK
Рис. 8.2. Команды SMTP, посылаемые во время тестового сеанса
Команда DATA будет отказывать, только если транзакция является не-
неполной или нет доступных ресурсов для обработки запроса. Реализация
SMTP в Microsoft Exchange не позволит иметь неполное сообщение. Как
можно видеть на рис. 8.3, Exchange требует, чтобы команды вводились в
определенном порядке, прежде чем он будет обрабатывать данные.
Я Telnet - exchange lullseivice.net
Connect ?<*< lermnal Help
228 taconic.fullseruice.net ESMTP Seruer (Microsoft Exchange Internet Hail Serui
ce 5.5.2232.9) ready
helo
251 OK
503 Ho recipients: need RCPT
563 Ho originator: need HAIL ~
nail
581 Syntax Error
nail fron: edwQfullseruice.net
250 OK - nail fron <eduQfullseruice.net>
Рис. 8.З. Microsoft Exchange требует, чтобы команды SMTP были
в определенном порядке

Exchange и почта Интернета 213
Протокол SMTP включает дополнительные свойства для помощи в по-
поиске получателей и списков распространения. Этими командами являются
команда VRFY, которая используется для предоставления информации о
пользователях почтового ящика, и команда EXPR, используемая для спис-
списков распространения. Однако, как видно на рис. 8.4, эти команды не реали-
реализованы в Microsoft Exchange по соображениям безопасности. Вместо них
для предоставления этой информации используется LDAP.
Команда NOOP используется для определения отсутствия операции.
Она не влияет ни на какие введенные ранее команды или параметры. Она
просто означает ничего не делать и получает с сервера ответ ОК.
RSET является командой сброса, которая прерывает текущую транзак-
транзакцию. Вся информация в буферах будет сброшена и таблицы состояния очи-
очищены. Она также получает с сервера ответ ОК. Эта команда может быть
отправлена в любой момент во время общения. . ......
9 Telnet exchange lullseivice.net
Connect ?* Tetm«ial Help
229 taconic.fullseruice.net ESHTP Server (Hicrosoft Exchange Internet Mail Serui
ce 5.5.2232.9) ready
helo
'258 OK ......
iwrfy dauem '
|252 Cannot uerify user . ;. •¦
urfy davea9fullseruice.net
252 Cannot uerify user
expn service "¦" ¦ •>: i4>~
502 copmand not inplenented •. .;.• -л* '. . •'
¦r
Рис. 8.4. Дополнительные свойства SMTP, например VRFY и EXPN,
не реализованы в Exchange
Открытие и закрытие сеанса
Когда между двумя компьютерами впервые создается сеанс, есть возмож-
возможность убедиться, что серверы общаются именно с тем, с кем они собира-
собирались общаться. Для этого используется команда HELO. Эта команда может
посылаться только один раз и имеет форму HELO mred.com. HELO иденти-
идентифицирует посылающий компьютер для сервера SMTP. Если при обработке
команды не возникает ошибок, то ответом будет 250 ОК. Эту команду мож-
можно интерпретировать как "Привет, я mred.com". Если команда HELO

214 Глава 8
посылается во второй раз, то ответом будет 503 bad sequence (неверная по-
последовательность). В указанном домене никакой проверки не делается, и
имя домена можно оставить пустым, как на рис. 8.2.
Когда сеанс заканчивается, для закрытия канала посылается команда
QUIT.
Сервер Exchange в действии
Рассмотрим теперь некоторые трассировки, показывающие, как работает
почта SMTP в реальной жизни. Для создания соединения SMTP с Exchange
требуется пять кадров и 420 байтов. Это включает трехходовое квитирова-
квитирование, кадр готовности службы SMTP и еще один кадр подтверждения (АСК).
Посмотрим на кадр готовности службы на распечатке ниже. Код ответа 220,
как мы знаем из таблицы 8.1, означает, что служба готова. Этот кадр поступа-
поступает из порта 25, который используется для службы SMTP. Код 220 посылается
как стандартный код ASCII и показан в шестнадцатеричной панели как 32 32
30. Символ ASCII для 20 равен 50 и преобразуется в шестнадцатеричное 32.
Символ ASCII для 0 равен 48 и преобразуется в шестнадцатеричное 30.
SMTP: Rsp: Service ready, 102 bytes
SMTP: Response = 220 taconic.fullservice.net ESMTP '
Server (Microsoft Exchange Internet Mail
SMTP: Data = Service 5.5.2232.9) ready ........... , с
Хотя TCP является дуплексным протоколом, SMTP действует только в
полудуплексном режиме. Это означает, что посылаемый символ должен
быть подтвержден перед посылкой следующего символа. Это требование
создает большой объем трафика подтверждения (АСК). Например, просто
отправка команды HELO требует 11 кадров и 695 байтов. Когда посылается
и подтверждается HELO, следующий кадр с клиентской машины посылает
0D 0А (ASCII 13, возврат каретки, и ASCII 10, перевод строки), как видно на
распечатке ниже.
TCP: .АР , 1еп: 2, seq: 123557-123558 ack: 1430817,
win 8658, src: 1667 dst: 25 (SMTP)
TCP: Source Port = 0x0683
¦ . TCP: Destination Port = SMTP
" ~" TCP: Sequence Number = 123557 @xlE2A5)
TCP: Acknowledgement Number = 1430817 @xl5D521)
TCP: Data Offset = 20 @x14)
TCP: Reserved = 0 @x0000)
+ TCP: Flags = 0x18 : .AP... .,-, ¦ ,-,.,. ..,bj_ ^ .;„.
TCP: Window = 8658 @x21D2) ' ''' '' " ' " ' "'
TCP: Checksum = 0x997F •• ' ¦ •'"' '-¦ <':*¦-¦¦•¦' '-¦'
TCP: Urgent Pointer = 0 @x0) -
TCP: Data: Number of data bytes remaining = 2 @x0002)
SMTP: Cmd: completed, 2 bytes
00000: F8 E0 07 00 01 01 00 01 B0 81 66 80 08 00 45 10
f.. .E.
00010: 00 2A C2 B3 40 00 80 06 OF 15 CE 70 C2 B2 CE 70

Exchange и почта Интернета 215
.*. -@ р.. .р
00020: С9 61 06 83 00 19 00 01 Е2 А5 00 15 D5 21 50 18
.а ! Р. ¦.
00030: 21 D2 99 7F 00 00 0D ОА '
Таблица 8.1. Коды ответа SMTP
Код Значение
211 Состояние или справка готовы.
214 Справочное сообщение.
220 Служба домена готова.
221 Служба домена закрывает канал передачи. ......
250 Действие закончилось успешно (ОК).
251 Пользователь не локальный. Пересылка в место назначения.
354 Начало ввода почты. '
421 Служба недоступна. Закрытие канала.
450 Действие не принято. Почтовый ящик недоступен
' • (почтовый ящик занят).
451 Действие прекращено. Обрабатывается локальная ошибка.
.452 . .... . Действие не принято. Недостаточно системной памяти. .;*ii
500 - Синтаксическая ошибка. Команда не опознана.
501 ' ¦ Синтаксическая ошибка в параметрах или аргументах. '¦ > ¦
502 Команда в системе не реализована. ' : '
503 . . Неверная последовательность команд. Команды ,,,, ,
в неправильном порядке. , ......
504 ';'¦ I: Параметр команды не реализован. Команда допустима, '!
но параметр — нет. Г. ¦ , -.-
550 Действие не принято. Почтовый ящик недоступен ¦:
(или не найден). ! '
551 ^ Пользователь не локальный. Сообщение необходимо
переслать.
552 . Действие прервано. Превышение выделенной памяти.
553 Действие не принято. Имя почтового ящика недопустимо
' v-* ¦' (неправильный синтаксис почтового ящика).
554 Отказ транзакции. ""¦>' "¦'"-¦¦
Когда посылающая машина пересылает кадр с завершенной коман-
командой, получающий сервер SMTP подтверждает это ответом 250 ОК B50
ASCII в шестнадцатеричном виде будет 32 35 30; 20 — символ пробела;
ASCII 79 в шестнадцатеричном виде 4F, a ASCII 75 — 4В. Отметим 0D 0А
в качестве последних двух байтов в шестнадцатеричной панели).

216 Глава 8
TCP: .АР..., len: 8, seq: 1430817-1430824, ack:
123559, win: 8754, src: 25 (SMTP) dst: 1667
TCP: Source Port = SMTP
TCP: Destination Port = 0x0683
TCP: Sequence Number = 1430817 @xl5D521)
TCP: Acknowledgement Number = 123559 @xlE2A7)
TCP: Data Offset = 20 @x14) ?• v.4'
' TCP: Reserved = 0 @x0000)
+ TCP: Flags = 0x18 : .AP... '" : -
TCP: Windows = 8754 @x2232) ^ .'..
TCP: Checksum = 0xE776
TCP: Urgent Pointer = 0 @x0)
TCP: Data: Number of data bytes remaining = 8 @x0008)
SMTP: Rsp: Requested mail action okey, completed, 8 bytes
SMTP: Response = 250 OK
00000: 00 01 B0 81 66 80 F8 E0 07 00 01 01 08 00 45 00
-• f E.
00010: 00 30 15 00 40 00 7D 06 BF D2 CE 70 C9 61 CE 70
.0..@.}....p.a.p
00020: C2 B2 00 19 06 83 00 15 D5 21 00 01 E2 A7 50 18
! P.
00030: 22 32 E7 76 00 00 32 35 30 20 4F 4B 0D 0A
.v..250 OK..
ПРОТОКОЛ РОРЗ -иЛи—^1 •< ¦•: ь- —
Протокол РОРЗ используется как упрощенный протокол почты, который
хранит сообщения на сервере, пока клиентская машина не соединится и не
выгрузит их по запросу. Он делает не слишком много по обработке сообще-
сообщения на сервере; служба РОРЗ просто слушает порт TCP ПО, пока почта не бу-
будет извлечена, и удаляет ее из почтового хранилища. Это не очень развитый
протокол, но он достаточно эффективен.
Когда клиент РОРЗ хочет создать соединение, он следует схеме одиноч-
одиночных рабочих команд. Подобно протоколу SMTP, который был рассмотрен
ранее, команды состоят из символов ASCII, разделенных пробелами. Эти
команды имеют длину в три или четыре символа. Модификаторы для
команд РОРЗ могут быть до 40 символов длиной.
Сервер РОРЗ дает два типа ответов. Первый ответ является положитель-
положительным (+ОК, как показано на рис. 8.5). Отрицательным ответом является -ERR.
Оба эти ответа должны быть представлены заглавными буквами и содержать
либо знак -, либо знак +.
Некоторые команды будут создавать многострочный ответ с сервера (на-
(например, команда list), и каждая строка будет заканчиваться комбинацией
возврата каретки и перевода строки (та же самая комбинация ASCII 13 и
ASCII 10 использовалась в протоколе SMTP). Когда все строки будут посла-
посланы, сервер пошлет . (ASCII 46) и дополнительный перевод строки. Это та же
комбинация <RLF>. [точка]<RLF>, которую мы видели в протоколе SMTP.

Exchange и почта Интернета 217
¦Э» Telnet - roetl.one.nel
Connect ?dl leimlnal Help
•OK PDP3 U1.21 1997/08/16 ready <3c3600800d57cii37aiiMil.one.net>
user euilsan
•OK ewilson selected
pass VpPXUxZQ
>OK Congratulations!
stat
»0K » 13203
List
>OK 4 Messages A32B3 octets)
1 983
г 9t1
9 7911
i 9UI
'
Рис. 8.5. Команды РОРЗ, отправленные во время сеанса Telnet
Четыре состояния РОРЗ Во время процесса соединения клиента и
получения почты РОРЗ проходит через четыре состояния. После начально-
начального соединения TCP и последующего приветствия сервер входит в состояние
авторизации, в котором клиент идентифицирует себя. Вслед за состоянием
авторизации РОРЗ входит в состояние транзакции и получает команды с
клиентской машины для обработки почты. После успешной обработки поч-
почты и отправки клиентом команды завершения quit сеанс входит в фазу об-
обновления и освобождает ресурсы, использованные во время состояния
транзакции. Затем соединение TCP закрывается. Эта последовательность
событий для успешного сеанса подробно описана в следующем списке.
1. Клиентская машина запрашивает у DNS адрес.
2. Когда адрес получен, машина инициирует трехходовое квитирова-
квитирование на порте 110.
3. Вслед за трехходовым квитированием сервер посылает приветствие.
4. Клиент отвечает именем пользователя.
5. Сервер проверяет, существует ли пользователь в системе, и отвечает
с помощью +ОК.
6. Клиент отвечает паролем. г
7. Сервер отвечает +ОК.
8. Клиент запрашивает состояние почтового ящика.

218
Глава 8
9. Сервер отвечает, посылая число и размер сообщений в почтовом
ящике.
10. Клиент запрашивает список сообщений. • f iv
11. Сервер отвечает. . ,'.' ' " ,
12. Клиент пересылает себе сообщения.
13. Клиент стирает сообщения на сервере.
14. Когда все сделано, он посылает команду завершения quit.
15. Сервер отвечает с помощью+ОК.
Таблица 8.2 суммирует команды РОРЗ, которые обычно встречаются в
трассировках сетевого мониторинга.
Таблица 8.2. Обычно используемые команды РОРЗ
Команда Аргументы
Описание
QUIT
STAT
Нет
Нет
LIST
RETR
Номер сообщения
(не обязателен)
Номер сообщения
(требуется)
DELE Номер сообщения
(требуется)
NOOP Нет
RSET
QUIT
Нет
Нет
Используется для аккуратного закрытия
сеанса РОРЗ. Позволяет серверу войти в
состояние обновления, где он освобождает
ресурсы.
Запрашивает у сервера число и размер
сообщений в почтовом ящике. Ответ будет
иметь вид +ОК nn mm, где пп — число
сообщений, a mm — число использованных
байтов.
Перечисляет сообщения по номеру
и размеру. • .¦••. . ¦ -.•¦• •¦¦
Выбирает сообщение с сервера РОРЗ
по номеру. Сервер возвращает +ОК,
количество байтов и текст сообщения.
Удаляет сообщение с сервера по номеру.
Нет операции. Вызывает с сервера . ,-
сообщение +ОК.
Сбрасывает сеанс. Снимает отметки со всех
сообщений, которые были помечены для
удаления (используя команду DELE).
Сервер удаляет сообщения, помеченные
командой DELE, освобождает ресурсы,
и закрывает соединение TCP.

Exchange и почта Интернета
219
Таблица 8.2. Обычно используемые команды РОРЗ (продолжение)
Команда Аргументы
Описание
ТОР
USER
Номер сообщения
и число строк
для извлечения
(требуется).
Используется для извлечения некоторого
числа строк из определенного сообщения.
Если число запрошенных строк больше,
чем объем сообщения, то извлекается все
сообщение.
Имя пользователя на Во время состояния приветствия
сервере (требуется) до состояния транзакции сообщает серверу,
какой почтовый ящик открыть.
PASS Пароль (требуется)
Используется во время состояния
авторизации немедленно после успешной
команды USER. При успехе сервер
отвечает +ОК.
Рассмотрим реальный сеанс РОРЗ. Этот кадр возникает немедленно по-
после трехходового квитирования на порте ПО и сигнализирует о входе в фазу
приветствия. РОРЗ использует TCP для переноса команд данных в виде
текста ASCII. В распечатке ниже мы видим приветствие РОРЗ +ОК.
TCP: .АР..., len: 66, seq: 836990619-836990684, ack:
124982, win:32736, src: 110 dst: 1844
TCP: Source Port = Post Office Protocol — Version 3
TCP: Destination Port = 0x0734
TCP: Sequence Number = 836990619 @x31E3769B)
TCP: Acknowledgement Number = 124982 @xlE836)
TCP: Data Offset = 20 @x14)
TCP: Reserved = 0 @x0000)
+ TCP: Flags = 0x18 : .AP...
' . TCP: Window = 32736 @x7FE0) ¦ ; ....;• .
TCP: Checksum = 0x5437 , ,. •..•-,¦ . ,', ,,
TCP: Urgent Pointer = 0 @x0) . . ,
TCP: Data: Number of data bytes remaining = 66
@x0042) ¦ '
00000: 00 01 B0 81 66 80 F8 E0 07 00 01 01 08 00 45 10
f E.
00010: 00 6A ЕЕ 25 40 00 3D 06 IF 69 CE 70 CO 64 CE 70
.j.%@.=..i.p.d.p
00020: D2 A9 00 6E 07 34 31 E3 76 9B 00 01 E8 36 50 18
...n.41.v....6P.
00030: 7F E0 54 37 00 00 2B 4F 4B 20 50 4F 50 33 20 76
.T7..+OK РОРЗ v
00040: 31 2E 32 31 20 31 39 39 37 2F 30 38 2F 31 30 20
1.21 1997/08/10

220 Глава 8
Теперь мы входим в фазу авторизации, которая направляется с клиент-
клиентской машины в порт TCP 110 на сервере. Отметим, что заданные в кадре
флаги А и Р говорят нам, что поле подтверждения существенно, а также
приказывают серверу отправить данные. В поле HEX мы видим команду
USER и аргумент edwilso. Кадр заканчивается шестнадцатеричными 0D 0А,
которые мы видели в других кадрах. Отметим, что этот трафик посылается
как обычный текст ASCII.
TCP: .АР..., len: 14, seq: 124982-124995, ack:
836990685, win: 8694, src: 1844 dst: 110
TCP: Source Port = 0x0734
'¦'¦¦¦¦¦¦ TCP: Destination Port = Post Office Protocol — Version 3
TCP: Sequence Number = 124982 @xlE836)
TCP: Acknowledgement Number = 836990685 @x31E376DD)
TCP: Data Offset = 20 @x14)
TCP: Reserved = 0 @x0000)
+ TCP: Flags = 0x18 : .AP...
TCP: Window = 8694 @x21F6)
TCP: Checksum = 0xA9DE
TCP: Urgent Pointer = 0 @x0)
TCP: Data: Number of data bytes remaining = 14
(OxOOOE) • . . ,
00000: F8 E0 07 00 01 01 00 01 B0 81 66 80 08 00 45 10
f...E.
00010: 00 36 06 DO 40 00 80 06 C3 F2 CE 70 D2 A9 CE 70
.6. .@ p. . .p
00020: CO 64 07 34 00 6E 00 01 E8 36 31 E3 76 DD 50 18
.d.4.n...61.v.p.
00030: 21 F6 A9 DE 00 00 55 53 45 52 20 65 64 77 69 6C
! USER edwi 1
00040: 73 6F 0D 0A
so. .
Сервер указывает, что существует пользователь с почтовым ящиком с
именем ewilso. ASCII гарантирует, что регистр символов будет сохранен,
использует это или нет определенная реализация. Команда PASS использу-
использует регистр символов. Этот ответ приходит из порта 110 на компьютер мес-
места назначения с заданными флагами А и Р. Мы неоднократно это увидим,
пока сервер будет проходить через различные состояния. Отметим, что но-
номер подтверждения совпадает с номером последовательности в следующем
кадре.
TCP: .АР..., len: 22, seq: 836990685-836990706, ack:
124996, win:32736, src: 110 dst: 1844
TCP: Source Port = Post Office Protocol - Version 3
TCP: Destination Port = 0x0734
TCP: Sequence Number = 836990685 @x31E376DD)
TCP: Acknowledgement Number = 124996 @xlE844)
TCP: Data Offset = 20 @x14)
TCP: Reserved = 0 @x0000)
+ TCP: Flags = 0x18 : .AP...

Exchange и почта Интернета 221
„....., ¦;. TCP: Window = 32736 @x7FE0) , ,, . . .... v.
.-. i!(, TCP: Checksum = 0x8AAD ' " .,/,,.
TCP: Urgent Pointer = 0 @x0) ." ''"_'
TCP: Data: Number of data bytes remaining =22
@x0016)
00000: 00 01 BO 81 66 80 F8 E0 07 00 01 01 08 00 45 10
f E.
00010: 00 ЗЕ ЕЕ 30 40 00 3D 06 IF 8A CE 70 CO 64 CE 70
.>.0@.=....p.d.p
00020: D2 A9 00 6E 07 34 31 E3 76 DD 00 01 E8 44 50 18
...n.41.v....DP.
00030: 7F E0 8A AD 00 00 2B 4F 4B 20 65 64 77 69 6C 73
+OK edwils
00040: 6F 20 72 65 6C 65 63 74 65 64 0D 0A . ' Q.
selected.
Теперь начинаются заботы о почте РОРЗ. Через Интернет открытым
текстом посылается пароль. Команда PASS переносит аргумент пароль, лег-
легко различимый в шестнадцатеричной трассировке. Конечно, необходимо
быть в нужном месте в нужное время, чтобы его перехватить, но пароль
там есть. Он поступает с клиентской машины в порт 110 на сервере. Снова
заданы флаги А и Р, а кадр заканчивается шестнадцатеричными 0D 0А.
Сравните номер последовательности в кадре ниже с номером подтверждения
из предыдущего кадра — они совпадают.
TCP: .АР..., len: 15, seq: 124996-125010, ack:
836990707, win: 8672, src: 1844 dst: 110
TCP: Source Port = 0x0734
TCP: Destination Port = Post Office Protocol — Version 3
; TCP: Sequence Number = 124996 @xlE844)
TCP: Acknowledgement Number = 836990707 @x31E376F3)
TCP: Data Offset = 20 @x14)
TCP: Reserved = 0 @x0000)
+ TCP: Flags = 0x18 : .AP...
TCP: Window = 8672 @x21E0) '
TCP: Checksum = 0x6533
TCP: Urgent Pointer = 0 @x0)
TCP: Data: Number of data bytes remaining = 15
(OxOOOF)
00000: F8 E0 07 00 01 01 00 01 B0 81 66 80 08 00 45 10
f.. .E.
00010: 00 37 07 DO 40 00 80 06 C2 Fl CE 70 D2 A9 CE 70
.7. .@ p. - -p
00020: CO 64 07 34 00 6E 00 01 E8 44 31 E3 76 F3 50 18
.d.4.n...Dl.v.p.
00030: 21 E0 65 33 00 00 50 41 53 53 20 5A 31 61 2A 30
!.e3..PASS Zla*0
00040: 6D 38 69 0D OA
m8i. . '

222 " Глава 8
Сервер отвечает из порта 110 с поздравлением +ОК и 0D 0А. Это сигна-
сигнализирует об окончании состояния авторизации. Мы видим флаги А и Р,
отправляя данные назад на клиентскую машину.
TCP: .АР len: 22, seq: 836990707-836990728, ack:
125011, win:32736, src: 110 dst: 1844
TCP: Source Port = Post Office Protocol — Version 3
TCP: Destination Port = 0x0734
TCP: Sequence Number = 836990707 @x31E376F3)
TCP: Acknowledgement Number = 125011 @xlE853)
TCP: Data Offset = 20 @x14)
TCP: Reserved = 0 @x0000) . .¦/'.'' (..
+ TCP: Flags = 0x18 : .AP... ' " \
TCP: Window = 32736 @x7FE0) . ' ,ч
TCP: Checksum = 0x8797
TCP: Urgent Pointer = 0 @x0)
TCP: Data: Number of data bytes remaining = 22
@x0016) : '
¦•"•.i 00000: 00 01 B0 81 66 80 F8 E0 07 00 01 01 08 00 45 10
1 f E. , i7
00010: 00 3E F2 24 40 00 3D 06 IB 96 CE 70 CO 64 CE 70 . ,
.>.$©.=....p.d.p ."¦;.;,
.„,, 00020: D2 A9 00 6E 07 34 31 E3 76 F3 00 01 E8 53 50 18
. . .n.41.v. . . .SP. ""''"
00030: 7F E0 87 97 00 00 2B 4F 4B 20 43 6F 6E 67 72 61 " '
+OK Congra
00040: 74 75 6C 61 74 69 6F 6E 73 21 0D 0A . ;; -
tulations!..
Первый кадр в фазе транзакции передает команду STAT, чтобы увидеть,
сколько сообщений ожидают в почтовом ящике.
TCP: .АР..., len: 6, seq: I 25011-125016, ack:
836990729, win: 8650, src: 1844 dst: 110
TCP: Source Port = 0x0734
TCP: Destination Port = Post Office Protocol - Version 3
TCP: Sequence Number = 125011 @xlE853)
TCP: Acknowledgement Number = 836990729 @x31E37709)
TCP: Data Offset = 20 @x14)
TCP: Reserved = 0 @x0000)
. , .. + TCP: Flags = 0x18 : .AP... . . :. . .*
TCP: Window = 8650 @x21CA)
TCP: Checksum = 0x2377
TCP: Urgent Pointer = 0 @x0)
TCP: Data: Number of data bytes remaining = 6 @x0006)
00000: F8 E0 07 00 01 01 00 01 B0 81 66 80 08 00 45 10
f...E.
00010: 00 2E 08 DO 40 00 80 06 Cl FA CE 70 D2 A9 CE 70
@ p. . .p
00020: CO 64 07 34 00 6E 00 01 E8 53 31 E3 77 09 50 18
.d.4.n...Sl.w.P.

Exchange и почта Интернета
223
00030: 21 СА 23 77 00 00 53 54 41 54 0D 0А ...
! .#w. .STAT. . ¦.-.-¦--
Сервер отвечает числом сообщений и байтов в почтовом ящике пользо-
пользователя. +ОК указывает на успешную команду. В данном случае на сервере
в наличии девять сообщений общим объемом 48564 байтов, как показано
в шестнадцатеричной панели в распечатке ниже.
TCP: .AP..., len: 13, seq: 836990729-836990741, ack:
125017, win:32736, src: 110 dst: 1844
., TCP: Source Port = Post Office Protocol - Version 3
гя. TCP: Destination Port = 0x0734 . . § \
Sequence Number = 836990729 @x31E37709) '•'¦"'"
Acknowledgement Number = 125017 @xlE859) ';i "'"'.'¦'¦
Data Offset = 20 @x14) •' ¦ " '
Reserved = 0 @x0000) '¦ .•¦¦>;.''n-. •:'k.o-> v
Flags = 0x18 : .AP...
Window = 327 36 @x7FE0) .. ". ' . ':
Checksum = OxOFFB ,'... .,,.¦:.;.
Urgent Pointer = 0 @x0)
Data: Number of data bytes remaining = 13
TCP:
''"" " TCP:
TCP:
TCP:
+ TCP:
TCP:
-/. TCP:
TCP:
TCP:
(OxOOOD)
00000: 00 01 B0 81 66 80 F8 E0 07 00 01 01 08 00 45 10
f E.
00010: 00 35 F2 32 40 00 3D 06 IB 91 CE 70 CO 64 CE 70
.5.2@.=....p.d.p
00020: D2 A9 00 6E 01 34 31 E3 77 09 00 01 E8 59 50 18
...n.41.w....YP.
00030: 7F EO OF FB 00 00 2B 4F 4B 20 39 20 34 38 35 36
+OK 9 4856
00040: 34 0D 0A . . . ..,
4.. ..-¦...• , . ¦..
Следующей в интерактивной фазе является команда LIST, за которой
следует 0D 0А, чтобы сообщить серверу, что команда закончилась. Мы видим
это в шестнадцатеричной панели ниже.
125017-125022, ack:
dst: 110
TCP: .АР..., len: 6, seq:
836990742, win: 8637, src: 1844
TCP: Source Port = 0x0734
TCP: Destination Port = Post Office Protocol - Version 3
TCP: Sequence Number = 125017 @xlE859)
TCP: Acknowledgement Number = 836990742 @x31E37716)
TCP: Data Offset = 20 @x14)
TCP: Reserved = 0 @x0000) ': '
+ TCP: Flags = 0x18 : .AP...
TCP: Window = 8637 @x21BD) •
TCP: Checksum = 0xl87C
TCP: Urgent Pointer = 0 @x0)
TCP: Data: Number of data bytes remaining = 6 @x0006)
00000: F8 E0 07 00 01 01 00 01 B0 81 66 80 08 00 45 10

224 ' Глава 8
00010: 00 2Е 09 DO 40 00 80 06 CO FA CE 70 D2 A9 CE 70
• • • -@ P- • -P
00020: CO 64 07 34 00 6E 00 01 E8 59 31 E3 77 16 50 18
•¦; .d.4.n.. .Yl.w.P. ¦>.... ;¦¦.¦* ,.¦¦ ¦-¦:
00030: 21 BD 18 7C 00 00 4C 49 53 54 OD OA . ,,'j'jv, ;•'•<•¦ t'H
! . . I . .LIST. . .-¦: ; , ...
Сервер РОРЗ отвечает с помощью +ОК и девяти сообщений D8564 окте-
октетов). Все они записаны в шестнадцатеричной панели — даже левая и правая
круглые скобки. Этот кадр в действительности больше, чем приведено в
распечатке ниже (он сокращен для ясности). Вслед за числом октетов сле-
следуют сообщения, пронумерованные и с указанием размера. Программное
обеспечение будет использовать эту информацию для запроса с сервера
РОРЗ сообщений по отдельности.
TCP: .АР..., 1еп: 107, seg: 836990742-836990848, ack:
125023, win:32736, src: 110 dst: 1844
TCP: Source Port = Post Office Protocol — Version 3
TCP: Destination Port = 0x0734
TCP: Sequence Number = 836990742 @x31E37716)
TCP: Acknowledgement Number = 125023 @xlE85E)
TCP: Data Offset = 20 @x14)
TCP: Reserved = 0 @x0000)
+ TCP: Flags = 0x18 : .AP... . .
TCP: Window = 32736 @x7FE0)
TCP: Checksum = 0xF276 ; _¦ ¦".
TCP: Urgent Pointer = 0 @x0)
TCP: Data: Number of data bytes remaining = 107
(ОхООбВ)
00000: 00 01 ВО 81 66 80 F8 E0 07 00 01 01 08 00 45 10
f E.
00010: 00 93 F2 3D 40 00 3D 06 IB 28 CE 70 CO 64 CE 70
...=@. = . . (.p.d.p
00020: D2 A9 00 6E 07 34 31 E3 77 16 00 01 E8 5F 50 18
...n.41.w...._P.
00030: 7F E0 F2 76 00 00 2B 4F 4B 20 23. 20 6D 65 73 73
..v..+OK 9 mess
00040: 61 67 65 73 20 28 34 38 35 36 34 20 6F 63 74 65
ages D8564 octe
Клиент начинает теперь считывать сообщения по отдельности. Первой
будет команда ТОР, запрашивающая первое сообщение, как мы видим в
шестнадцатеричной панели в распечатке ниже.
TCP: .АР..., len: 9, seg: 125023-125031, ack:
836990849, win: 8530, src: 1844 dst: 110
TCP: Source Port = 0x0734
TCP: Destination Port = Post Office Protocol - Version 3
TCP: Sequence Number = 125023 @xlE85F)
TCP: Acknowledgement Number = 836990849 @x31E37781)

Exchange и почта Интернета
225
TCP: Data Offset = 20 @x14) . ..
TCP: Reserved = 0 @x0000)
+ TCP: Flags = 0x18 : .AP... ' '
TCP: Window = 8530 @x2152) ' ':
TCP: Checksum = 0xB57D
TCP: Urgent Pointer = 0 @x0)
TCP: Data: Number of data bytes remaining = 9 @x0009)
00000: F8 E0 07 00 01 01 00 01 B0 81 66 80 08 00 45 10
f...E.
00010: 00 31 0A DO 40 00 80 06 BF F7 CE 70 D2 A9 CE 70
• 1. .@ p.-.p
00020: CO 64 07 34 00 6E 00 01 E8 5F 31 E3 77 81 50 18
.d.4.n..._1.w.P.
.-;,..; 00030: 21 52 B5 7D 00 00 54 4F 50 20 31 20 30 0D 0A
!R.}.- TOP 10.. . •
Сервер отвечает +ОК на команду ТОР, и текст первого сообщения на-
начинает передаваться клиенту. Сообщение имеет в длину 4292 октета, и
этот кадр содержит первый из заголовков сообщения received:... Большая
часть шестнадцатеричной панели не включена, но этот кадр несет полез-
полезную нагрузку 1024 байта, в основном занятую различными типами почто-
почтовых заголовков. Мы снова видим установленные флаги А и Р. Этот кадр
поступает с сервера клиенту, так как порт источника ПО.
TCP: .AP..., len: 1024, seq: 836990849-836991872, ack:
125032, win:32736, src: 110 dst: 1844
TCP: Source Port = Post Office Protocol - Version 3
TCP: Destination Port = 0x0734
TCP: Sequence Number = 836990849 @x31E37781)
TCP: Acknowledgement Number = 125032 @xlE868)
TCP: Data Offset = 20 @x14)
TCP: Reserved = 0 @x0000)
+ TCP: Flags = 0x18 : .AP...
TCP: Window = 3273 6 @x7FE0)
TCP: Checksum = 0xlD4E
TCP: Urgent Pointer = 0 @x0)
TCP: Data: Number of data bytes remaining = 1024
@x0400)
00000: 00 01 B0 81 66 80 F8 E0 07 00 01 01 08 00 45 10
f E.
00010: 04 28 F2 7B 40 00 3D 06 17 55 CE 70 CO 64 CE 70
. ( . {@. = ..U.p.d.p
00020: D2 A9 00 6E 07 34 31 E3 77 81 00 01 E8 68 50 18
...n.41.w....hP.
00030: 7F E0 ID 4E 00 00 2B 4F 4B 20 34 32 39 32 20 6F
..N..+OK 4292 о
00040: 63 74 65 74 73 0D 0A 52 65 63 65 69 76 65 64 ЗА
ctets..Received:
Клиент и сервер продолжают передавать сообщения с помощью комбина-
комбинации кадров АСК и кадров ACK/PUSH. Сеанс, наконец, завершается

226 -.,„>»-,..- Глава8
командой QUIT и одним последним АСК (подтверждением). Число кадров
зависит от размера сообщений, но по сути общение клиента и сервера
остается таким же.
Общение Exchange с другим сервером
Когда Exchange общается с другим сервером, он использует не РОРЗ или
SMTP, а вызовы удаленной процедуры (RPC), которые являются значитель-
значительно более безопасной и надежной формой коммуникации. Чтобы понять бо-
более полно, как работает эта коммуникация, нам необходимо рассмотреть
несколько вещей, уникальных для RPC. Служба вызова удаленной процеду-
процедуры выполняется на сервере Windows NT и решает множество задач, таких
как идентификация номера порта, на котором действует определенная
служба. Вызов удаленной процедуры помогает Exchange при поиске номе-
номеров UUID (универсальной уникальной идентификации), связанных с опре-
определенной службой. Эти UUID классифицируются по первым двум символам
числа, и хотя другие службы помимо Exchange используют эти числа, не-
несколько из них являются уникальными для продукта. Три наиболее важных
номера перечислены ниже. . , ., м...... ..,,¦.
• А4 — хранилище обмена я ¦ . "'
• F5 — каталог обмена
• Е1 — служба вызова удаленной процедуры
Если служба вызова удаленной процедуры отказывает, то серверы обме-
обмена (Exchange) не могут общаться друг с другом, а также с другими клиент-
клиентскими машинами. По этой причине хорошее понимание функции RPC
может существенно помочь при поиске неисправностей.
Если два сервера обмена (Exchange) хотят общаться друг с другом, преж-
прежде всего необходимо запросить службу вызова удаленной процедуры на дру-
другом сервере обмена, чтобы определить, где осуществляет прием МТА
(агент транспорта сообщений). Необходимость этого обусловлена тем, что
МТА будет перемещаться и осуществлять прием на различных портах при
последовательных перезагрузках. Служба вызова удаленной процедуры за-
занимается отслеживанием всех различных служб и поддерживает список
портов, которые они используют. Когда сервер Microsoft Exchange запуска-
запускается, он зарегистрируется в службе вызова удаленной процедуры и запро-
запросит номер выделенного порта. Служба вызова удаленной процедуры
обслуживает запросы TCP/IP на порте 135. Она имеет фиксированный
UUID, равный E1AF8308-5D1F-11C9- 91A4-08002B14A0FA.
Общение между серверами будет начинаться с механизма разрешения
имени (поиск WINS, DNS, Broadcast, LMHOST), после чего следует треххо-
трехходовое квитирование. Затем Exchange посылает кадр в порт TCP 135, кото-
который является службой местонахождения на другом сервере, и связывает
RPC со службой вызова удаленной процедуры на другом сервере обмена.
Мы узнаем об этом, рассматривая абстрактный интерфейс UUID E1AF8308-
5D1F-11C9-91A1-08002B14A0FA. El сообщает нам, что это служба вызова
удаленной процедуры.

Exchange и почта Интернета 227
+ TCP: .АР len: 72, seq: 22639100-22639171, аск:
1469213, win: 8760, src: 1238 dst: 135
MSRPC: c/o RPC Bind: UUID E1AF8308-5D1F-11C9-91A4-
08002B14A0DFA call 0x0 assoc grp 0x0 xmit 0xl6DO recv 0xl6DO
MSRPC: Version = 5 @x5)
MSRPC: Version (Minor) = 0 @x0)
'¦¦.!•-:¦ • ,- MSRPC: Packet Type = Bind
MSRPC: Flags 1=0 @x0)
MSRPC: 0 = Reserved -or- Not the first
fragment (AES/DC)
MSRPC: 0. = Not a last fragment -or- No
cancel pending
MSRPC: 0.. = Not a fragment -or- No cancel
pending (AES/DC)
MSRPC: ....0... = Receiver to respond with a fack
PDU -or- Reserved (AES/DC)
MSRPC: ...0.... = Not used -or- Does not support
concurrent multiplexing (AES/DC)
MSRPC: ..0 = Not for an idempotent request -
or- Did not execute guaranteed call (Fault PDU only)
(AES/DC)
MSRPC: .0 = Not for a broadcast request -or-
'Maybe' call semantics not requested (AES/DC)
MSRPC: 0 = Reserved -or- No object UUID
specified in the optional object field (AES/DC)
MSRPC: Packet Data Representation
MSRPC: Fragment Length =72 @x48)
MSRPC: Authentication Length = 0 @x0)
MSRPC: Call Identifier = 0 @x0)
MSRPC: Max Trans Frag Size = 5840 @xl6D0)
MSRPC: Max Recv Frag Size = 5840 @xl6D0)
MSRPC: Assoc Group Identifier = 0 @x0)
MSRPC: Presentation Context List
MSRPC: Number of Context Elements = 1 @x1)
MSRPC: Presentation Context Identifier = 0 @x0)
MSRPC: Number of Transfer Syntaxs = 1 @x1)
MSRPC: Abstract Interface UUID = E1AF8308-5D1F-
11C9-91A4- 08002B14AOFA
MSRPC: Abstract Interface Version = 3 @x3)
MSRPC: Transfer Interface UUID = 8A885D04-1CEB-
11C9-9FE8- 08002B104860
MSRPC: Transfer Interface Version = 2 @x2)
Другой сервер обмена подтверждает связывание с помощью BindAck в
поле типа пакета, как можно видеть на распечатке. В разделе результатов
мы видим подтверждение принятия. Мы успешно создали соединение RPC
между службами вызова удаленных процедур двух серверов обмена.
+ TCP: .АР..., len: 60, seq: 1469213-1469272, ack:
22639172, win: 8688, src: 135 dst: 1238
MSRPC: c/o RPC Bind Ack: call 0x0 assoc grp 0x7622B
xmit 0xl6D0 recv 0xl6D0
MSRPC: Version = 5 @x5) ¦¦¦¦'"¦¦¦¦ f '
MSRPC: Version (Minor) = 0 @x0)

228 . Глава 8
MSRPC: Packet Type = Bind Ack
MSRPC: Flags 1=3 @x3) '
MSRPC: 1 = Reserved -or- First fragment
(AES/DC)
MSRPC: 1. = Last fragment -or- Cancel
pending
MSRPC: 0.. = Not a fragment -or- No cancel
pending (AES/DC)
MSRPC: ....0... = Receiver to respond with a fack
PDU -or- Reserved (AES/DC)
MSRPC: ...0.... = Not used -or- Does not support
concurrent multiplexing (AES/DC)
MSRPC: ..0 = Not for an idempotent request
-or- Did not execute guaranteed call (Fault PDU only) (AES/DC)
MSRPC: .0 = Not for a broadcast request -or-
'Maybe' call semantics not requested (AES/DC)
MSRPC: 0 = Reserved -or- No object UUID
specified in the optional object field (AES/DC! . ^
MSRPC: Packet Data Representation
MSRPC: Fragment Length = 60 (ОхЗС) ¦
MSRPC: Authentication Length = 0 @x0)
MSRPC: Call Identifier = 0 @x0)
MSRPC: Max Trans Frag Size = 5840 @xl6D0)
MSRPC: Max Recv Frag Size = 5840 @xl6D0)
MSRPC: Assoc Group Identifier = 483883 @x7622B)
+ MSRPC: Secondary Address
MSRPC: Padding Byte(s) ~ '"* * '"'
MSRPC: Result List
MSRPC: Number of Result = 1 @x1)
MSRPC: Reserved = 0 @x0)
MSRPC: Reserved 2 ' '
MSRPC: Presentation Context Results
MSRPC: Result = Acceptance
MSRPC: Reason = Reason not specified
MSRPC: Transfer Syntax
MSRPC: Transfer Interface UUID = 8A885D04-
1CEB-11C9-9FE8-08002B104860
MSRPC: Transfer Interface Version = 2
@x2)
Первый сервер обмена посылает теперь RPC Request Opnum 0x3 друго-
другому серверу обмена. В него включен UUID разыскиваемой службы. Эта
команда используется для запроса номера порта службы, связанной с UUID.
Получив этот номер порта, первый сервер обладает всей информацией, не-
необходимой для контакта со службой на другой машине. Он закроет теперь
соединение TCP/IP между ними и создаст соединение непосредственно
с определенной службой.
Серверы снова используют трехходовое квитирование TCP/IP для созда-
создания соединения, а затем соединение делает двухходовое связывание RPC,
означающее, что первый сервер обмена делает связывание RPC, за которым
следует BindAck от второго сервера обмена.

Exchange и почта Интернета 229
Затем второй сервер обмена делает соединение с первым сервером с
последующим BindAck. В этом общении имеются два связывания и два
BindAck.
Обзор главы
В этой главе рассмотрен трафик сервера Exchange и почты Интернета. Мы
начали с последовательности операций при открытии и закрытии сеансов
Exchange. Были исследованы вопросы разрешения имен и роль TCP/IP.
Затем мы перешли к рассмотрению Exchange в действии. Было подробно
обсуждено взаимодействие, вовлеченное в обмен сообщениями.
Вслед за этим мы перешли к протоколу РОРЗ. Мы увидели, как Exchange
использует РОРЗ, когда необходимо взаимодействие с другими почтовыми
системами Интернета. Затем было рассмотрено взаимодействие серверов
Exchange друг с другом и показано использование RPC.
В следующей главе
В следующей главе мы начинаем изучать инструменты сетевого мониторин-
мониторинга. Мы рассмотрим семейство мониторов компании Microsoft, начиная с
облегченной версии, включенной в Windows NT 4.0 и Windows 2000. Затем
мы постепенно перейдем к полнофункциональным продуктам, поставляе-
поставляемым вместе с SMS 1.2 и 2.0. Мы обсудим несколько вопросов безопасности
и способы автоматизации сбора трассировок сетевого монитора.

л v_ . и..
ЧАСТЬ III
Сетевые мониторы:
инструментальные средства
работы
Существует множество инструментальных средств работы, предо-
предоставляющих некоторые низкоуровневые подробности, необходимые для
выполнения сетевого мониторинга и анализа. Компания Microsoft выпус-
выпустила несколько хороших программ, которые поставляются с серверными
продуктами, а также более надежные инструменты, поставляемые вместе
с продуктом Systems Management Server (SMS).

Глава 9
Семейство сетевых мониторов
компании Microsoft
В настоящее время существует несколько различных сетевых мониторов,
поставляемых компанией Microsoft. Все они называются просто сетевыми
мониторами. В этой главе будут рассмотрены эти продукты и показано, как
установить, сконфигурировать и получить максимум возможного из этих
мощных инструментов. В умелых руках сетевой монитор может предоста-
предоставить много различной информации.
Сетевой монитор < > "
Раньше при возникновении проблемы с сетью, часто приходилось гадать,
что же вызвало неполадки. Позже появились специализированные устройст-
устройства, которые были дорогими, трудными для управления и понимания. Теперь
имеется сетевой монитор, который является программным инструментом
анализа компании Microsoft. Существуют две версии этой программы: сокра-
сокращенная, поставляемая с серверными операционными системами, и полная,
которая поставляется с сервером управления системами. Microsoft Network
Monitor Lite способен перехватывать трафик, предназначенный только для
машины, выполняющей программу. Полная версия переводит сетевой
адаптер в "режим, не делающий различия" — т.е. он перехватывает трафик,
направленный на компьютер, выполняющий Microsoft Nerwork Monitor,
а также трафик, предназначенный для других устройств.
Network Monitor 2.0 поставляется вместе с Windows 2000 в версии Lite, a
полная версия поставляется вместе с Windows NT 4.0 и SMS 2.0. Network
Monitor 1.2. поставляется вместе с Windows NT 4.0 и SMS 1.2. В действите-
действительности существует лишь Небольшое различие между версиями продукта
2.0 и 1.2, так как функционально они одинаковы. Мы укажем различия, но
большая часть рассматриваемого материала применима к любой версии
продукта.

234 Глава 9
Л ГГ
Microsoft Network Monitor копирует кадры в буфер перехвата, который
является областью памяти с изменяемым размером. По умолчанию этот бу-
буфер перехвата равен одному мегабайту, но это легко изменить. Однако в
связи с этим зависимым от памяти буфером перехвата сетевой монитор мо-
может перехватить лишь столько информации, сколько может поместиться в
доступной памяти. Когда буфер будет заполнен, он начнет отбрасывать па-
пакеты, и поэтому можно пропустить разыскиваемую информацию. Кроме
того, сетевой монитор имеет склонность блокировать и связывать боль-
большую часть ресурсов процессора, когда ему разрешается выполняться в те-
течение продолжительных периодов после полного заполнения буфера. К
счастью, легко прекратить его работу с помощью Task Manager, но тогда те-
теряется весь перехваченный файл. Мы узнаем некоторые приемы решения
этой проблемы при рассмотрении необслуживаемого мониторинга сети.
Потеря файла обычно не является проблемой, так как можно выбрать,
какую часть кадра необходимо увидеть, создавая фильтр перехвата. Фильтр
перехвата (который в определенном смысле похож на запрос к базе данных)
позволяет перехватывать только определенные адреса или типы кадров.
Мы поговорим об этом в разделе о перехвате данных.
Так как Microsoft Nerwork Monitor легкодоступный, очень мощный инст-
инструмент, способный перехватывать данные из сети, необходимо позаботи-
позаботиться о системе безопасности. Как мы видели в других главах, обладая
определенными навыками, из сети можно получить очень важную инфор-
информацию. Microsoft Nerwork Monitor может быть прекрасным инструментом
для поиска неисправностей, но также может представлять существенную
опасность, оказавшись в недобросовестных руках. Есть несколько способов
защиты сети от неавторизованного использования этого инструмента. Мы^
поговорим об этом позже, в разделе о безопасности сетевого монитора. «
Microsoft Network Monitor не устанавливается по умолчанию. Чтобы
установить его, перейдите к вкладке служб сетевого апплета в панели
управления и выберите добавить (add) инструменты сетевого монитора и
агент. (ПРИМЕЧАНИЕ. Не забудьте выбрать инструменты сетевого мони-
монитора и агента, а не просто агента сетевого монитора, который представлен
в списке ниже и не включает программу Microsoft Network Monitor.) Уста-
Установка версий SMS использует отдельную программу Setup.exe, находящую-
находящуюся в каталоге NMEXR на сайте издательства "ЛОРИ" (www.lory-press.ru).
Создание перехвата
Когда данные перехватываются, карта Ethernet передает часть кадров, ко-
которые она видит в сети, в буфер перехвата. Если буфер перехвата перепол-
переполняется, то для определения того, что удерживается в памяти, будет
использоваться принцип простой очереди, или FIFO (первый вошел, пер-
первый вышел). Чтобы избежать переполнения буфера перехвата, можно из-
изменить настройки буфера, выбирая их из меню перехвата. Появится
диалоговое окно, позволяющее определить новый буфер перехвата в мега-
мегабайтах. Здесь можно также определить, будет ли перехватываться весь
кадр, или некоторое число байтов кадра, позволяя сохранить только
информацию заголовка.

Семейство сетевых мониторов компании Microsoft
235
Другим способом сократить объем выбранных данных является создание
фильтра перехвата для уточнения того, что именно плата передает в буфер
перехвата. Начните свой сеанс перехвата, выбрав start в меню перехвата
(или нажав кнопку Record). Как показано на рис. 9.1, сетевой монитор выво-
выводит статистические данные о сеансе перехвата во время выполнения. Эти
статистические данные дают представление о сетевой производительности
в данный момент. Важно помнить, что это мгновенный снимок, и хотя он
может дать некоторое представление о сети, его нельзя использовать в каче-
качестве инструмента планирования. Если, однако, задокументировать эти запи-
записи, развернуть их во времени и сравнить с информацией из управляемых
концентраторов, коммутаторов, и маршрутизаторов, можно получить
лучшее представление о сетевой производительности.
Графическая панель (верхняя левая на рис. 9.1) показывает текущее со-
состояние сети. Эти панели имеют изменяемый размер, позволяя лучше
представить данные. Это полезное свойством при мониторинге процесса
перехвата. Это высокоуровневое представление может помочь при поиске
неисправностей, предоставляя перечисленную ниже информацию. <
• Процент загруженности сети
• Число кадров в секунду ... .-.-.-,¦¦.¦. ч > . . . , ,( ,.,
. Nolwoifc Moniloi |\?lhi4fMM\NEl?(.'jp!u«fWirv<l.iw(Sl.ihnnSljWII
Capfcie look Qpbonj tfndow Ц<*>
* Network Ulfeaten:
0
Fume» Ри Second
0
B/« P« Second
0
Broadcast» F« Second
0
MJhcettPa Second
i
0
0
0
0
100
100
4125
100
NehmkAotttttl
TERESA
PROX
ED1750
EDI 750
biguy
2400
2400
!•¦>?
2
1
3
9
31
2
91
1<-2
25
133
NetvwkAddn
•BROADCAST
USC 000118
¦BROADCAST
PROX
PROX
¦BROADCAST
PROX
/
TimEUpscd 000104733
Networic Statistics
«Fram,.. 388
I! Bioadcasts 7
IS M<Ac«lt 32
«ByUs 62-893
В Framer Oiopced: 0
t. Nona!
Cultured SlaMid
Kfimn 338
И Fc&Tie: Diopped 0
P«i Second SMtHtcs
.'i Netwoik Ullt«c.i 0
К Fiamet/trcond 0
В 8/et/t«ond 0
& Bioadcasts/second 0
' УУ\
Netoofc Adienl Frames SentlFu
usc'"booif8"|d" " ¦"¦"'|i
TERESA
«Rcvd
ByUsSent
0
335
S>4es RcvdlDiected Fia
57 0
a lo
Muticasls Sent
0
0
Broadcasts Sent
0
2
Рис. 9.1. Текущее представление о состоянии сети можно получить
из статистических данных сеанса в окне перехвата сетевого монитора

236 Глава 9
• Число байтов в секунду ; ,-.,. .¦> ., ¦ -',-. ¦< • н-., . ;. '
• Число широковещательных сообщений в секунду ' ;?ф
• Число мультивещательных сообщений в секунду
Панель общей статистики (верхняя правая панель на рис. 9.1) показыва-
показывает числовой итог информации, содержащейся в графической панели. По-
Появляется также статистика относительно перехваченных данных. Панель
сообщает, сколько кадров находится в буфере, какая доля буфера использо-
использована, были или нет какие-либо кадры отброшены в связи с переполнением
буфера. Дополнительная статистика предоставляет информацию о сетевой
плате.
Панель статистики сеанса (ниже графической панели) перечисляет се-
сетевые адреса компьютеров, общающихся во время текущего сеанса перехва-
перехвата. Она показывает, сколько кадров находится в сети и в каком направлении
они движутся. Обратите особое внимание на стрелку, так как она использу-
используется в сетевом мониторе для указания направления потока данных (исполь-
(используется также при создании фильтров перехвата). Стрелка всегда указывает в
направлении компьютера, который будет получать информацию. Например,
на рис. 9.1 bigguy в столбце сетевого адреса 1 посылает 31 кадр в PROX
в столбце сетевого адреса 2. PROX посылает 25 кадров назад bigguy.
Панель статистики станции (ниже статистики сеанса) более подробно
представляет информацию из статистики сеанса, перечисляя число байтов
посланных и полученных каждой станцией, представленной в буфере пере-
перехвата. Информация о посланных широковещательных и мультивещатель-
мультивещательных сообщениях особенно полезна для быстрого выявления потенциальных
проблем в сети. Кроме того, может понадобиться исследовать направление
потока данных и размеры различных происходящих обменов данными. Все
это может оказаться потенциальными узкими местами сети.
Перехват трафика вручную '
Пришло время запустить сетевой монитор. Чтобы управлять перехватом
вручную, используется меню перехвата (рис. 9.2). Однако прежде чем на-
нажать Start, необходимо задать размер буфера. Выбор настроек буфера из
меню перехвата позволит сконфигурировать буфер. Используемый по умол-
умолчанию максимальный размер буфера перехвата, равный 8 мегабайтам, мень-
меньше объема оперативной памяти, установленной на машине. Хотя можно
использовать виртуальную память для буфера перехвата, лучше этого не де-
делать для гарантии, что критически важная информация кадра надежно пере-
перехвачена. Microsoft Network Monitor пошлет предупреждение при попытке
ввести размер буфера перехвата больше физической памяти машины. Сооб-
Сообщение говорит: "Запрашиваемый размер буфера может вызывать потерю
кадров в связи с процессом подкачки. Вы уверены, что хотите разместить
буфер этого размера?"
Помимо выбора размера буфера можно также выбрать размер кадра, ко-
который желательно перехватывать. Например, если интересует только ин-
информация заголовка для определенного протокола, то можно задать здесь
эту информацию и не тратить пространство на перехват лишних данных

Семейство сетевых мониторов компании Microsoft
237
¦TJf -О
"Captured Data
Find All Names
Clear Statistics
... Addresses...
* Buffer Settings...
''- f Filler...
. fretworks...
Trigger...
; Dedicated Capture Mode
' Save Configuration
fi;
FS
Рис. 9.2. Режим выделенного перехвата сокращает нагрузку центрального
процессора, помогая тем самым избежать потери кадров во время сеанса перехвата
кадра. Какой размер кадра перехватывается, зависит от определенного ис-
исследуемого протокола. Например, так как мы знаем, что нормальный заго-
заголовок Ethernet равен 14 байтам, можно задать кадр перехвата в 14 байтов и
перехватывать только заголовки Ethernet. Это позволит нам перехватить
73142 кадра с помощью одномегабайтного буфера перехвата. Можно было
бы использовать 34-байтовый кадр для перехвата заголовка IP A4 байтов
для заголовка Ethernet и 20 байтов для заголовка IP). Это очень полезно
при исследовании проблем передачи файлов, которые часто содержат 1200
или больше байтов данных пользователя, которые могут быстро заполнить
буфер перехвата.
Обновление окна статистики перехвата, показанного на рис. 9.1, созда-
создает для центрального процессора нагрузку, которая может быть излишней.
Выбирая режим выделенного (dedicated) перехвата в меню перехвата, мож-
можно избежать нагрузки, связанной с обновлением изображения, и тем самым
предоставить дополнительные ресурсы для перехвата кадров. Как показано
Dedicated Mode on \Etheinet\NET2
Total Frames Captured: 83
Stop and View
Pause
Normal Mode
Рис. 9.З. Меню перехвата позволяет полностью управлять сеансом перехвата.
Здесь же задаются настройки буфера

238
Глава 9
на рис. 9.3, в режиме выделенного перехвата имеется возможность пере-
переключения в нормальный режим, выбрав его из меню перехвата. Можно сде-
сделать все эти переключения во время работы Microsoft Network Monitor и не
потерять кадры. Кроме того, можно приостановить Netmon и продолжить
работу приложения в этом режиме.
Просмотр перехваченных данных
Когда сеанс перехвата закончен, что мы имеем? Сетевой монитор упроща-
упрощает задачу анализа данных, организуя перехваченные данные в несколько
различных представлений и выполняя большую часть анализа протокола.
На рис. 9.4 мы видим сводное представление. Оно полезно для получения
обзора информации, содержащейся в перехваченных данных. Большое
число кадров BPDU на рис. 9.4 являются конфигурационными сообщения-
сообщениями коммутатора.
12 97<
13 88С
14 98
15 38С
16 99
19 012
21 021
23 037
25 04
27 06J
29 074
3i os;
зз 09;
35 i:
37 12
39 137
41 14<
43 16
44 08С2400
44 08/
44 08
44 087
44 08! 2400
44 OS!
0090F2B1929
2400
OO9OF2B1929
2400
0090F2B1929
0090F2B1929
0090F2B1929
C090F2B1929
0090F2BH29
C0SOFJ81929
0090F2B1929
0090F2B1929
0090F2B1929
0O9OF2B1929
0090F231929
0090F2B1929
0090F2B1929
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
4L=
NBT Donuin Name Sow» protocol lumuv
PROX
2400
PROX
PROX
44 09C 2400
44 09CPROX
44 09C 2400
45 17< 0O90F2B1929
0090F2B1929
0090F281929
0090F281529
S3 22< 0090F2B1929
55 237
57 24S
0090F2B1929
0090F2B1929
IEEE 00000
PROX
IEEE 00000
PROX
IEEE 00000
IEEE 00000
IEEE 00000
IEEE 00000
IEEE 00000
IEEE 00000
IEEE 00000
IEEE 0CSO0
IEEE 00000
IEEE 00000
IEEE 00000
IEEE 00000
IEEE 00000
IEEE 00000
PROX
•BROADCAST
PROX
2400
PROX
2406
PROX
2400
PROX
IEEE 00000
00000
IEEE
IEEE
IEEE
IEEE 00000
IEEE 00000
IEEE 00000
BPDU
NBT
BPDU
HBT
BPDU
BPDU
BPDU
BPDU
BPDU
EPDU
BPDU
BPDU
BPDU
BPDU
BPDU
BPDU
BPDU
BPDU
SKB
ARP.RAriARP
ARP RA4ARP
SKB"
SXB
SKB
TCP
TCP
TCP
BPDU
BPDU
BPDU
BPDU
BPDU
BPDU
BPDU
Root BPDU
Root BPDU
Root BPDU.
Root BPDU
Root BPDU
Root BPDU
Soot BPDU
Root BPDU
Root BPDU
Root BPDU
Root BPDU
Root BPDU
Root BPDU
Port 0x8005. Address
Port 0x8005. Address
Port 0x8005. Address
Port 0x8005. Address OO9OF2V
Port 0x8005. Address 0090FV»
Port 0x8005. Address 0090р«Л
Address 0090Fc^
Address 0090Fi%
Address 0090Fi",
Address 0090Fi%
Address 0090F»-',
Address 0090Fo>
Address 0090F2>>
Port 0x8005
Port 0x8005
Root BPDU Priority 0x8000.
MS Refresh req tor KRED
Root BPDU Priority 0x8000.
NS Refresh req tor HRED
Root BPDU Priority 0x8000,
Priority 0x8000.
Priority 0x8000.
Priority 0x8000.
Priority 0x8000.
Priority 0x8000.
Priority 0x8000. Port 0x8005.
Priority 0x8000. Por! 0x8005.
Priority 0x8000. Port 0x8005.
Priority 0x8000. Port 0x8005.
Priority 0x8000. Port 0x8005.
Priority 0x8000. Port 0x8005. Address 0090FJ>>
Priority 0x8000. Port 0x8005. Address 0090F?>
Priority 0x8000. Port 0x8005. Address "
С tree disconnect
Request. Target IP 10 0.0 60
Reply. Target IP 10 0 0 10 Target Hdvr Addr
R tree disconnect
С logoff i X
S logoff 4 X
A F. len 0. soq 16643231-16643231. ack
A F. len 0. seq 139748-139748. ack 166432|
A . len 0. seq 16643232-16643232. ack
Root BPDU Priority 0x8000. Port 0x8005. Address 0090F*,
Port 0x8005.
Port 0x8005
Port 0x8005.
Port 0x8005.
Port 0x8005.
Port 0x8005.
009CV
432i-$
Root BPDU
Root BPDU
Root BPDU
Root BPDU
Root BPDU
Root BPDU
Priority 0x8000.
Priority 0x8000.
Priority 0x8000.
Priority 0x8000.
Priority 0x8000.
Priority 0x8000.
Address .
Address 0090FiJ
Address 0090FJ4
Address 0090FS-*»
Address 0090Fii
Address 0090F*>
. -¦¦ ¦-¦ >Ы
IF»: 1/320
Рис. 9.4. Сводное представление сетевого монитора позволяет быстро определить
аномалии в перехваченных данных -
Добавляя подробное и шестнадцатеричное представления из меню
Window, можно найти такую информацию, как адрес источника и адрес
места назначения кадра. На рис. 9.5 мы видим источник и место назначе-
назначения трафика BPDU, который поглощает большую часть полосы пропуска-
пропускания сети. Вооружившись этой информацией, можно перейти к машине и

Семейство сетевых мониторов компании Microsoft
239
провести небольшое расследование, почему машина заполняет сеть бес-
бесполезной информацией. Это представление дает также данные о протоко-
протоколах, которые нужны для изменения настроек буфера, если пользователя
интересует какой-то определенный аспект. .. . .,.,
Netemfc MoralOf • (Слр(ше:7 (Detail)
«Ф ?* ?*
Hdp
Frame
13
14
15
16
17
И
Tine
12
13
14
15
16
97"
88C
981
38(
995
Src KAC Add
0090F2B1929
2400
0090F2B1929
2400
0090F2B1929
t
Dst
IEfCfc
PROJ
IEEE
PROJ
KAC Add
00000
00000
00000
Protocc
BPDU
HBT
BPDU
КВТ
BPDU
Description
Root
HS
Root
NS
Root
BPDU Priority
Refresh req for
BPDU: Priority
Refresh req for
BPDU' Priority
0x8000.
KRED
3x8000.
HREP
3x8000
Port
Port
Port
0x9005.
< 1E>
0x8005
< 1?>
0x8005
Address
Address
Address
)
0Q90F:-
0090F>r
0G90F;
18 19 0i;0090F2B1929 IEEE 00000 BPDU Root BPDU Priority 0x8000 Port 0x8005 Address 0090F
HERHET 802.3 Lenqth ¦ 72
¦ETHERHET Destination address 0180C2000000
¦ETHERHET Source address 0090F2B1929D
ETHERHET Frame Length 72 @x0048)
ETHERHET Data Length 0x002E D6)
ETHERHET Ethernet Data Hu&ber of data bytes remaining
¦ОС: 0Т DSAP-0x42 SSAP-0»42 С
-BPDU: Root BPDU Priority 0x8000 Port 0x8005. Add:
BPDO: Protocol ID ¦ 0 @x0)
Version ¦ 0 @x0)
Message Type * Configuration
Flags • 0 @x0)
Root ID Priority • 32768 @x8000) !i
Root ID • 0090F2B1929S
Cost - 0 @x0) .
Bridge ID Priority ¦ 32768 @x8000)
Bridge ID - 0090F2B1929S
¦il
BPDO:
BPDU:
«BPDU:
BPDU:
BPDU:
BPDU
BPDU
BPDU:
58 @x0031)
0090F2B19295. Cost 0x0
i.H /,'-\;.i i;. м-
J
00000010 03 00 00 00 00 00 80 00 00 90 F2 Bl 92 95 00 00
00000020 00 00 80 00 00 90 F2 Bl 92 9S 80 OS 00 00 14 00
00000030 02 00 OF 00 00 00 00 00 00 00 00 00 00 00 00 00
00000040 00 00 00 00 00 00 00 00
' f. • ^ _. .. ._;.
¦ • ¦ С - - Е-1
J
F«: 1ЭЛ20
Рис. 9.5. Подробное и шестнадцатеричное представления сетевого монитора
позволяют найти источник и адреса места назначения машины, посылающей
информацию по сети
Сохранение перехваченных данных
После перехвата данных из сети желательно сохранить их в качестве опор-
опорной информации при проведении некоторых сетевых настроек или для
предоставления основы для долгосрочного анализа. В любом случае он бу-
будет сохранен как файл .cap, который можно открыть в сетевом мониторе в
любое время. Кроме того, не забудьте сохранить данные в файле, прежде
чем начинать другой сеанс перехвата, иначе можно потерять перехвачен-
перехваченные данные. Для сохранения перехваченных данных следует выбрать
команду Save из меню File.
Имеется возможность выбрать место расположения, а также диапазон
кадров, которые желательно сохранить. По умолчанию будут сохранены
все перехваченные кадры. Можно также выбрать сохранение отфильтро-
отфильтрованных перехваченных данных. Например, если сконфигурировать
фильтр показа (который мы рассмотрим в следующем разделе), можно

240
Глава 9
сохранить данные только из текущего вывода на экран. Это позволяет
модифицировать файл .cap. Можно также создать несколько файлов .cap
из одного большого перехвата данных, что позволяет сохранить только
интересующие данные. . ...... .... ... ... ,s,,, v . . ч, , , . ,.,.
Фильтрация данных перехвата
В сетевом мониторе используются два вида фильтров. Первым является
фильтр перехвата, а вторым — фильтр вывода. Оба они работают аналогич-
аналогичным образом. Фильтр работает в некотором смысле как запрос, применяю-
применяющийся к базе данных. Он позволяет выбрать часть или подмножество
доступных данных. Например, если удалось сузить проблему до определенно-
определенного компьютера, то можно отфильтровать весь остальной трафик и сосредото-
сосредоточиться только на этом компьютере. Еще одним свойством является
возможность сохранить фильтры и использовать их позже (несколько полез-
полезных фильтров находится на сайте издательства "ЛОРИ" (www.loiy-press.ru).
Это пригодится при попытке исправить определенную проблему. Можно со-
сохранить множество данных, а после выполнения изменений фильтр выполня-
выполняется снова, позволяя тем самым проследить за произошедшими изменениями.
Фильтр перехвата Чтобы создать фильтр перехвата, из меню надо вы-
выбрать пункт filter. Как показано на рис. 9.6, можно фильтровать данные по
протоколу, по адресу или по образцу данных (или по комбинации всех трех).
Capture Filter
~SAP/ETYPE = TC
(Address Pats)
INCLUDE "ANY <¦¦> "ANY
(Pattern Matches]
»**«¦':•;.
Cancel
Help
Load...
Save...
Рис. 9.6. Функции фильтра перехвата похожи на запрос базы данных тем,
что позволяют определить подмножество данных для анализа

Семейство сетевых мониторов компании Microsoft
241
Если желательно фильтровать по протоколу, необходимо выбрать стро-
строку SAP/ETYPE и нажать кнопку Edit line. Появится меню, позволяющее вы-
выбрать тип протокола, который желательно отфильтровать. Чтобы выбрать
один определенный протокол, проще всего отключить все протоколы и за-
затем включить один протокол, который желательно проверить. Хотя диало-
диалоговые окна довольно неудобны для использования, можно быстро перейти
к разделу, щелкая по именованному заголовку и вводя затем первую букву
требуемого протокола или адреса. Это немного лучше, чем прокручивать
длинный список адресов.
Если вас интересует только одна машина, выберите адресные пары и
снова нажмите кнопку Edit line (или просто сделайте двойной щелчок по
выражению). Этот фильтр работает одинаково в режиме перехвата и режи-
режиме вывода и является отличным инструментом, используемым при анализе
общения между серверами и рабочими станциями или между принтерами.
Фильтр перехвата на совпадении с образцом немного сложнее для испо-
использования, так как он требует определенных знаний о месте кадра, где мо-
может появиться определенный образец. Для поиска этой информации
используется анализ существующей перехваченной информации в шестнад-
цатеричной панели. Когда будет найден шаблон для определенного приме-
примера, создайте фильтр перехвата и протестируйте его для проверки, что он
делает то, что нужно. Мы рассмотрим это при анализе шестнадцатеричной
панели.
Фильтр вывода данных Фильтр вывода данных работает почти так
же, как и фильтр перехвата, но действует на уже перехваченных данных.
Он не изменяет содержимое буфера перехвата. С помощью фильтра выво-
вывода данных можно выбрать определенный протокол, адрес или свойство
I
.xpression
E
'1
Expression
ED1750 |ETHERNET)<-->'ANY
I Addiess ] Piotocd ] Property j
Station X Ejection
j
Name lAddiess 1 1 ШЗЕШ
CINPROXY 00104BSJ ->
ED175O 10.0 0 7Г
EDI 750 0060378BI
HW KM DB
HW KM DB
JWH1364
JWH1364
JWH1364
JWH1364
3001.08LJ
08003E0
00600SA
з.оооас;
3001.006
0008C78
il._J lid
j "OK } Cancel ] Help )
Station 2
Name
¦ANY
-BROADCAST
¦NETBIOS Multicast
2400
2400
bigguy
8IGGUY
CINPROXf
CINPR0W
4 I
Addtess J J
FFFFFFF—j
0300000—'
10.0.0.6C
0090276
0090278
10.0.0.61
216.23.7
00104B6
E_*Addiestes... J
Рис. 9.7. Фильтрация адресов упрощает поиск неисправностей с помощью
сетевого монитора

242 i: Глава 9
данных, чтобы помочь отсортировать данные. Выборка делается таким же
образом, как и при создании фильтра перехвата. Однако существует одно
важное различие: можно применять также логические операции AND, OR
или NOT. Эта возможность предоставляет больший диапазон выбора при
создании фильтра, чем это доступно в режиме фильтра перехвата. Как по-
показано на рис. 9.7, появляется меню, позволяющее выбрать адрес, который
желательно проверить. Существует возможность включить или исключить
адрес. Можно также выбрать направление потока информации. Выберите
имя для станции 1 в левом столбце, стрелку направления (помните, что
вершина стрелки указывает направление потока данных), а затем выберите
получателя в столбце станции 2. Например,, на рис. 9.7 фильтр включает
трафик данных из ED1750 во все станции сети, а также трафик из любой
станции сети в ED1750. Это полезно при анализе образцов трафика сервера.
Анализ перехваченных данных
Когда данные перехвачены и применен фильтр вывода данных, наступает
время анализировать кадры. Верхняя панель является итоговой панелью,
которая содержит информацию перечисленную ниже. Эти столбцы можно
переупорядочить, нажимая заголовок столбца и перетаскивая в новое
желаемое положение. '"" ' " "' ; - ~.- • ¦;•¦•• • ¦
• Номер кадра. Microsoft Network Monitor присваивает кадру номер
для целей учета. Он в реальности не появляется в самом кадре, но
добавляется программой, чтобы упростить ссылку на информацию,
находящуюся в перехваченных данных.
• Время. Время, также присваиваемое Microsoft Network Monitor, позво-
позволяет узнать, сколько времени проходит между кадрами. Это предостав-
предоставляет полезную информацию при выполнении анализа сетевой
производительности. Время, которое выводится в этом столбце, кон-
конфигурируется в параметрах меню Display. Существуют три возможно-
возможности: время дня, секунды с начала перехвата и секунды от прохождения
предыдущего кадра. Выбирая время дня, можно сопоставить инфор-
информацию из журнала событий Windows с информацией, перехваченной
Microsoft Network Monitor. Такое сопоставление допустимо для мощного
поиска неисправностей при появлении ошибочных сообщений.
• Адрес MAC источника. Это устройство, которое прежде всего создает
кадр. Есть три возможности для вывода адреса MAC, задаваемые из
меню Options. Можно выбрать вывод имени, которое присвоено адре-
адресу MAC в адресной книге Microsoft Network Monitor; можно выбрать
вывод просто адреса MAC (поведение по умолчанию); или можно вы-
выбрать вывод имени поставщика, связанного с первыми шестью байта-
байтами адреса MAC. Это бывает полезно при попытке найти неизвестное
устройство в сети.
• Адрес MAC места назначения. Это аппаратный адрес места назначения
пакета.
• Протокол. Это основной протокол кадра.

Семейство сетевых мониторов компании Microsoft - 243
• Описание. Это поле предоставляет суммарную информацию о кад-
кадре. Описание также конфигурируемо с помощью параметров меню
Display. Существует две возможности: последний протокол в кадре
¦:'~"'%Sr- или автоматический выбор на основе используемого фильтра вывода.
Часто можно собрать достаточно информации из сводки, чтобы полу-
получить представление о том, что происходит в сеансе перехвата. Трех-
Трехходовое квитирование TCP легко обнаружить по описанию. Здесь
часто показывается информация о флагах TCP.
• Другой адрес источника. Чтобы увидеть это поле, следует переместить
ползунок в нижней части итоговой панели. Другой адрес источника
является адресом другого протокола, содержащимся в кадре.
• Другой адрес места назначения. Это адрес другого протокола, содер-
содержащийся в кадре.
w • Тип другого адреса. Этот адрес сообщает, какой протокол содержат
поля другого адреса.
Детализированная панель находится в середине. Здесь происходит бо-
большая часть анализа. Microsoft Network Monitor использует файлы .dll и
файлы .ini для синтаксического разбора протокола. Существуют, напри-
например, файлы TCP.dll и TCP.ini, хранящиеся в каталоге синтаксического раз-
разбора Microsoft Network Monitor. Чтобы правильно проанализировать
протоколы, которые Microsoft Network Monitor не понимает, необходим
анализатор .dll и файл .ini. Можно написать их самостоятельно или получить
их от независимых поставщиков.
Шестнадцатеричная панель находится в нижней части и содержит спе-
специальную информацию об анализируемом кадре. Например, рассматривая
трассировки протокола РОРЗ, мы замечаем, что вся информация находит-
находится в шестнадцатеричной трассировке, а не в детализированной панели.
Знание того, как читать шестнадцатеричную трассировку, поможет создать
специальные фильтры перехвата (см. рис. 9.8).
На рис. 9.8 изображен транспортный кадр NetBIOS, который перено-
переносится поверх TCP, IP и протокола Ethernet. Этот конкретный кадр являет-
является дежурным кадром сеанса. Если требуется создать фильтр перехвата,
который перехватывает только дежурные кадры сеанса NetBIOS (возмож-
(возможно, для анализа влияния дежурного трафика NetBIOS на сеть), нам понадо-
понадобится использовать смещение образца. Мы расширяем раздел NBT
трассировки, щелкая на знаке плюс рядом с итоговой строкой NBT. Затем
выбираем строку NBT: packet type. Отметим, что соответствующий раздел
шестнадцатеричной трассировки автоматически подсвечивается, когда мы
выбираем различные строки в детализированной панели. Когда мы вы-
выбираем packet type = session keep alive, подсвечивается шестнадцатеричное
число 85 в строке 30. Теперь мы можем отсчитывать, пока не увидим, что
шестнадцатеричное число 85 находится в смещенной позиции шестнадца-
теричного 36 с начала кадра. Вместо отсчета можно посмотреть в нижний
правый угол экрана Microsoft Network Monitor. Там мы видим, что это сме-
смещение 54 (десятичное) хЗб (шестнадцатеричное). Эту информацию можно
ввести в шаблон совпадения фильтра перехвата, как показано на рис. 9.9.

244
Глава 9
Netmxfc Momto. - ICafrfina:7 IDeladll
5? Et E« ЕирЦ> lodt Qpteni
Help
Frame Time Src MAC Add Dst MAC AddlProtocdDescription
59 08«b:
S9 26;
61
63 287
6S 16S
>iggu у
0090F2B1929
2?< 0090F2B1929
0090F281929
biggu у
Я1ЛЯТ
PROX
IEEE
IEEE
IEEE
PROX
00000
00000
00000
TCP
BPDU
BPDU
BPDU
UDP
SS Session KeeD Alive Len A
A . len 0. seq 389B98092-389898092. ack 1Г""
Root BPDU Priority 0x8000. Port 0x8005. Address 0090Г;
Root BPDU: Priority 0*8000. Port 0x800S. Address 0090Ff"
Root BPDU Priority 0x8000. Port 0x8005. Address 0090F«
Src Port Dnknovn. CS42); Dst Port. Unknown A45). I'
TCP. Reserved - 0 @x0000)
-TCP Flags ¦ 0x18 AP
TCP .0
TCP 1
TCP: .. .1
TCP: 0
TCP
TCP
TCP Windov • 7650 @xlDE2)
TCP Checksum • 0x5 IDA
TCP Urgent Pointer • 0 @x0)
TCP Data Number of data bytes remaining ¦ 4 @x0004)
—HBT SS: Session Keep Alive. Len. 0
Ho urgent data
Acknowledgement field significant
Push {unction
Ho Reset
Ho Synchronize
No Fi
-HBT Packet Flags • 0 @x0)
КВТ 0 • Add 0 to Length
HBT Packet length • 0 @x0)
00000000 00 90 27 84 SB 1A' 00" 90 27 ~64" FA D6 9 o"5 00
00000010 00 2C AD 29 40 00 80 06 39 5C 0A 00 00 0A 0A 00
00000020 00 3D 00 8B OD FF 00 02 21 90 17 3D 5F 6C 50 18
00000030 ID E2 51 DA 00 00 ЁЁЯОО 00 00
¦*Fsr"FdT~r
..!>¦ С 9\ ....
-,i IE.- IP.
J
iLL
IPtckatTyp.
Рис. 9.8. Фильтрация адресов упрощает поиск неисправностей с помощью
сетевого монитора . ,
Дополнительные 00, добавленные после 85, являются тем, что следует в
шестнадцатеричной трассировке и сокращает число ложных совпадений.
Возможная фильтрация по двум или трем числам обеспечивает более тон-
тонкое управление процессом перехвата данных.
Модификация вывода Существует пара настроек, которая облегчает
изучение трассировок Microsoft Network Monitor. Первой является настрой-
настройка текста вывода, который задается выбором шрифта из меню Display. Более
функциональным изменением является присваивание определенным прото-
протоколам специальных цветов. Можно например, присвоить красный цвет TCP,
зеленый Browser, а желтый для трафика NetLogon. Это значительно облегча-
облегчает трассировку определенных взаимодействий в перехваченных данных с
большим числом кадров. Можно выбирать цвет переднего плана, который
изменяет только цвет шрифта, или цвет фона, или и то и другое.
Другим свойством Microsoft Network Monitor является дублирование, ко-
которое выбирается из меню Window. При этом перехваченная информация
копируется в другое окно, позволяя работать с обоими окнами, как если бы
они были различными перехватами информации. Можно использовать
различные фильтры вывода и сравнивать два представления одной и той
же перехваченной информации. Чтобы помочь в отслеживании этого про-
процесса, можно добавить также в том же меню в окно метку. Это позволит

Семейство сетевых мониторов компании Microsoft
245
¦ Pattern Match
i Offset (in hex) [36
' <•" From Start of Frame
; С From End of Topology' Header
j Pattern 8500
' 1 (? Hex Г ASCII '
OK
Cancel
Help
Рис. 9.9. Фильтр перехвата по совпадению образца требует образец и смещение
избежать путаницы, связанной с работой с двумя представлениями с одним
и тем же именем. При работе с дубликатом можно закрыть одно окно, не
влияя на содержимое другого окна. Когда настройки будут сконфигури-
сконфигурированы желательным образом, можно сохранить их, выбирая Save configuration
из меню Display.
Выбирая пункт Insert comment frame из меню Tools, можно добавить ин-
информацию в файл .cap, чтобы помочь интерпретировать данные в другое
время или с целью тренировки. Можно вставить два различных вида кадров:
кадр закладки и кадр комментария. Данные будут появляться в трассировке
как кадр комментария или закладки, и это позволит ввести сообщение, кото-
которое будет храниться в кадре (см. рис. 9.10). Можно также выбрать коммента-
комментарий или закладку из списка протоколов при создании фильтра вывода. Это
полезно для обильно документированных кадров .cap, а затем можно будет
распечатать результаты. При добавлении комментариев в файл .cap не стоит
включать их статистические вычисления, так как это будет портить показа-
показатели о том, сколько кадров передано во время периода перехвата. Если ана-
анализируется не этот аспект трафика, то не имеет значения, включен ли кадр
комментария в статистику перехвата.
Можно передать также кадр комментария по действующей сети, чтобы
помочь в поиске определенных кадров, когда себя проявляют некоторые
сетевые проблемы. Это включает использование полной версии Microsoft
Network Monitor и выполнение его в двух экземплярах, чтобы оба передава-
передавали и получали одновременно. При использовании закладки можно собрать
вместе некоторый массив информации в конечном разделе кадра закладки,
как показано в детализированной панели на рис. 9.10.
Система безопасности сетевого монитора
При тех мощных возможностях, которые заложены в сетевом мониторе,
очень важно принять соответствующие меры безопасности для защиты сети
от неправильного использования этого инструмента. Компания Microsoft
уже реализовала одно свойство безопасности в серверных продуктах,

246
Глава 9
iai [bi
bi I+Th raei wKh.i i ? I
frame
Til
Src НАС Add Pst MAC Add!
Description
iptio
вршГ
Root BPDU: Priority 0x8000. Port 0x8005. Address 009Ш»|
NS Registration req ior PR0X*-m-*-m-+++<-+*
N3 Registration req ior PROX-м- hhiiimi I
Root BPDU: Priority 0x8000. Port 0x8005. Address """"¦^-J
1.902
1 936
2 687
3 915
0090F2B1929
PROX
PROX
0090F2B1929
IEEE 00000
•BROADCAST
BROADCAST
IEEE 00000
BPDU
NBT
HBT
BPDU
0 000 4C4F4ES44F5 4E4SS457S24 COKMEHTldfg
«FRAME Base frame properties
¦ETHERNET ETYPE - 0x1984 Protocol • Unknown
-TRAIL FRAME TYPE ¦ BookMark
TRAIL Trail ID ¦ SMST
TRAIL:
TRAIL
TRAIL
-TRAIL
Special Frame Type
Block Statistics
Use this Frame as a Statistics Endpoint
Sho» Statistics (or all Fraiies. even it Filtered
TRAIL Frames in
Kill Tot«l
TRAIL
TRAIL:
TRAIL:
TRAIL:
TRAIL-
TRAIL
TRAIL
-TRAIL.
TRAIL
TRAIL
AverageSiz<
Minimum Si
Maximum Si
Total Time
Average Ti
Minimum Ti
Maximum Ti
Hock • 7
CMSE
¦ 88
i ¦ 72
1-110 - ','. •
' 6900 ll '
л Betveen Frames - 11S0 0
л Betveen Frames - 125
ie Batveen Fra»es > 2013
Bytes Per Second ¦ 89
BandVidth consumed tor 10 Kega Bits Per Second ¦
BandVidth consumed for 100 Mega Bits Per Second '
0 0У.
0 OX
00000000 <E 45 54 57 52 4B 4D 4F 4E S4 4F 52 19 84 24 4D KETWRKMONTOR aSM
00000010 53 54 00 00 00 00 Ы 00 00 00 62 6F 6F 6B 6D 61 ST f bookma
00000020 72 6B 00 rk
1 .:. ^
— fl
iT*i(8»<ef<»aii*imeir»eec»i * if*W17 0!r 0[xOJ
LOW)
Рис. 9.10. Кадр комментария предоставляет место для записи примечаний,
которые остаются в файле перехвата
которое состоит в том, что сетевой монитор будет контролировать трафик
только между сервером, на котором он выполняется, и остальной сетью.
Это защитит вас от некорректного использования. Однако версия, которая
поставляется вместе с Systems Management Server (SMS), способна перехва-
перехватывать кадры, посланные на компьютер или из любого компьютера в сети,
а также перехватывать кадры в удаленной сети.
Защита с помощью пароля
Для сетевого монитора можно задать два пароля с помощью пиктограммы
агента мониторинга в панели управления; это пароль вывода и пароль пе-
перехвата, показанные на рис. 9.11. Пароль вывода разрешает доступ к сохра-
сохраненному файлу перехвата (.cap). С помощью этого пароля разрешается
только открыть сохраненный ранее файл перехвата. Он не разрешает пе-
перехватывать новые данные. Это применимо только к Microsoft Network
Monitor, установленному на машине, на которой пароль был задан. Он так-
также не защищает файл .cap от просмотра в сети с помощью другого Microsoft
Network Monitor. Другими словами, это защита с помощью пароля установ-
установки программы и связанного с ней агента — а не данных.

Семейство сетевых мониторов компании Microsoft
247
Network Monitoring Password Change
You can control access to Network Monitor with two types ot
passwords. The Display password will restrict a user to viewing only
previously saved capture files The Capture password allows the user
to capture data, as well as to view capture files.
Old Capture Password
Password:
Display Password
Password:
Confirm: |
- Capture Password
Password I
Confirm:
|
Enter the old capture
password for validation.
This password will only
grant permission to view
previously saved capture
files.
This password will grant
permission to capture
frames and to view capture
files.
OK
J Cancel j No Password
Help
Рис. 9.11. Апплет агента сетевого монитора в панели управления предоставляет
базовую безопасность для сетевого монитора
Пароль перехвата разрешает неограниченный доступ к сетевому мони-
монитору. С помощью этого пароля можно открывать сохраненные файлы пере-
перехвата, а также создавать новые перехваты данных. Пароль запрашивается
при каждом запуске Microsoft Network Monitor. Если ввести пароль перехва-
перехвата, то имеется полный доступ ко всем свойствам; если ввести пароль вывода,
то можно выводить только файлы .cap.
Важно задавать эти пароли на удаленных рабочих станциях и серверах,
на которых установлен агент. Если служба выполняется без защиты паролем,
то любой человек с версией SMS сетевого монитора может соединиться с ва-
вашим сервером и использовать его для перехвата данных из сети. Эти пароли
должны быть защищены, поскольку не существует способа восстановить их
иначе, как удалить и снова выполнить установку Microsoft Network Monitor
и связанных с ним агентов. Удаление ключа защиты в службе ВН в реестре
не работает для восстановления при потерянном пароле.
Установка сетевого монитора:
обнаружение других мониторов ,
Чтобы защитить свою сеть от неавторизованного просмотра, сетевой мони-
монитор может легко определить другие экземпляры программы в сети. Он может
сделать это независимо от того, работает или нет программа. Как показано на
рис. 9.12, если драйвер установлен на машине, он будет сообщать имя

Other Netwoik Monrtoi Installations
Total Installed: 4 Total Running 2
Total Capturing 1
Machine Name jUsei Name jCuiient State
hgguy
PR OX
TERESA
kitchen
pfcx
MiED
¦(Сарйш..
Driver is installed
Running
Running
Adaptei Addiess IVeuion
ШМШШ Tl.XII
00902734881A
003CI2764FAD6
00&05F0FC84A
J
•&!¦
Г Add Names to Addtess Database
~0K I Help | Re.ieshList
.11
У
Рис. 9.12. Инструмент обнаружения установок сетевых мониторов позволяет
управлять использованием Microsoft Network Monitor
машины, имя зарегистрированного на компьютере пользователя, ад-
адрес Ethernet машины, номер версии программы и перехватывает ли про-
программа данные, или просто установлена. Чтобы получить эту информацию,
необходимо выбрать в меню Tools пункт Identify network monitor users
(Идентифицировать пользователей сетевого монитора). Важно отметить,
что если имеются сетевые сегменты, разделенные маршрутизатором, кото-
который не пересылает мультивещательные сообщения, то невозможно будет
определить установки сетевого монитора в другом сегменте, не соединив-
соединившись с этим сегментом. Это связано с тем, что Netmon использует суффикс
NetBIOS для объявления о своем присутствии в сети. Суффикс BE объявля-
объявляет агента сетевого монитора, а суффикс BF объявляет в сети само приложе-
приложение сетевого монитора. Если они не пересылаются, то необходимо будет
соединиться с определенным сегментом, чтобы определить незаконные
установки этих инструментов.
После выбора пункта меню "Определить пользователей сетевого мони-
монитора" машина Netmon посылает запрос станции BONE, как показано в сле-
следующей распечатке. Протокол BONE (сокращение от Bloodhound Oriented
Network Entity, что может быть приблизительно переведено как "Сетевая
ищейка") используется сетевым монитором, чтобы он мог общаться. Этот
запрос станции является очень маленьким кадром многоадресной рассыл-
рассылки 802.3, который использует только 29 байтов.
BONE: Station Query Request С @x00)
BONE: Signature = RTSS
BONE: Command = Station Query Request С
@x00)

Семейство сетевых мониторов компании Microsoft 249
BONE: Flags = 0x00
BONE: Bone Data: Number of data bytes remaining = 0
| @x0000)
Ответ направляется в машину, которая послала запрос, и является мале-
маленьким кадром 802.3, в этот раз требующим около 125 байтов. Ответ сообща-
сообщает статус драйвера; 0x00000003 означает, что драйвер установлен и
активен, но не перехватывает данные. Он содержит версию драйвера, ма-
машину, адрес MAC машины и имя любого пользователя, которое было скон-
сконфигурировано при конфигурировании драйвера. ¦-..'..
BONE: Station Query Response R @x01) ¦ •• ¦ - • ¦'
BONE: Signature = RTSS
BONE: Command = Station Query Response R @x01)
BONE: Flags = 0x00
BONE: REsponse Data Length = 96 @x0060) .
BONE: Station Query Flags = 0x000000003 ' .
', , BONE: Station Query Version 1.01
BONE: Station Query License Number = 0x00000000
BONE: Station Query Machine Name = TERESA
BONE: Station Query User Name = MrED
BONE: Station Query Node Address = 00805F0FC84A
BONE: Bone Data: Number of data bytes remaining = 0
@x0000) ,,,, _,. . ,;. . ; ¦.-*-. , • - r
Сетевой монитор Systems Management Server 1.2
Сетевой монитор, который поставляется вместе с SMS 1.2 (v4.00.351), рабо-
работает в основном так же, как сетевой монитор из NT 4.O. Однако есть неско-
несколько дополнительных свойств, которые делают его значительно более
полезным инструментом для перегруженных сетевых администраторов.
Дополнительные свойства
Возможно, наиболее мощным дополнительным свойством, предоставляе-
предоставляемым полной версией сетевого монитора, является возможность соединять-
соединяться с удаленными агентами, выполняющимися на других машинах. Делая
это, можно увидеть сетевой трафик, обычно невидимый в сегментированной
разделенной коммутаторами сети.
Используя свойство соединения с удаленной сетью, версия Netmon SMS
может соединиться с другим сервером NT, рабочей станцией или машиной
Windows 95 или 98, на которой установлен и выполняется агент сетевого мо-
монитора. Агент сетевого монитора устанавливается как служба Windows NT
и при желании может быть настроен для автоматического запуска для об-
облегчения использования удаленного поиска неисправностей. При желании
служба может быть оставлена с ручным управлением и запускаться удален-
удаленно с помощью утилиты NETSVC из NT Resource Kit. Эта утилита позволяет
запрашивать, перечислять, запускать и останавливать службы на удаленных
машинах Windows NT.

250 Глава 9
Синтаксис
Netsvc
Netsvc \\имя_компыотера /команда
Netsvc
Netsvc
Netsvc
\\имя_компьютера
\\имя_компьютера
\\имя_компьютера
/list
/query
/start
"агент
"агент
сетевого
сетевого
монитора"
монитора"
Установка и конфигурирование агента сетевого монитора Windows 9.x
Установка и работа агента сетевого монитора Windows 9.x не совсем прямо-
прямолинейна. Агент находится на на сайте издательства "ЛОРИ" (www.lory-press.ru)
в каталоге \admin\nettools\Netmon и состоит из двух частей. Имеется драй-
драйвер протокола, который предоставляет показатели производительности сис-
системному монитору для адаптеров NDIS 3.1. Это позволяет системному
монитору просматривать статистику сетевого трафика. Агент сетевого монито-
монитора использует некоторые функции, предоставляемые драйвером протокола для
передачи информации назад в приложение Netmon. Вот шаги, необходимые
для установки агента сетевого монитора Windows 9.x.
1. Откройте сетевой апплет в панели управления и щелкните
по кнопке Add. '»_."
2. Выберите тип сетевого компонента и сделайте двойной щелчок
по службе.
3. В диалоговом окне службы щелкните по кнопке Have disk. '"
4. Для установки из каталога используйте каталог на \admin\nettools\
Netmon на компакт-диске Windows 9.x.
5. В окне выбора сетевой службы щелкните по агенту Microsoft Network
Monitor и подтвердите ОК.
Приведенные выше шаги установят драйвер протокола и агента. Что-
Чтобы сконфигурировать агент, вернитесь в сетевой апплет, выберите Micro-
Microsoft Network Monitor Agent и щелкните по свойствам. Это приведет к
появлению окна, аналогичного тому, которое мы видели ранее для машин
Windows NT, где можно присвоить пароль перехвата и пароль вывода.
Этот пароль должен задаваться, когда агент не выполняется и системный
монитор не выводит данные производительности сети.
Когда агент будет установлен и сконфигурирован, наступает время для
его запуска. Это делается из команды запуска (run) вводом nmagent. Агент
может останавливаться из команды запуска (run) с помощью ввода nmagent
-close. Агент можно также запустить как службу на машине Windows 9.x, делая
следующие изменения в реестре.

Семейство сетевых мониторов компании Microsoft
251
Запуск агента сетевого монитора как службы
Выберите следующую строку в реестре на машине Windows 9.x
HKEY_LOCAL_MACHINE\Software\Microsoft\CurrentVersion
\RunServicesOnce
Добавьте новое строковое значение nm agent
Измените значение новой строки и введите nmagent.ехе
Так как агент выполняется теперь как служба на машине Windows 9.x, он
будет продолжать выполняться независимо от того, зарегистрирован на
компьютере пользователь или нет. Чтобы остановить службу в любое время,
используйте команду nmagent -close из окна запуска (run).
Соединение с удаленными агентами .
Чтобы соединиться с удаленным агентом, выберите networks из меню captu-
capture. Появившееся окно выбора сети перехвата перечисляет все установлен-
установленные на машине сетевые адаптеры и один дополнительный адаптер,
называемый удаленным (remote). По умолчанию его состояние определяет-
определяется как разъединенное и неизвестного типа. При успешном запросе сетевого
агента можно просто сделать двойной щелчок по удаленной неизвестной
сети, и появится окно, показанное на рис. 9.13. Введите имя машины одного
из агентов, который будут возвращен этим запросом, и должно будет устано-
установиться соединение. Если агент защищен паролем, то появится диалоговое
окно, запрашивающее пароль. После соединения сеанс работает таким же
образом, как и локальный перехват. Можно также настроить буфера пере-
перехвата и сконфигурировать фильтр перехвата, но различия в способе работы
сеанса нет.
Connect To Network Monitoring Agent
Current Status: No Connection
Connect
New Connection Information:
Agent Name: JTERESA
User Comment: |PR0X:|
Agent status update frequency
Every \2
Г~ 2,k>w Link
seconds
Cancel
Рис. 9.13. Чтобы соединиться с удаленной сетью, введите имя поддерживающей
агент машины

252
Глава 9
Мастера-помощники
Сетевой монитор SMS 1.2 включает несколько мастеров, которые помогут
найти некоторые важные данные. Это отчеты (они не являются в действи-
действительности мастерами) верхнего пользователя и распределения протокола.
Другие функции мастеров — поиск всех маршрутизаторов в файле перехва-
перехвата и поиск всех имен в файле захвата, а также они могут разрешать адреса
по именам. Недостаток этих отчетов в том, что не существует способа со-
сохранить информацию помимо печати экрана (print screen) для перехвата
отчета с экрана. Это существенный недостаток, так как часто полезно рас-
распечатать данные, в частности, отчет верхнего пользователя. Рассмотрим
отчет верхнего пользователя.
Отчет верхнего пользователя активируется в режиме вывода (когда выво-
выводятся перехваченные данные в противоположность просмотру статистики
сеанса). Отчет выбирается из меню Tools и имеет возможность показать,
сколько выводить верхних пользователей, и основывается ли список на ад-
адресе канала данных или на адресе MAC. Можно также применить текущий
фильтр вывода или выбрать игнорирование фильтра вывода и основывать
отчет на всем файле перехвата. Как можно видеть на рис. 9.14, отчет пере-
перечисляет имя, адрес, число кадров и процент числа кадров и размера кад-
кадра. Эта информация может помочь при планировании и расширении
сети, а также при обнаружении нарушений эксплуатации сети.
TOP USERS
Top Sender By Number of Frames, FAei Applied
Name
UNKNOWN
UNKNOWN
Address
10.112.201.80
10.112201 140
Frames
12
13
X Frames
48
52
X Filtered Frames
48
52
Bytes
2448
1722
KBytes
58
41
5 J
«1 1 >Г
Top Recipient By Number of Frames. Fdter Applied
Name
UNKNOWN
UNKNOWN
Address
10.112201.140
10.112.201.80
Frames
12
13
X Frames
48
52
X Filtered Frames
48
52
Bytes
2448
1722
X Bytes
58
41
X Filte|
58
41
Help
Рис. 9.14. Отчет верхних пользователей Netmon может помочь при планировании
сети

Семейство сетевых мониторов компании Microsoft
253
Отчет о распределении протоколов доступен таким же образом, как и
отчет верхних пользователей: из меню Tools в режиме вывода. Возможно-
Возможности этого отчета включают перечисление всех протоколов в кадре, сообще-
сообщение о последнем протоколе в кадре и сообщение о первом действующем в
кадре протоколе. Кроме того, можно выбрать дальнейшее ограничение на
отчет, применяя текущий фильтр вывода к отчету. Этот отчет может стать
существенной помощью при попытке выявить аномалии в сети. Однако
чтобы эта информация была наиболее полезна, необходимо знать, каким
является нормальное распределение для сети. Если, например, сеть обыч-
обычно имеет очень немного кадров ARP_RARP, но внезапно ими заполняется,
есть хорошая исходная точка для поиска. Если же произошел внезапный
всплеск пакетов UDP, это будет иметь другое значение. Знание того, что
является нормальным для сети, трудно переоценить. Как можно видеть на
рис. 9.15, отчет перечисляет каждый протокол, число кадров и байтов и
процент для перехваченных данных. _>.„. , ,.
Protocol Distribution Report
25 Total Frames in Capture
4170 Total Bytes in Capture
25 Total Frames which Passed the Filter
4170 Total Bytes which Passed Filter
All Protocols in each Frame Calculated. Filter Applied
Help
Protocol
ETHERNET
FRAME
icmp ¦
IP
MSRPC
NBT
R SRVSVC
SMB
TCP
Frames
25
25
8
25
4
16
2
16
17
Bytes Claimed
350
0
320
500
192
64
96
2308
340
X Frames
100
100
32
100
16
64
8
64
68
% Bytes
8
0
7
11
4
1
2
55
8
% Filtered Frames
100
100
32
100
16
64
8
64
68
i
or1*
7
1
4
1
2
5
8,r|
«I i >Г
Рис. 9.15. Отчет о распределении протоколов Netmon помогает в обнаружении
сетевых аномалий
Поиск сетевых адресов по имени позволяет вводить имя компьютера, а
поиск найдет соответствующий адрес MAC. Это не очень сложно выпол-
выполнить в сети TCP/IP, так как можно сделать ping имени хоста и затем полу-
получить информацию из кэша ARP с помощью команды ARP -а. Однако он
может также использовать SAP, DNS и запрос базы данных SMS, поэтому
это может быть более мощное решение. Если происходит обычная провер-
проверка адреса MAC, часто быстрее перейти в окно CMD и сделать ping и ARP -а.
Как мы видим на рис. 9.16, когда имя разрешено, будет выведена вся

Find Network Addresses From Name
Name: |teresa
Local Machine Information
Run Query
[TERESA
Aliases:
Addresses:
Ogtions
Keep Names
Type
IP Address:
MAC Address:
Address | I
10.0.0.11 , • M
00 80 5F OF C8 4A (Ethernet] '' W
<l 1 >Г
fione
Help
Рис. 9.16. Поиск сетевого адреса из запросов имени нескольких источников
для разрешения имени
'*¦ ' . Ц'': ='¦• '. :
найденная о нем информация. Выбор только тех служб, которые присутст-
присутствуют в сети, может оптимизировать этот процесс. Кроме того, можно уско-
ускорить процесс, делая локальную базу данных ADR первым источником,
который будет запрашиваться с помощью кнопок "плюс" и "минус" рядом с
окном выбора службы.
Конфигурирование триггеров
Триггер проверяет кадры по мере их прохождения. Сетевой монитор соби-
собирает данные, чтобы найти кадры, удовлетворяющие некоторым критери-
критериям. Если они удовлетворяют заданному условию, то сетевой монитор
выполнит некоторые заданные действия. Это весьма мощный инструмент,
открывающий почти неограниченные возможности. Очень простой триг-
триггер, который не даст потерять данные во время сеанса мониторинга, созда-
создается с помощью выбора триггера на пространстве буфера, выбирая 100%
для задания пространства буфера и задавая затем действие триггера как
остановку перехвата.
Чтобы несколько усовершенствовать этот триггер, напишите простой
пакетный файл, который будет выполнять команду net send, уведомляя, что
перехват данных остановлен, а затем прикажите триггеру выполнить этот
пакетный файл (с расширением .bat), когда перехват данных остановится.

Семейство сетевых мониторов компании Microsoft 255
Этот пакетный файл может состоять только из одной строки и выглядеть
как файл, представленный ниже. Его можно написать в notepad и затем пе-
переименовать файл с расширением .txt в файл с расширением .bat и указать
в командной строке его расположение.
Простой пакетный файл, уведомляющий при остановке
перехвата данных ¦ .>.
Net send administrator the capture has ceased! 'ic i,•••¦'•'• <¦
Примечание:
Net send будет использовать следующее: имя пользователя,
имя машины или *, означающее "все".
Сообщение следует за местом назначения и не требует " "
Использование триггеров может стать очень сложным, когда вводятся
элементы смещения шаблона. Используя смещения шаблона, сетевой мони-
монитор может идентифицировать широкое множество событий и выполнить
все, что можно выполнить из командной строки — включая другой экземп-
экземпляр сетевого монитора на другой машине. Использование шестнадцатерич-
ной панели для идентификации смещения и шаблона для определения
события, которое будет за этим инициироваться, может определить эти
смещения шаблона. Это делается таким же способом, который рассматри-
рассматривался ранее в этой главе в разделе о разработке фильтров перехвата. "¦¦'v
Автоматический запуск сетевого монитора Если требуется авто-
автоматически запускать сетевой монитор либо с помощью пакетного файла с
триггером, либо с помощью службы планировщика Windows NT (команда
AT), можно использовать следующие ключи командной строки. Каждый
из этих ключей изменяет команду netmon. Пример пакетного файла вклю-
включен в каталог batch на сайте издательства "ЛОРИ" (www.lory-press.ru). Что-
Чтобы облегчить использование Netmon из командной строки, добавьте
каталог с исполняемым файлом в путь доступа компьютера, изменяя пере-
переменную path системного окружения. , ^ r ,r, ,. ,.т. ,,.,-
• /autostart — заставляет сетевой монитор запустить перехват данных
немедленно после запуска. Пример: netmon /autostart.
• /remote computer - computer является именем удаленного агента, с которым
> желательно соединиться. Пример: Netmon /remote exchange. ¦; ¦
• /net number - number определяет соединение с указанным сетевым ин-
интерфейсом. Эту информацию получают при помощи команды ne-
networks из меню capture. Пример: Netmon /net 2 (запустит Netmon,
используя интерфейс сети #2, указанный в диалоговом окне сетей, но
не начнется перехват данных, так как не определен ключ /autostart).
• /capturefilter path — определяет фильтр перехвата, который будет ис-
использоваться при работе сетевого монитора. Path задает расположение
определенного фильтра перехвата.

256 ¦ Глава 9
• /displayfilter path — определяет фильтр вывода, который будет загру-
загружаться при запуске сетевого монитора.
• /buffersize number— задает размер буфера в байтах (одномегабайтный
буфер перехвата будет определяться как /buffersize 1024000).
• /quickfilter type, address — указывает, что сетевой монитор начнет пере-
перехват данных сразу после запуска, и будет фильтровать на указанном
адресе.
• /autostop — заставляет сетевой монитор остановить перехват дан-
данных, когда буфер заполнится. Пример: Netmon /autostart /buffersize
1024000 /autostop (запускает Netmon и немедленно начинает пере-
перехват данных с буфером перехвата в один мегабайт. Когда буфер пере-
перехвата заполнится, он остановится).
Network Monitor 2.0 ,лн ^ :
При запуске Systems Management Server Network Monitor версии 2.0
(V5.00646) можно подумать, что встретился со старым другом. Это полная
версия Windows 2000 Network Monitor. Интерфейс практически такой же,
и большинство утилит работает так же. Однако некоторые вещи измени-
изменились и появились новые свойства.
Новые свойства г„»_ _11 ^-^-„„.--^ '.....'
Программы-эксперты — шесть экспертов, поставляемых вместе с Network
Monitor 2.0, перечислены ниже.
• Эксперт среднего времени ответа сервера вычисляет среднее время,
которое требуется серверу для ответа на запрос пользователя данных.
Он может использовать SMB, специальные порты TCP или специальные
сокеты IPX для получения этих чисел, выраженных в секундах.
• Распределение свойств вычисляет статистики кадров для определенно-
определенного свойства, найденного в кадрах перехваченных данных. Эти свойства
могут быть весьма специальными, такими как прием HTTP.
• Утилита объединения протоколов рекомбинирует данные транзак-
транзакции, которые были посланы по сети в множестве кадров. Этот экс-
эксперт может собрать все фрагменты вместе на основе информации,
которая содержится в кадрах. ¦.; ¦ j ¦. :..;-!/
• Эксперт распределения протоколов проверяет перехваченные дан-
данные и предоставляет статистики о пакетах почти таким же образом,
как мастер распределения протоколов в продукте 1.2.
• Эксперт пересылки TCP находит кадры TCP, которые были пересланы
на один и тот же компьютер. Это полезно при выявлении проблемных
компьютеров.

Семейство сетевых мониторов компании Microsoft
257
• Эксперт верхних пользователей находит верхних отправителей и по-
получателей данных в файле перехвата, проверяя адреса источника и
места назначения, содержащиеся в кадрах.
SMS 2.0 Platform Software Development Kit (SDK) позволяет разработать
своих собственных экспертов, их можно также купить у независимых по-
поставщиков. Эксперты запускаются из меню tools expert при работе в режи-
режиме показа. Как можно видеть на рис. 9.17, эксперт среднего времени ответа
сервера может быстро выделить проблему со временем ответа сети. На ри-
рисунке сервер 11.0.0.206 имеет среднее время ответа 2.378751 секунд, в то
время как все остальные места назначения имеют времена ответа в долях
секунды. Чтобы еще больше ухудшить ситуацию, этот медленный сервер
используют десять пользователей. Раньше этот процесс превращался в де-
десяток телефонных вызовов (что затрудняло выявление и исправление
проблемы). Но теперь, когда благодаря мониторингу и анализу наши дейст-
действия носят профилактический характер, можно решить проблему без вся-
всяких телефонных звонков. Пользователь только после решения проблемы
заметит, что сервер стал видимо работать быстрее.
Micro»* Network Мопйш - lEveM V>ewm|
M fie ?<* V«w fipu*u v^xiow hfet
Bl^-sl Л|
Average Server Response Time {
Setvtt
SunvMry
11001550.000000000001
101Q 000000000001
1.000000000001
2300166
110.0207
110.0.20»
110.0205
1100201
1 Avewge Response Типе [se<x*!cfc] J 0 Retpomei
0.617262
0 00157U3
00OO4S2114
oocn
01295
0.0Л4464
Z 37851
O0O79O9O5
00309688
1797
14
634
1
г
к
«в
174
448
1 » Ciwit 1
2
3
3
1
2
10
15
26
The average was calculated by adding die individual response times and dmdmg by the number of responses
;To«r Events-10 'FP.lAttfb lOftONO)
Л
1,
:t «»0|
Рис. 9.17. Эксперты создают отчеты, которые быстро указывают моменты,
требующие внимания

258
Глава 9
Эксперт пересылки TCP на рис. 9.18 сообщает, что на самом деле су-
существует несколько пересылок, но ни одна из них не идет на машину или
из машины с длинным временем ответа. Так как это происходит не на
коммутируемой магистрали, то пересылки могут быть вызваны сетевой
перегрузкой, указывающей на возможную причину некоторых задержек.
fat View Орсоо;
О 004000 CIHFP1
О 004000 STOREXEC
0 019000 0800ЭЕ0
0 029000 CINFP1
55: Session Message. Lea 28
SS: Session Message, ten 56
к . len 0. seq ?6
SS: Session Kessage. lea 52
.jRrni G \2poVKbiс* lOOXdore
_J Bin 2 G:\*n2622.c«>. lOOXdona
11г Е
¦¦< 1
15 i
I» f
il17
Ши 1
tl ... 1
ШЙ
^H
^H
^H
¦1
t i venl Vtewet
Common |
S»verty I Souce ( Ivtf*
> TCPR«tt«ratnit RebantrmrtedFiamc
) TCP Rettanun* Retiantm^ed F tame
) TCP Retiamml Rptrantmxted Tiame
1 TCP Rebanont Rtf)ansm«ted Frame
1 1LJ* H^dantfntf Retranur^tteo ^facnc
1 TCP Rotiantmt Rctfdnfni'tco ^lanw
1 TCP Retianmt Racartpratted Fiame
1 TCP Retiantml Reuyar^ttd r'*me
1 TCP RMfammt Rotiantn^tetJ Ftame
1 TCP Retiarumt RebanvrMiled Frame
1
*SI»rt][^MicronU NetmriL M- .
1 Tme
120029 AM
1200 23 AM
12OO23AM
12 00 22 AM
1200 22 AM
1200 22 AM
120021AM
12:0021AM
120O17AM
1200.16AM
12:0015AM
120015AM
I SrcAddrm
11.0Д2О1
11O0201
1100.201
1100201
1100201
11 00.201
1100201
1100.201
110 0207
110.0207
1100201
1100.201
М«„«006
I DjlAod |
23.00186
nooee
11 0068
110088
110088
110088
110088
110088
11.00183
1100133
11.00.88
110088
46 FB
SeqNuntw
4412?6
328522943
328508348
328505C30
J28484739
328482C17
328479250
328475588
Э343215
3S43152
328475327
328475219
I Flare Numb»
3147
2X1
2260
2234
2200
2120
20%
1981
1287
1193
1051
1037
1
- oFbMJf
I.I3IXI
ШЁ
2992 ШЯ
2295 ШВ
2250 ЯШ
7PX H
2143 <^B
2110 ^Ш
2028 :^Ш
1879 ^Ш
1277 ^Ш
1184 ,^В
104S |Н
1022 ЩЛ
" СОЙ) '"
т 136АМ
Рис. 9.18. Эксперт пересылки TCP идентифицирует пересылку кадров,
что указывает на потенциальные сетевые проблемы — ¦«
Утилита объединения протоколов сообщает нам, что в перехваченных'
данных не существует фрагментированных пакетов, поэтому эта возможная
причина может быть отброшена.
Рассматривая эксперт верхних пользователей, мы видим, что пять из де-
десяти верхних пользователей соединены с сервером 11.0.0.206, и наш эксперт
протоколов также говорит, что существует большое число соединений RPC
с одной и той же машиной. Мы исследуем этот вопрос и находим, что
11.0.0.206 является более старой машиной, находится на 10-мегабитном сег-
сегменте Ethernet и даже не имеет в себе платы PCI Ethernet. Очевидно, что мы
обнаружили причину слабой производительности. Пользователи не жалова-
жаловались на нее раньше, потому что "она всегда медленная" и они "научились с
этим жить". Замена старой платы на 100-мегабитную плату PCI решает эту
проблему достаточно просто.

Семейство сетевых мониторов компании Microsoft 259
Как можно видеть на рис. 9.18, эксперты записывают свою работу в окне
статуса экспертов. Мониторинг этого окна удержит вас от попытки выпол-
выполнить две программы-эксперта в одно время (что породит сообщение об
ошибке). Это важно помнить, так как выполнение эксперта на большом
файле перехвата может потребовать много времени на медленной машине,
а окно статуса эксперта является единственным местом, которое позволит
узнать, что компьютер не заблокирован. В это время можно заметить, что
использование центрального процессора доходит до 100%, поэтому не
надо выполнять экспертов на производственных серверах, так как это вы-
вызовет жалобы сообщества пользователей.
А вот это не работает
Невозможно соединиться с машиной Windows 95 или 98 и выполнить на
ней удаленный сеанс сетевого монитора с помощью Network Monitor 2.0,
так как для этого требуется драйвер Network Monitor версии 2, который
требует Windows NT 4 с сервисным пакетом 4. Это также препятствует вы-
выполнению приложения сетевого монитора на машине Windows 9.x. Раньше
можно было установить полную версию сетевого монитора на портативном
компьютере Windows 95 или 98 и наслаждаться улучшенными свойствами
портативности 9.x, такими как улучшенное управление энергопотреблением
и plug-and-play, а также иметь портативный сетевой анализатор. Невозмож-
Невозможно установить Network Monitor 2.0 на этой платформе. Однако Windows 2000
Professional прекрасно работает на переносных компьютерах, и можно
выполнять Network Monitor 2.0 на этой платформе.
Тем не менее можно без проблем установить обе версии сетевого мони-
монитора на одной машине. При необходимости можно выполнять обе версии
на одной машине одновременно.
Невозможно открыть файл .cap, созданный Network Monitor 2.0 на ма-
машине Network Monitor 1.2. Если попробовать это сделать, будет получено
сообщение об ошибке: "Файл перехваченной информации является недей-
недействительным". Так как не существует способа сообщить, в каком формате
записан файл .cap, лучше создать отдельные каталоги, чтобы избежать
путаницы при выполнении в сети обеих версий.
Несколько передач перехвата недопустимы в Network Monitor 2.0. Это
несколько неудобно с точки зрения тестирования, однако в реальной жиз-
жизни требуется редко. При переходе к утилитам перехвата передачи единст-
единственными вариантами являются передача всех кадров, передача выбранных
кадров или применение текущего фильтра изображения. Это еще одна при-
причина для сохранения утилит версии 1.2 — по крайней мере в лабораторной
среде.
Дополнительные свойства безопасности
Инструмент управления монитором непрерывно следит в сети за предо-
предопределенными событиями. Эти события перечислены ниже:
• Монитор перенаправления ICMP создает событие, когда маршрутизатор
в сети перенаправляет кадры.

260 Глава 9
• Монитор маршрутизатора IP создает событие, когда маршрутизатор в
сети отказывает.
• Монитор IPRange создает событие, когда кадр имеет адрес источника,
который находится вне диапазона адресов, заданных администрато-
администратором как допустимые для определенной сети.
• Монитор маршрутизатора IPX создает событие, когда в сети отказывает
маршрутизатор IPX.
• Мониторы DHCP и WINS создают событие, когда в сети будет обнару-
обнаружен работающий недопустимый или неавторизованный сервер DHCP
или сервер WINS.
• Монитор SynAttack наблюдает за сигналами SynAttack в сети. Эта ата-
атака будет создавать большое число не отвечающих соединений на сете-
сетевом сервере, что в свою очередь поглощает большой объем ресурсов.
Подобно пиявкам, synattack будут высасывать жизнь из сервера. Это
атака отказа в обслуживании, и монитор SynAttack знает, как следить
за характеристиками, которые указывают, что происходит атака этого
типа. • - - ¦'•.'• ' ¦
• Монитор безопасности обнаруживает неавторизованные экземпляры
сетевого монитора, выполняющиеся в сети.
Когда утилита управления монитором используется для конфигурирова-
конфигурирования и активации определенного монитора локально или удаленно, монитор
проверяет кадры, проходящие мимо машины, так как он ищет определен-
определенное свойство, связанное с событием, которое он ищет. Когда маршрутиза-
маршрутизатор прекращает работу, он больше не объявляет себя в сети. Инструмент
управления монитором может заметить отсутствие этих объявлений мони-
монитора в течение определенного периода времени. Тогда он создаст событие
и откроет инструмент сетевого монитора в окне просмотра событий.
Чтобы использовать монитор, должна выполняться служба управления
монитором. Она устанавливается при установке Network Monitor 2, но
служба монитора по умолчанию задана для управления вручную. Помимо
мониторов, которые поставляются вместе с Network Monitor 2, можно ис-
использовать заказные мониторы или мониторы независимых поставщиков,
чтобы еще больше расширить функциональность продукта. Нельзя выпол-
выполнить утилиту управления монитором на любой системе, которая не удов-
удовлетворяет требованиям выполнения приложения Network Monitor 2.
Кроме того, он требует административных прав на компьютере, выполня-
выполняющем утилиту управления монитором. Чтобы использовать службу собы-
событий, требуется WBEM (управление предприятием на основе Windows), и вы
получите это приглашение, запустив утилиту управления монитором на
компьютере, который не имеет установленной WBEM. Windows 2000 имеет
WBEM по умолчанию, и на машине Windows NT 4.0 вы получаете WBEM,
когда устанавливаете административные инструменты SMS 2.O. Можно за-
запустить утилиту из ММС, щелкая правой кнопкой мыши по сетевому мони-
монитору и выбирая запуск утилиты управления сетевого монитора, или можно
создать ссылку на mcsui.exe (что легче и быстрее). Кроме того, добавив

Семейство сетевых мониторов компании Microsoft
261
каталог netmon2 в path, можно запускать netmon.exe и mcsui.exe из окна за-
запуска или приглашения CMD. Когда утилита управления монитором запу-
запущена, можно выбрать любой из мониторов, перечисленных ранее в этом
разделе, как показано на рис. 9.19. . ,. . , ,((.,, ,, _,, , м .
ETHERNET: 000000000000 ETHERNET: 00902764FAO6
Instated Monitors
1СЫР Redrect Monitor
IP Router Monitor
IPRange Monitor >
IPX Router Monitor
Rogue DHCP and WINS Monitor
Security Monitor ',
SyrAttack Monitor
Enabled Monitors
Status
«Qisable
Configure |
Start I
I Security Monitor 1
IIP Route! Monitor 1
Configured
J
Рис. 9.19. Утилита управления сетевым монитором автоматизирует большую часть
деятельности мониторинга
Нежелательно выполнять утилиту управления монитором на той же ма-
машине, которая выполняет первичный сайт SMS, лучше (в связи с требования-
требованиями ресурсов) настроить отдельную машину для выполнения мониторинга.
Затем можно будет использовать эту машину для мониторинга нескольких уда-
удаленных компьютеров, а также для выполнения необслуживаемых трассиро-
трассировок сетевого монитора и триггеров. По сути он станет сетевым управляющим
компьютером.
Посмотрим, как можно сконфигурировать монитор для сигнализации о
том, что один из маршрутизаторов отключился. На рис. 9.19 установлен-
установленные мониторы перечислены в левой панели вывода. Включенные монито-
мониторы перечислены в правой панели вывода. Включите монитор, выбрав его
из левого списка и нажимая кнопку Enable. Затем утилита управления сете-
сетевым монитором предложит сконфигурировать включенный монитор. Если
вам не нужно конфигурировать монитор в это время, в ответ нажмите по
(нет). Не сконфигурированный монитор будет показан как включенный в
правой панели. Если двинуться дальше и сконфигурировать монитор, то
появится экран, изображенный на рис. 9.20. Чтобы проследить за опреде-
определенным маршрутизатором, надо ввести IP-адрес в поле слева на экране и
выбрать число секунд, после которых маршрутизатор считается отключен-
отключенным, помещая это значение в поле внизу слева на экране. После этого на-
нажмите кнопку Set monitor configuration (Задать конфигурацию монитора) в
нижней правой стороне экрана (она не показана на рис. 9.20).

m Moraloi Conliol Tool ¦ IConligue IP Router Мопйш II
M
W»Jow Help
IP Router Monitor Configuration
a ¦•¦
Monitor these Router
IP Addresses:
10.
10.
10.
10.
0.0.10
1.0.10
2.0.10
3.0.10
ft
1
I
In the text bo» to the left, enter the IP
Addresses of the routers that you wish to
monitor for activity.
Quiet routers
are
considered
down in
[180 seconds.
In the text box to the left, enter a number from 10 to
600. This number represents the seconds of time that
a router must be quiet before the router is considered
Рис. 9.20. Окно конфигурации монитора маршрутизатора IP перечисляет
маршрутизаторы, которые отслеживаются в данный момент
Монитор маршрутизатора IP теперь сконфигурирован, но он не являет-
является активным, пока не будет выбран в правой панели и не будет нажата
снопка start (запуск). Теперь он выводится как действующий.
Если сконфигурированный маршрутизатор IP обнаружен как неактив-
шй, то утилита управления сетевым монитором будет выводить событие в
курнале событий монитора (см. рис. 9.21). К сожалению, он не записывает
i журнал событий Windows, и поэтому утилиты журнала событий не смогут
>треагировать на это событие.
Интересным свойством утилиты управления сетевым монитором являет-
является возможность сконфигурировать несколько мониторов одного типа. Это
»значает, что можно сконфигурировать несколько мониторов маршрутиза-
маршрутизаторов IP и активировать их по отдельности или в одно время. Это позволит
1ыключить из сети определенный маршрутизатор для обслуживания без не-
•бходимости выключать монитор маршрутизатора IP в целом. Это можно
делать также и для других мониторов: например, использовать несколько
юниторов безопасности, которые позволяют администратору выполнять
нализ сети, но он должен будет получить разрешение от старшего админи-
тратора. При таком сценарии старший администратор просто запускает
ключенный ранее монитор безопасности, чтобы позволить младшему адми-
[истратору выполнить анализ сети. По завершении монитор, содержащий
дрес MAC, выключается. ' :

Семейство сетевых мониторов компании Microsoft
263
вв Moniloi Conliol Tool - (Event Vieweil
M ?*e ?* tfew
Window hlelp
i MonitorEvents |
I Severity | Soutct
Event
I Oesaipton
Troe
Dale
IP Route Mont, limed out
IP Routei Momr ijnedout
IP Route Мог* timed oul
IPRouteiHmed... 11:5809AM 8/28/9S
IPRoutei tuned 11:5809AM &?8/3S
IP Route» timed П 58 09AM 8/28/99
This router has not retransmitted within our timeout penod. It may no longer be fimctiona]
Ж
FofKeip.'prien
¦ if otalEvents: 3
Рис. 9.21. Обнаруженные события выводятся в журнале событий утилиты
управления сетью
Запуск Network Monitor 2 из командной строки Запущенный сете-
сетевой монитор работает таким же образом, как в Netmon 1.2; однако синтаксис
немного отличается: двоеточие ставится между ключом и модификатором.
Например, Netmon /гето1е:имя_компъютера запускает Netmon версии 2 и
соединяется с удаленным компьютером. Однако изменилась одна команда:
/buffersize получает теперь размер буфера в мегабайтах, а не в байтах. На-
Например, чтобы запустить Netmon v.2 и начать перехват данных с помощью
трехмегабайтного буфера перехвата, введите Netmon /autostart /buffersize:3
из командной строки или команды run. Существует одна новая переменная
командной строки, ключ /quickfiltername. Он используется для определения
фильтра, который определяется параметром /quickfilter. Он игнорируется,
если нет определенного параметра /quickfilter.
Обзор главы
В этой главе было подробно рассмотрено семейство сетевых мониторов
компании Microsoft. Были выявлены сходства и различия двух поколений
продуктов и даны рекомендации по их использованию для мониторинга,
анализа, поиска неисправностей и работы системы безопасности. Было
рассмотрено использование программ-мастеров из семейства 1.2 и про-
программ-экспертов из семейства 2.0 для быстрого обнаружения потенциаль-
потенциальных проблем и для идентификации областей, которые могут требовать
дальнейшего исследования. В конце была обсуждена утилита, управления

264
Глава9
сетевым монитором, поставляемая вместе с Network Monitor 2.0, которая
может автоматизировать некоторые из повседневных задач, связанные с
проблемами безопасности и критически важным сетевым оборудованием.
В следующей главе
.^v
Мы начнем заключительный раздел книги с рассмотрения поиска неисп-
неисправностей. Мы обсудим некоторые наиболее стандартные проблемы:
медленная сеть, пользователь не может зарегистрироваться, рабочая
станция не может получить IP-адрес. Мы научимся пользоваться сетевым
монитором для разрешения всех этих проблем. Другими словами, мы ис-
" пользуем ту или иную проблему в качестве инструмента для закрепления
полученных ранее знаний.
Рассмотрев обычные проблемы, мы перейдем к некоторым особым со-
сообщениям об ошибках. Наша цель состоит в разработке модели поиска не-
неисправностей, а не просто в поиске ответа на какую-то неопределенную
проблему. В конце рассматривается широковещательный шторм и обсужда-
обсуждается стратегия выхода из проблемных ситуаций.

ЧАСТЬ IV
Сценарии поиска
неисправностей:
распространенные
проблемы
еперъ мы готовы найти ответы на вопросы и проблемы, которые
преследуют нас в течение долгого времени. Мы увидим, может ли помочь
знание протоколов и утилит мониторинга при поиске неисправностей
в сети.

Глава 10
Вопросы поиска
неисправностей
Основная проблема с соединением состоит в том, что оно либо есть,
либо его нет — по крайней мере большую часть времени. Периодически
возникающие проблемы соединения особенно неприятны. Обеспечить со-
соединение — значит предоставить компьютерам возможность общаться друг
с другом по проводам.
Рабочая станция не может зарегистрироваться
Одна из наиболее распространенных проблем соединения в сети возника-
возникает, когда рабочая станция не может зарегистрироваться в домене. Хотя
это могут вызывать многие причины (конфигурация протокола, разреше-
разрешение имени, разрешение имени NetBIOS, полномочия), в этом разделе будут
рассмотрены только некоторые из них. . ;,. .
Можно ли сделать ping сервера? >
Если рабочая станция имеет проблемы регистрации в домене, прежде все-
всего необходимо проверить соединение. Для этого используется утилита
ping. Как показано на распечатке ниже, сначала делается ping по имени,
чтобы проверить разрешение имени. Он возвращается назад с ответом. За-
Затем мы делаем ping по определенному IP-адресу, чтобы проверить, имеется
ли доступ к тому же месту назначения, и, наконец, посылается большой па-
пакет для проверки, что пакеты большого размера могут дойти до места на-
назначения. Ping по умолчанию посылает очень маленький 32-байтовый
пакет, который может дойти до места назначения, в то время как больший
по объему трафик регистрации может не пройти через маршрутизатор.
C:\>ping PROX
Pinging PROX [10.0.0.10] with 32 bytes of data:

268
Глава 10
Reply from 10.0.0.10: bytes=32 time<10ms TTL=128
Reply from 10.0.0.10: bytes=32 time<10ms TTL=128 .., ,
Reply from 10.0.0.10: bytes = 32 time<10ms TTL=128 •¦"*, :
Reply from 10.0.0.10: bytes=32 time<10ms TTL=128
C:\>ping 10.0.0.10
Pinging 10.0.0.10 with 32 bytes of data:
Reply from 10.0.0.10: bytes=32 time<10ms TTL=128
Reply from 10.0.0.10: bytes=32 time<10ms TTL=128
Reply from 10.0.0.10: bytes = 32 time<10ms TTL=128
Reply from 10.0.0.10: bytes=32 time<10ms TTL=128 l
C:\>ping 10.0.0.10 -1 4048 •'¦ - -r.a ,. лч ч ¦ • •-¦
Pinging 10.0.0.10 with 4048 bytes of data:
Reply from 10.0.0.10: bytes=4048 time<10ms TTL=128
Reply from 10.0.0.10: bytes=4048 time<10ms TTL=128
Reply from 10.0.0.10: bytes=4048 time<10ms TTL=128
Reply from 10.0.0.10: bytes=4048 time<10ms TTL=128
Если большие пакеты не доходят до места назначения, а маленькие паке-
пакеты доходят до сервера регистрации, то можно подредактировать реестр и
определить меньший размер пакета как временную меру, пока не будет
ясно, могут ли поддерживаться большие пакеты. Это делается в реестре
следующим образом:
Настройка размера пакетов TCP
Добавьте значение в следующий ключ:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcipip\
parameters_
Имя значения: TcpSendSegmentSize
Тип будет Reg_Dword
По умолчанию используется 1460 байтов
Стандартное предупреждение о редактировании реестра Эти из-
изменения будут влиять на всю коммуникацию с помощью TCP/IP и должны
делаться только после тщательного тестирования. Конечно, прежде чем де-
делать какие-либо изменения в реестре, убедитесь, что существует тщательно
проверенная и актуальная резервная копия. По крайней мере сначала экс-
экспортируйте ключ (см. рис. 10.1). Для импорта и экспорта ключей .reg Rege-
dit является самым простым средством (он имеет также то достоинство,
что может искать во всем реестре определенное значение). Для редактиро-
редактирования реестра (локально или удаленно) используйте Regedit32, так как он
имеет лучший редактор.
Помощь от Netmon Повторите команды ping и выполните в трасси-
трассировке Netmon выборку только рабочей станции и сервера. В дополнение к
командам ping попробуйте также выполнить следующие команды.
• Net view \\имя_сервера
• Net use \\имя_сервера\{рс$

Вопросы поиска неисправностей
269
TI28
пэе
0x00000001 A1
OxOOOOOOPO fO]
"pox"
0x00000001 П)
Email Rea»t»Fik
«^ iC!
" J Ttanaent
' •_) Wnsock
CiJ Pertcmanc*
?j Setirty
_JNm
_JV3PC*che
_| W3Pn*y
. _J W3SVC
4»
Sstactadtunch
4 23 PM
л I.
Рис. 10.1. Прежде чем делать изменения, воспользуйтесь Regedit для экспорта
ключей реестра
Если эти две команды возвращаются с сообщением об ошибке, то имеет-
имеется существенная проблема. Посмотрим на Netmon и проверим, можем ли
мы обнаружить источник нашей проблемы. Мы видим, что команда ping
работает фактически без каких-либо проблем. Это показано на распечатке
ниже. Мы видим ICMP из источника в место назначения. Это тип эхо-пакета.
Его размер 32 байта, что является используемым по умолчанию размером
пакета ping. . ... . . , . ¦
ICMP: Echo, From 10.00.00.60 To 10.00.00.10
ICMP:
ICMP:
ICMP:
ICMP:
ICMP:
@x0020)
Packet Type = Echo
Checksum = 0x2E5C
Identifier = 256 @x100)
Sequence Number = 7680 (OxlEOO)
Data: Number of data bytes remaining = 32
За эхо-пакетом ICMP следует пакет ответа ICMP, который мы видим на
распечатке ниже. Этот пакет возвращается из места назначения для ping
как пакет эхо-ответ. Он также имеет 32 байта. Это говорит нам, что по край-
крайней мере имеется элементарная коммуникация между рабочей станцией
и сервером. . ... . ^ • '

270 Глава 10
'.U* ICMP: Echo Reply, To 10.00.00.60 From 10.00.00.10 " '
ICMP: Packet Type = Echo Reply
ICMP: Checksum = 0x365C •¦•¦¦-• . \
ICMP: Identifier = 256 @x100)
ICMP: Sequence Number = 7680 (OxlEOO)
ICMP: Data: Number of data bytes remaining = 32
@x0020)
Затем мы проверяем команду net view \\имя_сервера, что приводит к
трехходовому квитированию между рабочей станцией и сервером. Треххо-
Трехходовое квитирование происходит между рабочей станцией и портом 139,
службой сеанса NetBIOS на сервере. Все работает нормально, поэтому да-
давайте посмотрим раздел NBT следующего кадра, который показан на распе-
распечатке ниже. Кадр из рабочей станции на сервер выглядит правильным. Мы
видим, что тип пакета указывается как запрос сеанса (session request). Он
содержит имя вызванного сервера и имя вызывающей рабочей станции.
<00> является уникальным суффиксом NetBIOS, указывающим службу рабо-
рабочей станции. Можно найти регистрацию <00> для этой машины в базе дан-
данных WINS, отображающую ее в IP-адрес этой машины. Регистрация в базе
данных WINS облегчает NetBIOS коммуникацию между машинами.
NBT: SS: Session Request, Dest: PROX Source: j
2400 <00>, Len: 68 ,j
NBT: Packet Type = Session Request ¦ ,. . , V
. NBT: Packet Flags = 0 @x0) —., , ", ,, ' . L.
NBT: 0 = Add 0 to Length ''"•* "* *
. .... NBT: Packet Length = 68 @x44) ; -f ^.^
NBT: Called Name = PROX
NBT: Calling Name = 2400 <00> V' ''''"'''
Так как запрос сеанса NBT прошел нормально, посмотрим на ответ, ко-
который приходит с сервера. Он содержится на распечатке ниже. В этом мес-
месте мы получаем некоторую полезную информацию. Мы имеем ответ с
отказом сеанса (Negative Session Response), и код ошибки службы сеанса го-
говорит нам, что вызванное имя отсутствует. Теперь мы знаем, что проблема
не на рабочей станции, а на сервере. Другие рабочие станции будут сталки-
сталкиваться с той же проблемой. Теперь необходимо проверить, что происхо-
происходит на сервере. Но сначала посмотрим, можно ли получить какую-либо
дополнительную информацию из только что сделанной трассировки Netmon.
NBT: SS: Negative Session Response, Len: 1
NBT: Packet Type = Negative Session Response
NBT: Packet Flags = 0 @x0)
NBT: 0 = Add 0 to Length
NBT: Packet Length = 1 @x1)
NBT: Session Service Error Code = Called Name Not
Present
Мы видим несколько запросов контроллера первичного домена, но не
видим ответа. Это происходит, как SMB С transact в \mailslot\net\netlogon.
Возможно, существует также проблема со службой netlogon.

Вопросы поиска неисправностей
271
UDP: Src Port: NETBIOS Datagram Service, A38); Dst Port:
NETBIOS Datagram Service A38); Length = 230 @xE6)
+ NBT: DS: Type = 17 (DIRECT GROUP) M,;,; .
+ SMB: С transact. File = \MAILSLOT\NET\NETLOGON s
NETLOGON: Query for Primary DC uuuiit. i , ¦
NETLOGON: Opcode = Query for Primary DC
NETLOGON: Computer Name =2400
NETLOGON: Mailslot Name = \MAILSLOT\NET\GETDC915
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
Если заглянуть в просмотрщик событий на рабочей станции, можно уви-
увидеть следующее сообщение: "Броузер не смог извлечь список серверов из
мастер-броузера \\PROX в сети \Device\NetBT_E100Bl. Данные являются
кодом ошибки". Это сообщение просто подтверждает, что на сервере име-
имеется проблема. На сервере необходимо проверить следующее:
• Проверьте, что служба сервера выполняется на компьютере места на-
назначения. Проверьте апплет служб в панели управления (см. рис. 10.2).
Если служба сервера не выполняется, машина будет все равно отве-
отвечать на ping, но сеанс создать невозможно. Если служба сервера оста-
остановлена, запустите ее. Это даже не требует перезагрузки машины. Это
объяснит также сообщения ошибок броузера в журнале событий, так
как служба броузера компьютера зависит от службы сервера. Кроме
того, служба netlogon также зависит от службы сервера. Мы рассмат-
рассматривали ранее проблемы со службой netlogon в трассировке Netlogon.
Вопрос, конечно, в том, почему служба сервера остановлена? Некото-
Некоторые вещи Netmon просто не может сообщить. Может быть, настало
время сменить пароль администратора. •• •¦ ¦ *- ......
Services
Seiyice
Status
Startup
Remote Procedure Cal (RPC) Locator
Remote Procedure Can (RPC) Service
Schedule
Started
Started
Automatic ±\
Automatic
Manual
Close"" i|
Start
SMS Client Service
SMS Remote Control Agent
SMS_NT_LOGON_DISCOVERY_AGENT
Spooler
TCP/IP NetBIOS Help» ',r
Telephony Sei vice
Startup Parameters:
Stalled
Started
Slatted
Automatic
Manual
Manual
Manual
Automatic
Automatic
Manual
J
Startup...
HV/Profiles...
Help
Рис. 10.2. Проверьте состояние служб, чтобы исключить потенциальные проблемы

272 ¦¦¦¦"¦ Глава 10
• Проверьте, отвечает ли сервер места назначения. Он может быть за-
заблокирован. Сервер может отвечать на эхо-пакет ICMP, даже если се-
сеанс невозможно создать. Если компьютер заблокирован и невозможно
восстановить управление через менеджер задач или каким-либо другим
способом, следует сообщить всем пользователям о необходимости со-
сохранить свои данные и по возможности аккуратно выйти из системы.
Можно попробовать выполнить закрытие системы, хотя в зависимо-
зависимости от того, что произошло, возможно, придется сделать полную за-
загрузку. Если повезет, все восстановится нормально. Если нет, придется
проверять процедуры резервного копирования.
• Следующий пункт может показаться глупым, но если выполняется реги-
регистрация пользователей в пределах лицензии, а ограничения лицензии
превышены, то сервер будет отвечать на ping, но сеанс создаваться не
будет. Проверьте апплет лицензии в панели управления и в журнале
событий, чтобы убедиться, что ограничения лицензии не нарушены.
• Проверьте, используется ли DNS или файл хоста. Методы разреше-
разрешения имени хоста используются первыми в ping для разрешения име-
имени. Команды net используют методы разрешения имени NetBIOS
(lmhosts, WINS). Ping может работать, в то время как net view может
простаивать.
Рассмотрим случай с портативным компьютером
Приведенный выше сценарий было бы практически невозможно разо-
разобрать без использования Netmon. Если на рабочей станции установлены
агенты, можно было бы соединиться удаленно и управлять трассировками;
однако многие компании не очень широко используют агентов Netmon, и,
конечно, Netmon 2 требует агентов версии 2, которые не работают на ма-
машинах Windows 9.x. В таких случаях портативный компьютер с версией
SMS Netmon становится мобильным сетевым анализатором. Портатив-
Портативный компьютер не должен присоединяться к домену, чтобы перехватить
трафик. Ему требуется только сетевое соединение, и вы можете решать
сетевые проблемы там, где можно соединиться с сетью. Конечно, требует-
требуется плата Ethernet для поддержки безразличного режима, но большинство
современных плат поддерживают эти функции.
Рабочая станция не может получить
выделяемый DHCP адрес
Хотя DHCP облегчает жизнь администратора, иногда клиентская машина
Сталкивается с проблемами при получении адреса. В таких ситуациях ин-
информация часто бывает скудной. Помимо того факта, что рабочая станция
не получила адреса, мало что еще известно. Здесь начинают играть роль
наши знания процессов DHCP и Netmon.

Вопросы поиска неисправностей 273
Взгляд на диалог ~
Прежде всего, необходимо проверить, что машина была сконфигурирована
для запроса адреса. Если в окне свойств TCP/IP отмечено свойство "полу-
"получать IP-адрес с сервера DHCP", то это должно работать. Если нет, мы преры-
прерываем Netmon и просматриваем диалог. В идеале должны присутствовать
четыре кадра, перечисленные ниже.
1. Поиск DHCP
2. Предложение DHCP
3. Запрос DHCP
4. DHCPACK
Если эти четыре кадра не присутствуют, DHCP не будет работать, а кли-
клиент не сможет получить адрес. Если ничего не присутствует, то клиент не-
неправильно сконфигурирован для запроса адреса DHCP. Решение проблемы
DHCP является процессом просмотра диалога и идентификацией того, что
из диалога, представленного выше, пропущено.
Проанализируйте, что пропущено
Наш первый шаг состоит в просмотре трассировки и поиске пропущенно-
пропущенного. Кадр запроса DHCP посылается с помощью многоадресной рассылки
UDP IP из порта 68, клиентского порта ВООТР, в порт 67, серверный порт
ВООТР. Magic cookie будет в порядке. Это четырехбайтная область в паке-
пакете DHCP, которая идентифицирует начало поля, определенного поставщи-
поставщиком для специальных параметров. Если используется данное поле
параметров, это отмечается IP-адресом 99.130.83.99, который показан в трас-
трассировке Netmon как шестнадцатеричное 63 82 53 63. Параметры могут пере-
перечислять такие вещи, как идентификатор клиента, запрошенный адрес, а
также другие позиции. В нашем поле параметров идентификатор клиента
равен адресу MAC делающего запрос компьютера — в данном случае KENNY.
Мы также видим, что машина KENNY запрашивает тот же адрес, которым
она владела ранее. Если этот адрес доступен, его можно будет использовать
снова. .,. ¦--,...
UDP: IP Multicast: Src Port: BOOTP Client, F8); Dst Port:
BOOTP Server F7); Length = 308 @x134)
UDP: Source Port = BOOTP Client
UDP: Destination Port = BOOTP Server
UDP: Total length = 308 @x134) bytes
UDP: UDP Checksum = 0x36C3
UDP: Data: Number of data bytes remaining = 3 00
@x012C)
DHCP: Request (xid = 05F105F1) ' '
DHCP: Op Code (op) = 1 @x1)
DHCP: Hardware Type (htype) = 1 @x1) 10 Mb
Ethernet
DHCP: Hardware Address Length (hlen) = 6 @x6)
DHCP: Hops (hops) = 0 @x0)

274
Глава 10
DHCP: Transaction
@x5F105Fl)
DHCP: Seconds
Flags
Client
Your
Server
Relay
Client
ID
(xid)
= 99681777
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
(sees)
(flags)
(ciaddr)
(yiaddr)
(siaddr)
(giaddr)
IP Address
IP Address
IP Address
IP Address
Ethernet Address (chaddr)
Server Host Name (sname)
Boot File Name (file)
Magic Cookie = [OK] ¦ ;i •. ¦ ..
DHCP: Option Field (options)
DHCP: DHCP Message Type = DHCP Request
Client-Identifier = (Type: 1) 00
0 @x0) ¦ - -4
0 @x0) . ;."*'
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
= 00104BEC8DB2
<Blank>
<Blank>
DHCP:
4b ec 8d b2
. . .. DHCP:
'•"• ' DHCP:
DHCP:
06 Of 2c 2e 2f
DHCP:
10
Requested Address = 10.0.0.76
Host Name = kenny
Parameter Request List = (Length: 8)
39
End of this option filed
01 03
В трассировке ниже запрошенный адрес недоступен, так как он получа-
получает NACK, что является негативным подтверждением. Если рассмотреть
часть IP в кадре, то можно увидеть машину, которая посылает этот NACK
на рабочую станцию. Мы видим в этой части пакета, что он приходит из
порта 67, порта сервера ВООТР, в порт 68, порт клиента ВООТР. Когда ра-
рабочая станция получает NACK, она не будет инициализировать TCP/IP,
пока не получит адрес. Если TCP/IP является единственным протоколом,
машина не сможет общаться в сети, пока не будет обнаружен сервер DHCP.
UDP: IP Multicast: Src Port: BOOTP Server, F7); Dst Port:
BOOTP Client F8); Length = 308 @x134)
UDP: Source Port = BOOTP Server
UDP: Destination Port = BOOTP Client li;';:
i;- UDP: Total length = 308 @x134) bytes : ' '*
'¦"*•' UDP: UDP Checksum = 0x2D13 ¦' <
UDP: Data: Number of data bytes remaining = 300
(OxO12C)
DHCP: NACK (xid = 05F105F1)
DHCP: Op Code (op) = 2 @x2)
DHCP: Hardware Type (htype) = 1 @x1) 10 Mb
Ethernet
Так как клиентская машина посылает запросы DHCP и получает NACK с
сервера DHCP, то можно сказать, что они общаются. Тот факт, что машина
посылает запросы, является обнадеживающим, поскольку она делает все,
что должна делать клиентская машина. Для проверки можно использовать
команду ipconfig /renew из окна CMD, что заставит клиентскую машину со-
создать трафик DHCP. Это один из способов выполнить передачу, не перезаг-
перезагружая машину. В трассировке Netmon мы должны увидеть два кадра DHCP:
запрос DHCP и DHCP ACK.

Вопросы поиска неисправностей 275
В нашей трассировке DHCP мы находим только запросы и один NACK.
Мы не находим никакого другого трафика. Следующий шаг состоит в пере-
переходе к серверу и изучению свойств DHCP. Там можно обнаружить, что сер-
сервер не имеет свободных адресов, или что область действия была
деактивирована. Это, видимо, две наиболее распространенные причины.
Рабочая станция работает медленно
Нет ничего необычного, когда пользователи жалуются на то, что сеть рабо-
работает медленно. Эти жалобы сетевые администраторы слышат достаточно
часто. Однако пользователи редко высказывают иные суждения, помимо
общего наблюдения, что сеть медленная. Раньше администратор приходил
к пользователю, наблюдал за его действиями и соглашался или не согла-
соглашался с точностью наблюдений. Это не лучший способ для нового тысяче-
тысячелетия. У нас есть Netmon в качестве средства спасения. Рассмотрим
пример ниже, чтобы понять, как Netmon работает в этой ситуации.
Можно ли точно определить понятие "медленная"?
Простейшим способом определить понятие "медленная" является использо-
использование эксперта среднего времени ответа сервера, имеющегося в Netmon 2.O.
Прежде чем запускать эксперт, необходимо перехватить некоторый объем
трафика между сервером и клиентской машиной. Если установлен агент
версии 2, то все просто; если нет, то придется поместить портативный
компьютер в том же сегменте, что и сервер, и сконфигурировать фильтр
перехвата, который изолирует трафик между рабочей станцией и рассмат-
рассматриваемым сервером. Это должно быть сделано после проверки на рабочей
станции, сколько там открыто приложений, сколько имеется свободного
пространства на диске для виртуальной памяти, и т.п. Когда будут исключе-
исключены все возможные проблемы рабочей станции, можно начинать перехват
данных.
Что является источником недовольства?
После воспроизведения источника недовольства загрузите перехваченный
файл в Netmon 2.0 и сконфигурируйте эксперт времени ответа (см. рис. 10.3).
Конфигурирование эксперта является существенно важным для получения
точных результатов. Если, например, пользователь жаловался, что была мед-
медленной почта РОРЗ, то необходимо добавить эксперту порт 110. Можно испо-
использовать Приложение А для помощи в определении номеров общеизвестных
портов при добавлении их эксперту.
Изменяя конфигурационные файлы, эксперт может сообщить о боль-
большинстве приложений, выполняющихся в сети. Если удалить все порты,
кроме порта рассматриваемого приложения, будут получены различные
показатели производительности. Использование Netmon 2.0 в этой облас-
области почти не ограничено.

276
Глава 10
Aveiage Seiver Response Time Configuration Q
ICP/IP ports
Enter Port
Number
Enter pocket
Number
1
:. ¦ i
OK
< Delete IPX
Cancel
Help
Рис. 10.3. До выполнения эксперта среднего времени ответа сервера необходимо
сконфигурировать его для рассматриваемого приложения , ; , .
Эксперт создает отчет, перечисляя IP-адреса и среднее время ответа в се-
секундах, как показано на рис. 10.4. Если результаты соответствуют базовым
показателям, возможно, придется снова посмотреть на рабочую станцию и
привычную работу определенного пользователя. Если они действительно
медленные, то трассировка будет требовать дополнительного анализа. От-
Отчет распределения протоколов, отчет верхних пользователей и эксперт пе-
пересылки TCP могут предоставить ценную помощь при поиске причины
медленной работы сети. Помимо просмотра на экране отчеты можно сохра-
сохранить как текстовые файлы и распечатать или превратить в другие документы,
например файлы Microsoft Word.
Проблемы с регистрацией
Пока людям необходимо будет регистрироваться в сети, будут возникать
проблемы с регистрацией. На самом деле существует только несколько пере-
переменных, вовлеченных в процесс регистрации: имя пользователя, пароль и
домен. Если они неправильны, то регистрация будет отказывать. Журнал со-
событий сервера может предоставить ценную информацию, но необходимо

Вопросы поиска неисправностей 277
Microsoft Netmxk MokIoi
Qoton» Window Ц*
Average Server Response Time [
Swver | Avetape Reipome Time (seconds) j Я Reiponset
IS813* 303
21S32243135 020*667 9 1
216 32182.252 0 345556 . , S , ,- > 1
207 4S.mX 010C667 ' J 1
206.1512551» 057N92 1J 1
пшют"—дир————— as r-
Toe average was calculated by addtog tbe individual response times aad dividing by the number otresponses.
.'¦-.;•• ¦ ' ¦ ¦¦¦ ' .- . . " '¦ ; . ¦ ¦ , ¦ , ' . ¦ , - : P, ; . ,
•¦¦ ¦'¦'¦''-.-', .¦¦.:.-. ;• /*' i/ ^;':- ' .. \ . ; ^ ¦¦ i .
j
FC. 1/10S9 OII.0W)) L'lldl
Рис. 10.4. Отчет о среднем времени ответа сервера подтверждает проблему
с временем ответа
найти контроллер домена, который получает и обрабатывает запросы ре-
регистрации. Кроме того, если безопасная регистрация не включена (а лучше
бы включить), то журнал событий ничем не сможет помочь. Однако разумное
применение Netmon сможет помочь в разрешении проблемы.
Я пытаюсь аутентифицироваться, но где?
Иногда пользователь при попытке зарегистрироваться вводит неправиль-
неправильное имя домена. На машинах на основе NT это не проблема, так как они вы-
выбирают домен регистрации из выпадающего списка. В Windows 2000 весь
вопрос с доменом скрыт от взгляда пользователя, поэтому пользователи не
знают, где они регистрируются — либо на рабочей станции, либо в домене.
Что доступно, там они и будут соединены.
Давайте посмотрим на клиента Windows 98, регистрирующегося в доме-
домене. Клиент вводит имя пользователя, пароль и имя домена, а затем начина-
начинает жаловаться, что не может войти в домен. Мы говорим с клиентом по
телефону, и он подтверждает, что ввел свое имя пользователя и пароль, и
что имя домена было введено правильно. Мы советуем ему нажать пару раз
клавишу caps lock и проверить, что индикатор загорается, гаснет, загорает-
загорается, гаснет. Мы проверяем менеджера доменов пользователя и видим, что
позиции отключения учетной записи и блокирования учетной записи не

Глава 10
помечены, поэтому можно быть уверенным, что учетная запись не заблоки-
заблокирована. Просмотрщик событий также не показывает записей, указываю-
указывающих на неудачные попытки регистрации. Мы просматриваем резервные
контроллеры домена, но там тоже нет ничего подозрительного. Мы про-
просим пользователя включить и выключить соединительный кабель из стен-
стенной розетки и из платы Ethernet. Он подтверждает, что соединение
нормальное. Он пытается повторить и снова не может аутентифицировать-
ся, поэтому мы предлагаем ему перезагрузить машину, но он по-прежнему
не может соединиться. Это удаленный клиент, и мы не можем наблюдать за
регистрацией пользователей. Что тогда делать? Можно сказать ему, что ма-
машина не работает, и посоветовать отправить ее в корпоративный отдел ин-
информационных технологий для эффективной проверки, вызвать сервисную
компанию для ремонта машины или попробовать использовать Netmon.
Мы просим пользователя перезагрузить машину еще раз и запускаем
Netmon, когда слышим сигнал на другом конце телефонной линии. Когда
пользователь сообщает, что он по-прежнему не работает, мы останавлива-
останавливаем Netmon и звоним пользователю после анализа трассировки (что мы и
собираемся сейчас сделать).
Мы видим запрос DHCP и DHCP ACK в первых двух кадрах, поэтому
проблема не в DHCP. Следующий кадр является ARP_RARP, это означает,
что компьютер взял присвоенный ему адрес и послал запрос ARP для этого
адреса. Таким образом, если другая машина имеет этот адрес, то будет обес-
обеспечена сетевая ошибка двойного IP-адреса. Другое свойство ARP_RARP со-
состоит в том, что машины, которые имеют старый IP-адрес в своем кэше
ARP, будут автоматически обновлять свой кэш ARP, когда они получат за-
запрос. В нашей трассировке мы не видим никакого ответа на ARP_RARP,
поэтому это не проблема двойного IP-адреса.
Затем идут два широковещательных сообщения регистрации NBT. Мы
видим уникальное широковещание NTB для <00>, что является на компью-
компьютере службой рабочей станции, а также широковещание NBT для <03>, со-
содержащееся в распечатке ниже. Этот кадр является широковещанием в
сети дейтаграмм UDP в 10.255.255.255. Это широковещание используется
для службы имен NetBIOS для регистрации имени компьютера в службе
рассылки. Как можно видеть в разделе класса записи, это уникальное имя
NetBIOS. До сих пор все выглядит, как должно быть. Мы подтвердили, что это
не проблема соединения, потому что взаимодействие выглядит нормально.
UDP: Src Port: NETBIOS Name Service, A37); Dst Port:
NETBIOS Name Service A37); Length = 76 @x4C)
v. ;. UDP: Source Port = NETBIOS Name Service
, . UDP: Destination Port = NETBIOS Name Service
UDP: Total length = 76 @x4C) bytes
UDP: UDP Checksum = 0xF520
UDP: Data: Number of data bytes remaining = 68
¦v'' @x0044)
NBT: NS: Registration req. for KENNY ^'"- ¦ ¦ <03>
NBT: Transaction ID = 4 @x4)
• + NBT: Flags Summary = 0x2910 - Req.; Registration;
Success

Вопросы поиска неисправностей
279
NBT: Question Count = 1 (Oxl)
NBT: Answer Count = 0 @x0) ¦ "'•"
NBT: Name Service Count = 0 @x0)
NBT: Additional Record Count = 1 @x1) ' • ¦' *'
NBT: Question Name = KENNY <03> - ¦ '
<¦'¦"¦ NBT: Question Type = General Name Service
¦ ¦"'¦• •; NBT: Question Class = Internet Class ¦¦.-). ;>
..' ... NBT: Resourse Record Name = KENNY <03>
NBT: Resourse Record Type = NetBIOS General Name
Service
NBT: Resourse Record Class = Internet Class
NBT: Time To Live = 300000 @x493E0) •..
NBT: RDATA Length = 6 @x6)
NBT: Resource Record Flags = 0 @x0)
NBT: 0 = Unique NetBIOS Name
NBT: .00 = В Node
NBT: ...0000000000000 = Reserved
NBT: Owner IP Address = 10.0.0.76
Следующий кадр решает проблему. Отметим запрос группы <00>, что яв-
является именем домена. Именем домена, который ищет рабочая станция, бу-
будет NETMO. Это неправильно. Это неверный домен. Посмотрим, что
происходит в оставшейся части перехваченного файла.
UDP: Src Port: NETBIOS Name Service, A37); Dst Port:
NETBIOS Name Service A37); Length = 76 @x4C)
UDP: Source Port = NETBIOS Name Service
Destination Port = NETBIOS Name Service
Total length = 76 @x4C) bytes
UDP Checksum = 0x7A22
Data: Number of data bytes remaining = 68
UDP:
UDP:
UDP:
UDP:
@x0044)
NBT: NS:
NBT:
+ NBT:
Success
NBT:
NBT:
NBT:
NBT:
NBT:
NBT:
NBT:
NBT:
NBT:
Service
NBT:
NBT:
NBT:
NBT:
Registration req. for NETMO <00>
Transaction ID = 2 @x2)
Flags Summary = 0x2910 - Req.; Registration;
Question Count = 1 @x1) , ,
Answer Count = 0 @x0) . , . , .¦
Name Service Count = 1 @x1)
Additional Record Count = 1 @x1)
Question Name = NETMO <00>
Question Type = General Name Service
Question Class = Internet Class
Resource Record Name = NETMO <00>
Resource Record Type = NetBIOS General Name
Resource Record Class = Internet Class
Time To Live = 300000 @x493E0)
RDATA Length = 6 @x6)
Resource Record Flags = 32768 @x8000)
NBT: 1 = Group NetBIOS Name
NBT: .00 = В Node

280
Глава 10
NBT: ...0000000000000 = Reserved
NBT: Owner IP Address = 10.0.0.76 ' ": *
Рабочая станция пытается теперь сделать широковещательный запрос
netlogon с помощью дейтаграммы UDP в сеть 10.255.255.255. Она поступает
из порта 138 службы дейтаграмм NetBIOS и направляется в порт 138 служ-
службы дейтаграмм NetBIOS на машине места назначения. Имя источника опре-
определяет Kenny, а имя пользователя administrator. Машина Kenny пытается
найти \mailslot\net\netlogon для домена NETMO.
IP: ID = 0x3100; Proto = UDP: Len: 253 . ..''
IP: Version = 4 @x4) .
IP: Header Length =20 @x14) i '
+ IP: Service Type = 0 @x0) r.:->
IP: Total Length = 253 (OxFD)
IP: Identification = 12544 @x3100)
+ IP: Flags Summary = 0 @x0) t .
IP: Fragment Offset = 0 @x0) bytes
IP: Time To Live = 128 @x80)
IP: Protocol = UDP - User Datagram \, •¦-'¦ '
IP: Checksum = 0xF3A5 ¦¦ . ;- ¦ .
• : ¦ IP: Source Address = 10.0.0.76 ..-' '.'
IP: Destination Address = 10.255.255.255
IP: Data: Number of data bytes remaining = 233
@x00E9)
¦¦""¦ UDP: Src Port: NETBIOS Datagram Service, A38); Dst Port:
NETBIOS Datagram Service A38); Length = 233 @xE9)
UDP: Source Port = NETBIOS Datagram Service
UDP: Destination Port = NETBIOS Datagram Service
Total length = 233 @xE9) bytes
UDP Checksum = 0xlB3 5
Data: Number of data bytes remaining = 225
¦¦¦•¦qi>
UDP:
UDP:
UDP:
(OxOOEl)
NBT: DS:
NBT:
+ NBT:
NBT:
NBT:
NBT:
NBT:
NBT:
NBT:
NBT:
NBT:
@x008F)
SMB
+ SMB:
+ SMB:
Type =17 (DIRECT GROUP)
Datagram Packet Type = DIRECT GROUP
Datagram Flags = 2 @x2)
Datagram ID = 26 @x8A)
Source IP Address = 10.0.0.76
Source Port = 138 @x8A)
Datagram Length = 211 @xD3)
Packet Offset = 0 @x0)
Source Name = KENNY <00>
Destination Name = NETMO <00>
DS Data: Number of data bytes remaining
= 143
С transact, File = \MAILSLOT\NET\NETLOGON
SMB Status = Error Success
Header: PID = 0xl52F TID = OxFFFF MID = 0x0101
UID = OxFFFF
+ SMB: Command = С transact
SMB: Data: Number of data bytes remaining = 51
@x0033)

Вопросы поиска неисправностей 281
""' 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 = ADMINISTRATOR
NETLOGON: Mailslot Name = \MAILSLOT\TEMP\NETLOGON
NETLOGON: Request Count = 1 @x1)
NETLOGON: LM20 Token = OS/2 LAN Manager 2.0 (or later)
Networking
Оставшаяся часть файла перехвата является повторением приведенных
выше кадров, которые уже были рассмотрены. Потребовалось меньше часа
для анализа перехваченных данных без доставки машины для осмотра и тес-
тестирования. Мы звоним пользователю, чтобы он ввел правильное имя домена,
и он входит в сеть.
Встречаются редкие ситуации, когда приложение будет испорчено в такой
степени, что нам придется серьезно покопаться, но когда необходимо про-
просмотреть взаимодействие приложений, можно получить некоторые очень ин-
интересные представления и решать сложные раздражающие проблемы
достаточно просто.
Странные ошибки журнала событий
Иногда в окнах журнала возникают достаточно странные ошибки событий.
Одной из них является событие ID 2000, которое просто говорит
STATUS_NO_SUCH_FILE. Это событие происходит, когда сетевое прило-
приложение посылает команду удаления файла на общий диск, а файл уже был
удален. Словом, во второй строке раздела данных сообщения об ошибке
будет cOOOOOOf, которое соответствует STATUS_NO_SUCH_FILE .
Метод поиска серверных проблем
Это проблема связана с SMB. Сначала рассмотрим файл перехвата. Чтобы
упростить это, мы создали фильтр вывода, который показывает только
команды SMB для удаления файла. На рис. 10.5 показано, как создается
этот фильтр вывода. Находясь в режиме вывода, выберите фильтр из меню
вывода (display). Сделайте двойной щелчок по строке протокола, и когда
появится диалоговое окно выбора, отключите все протоколы. Выберите
SMB из списка протоколов в правой панели диалогового окна, а затем щел-
щелкните по кнопке включить (enable). Простым способом перейти в раздел
"S" списка протоколов без прокручивания длинного списка является щел-
щелчок по панели меню name и ввод "S". Это переместит вас в раздел "S", позво-
позволяя быстро найти протокол SMB. Когда протокол SMB будет включен,
нужно будет найти команду SMB delete. Чтобы сделать это, щелкните по за-
закладке property. К сожалению, диалоговое окно недостаточно разумно, что-
чтобы помнить, какой протокол был только что включен, и перед нами опять
оказывается тот же самый список протоколов. Ввод "S" здесь не поможет,
поэтому придется прокручивать список, пока не будет найден протокол
SMB. Щелкните по знаку "плюс" рядом с SMB, и появится длинный список
свойств протокола. Прокручивайте его, пока не сможете выбрать command

282
Глава 10
Expression
Expiession
SMB Command == 0x6 (delete We)
PioiocotPiopetiy
Relation Value (Byte)
Byles Remaining in Rpe
Caching mode
Capabilities ¦-""¦¦¦
Capabilities Flags
Change count
ge Time
A
о
contains
exists
|0x06
echo
end message
exit
OK
Cancel
Help
Hex
С Oecimal
Рис. 10.5. Конфигурируя фильтр вывода, усилия по выявлению неисправностей
можно свести к очень узкой проблеме „ .¦ ¦.,,,: , ., ........г. ¦ ¦¦¦ . :.
из диалогового окна. Когда command будет выбрана, появится список зна-
значений. Прокручивайте Вниз, пока не сможете выбрать delete file, а затем
нажмите ок. Этот фильтр вывода показывает теперь команды SMB delete
любого компьютера.
При просмотре кадров SMB delete мы ищем сообщение об ошибке. Рас-
Рассмотрим взаимодействие. Клиентская машина посылает на сервер команду
С delete file. Параметры включают расположение файла.
SMB: С delete file, File = \PROGRAMS\TEMP\tmpl665.aud
~ + SMB: SMB Status = Error Success
+ SMB: Header: PID = 0xl4E5 TID = 0x0800 MID = 0x6701
UID = 0x0800
SMB: Command = С delete file
'¦ SMB: Word count = 1 ' ¦
SMB: Word parameters
¦¦; + SMB: File Attributes = 6 @x6)
: ,. •¦ ,. . SMB: Byte count = 55 . ., n ,
... : SMB: Byte parameters
SMB: File name = \PROGRAMS\TEMP\tmpl665.aud
Ответ с сервера возвращается в следующем кадре и представлен в распе-
распечатке ниже. Мы имеем команду R delete file с сообщением об отсутствии
ошибок. Файл был успешно удален с сервера.
SMB: R delete file
+ SMB: SMB Status = Error Success

Вопросы поиска неисправностей
283
+ SMB: Header: PID = 0х14Е5 TID = 0x0800 MID = 0x6701
UID = 0x0800
SMB: Command = С delete file
SMB: Word count = 0
SMB: Byte count = 0
Мы не смогли локализовать проблему в первом файле перехваченных
данных. Понятно, что эту ошибку найти будет трудно. Можно помочь себе,
создавая фильтр перехвата, чтобы перехватывать только один тип пакетов.
Чтобы получить требуемую информацию, которая показана на рис. 10.6,
мы должны найти шаблон и смещение, указывающее команду SMB delete.
Чтобы сделать это, мы ищем такой кадр в фильтре вывода. Как можно ви-
видеть на рис. 10.7, выбор в панели вывода командной строки SMB высвечи-
высвечивает 06 в шестнадцатеричной панели в строке смещения 03. Просматривая
строку статуса Netmon в нижнем правом углу, мы видим, что точное смеще-
смещение равно Зе в шестнадцатеричном виде. Мы имеем теперь смещение и
шаблон для фильтра перехвата команды delete SMB.
Capture Filter
1
Add
—SAP/ETYPE - Any SAP or Any ETYPE
(Addiess Pairs)
INCLUDE "ANY <•-> "ANY
(Pattern Matches)
Offset ОхЗЕ pattern = 0x0600
Pattern Match
Qffset(inhex| Щ
& Fiom Sjatt of Frame
*"" Fiom ?nd of Topology Header
-.— i Pattern...
I
P.R
OK
Cancel
Help
¦; I Pattern |0S00
<* Hea ^ ASCII
OK.
Cancel
Help
Load...
MOT
Edit
Linfi..
Delete —rf
4"» 1}
Save... |
Рис. 10.6. Фильтр перехвата, который фильтрует команды SMB delete и ослабляет
проблему заполнения буфера перехвата
Выполнение без сопровождения
Мы получили намек из журнала событий на то, почему происходят серверные
ошибки. Вооруженные этой информацией, мы можем теперь выполнить
Netmon без сопровождения и спланировать его выполнение с помощью
команды AT. Так как используется очень специализированный фильтр

284
Глава 10
¦ IFAbookcap.U«b delete cap (Detail)
MAC AddlDst MAC AddiProt
925 00A02474:>DS 0008C7569F9 SMB С delete file. File ¦ NPROGRAMS^TE)IP\t»pU6S aud
9 92S I0008C7569F9 DOA024742D5
11 185J00A024742DS 300вС?56!
11 1880008C7S69F9 00A024742D5
41 73900609777СВ6 COHPAQA63A3
41 74QCOMPAQA63A3 00609777СВ6
SSB
SHB
SHB
sub
SHB
R delete tile
С delete tile
R delate file
С delete file.
R delete file
Fill •
File • \DOMAIM
jlS
<i _ _ .,..,,..,:.„,.„
¦FRAKE Base irane properties
¦ETHERHET, ETYPE ¦ 0x0800 Protocol • IP DOD Internet Protocol
¦IP: ID • 0x3CA7. Proto ¦ TCP. len 136
¦TCP AP len 96 seq 4284951-428S046. ack SW3901. vin 7882 src; U57 dst
¦NBT SS Session Kessage. len: 92
«SHE С delete file. File • 4PROGRAMSsTE)IPNt»pl665 aud . »
¦5MB SMB Status " Error Success i ¦ ,. ; т
¦SKB Header PIP ¦ OxHES TIP ¦ 0x0800 KIP • 0x6701 UID • 0x0800 '
SKB
SHB
¦SKB
SKB
SKB
SHB
4]
00000000
ooooooio
00000020
00000030
00000040
00000050
00000060
00000070
21 i
Word count
i
Vord paraneters
File Attributes
Byte count
•
55
Byte parameters
File na&e
00 08
00 88
00 CE
IE CA
00 00
00 00
SC 00
53 00
C7
3C
04
05
00
00
50
SC
m
6 @x6)
'!*"
- \PROGRAHSvrEHP\t»pU$.S »ud
56
A7
85
93
00
oa
00
oo
9F
40
00
00
00
E5
52
54
92
00
8Б
00
80
14
00
00
00
20
00
00
00
00
4F
45
АО
Db
41
00
00
08
00
00
24
06
62
00
00
01
47
4D
74
25
17
5C
00
67
00
00
2D
0B
03
FF
00
01
52
50
5A
00
8E
53
00
06
00
00
08
00
8D
4D
00
00
41
SC
00
D7
2D
42
00
37
00
oa
1 '
45
0B
50
1
OO
00
18
ИЯ00
00
00
4D
74
00
114
00
00
- '•¦¦viOSr-T^E
><«# •/. *
.* 4 i Ab Ai-P
- о . s SME|
. С
.St. g , 7
n PR 0 0 R* H
SnTEK?M
^twihei Dw lypc of SM8 operaiioo
Fa \li
;OKC2(x3E)
Рис. 10.7. С помощью тщательного анализа шестнадцатеричнои панели
мы находим необходимую информацию для создания мощных фильтров перехвата
перехвата и можно определить достаточно большой буфер перехвата, то
можно позволить ему выполняться в течение достаточно длинного периода
времени.
Сеанс NETMON без сопровождения
использование фильтра перехвата
Netmon /autostart /buffersize 1024000 /capturefilter
с:/smbdelete.cf /autostop
ВВЕДИТЕ ПРИВЕДЕННЫЙ ВЫШЕ ТЕКСТ КОМАНДЫ В ТЕКСТОВЫЙ ФАЙЛ
И СОХРАНИТЕ КАК ФАЙЛ .ВАТ
Используйте службу планировщика для автоматизации процесса.
На рис. 10.8 мы видим, как использовать службу планировщика для авто-
автоматизации сеанса Netmon без сопровождения. Чтобы это работало, необ-
необходимо запустить службу планировщика, используя апплет службы в
управляющей панели. Когда он будет выполняться, мы переходим в окно
CMD и вводим требуемую команду AT. В данном случае мы приказываем
планировщику выполнить наш файл .bat с понедельника до пятницы в 5:00
после обеда. Приведенный выше файл .bat будет выполняться, пока буфер
не заполнится, и затем остановится.

Вопросы поиска неисправностей 285
Рис. 10.8. Использование команды AT для автоматизации сеансов перехвата
сетевого монитора -~ V -,-. '
Выполняя автоматический сеанс Netmon во время проявления сервер-
серверной проблемы, мы имеем хорошую возможность найти неправильно рабо-
работающую программу, которая пытается повторно удалить уже удаленный
файл.
Тщательно созданный фильтр перехвата сокращает беспорядок, кото-
который необходимо расчистить, чтобы найти проблемное приложение. Когда
сообщение об ошибке будет обнаружено, мы просто разрешаем адрес ис-
источника в имя пользователя и находим, какая программа выполняется в то
время, когда мы видим ошибку. Кроме того, можно включить просмотр
времени при открытии файла перехвата и точно увидеть, какой кадр соот-
соответствует определенному сообщению об ошибке в просмотрщике событий.
Избыточное широковещание
Широковещание всегда является хорошим объектом для мониторинга,
так как заставляет все машины в подсети просматривать кадр. Это создает
лишнюю работу для многих машин. Кроме того, когда возникает широко-
широковещательный шторм, он оказывает разрушительное влияние на всю сеть.
К счастью, эти проблемы легко обнаружить, как видно на рис. 10.9. Кажется,
имеется какая-то проблема.
Кто это делает?
При рассмотрении трафика широковещания первый шаг состоит в созда-
создании фильтра вывода широковещания, выбирающего все широковещатель-
широковещательные сообщения в окне фильтра вывода. Когда это будет сделано, проверка
широковещательных сообщений достаточно прямолинейна. Если возника-
возникает широковещательный шторм, как на рис. 10.9, его легко обнаружить.
Наиболее активному пользователю отчет может дать представление о
том, как он повлиял на сеть. Пользователь на рис. 10.9 создал 93 процента

286
Глава 10
Nelwo.lt Hondo. - |G\o.co1.c«p (SuMunll
-RelTiRe TSx
НАС &ddr TSst НАС kddr (Protocol
82,938 О06ОО889БВС2 FFFFFFFFFFFF ARP.RARP ARP: Request, Target IP' 10 1 61 17?
23
25
27
2*
31
зг
31
34
23S
236
23?
2J8
23?
240
241
242
2<J
2<«
246
247
248
249
2S0
!2S1
!2S2
l2S3
|2S4
255
256
I?S?
258
259
92,938
82,939
82.»3S
82,939
02,539
вг.?4В
82.940
82 940
83,131
вз.т
83.131
83.131
83,131
63.131
«3.131
83.132
83.132
83.132
83.132
вздзг
взлзг
вэлзг
83.132
83.132
83.132
83,133
83.133
83.133
83.133
83.133
83.133
183.133
оовооввэввсг
00ьС08вЭВ8С2
006Ш89ВВС2
FFFFFFSTFFFF
собоове-зввсг
[Ю600889ВВС2
*0В
00600889ВВС2
МИ08в9ВВС2
00&008ОТВВС2
00600889ВВС2
0в?0в9ВС
0в08в9С2
OOSD0889BBC2
00600889ВВС2
0«в008в988С2
00600889ВВС2
о
00400889ШС2
00S80889BBC2
08600889БВС2
OOS00889BBC2
o
ооеоевезввсг
0060038 »8К2
FFF?FFTF
FFFFFTFFFFFF
FFFFFFFFFFFF
FFFFFFFFFFFF
FBTFFFTFFFFF
FFFFFFFFWFF
_
ARP RASP
ARPR4RP
_
ASP ЙАЙР
ARPIR4RP
4RF RARP
ARP RASP
MSP_R*RP
4BP EARP
iBP 8ARP
ASP RASP
ARP HARP
_
ARP BASF
ARP_RARP
ARP_R«iP
AHP RARP
ARP~RAi?P
ARP~RAj?P
arpZrarp
AR? HASP
ARP RAHP
AEP~RARP
ARPlRAHP
ARP RASP
ARP RARP
ARP_RARP
ARP RARP
АИР:
ARP:
ARP;
ARP;
ARP:
ARP:
ARP.
dRP
ARP:
ARP:
ARP:
ARP:
ARP
ARP
ARP;
ARP
ARP:
&RP'
ARP:
ABP:
ARP:
ARP:
ARP
ARP:
ASP:
ARP
ARP.
iRP
*RP:
ARP
ARP
ARP
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
Request
.Request
Request
Request
Request
Target IP,
Target IP:
Target IP;
Target IP:
Target IP:
Target IP:
Target IP:
Target IP:
Target IP:
Target IP:
Target IP:
Target IP;
Target IP:
Target IP:
Target IP;
Target IP;
Target IP;
Target IP:
Target IP:
Target IP:
Target IP:
Target IP:
Target IP:
Target IP:
Target IP:
Target IP;
Target IP;
Target IP;
Target IP:
Target IP:
Target IP:
Target IP;
Target IP:
10.1
10.1.
10.1.
10.1.
10.1.
10.1,
10.1.
10.1.
10 1.
10.1
10 1.
10,1
10,1
10.1
10.1
io.г.
10,1.
10,1.
ю.г.
10,1.
юл.
io.i.
10.1
юл
10.1
юл
10.1
10.i
10.1
10.1
io i
ic :
61 w&
SI.175
61.174
61.173
61.172
«1.171
61.170
61.169
61.168
61.H?
61,166
41.165
61,164
61.163
61.162
.61.161
. 61. Ш
.61 Ш
.61,158
.61.157
.61.156
.61.155
61 1S4
61 1S3
.61 1S2
.61.151
61 ISO
61,149
61.148
.61.147
.61.146
61 145
6».144
JABP Ptotocoi Sietnty Wo»al«jn
' IFs: JO Л «88
' fo«. мьгТ (Qewci
Рис. 10.9. Некоторые проблемы очень легко обнаружить
трафика в относительно загруженной сети. Наверняка этому пользовате-
пользователю казалось, что сеть тормозит, и он не подозревал о своей причастности
к этой проблеме. Следующий пакет ARP показывает IP-адрес и адрес MAC
вызывающей шторм машины.
ARP_RARP: ARP:
ARP_RARP:
ARP_RARP:
ARP_RARP:
ARP_RARP:
ARP_RARP:
ARP_RARP:
ARP_RARP:
ARP_RARP:
ARP_RARP:
ARP_RARP:
Request, Target IP: 10.1.61.176
Hardware Address Space = 1 @x1)
Protocol Address Space = 2048 @x800) '"
Hardware Address Length = 6 @x6)
Protocol Address Length = 4 @x4)
Opcode = 1 @x1)
Sender's Hardware Address = 00600889BBC2
Sender's Protocol Address = 10.1.1.163
Target's Hardware Address = 000000000000
Target's Protocol Address = 10. 1.61.176
Frame Padding

Вопросы поиска неисправностей 287
Поиск имени пользователя
Получить IP-адрес из кадра
можно использовать ping -a 10.0.0.163 для получения имени хоста
можно использовать агр -а для вывода кэша ARP
можно использовать nbtstat -a 10.0.0.163 для получения таблицы
имен NetBIOS удаленной машины
Почему они это делают?
Очевидно, что это вопрос, на который необходимо ответить, чтобы испра-
исправить проблему. В краткосрочном периоде, вооружившись информацией,
полученной при использовании различных утилит командной строки, пе-
перечисленных выше, можно проследить машину и отключить ее в сети. Это
определенно улучшит время ответа для других пользователей сети.
Теперь, когда проблема не вызывает кризиса (и сопровождающих теле-
телефонных звонков), есть время проанализировать ее. Необходимо исследо-
исследовать машину и проверить, какое установлено программное обеспечение,
какие протоколы загружены, а также вид используемого сетевого адаптера.
Кроме того, необходимо посмотреть, существуют ли обновления для любо-
любого из этих объектов — приложений, драйверов и т.д. Не забудьте проверить
обновления встроенных программ самого компьютера.
Так как мы обнаружили проблему, можно вернуться назад и рассмотреть
некоторые предыдущие трассировки, чтобы также поискать в них широко-
широковещательные сообщения. Возможно, что мы не выполняли фильтр широко-
широковещания на предыдущих трассировках. Может быть, важно увидеть, как
долго существовала проблема, чтобы получить данные, которые помогут
при выявлении причин неисправности. Определив, когда возникла пробле-
проблема, можно получить представление о том, что изменилось в тот день, что
было добавлено, удалено или обновлено, т.е. что вызвало проблему.
Просмотр Web-сайтов поставщика, которые поддерживают определен-
определенную комбинацию, существующую на рассматриваемой машине. Перейдите
в раздел Web-сайта, посвященный поддержке, и выполните запрос о широ-
широковещании ARP для стартеров. Если это не поможет, то может оказаться
полезным посещение групп новостей в Интернете и запрос о шторме ши-
широковещания ARP. Конечно, прежде чем делать такой запрос, проверьте
архив группы новостей, чтобы увидеть, сколько раз этот вопрос уже зада-
задавался. Если это распространенная проблема, то, конечно, множество лю-
людей уже встречали аналогичные симптомы. Возможно, вы обнаружите, что
эта проблема была вызвана старой как мир программой Jet Admin, которая
пыталась автоматически найти все принтеры в мире, используя ARP для за-
запроса всего адресного пространства в сети в поисках всех не сконфигури-
сконфигурированных принтеров. Это может показаться хорошей идеей, пока не
поймешь, что существует почти 17000000 адресов хостов в сети класса А.
Это достаточно большой объем широковещания. Реализованное исправле-
исправление включало: загрузку последней версии программного обеспечения,

288 " Глава 10
поиск всех файлов, связанных со старой программой (она не имела про-
программу деинсталляции), поиск реестра для удаления всех ссылок на старую
программу, перезагрузку машины, проверку с помощью Netmon, не начала
ли она снова широковещание, и, наконец, установку нового программного
обеспечения.
Обзор главы t
В этой главе обсуждались некоторые общие вопросы соединения и спосо-
способы использования Netmon во время поиска неисправностей. Были рассмот-
рассмотрены ситуации, где можно делать ping сервера, но нельзя сделать net view
на сервере. В этом сценарии Netmon нашел ошибку сеанса NBT, утвержда-
утверждающую, что служба не существует на целевой машине. Затем была рассмот-
рассмотрена ситуация, когда клиентская машина DHCP не могла получить
выделенный адрес. Машина делала правильные запросы, но не получала
никакого ответа, кроме отказа на запрос получить старый IP-адрес. После
успешного разрешения этой проблемы мы обратились к старой как мир жа-
жалобе о том, что сеть работает медленно. Используя экспертов Netmon 2, мы
смогли определить, насколько сеть медленна, и использовали дополнитель-
дополнительные утилиты, помогающие ослабить источник замедления. Наконец, мы
решили проблему регистрации, внимательно проверяя, что именно ввел
пользователь. Это помогло избежать дорогостоящего вызова сервисной
службы независимой компании или трудностей и неудобств по доставке
компьютера в отдел информационных технологий компании.
В следующей главе •»¦ ,•««*•¦ •
В следующей главе мы рассмотрим сетевую безопасность. Мы исследуем, как
обнаружить и остановить незаконные серверы DHCP, используя Network
Monitor версий 1.2 и 2.0. Мы проанализируем процесс перехвата данных и
создание триггера перехвата и фильтра перехвата. Затем мы рассмотрим
настройку монитора сервера Rogue DHCP с помощью Network Monitor 2.0,
используя существующие утилиты управления монитором.
Затем мы остановимся на идентификации неавторизованного сетевого
анализатора с помощью Network Monitor версий 1.2 и 2.0. Мы проанализи-
проанализируем шаблоны трафика, связанные с каждым из них, и сконфигурируем
триггеры и фильтры перехвата. Мы рассмотрим использование утилит
управления сетевым монитором для прекращения доступа неавторизован-
неавторизованных сетевых анализаторов к сети и поймем, как можно реально помешать
сетевому анализатору собирать данные.

Глава 11
Вопросы безопасности
Вопросы безопасности всегда вызывают пристальное внимание у каждого
сетевого администратора. Защита сети является одной из наиболее важных
обязанностей сетевого администратора и одним из вопросов, которые
постоянно задают консультантам.
Нелегальные серверы DHCP
Нелегальными серверами DHCP являются "левые" серверы, которые рас-
располагаются в сети подобно минным полям, ожидая прибытия ничего не
ожидающего компьютера. Хотя большинство этих инцидентов происходит
по вине наивных пользователей или неопытных администраторов, сущест-
существуют ситуации, когда играет роль саботаж. В любом случае эффект будет
один и тот же — неограниченный хаос, так как коммуникация между ма-
машинами начинает разрушаться. В этом сценарии будут один или два резуль-
результата. "Левый" сервер DHCP раздает адреса, которые действительны для
определенной области сети, приводя тем самым к дублированию IP- адресов.
Когда это происходит, машина, имевшая IP-адрес дольше всех, обычно выиг-
выигрывает, когда отвечает на ARP_RARP, посланный машиной, получающей ад-
адрес. Новая машина должна затем освободить адрес. В таком сценарии новая
машина неспособна общаться с другими компьютерами. Другой результат
состоит в том, что нелегальный сервер DHCP раздает адреса, которые не-
недействительны в сети, и новые машины неспособны общаться с кем-либо,
кроме себя самой. Ни один из таких сценариев никого не устраивает.
Есть ли у меня для вас адрес?
Когда клиентская машина DHCP подключается к линии, она делает широ-
широковещательный запрос DHCP. Этот запрос поступает в каждую машину в
сети, так как имеет место назначения в Ethernet FFFFFFFFFFFF и место на-
назначения в IP 255.255.255.255. Как можно видеть на распечатке ниже, дей-
тограмма UDP направляется во все машины, которые слушают порт 67.

290
Глава 11
ETHERNET: ETYPE = 0x0800 : 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
RTHERNET: 0. = Universally Administered address
ETHERNET: Frame Length : 342 @x0156)
ETHERNET: Ethernet Type : 0x800 (IP: DOD Internet
Protocol)
ETHERNET: Ethernet Data: Number of data bytes
remaining = 328 @x0148)
IP: ID = 0x0; Proto = UDP; Len: 328
IP: Version = 4 @x4)
IP: Header Length =20 @x14)
IP: Service Type = 0 @x0)
IP: Precedence = Routing
IP: ...0.... = Normal Delay
4! ' ' IP: ....0... = Normal Throughput ¦ •¦-.¦¦'.¦>
" IP: 0.. = Normal Reliability '•' ' ' :
IP: Total Length = 328 @x148) ;..¦•>. . <
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 -i^-v-i .•'.. -^
"'¦' IP: Source Address = 0.0.0.0 ' '¦'<''
IP: Destination Address = 255.255.255.255 ¦ ¦ ¦•¦
IP: Data: Number of data bytes remaining =3 08
@x0134)
UDP: IP Multicast: Src Port: BOOTP Client, F8); Dst Port:
BOOTP Server F7); Length = 308 @x134)
UDP: Source Port = BOOTP Client
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: Discover (xid = 05D105D1)
DHCP: Op Code (op) = 1 @x1)
DHCP: Hardware Type (htype) = 1 @x1) 10Mb Ethernet
DHCP: Hardware Address Length (hlen) = 6 @x6)
DHCP: Hops (hops) = 0 @x0)
DHCP: Transaction ID (xid) = 97584593 @x5D105Dl)
DHCP: Seconds (sees) = 0 @x0)

Вопросы безопасности
291
Любая машина, которая слышит этот запрос, может ответить, посылая
широковещательное сообщение UDP с портом места назначения 68. Это ши-
широковещание IP в адрес 255.255.255.255. Любая машина, которая слышит
предложение DHCP, может запросить адрес.
ETHERNET: ETYPE = 0x0x0800 : Protocol = IP: DOD Internet
Protocol
IP: ID = 0xB71F; ProtO = UDP: Len: 328
IP: Version = 4 @x4) - Г • •'• : ¦
, .¦¦¦•• IP: Header Length = 20 @x14) : ¦' ¦¦¦;..¦:->'¦ ¦ V - • .^ ....
+ IP: Service Type = 0 @x0) . ¦ ¦•..>
.:• IP: Total Length = 328 @x148) -;1 .. •• ,-.. ,<-.
IP: Identification = 46879 @xB71F) . ...:,, ¦
+ IP: Flags Summary = 0 @x0) . , .. . ,... .....
IP: Fragment Offset = 0 @x0) bytes
¦' , . IP: Time to Live = 128 @x80)
IP: Protocol = UDP - User Datagram '
IP: Checksum =0x787B
IP: Source Address =10.0.0.11 ¦
1 ' IP: Destination Address = 255.255.255.255
IP: Data: Number of data bytes remaining =3 08
@x0134)
UDP: IP Multicast: Src Port: BOOTP Server, F7); Dst
Port: BOOTP Client F8); Length = 308 @x134)
UDP: Source Port = BOOTP Server
UDP: Destination Port = BOOTP Client ¦;
UDP: Total length = 308 @x134) bytes
UDP: UDP Checksum = 0x6D2F
UDP: Data: Number of data bytes remaining =3 00
@x012C)
DHCP: Offer (xid = 05D105D1)
DHCP: Op Code (op) = 2 @x2)
Hardware Type (htype) = 1 @x1) 10Mb
DHCP
Ethernet
DHCP
DHCP
DHCP
@x5D105Dl)
DHCP: Seconds
DHCP: Flags
DHCP:
DHCP: Client
DHCP: Your
DHCP:
DHCP:
DHCP:
DHCP:
DHCP:
DHCP :
DHCP:
Hardware Address Length (hlen) =
6 @x6)
@x0)
Hops (hops) = 0
Transaction ID (xid) = 97584593
(sees) = 0 @x0)
(flags) = 0 @x0)
0 = No Broadcast
IP Address (ciaddr) = 0.0.0.0
IP Address (yiaddr) = 10.0.0.76
IP Address (siaddr) = 0.0.0.0
IP Address (giaddr) = 0.0.0.0
Server
Relay
Client Ethernet Address (chaddr) = 00104BEC8DB2
Server Host Name (sname) = <Blank>
Boot File Name (file) = <Blank>
Magic Cookie = [OK]
Option Field (options)
DHCP: DHCP Message Type = DHCP Offer '<
DHCP: Subnet Mask = 255.0.0.0

292
Глава 11
..; . . . ,, . DHCP: Renewal Time Value (Tl) = 1 Days, 12:00:00
. ... _. .,. DHCP: Rebinding Time Value (T2) = 2 Days, 15:00:00
DHCP: IP Address Lease Time = 3 Days, 0:00:00
DHCP: Server Identifier = 10.0.0.11
DHCP: Router =10.0.0.15
DHCP: Domain Name Server =10.0.0.10
DHCP: NetBIOS Name Service = 10.0.0.10
В связи с широковещательной природой протокола DHCP нелегальных
серверов DHCP быть в сети не должно. Одним из способов управления рас-
распространением серверов DHCP является конфигурирование триггера со
смещением 2А и шаблоном, совпадающим с 0201. Он будет обнаруживать и
сигнализировать о деятельности DHCP в сети. Затем можно будет исполь-
использовать перехваченную информацию для отслеживания и удаления неавто-
неавторизованных машин. Это не такой простой способ использования триггера
для изолирования ответа только на нелегальные серверы DHCP. Этот
подход проиллюстрирован на рис. 11.1 и допустим в программах Netmon
версий 1.2 и 2.0.
Для Netmon 1.2 существует также утилита управления монитором, ко-
которая может быть сконфигурирована для создания события, когда она
Capture Tiiqqer
Trigger on
С Nothing
f Pattern match
С Suffer space
<~ Pattern match then buffer space
(* Bu.f/ei space Ihen pattern match
Buffer Space
r
с
r
25%
50*
75*
Pattern
Offset (Hex):
Pattern: |0201
<* From Start of Fiame
С Ftom End of Jopology Header
Hex
ASCil
T nggei Action
<• Audible Signal Only
Slop Capture
Execute Command Line |C:\roguedhcp.bat
Browse... I
Cancel
Help
Рис. 11.1. Триггер сигнализирует администратору о присутствии DHCP

Вопросы безопасности
293
[ИДГПД31В
JfPe
IConliguip Hoquc Dili С ami WINS MofMoil
1
rUI>
Rogue DHCP and WINS Monitor Configuration
What do you want the Rogue DHCP and WINS monitor to do?
<* Monitor for Rogue DHCP and WINS Servers
<* Monitor for Rogue DHCP Servers
<~ Monitor for Rogue WINS Servers
Valid DHCP
Addresses
Valid WINS
Addresses
In the text box to the left, enter the IP
Addresses of the computers that you expect to
be sending DHCP Server messages on your
network. These valid servers will be ignored by
the monitor.
In the text box to the left, enter the IP
Addresses of the computers that you expect to
be sending WINS Server messages on your
network. These valid servers will be ignored by
the monitor.
Рис. 11.2. Утилита управления монитором сервера незаконного DHCP и WINS
создает событие при обнаружении нелегальных серверов
обнаруживает "левый" сервер DHCP. Она работает таким же образом,
как и триггер, показанный на рис. 11.1, но имеются дополнительные воз-
возможности узнать, какие серверы DHCP авторизованы, поскольку они
были перечислены при конфигурировании нелегального монитора, как
на рис. 11.2.
Утилита управления монитором незаконного монитора DHCP также
требует проверки событий и ничего не делает для неавторизованного сер-
сервера. Лучшим подходом было бы инициирование пакетного файла, кото-
который вызывает команду shutdown из набора ресурсов NT. Windows 2000
реализует широковещание DHCPINFORM в реализации DHCP, которая со-
создана для проверки в активном каталоге, прежде чем обслуживать запросы
от клиентов. Это широковещание происходит, даже если он не находит
контроллер домена. Активный каталог будет продолжать зондировать
DHCPINFORM каждые пять минут, даже если начнет выполняться сервер
DHCP. Когда контроллер появляется в сети, то если сервер DHCP не был
специально авторизован в активном каталоге, он будет прекращать работу
как сервер DHCP.

294
Глава 11
. . -. Y-sv . *¦ .j.'. . *¦ ¦ ¦ *.\~ ¦or*'-;"*--'? "¦••'АЦГ..- ¦•¦¦.--'•Г1-.'- -.-¦¦¦¦'¦:¦* ¦¦•¦' "• -v^jtf^-- ¦-*'*
Итак, где вы? ^-^ ^: .^.
Получив сигнал о наличии нелегального сервера DHCP, можно просмот-
просмотреть перехваченное предложение DHCP, найти идентификатор сервера,
а затем, используя такие утилиты, как ARP и NBTSTAT, найти сервер и
выключить его.
DHCP: Offer ' (xid=05D105Dl)
DHCP: Op Code (op)
DHCP: Hardware Type (htype)
DHCP: Hardware Address Length
= 2 @x2)
= 1 @x1)
(hlen) = 6
= 0 @x0)
= 97584593
= 0 @x0)
= 0 @x0)
10Mb Ethernet
@x6)
@x5D105Dl)
DHCP
DHCP
DHCP
DHCP
DHCP
DHCP
DHCP: Hops (hops)
DHCP: Transaction ID (xid)
DHCP: Seconds . (sees)
DHCP: Flags ' (flags)
DHCP: 0 = No Broadcast
DHCP: Client IP Address (ciaddr) =0.0.0.0
DHCP: Your IP Address (yiaddr) = 10.0.0.76 ,Л,
DHCP: Server IP Address (siaddr) = 0.0.0.0 -.'..' ¦. y.
DHCP: Relay IP Address (giaddr) = 0.0.0.0
DHCP: Client Ethernet Address (chaddr) = 00104BEC8DB2
DHCP: Server Host Name (sname) = <Blank>
DHCP: Boot File Name (file) = <Blank>
DHCP: Magic Cookie = [OK]
DHCP: Option Field (options) ¦ '• ¦¦¦
DHCP: DHCP Message Type = DHCP Offer — —
DHCP: Subnet Mask = 255.0.0.0
DHCP: Renewal Time Vaqlue (Tl) = 1 Days, 12:00:00
Rebinding Time Value (T2) = 2 Days, 15:00:00
IP Address Lease Time = 3 Days, 0:
Server Identifier = 10.0.0.11
Router = 10.0.0.15
Domain Name Server = 10.0.0.10
NetBIOS Name Service = 10.0.0.10
00:00
Нелегальный анализ сети ("вынюхивание")
Во многих отношениях нелегальный анализ сети ("вынюхивание", англ.
sniffing) является значительно большей угрозой безопасности, чем нелега-
нелегальный сервер DHCP. Как мы видели в этой книге, с помощью Netmon и
правильного понимания протоколов в незащищенной сети можно собрать
информацию любого вида. Это включает возможность считывать данные,
которые передаются по линиям связи, такие как почта POP и SMTP, паро-
пароли Telnet, FTP, POP3 и многое другое. Чтобы проанализировать сеть, необ-
необходимо иметь портативный компьютер, плату Ethernet в свободном
(беспорядочном) режиме и незащищенное сетевое соединение. В течение
очень короткого времени можно собрать достаточно информации, чтобы
сделать сеть полностью неуправляемой.

Вопросы безопасности
295
Прежде всего необходимо их найти
Netmon 1.2 имеет возможность непосредственно определять драйвер для
анализаторов и агентов 1.2. Однако он может фильтровать кадры системы
безопасности, которые посылает программа Netmon 2.O. Эти кадры систе-
системы безопасности показаны на рис. 11.3. Используя смещение 00 и шаблон
030000000002, можно сконфигурировать фильтры вывода и триггеры для
изоляции кадров системы безопасности. Это можно сделать в Network
Monitor 1.2 и 2.0.
?>№ Е«
loo's Qpfom Wndow Hcip
Time
[ Dst НАС Addr
Prot
Description
10 10.
20 11
30 11
40 12
SO.12
LOCAL
LOCAL
LOCAL
LOCAL
LOCAL
030000000002
030000000002
030000000002
030000000002
030000000002
Bone
Bone
Bone
Bone
Security Check @x03)
Security Check @x03)
Security Check @x03)
Security Check @x03)
Security Check @*03)
J
¦Frame Base frame properties
¦ETHERNET 602 3 length • 197
¦LLC UI DSAP-0x03 SSAP-0x02 С
Bone Signature - RTSS
Bone Command " Security Check @x0 3)
Bone Flags • 0x00
52 54 53 53 0J 00 00 '30 00 00 A8 00 01 00 00
07 05 D7 95 SO 5j 4F 58 00 :s 4D 00 ВС F0 12
00 CF 90 35 00 41 64 tb 6? 6E 69 73 74 72 61 ?4
bF 72 00 00 00 10 00 00 00 12 11 00 75 1'3 ;3 04
|78 0C Fl 12 0C 01 00 00 00 00 90 27 64 FA [>•> 00
ISO 27 64 РЛ Ob 50 00 52 00 4F 00 5Э 00 00 00 28
100 4D 00 00 00 EC 00 Fu 00 12 00 00 00 CF 00 *0
lOJi 35 00 01 00 41 00 64 00 12 00 69 03 SE 00 b«
00 73 00 74 00 72 00 61 00 74 00 6F 00 72 00 00
'00 00 00 00 Ll(. 10 00 00 UU 00 00 00 05 1У 20 11
-E5 Adftjnistrat
or x»f
x ¦ E'd ¦
Vd *P ft О S l
И +.' . - ?.
5 Ad in l ii l1
Рис. 11.3. Кадры системы безопасности Netmon 2.0 являются хорошей мишенью для
триггера
Сетевой монитор может также использовать свойство определения по-
пользователей сетевого монитора из меню tools. Версия 2 продукта способна
определить драйвер 1.2 и драйвер 2.0. Конечно, Netmon 1.2 может обнару-
обнаружить только свой собственный драйвер. Инструмент Netmon 2.0 показан
на рис. 11.4.
Как отбить нюх чужим ищейкам
Наиболее мощным решением проблемы нелегального анализа сети являет-
является утилита управления сетевым монитором. Неавторизованная программа
будет закрыта при попытке выполнения. Это актуально только для

296
Глава 11
Identify Network Monitor Users
Total Instated 4
Total Running 3
Total Capturing. 0
Relresh Ust
Г Add Names to Address Database
OK
Help
Рис. 11.4. Network Monitor 2.0 может обнаружить свой собственный драйвер
и драйвер 1.1 ¦ - - ¦ :-¦• ¦,"¦', ""v<.
программы сетевого монитора версии 2. Netmon 1.2 будет выполняться без
последствий. Чтобы определить его присутствие, используйте утилиту
идентификации пользователей сетевого монитора.
Обзор главы . -.,.,.
В этой главе были рассмотрены некоторые вопросы безопасности сетей,
протоколов и утилит, используемые для анализа. Были обсуждены пробле-
проблемы, возникающие при бездумном запуске в сети сервера DHCP, и несколько
методов обнаружения и удаления таких серверов. Мы также рассмотрели во-
вопросы безопасности, касающиеся утилит сетевого монитора. Мы увидели,
что наиболее мощным оружием, которое существует для защиты от атак анали-
анализа сети, является использование анализатора для обнаружения и выключения
нелегальных сетевых мониторов.

Приложение А
Список общеизвестных
номеров портов TCP и UDP
Таблица АЛ. Общеизвестные номера портов TCP и UDP
Десятичное
значение
O/tcp, udp
1/tcp, udp
2/tcp, udp
3/tcp, udp
4/tcp, udp
5/tcp, udp
6/tcp, udp
7/tcp, udp
8/tcp, udp
9/tcp, udp
10/tcp, udp
11/tcp, udp
12/tcp, udp
13/tcp, udp
14/tcp, udp
15/tcp, udp
Зарезервированное
слово
tcpmux
compressnet
compressnet
Че
echo
discard
systat
daytime
Описание
Зарезервировано
Мультиплексор службы порта TCP
Утилита управления
Процесс сжатия
Не используется
Вход удаленного задания
Не используется
Эхо-сигнал
Не используется
Отбросить; алиас= sink null
Не используется
Активные пользователи;
алиас = users
Не используется
Время дня
Не используется
Не используется [было netstat]

298
Таблица АЛ.
Десятичное
значение
16/tcp, udp
17/tcp, udp
18/tcp, udp
19/tcp, udp
20/tcp, udp
21/tcp, udp
22/tcp, udp
23/tcp, udp
24/tcp, udp
25/tcp, udp
26/tcp, udp
27/tcp, udp
28/tcp, udp
29/tcp, udp
30/tcp, udp
31/tcp, udp
32/tcp, udp
33/tcp, udp
34/tcp, udp
35/tcp, udp
36/tcp, udp
37/tcp, udp
38/tcp, udp
39/tcp, udp
40/tcp, udp
41/tcp, udp
Приложение А
Общеизвестные номера портов TCP и UDP (продолжение)
Зарезервированное Описание
слово
qotd
msp
chargen
ftp-data - •*
ftp
telnet
smtp
nsw-fe "
msg-icp
msg-auth
dsp
time
rip
graphics
He используется
Ссылка дня; алиас = quote
Протокол отправки сообщений
.. . Генератор символов; ^ , ^р *\
i .,' './¦ Ш алиас = ttytst source А$ ¦' $¦ *J
* * ч T* Пересылка файлов
* / .L С' [данные по умолчанию]
Пересылка файлов [управление],
диалоговое соединения
Не используется
Telnet
Любая частная почтовая система
SMTP; алиас = mail
Не используется
NSW User System FE _____ Z
He используется
MSGICP
He используется
Аутентификация MSG
¦ t. - . »
He используется
Протокол DSP
(Display Support Protocol)
He используется
Любой частный принт-сервер
Не используется
Время; алиас = timeserver
Не используется
Протокол определения
местоположения ресурсов (RLP);
алиас = resource
Не используется
графика

Список общеизвестных номеров портов TCP и UDP
299
Таблица АЛ. Общеизвестные номера портов TCP и UDP (продолжение)
Десятичное Зарезервированное Описание ; ;,,-
значение слово
42/tcp, udp
43/tcp, udp
44/tcp, udp
45/tcp, udp
46/tcp, udp
47/tcp, udp
48/tcp, udp
49/tcp, udp
50/tcp, udp
51/tcp, udp
52/tcp, udp
53/tcp, udp
54/tcp, udp
55/tcp, udp
56/tcp, udp
57/tcp, udp
58/tcp, udp
59/tcp, udp
60/tcp, udp
61/tcp, udp
62/tcp, udp
63/tcp, udp
64/tcp, udp
65/tcp, udp
66/tcp, udp
67/tcp, udp
68/tcp, udp
69/udp
70/tcp, udp
nameserver
nicname
mpm-flags
mpm
mpm-snd
ni-ftp i
login i. •
re-mail-ck
la-maint
xns-time
domain
xns-ch
isi-gl
xns-auth
xns-mail
ni-mail
acas
via-ftp I '
covia
tacacs-ds .; .
sql*net
bootpc
bootpc
tftp
gopher
Сервер имен хостов;
алиас = nameserver
Who Is; алиас = nicname
Протокол MPM FLAGS
Модуль обработки сообщений
MPM [отправка по умолчанию]
NIFTP •
Не используется
Протокол хоста регистрации
Протокол проверки удаленной
почты
Поддержка логического адреса IMP
Протокол времени XNS
Сервер имен доменов
Центр обмена информацией XNS
Графический язык ISI
Аутентификация XNS
Любой частный терминальный
доступ
Почта XNS
Любая частная файловая служба
Не используется
NIMAIL
Службы АСА
VIA Systems - FTP
Интегратор коммуникации (CI)
Служба базы данных TACACS
Oracle SQL*NET
Сервер протокола DHCP/BOOTP
Серве протокола DHCP/BOOTP
Протокол TFTP
Gopher " '

300
Приложение А
Таблица АЛ. Общеизвестные номера портов TCP и UDP (продолжение)
Десятичное Зарезервированное Описание*. ¦ i •• .:><;;-:
значение слово
Служба удаленных заданий
Служба удаленных заданий
Служба удаленных заданий *''''¦¦'•'
Служба удаленных заданий '$'
Любая частная служба внешнего
соединения > > -
Не используется <, \'.
!' Любая частная служба RJE
Vettcp
Finger
WWW HTTP
Сервер имен HOSTS2
УтилитаXFER !' ' ' '
Устройство MIT ML : ! '
Средство общей трассировки
Устройство MIT ML ¦'¦'' '-'¦
Micro Focus Cobol J
Любая частная терминальная линия;
алиас = ttylink
Kerberos
Шлюз Telnet SU/MIT
Шлюз Telnet SU/MIT
Отображение маркера атрибута '
безопасности DNSIX '.
MIT Dover Spooler • ,
'¦¦ Протокол сетевой печати
Протокол управления устройством
(DCP)
Диспетчер объектов Tivoli
SUPDUP
Спецификация протокола DIXIE
Протокол Swift удаленного
виртуального файла
71/tcp, udp
72/tcp, udp
73/tcp, udp
74/tcp, udp
75/udp
76/tcp, udp
77/tcp, udp
78/tcp, udp
79/tcp, udp
80/tcp, udp
81/tcp, udp
82/tcp, udp
83/tcp, udp
84/tcp, udp
85/tcp, udp
86/tcp, udp
87/tcp, udp
88/tcp, udp
89/tcp
89/udp
90/tcp, udp
91/tcp, udp
92/tcp, udp
93/tcp, udp
94/tcp, udp
95/tcp, udp
96/tcp, udp
97/tcp, udp
netrjs-1
netrjs-2
netrjs-3
netrjs-4
vettcp i
finger
www
hosts2-ns
xfer
mit-ml-dev
ctf
mit-ml-dev
mfcobol
kerboros
su-mit-tg
su-mit-tg
mit-gov
npp
dcp
objcall
siipdup
dixie
swift-rvf

Список общеизвестных номеров портов TCP и UDP
301
Таблица АЛ. Общеизвестные номера портов TCP и UDP (продолжение)
Десятичное Зарезервированное Описание ;¦¦
значение слово
98/tcp, udp
99/tcp, udp
100/tcp
101/tcp, udp
102/tcp, udp
103/tcp, udp
104/tcp, udp
105/tcp, udp
106/tcp, udp
107/tcp, udp
108/tcp, udp
109/tcp, udp
110/tcp, udp
111/tcp, udp
112/tcp,udp
113/tcp, udp
114/tcp, udp
115/tcp, udp
116/tcp, udp
117/tcp, udp
118/tcp, udp
119/tcp, udp
120/tcp, udp
121/tcp, udp
tacnews
metagram
newacct
hostname
iso-tsap
gppitnp
acr-nema
csnet-ns
3com-tsmux
rtelnet
snagas
pop2
рорЗ
sunrpc
mcidas
auth
audionews
sftp
ansanotify
uucp-path
sqlserv •. i ¦
nntp
cfdptkt
erpc
TAC News
Metagram Relay
[нелегальное использование]
сервер имен хостов NIC;
алиас = hostname
ISO-TSAP
Genesis Point-to-Point TransNet;
алиас = webster
ACR-NEMA Digital Imag.
& Comm. 300
Сервер имен почтовых ящиков
3COM-TSMUX
Удаленная служба Telnet
Сервер доступа шлюза SNA
Протокол POP (Post Office Protocol) -
версия 2; алиас = postoffice
Протокол POP (Post Office Protocol) -
версия З; алиас = postoffice
Вызов удаленной процедуры
компании SUN
Протокол передачи данных McIDAS
служба аутентификации;
алиас = authentication
Многоадресная рассылка
аудио-новостей
Протокол SFTP (Simple File
Transfer Protocol) ., ( ',
ANSA REX Notify
Служба путей доступа UUCP
Службы SQL
Протокол передачи сетевых . • \ •
новостей; алиас = usenet
CFDPTKT
Encore Expedited Remote Pro.Call

302
Таблица АЛ. Общеизвестные номера
Десятичное
значение
122/tcp, udp
123/tcp, udp
124/tcp, udp
125/tcp, udp
126/tcp, udp
127/tcp, udp
128/tcp, udp
129/tcp, udp
130/tcp, udp
131/tcp, udp
132/tcp, udp
133/tcp, udp
134/tcp, udp
135/tcp, udp
136/tcp, udp
137/tcp, udp
138/tcp, udp
139/tcp, udp
140/tcp, udp
141/tcp, udp
142.tcp, udp
143/tcp, udp
144/tcp, udp
145/tcp, udp
146/tcp, udp
147/tcp, udp
148/tcp, udp
149/tcp, udp
150/tcp, udp
151/tcp, udp
Приложение А
портов TCP и UDP (продолжение)
Зарезервированное Описание ... . r <
слово
smakynet
ntp
ansatrader
locus-map „¦;¦
unitary - r
locus-con ¦¦¦
gss-xlicen
pwdgen
cisco-fna
cisco-tna
cisco-sys
statsrv
ingres-net
loc-srv
profile „,..,.,..
netbios-ns
netbios-dgm
netbios-ssn
emfis-data
emfis-cntl
bl-idm
imap2
news
uaac
iso-ipO
iso-ip ¦'¦ ¦ ¦ ¦¦ ¦"¦
cronus ;
aed-512
sql-net
hems
SMAKYNET
Протокол сетевого времени;
ал и ас = ntpd ntp
ANSA REX Trader
Locus PC-Interface Net Map Server
Unisys Unitary Login
Locus PC-Interface Conn Server
GSS X License Verification
Протокол генерации протоколов
Cisco FNATIVE
Cisco TNATIVE
Cisco SYSMAINT
Служба статистики
Служба INGRES-NET
Служба места расположения
Служба именования PROFILE
Служба имен NetBIOS
Служба дейтаграмм NetBIOS >
Служба сеанса NetBIOS
Служба данных EMFIS
Служба контроля EMFIS
Britton-Lee IDM
Промежуточный протокол доступа
к почте версии 2
newS; алиас = news
Протокол UAAC
ISO-IP0
ISO-IP
CRONUS-SUPPORT
AED 512 Emulation Service
SQL-NET
HEMS

Список общеизвестных номеров портов TCP и UDP
303
Таблица АЛ. Общеизвестные номера
Десятичное
значение
152/tcp, udp
153/tcp, udp
154/tcp, udp
155/tcp, udp
156/tcp, udp
157/tcp, udp
158/tcp, udp
159/tcp, udp
160/tcp, udp
161/tcp, udp
162/tcp, udp
163/tcp, udp
164/tcp, udp
165/tcp, udp
166/tcp, udp
167/tcp, udp
168/tcp, udp
169/tcp, udp
170/tcp, udp
171/tcp, udp
172/tcp, udp
173/tcp, udp
174/tcp, udp
175/tcp, udp
176/tcp, udp
177/tcp, udp
178/tcp, udp
179/tcp, udp
180/tcp, udp
181/tcp, udp
портов TCP и UDP (продолжение)
Зарезервированное Описание
слово
bftp
sgmp
netsc-prod
netsc-dev
sqlsrv
knet-cmp '"
pcmail-srv
nss-routing
sgmp-traps
snmp
snmptrap
cmip-man
cmip-agent
xns-courier
Z1
s-net |
narap
r i Ml' ¦¦) ¦
rsvd ...
send
print-srv
multiplex ,
cl/1 :.
xyplex-mux
mailq
vmnet
genrad-mux
xdmcp
nextstep
bgp h
unify
. • f 1 . . . '. Fl . 1. i ¦
Фоновая программа пересылки
файлов
SGMP; алиас = sgmp
Netscape ' '
Netscape ' "':'
служба SQL
Протокол сообщений/команд
KNET/VM
Сервер PCMail; алиас = repository
NSS-Routing
SGMP-TRAPS r" ' ''
SNMP; алиас = snmp "¦'''
SNMPTRAP ' ;
Менеджер CMIP/TCP
Агент CMIP/TCP : '
Xerox ' ''i>:' " ;'-
SiriusSystems "' n>)" ¦ ' :
NAMP
RSVD
SEND \ ' . ..
Network PostScript
Network Innovations Multiplex
Network Innovations CL/1
Xyplex
MAILQ
VMNET ' '_ '¦'¦
GENRAD-MUX
X Display Manager Control Protocol
NextStep Window Server
Border Gateway Protocol
Intergraph
Unify

304
Приложение А
Таблица A.I. Общеизвестные номера
Десятичное
значение
182/tcp, udp
183/tcp, udp
184/tcp, udp
185/tcp, udp
186/tcp, udp
187/tcp, udp
188/tcp, udp
189/tcp, udp
190/tcp, udp
191/tcp, udp
192/tcp, udp
193/tcp, udp
194/tcp, udp
195/tcp, udp
196/tcp, udp
197/tcp, udp
198/tcp, udp
199/tcp, udp
200/tcp, udp
201/tcp, udp
202/tcp, udp
203/tcp, udp
204/tcp, udp
205/tcp, udp
206/tcp, udp
207/tcp, udp
208/tcp, udp
209/tcp, udp
210/tcp, udp
211/tcp, udp
портов TCP и UDP (продолжение)
Зарезервированное Описание
слово
audit
ocbinder
ocserver
remote-kis
kis
aci .... ,
mumps „.
qft- .
SacP я i v
prospero
osu-nms ,,-,-.
srmp
ire
dn6-nlm-aud
dn6-smm-red
dls
dls-mon
smux
sre
at-rtmp
at-nbp
at-3
at-echo
at-5
at-zis
at-7
at-8
tarn
z39.50
914c/g
Unisys Audit SITP
OCBinder
OCServer
Remote-KIS
Протокол KIS
Прикладной интерфейс
коммуникации
Plus Five's MUMPS
Queued File Transport
Gateway Access Control Protocol
Prospero
OSU Network Monitoring System
Spider Remote Monitoring Protocol
Internet Relay Chat Protocol
DNSIX Network Level Module Audit
DNSIX Session Mgt Module Audit
Redir
Directory Location Service
Directory Location Service Monitor
SMUX
IBM System Resource Controller
AppleTalk Routing Maintenance
AppleTalk Name Binding
AppleTalk Unused
AppleTalk Echo
AppleTalk Unused
AppleTalk Zone Information
AppleTalk Unused
AppleTalk Unused
Trivial Authenticated Mail Protocol
ANSI Z39.50
Texas Instruments 914C/G Terminal

Список общеизвестных номеров портов TCP и UDP
305
Таблица АЛ. Общеизвестные номера портов TCP и UDP (продолжение)
Десятичное
значение
212/tcp, udp
213/tcp, udp
214/tcp, udp
215/tcp, udp
216/tcp, udp
217/tcp, udp
218/tcp, udp
219/tcp, udp
220/tcp, udp
221/tcp, udp
222/tcp, udp
223/tcp, udp
224-241
243/tcp, udp
245/tcp, udp
246/tcp, udp
247-255
345/tcp, udp
346/tcp, udp
347/tcp, udp
371/tcp, udp
372/tcp, udp
373/tcp, udp
374/tcp, udp
443/tcp
512/tcp
Зарезервированное Описание
слово
anet
ipx
vmpwscs
softpc
atls
dbase
mpp
uarps
imap3
fln-spx
fsh-spx
cdc
sur-meas
link
dsp3270
pawserv
zserv
fatserv
clearcase
ulistserv
legent-1
legent-2
ssl
print
ATEXSSTR
IPX
VM PWSCS
Insignia Solutions
Access Technology License Server
dBASE UNIX
Netix Message Posting Protocol
Unisys ARPs
Interactive Mail Access Protocol v3
Berkeley rloging with SPX Auth
Berkeley rshd with SPX Auth
Certificate Distribution Center
Зарезервировано
Survey Measurement
LINK
Display System Protocol
Зарезервировано
Perf Analysis Workbench
Zebra Server
Fatmen Server
Clearcase
UNIX Listserv
Legent Corporation
Legent Corporation
Secure Sockets Layer, используется
для предоставления защищенной
коммуникации в Интернете
Windows NT Server и Windows NT
Workstation версии 4.0 могут
посылать клиентские задания
печати LPD из любого доступного
зарезервированного порта между
512 и 1023. (См. также описание
портов от 721 до 731.)

306
Приложение А
Таблица АЛ. Общеизвеаные номера портов TCP и UDP (продолжение)
Десятичное Зарезервированное Описание
значение слово
512/udp
513/tcp
513/udp
514/tcp
biff
login
who
cmd
514/udp syslog
515/tcp, udp printer
517/tcp, udp talk
518/tcp, udp ntalk
519/tcp, udp utime
520/tcp efs
Используется почтовой системой
для уведомления пользователей .
о новой полученной почте;
в настоящее время получает : "
сообщения только от процессов на
том же компьютере; алиас = comsat
Удаленный вход в систему, подобно
telnet; выполняется автоматическая
аутентификация на основе номеров
привилегированных портов
и распределенных баз данных,
которые идентифицируют "домены
аутентификации".
Поддерживает базы данных,
показывающие, кто зарегистриро-
зарегистрировался на компьютерах в локальной
сети, и среднюю нагрузку компьютера;
алиас = whod
Подобно exec, но выполняется
автоматическая аутентификация,
как для сервера входа в систему
Спулер; алиас = spooler; (служба
сервера печати LDP будет ожидать
входящие соединения на порте
tcp515)
Подобно линии связи tenex,
но между компьютерами;
к сожалению не использует
протокол линии связи. (Это
в действительности просто порт
рандеву, из которого создается
соединение TCP)
Unixtime
Сервер расширенных имен файлов

Список общеизвестных номеров портов TCP и UDP
307
Таблица А.1. Общеизвестные номера портов TCP и UDP (продолжение)
Десятичное Зарезервированное Описание •-.,>
значение слово
520/udp
router
525/tcp, udp
526/tcp, udp
530/tcp, udp
531/tcp
531/udp
532/tcp, udp
533/tcp, udp
540/tcp, udp
543/tcp, udp
544/tcp, udp
550/tcp, udp
555/tcp, udp
556/tcp, udp
560/tcp, udp
561/tcp, udp
562/tcp, udp
564/tcp, udp
565/tcp, udp
570/tcp, udp
571/tcp, udp
600/tcp, udp
607/tcp, udp
666/tcp, udp
704/tcp, udp
timed
tempo
courier
conference
rvd-control
netnews
netwall
uucp
klogin
kshell
new-rwho
dsf
remotefs
rmonitor
monitor
chshell
9pfs
whoami
meter
meter
ipcserver
nqs
mdqs
elcsd
Локальный процесс маршрутизации
(на сайте); использует вариант
информационного протокола
маршрутизации Xerox NS;
алиас = router routed
Сервер времени
Newdate
RPC
Chat
MIT-disk
Readnews
Для аварийного широковещания
Uucpd
Krcmd; алиас = cmd
New-who
Сервер rfs; алиас = rfs_server rfs
Rmonitord
Chcmd
Служба файлов Plan 9
Whoami
Demon
Udemon
сервер IRC Sun
Nqs
Демон копии/сервера Errlog

308
Приложение А
Таблица АЛ. Общеизвестные номера портов TCP и UDP (продолжение)
Десятичное
значение
Зарезервированное
слово
Описание
721-731
740/tcp, udp
741/tcp, udp
742/tcp, udp
744/tcp, udp
747/tcp, udp
748/tcp, udp
749/tcp, udp
750/tcp
750/udp
751/tcp, udp
752/tcp, udp
753/tcp, udp
758/tcp, udp
759/tcp, udp
760/tcp, udp
762/tcp, udp
763/tcp, udp
764/tcp, udp
765/tcp, udp
767/tcp, udp
769/tcp, udp
printer
netcp
netgw
netrcs
flexlm
fujitsu-dev
ris-cm
kerberos-adm
rfile
loadav
pump
qrh
rrh
754/tcp, udp tell
nlogon
con
ns
quotad
cycleserv
omserv
webster
phonebook
vid
В Windows NT 3.5x все задания
печати TCP/IP, посланные
с компьютера Windows NT,
посылаются из портов TCP с 721
по 731. (Это изменилось для
Windows NT Server и Windows NT
Workstation версии 4.0, которые
посылают задания печати клиента
LPD из любого доступного
резервного порта между 512 и 1023.)
NETscout Control Protocol
NetGW
Network based Rev. Cont. Sys.
Flexible License Manager
Fujitsu Device Control
Russell Info Sci Calendar Manager
Администрация Kerberos
Аутентификация Kerberos;
алиас = kdc
Аутентификация Kerberos
Сервер паролей Kerberos
Сервер регистрации пользователей
Kerberos
Послать; подчиненное
распространение Kerberos
761/tcp, udprxe
Phone

Список общеизвестных номеров портов TCP и UDP
309
Таблица АЛ. Общеизвестные номера портов TCP и UDP (продолжение)
Десятичное
значение
Зарезервированное Описание
слово
770/tcp, udp
771/tcp, udp
772/tcp, udp
773/tcp
773/udp
774/tcp
774/udp
775/tcp
775/udp
776/tcp, udp
780/tcp, udp
781 /tcp, udp
782/tcp, udp
783/tcp, udp
800/tcp, udp
801/tcp, udp
888/tcp, udp
996/tcp, udp
997/tcp, udp
998/tcp
998/udp
999/tcp
999/udp
999/tcp, udp
1000/tcp
1000/udp
cadlock
rtip
cycleserv2
submit
notify
rpasswd
acmaint_dbd
entomb
acmaint_transd
wpages
wpgs
hp-collector
hp-managed-node
hp-alarm-mgr
mdbs_daemon
device
erlogin
xtreelic
maitrd
busboy
puparp
garcon
applix
puprouter
cadlock
ock
¦'!-.- V > .¦•¦...-'"
Сборщик данных
производительности HP
Узел, управляемый данными
производительности HP
менеджер сигналов данных
производительности HP
Вход в систему и передача
параметров среды
XTREE License Server
Applix ас

ПриложёниёВ
(U . » ;А -,.. i¦¦¦¦'¦•-.
Утилиты командной строки
¦'¦( !.l
Таблица B.I. Полезные утилиты командной строки
Утилита Модификаторы
Описание
ping
ARP
Nbstat
-a
«¦¦¦»<..."t>r
-a . . ;
-а удаленное_имя
-А удаленный_1Р-адрес
-с
-n
-R ' ' " '¦' '' '' "
"Г .. .¦¦'¦.¦'¦."..¦"Л ¦ !
-s
Netstat -а
Используется для тестирования соедине-
соединения между двумя 1Р-хостами.
Используется для просмотра на компьюте-
компьютере кэша ARP.
Выводит удаленную таблицу имен NetBIOS.
Выводит локальный кэш имен NetBIOS.
Выводит локальные имена NetBIOS.
Перезагружает файл LMHosts.
Выводит статистику преобразования имен.
Выводит сеансы клиента и сервера,
перечисляя удаленные компьютеры
только по IP-адресам. : •>
Пытается преобразовать IP-адрес
удаленного компьютера в имя, используя
файл HOSTS.
Выводит все соединения и принимающие
порты.
Выводит статистику Ethernet.
Выводит статистику по протоколам.
Выводит содержимое таблицы
маршрутизации.

Утилиты командной строки
311
Таблица В.1. Полезные утилиты командной строки (продолжение)
Утилита Модификаторы Описание
telnet IP-адрес
Используется для создания удаленного
сеанса на другом хосте. Используется для
поиска неисправностей.
FTP
Nslookup
At
Rcmd
Netsvc
Ipconfig
IP-адрес
IP-адрес сервера DNS
и получающего хоста
Время и команда
Имя сервера
/query/list/start/stop
/all | more
/release
/renew
Используется для пересылки файлов
в Интернет.
Используется для проверки разрешения
DNS.
Используется для планирования запуска
программы в определенное время.
Используется для выполнения удаленной
команды на хосте.
Используется для удаленной остановки,
запуска, перечисления и запроса статуса
определенной службы на определенном
сервере.
Используется для вывода IP конфигурации
о локальном хосте.
Освобождает IP-адрес.
Обновляет IP-адрес.

Приложение С
Общие NCP
Таблица С.1. Общее распределение NCP
Тип
Поле
Значение
NCP соединения
NCP соединения
NCP соединения
NCP соединения
NCP соединения
NCP соединения
NCP соединения
NCP соединения
NCP соединения
NCP соединения
NCP соединения
NCP соединения
NCP соединения
NCP соединения
NCP соединения
0x2222 23 29
0x2222 23 254
0x1111
0x5555
0x2222 24
0x2222 97
0x2222 23 31
0x2222 23 26
0x2222 23 19
0x2222 23 23
0x2222 23 27
0x2222 23 21
0x2222 19
0x2222 23 28
0x2222 23 22
Изменить состояние соединения
Очистить номер соединения
Создать служебное соединение
Разрушить служебное соединение
Конец задания
Получить размер максимального
пакета большого пакета NCP
Получить список соединений
от объекта
Получить адрес IP
Получить адрес IP (старый)
Получить ключ регистрации
Получить список соединений
объекта
Получить список соединений
объекта (старый)
Получить номер станции
Получить информацию
о зарегистрированной станции
Получить информацию
о зарегистрированной станции
(старую)

Общие NCP
313
Таблица C.I. Общее распределение NCP
Тип
NCP соединения
NCP соединения
NCP соединения
NCP соединения
NCP соединения
NCP соединения
NCP соединения
NCP соединения
NCP соединения
NCP соединения
NCP соединения
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
Поле
0x2222 23 05
0x2222 23 02
0x2222 23 24
0x2222 23 20
0x2222 23 00
0x2222 25
0x2222 33
0x2222 101
0x9999
0x3333
0x2222 23 30
0x2222 22 39
0x2222 87 10
0x2222 22 13
0x2222 22 33
0x2222 22 18
0x2222 22 22
0x2222 22 19
0x2222 87 12
0x2222 66
0x2222 59
0x2222 23 244
0x2222 74
(продолжение)
Значение
Получить информацию
о зарегистрированной станции
(старую)
Получить список соединений
пользователя (старый)
Регистрация объекта с ключом
Объект регистрации
Пользователь регистрации (старый)
Выход из системы
Согласовать размер буфера
Пакет запроса соединения пакетной
передачи (burst connection)
Обрабатываемый запрос
Обработанный запрос
Задать интервал задержки
сторожевой схемы
Добавить расширенное доверительное
множество к файлу или каталогу
Добавить доверительное множество
к файлу или подкаталогу
Добавить доверительное множество
к каталогу
Добавить ограничение дискового
пространства пользователя
Выделить дескриптор постоянного
каталога
Выделить специальный дескриптор
временного каталога
Выделить дескриптор временного
каталога
Выделить короткий дескриптор
каталога
Закрыть файл
Зафиксировать файл
Преобразовать путь доступа в запись
каталога
Копировать из одного (Ьайла в лттой

314
Приложение С
Таблица С.1. Общее распределение NCP (продолжение)
Тип
Поле
Значение
NCP файловой системы 0x2222 22 10
NCP файловой системы 0x2222 67
NCP файловой системы 0x2222 77
NCP файловой системы 0x2222 22 20
NCP файловой системы 0x2222 87 08
NCP файловой системы 0x2222 22 11
NCP файловой системы 0x2222 22 14
NCP файловой системы 0x2222 87 11
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
0x2222 68
0x2222 22 23
0x2222 90 150
0x2222 63
0x2222 62
0x2222 87 22
0x2222 71
0x2222 22 35
NCP файловой системы 0x2222 22 31
NCP файловой системы 0x2222 22 45
NCP файловой системы 0x2222 22 01
NCP файловой системы 0x2222 22 03
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
0x2222 87 29
0x2222 22 42
0x2222 22 51
0x2222 87 31
0x2222 87 28
NCP файловой системы 0x2222 87 26
Создать каталог
Создать файл
Создать новый файл
Удалить дескриптор каталога
Удалить файл или подкаталог
Удалить каталог .:
Удалить доверительное множество
из каталога
Удалить доверительное множество
из файла или подкаталога
Стереть файл
Извлечь базовый дескриптор
Запрос миграции файла ,
Продолжить поиск файла
Инициализировать поиск файла
Создать базу каталога и номер тома
Получить текущий размер файла
Получить ограничения дискового
пространства каталога
Получить запись каталога
Получить информацию о каталоге
Получить путь доступа каталога
Получить действующие права
каталога
Получить действующие права
каталога
Получить действующие права
записи каталога
Получить расширенную
информацию о томе
Получить информацию о файле
Получить строку полного пути
доступа
Получить информацию о Huge NS

Общие NCP
Таблица C.I.
Тип
Общее распределение
Поле
NCP (продолжение)
Значение
315
NCP файловой системы 0x2222 22 52
NCP файловой системы 0x2222 22 48
NCP файловой системы 0x2222 22 47
NCP файловой системы 0x2222 87 24
NCP файловой системы 0x2222 87 19
NCP файловой системы 0x2222 22 41
NCP файловой системы 0x2222 22 50
NCP файловой системы 0x2222 22 26
NCP файловой системы 0x2222 87 21
NCP файловой системы 0x2222 90 10
NCP файловой системы 0x2222 90 11
NCP файловой системы 0x2222 85
NCP файловой системы 0x2222 22 44
NCP файловой системы 0x2222 22 21
NCP файловой системы 0x2222 18
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
0x2222 22 06
0x2222 22 05
0x2222 87 02
0x2222 23 243
NCP файловой системы 0x2222 87 35
Получить список смонтированных
томов
Получить запись каталога
пространства имен
Получить информацию
о пространстве имен
Получить список загруженных
пространств имен по номеру тома
Получить информацию о NS
Получить используемое дисковое
пространство и ограничения объекта
Получить действующие права объекта
для записи каталога
Получить имя пути доступа пары
номеров том-каталог
Получить строку пути доступа
из короткого дескриптора каталога
Получить счетчик ссылок из номера
записи каталога
Получить счетчик ссылок
из дескриптора каталога
Получить битовое отображение
блоков данных фрагментированного
файла
Получить информацию о томе
и удалении
Получить информацию о томе
с дескриптором
Получить информацию о томе
с номером
Получить имя тома
Получить номер тома
Инициализировать поиск
Отобразить номер каталога в путь
доступа
Изменить атрибуты DOS файла
или подкаталога

316
Таблица
Тип
С.1.
Общее
распределение
Поле
NCP
(продолжение)
Значение
Приложение С
NCP файловой системы 0x2222 87 07
NCP файловой системы 0x2222 22 04
NCP файловой системы 0x2222 87 06
NCP файловой системы 0x2222 87 34
NCP файловой системы 0x2222 84
NCP файловой системы 0x2222 87 01
NCP файловой системы 0x2222 87 30
NCP файловой системы 0x2222 87 32
NCP файловой системы 0x2222 87 33
NCP файловой системы 0x2222 22 49
NCP файловой системы 0x2222 65
NCP файловой системы 0x2222 76
NCP файловой системы 0x2222 90 00
NCP файловой системы 0x2222 22 16
NCP файловой системы 0x2222 87 18
NCP файловой системы 0x2222 22 29
NCP файловой системы 0x2222 87 23
NCP файловой системы 0x2222 72
NCP файловой системы 0x2222 22 17
NCP файловой системы 0x2222 87 17
NCP файловой системы 0x2222 22 28
NCP файловой системы 0x2222 22 43
NCP файловой системы 0x2222 22 34
Изменить информацию DOS
о файле или каталоге
Изменить маску максимальных прав
Получить информацию о файле
или каталоге
Открыть элемент управления
CallBack (обратного вызова)
Открыть/создать файл (старый)
Открыть/создать файл
или подкаталог
Открыть/создать файл
или подкаталог
Открыть/создать файл
или подкаталог с помощью CallBack
Открыть/создать файл или
подкаталог II с помощью CallBack
Открыть поток данных
Открыть файл (старый)
Открыть файл (старый)
Выполнить синтаксический разбор
дерева
Удалить стертые файлы (старый)
Удалить утилизируемый файл
Удалить утилизируемый файл
(старый)
Запросить формат информации NS
Прочитать из файла
Восстановить стертый файл
(старый)
Восстановить утилизируемый файл
Восстановить утилизируемый файл
(старый)
Удалить расширенное доверительное
множество из каталога или файла
Удалить ограничение дискового
пространства пользователя

Общие NCP
317
Таблица C.I. Общее распределение NCP (продолжение)
Тип
Поле
Значение
NCP файловой системы 0x2222 22 15
NCP файловой системы 0x2222 69
NCP файловой системы 0x2222 22 46
NCP файловой системы 0x2222 87 04
NCP файловой системы 0x2222 22 24
NCP файловой системы 0x2222 22 30
NCP файловой системы 0x2222 22 40
NCP файловой системы 0x2222 22 12
NCP файловой системы 0x2222 22 02
NCP файловой системы 0x2222 23 15
NCP файловой системы 0x2222 22 38
NCP файловой системы 0x2222 87 05
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
0x2222 87 16
0x2222 22 27
0x2222 22 32
0x2222 64
0x2222 87 03
0x2222 87 20
0x2222 90 12
0x2222 22 36
Переименовать каталог
Переименовать файл
Переименовать или переместить
(старый)
Переименовать или переместить
файл или подкаталог
Восстановить извлеченный базовый
дескриптор
Просканировать каталог
Просканировать дисковое
пространство каталога '
Просканировать каталог
для выявления доверительного
множества
Просканировать информацию
о каталоге
Просканировать информацию
о файле
Просканировать файл или каталог
для выявления расширенного
доверительного множества
Просканировать файл или каталог
для выявления доверительного
множества
Просканировать утилизируемые
файлы
Просканировать утилизируемые
файлы (старый)
Просканировать ограничения тома
диска пользователя.
Искать файл
Искать файл или каталог
Искать множество файлов
или подкаталогов
Задать размер сжатого файла
Задать ограничение дискового
пространства каталога

318
Приложение С
Таблица С.1. Общее распределение NCP (продолжение)
Тип
Поле
Значение
NCP файловой системы 0x2222 22 37
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
NCP файловой системы
0x2222 22 00
0x2222 22 25
0x2222 70
0x2222 79
0x2222 23 16
0x2222 75
NCP файловой системы 0x2222 87 27
NCP файловой системы 0x2222 87 25
NCP файловой системы 0x2222 87 09
NCP файловой системы
NCP печати
NCP печати
NCP печати
NCP печати
NCP печати ;:.. •
NCP печати
NCP печати ; :
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
0x2222 73
0x2222 17 01
0x2222 17 09
0x2222 17 06
0x2222 1710
0x2222 17 02
0x2222 17 03
0x2222 17 00
0x2222 23 132
0x2222 23 115
0x2222 23 111
0x2222 23 130
0x2222 23123
0x2222 23 109
0x2222 23 110
Задать информацию о записи
каталога
Задать дескриптор каталога
Задать информацию о каталоге
Задать атрибуты файла . . ., < /
Задать расширенный атрибут файла
Задать информацию о файле
Задать для файла отметку времени
и даты
Задать информацию Huge NS >¦
Задать информацию NS
Задать короткий дескриптор
каталога
Записать в файл .,...,
Закрыть файл спулинга
Создать файл спулинга , , :/,
Получить статус принтера
Получить очередь принтера '
Задать флаги файла спулера
Загрузить в спулер дисковый файл
Записать в файл спулера
Прервать обслуживание задания
очереди ¦ '''
Прервать обслуживания задания
очереди (старый)
Присоединить сервер очереди
к очереди : !/
Изменить приоритет задания
Изменить запись задания очереди
Изменить запись задания очереди
(старый)
Изменить позицию задания очереди

Общие NCP
319
Таблица C.I. Общее распределение NCP (продолжение)
Тип
Поле
Значение
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
0x2222 23 133 Изменить на права клиента , .
0x2222 23 116 Изменить на права клиента (старый)
0x2222 23 127 Закрыть файл и запустить задание
очереди
0x2222 23 105 Закрыть файл и запустить задание
очереди (старый)
0x2222 23 100 Создать очередь
0x2222 23 121 Создать задание очереди и файл
0x2222 23 104 Создать задание очереди и файл
(старый)
0x2222 23 101 Разрушить очередь
0x2222 23 112 Отсоединить сервер очереди
от очереди
0x2222 23 131 Закончить обслуживание задания
очереди
0x2222 23 114 Закончить обслуживание задания
очереди (старый)
0x2222 23 135 Получить размер файла задания
печати
0x2222 23 120 Получить размер файла задания
печати (старый)
0x2222 23 129 Получить список заданий печати
0x2222 23 107 Получить список заданий печати
(старый)
0x2222 23 137 Получить задания печати из списка
форм
0x2222 23 136 Переместить задание очереди
из источника Q в место назначения Q,
0x2222 23 125 Прочитать текущий статус очереди
0x2222 23 102 Прочитать текущий статус очереди
(старый)

320
Таблица С.1. Общее
Тип
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCP управления
очередью
NCPRPC
NCP RPC
NCPRPC
NCP RPC
NCPRPC
NCP RPC
NCP RPC
распределение NCP
Поле
0x2222 23 122
0x2222 23 108
0x2222 23 134
0x2222 23 118
0x2222 23 128
0x2222 23 106
0x2222 23117
0x2222 23 124
0x2222 23113
0x2222 23138
0x2222 23 126
0x2222 23 103
0x2222 23 119
0x2222 131 05
0x2222 131 04
0x2222 131 07
0x2222131 01
0x2222 131 03
0x2222 131 06
0x2222 131 02
Приложение С
(продолжение)
Значение
Прочитать запись задания очереди
Прочитать запись задания очереди
(старый)
Прочитать текущий статус сервера
очередей
Прочитать текущий статус сервера
очередей (старый)
Удалить задание из очереди
Удалить задание из очереди ¦
(старый)
Восстановить права сервера
очередей
Обслужить задание печати
Обслужить задание печати (старый)
Обслужить задание печати списком
форм
Задать текущий статус очереди
Задать текущее состояние очереди
(старый)
Задать текущее состояние сервера
очередей
RPC "добавить пространство имен
к тому"
RPC "размонтировать том"
RPC "выполнить файл NCF"
RPC "загрузить NLM"
RPC "смонтировать том"
RPC "задать значение команды"
RPC "Выгрузить NLM"

Приложение D
Поиск обычных
сетевых ошибок
В этом приложении рассматриваются некоторые из наиболее распростра-
распространенных ошибок и предлагаются методы их решения.
Короткие/длинные кадры
Короткими называют кадры, которые были преждевременно завершены.
Они обычно возникают, когда сквозной коммутатор пересылает кадры, ко-
которые столкнулись с конфликтами в сегменте источнике. Длинный кадр
возникает, когда конец одного кадра и начало другого не четко определе-
определены. Это может происходить, когда диаметр коллизионного домена превы-
превышает спецификацию.
Ошибки CRC или FCS
Любое искажение кадра может приводить к ошибке контроля циклическо-
циклического избыточного кода — CRC (называемой также ошибкой контрольной
последовательности кадра). Передающий NIC выполняет вычисление на
заголовке кадра и поле данных. Результат вычисления хранится в четырех
байтах после поля данных. Когда кадр достигает места назначения, вы-
выполняются те же самые вычисления и результат сравнивается с четы-
рехбайтным полем. Несовпадение называется ошибкой CRC или FCS. Иска-
Искажение может быть результатом плохо соединенных разъемов или кабелей,
использования кабеля cat 3 для 100 Мбит/сек Ethernet, источников электро-
электромагнитного шума, например трансформаторов и электромоторов, располо-
расположенных возле кабеля UTP, исходящих кабелей, превышающих 100 метров,
и множества других причин.

322 Приложение D
Конфликты
Конфликты вызываются наложением передач, в связи с двумя или большим
числом NIC, посылающих пакеты одновременно. Конфликты могут про-
происходить, если различные NIC решают передавать почти одновременно,
так как ничего не слышат в сети в данный момент. Все пакеты, вовлеченные
в конфликт, потеряны и автоматически передаются повторно.
Поздние конфликты yg.^-ы-* -, v-.•-.,,¦*¦ r%Jt
Обнаружение конфликта после того, как были переданы первые 64 байта
пакета. NIC, определяющий поздний конфликт, проходит через обычные
помехи CSMA/CD, ожидание и повтор, но также увеличивает счетчик
поздних конфликтов. Опасность состоит в том, что пакеты, близкие по
длине к 64 байтам, могут быть переданы до обнаружения конфликта и не
передаваться NIC повторно. Это заставляет компьютер ожидать, пока другой
конец не ответит должным образом, и затем повторить. Это может потре-
потребовать нескольких секунд или даже вызвать закрытие соединения. Причи-
Причиной поздних конфликтов является сеть, которая превышает ограничения
синхронизации стандарта IEEE 802.3.

Приложение Е
Суффиксы NetBIOS
Таблица ЕЛ. Суффиксы NetBIOS
Название
<имя компьютера>
<имя компьютера>
<\\-_MSBROWSE_>
<имя компьютера>
<имя компьютера>
<имя компьютера>
<имя компьютера>
<имя компьютера>
<имя компьютера>
<имя компьютера>
<имя компьютера>
<имя компьютера>
<имя компьютера>
<имя компьютера>
<имя компьютера>
<имя компьютера>
Номер(Ьех)
0
1
1
3
6
IF
20
21
22
23
24
30
31
43
44
45
Тип
и
и
G
и
и
и
и
и
и
и
и
и
и
и
и
и
Применение
Служба рабочей станции
Служба рассылки
Мастер-броузер
Служба рассылки
Служба сервера RAS
Служба NetDDE
Служба сервера файлов
Служба клиента RAS
Microsoft Exchange Interchange
(MSMail Connector)
Microsoft Exchange Store
Microsoft Echange Directory
Служба сервера общего
использования модема
Служба клиента общего
использования модема
Удаленное управление
клиентами SMS
удаленные администраторы SMS
Удаленный чат клиентов SMS

324
Приложение Е
Таблица ЕЛ. Суффиксы NetBIOS (продолжение)
Название
<имя компьютера>
<имя компьютера>
<имя компьютера>
<имя компьютера>
<имя компьютера>
<имя компьютера>
<имя компьютера>
<имя пользователя>
<домен>
<домен>
<домен>
<домен>
<домен>
<службы — INet>
<IS — имя компьютера>
<имя-компьютера>
IRISMULTICAST
IRISNAMESERVER
Forte_$ND800ZA
Номер(Ьех)
46
4С
52
87
6А
BE
BF
3
0
IB
1С
ID
IE
1С
0
[2B]
[2F]
[33]
[20]
Тип
и
и
и
и
и
и
и
и
G
и
G
и
G
G
и
и
G
G
и
Применение
Удаленная передача
клиентов SMS
Служба TCPIP Pathworks DEC
на Windows NT
Служба TCPIP Pathworks DEC
на Windows NT
Microsoft Exchange MTA
Microsoft Exchange IMC
Агент сетевого монитора
Приложение сетевого
монитора
Служба рассылки
Имя домена
Мастер-броузер домена
Контроллеры домена
мастер-броузер
Выборы службы броузера
IIS
IIS
Служба сервера Lotus Notes
Lotus Notes
Lotus Notes
Служба сервера Gateway DCA
IrmaLan

Приложение F
Запуск контроллера домена
Таблица F.I. Запуск контроллера домена
Кадр Время Адрес MAC Адрес MAC Протокол Описание
источника назначения
67.409 2400
67.467 Ргох
67.468 2400
4 67.823 2400
5 68.823 2400
6 71.283 Ргох
7 72.727 2400
¦BROADCAST DHCP
¦BROADCAST DHCP
¦BROADCAST ARP RARP
¦BROADCAST ARP RARP
¦BROADCAST ARP RARP
¦BROADCAST BROWSER
¦BROADCAST ARP RARP
Запрос
(xid=2BlD7FEF)
ACK
(xid=2BlD7FEF)
ARP: Запрос,
IP получения:
10.0.0.60
ARP: Запрос,
IP получения:
10.0.0.60
ARP: Запрос,
IP получения:
10.0.0.60
Объявление
рабочей группы
[0х0с] MRED
ARP: Запрос,
IP получения:
10.0.0.10

326
Приложение F
Таблица F.I. Запуск контроллера домена (продолжение)
Кадр Время Адрес MAC Адрес MAC Протокол Описание
источника назначения ¦
8 72.728 Ргох
2400
ARP_RARP
9 72.728 2400
10 74.214 2400
11 75.714 2400
12 77.246 2400
13 77.996 2400
14 78.746 2400
15 79.496 2400
16 84.313 Ргох
17 87.283 2400
18 88.028 2400
19 88.778 2400
20 89.528 2400
Ргох
Ргох
Ргох
NBT
NBT
NBT
¦BROADCAST NBT
¦BROADCAST NBT
¦BROADCAST NBT
¦BROADCAST NBT
¦NETBIOS Mu- BROWSER
licast
¦BROADCAST NBT
¦BROADCAST NBT
¦BROADCAST NBT
¦BROADCAST NBT
ARP: Ответ,
IP получения:
10.0.0.60,
аппаратный
адрес получения
00902764FEBF
NS: Запрос
регистрации
2400 <00>
NS: Запрос
регистрации
2400 <00>
NS: Запрос
регистрации ; '
2400 <00>
NS: Запрос
регистрации
2400 <00> >
NS: Запрос
регистрации
2400 <00>
NS: Запрос
регистрации
2400 <00>
NS: Запрос
регистрации
2400 <00>
Объявление
MRED [ОхОс]
рабочей группы
NS: Запрос
регистрации 2400
NS: Запрос
регистрации 2400
NS: Запрос
регистрации 2400
NS: Запрос
регистрации 2400

Запуск контроллера домена
327
Таблица F.I. Запуск контроллера домена (продолжение)
Кадр Время Адрес MAC Адрес MAC Протокол Описание
источника назначения
21 90.284 2400
22 90.308 2400
23 91.044 2400
24 91.794 2400
25 92.544 2400
26 93.295 2400
27 94.044 2400
28 94.794 2400
29 95.544 2400
30 96.297 2400
31 96.462 2400
32 96.462 Ргох
33 96.462 2400
34 96.463 Ргох
¦BROADCAST BROWSER
¦BROADCAST NBT
¦BROADCAST NBT
¦BROADCAST NBT
¦BROADCAST NBT
¦BROADCAST NBT
¦BROADCAST NBT
¦BROADCAST NBT
¦BROADCAST NBT
¦BROADCAST BROWSER
¦BROADCAST NBT
2400
Prox
2400
NBT
NETLOGON
NETLOGON
Объявление
хоста [0x01] 2400
NS: Запрос
регистрации
MRED <00>
NS: Запрос
регистрации
MRED <00>
NS: Запрос
регистрации
MRED <00>
NS: Запрос
регистрации
MRED <00>
NS: Запрос
регистрации
MRED <1C>
NS: Запрос
регистрации
MRED<1C>
NS: Запрос
регистрации
MRED <1C>
NS: Запрос
регистрации
MRED <1C>
Объявление
хоста 2400 [0x01]
NS: Запрос
MRED <1B>
NS: Запрос
(статуса узла)
главным образом
MRED <1B>, успех
Запрос
первичного DC
Ответ
на первичный

328
Приложение F
Таблица F.I. Запуск контроллера домена (продолжение)
Кадр
35
36
37
38
39
40
41
42
43
44
45
Время
96.491
96.491
96.492
96.492
96.492
96.493
96.497
96.508
96.509
96.51
96.513
Адрес MAC
источника
2400
Ргох
2400
2400
Ргох
2400
Ргох
2400
Ргох
2400
Ргох
Адрес MAC
назначения
Ргох
2400
Ргох
Ргох
2400
Ргох
2400
Ргох
2400
Ргох
2400
Протокол
TCP
TCP
TCP
NBT
NBT
SMB
SMB
SMB
SMB
SMB
SMB
Описание
....S., len: 4,
seq: 78400-78403,
ack:0, win: 8192,
src:1025dst: 139
(сеанс NBT)
.A..S., len: 4, seq:
171256-171259,
ack: 78401, win:
8760, src: 139
(сеанс NBT)
.A...., len: 0, seq:
78401-78401, ack:
171257, win: 8760,
src: 1025 dst: 139
(сеанс NBT)
SS: Запрос сеанса,
назначение:
PROX, источник:
2400 <00>, Len: 68
SS: Положительный
ответ на сеанс,
Len:0
С Negotiate,
Dialect = NT LM 0.12
R Negotiate,
Dialect # = 7
С Session Set-up &
X, Username =,
and С Tree Con-
Connect & X, Share =
\\PROX\IPC$
R Session Set-up &
X, and R Tree
Connect & X,
Type = IPC
С NT create &X,
File=\NETLOGON
R NT create &X,
FID = 0x807

Запуск контроллера домена
329
Таблица F.I. Запуск контроллера домена (продолжение)
Кадр Время Адрес MAC Адрес MAC Протокол Описание
источника назначения
46 96.513 2400
Ргох
47 96.518 Ргох
48 96.518 2400
49 96.519 Ргох
50 96.52 2400
51 96.53 Ргох
52 96.531 2400
53 96.532 TERESA
54 96.587 2400
55 96.658 2400
56 96.661 Ргох
2400
Ргох
2400
Ргох
2400
MSRPC с/о RPC Bind:
UUID
12345678-1234-АВ
CD-EF00-0123456
7CFFB call 0x1
assoc grp 0x0 xm
MSRPC с/о RPC Bind Ack:
call 0x1 assoc grp
0xl9D9Bxmit
0x1630 recv 0x1630
RJLOGON RPC Client Call
Logon: NetrServer
ReqChallenge(..)
R_LOGON RPC Server
Response Logon:
NetrServerReq
Challenge^.)
R LOGON
R_LOGON
RPC Client Call
Logon: NetrServer
Authenticate2(..)
RPC Server
Response Logon:
NetrServer
Authenticate2(..)
NS: Query Req.
ForNETMON
¦BROADCAST NBT
¦BROADCAST ARP_RARP ARP: Request,
Target IP:
10.0.0.60
¦BROADCAST BROWSER
Prox
2400
SMB
SMB
Объявление
хоста [0x01] 2400
С NT Create &X,
File =
\NETLOGON
R NT Create &X,
FID = 0x808

330
Приложение F
Таблица F.I. Запуск контроллера домена (продолжение)
Кадр Время Адрес MAC Адрес MAC Протокол Описание
источника назначения
57 96.662 2400
Ргох
MSRPC
58 96.664 Ргох
2400
MSRPC
59 96.667 2400
60 96.67 Ргох
61 96.675 2400
62 96.678 Ргох
63 96.683 2400
64 96.687 Ргох
65 96.782 2400
Ргох
2400
Ргох
2400
Ргох
2400
R_LOGON
R_LOGON
R_LOGON
R LOGON
R LOGON
R LOGON
¦BROADCAST NBT
c/o RPC Bind:
UUID
12345678-1234-AB
CD-EFOO-0123456
7CFFB call 0x0
assoc grp 0xl9D9B
c/o RPC Bind
Ack: Call 0x0
Assoc grp
0xl9D9Bxmit
0x1630 recv
0x1630
RPC Client Call
Logon: NetrData-
baseDeltas(..)
RPC Server
Response Logon:
NetrDatabase
Deltas (..)
RPC Client Call
Logon: Netr
DatabaseDel tas (..)
RPC Server
Response Logon:
NetrDatabase
Delatas(..)
RPC Client Call
Logon: Netr
DatabaseDeltas(..)
RPC Server
Response Logon:
NetrDatabase
Deltas (..)
NS: Запрос
регистрации
MRED <1E>

Запуск контроллера домена
331
Таблица F.I. Запуск контроллера домена (продолжение)
Кадр Время Адрес MAC Адрес MAC Протокол Описание
источника назначения
66 96.81 2400
Ргох
TCP
67 96.91 2400
68 97.372 2400
69 97.374 Ргох
70 97.529 2400
71 97.654 2400
72 98.201 2400
73 98.279 2400
74 98.404 2400
75 98.951 2400
76 99.029 2400
77 99.156 2400
¦BROADCAST NBT
Ргох
2400
NETLOGON
NETLOGON
*BROADCAST NBT
¦BROADCAST NBT
¦BROADCAST NBT
¦BROADCAST NBT
¦BROADCAST NBT
¦BROADCAST NBT
¦BROADCAST NBT
¦BROADCAST NBT
.A...., len: 0, seq:
80511-80511, ack:
172694, win: 7323,
src: 1025 dst: 139
(NB)
NS: Запрос
регистрации
2400 <03>
Запрос
первичного DC
Ответ
на первичный
запрос
NS: Запрос
регистрации
MRED <1Е>
NS: Запрос
регистрации
2400 <03>
NS: Запрос
регистрации
2400++++++++++++
NS: Запрос
регистрации
MRED <1Е>
NS: Запрос
регистрации
2400 <03>
NS: Запрос
регистрации
2400++++++++++++
NS: Запрос
регистрации
MRED <1E>
NS: Запрос
регистрации
2400 <03>

332
Приложение F
Таблица F.I. Запуск контроллера домена (продолжение)
Кадр Время Адрес MAC Адрес MAC Протокол Описание
источника назначения
78 99.701 2400
79 99.785 2400
80
81
99.79
99.79
Ргох
Ргох
82 99.92 2400
83 99.92 Ргох
84 99.92 2400
85 99.92 2400
86 99.92 Ргох
87 99.922 2400
88 99.922 Ргох
¦BROADCAST
¦BROADCAST
¦NETBIOS
Multicast
¦BROADCAST
Ргох
2400
Ргох
Ргох
2400
Ргох
2400
NBT
BROWSER
BROWSER
BROWSER
TCP
TCP
TCP
NBT
NBT
SMB
SMB
NS: Запрос
регистрации
2400++++++++++++
Запрос
объявления
[0x02]
Объявление
локального
мастера [OxOfj
PROX
Объявление
локального
мастера [0x0f]
PROX
....S., len: 4, seq:
81842-81845, ack:
0, win: 8192, src:
1028 dst: 139 (NB)
.A..S., len: 4, seq:
171273-171276,
ack: 81843, win:
8760, src: 139
(сеанс NBT)
.A...., len: 0, seq:
81843-81843, ack:
171274, win: 8760,
src: 1028 dst: 139
(NB)
SS: Запрос сеанса,
Dest: PROX,
Source: 2400 <00>,
Len: 68
SS: Положительный
ответ сеанса,
Len:0
С Negative,
Dialect = NT LM
0.12
R Negative,
Dialect # = 7

Запуск контроллера домена
333
Таблица F.I. Запуск контроллера домена (продолжение)
Кадр Время Адрес MAC Адрес MAC Протокол Описание
источника назначения
89 99.923 2400
Ргох
90 99.923 Ргох
91 99.924 2400
92 99.927 Ргох
93 99.928 2400
94 99.929 Ргох
95 100.094 2400
2400
Ргох
2400
Ргох
2400
Ргох
96 100.123 2400
97 100.123 Ргох
Ргох
2400
98 100.124 2400
Ргох
SMB
SMB
SMB
SMB
SMB
SMB
TCP
TCP
TCP
TCP
С Session Set-up &
X, Username=,
and С tree Con-
Connect & X, Share =
\\PROX\IPC$
R Session Set-up
& X, and R Tree
Connect & X,
Type = IPC
С Transact,
Remote API
R Transact,
Remote API
(ответ на кадр 91)
С transact,
Remote API
R transact,
Remote API
(ответ на кадр 93)
.A...., len: 0, seq:
82509-82509, ack:
171796, win: 8238,
src: 1028 dst: 139
(NB)
....S., len: 4, seq:
82084-82087, ack:
0, win: 8192, src:
1029 dst: 1745
.A..S., len: 4, seq:
171282-171285,
ack: 82085, win:
8760, src: 1745
dst: 1029
.A len: 0, seq:
82085-82085, ack:
171283, win: 8760,
src: 1029 dst: 1745

334
Приложение F
Таблица F.I. Запуск контроллера домена (продолжение)
Кадр Время Адрес MAC Адрес MAC Протокол Описание
источника назначения
99 100.149 2400
100 100.152 Ргох
Ргох
2400
TCP
TCP
101 100.31 2400
102 100.451 2400
103 100.518 2400
104 100.518 Ргох
Ргох
TCP
¦BROADCAST NBT
Ргох
2400
TCP
TCP
105 100.522 Ргох
2400
TCP
106 100.522 2400
107 100.921 2400
108 101.177 2400
109 101.277 Ргох
Ргох
TCP
¦BROADCAST BROWSER
*BROADCAST BROWSER
¦BROADCAST BROWSER
.AP..., len: 1, seq:
82085-82085, ack:
171283, win: 8760,
src: 1029 dst: 1745
AP..., len: 1129,
seq: 171283-172411,
ack: 82086,
win: 8759, src:
1745 dst: 1029
.A...., len: 0, seq:
82086-82086, ack:
172412, win: 7631,
src: 1029 dst: 1745
NS: Запрос
регистрации
2400++++++++++++
.A...F, len: 0, seq:
82086-82086, ack:
172412, win: 7631,
src: 1029 dst: 1745
.A...., 0, seq:
172412-172412.
ack: 82087, win:
8759, src: 1745
dst: 1029
.A...F, len: 0, seq:
172412-172412,
ack: 82087, win:
8759, src: 1745
dst: 1029
.A len: 0, seq:
82087-82087, ack:
172413, win: 7631,
src: 1029 dst: 1745
Объявление
хоста [0x01] 2400
Выборы [0x08]
[Принудительно]
Выборы [0x08]
PROX

Запуск контроллера домена 335
Таблица F.I. Запуск контроллера домена (продолжение)
Кадр Время Адрес MAC Адрес MAC Протокол Описание
источника назначения
ПО 102.278 Prox *BROADCAST BROWSER Выборы [0x08]
PROX
111 103.28 Prox *BROADCAST BROWSER Выборы [0x08]
PROX
112 104.281 Prox *BROADCAST BROWSER Выборы [0x08]
¦ ¦'. ': -^:..O. .Л'? ?:, ;' .-¦ ; . PROX
113 105.288 Prox
¦NETBIOS Multicast
¦BROADCAST
Prox
Prox
Prox
¦BROADCAST
¦BROADCAST
¦BROADCAST
BROWSER
NBT
NBT
NBT
NBT
NBT
NBT
BROWSER
Объявление
локального
мастера [OxOf]
PROX
Объявление
локального
мастера [OxOf]
PROX
NS: Запрос
ED1750
NS: Запрос
ED 1750
NS: Запрос
ED1750
NS: Запрос
ED 1750
NS: Запрос
ED1750
NS: Регистрация
ED <03>
114 105.289 Prox
115 126.562 2400
116 128.047 2400
117 129.547 2400
118 131.063 2400
119 131.813 2400
120 131.841 2400
121 131.842 bigguy *BROADCAST ARP_RARP ARP: Запрос,
IP получателя:
10.0.0.60
122 132.563 2400 ¦BROADCAST NBT NS: Запрос
ED1750
123 134.817 TERESA ¦BROADCAST BROWSER Объявление
локального
мастера [OxOf]
TERESA

Приложение G
i-r-Л
Открытие страницы Web
Таблица G.I. Открытие страницы Web
Кадр Время Источник Место
назначения
Протокол Описание
Л
1 9.525 proxWan 8AA851000101 DNS
2 9.525 proxWan 8AA851000101 DNS
3 9.635 8AA851000101 proxWan DNS
4 9.655 8AA851000101 proxWan DNS
5 9.655 proxWan 8AA851000101 ICMP
0x1: Стандартный
запрос home.
microsoft.com типа
Host Addr на классе
INET addr.
Oxl: Стандартный
запрос home.
microsoft.com типа
Host Addr на классе
INET addr.
Oxl: Стандартный
ответ на запрос
home.microsoft.com
типа Host Addr на
классе INET addr.
Oxl: Стандартный
ответ на запрос
home.microsoft.com
типа Host Addr на
классе INET addr.
Место назначения
недоступно:
206.112.194.65.
См. кадр 4

Открытие страницы Web
337
Таблица G.I. Открытие араницы Web (продолжение)
Кадр Время Источник Место Протокол Описание
назначения
6 9.655 proxWan 8AA851000101 TCP
7 9.826 8АА851000101 proxWan TCP
8 9.826 proxWan 8AA851000101 TCP
9 9.846 proxWan 8AA851000101 HTTP
10 10.136 8AA851000101 proxWan HTTP
11 10.136 8AA851000101 proxWan TCP
12 10.156 proxWan 8AA851000101 TCP
13 10.266 proxWan 8AA851000101 DNS
14 10.266 proxWan 8AA851000101 DNS
....S., len: 4, seq:
241730-241733,
ack: 0, win: 8192,
src: 3488 dst: 80
.A..S., len: 4, seq:
142002582-14200258
5, ack: 241731, win:
8760, src 80 dst: 3488
.A...., len: 0, seq:
241731-241731,
ack: 142002583,
win: 8760, ere: 3488
dst: 80
Запрос GET
(от клиента
через порт 3488)
Ответ(клиенту
через порт 3488)
.A...F, len: 0, seq:
142002909-14200290
9, ack: 242308,
win: 8183, src: 80
dst: 3488
...R.., len: 0, seq:
242308-242308, ack:
142002583, win: 0,
src: 3488 dst: 80
0x1: Стандартный
запрос
www.msn.com типа
Host Addr на классе
INETaddr.
0x1: Стандартный
запрос
www.msn.com типа
Host Addr на классе
INET addr.

338
Приложение G
Таблица G.I. Открытие страницы Web (продолжение)
Кадр Время Источник Место Протокол Описание .-
назначения
0x1: Стандартный
ответ на запрос
www.msn.com типа
Host Addr на классе
INET addr.
15 10.417 8АА851000101 proxWan DNS
16 10.417 proxWan 8AA851000101 TCP
17 10.447 8AA851000101 proxWan DNS
18 10.447 proxWan 8AA851000101 ICMP
19 10.547 8AA851000101 proxWan TCP
20 10.547 proxWan 8AA851000101 TCP
21 10.567 proxWan 8AA851000101 HTTP
22 13.512 proxWan 8AA851000101 HTTP
23 13.932 8AA851000101 proxWan HTTP
24 14.032 8AA851000101 proxWan HTTP
....S., len: 4, seq:
241741-241744,
ack:0, win: 8192,
src: 3491 dst: 80
0x1: Стандартный
ответ на запрос
www.msn.com типа
Host Addr на классе
INET addr.
Место назначения
недоступно:
206.112.194.65.
См. Кадр 17
.A..S., len: 4, seq:
631519114-631519117,
ack: 241742,
win: 8760, src: 80
dst: 3491
.A...., len: 0, seq:
241742-241742,
ack: 631519115,
win: 8760, src: 3491
dst: 80
Запрос GET
(от клиента
через порт 3491)
Запрос GET
(от клиента
через порт 3491)
Ответ (клиенту
через порт 3491)
Ответ (клиенту
через пор г 3491)

Открытие страницы Web
339
Таблица G.I. Открытие страницы Web (продолжение)
Кадр Время Источник Место Протокол Описание
назначения
25 14.052 proxWan
8АА851000101 TCP
26 14.403 8АА851000101 proxWan HTTP
27 14.423 proxWan 8AA851000101 TCP
28 14.513 8AA851000101 proxWan HTTP
29 14.644 8AA851000101 proxWan HTTP
30 14.663 proxWan 8AA851000101 TCP
31 14.844 8AA851000101 proxWan HTTP
32 14.864 proxWan 8AA851000101 TCP
33 14.935 8AA851000101 proxWan HTTP
34 15.114 proxWan 8AA851000101 TCP
35 15.244 8AA851000101 proxWan HTTP
36 15.344 8AA851000101 proxWan HTTP
.A...., len: 0, seq:
242091-242091,
ack: 631522035,
win: 8760, src: 3491
dst: 80
Ответ(клиенту
через порт 3491)
.A...., len: 0, seq:
242091-242091,
ack: 631523495,
win: 8760, src: 3491
dst: 80
Ответ (клиенту
через порт 3491)
Ответ(клиенту
через порт 3491)
.A...., len: 0, seq:
242091-242091,
ack: 631526415,
win: 8760, src: 3491
dst: 80
Ответ (клиенту
через порт 3491)
.A...., len: 0, seq:
242091-242091,
ack: 631527875,
win: 8760, src: 3491
dst: 80
Ответ (клиенту
через порт 3491)
.A...., len: 0, seq:
242091-242091,
ack: 631529335,
win: 8760, src: 3491
dst: 80
Ответ(клиенту
через порт 3491)
Ответ (клиенту
через порт 3491)

340
Приложение G
Таблица G.I. Открытие араницы Web (продолжение)
Кадр Время Источник Место Протокол Описание
назначения
37 15.364 proxWan
8АА851000101 TCP
38 15.456 8АА851000101 proxWan HTTP
39 15.555 8AA851000101 proxWan HTTP
40 15.575 proxWan 8AA851000101 TCP
41 15.705 8AA851000101 proxWan HTTP
42 15.725 proxWan 8AA851000101 TCP
43 15.805 8AA851000101 proxWan HTTP
44 15.896 8AA851000101 proxWan HTTP
45 15.896 proxWan 8AA851000101 TCP
46 16.005 8AA851000101 proxWan HTTP
47 16.106 8AA851000101 proxWan HTTP
48 16.106 proxWan 8AA851000101 TCP
.A...., len: 0, seq:
242091-242091,
ack: 631532255,
win: 8760, src: 3491
dst: 80
Ответ (клиенту
через порт 3491)
Ответ (клиенту
через порт 3491)
A...., len: 0, seq:
242091-242091,
ack: 631535175,
win: 8760, src: 3491
dst: 80
Ответ(клиенту
через порт 3491)
.А len: 0, seq:
242091-242091,
ack: 631536635,
win: 8760, src: 3491
dst: 80
Ответ (клиенту
через порт 3491)
Ответ (клиенту
через порт 3491)
.A...., len: 0, seq:
242091-242091,
ack: 631539555,
win: 5840, src: 3491
dst: 80
Ответ (клиенту
через порт 3491)
Ответ (клиенту
через порт 3491)
.A...., len: 0, seq:
242091-242091,
ack: 631542475,
win: 2920, src: 3491
dst: 80

Открытие страницы Web
341
Таблица G.I. Открытие страницы Web (продолжение)
Кадр Время Источник Место Протокол Описание
назначения
49 16.186 proxWan
8АА851000101 TCP
50 16.216 8АА851000101 proxWan HTTP
51 16.346 8AA851000101 proxWan HTTP
52 16.346 proxWan 8AA851000101 DNS
53 16.346 proxWan
54 16.366 proxWan
8AA851000101 DNS
8AA851000101 TCP
55 16.516 8AA851000101 proxWan HTTP
56 16.536 proxWan 8AA851000101 TCP
57 16.698 8AA851000101 proxWan HTTP
58 16.797 8AA851000101 proxWan HTTP
59 16.797 proxWan 8AA851000101 TCP
60 16.897 8AA851000101 proxWan
HTTP
.A...., len: 0, seq:
242091-242091,
ack: 631542475,
win: 8760, src: 3491
dst:80 , ,
Ответ (клиенту
через порт 3491)
Ответ (клиенту
через порт 3491)
0x2: Стандартный
запрос msimg.com
типа Host Addr на
классе INET addr.
0x2: Стандартный
запрос msimg.com
типа Host Addr на
классе INET addr.
.A...., len: 0, seq:
242091-242091,
ack: 631545395,
win: 8760, src: 3491
dst: 80
Ответ (клиенту
через порт 3491)
.А len: 0, seq:
242091-242091,
ack: 631546855,
win: 8760, src: 3491
dst: 80
Ответ (клиенту
через порт 3491)
Ответ (клиенту
через порт 3491)
.A...., len: 0, seq:
242091-242091,
ack: 631549775,
win: 8760, src: 3491
dst: 80
Ответ (клиенту
через порт 3491)

342
Приложение G
Таблица G.I. Открытие страницы Web (продолжение)
Кадр Время Источник Место Протокол Описание
назначения
61 16.897 8АА851000101 proxWan DNS
62 16.897 proxWan 8AA851000101 TCP
63 16.897 proxWan 8AA851000101 TCP
64 16.917 8AA851000101 proxWan DNS
65 16.917 proxWan 8AA851000101 ICMP
66 17.067 8AA851000101 proxWan HTTP
67 17.207 8AA851000101 proxWan HTTP
68 17.207 proxWan 8AA851000101 TCP
69 17.247 8AA851000101 proxWan HTTP
70 17.247 8AA851000101 proxWan TCP
0x2: Стандартный
запрос msimg.com
типа Host Addr на
классе INET addr.
A len: 0, seq:
242091-242091,
ack: 631551235,
win: 8760, src: 3491
dst: 80
....S., len: 4, seq:
241751-241754,
ack: 0, win: 8192,
src: 3494 dst: 80
0x2: Стандартный
запрос msimg.com
типа Host Addr на
классе INET addr.
Место назначения
недоступно:
206.112.194.65.
См. Кадр 64
Ответ(клиенту
через порт 3491)
Ответ (клиенту
через порт 3491)
А len: 0, seq:
242091-242091,
ack: 631554155,
win: 8760, src: 3491
dst: 80
Ответ(клиенту
через порт 3491)
A..S., len: 4, seq:
550165240-55016524
3, ack: 241752,
win: 8760, src: 80
dst: 3494

Открытие страницы Web
343
Таблица G.I. Открытие араницы Web (продолжение)
Кадр Время Источник Место Протокол
назначения
Описание
71 17.247 proxWan 8AA851000101 TCP
72 17.267 proxWan 8AA851000101 HTTP
73 17.418 proxWan 8AA851000101 TCP
74 17.498 8AA851000101 proxWan HTTP
75 17.618 proxWan 8AA851000101 TCP
76 18.229 proxWan 8AA851000101 HTTP
77 18.319 proxWan 8AA851000101 TCP
78 18.449 8AA851000101 proxWan HTTP
79 18.449 8AA851000101 proxWan TCP
80 18.449 proxWan 8AA851000101 TCP
.A...., len: 0, seq:
241752-241752,
ack: 550165241,
win: 8760, src: 3494
dst. 80
Запрос GET
(от клиента
через порт 3494)
.A...., len: 0, seq:
242091-242091,
ack: 631554686,
win: 8229, src: 3491
dst: 80
Ответ (клиенту
через порт 3494)
.A...., len: 0, seq:
242091-242091.
ack: 550165457,
win: 8544, src: 3494
dst: 80
Запрос GET
(от клиента
через порт 3494)
....S., len: 4, seq:
241766-241769,
ack: 0, win: 8192,
src: 3495 dst: 80
Ответ (клиенту
через порт 3494)
.A..S., len: 4, seq:
1485616298-1485616
301, ack: 241767,
win: 8760, src 80
dst: 349
.A len: 0, seq:
241767-241767,
ack: 1485616299,
win: 8760, ere: 3495
dst: 80

344
Приложение G
Таблица G.I. Открытие страницы Web (продолжение)
Кадр Время Источник Место Протокол Описание
назначения
81 18.479 proxWan 8AA851000101 HTTP
82 18.62 proxWan 8AA851000101 TCP
83 18.73 8AA851000101 proxWan HTTP
84 18.92 proxWan 8AA851000101 TCP
85 19.14 proxWan 8AA851000101 HTTP
86 19.141 proxWan 8AA851000101 HTTP
87 19.381 8AA851000101 proxWan HTTP
88 19.381 proxWan 8AA851000101 HTTP
89 19.381 8AA851000101 proxWan HTTP
90 19.401 proxWan 8AA851000101 HTTP
91 19.691 proxWan 8AA851000101 HTTP
92 1Э.761 8AA851000101 proxWan HTTP
Запрос GET
(от клиента
через порт 3495)
.A...., len: 0, seq:
242427-242427,
ack: 550165671,
win: 8330, ere: 3494
dst: 80
Ответ (клиенту
через порт 3495)
.A...., len: 0, seq:
242103-242103,
ack: 1485616512,
win: 8547, ere: 3495
dst: 80
Запрос GET
(от клиента через
порт 3494)
Запрос GET
(от клиента
через порт 3495)
Ответ (клиенту
через порт 3494)
Запрос GET и
(от клиента
через порт 3494)
Ответ (клиенту
через порт 3495)
Запрос GET
(от клиента
через порт 3495)
Запрос GET
(от клиента
через порт 3491)
Ответ (клиенту
через порт 3494)

Открытие страницы Web
345
Таблица G.I. Открытие страницы Web (продолжение)
Кадр Время Источник Место Протокол Описание
назначения
93 19.821 proxWan 8AA851000101 DNS
94 19.822 proxWan 8AA851000101 DNS
95 19.852 8AA851000101 proxWan HTTP
96 19.872 proxWan 8AA851000101 TCP
97 19.872 8AA851000101 proxWan HTTP
98 19.942 proxWan 8AA851000101 HTTP
99 19.942 8AA851000101 proxWan DNS
100 19.962 proxWan 8AA851000101 TCP
101 19.962 8AA851000101 proxWan DNS
102 19.962 proxWan 8AA851000101 ICMP
103 20.023 8AA851000101 proxWan HTTP
0x3: Стандартный
запрос go.msn.com
типа Host Addr на
классе INET addr.
0x3: Стандартный
запрос go.msn.com
типа Host Addr на
классе INET addr.
Ответ (клиенту
через порт 3494)
.А...., 1еп: 0, seq:
243029-243029,
ack: 550167891,
win: 8760, src: 3494
dst: 80
Ответ (клиенту
через порт 3495)
Запрос GET
(от клиента
через порт 3495)
0x3: Стандартный
ответ на запрос
go.msn.com типа
Host Addr на классе
INET addr.
....S., len: 4, seq:
241781-241784,
ack: 0, win: 8192,
src: 3498 dst: 80
0x3: Стандартный
ответ на запрос
go.msn.com типа
Host Addr на классе
INET addr.
Место назначения
недоступно:
206.112.194.65.
См. кадр 101
Ответ (клиенту
через порт 3491)

346
Приложение G
Таблица G.I. Открытие страницы Web (продолжение)
Кадр Время Источник Место Протокол Описание
назначения
104 20.222 proxWan 8AA851000101 TCP
105 20.222 8АА851000101 proxWan HTTP
106 20.222 8АА851000101 proxWan TCP
107 20.222 proxWan 8AA851000101 TCP
108 20.222 proxWan 8AA851000101 HTTP
109 20.422 proxWan 8AA851000101 TCP
¦ -V -.У ¦: ¦'. ¦ .?.¦ у'- '-:: ''•'¦¦¦ - "
110 20.533 8AA851000101 proxWan HTTP
111 20.643 proxWan 8AA851000101 HTTP
112 20.873 8AA851000101 proxWan HTTP
113 21.023 proxWan 8AA851000101 TCP
114 0
STATS
.A...., len: 0, seq:
242571-242571,
ack: 631554827,
win: 8088, ere: 3491
dst:80 , ...
Ответ(клиенту
через порт 3495)
.A..S., len: 4, seq:
170783881-170783884,
ack: 241782, win: 8760,
sre 80 dst: 3498
.A...., len: 0, seq:
241782-241782,
ack: 170783882,
win: 8760, ere: 3498
dst: 80
Запрос GET
(от клиента
через порт 3498)
.A...., len: 0, seq:
243130-243130,
ack: 1485617155,
win: 7904, ere: 3495
dst: 80
Ответ (клиенту
через порт 3498) .
Запрос GET
(от клиента
через порт 3498)
Ответ(клиенту
через порт 3498)
.A...., len: 0, seq:
242548-242548,
ack: 170784332,
win: 8310, ere: 3498
dst: 80
Число перехваченных
кадров = 113

Глоссарий
Аск Управляющий бит (подтверждения) не занимает места в последователь-
последовательности и указывает, что поле подтверждения сегмента определяет следующий
номер последовательности, который ожидает отправитель этого сегмента,
подтверждая получение всех предыдущих номеров последовательности. I
Bit Бит. Единица или ноль.
Byte Байт. Восемь битов. Смотрите также Octet.
Backup Browser Резервный броузер. Получает копию списка просмотра от
мастер-броузера и передает список по запросу компьютерам домена.
Connection Соединение. Логический путь коммуникации, определяемый
парой сокетов.
Datagram Дейтаграмма. Сообщение, посылаемое в коммуникационных сетях
компьютеров с пакетной коммутацией. < = ,, ,, , '
Destination Address Целевой адрес. Адрес места назначения, обычно иденти-
идентификаторы хоста и сети.
Domain Master Browser Мастер-Броузер домена. Всегда первичный контроллер
домена; он отвечает за сбор объявлений для всего домена, включая все подсети
сети TCP и сетевые сегменты.
Fin Управляющий бит (конец), занимающий один номер последовательности.
Он указывает, что отправитель больше не будет посылать данные или контро-
контролировать пространство занимающей последовательности.
Fragment Фрагмент. Часть логической единицы данных; в частности, фрагмент
Интернета является частью дейтаграммы Интернета.
FTP Протокол пересылки файлов.
Gratuitous ARP_RARP Добровольный ARP_RARP. Широковещательное сооб-
сообщение, сделанное клиентом DHCP перед использованием адреса IP. Компью-
Компьютер берет адрес, присвоенный ему DHCP, и посылает запрос ARP именно для
этого адреса. Таким образом, если другая машина имеет этот адрес, то возник-
возникнет сетевая ошибка двойного IP-адреса. Другое свойство добровольного
ARP_RARP состоит в том, что машины, которые имеют старый IP-адрес в своем
кэше, будут автоматически обновлять свой кэш ARP при получении запроса.
GUID (Globally Unique Identifier) Глобальный уникальный идентификатор.
Другое имя для UUID (Universally Unique Identifier — универсальный уника-
уникальный идентификатор). Является уникальной идентифицирующей строкой,
связанной с интерфейсом вызова удаленной процедуры. Например:
12345678-1234-ABCD-EF00-01234567CFFB.

348 Глоссарий
Header Заголовок. Управляющая информация в начале сообщения, сегмента,
фрагмента, пакета или блока данных.
Host Хост. В терминологии IP любое устройство с IP-адресом. Это может быть
компьютер, принтер, управляемый концентратор, коммутатор или маршрутиза-
маршрутизатор. В более общем смысле это либо источник, либо место назначения сообщений
в сети.
Identification Идентификация. Поле протокола Интернета, присвоенное
отправителем, которое помогает при сборке фрагментов дейтограммы.
Internet address Адрес Интернета. Адрес источника или места назначения,
характерный для уровня хоста. Это IP-адрес, такой как 10.0.0.10.
Internet datagram Дейтаграмма Интернета. Единица обмена данными между
модулями Интернета и протоколами более высокого уровня вместе с заголовком
Интернета.
Internet fragment Фрагмент Интернета. Часть данных дейтограммы Интернета
с заголовком Интернета.
IRS number (Initial Receive Sequence) Начальный номер последовательности
получения. Первый номер последовательности, используемый отправителем
при соединении.
ISN (Initial Sequence Number) Начальный порядковый номер. Первый номер
последовательности, используемый при соединении (ISS или IRS). Выбирается
процедурой на основе часов.
ISS number (Initial Send Sequence) Начальный номер посланной последовате-
последовательности. Первый номер последовательности, используемой отправителем при
соединении.
Leader Заголовок. Управляющая информация в начале сообщения или блока
данных; в частности, в ARPANET управляющая информация в сообщении
ARPANET в интерфейсе хост-ШР.
Left sequence Оставшаяся последовательность. Следующий номер последова-
последовательности, который будет подтвержден при получении данных (или наимень-
наименьший неподтвержденный в настоящее время номер последовательности),
который иногда называется левым краем посланного окна.
Local packet Локальный пакет. Единица информации в локальной сети.
Magic Cookie Область из четырех байтов в пакете DHCP, которая идентифи-
идентифицирует начало поля специальных параметров, зависящих от поставщика. Если
используется данное поле параметров, это отмечается IP- адресом 99.130.83.99,
который показывается в трассировке Netmon как шестнадцатеричное 63 82 53
63. Параметры могут содержать идентификатор клиента, запрошенный адрес,
а также другие позиции.
Master browser Мастер-броузер. Отвечает за сбор информации для создания
и поддержания списка просмотра, который содержит все серверы в домене
мастер-броузера или рабочей группы, а также перечисляет все домены в сети.
Module Модуль. Реализация, обычно программная, протокола или другой
процедуры.

Глоссарий 349
MSL (Maximum Segment Lifetime) Максимальное время жизни сегмента. Время,
в течение которого сегмент TCP может существовать в системе взаимодействия
сетей. Произвольно определен как две минуты. .,.. .с < .
Nonbrowser He-броузер. Специально сконфигурирован для того, чтобы не под-
поддерживать список просмотра.
Octet Октет. Байт из восьми битов. Сегодня несколько анахронический тер-
термин. Раньше существовали десятибитные байты. • . .-.-..
Options Параметры. Могут содержать несколько параметров, каждый из кото-
которых может иметь в длину несколько октетов. Параметры используются прежде
всего в ситуация проверки; например, для задания отметки времени. Протокол
Интернета и TCP предоставляют поля параметров.
Packet Пакет. Пакет данных с заголовком, который может или нет быть
логически завершенным; чаще встречается физическое, а не логическое
пакетирование данных.
Port Порт. Часть сокета, которая определяет, какой канал логического ввода
или вывода процесса связан с данными.
Potential Browser Потенциальный броузер. Компьютер, который может под-
поддерживать список просмотра сетевых ресурсов. Он пока еще не имеет списка и
будет поддерживать список просмотра, только если мастер броузер прикажет
ему это делать.
Process Процесс. Программа во время выполнения; источник или место на-
назначения данных с точки зрения TCP или другого протокола хост-хост.
PUSH Управляющий бит, не использующий номер из последовательности и
указывающий, что сегмент содержит данные, которые должны быть доставле-
доставлены получающему пользователю.
Receive next sequence number Следующий номер последовательности для по-
получения. Следующий номер последовательности, который ожидает получить
локальный TCP.
Receive window Окно получения. Номера последовательности, которые готов
получить локальный (получающий) TCP. Таким образом, локальный TCP рас-
рассматривает сегменты, перекрывающие диапазон от RCV.NXT до RCV.NXT +
RCV.WND -1, несущие приемлемые данные или управляющую информацию.
Сегменты, содержащие номера последовательности полностью вне этого диа-
диапазона, рассматриваются дубликатами и отбрасываются.
RST Управляющий бит (сброс), не использующий пространство последовате-
последовательности и указывающий, что получатель должен удалить соединение без даль-
дальнейшего взаимодействия. Получатель может определить на основе номера
последовательности и полей подтверждения входящего сегмента, должен он
принять или игнорировать команду reset. В любом случае получение сегмента,
содержащего RST, порождает RST в ответ.
RTP (Real Time Protocol) Протокол реального времени. Протокол хост-хост
для передачи информации, критически важной по времени.
Segment Сегмент. Логическая единица данных; в частности сегмент TCP явля-
является единицей данных, пересылаемых между парой модулей TCP.

350 Глоссарий
i
Segment acknowledgment Подтверждение сегмента. Номер последовательно-
последовательности в поле подтверждения приходящего сегмента.
Segment length Длина сегмента. Объем пространства номеров последовате-
последовательности, занимаемый сегментом, включая любую управляющую информацию,
которая занимает пространство последовательности.
Segment sequence Последовательность сегментов. Номер в поле последователь-
последовательности приходящего сегмента. ; . .'¦-.;.•¦ •¦¦,¦•.¦'.¦.". -ДСГ; ¦;¦¦
Send sequence Последовательность отправки. Следующий номер последо-
последовательности, который будет использовать локальный (посылающий) TCP
при соединении, выбираемый вначале из области начальных номеров по-
последовательности (ISN) и увеличиваемый для каждого переданного октета
данных.
Send window Окно передачи. Представляет номера последовательности, кото-
которые готов получить удаленный (получающий) TCP. Оно равно значению поля
окна, определенного в сегментах удаленного TCP (получающего данные). Диа-
Диапазон номеров новой последовательности, который может быть послан TCP,
находится между SND.NXT и SND.UNA + SND.WND -1. (Конечно, ожидается
пересылка номеров последовательности между SND.UNA и SND.NXT.)
Socket Сокет. Адрес, который специально включает идентификатор порта,
т.е. соединение адреса Интернета с портом TCP.
Source address Адрес источника. Обычно идентификаторы сети и хоста.
SYN Управляющий бит во входящем сегменте, занимающий номер последо-
последовательности, используемый при инициации соединения, чтобы указать, где
начнется нумерация последовательности.
ТСВ (Transmission Control Block) Блок управления передачей. Структура данных,
которая записывает состояние соединения. .
TCP (Transmission Control Protocol) Протокол управления передачей. Протокол
хост-хост для надежной коммуникации в межсетевых средах.
Type of Service Тип службы. Поле протокола Интернета, которое указывает
тип службы для этого фрагмента Интернета.
UUID (Universally Unique Identifier) Универсальный уникальный идентифика-
идентификатор. Уникальная идентификационная строка, связанная с интерфейсом вызова
удаленной процедуры, называемая также иногда GUID (глобальный уникальный
идентификатор). Пример: 12345678-1234-ABCD-EF00-01234567CFFB.
URG Управляющий бит (срочности), не использующий номер последователь-
последовательности, указывает, что получающий пользователь должен выполнить срочную
обработку, как только будут получены данные с номерами последовательности
меньше значения, указанного в указателе срочности.
Urgent pointer Указатель срочности. Управляющее поле, имеющее смысл, то-
только когда задан бит URG. Это поле передает значение указателя срочности,
которое указывает октет данных, связанный со срочным вызовом посылающего
пользователя.