Цель механизма срочной доставки TCP состоит в том, чтобы посылающий пользователь мог стимулировать получателя принять некоторые срочные данные и разрешить получающему TCP указать получателю, что все известные в данный момент срочные данные получены пользователем.
Этот механизм позволяет в потоке данных обозначить точку как конец срочной информации. Всякий раз, когда эта точка у получающего TCP возникает перед номером получаемой последовательности (RCV.NXT), TCP должен приказать пользователю перейти в "режим срочности". Когда номер получаемой последовательности сталкивается с указателем срочности, TCP должен приказать пользователю перейти в "нормальный режим". Если указатель срочности обновляется, когда пользователь находится в "режиме срочности", обновление будет для пользователя невидимым. Метод использует поле срочности, которое переносится во всех передаваемых сегментах. Управляющий флаг URG указывает, что поле срочности имеет смысл и должно быть добавлено к номеру последовательности сегмента, чтобы породить указатель срочности. Отсутствие этого флага указывает, что ожидающих срочных данных нет.
Чтобы послать указание о срочности, пользователь должен послать также по крайней мере один октет данных. Если посылающий пользователь указывает путь доступа, то своевременность доставки срочной информации в процесс места назначения улучшается.
Выделенный 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 байта для ответа. Посмотрим теперь на такую транзакцию на листинге ниже:
DisablePasswordChange по умолчанию равно 0. Это означает, что пароль учетной записи машины должен изменяться каждые три дня и синхронизироваться с одним из PDC. Если машина Windows NT не получает доступа к PDC после изменения пароля, то PDC будет квитировать существующий пароль для следующих трех дней. Через шесть дней, когда компьютер Windows NT попытается аутентифицировать учетную запись машины, пароль не будет совпадать с паролем в базе данных системы безопасности. Это не должно меняться, если только не будут полностью оценены последствия такого изменения. Пароль учетной записи машины используется для защиты против подделки учетной записи компьютера и является поэтому составной частью системы безопасности NT.
Pulse используется для контроля частоты, с которой PDC будет просматривать изменения в базе данных служб каталогов и посылать сообщения "announce change to UAS or SAM" для BDC о том, что требуется обновление. По умолчанию используется значение pulse равное 300 секундам (5 минутам); оно может, однако, принимать максимальное значение 17200 секунд (48 часов). Служба 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. В большом домене можно сократить это до такой степени, что домен никогда не будет синхронизирован.
Пришло время запустить сетевой монитор. Чтобы управлять перехватом вручную, используется меню перехвата. Однако прежде чем нажать Start, необходимо задать размер буфера. Выбор настроек буфера из меню перехвата позволит сконфигурировать буфер. Используемый по умолчанию максимальный размер буфера перехвата, равный 8 мегабайтам, меньше объема оперативной памяти, установленной на машине. Хотя можно использовать виртуальную память для буфера перехвата, лучше этого не делать для гарантии, что критически важная информация кадра надежно перехвачена. Microsoft Network Monitor пошлет предупреждение при попытке ввести размер буфера перехвата больше физической памяти машины. Сообщение говорит: "Запрашиваемый размер буфера может вызывать потерю кадров в связи с процессом подкачки. Вы уверены, что хотите разместить буфер этого размера?"
Помимо выбора размера буфера можно также выбрать размер кадра, который желательно перехватывать. Например, если интересует только информация заголовка для определенного протокола, то можно задать здесь эту информацию и не тратить пространство на перехват лишних данных кадра. Какой размер кадра перехватывается, зависит от определенного исследуемого протокола. Например, так как мы знаем, что нормальный заголовок Ethernet равен 14 байтам, можно задать кадр перехвата в 14 байтов и перехватывать только заголовки Ethernet. Это позволит нам перехватить 73142 кадра с помощью одномегабайтного буфера перехвата. Можно было бы использовать 34-байтовый кадр для перехвата заголовка IP (14 байтов для заголовка Ethernet и 20 байтов для заголовка IP). Это очень полезно при исследовании проблем передачи файлов, которые часто содержат 1200 или больше байтов данных пользователя, которые могут быстро заполнить буфер перехвата.
Обновление окна статистики перехвата, показанного на рис., создает для центрального процессора нагрузку, которая может быть излишней. Выбирая режим выделенного (dedicated) перехвата в меню перехвата, можно избежать нагрузки, связанной с обновлением изображения, и тем самым предоставить дополнительные ресурсы для перехвата кадров. Как показано на рис, в режиме выделенного перехвата имеется возможность переключения в нормальный режим, выбрав его из меню перехвата. Можно сделать все эти переключения во время работы Microsoft Network Monitor и не потерять кадры. Кроме того, можно приостановить Netmon и продолжить работу приложения в этом режиме.
