Главная Networks, Windows, Без рубрики, Новое Протокол SMB. Что же у него внутри?
  • Протокол SMB. Что же у него внутри?

    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: \172.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

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

Комментарии

  1. Полезная статья. Наконец для себя узнал подробности развития SMB в Windows 6.x.

    В таблице Диалекты в первой строчке непонятное окончание “Оригинальная версия SMB, разработанная IBM. Не”

  2. Поправил, даже не знаю откуда взялось.

  3. почитать про всё это можно…

    неплохо бы писать про практическое применение, личный опыт, применения этой самой теории

    а статья понравились, хорошо написано +5

  4. А, вот, у Александра Шаповала (см. http://www.techdays.ru/videos/1225.html), скорость копирования одного большого файла при использовании «SMB v1 SMB v2» и «SMB v2 SMB v2» отличается в 3-4 раза (в пользу SMB v2, разумеется).

    В чем подвох?

    Ну и в догонку: помимо презентации от Александра Шаповала дам ссылку на презентацию от Адрея Бешкова и его блог:

    http://ftp.w2a.ru/%d0%a1%d0%b5%d…5%d0%be/SMB2.mp4

    (эту презентацию мне почему-то не удалось обнаружить на techdays.ru)

    blogs.technet.com/b/abesh…/03/3196454.aspx

  5. Шикарная статья. Огромное спасибо автору.

  6. 2shs
    Всегда приятно, когда есть такие читатели “с пристрастием”. Спасибо за предложения об изменениях.
    Так же считаю хорошо, что большинство ошибок – это по сути “опечатки”. Тем более в техническом тексте.

    А вообще, хорошим тоном было бы отправить это все в личку и не плодить много-много сообщений подряд. Ну или хотя бы выложить в одном комментарии. Это ведь не сложно же?
    [upd]
    Склеил все ваши комментарии в один.

    “В чем подвох?”
    Честно сказать не знаю, но вот так прошел тест. каждое копирование делалось 3 раза и вычислялось среднее значение. Почему на одном файле SMB1=SMB2 это лучше обратиться к разработчикам. Я лишь провел свой тест.

  7. Скорее всего потому, что кроме SMBv2 там еще работал механизм уменьшения пакетов поддтверждения (включается на “стабильных и быстрых каналах”, если я правльно понимаю – на гигабите).

  8. Можно попробовать собрать стенд, и протестировать 10mbit/100mbit/1Gbit/10Gbit

    smbv1 против smbv2
    на кучке файлов и на одном большом.

  9. >Так же считаю хорошо, что большинство ошибок — это по сути «опечатки». Тем более в техническом тексте.

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

    >А вообще, хорошим тоном было бы отправить это все в личку и не плодить много-много сообщений подряд.
    Честно говоря, не увидел (и сейчас не вижу) возможности отправить что-либо в личку. Ткните носом, плизс, как это сделать?

    >Ну или хотя бы выложить в одном комментарии. Это ведь не сложно же?
    Нет, не сложно, просто коментировал по мере чтения. Сам бы рад был объединить в один пост, но, IIUC, движок этого сайта не дает мне такой возможности. Даже отредактировать или удалить свой коментарий не могу 🙁

    >Склеил все ваши комментарии в один.
    Спасибо.
    Думаю, что комментарии про опечатки можно и вовсе удалить, как неинформативные, им действительно место в личке. Если у вас есть такая возможность и нет возражений, то сделайте это, не сочтите за труд.

    ЗЫ Этот коментарий так же можно удалить 😉

  10. Просто нужно зарегистрироваться на сайте:
    http://itband.ru/wp-login.php?action=register
    тогда появится возможность править комментарии.

  11. >Скорее всего потому, что кроме SMBv2 там еще работал механизм уменьшения пакетов поддтверждения (включается на «стабильных и быстрых каналах», если я правльно понимаю — на гигабите).
    На сколько я понимаю, SMB2 болжен выигрывать с большим отрывом на плохих каналах, где ошибки передачи имеют место быть. Посему, тестировать нужно именно на хорошем канале, т.к. результтат для плохого – очевиден.

    >Можно попробовать собрать стенд, и протестировать 10mbit/100mbit/1Gbit/10Gbit
    smbv1 против smbv2
    на кучке файлов и на одном большом.

    Тут, еще не совсем понятно, что считать большим файлом? Большой относительно чего? Так, Бешков в своей презентации демонстрирует трехкратное превосходство в скорости SMB2 при копировании файла в 42 mb, называя его маленьким файлом.

  12. >>Для этого было взято порядка 7500 файлов, общим размером в 150 мб. Файлы >>были разного размера: от 1 кб до 10 мб. Так же эти файлы были сжаты в один >>архив, для проверки работы на одном файле.

    т.е. общий объем для теста был 150 мб.

  13. >т.е. общий объем для теста был 150 мб
    Да, вы написали в статье, что файл был размером 150 мб. В том то и дело, что это всего в 4 раза больше “маленького” файла (42 мб), эксперименты на котором проводил Бешков.
    Я к чему, собственно: вполне, возможно, что SMB2 дествительно себя хуже ведет на относительно больших файлах. Но, хотелось бы понять, где эта граница (большой/маленький) для SMB2 находится, и на зависит ли она от аппаратных характеристик стенда (память, процессор)?

  14. Думаю, сделать отдельный тест.
    Взять, например, файлы 5-50-100-250-500-1000-2000 мб, и тестировать их на разной скорости и на разных протоколах.

    Думаю интересно должно получиться 🙂

  15. >Думаю интересно должно получиться
    С нетерпением буду ждать результатов 😉

  16. Так провели в итоге тест или нет ?

  17. Провел, результаты интересные: http://www.inadmin.ru/2010/07/01/smbv1-vs-smbv2/

  18. Если даже пользователь работает через VPN, но подключение или очень медленное, или постоянно обрывается – проще работать с автономной копией и синхронизировать изменения, чем пытаться что-то сделать на сервере.

  19. В статье есть несколько неточностей:
    1) SMB не занимается поиском серверов. Этим занимается BROWSER, LLMNR, домен и прочие отдельные сущности.
    2) SMB 2 не включает в себя никакой особой реализации IPC. Со стороны SMB единственное отличие между работой с именованным каналом и обычным файлом – это особая шара $IPC. Дальше идут стандартные CreateFile, ReadFile, WriteFile,DeviceIoControl. Все перечисленные возможности (IPC, принтеры и тд) реализуются через DCE RPC Over NamedPipe. Так что говорить, что SMB напрямую реализует удаленную печать тоже самое, что говорить что SMB напрямую реализует домен или TFS. Соответственно DCE RPC вызов можно сделать локально вообще без реализации SMB, а собственный нестандартизированный именованный канал можно пробросить через SMB.
    3) Тестировать скорости при коннекте Vista-Xp и Vista-Vista не корректно, т.к. начиная с Vista кроме SMB была огромная куча улучшений (сеть, файловые системы, управление памятью), которые очень сильно повлияют на тест. Нужно тестировать Vista-Vista с принудительным понижением до SMB1.
    Также отвечу на вышезаданный вопрос про копирование большого файла. Единственным отличием в потоке данных SMB1 и SMB2 при копировании большого файла является максимальный размер куска передаваемых данных. В SMB 1 он подрезан до 32к, SMB2 обычно оперирует 64к блоками, но может передавать и большие. Так что скорость на винтах которым пофигу размер блока должна быть почти одинаковой. Для маленьких файлов разница в скорости объясняется тем, что SMB1 спрашивал много лишней инфы разными доп запросами при открытии файла. При разработке SMB2 всю эту инфу добавили в конец ответа про открытие файла.

    PS. Говорю не понаслышке, приходилось реализовывать обе версии протокола.