SMB достаточно развит, чтобы преобразовывать имя сервера множеством различных методов. Например, в URL file://prox/users/teresa/movies.xIs клиент возьмет часть между двумя наклонными чертами и следующей наклонной чертой в качестве имени сервера, а остальное будет интерпретировано как относительное имя. В примере именем сервера будет 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.
Пример потока сообщений
Типичная последовательность обмена сообщениями для клиента, соединенного с сервером уровня пользователя включает открытие файла, чтение из него данных, закрытие файла и разъединение с сервером. Механизм пакетирования запросов CIFS (называемый механизмом "AndX") дополнительно позволяет объединять в одно до шести сообщений в этой последовательности, поэтому в действительности в этой последовательности существуют только три перехода туда и обратно, и последнее из них клиент может сделать асинхронно.
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. В большом домене можно сократить это до такой степени, что домен никогда не будет синхронизирован.
PulseMaximum используется для управления частотой, с которой PDC будет посылать сообщения pulse своим BDC, даже если базы данных являются актуальными. По умолчанию используется 7200 секунд (два часа), а максимальное значение PulseMaximum равно 172800 секундам (два дня). Это значение можно задавать для гарантии, что PDC не всегда контактирует с BDC при изменениях. Если PulseMaximum задан как максимум в два дня, возникает риск истечения срока действия пароля учетной записи. Задание его как один день выглядит достаточно безопасным для сети с большим числом BDC в удаленных WAN.
PulseTimeoutl контролирует время ожидания PDC ответа от BDC, когда было послано сообщение "announce change to UAS or SAM". Если BDC не отвечает в течение этого периода, то он считается не реагирующим. Не реагирующий BDC не учитывается числом PulseConcurrency, что позволит соединиться дополнительному BDC. Он сможет затем обновить изменения в базе данных, если кто-то превысит предел PulseTimeoutl. Если, однако, значение PulseConcurrency было увеличено, чтобы включить все BDC, то это не будет иметь никакого значения. По умолчанию на ответ на сообщение pulse дается 10 секунд.
В WAN с медленными каналами связи значение по умолчанию 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 будет занимать один из слотов PulseConcurrency в течение длительного времени (два часа), увеличивая тем самым время выполнения частичной синхронизации. Если это значение слишком маленькое (минимум равен 60 секундам), то нагрузка на PDC будет увеличиваться в связи с большим числом BDC, выполняющих частичные синхронизации.
ReplicationGoverner применяется для управления долей полосы пропускания, которую может использовать служба NetLogon, при выполнении проверки базы данных. По умолчанию используется значение 100 процентов сетевой полосы пропускания при использовании буфера размером 128 Кбайт данных. Это легко может поглотить весь канал на медленной линии связи между удаленными сайтами WAN. Задавая этот ключ как 50 процентов, тем самым изменяют две вещи. Теперь служба NetLogon будет обладать буфером в 64 Кбайта данных и иметь для сообщений синхронизации 50 процентов полосы пропускания.
Это значение не должно задаваться меньше 25, иначе синхронизация может никогда не закончиться. Однако можно использовать команду AT планировщика команд, чтобы задавать для этого параметра различные значения в течение дня. Например, можно задавать ReplicationGaverner равным 25 днем и равным 100 ночью. Конечно, это следует делать на каждом BDC, но проблема невелика.
Протокол 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 является командой сброса, которая прерывает текущую транзакцию. Вся информация в буферах будет сброшена и таблицы состояния очищены. Она также получает с сервера ответ ОК. Эта команда может быть отправлена в любой момент во время общения.
