Лучшее, что можно сделать для оптимизации трафика броузера в интрасети,— это небольшие, эффективные страницы Web, где создается большая часть трафика. Чтобы реализовать эту оптимизацию, можно предпринять следующее:
1. Сократите число графических изображений, используемых на странице Web, так как они составляют существенную часть сетевого трафика. При использовании графики проверьте, что графический формат оптимизирован для Web (т.е. не используйте файлы .bmp или .tiff, так как с ними связан большой объем дополнительных накладных расходов).
2. Ограничьте использование фреймов, так как использование нескольких фреймов может приводить к нескольким загрузкам для каждой страницы.
3. Сократите необходимость прокручивания страницы. Чтобы сделать это, разбейте страницу на меньшие куски. Таким образом, если клиент не заинтересован во всей странице, не будет затрачиваться дополнительное время для загрузки ненужной информации.
4. Разместите серверы прокси в удаленных местах и разрешите активное кэширование. Это позволит сократить количество повторных загрузок одной и той же информации.
5. Увеличьте размер кэша на локальной машине. Кэширование данных на локальной машине ускорит для пользователя процесс просмотра и сократит сетевой трафик. Все это уменьшает для компьютера необходимость загружать одну и ту же информацию при повторном посещении страниц Web.
6. Тщательно оцените необходимость защищенности (как узлов, защищенных паролем, так и SSL), поскольку слишком слабая защищенность вызывает дополнительный сетевой трафик.
Протокол SMTP (Simple Mail Transfer Protocol, простой протокол передачи почты) используется для получения почты из Интернета. Когда адрес сервера преобразован (с помощью DNS), создается соединение с портом 25. Команды SMTP используются для управления потоком почты из одной машины в другую. Каждая из этих команд заканчивается нажатием клавиши Enter или Return. Команды SMTP не зависят от регистра символов, хотя SMTP будет сохранять регистр при адресации, так как некоторые реализации могут иметь имена пользователей, зависящие от регистра символов. Как видно на рис., для создания соединения может использоваться Telnet, а также другой сервер SMTP. Это часто делается для тестирования соединения почты Интернета с Exchange. Процесс начинается с команды mail, посылаемой отправителем с помощью from: в форме <имя_пользователя>@<имя_домена>. From: является полем, которое сообщает серверу SMTP имя пользователя. <имя_пользователя>@<имя_домена> также станет ответом для адреса.
Команда HELO (HELLO в некоторых реализациях) позволяет узнать, общаются ли две машины. В то время как приветствие при соединении идентифицирует сервер получателя, HELO используется для идентификации отправителя на сервере SMTP. HELO и сопровождающий 250 OK позволяют узнать, что отправитель и получатель находятся в состоянии начального соединения без выполняющихся транзакций и с пустыми буферами. Команда mail сообщает серверу SMTP, что начинается новая транзакция. Если все правильно, то вернется ответ 250 ОК. from: называется также адресом обратного пути. Он может содержать более одного почтового ящика, а также список хостов для обратной маршрутизации источника.
Следующей командой MAIL используется для начала почтовой транзакции. Эта строка также будет содержать from:, что называется обратным путем доступа и используется для извещений о недоставке. Эта информация хранится сервером SMTP отправителя в буфере обратных путей доступа, который будет обрабатываться после ввода всех данных.
RCPT идентифицирует получателя сообщения и является командой, вводимой после команды mail. Если эта команда mail получена сервером SMTP правильно, то будет возвращаться ответ 250-ОК. Если получатель неизвестен, то с сервера вернется ошибка 550. Если получатель введен неправильно, то будет порождаться ошибка 553 неправильно сформированного адреса. Протокол позволит в этом месте ввести в процесс несколько получателей. Нажатие клавиши Return в конце строки RCPT и ввод другой команды RCPR вводит дополнительных получателей. Кроме почтового ящика в поле RCPT можно также поместить список маршрутов хостов источников. Данные RCPT хранятся в буфере путей доступа пересылки столько, сколько нужно серверу.
Третьим шагом является команда 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 является командой сброса, которая прерывает текущую транзакцию. Вся информация в буферах будет сброшена и таблицы состояния очищены. Она также получает с сервера ответ ОК. Эта команда может быть отправлена в любой момент во время общения.
Когда между двумя компьютерами впервые создается сеанс, есть возможность убедиться, что серверы общаются именно с тем, с кем они собирались общаться. Для этого используется команда HELO. Эта команда может посылаться только один раз и имеет форму HELO mred.com. HELO идентифицирует посылающий компьютер для сервера SMTP. Если при обработке команды не возникает ошибок, то ответом будет 250 ОК. Эту команду можно интерпретировать как "Привет, я mred.com". Если команда HELO посылается во второй раз, то ответом будет 503 bad sequence (неверная последовательность). В указанном домене никакой проверки не делается, и имя домена можно оставить пустым, как на рис. Когда сеанс заканчивается, для закрытия канала посылается команда QUIT.
Рассмотрим теперь некоторые трассировки, показывающие, как работает почта 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, перевод строки), как видно на распечатке ниже.
