FileTransfer Для обмена информации между пользователями, чаще всего используется локальная сеть или интернет. В локальных сетях большая часть информации передается через простую передачу файлов. Конечно есть системы документооборота, которые призваны упростить жизнь всем, включая сотрудников с их бумажной волокитой. Но данные решения требуют больших трудозатрат на внедрение, поэтому, на данный момент, чаще всего используется обычный файл-сервер. К тому же очень часты просто “файло-помойки” со всяким контентом. Обмен данными (в среде операционных систем Microsoft и не только) происходит по протоколу SMB.

В данном обзоре основной упор будет сделан на “новый” протокол SMB2, но так же будет встречаться упоминания об SMB1. Операционные системы использовались MS Windows 2008/2008R2.

Общие данные

Протокол SMB (Server Message Block) работает на 6-м и 7-м уровне модели OSI, т.е. на уровне представления и приложений. Используется для удаленного доступа к файлам, принтерам, Serial портам, а так же к другим сетевым взаимодействиям между узлами.

Модель OSI – абстрактная модель взаимодействия, состоит из 7-ми уровней, каждый из которых определяет сетевые функции. Все уровни независимы друг от друга. Эта независимость приводит к тому, что одному уровню не нужно знать как применяется второй уровень, необходимо только знать как с ним взаимодействовать. Это является одной из основных причин, почему данная модель стала так популярна.
OSI table

Протокол SMB работает как клиент-серверное приложение, т.е. когда клиент посылает запрос, то сервер отвечает ему. Часть раздела SMB протокола предназначена для доступа к файловой системе, к примеру, когда пользователь делает запрос к файл-серверу для получения файла. Другая же часть нацелена на использования межпроцессного взаимодействия Inter-process communication (IPC).

Хотя главной целью является общий доступ к файлам, SMB протокол предоставляет и другие возможности. В основном это реализации самого протокола, которые и делают его таким универсальным.

  1. Согласование диалектов
  2. Определение SMB серверов в сети
  3. Печать с использованием сети
  4. Доступ к файлам и директориям с аутентификацией
  5. Уведомление об изменении файлов и папок
  6. Поддержка юникода
  7. Оппортунистические блокировки

Немного об SMB2

Новая версия протокола SMB, SMB 2.0, была впервые внедрена на ОС MS Winodws Vista и Windows 2008 в 2006 году. Хотя протокол и проприетарный, но спецификация доступна на сайте MSDN, в отличие от SMB1, который долгое время был закрытым. В Windows 2008R2 и Windows 7 появилось небольшое обновление протокола до диалекта 2.10, в котором была увеличена общая сетевая производительность

Преимуществом SMB2 протокола можно считать снижение числа общения между узлами, что приводит к уменьшению зашумленности в сетях. Достигнуто было за счет значительного уменьшения числа команд. Уменьшение с более чем 100 до 19 штук.

  1. Согласование и аутентификация (NEGOTIATE, SESSION_SETUP, LOGOFF, TREE_CONNECT, TREE_DISCONNECT)
  2. Доступ к файлам и директориям (CANCEL, CHANGE_NOTIFY, CLOSE, CREATE, FLUSH, IOCTL, LOCK, QUERY_DIRECTORY, QUERY_INFO, READ, SET_INFO, WRITE)
  3. Другое (ECHO, OPLOCK_BREAK)

Так же добавлена возможность конвейерной отправки сообщений, что дало возможность “склеивать” несколько запросов в один. Данная технология называется pipelining, который позволяет отправлять дополнительные запросы, не дожидаясь ответа от предыдущего запроса. Таким образом уменьшается очередь команд, которые необходимо отправить серверу. Данное решение позволило сократить количество ожидающих запросов/ответов, что приводит к повышению производительности.

Так же SMB2 теперь может управлять потоком данных (credit-based flow control). Начиная передачу с небольшого “окна данных” сервер увеличивает его и автоматически подстраивается под среду. Данное решение позволяет сохранять большое количество передаваемых данных и лучше использовать пропускную способность сети.

Компаундирование (смешивание). В отличие от первой версии протокола, в SMB2 все команды стали более простые. В реализации SMB1 были сложные команды и субкоманды (специальные для каждого случая), которые были набором различных вариацией простых команд (LOCK_AND_READ или WRITE_AND_UNLOCK). Повторюсь, теперь все команды стали простыми, а взамен появилась возможность соединить несколько команд в произвольном порядке, как бы эмулировав старые сложные команды. Это привело к значительному уменьшению команд в SMB2.

Кэширование свойств папок и файлов.

Отказоустойчивое подключение, позволяет прозрачно вернуться в сеть, при кратковременной потере сетевого подключения. Спасает от необходимости устанавливать заново согласование в новой сессии.

Цифровая подпись теперь HMAC SHA-256

Улучшена масштабируемость для совместного использования файлов. Возможное количество одновременно подключенных клиентов и открытых файлов значительно увеличено.

Лучшая работа через NAT.

Расширение механизма (например, создать контекст или переменной смещения).

Поддержка symbolic link.

Оппортунистические блокировки

Оппортунистическая блокировка (Oplock) это механизм, позволяющий клиентам динамически изменять стратегию буферизации для данного файла или потока данных с целью увеличения производительности и уменьшения нагрузки на сетевое подключение. Производительность удаленных операций может быть увеличена, если клиент сможет локально буферизовать данные. Это позволяет отказаться от передачи данных/пакетов SMB при изменении данных.

К примеру: клиент не должен производить мгновенную запись изменений в файл, открытый по сети, если он знает, что никакой другой процесс не получит доступ к этому файлу. Кроме того, клиент может использовать упреждающую буферизацию данных. Так же использование оппортунистической блокировки позволяет приложениям получать прозрачный доступ к файлам в фоновом режиме.

Файловая система NTFS поддерживает несколько потоков данных к одному файлу. OpLock ориентированы на потоки. Это означает, что операции применяемы к данному открытому потоку, в целом не влияют на OpLock в другом потоке. Так же есть исключения, которые будут явно указаны.

Различают несколько видов оппортунистических блокировок:

  1. Level1 (исключающая): позволяет клиенту открыть поток для эксклюзивного доступа и позволяет клиентам выполнять буферизацию данных. Поддерживается кэширования записи и чтения.
  2. Level2 (общедоступная): позволяет создавать многочисленные читающие потоки. Поддерживает кэширование чтения.
  3. Пакетная (исключающая): дает возможность держать открытый поток на сервера, хотя локально был закрыт этот поток. Позволяет читать, писать и кэшировать дескрипторы.
  4. Фильтрующая (исключающая): позволяет приложения открывать и читать поток данных

Подпись SMB трафика (SMB Signing)

Подпись SMB трафика (SMB Signing) – это специальный механизм, обеспечивающий безопасность протокола SMB. Предназначен для повышения защиты передаваемого трафика и от атак в Man-In-The-Middle. Впервые SMB Signing появился в Windows NT 4.0 SP3 и Windows 98.

SMB Signing предоставляет два улучшения для протокола SMB:

  1. Взаимная аутентификация
  2. Аутентификация сообщений

Эти преимущества достигаются путем добавления в SMB пакет цифровой подписи.

Включение ж приводит к увеличению нагрузку, что может привести к снижению производительности передачи сетевого трафика на 10-15%.

Принцип работы:

  1. Клиент соединяется с сервером, делается запрос на использования SMB Signing
  2. Сервер отвечает на соединение, что можно использовать SMB Signing
  3. Клиент делает новый запрос, куда включает NTLM/NTLM v2 данные или билет от Kerberos и отправляет серверу. После данного этапа каждый последующий пакет имеет +1 к последовательности. Таким образом можно отслеживать, что нет вмешательства в пакеты отправляемые между клиентом и сервером
  4. Устанавливается номер последовательности равный 1. Генерируется цифровая подпись, путем сложения сессионного ключа (например, взятого из билета kerberos`a) и SMB пакета, и от него берется MD5/SHA-256 хэш сумма и помещается в поле SecuritySignature. После этого последовательность увеличивается на единицу, т.е. теперь равно двум (2)
  5. Клиент получает пакет и выполняет действия аналогичные п.4, только со своим сессионным ключом. Если значения совпадут, то пакет считается нормальным (иначе отбрасывается).
  6. После этого общение происходит с цифровой подписью, т.е. теперь пакеты проверяются.

Т.к. сессионный ключ в открытом виде не пересылается, то становится довольно проблематично, а главное в короткие сроки, отгадать этот самой ключ и подменять его. Таким вот простым образом достигается безопасность передачи трафика.

Так же есть реализация IPSec, в котором защищаются сами пакеты IP. IPSec может работать с любым вышестоящим (в модели OSI) протоколом, в том числе и с SMB. Отличает SMB Signing от IPSec уровни на которых происходит защита. В бонус IPSec: может не только подписывать трафик, но и защищать его от свободного снифинга. Достигается путем шифрации сессионным ключом.

Аутентификация в SMB

Существует два вида уровня доступа:

  1. User-Level – Этот уровень отвечает за аутентификации при подключении к серверу, т.е. когда клиент пытается подключиться к серверу он отсылается свои данные для аутентификации (возможно использование анонимного доступа, тогда любой имеет доступ к серверу). Если аутентификация прошла успешно, то клиента допускают до сервера (в обычной жизни это выглядит как отображение общедоступных папок в сетевом окружении, при заходе,например, \FF-srv01.inadmin.local). Иначе он просто не сможет подключиться до сервера.
  2. Share-level – Это уровень доступа, определяемые индивидуально для каждой общедоступной папки. Например, не все пользователи имеют доступ к “Папка1”, но при этом имеют доступ к папке “Общие Документы”.

Таким образом мы получаем, что сначала работает User-Level, а потом уже Share-Level, при условии, что клиент смог пройти аутентификацию на User-Level.

Inter-process communication

Inter-process communication (IPC) – набор способов обмена данными среди нескольких потоков в одном или нескольких процессах. IPC делятся на методы: обмена сообщений, синхронизации, разделяемой памяти и удаленных вызовов (RPC). Другими словами это механизм для облегчения связи и обмена данными между приложениями, которые могут быть запущены на одном или нескольких компьютерах, соединенных сетью, используются для обмена служебной информацией. Межпроцессорное взаимодействие можно разделить на наиболее крупные разделы:

  1. Сообщения: Pipes (каналы) и message queues (очереди сообщений)
  2. Shared Memory (Разделяемая память)
  3. Remote procedure calls (RPC, удаленный вызов процедур)
  4. Синхронизация: семафоры и блокирование
  5. Сетевое взаимодействие (API сокеты)

Давайте рассмотрим простой пример работы IPC. У нас есть несколько приложений, запущенных на одном ПК. И вот мы хотим реализовать возможность “общения” между этими программами. Как такое сделать? Использовать IPC.

Самим простым способом общения, можно считать, сообщения. К примеру, можно использовать WinAPI SendMessage, SendMessageEx, PostMessage. Сообщения бывают именованными и широковещательными. В качестве идентификатора для именованных сообщений можно использовать любой набор букв, главное что-бы он был уникальным. При файлов широковещательных сообщениях данные получают все приложения. Как можно понять, в данном примере обмен данными проходил в пределах одного ПК и сеть не использовалась. Обмен данными происходил между несколькими запущенными приложениям на одном ПК.

Зачем же нужен IPC? Ну допустим у вас есть два приложения, одно считает сумму. А вот второе эту сумму обрабатывает и делает сводные таблицы. Для передачи суммы из одной программы в другую и используем IPC.

Ярким представителем IPC в сетевой среде можно считать RPC (Remote Procedure Call). Данный протокол обеспечивает удаленное выполнение процедур.

Давайте рассмотрим состав RPC пакета:
RPC пакет
Как видно, протокол MSRPC работает непосредственно с SMB2 (об версиях SMB чуть ниже). На данном примере нам будет интересен так же UUID (Universally Unique IDentifier — Универсальный Уникальный Идентификатор), который является идентификатором RPC сервиса, запущенного на удаленном сервере, к которому мы хотим подключиться.

MSRPC over SMB – это одна из первых реализаций межпроцессорного взаимодействия, позволяющая использовать аутентификационные данные пользователя, когда он подключается к общедоступной папке SMB. MSRPC работает непосредственно с SMB, т.е. нет никакой прослойки между RPC и SMB.

Такие подключения называют именноваными каналами (named pipes). Реализованы эти каналы через драйвер npfs.sys. При использовании MSRPC over SMB необходимо использование endpoint mapper и well-known mapper, так же в заголовке необходимо указать индетификатор транспортного протокола (0x0F)

Примером именованных каналов (named pipes):

  • \pipe\samr – SAM (Security Account Manager)
  • \pipe\lsarpc – LSA (Local Security Manager)
  • \pipe\netlogon – Netlogon RPC server
  • \pipe\svcctl – SCM (Service Control Manager)
  • \pipe\eventlog – Eventlog Service
  • \pipe\srvsvc – Server service
  • \pipe\wkssvc – Workstation service

По RPC можно почитать книгу. Про RPC over SMB смотрите аппендикс I и L.

Для реализации данного функционала существует общедоступная, “расшаренная”, папка IPC$ у ОС Windows. Это не “настоящая”, в обычном понимании, общедоступная папка, а виртуальная. Используется как раз для взаимодействия между узлов через сеть.
IPC_Share

Более подробней про IPC.

Транспорт протокола SMB

Протокол SMB был основан в 80-х годах, и за свое существование многое изменилось. Рассматривать “дикости” вроде SMB Over IPX/SPX или SMB Over NetBEUI не будем. Это такие пережитки прошлого, когда каждый изобретал свой собственный велосипед, не совместимые с велосипедами других компаний. Гораздо важнее сосредоточиться на текущем положении дел, а оно такого:
SMB Protocol Table
Сейчас для транспорта используется связка TCP/IP, которая отлично себя зарекомендовала не только при использование SMB протоколом. А вот на сеансовом уровне будут различия. Долгое время использовался NetBIOS Over TCP/IP (NBT), но в последних версиях ОС MS Windows был сделан отказ от него и переход на SMB Over TCP/IP. Совместимость новых операционных систем со старыми протоколами – есть. О реализации согласований протоколов чуть позже.

В нашем случае, т.е. по состоянию дел на текущий момент, есть два варианта транспорта:

NetBIOS Over TCP/IP:

NetBIOS протокол работает на сеансовом уровне модели OSI. Решает задачи:

  1. Регистрация сетевых имен

  2. Установление сессий

  3. Установление надежных соединений для передачи данных (TCP)

  4. Установление ненадежных соединений для передачи данных (UDP)

Вероятно вы заметили, что функционал дублирует задачи DNS. Это верно NetBIOS изначально был разработан, когда технологии DNS не было. Поэтому от данного протокола, NBT, и отказываются в использовании.

Используемые порты:

  1. UDP 137 – Name managment.

  2. UDP 138 – Datagram traffic.

  3. TCP 139 – Session traffic

SMB Over TCP

  1. TCP/UDP 445 – Session traffic. Сессионный трафик, передача файлов, использование принтеров и прочее.

Протокол специально разработан для выполнении одной задачи, а именно связки SMB и TCP/IP.

Довольно часто SMB винят в создании большого количества широковещательного (broadcast) трафика. Но на самом деле причина кроется не в SMB, а в NBT, который он использует. Протоколом по умолчанию NBT был в Windows NT, но к Windows 2000 был сделан отказ от реализации разрешения имен на основе WINS серверов. Стандартом стал DNS. Таким образом NBT стал особняком, который дублировал задачи. И в последних версиях ОС уже по умолчанию используется SMB over TCP/IP.

Есть так же еще одна неприятная особенность, точнее наследие прошлого. Операционная система довольно долго развивается, так же есть много других продуктов (Exchange, Sharepoint и прочих сервисов в самой ОС), которые могут использовать NetBIOS API для задач с разрешением имен. Таким образом полный отказ от NetBIOS может привести к неожиданным последствиям при разрешении сетевых имен.

К преимуществам использования протокола SMB Over TCP/IP можно отнести:

  1. Упрощение транспорта трафика SMB

  2. Отказа от использования WINS и широковещательного трафика NetBIOS в сети.

  3. Стандартизация разрешения имен, все запросы разрешаются через DNS сервер.

Для отключения NBT:

  1. Необходимо зайти в сетевое окружение
  2. Выбрать сетевой адаптер “Подключение по локальной сети”, зайти в свойства
  3. Выбрать Internet Protocol (TCP/IP) и зайти в свойства
  4. Перейти на вкладку Advanced
  5. Выбрать Disable NetBIOS over TCP/IP
    Disable NBT

Для просмотра интерфейсов, на которых есть NBT можно воспользоваться командой Net config redirector

Computer name \FF-SRV01 Full Computer name FF-SRV01.InAdmin.Local User name Administrator Workstation active on NetBT_Tcpip_{860BDBCB-FF6A-4AC7-B5BC-981A00AA8AE8} (00155DF83106) Software version Windows Server 2008 R2 Standard Workstation domain INADMIN Workstation Domain DNS Name InAdmin.Local Logon domain FF-SRV01 COM Open Timeout (sec) 0 COM Send Count (byte) 16 COM Send Timeout (msec) 250 The command completed successfully.

Согласование транспортных протоколов (NetBIOS Over TCP/IP vs SMB Over TCP/IP)

Одним из самых главных этапов при установлении соединения является согласование протоколов. Алгоритм следующий:

NBT or SMB TCP

  1. Попытка установить TCP сессию на 445 порту (порт, на котором работает SMB Over TCP/IP).
  2. Если удалось поднять сессию, то поднимается SMB через SMB Over TCP/IP
  3. Если сессия на 445 порту не установилась, то делается попытка установить связь через 139 порт (порт, на котором работает NetBIOS Over TCP/IP).
  4. Если сессия установилась, то поднимается SMB через NetBIOS Over TCP/IP

Таким образом предпочтение при подключение имеет более новый протокол, т.е. SMB Over TCP/IP. Если же сессия не установилась, то делается попытка отступить на более старый протокол взаимодействия. В случае, когда п.1 и п.3 не завершатся установлением сессии, то попытки подключения прекращаются и выдается ошибка подключения.

Диалекты

По причине того, что SMB протокол старый и развивается достаточно долго,а следовательно и функциональность наращивается, то возможности взаимодействия сетевых узлов необходимо согласовать. Иначе будет ситуация когда узлы не понимают друг друга. Каждый этап развития характеризуется своим диалектом (или стандартным пакетом). Каждый диалект характеризуется строкой:

PC NETWORK PROGRAM 1.0 Оригинальная версия SMB, разработанная IBM. MICROSOFT NETWORKS 1.03 Добавлены новые команды MICROSOFT NETWORKS 3.0 Аналогичен LanMan1.0, но ошибки должны транслироваться в DOS LANMAN1.0 Полный протокол LANMAN1.0 LM1.2X002 Полный протокол LANMAN2.0 DOS LM1.2X002 Аналогичен LM1.2X002 только с трансляцией ошибок в DOS LANMAN2.1 Расширение протокола LANMAN2.0 DOS LANMAN2.1 Аналогичен LANMAN2.1 только с трансляцией ошибок в DOS Windows for Workgroups 3.1a Очередное расширение протокола NT LM 0.12 Расширение протокола для работы в NT системах SMB 2.002 Новый протокол, много полезных дополнений, уменьшено кол-во команд SMB 2.10 Расширение SMB 2.002, увеличена производительность

Процедура согласования диалектов

Итак, вторым этапом согласования является: согласование диалектов. Рассмотрим пример согласования диалектов между MS Windows 2008 R2 серверами (SMB 2.10):

SMB Dialects

  1. Клиент (ОС, которой необходимо получить доступ до другого сервера) отсылает запрос, содержащий поддерживаемый им диалекты. Dialect: PC NETWORK PROGRAM 1.0 Dialect: LANMAN1.0 Dialect: Windows for Workgroups 3.1a Dialect: LM1.2X002 Dialect: LANMAN2.1 Dialect: NT LM 0.12 Dialect: SMB 2.002 Dialect: SMB 2.???
  2. Сервер принимает пакет с запросом на согласование диалектов. Находит в нем строку “SMB 2.???” среди предложенных диалектов. И формирует ответ для клиента, где устанавливает значение: DialectRevision: 767 (0x2FF)
  3. Клиент получает ответ от сервера и формирует новый запрос, в который включает поддерживаемые диалекты для SMB2 Dialects: 514 (0x202) Dialects: 528 (0x210)
  4. Сервер получает новый запрос. Находит в нем, что поддерживается 0×0210 и формирует ответ для клиента, установив DialectRevision: 528 (0x210)

Рассмотрим второй пример. На этот раз согласование диалектов между OC Windows 2008. В отличии от первого случая, тут согласование пройдет более просто, и будет выбран диалект SMB 2.002:

SMB Dialects negociate 2.002

  1. Клиент (ОС, которой необходимо получить доступ до другого сервера) отсылает запрос, содержащий поддерживаемый им диалекты. Dialect: PC NETWORK PROGRAM 1.0 Dialect: LANMAN1.0 Dialect: Windows for Workgroups 3.1a Dialect: LM1.2X002 Dialect: LANMAN2.1 Dialect: NT LM 0.12 Dialect: SMB 2.002
  2. Сервер получает запрос и формирует ответ для клиента, установив DialectRevision: 0x0202

Процедура установления сессии

Следующим этапом будет установление сессии. На данном этапе создается запрос SESSION_SETUP Request и отсылается от клиента к серверу для установления аутентификационной сессии.

  1. Клиент запрашивает GSS (Generic Security Service) на выдачу аутентификационного токена и отправляет его в SESSION_SETUP Request: Command: SESSION SETUP SecurityMode: Signing Enabled SecurityBufferOffset: 88 (0x58) SecurityBufferLength: 74 (0x4A) Buffer: (74 bytes)
  2. Сервер получает токен с GSS. Сервер формирует ответ установив Status=STATUS_MORE_PROCESSING_REQUIRED и помещает токен, полученный от GSS Status: STATUS_MORE_PROCESSING_REQUIRED Command: SESSION SETUP TreeId: 0 (0x0) SessionId: 4406368010297 (0x401F0000039) SessionFlags: Normal session SecurityBufferOffset: 72 (0x48) SecurityBufferLength: 219 (0xDB) Buffer: (219 bytes)
  3. Клиент получает токен с GSS и отсылает SMB2 SESSION_SETUP Request, извлекая токен из GSS и SessionID из предыдущего ответа Status: STATUS_SUCCESS Command: SESSION SETUP SessionId: 4406368010297 (0x401F0000039) SecurityMode: Signing Enabled SecurityBufferOffset: 88 (0x58) SecurityBufferLength: 245 (0xF5) Buffer: (245 bytes)
  4. Сервер принимает GSS и возвращает, что сессия установлена: Status: STATUS_SUCCESS Command: SESSION SETUP SessionId: 4406368010297 (0x401F0000039) SecurityBufferOffset: 72 (0x48) SecurityBufferLength: 29 (0x1D) Buffer: (29 bytes)

Получение доступа к папкам

  1. Для завершения аутентификации, клиент посылает запрос, используя для этого SessionID. Status: STATUS_SUCCESS Command: TREE CONNECT МessageId: 3 (0x3) TreeId: 0 (0x0) SessionId: 4406368010297 (0x401F0000039) Share: 2.16.0.2IPC$
  2. Сервер, при получении запроса, формирует ответ со следующими полями: Status: STATUS_SUCCESS MessageId: 3 (0x3) SessionId: 4406368010297 (0x401F0000039) TreeId: 1 (0x1)

Последующие операции (такие как CREATE, WRITE, READ) будут использовать SessionID и TreeID

Чтение файла

Т.к. сессия у нас уже установлена и параметры мы можем использовать, то давайте рассмотрим, к примеру открытие файлов по сети

  1. Клиент отправляет SMB2 Create Request для файла TestSMB.txt Status: STATUS_SUCCESS Command: CREATE MessageId: 10 (0xA) ProcessId: 65279 (0xFEFF) TreeId: 1 (0x1) SessionId: 4406368010297 (0x401F0000039) RequestedOplockLevel: 9 (0x9) DesiredAccess: 0x00120089 read: (...............................1) Read Data readEA: (............................1...) Read EA FileRead: (........................1.......) File Read Attributes ShareAccess: Shared for Read/Write CreateDisposition: Open Name: TestSMB.txt
  2. Сервер формирует ответ SMB2 Create Response Status: STATUS_SUCCESS Command: CREATE Flags: 1 (0x1) ServerToRedir:...............................1 Server to Client MessageId: 10 (0xA) ProcessId: 65279 (0xFEFF) TreeId: 1 (0x1) SessionId: 4406368010297 (0x401F0000039) CreateAction: 1 (0x1) CreationTime: 127972992877715232 (0x1C6A6C24D51DF20) LastAccessTime: 127972992923579232 (0x1C6A6C2500DB360) LastWriteTime: 127972992923579232 (0x1C6A6C2500DB360) ChangeTime: 127972992923579232 (0x1C6A6C2500DB360) AllocationSize: 104 (0x68) EndOfFile: 98 (0x62) Volatile: -4294967287 (0xFFFFFFFF00000009)
  3. Клиент отправляет запрос на чтение данных из файла SMB2 Read Request Smb2: C READ 0x62 bytes from offset 0 (0x0) Status: STATUS_SUCCESS Command: READ MessageId: 11 (0xB) ProcessId: 65279 (0xFEFF)TreeId: 1 (0x1) SessionId: 4406368010297 (0x401F0000039) CRead: Size: 49 (0x31) Padding: 80 (0x50) DataLength: 98 (0x62) Offset: 0 (0x0) Fid: Persistent: 17 (0x11) Volatile: -4294967287 (0xFFFFFFFF00000009)
  4. Сервер отвечает ответом SMB2 READ Response c данными из файла Smb2: R READ 0x62 bytes read Status: STATUS_SUCCESS Command: READ Flags: 1 (0x1) ServerToRedir:...............................1 Server to Client MessageId: 11 (0xB) ProcessId: 65279 (0xFEFF) TreeId: 1 (0x1) SessionId: 4406368010297 (0x401F0000039) RRead: Size: 17 (0x11) DataOffset: 80 (0x50) Reserved: 0 (0x0) DataLength: 98 (0x62) DataRemaining: 0 (0x0) Reserved2: 0 (0x0) Data: (98 bytes)
  5. Клиент отправляет SMB2 CLOSE Request для закрытия файла Smb2: C CLOSE FID= SMB2Header: Status: STATUS_SUCCESS Command: CLOSE MessageId: 12 (0xC) ProcessId: 65279 (0xFEFF) TreeId: 1 (0x1) SessionId: 4406368010297 (0x401F0000039) CClose: Size: 24 (0x18) Flags: 1 (0x1) <- Post-query attributes Reserved: 0 (0x0) Fid: Persistent: 9 (0x9) Volatile: -4294967295 (0xFFFFFFFF00000001)
  6. Сервер отвечает SMB2 Close Response сообщая об удачном закрытии файла Smb2: R CLOSE Status: STATUS_SUCCESS Command: CLOSE Flags: 1 (0x1) ServerToRedir:...............................1 Server to Client MessageId: 12 (0xC) ProcessId: 65279 (0xFEFF) TreeId: 5 (0x5) SessionId: 4398046511121 (0x40000000011) RClose: Size: 60 (0x3C) Flags: 1 (0x1) Reserved: 0 (0x0) CreationTime: 127972990708847232 (0x1C6A6C1CC0B9280) LastAccessTime: 127972993090343232 (0x1C6A6C259FE5140) LastWriteTime: 127972992877715232 (0x1C6A6C24D51DF20) ChangeTime: 127972992877715232 (0x1C6A6C24D51DF20) AllocationSize: 0 (0x0) EndOfFile: 0 (0x0)

Сравнение производительности протоколов SMB и SMB2

А теперь давайте посмотри в жизни “действительную” разницу при использовании SMB2. Для этого был собран тестовый стенд, в котором приняли участия MS Windows 7, Windows 2008R2, Windows 2003.

Как уже упоминалось немного выше, что новый версия протокола SMB значительно лучше работает на большом количестве мелких файлов и на плохих соединениях, с летентностью, к примеру, 200 мс.

Первый случай, копирования по сети с Windows 2008 на Windows 2008 и Windows 2003.

original

Первый пик, это при копировании по протоколу SMB2, второй же пик, сплошная, это загрузка по SMB1. Как видно, при использовании нового протокола утилизация канала используется на всю мощность. По оси Х идет время. Сразу можно увидеть, какой из протоколов быстрей “переваривает” информацию.

Второй ж пример будет для канала с большой латентностью. Здесь раскрываются возможности технологии pipelining.

perf2

На данном примере видно, что время передачи и загрузка канала еще больше разнится. Позволяя SMB2 просто разрывать в клочья SMB1.

А теперь немного статистики. Для этого было взято порядка 7500 файлов, общим размером в 150 мб. Файлы были разного размера: от 1 кб до 10 мб. Так же эти файлы были сжаты в один архив, для проверки работы на одном файле. Тестовый стенд представлял в тот же набор операционных систем, но в этот раз в тесте принял участие еще и канал Wi-Fi. Латентность сети была порядка 1-2 мс.

Общая схема была такой:

Speed_topology

Первый тест производился на большом количестве файлов. Копировалось с Windows 7 на сервера под управлением Windows 2008R2 и Windows 2003.

По оси X время в секундах.

Speed_mn

Видно, что при использовании SMB2, скорость копирования выше. Преимущество практически не зависит от типа канала: Wi-Fi или Ethernet.

Второй тест производился на одном файле, полученным путем архивации этих же файлов без сжатия. Чем было достигнут тот же размер данных, но в одном файле.

Speed_one

В данном случае преимущество у протокола SMB2 теряется. Скорости копирования идентичны. Так же можно сравнить общие скорости копирования большого количества файлов и одного файла, при одном и том же размере, то скорость обработки одного файла будет больше, т.к. необходимо меньше согласующих команд пересылать между узлами. Тут даже не спасет технологичный SMB2 протокол.

Заключение

На этом завершим краткий обзор “нового” протокола SMB. Как вы уже поняли, его использование позволяет ускорить процесс передачи данных между узлами в сети. Так же к плюсам можно отнести отказ от использования NBT в качестве транспортного протокола. Уменьшена зашумленность сетевого канала.

Новые ОС Microsoft уже во всю используют его, что очень радует.

Баканов Денис

MCSE+S; MCITP EA

Оригинал статьи


Источник: http://itband.ru/2010/06/in-smb-protocol/



Рекомендуем посмотреть ещё:


Закрыть ... [X]

Что такое файл и расширение файла? Как создать и открыть


Как сделать видно расширение файлов Как сделать видно расширение файлов Как сделать видно расширение файлов Как сделать видно расширение файлов Как сделать видно расширение файлов Как сделать видно расширение файлов Как сделать видно расширение файлов Как сделать видно расширение файлов