Тип потока данных (DataStream) сообщает, какой тип данных переносится внутри пакета. Он может быть задан как специальное число, определенное приложением через Winsock. Самой важной функцией этого поля является обеспечение аккуратного разъединения сеанса. По умолчанию это будет одно из двух следующих сообщений:
• Конец соединения (End-of-Connection). Если тип потока данных задан как OxFE, то партнер по сеансу хочет прекратить сеанс.
• Конец соединения (End-of-Connection). Если тип потока данных задан как OxFF, то пакет передается, так как был получен запрос конца соединения.
Некоторые из других записей, встречающиеся в этом поле, включают числа, перечисленные в таблице
Идентификатор соединения источника и места назначения Это третье и четвертое поля из семи полей заголовка SPX. Поля идентификаторов сое динения источника и места назначения занимают два байта и используются для демультиплексирования сеансов SPX через единственный сокет на уровне IPX. Если идентификатор соединения места назначения задан как 0XFFFF, значит, это пакет начального соединения.
Порядковый номер Пятое поле в заголовке SPX является полем порядкового номера. Это двухбайтовое поле, содержащее счетчик переданных пакетов данных. Это число будет увеличиваться после получения подтверждения о передаче пакета данных.
Номер подтверждения Шестое поле является полем номера подтверждения, сообщающим номер последовательности следующего пакета SPX, который ожидается от партнера SPX.
Номер размещения Последнее поле заголовка SPX является полем номера размещения. Это поле сообщает номер буфера получения, который доступен на рабочей станции. Этот номер почти всегда больше, чем номер подтверждения. Доступность свободных буферов вычисляется, как размер окна, который равен номеру размещения минус номер подтверждения плюс один. Это поле используется как механизм управления потоком. Он работает следующим образом. Когда получающая сторона посылает номер размещения меньше номера подтверждения, отправитель не будет больше посылать данные, пока получающая сторона не пошлет пакет с номером размещения больше номера подтверждения.
Пример создания соединения Трассировка сетевого монитора, приведенная ниже, показывает последовательность успешной инициализации сеанса. Отметим, что идентификатор соединения места назначения задан как OxFFFF, а номер размещения как OxFFFF. Эта последовательность пакетов называется квитированием SPX.
Протокол блоков сообщений сервера (SMB — Server Message Blocks) является рабочей лошадкой мира Windows NT и Windows 2000. Он используется между компьютерами для общего доступа к файлам, принтерам, последовательным портам и для коммуникационных абстракций, таких как именованные каналы и почтовые ящики. SMB является клиент-серверным протоколом типа запрос-ответ.
Протокол SMB превратился в общую файловую систему Интернета (Common Internet File System, CIFS). CIFS предоставляет межплатформенный механизм клиентских систем для запроса служб файлов и печати на серверных системах. Он поддерживает файлы и печать, используя команды доступа open (открыть), close (закрыть), read (читать), write (писать) и seek (искать). Кроме того, он поддерживает доступ к файлам и записям как в блокированном, так и в неблокированном режиме. Когда приложение блокирует файл, ему не могут помешать другие приложения. Блокированные файл или запись недоступны не блокирующим приложениям.
SMB предоставляет кэширование с опережающим чтением и с обратной записью. Это безопасные операции до тех пор, пока только один клиент имеет доступ к файлу. Кэширование чтения и оптимизация упреждающего чтения являются безопасными при доступе к файлу или в режиме только чтения. Если несколько клиентов пытаются одновременно записывать в файл, то ничто не будет безопасным; поэтому все файловые операции должны управляться на сервере. SMB уведомляет обращающегося к файлу клиента об изменениях в режиме доступа, чтобы клиент мог использовать оптимальный метод доступа.
Приложения регистрируются для уведомления сервером об изменениях содержимого файла или каталога. Это позволяет приложению знать, когда обновить изображение, не требуя от него постоянно запрашивать сервер.
Существует почти столько же различных версий протокола SMB, сколько и поставщиков программного обеспечения. Каждая версия предоставляет дополнительные функции, свойства и средства. Чтобы справиться с этим изобилием, SMB выполняет так называемое согласование диалектов. Когда два компьютера вступают в контакт, они согласовывают диалект или версию SMB, которая будет использоваться при их общении. Это критический шаг в терминах как производительности, так и безошибочной коммуникации, так как каждый диалект может предоставлять различные сообщения, а также изменения в полях и семантике существующих сообщений других диалектов. В дополнение к обычным атрибутам файлов, например, времени создания и модификации, такими приложениями, как Word могут добавляться другие элементы, чтобы включить, например, имя автора или описание содержимого.
Протокол может поддерживать виртуальные тома, используя файловую систему, которая может охватывать несколько томов и серверов, но выглядеть при этом для клиентской машины как находящаяся на одном сервере. Файлы и каталоги поддерева могут перемещаться на другие серверы, имена при этом изменять не придется. В этом случае не нужно будет делать изменения на настольном компьютере, когда делаются изменения на сервере. Эти поддеревья могут также реплицироваться для выравнивания нагрузки и устойчивости к ошибкам. Когда клиент запрашивает файл, SMB использует направления для пересылки клиента на сервер, который содержит данные. Все это происходит за сценой без вмешательства клиента.
SMB позволяет клиенту преобразовывать имена серверов с помощью DNS, WINS, LMHOSTS или любого другого механизма преобразования имен. Это перемещает нас из неструктурированного, "плоского" пространства серверных имен в иерархически организованное пространство, поддерживающее более широкий диапазон взаимодействия. Чтобы сберечь полосу пропускания, SMB может пакетировать запросы в одном сообщении для минимизации задержки перемещения туда и обратно, даже когда более поздние запросы зависят от результатов предыдущих; он поддерживает также имена файлов в кодировке Unicode.
Обзор работы SM В
Для получения доступа к файлу на сервере клиентское приложение должно разобрать полное имя файла, чтобы определить имя сервера и относительное имя на этом сервере, разрешить имя сервера в адрес транспортировки, создать соединение с сервером и затем обменяться сообщениями. Если имя сервера было ранее разрешено, то оно может находиться в кэше, поэтому разрешение имени может не понадобиться. Кроме того, если предыдущее соединение все еще доступно, то новое соединение тогда не потребуется. Этот процесс повторяется множество раз в течение нормального рабочего дня. Если соединение простаивало в течение некоторого времени, оно будет разорвано.
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") дополнительно позволяет объединять в одно до шести сообщений в этой последовательности, поэтому в действительности в этой последовательности существуют только три перехода туда и обратно, и последнее из них клиент может сделать асинхронно.
Получив подходящий 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 байта для ответа. Посмотрим теперь на такую транзакцию на листинге ниже:
Использование LMHOSTS Начнем этот раздел с обсуждения двух способов, с помощью которых рабочая станция находит машину регистрации — с помощью широковещания и с помощью WINS. Существует и третий способ: использование файла lmhosts. Обратимся к этому файлу.
Используя запись #PRE, мы приказываем машине сделать предварительную загрузку записи в кэш имен NetBIOS. Она будет найдена, когда мы введем nbtstat -с, как показано на рис. Задав #DOM с именем домена, мы сообщаем машине, что это контроллер домена, и поэтому получаем дополнительные записи, такие как <1С>, также показанные на рис.
Используя файл LMHOSTS, мы ускоряем процесс регистрации, не выполняя при этом ни широковещательного запроса, ни запроса WINS, и, кроме того, сокращаем сетевой трафик. Стандартная проблема с реализацией LMHOSTS состоит в размещении его на всех клиентских машинах. Выход простой: поместите LMHOSTS в сценарий регистрации, и он сам скомпонуется на клиентские машины. На машине WIN NT он помещается в каталоге \\system32\drivers\etc. На машине Windows 9.x он помещается в каталог \\windows.
Нужно ли иметь больше контроллеров доменов? Обычно процесс регистрации происходит между 8 и 9 часами утра. Сколько реально необходимо иметь серверов регистрации? Помните, что добавление дополнительных резервных контроллеров доменов увеличивает сетевой трафик, как мы увидим в следующей главе. Это означает, что было бы плохой идеей сделать каждый сервер в сети резервным контроллером домена (что встречается достаточно часто).
Используя очень консервативную оценку, один контроллер домена может легко управлять 2000 пользователей. Если вернуться к нашему окну регистрации, можно видеть, что в течение одного часа (3600 секунд), происходит в среднем меньше двух регистрации в секунду (если запросы регистрации распределены равномерно). Что делать в такой ситуации? Прежде всего, необходимо использовать монитор производительности для создания протокола утренней деятельности по регистрации. Как можно видеть на рис. лучшим способом это сделать является создание протокола (log) монитора производительности и протокола использования памяти, процессора и серверного объекта. Для этого надо перейти во view\log и выбрать соответствующие режимы. В меню режимов выбирается тип протокола (log), а затем вводится имя протокола. Можно использовать, например, logon.log или добавить дату. Выберите хорошее место для размещения протокола (не в корне), интервал обновления и нажмите save (сохранить). Теперь необходимо добавить некоторые показатели, нажимая кнопку "плюс", как показано на рис.
Когда показатели будут добавлены, необходимо вернуться в меню режимов, выбрать тип протокола (log) и запустить протокол, как показано на рис. Это будет достаточно большой протокол, так как записи в нем появляются каждую секунду.
Если после создания протокола будут замечены периоды, когда происходит множество попыток регистрации в секунду, необходимо сделать несколько дополнительных изменений.
