Лучшее, что можно сделать для оптимизации трафика броузера в интрасети,— это небольшие, эффективные страницы Web, где создается большая часть трафика. Чтобы реализовать эту оптимизацию, можно предпринять следующее:
1. Сократите число графических изображений, используемых на странице Web, так как они составляют существенную часть сетевого трафика. При использовании графики проверьте, что графический формат оптимизирован для Web (т.е. не используйте файлы .bmp или .tiff, так как с ними связан большой объем дополнительных накладных расходов).
2. Ограничьте использование фреймов, так как использование нескольких фреймов может приводить к нескольким загрузкам для каждой страницы.
3. Сократите необходимость прокручивания страницы. Чтобы сделать это, разбейте страницу на меньшие куски. Таким образом, если клиент не заинтересован во всей странице, не будет затрачиваться дополнительное время для загрузки ненужной информации.
4. Разместите серверы прокси в удаленных местах и разрешите активное кэширование. Это позволит сократить количество повторных загрузок одной и той же информации.
5. Увеличьте размер кэша на локальной машине. Кэширование данных на локальной машине ускорит для пользователя процесс просмотра и сократит сетевой трафик. Все это уменьшает для компьютера необходимость загружать одну и ту же информацию при повторном посещении страниц Web.
6. Тщательно оцените необходимость защищенности (как узлов, защищенных паролем, так и SSL), поскольку слишком слабая защищенность вызывает дополнительный сетевой трафик.
Третьим шагом является команда DATA, за которой следует нажатие клавиши Enter или отправка возврата каретки и перевода строки (<CRLF>) (несколько анахронический термин). Когда сервер получит эту команду, протокол SMTP рассматривает весь последующий трафик как данные для этого поля, пока не получит строку, содержащую только одну точку. Другими словами, раздел данных завершается, когда получающий сервер получит строку символов return-T04Ka-return (<CRLF>.<CRLF>). Индикатор конца данных подтверждает транзакцию и приказывает серверу SMTP обработать данные в буфере обратного пути доступа и буфере пути доступа пересылки. Когда обработка закончена, сервер вернет ОК. Приняв сообщение, сервер вставляет отметку времени в начале строки почтовых данных, которая указывает идентичность посылающего и получающего хостов. При конечной доставке сообщения также вставляется строка пути возврата, которая содержит информацию из обратного пути, введенного вместе с командой mail. Поле данных почты может также содержать, если потребуется, тему данных, строки to, сс и from. На рис. показано использование этих команд в сеансе Telnet, созданном с сервером Exchange. Это хороший способ протестировать соединение Exchange и почты Интернета.
Команда DATA будет отказывать, только если транзакция является неполной или нет доступных ресурсов для обработки запроса. Реализация SMTP в Microsoft Exchange не позволит иметь неполное сообщение. Как можно видеть на рис, Exchange требует, чтобы команды вводились в определенном порядке, прежде чем он будет обрабатывать данные.
Протокол SMTP включает дополнительные свойства для помощи в поиске получателей и списков распространения. Этими командами являются команда VRFY, которая используется для предоставления информации о пользователях почтового ящика, и команда EXPR, используемая для списков распространения. Однако, как видно на рис. эти команды не реализованы в Microsoft Exchange по соображениям безопасности. Вместо них для предоставления этой информации используется LDAP.
Команда NOOP используется для определения отсутствия операции. Она не влияет ни на какие введенные ранее команды или параметры. Она просто означает ничего не делать и получает с сервера ответ ОК.
RSET является командой сброса, которая прерывает текущую транзакцию. Вся информация в буферах будет сброшена и таблицы состояния очищены. Она также получает с сервера ответ ОК. Эта команда может быть отправлена в любой момент во время общения.
Рассмотрим теперь некоторые трассировки, показывающие, как работает почта SMTP в реальной жизни. Для создания соединения SMTP с Exchange требуется пять кадров и 420 байтов. Это включает трехходовое квитирование, кадр готовности службы SMTP и еще один кадр подтверждения (АСК). Посмотрим на кадр готовности службы на распечатке ниже. Код ответа 220, как мы знаем из таблицы, означает, что служба готова. Этот кадр поступает из порта 25, который используется для службы SMTP. Код 220 посылается как стандартный код ASCII и показан в шестнадцатеричной панели как 32 32 30. Символ ASCII для 20 равен 50 и преобразуется в шестнадцатеричное 32. Символ ASCII для 0 равен 48 и преобразуется в шестнадцатеричное 30.
Хотя TCP является дуплексным протоколом, SMTP действует только в полудуплексном режиме. Это означает, что посылаемый символ должен быть подтвержден перед посылкой следующего символа. Это требование создает большой объем трафика подтверждения (АСК). Например, просто отправка команды HELO требует 11 кадров и 695 байтов. Когда посылается и подтверждается HELO, следующий кадр с клиентской машины посылает 0D OA (ASCII 13, возврат каретки, и ASCII 10, перевод строки), как видно на распечатке ниже.
Раньше при возникновении проблемы с сетью, часто приходилось гадать, что же вызвало неполадки. Позже появились специализированные устройства, которые были дорогими, трудными для управления и понимания. Теперь имеется сетевой монитор, который является программным инструментом анализа компании 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 на сайте издательства "ЛОРИ".
Пришло время запустить сетевой монитор. Чтобы управлять перехватом вручную, используется меню перехвата. Однако прежде чем нажать Start, необходимо задать размер буфера. Выбор настроек буфера из меню перехвата позволит сконфигурировать буфер. Используемый по умолчанию максимальный размер буфера перехвата, равный 8 мегабайтам, меньше объема оперативной памяти, установленной на машине. Хотя можно использовать виртуальную память для буфера перехвата, лучше этого не делать для гарантии, что критически важная информация кадра надежно перехвачена. Microsoft Network Monitor пошлет предупреждение при попытке ввести размер буфера перехвата больше физической памяти машины. Сообщение говорит: "Запрашиваемый размер буфера может вызывать потерю кадров в связи с процессом подкачки. Вы уверены, что хотите разместить буфер этого размера?"
Помимо выбора размера буфера можно также выбрать размер кадра, который желательно перехватывать. Например, если интересует только информация заголовка для определенного протокола, то можно задать здесь эту информацию и не тратить пространство на перехват лишних данных кадра. Какой размер кадра перехватывается, зависит от определенного исследуемого протокола. Например, так как мы знаем, что нормальный заголовок Ethernet равен 14 байтам, можно задать кадр перехвата в 14 байтов и перехватывать только заголовки Ethernet. Это позволит нам перехватить 73142 кадра с помощью одномегабайтного буфера перехвата. Можно было бы использовать 34-байтовый кадр для перехвата заголовка IP (14 байтов для заголовка Ethernet и 20 байтов для заголовка IP). Это очень полезно при исследовании проблем передачи файлов, которые часто содержат 1200 или больше байтов данных пользователя, которые могут быстро заполнить буфер перехвата.
Обновление окна статистики перехвата, показанного на рис., создает для центрального процессора нагрузку, которая может быть излишней. Выбирая режим выделенного (dedicated) перехвата в меню перехвата, можно избежать нагрузки, связанной с обновлением изображения, и тем самым предоставить дополнительные ресурсы для перехвата кадров. Как показано на рис, в режиме выделенного перехвата имеется возможность переключения в нормальный режим, выбрав его из меню перехвата. Можно сделать все эти переключения во время работы Microsoft Network Monitor и не потерять кадры. Кроме того, можно приостановить Netmon и продолжить работу приложения в этом режиме.
