Блокировки Level П oplock позволяют нескольким клиентам иметь открытым один файл при условии, что ни один клиент не выполняет операций записи в файл. Это важно для сред со старыми машинами. Большинство открытий в режиме совместимости этих клиентов отображается в запрос открытия для совместно используемого доступа к файлу для чтения/записи. Однако помните, что это может также отменять блокировки oplock для других клиентов, даже если ни один из клиентов в действительности не намерен писать в файл.
Последовательность действий почти такая же, как у исключающей блокировки oplock. Основное различие состоит в том, что сервер информирует клиента, что он должен прекратить блокировку Level II oplock, когда никто не пишет в файл. То есть клиент А, например, может открыть файл для желательного доступа READ и общего доступа READ/WRITE. Это означает, что клиент А не будет выполнять никаких записей в файл.
Когда клиент В открывает файл, сервер должен синхронизироваться с клиентом А, если последний имеет какие-либо буферизованные блокировки Когда он синхронизируется, запрос клиента В на открытие может быть завершен. Клиент В, однако, информируется, что он имеет Level II oplock, а не исключающую блокировку oplock для файла.
В этом случае ни один клиент с блокировкой level П oplock на файле не сможет буферизировать какую-либо информацию блокирования на локальной клиентской машине. Это позволяет серверу гарантировать, что если выполняется какая-либо операция записи, то ему необходимо только уведомить клиентов level II, что блокировка должна быть прервана, без необходимости синхронизации всех аксессоров (средств доступа) файла.
Level II oplock может быть ПРЕРВАНА В НИКУДА (BROKEN ТО NONE), означая, что некоторый клиент, открывший файл, выполнил теперь операцию записи в файл. Так как ни один клиент level II не может создать ситуацию блокирования буфера, то информация на сервере остается в согласованном состоянии. Записывающий клиент, например, не сможет записать в заблокированный диапазон по определению. Однако данные опережающего чтения могут буферизироваться на клиентской машине, снижая тем самым объем сетевого трафика, требуемого файлу. Когда прерывается блокировка level II oplock, буферизирующий клиент должен очистить свои буферы и прекратить выполнение всех операций на файле через сеть. Никакого ответа на прерывание oplock от клиента не ожидается, когда сервер прерывает его из LEVEL II в NONE.
Выделенный IP-адрес должен обновляться до истечения срока своей службы. Как можно видеть в распечатке выше, когда выделенный адрес подтверждается, одновременно задается время обновления. Процесс обновления требует только двух кадров: запроса DHCP и последующего АСК.
Клиент DHCP будет запрашивать обновление дважды — при запуске и при истечение половины выделенного времени. В каждом из этих случаев, если запрос успешен, он будет использовать только два кадра. Эти два кадра выглядят точно так же, как кадры запроса и подтверждения, показанные в предыдущем разделе. Единственное различие состоит в том, что при запросе во время истечения половины выделенного времени это будет направленная дейтаграмма, а не широковещательное сообщение, как в случае обновления при запуске.
Эти два кадра имеют размер всего 684 байта и требуют только 100 миллисекунд для завершения. Если клиентской машине DHCP не удалось получить обновление после двух попыток, она будет ждать до следующего периода обновления. Если срок выделенного адреса истекает, то машина возвращается к описанному ранее процессу из четырех кадров, как если бы она пыталась получить адрес в первый раз.
Оптимизация трафика DHCP В действительности трафик DHCP имеет минимальное влияние на объем создаваемого сетевого трафика. Существуют только шесть случаев, когда трафик будет присутствовать вообще. Они перечислены ниже:
• Клиенту DHCP требуется адрес в первый раз — четыре кадра.
• Автоматическое обновление при истечении половины выделенного времени — два кадра.
• Перезапуск клиентской машины DHCP — два кадра.
• Машина перемещается в новую подсеть. Это будет создавать два кадра обновления, которые получат отрицательное подтверждение, затем четыре кадра для получения адреса — всего шесть кадров.
• Замена NIC на машине — четыре кадра.
• Адрес IP освобождается или обновляется вручную, с помощью либо ipconfig, либо winipcfg.
Одним из основных способов сокращения объема трафика DHCP является настройка длительности времени выделения. Это делается менеджером DHCP, как показано на рис. Если длительность выделения адреса изменяется с используемых по умолчанию трех дней до тридцати дней, то сокращение трафика может быть существенным — 13684 байта на каждую машину. Такое изменение имеет смысл, когда область адресов значительно больше, чем число хостов, которые необходимо адресовать. Если это не так, то придется либо использовать длительность выделения по умолчанию, либо сделать длительность еще короче. Другой сценарий при настройке длительности выделения номера может возникать в ситуации, когда существует большое количество переносных компьютеров, которые соединяются с сетью на регулярной основе. Если пользователи не обучены освобождать свои IP-адреса при выходе из сети, они могут получать несколько адресов, требуя тем самым большего пространства адресов, чем необходимо.
Получив подходящий 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). Регистрируется само имя домена, а также имена пользователей, регистрирующихся в домене. Эти имена нужны для некоторых функций сообщений и коммуникации. Например, если необходимо послать сообщение, используя сетевую команду send (послать) некому Джейсону, он должен иметь зарегистрированное имя пользователя, иначе ничего не получится. Общее число зарегистрированных имен зависит, очевидно, от числа запущенных служб. Каждое зарегистрированное имя будет использовать всего 214 байтов — 110 байтов для запроса регистрации имени и 104 байта для ответа. Посмотрим теперь на такую транзакцию на листинге ниже:
Система имен доменов (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 байтам, в зависимости от количества перечисленных имен серверов. Отметим, что
DNS является направленным протоколом, и адрес MAC места назначения является реальным адресом сервера DNS, а не широковещательным адресом, как в других протоколах. Кроме того, мы видим в разделе IP, что место назначения является реальным IP-адресом сервера DNS в этой сети.
Раньше при возникновении проблемы с сетью, часто приходилось гадать, что же вызвало неполадки. Позже появились специализированные устройства, которые были дорогими, трудными для управления и понимания. Теперь имеется сетевой монитор, который является программным инструментом анализа компании Microsoft. Существуют две версии этой программы: сокращенная, поставляемая с серверными операционными системами, и полная, которая поставляется с сервером управления системами. Microsoft Network Monitor Lite способен перехватывать трафик, предназначенный только для машины, выполняющей программу. Полная версия переводит сетевой адаптер в "режим, не делающий различия" — т.е. он перехватывает трафик, направленный на компьютер, выполняющий Microsoft Nerwork Monitor, а также трафик, предназначенный для других устройств.
Network Monitor 2.0 поставляется вместе с Windows 2000 в версии Lite, а полная версия поставляется вместе с Windows NT 4.0 и SMS 2.0. Network Monitor 1.2. поставляется вместе с Windows NT 4.0 и SMS 1.2. В действительности существует лишь Небольшое различие между версиями продукта 2.0 и 1.2, так как функционально они одинаковы. Мы укажем различия, но большая часть рассматриваемого материала применима к любой версии продукта.
Microsoft Network Monitor копирует кадры в буфер перехвата, который является областью памяти с изменяемым размером. По умолчанию этот буфер перехвата равен одному мегабайту, но это легко изменить. Однако в связи с этим зависимым от памяти буфером перехвата сетевой монитор может перехватить лишь столько информации, сколько может поместиться в доступной памяти. Когда буфер будет заполнен, он начнет отбрасывать пакеты, и поэтому можно пропустить разыскиваемую информацию. Кроме того, сетевой монитор имеет склонность блокировать и связывать большую часть ресурсов процессора, когда ему разрешается выполняться в течение продолжительных периодов после полного заполнения буфера. К счастью, легко прекратить его работу с помощью Task Manager, но тогда теряется весь перехваченный файл. Мы узнаем некоторые приемы решения этой проблемы при рассмотрении необслуживаемого мониторинга сети. Потеря файла обычно не является проблемой, так как можно выбрать, какую часть кадра необходимо увидеть, создавая фильтр перехвата. Фильтр перехвата (который в определенном смысле похож на запрос к базе данных) позволяет перехватывать только определенные адреса или типы кадров. Мы поговорим об этом в разделе о перехвате данных.
Так как Microsoft Nerwork Monitor легкодоступный, очень мощный инструмент, способный перехватывать данные из сети, необходимо позаботиться о системе безопасности. Как мы видели в других главах, обладая определенными навыками, из сети можно получить очень важную информацию. Microsoft Nerwork Monitor может быть прекрасным инструментом для поиска неисправностей, но также может представлять существенную опасность, оказавшись в недобросовестных руках. Есть несколько способов защиты сети от неавторизованного использования этого инструмента. Мы-поговорим об этом позже, в разделе о безопасности сетевого монитора.
Microsoft Network Monitor не устанавливается по умолчанию. Чтобы установить его, перейдите к вкладке служб сетевого апплета в панели управления и выберите добавить (add) инструменты сетевого монитора и агент. (ПРИМЕЧАНИЕ. Не забудьте выбрать инструменты сетевого монитора и агента, а не просто агента сетевого монитора, который представлен в списке ниже и не включает программу Microsoft Network Monitor.) Установка версий SMS использует отдельную программу Setup.exe, находящуюся в каталоге NMEXR на сайте издательства "ЛОРИ".
