Протокол SMB, соответствующий прикладному и представительному уровням модели OSI, регламентирует взаимодействие рабочей станции с сервером. В функции SMB входят следующие операции:
Управление сессиями. Создание и разрыв логического канала между рабочей станцией и сетевыми ресурсами файлового сервера.
Файловый доступ. Рабочая станция может обратиться к файл-серверу с запросами на создание и удаление каталогов, создание, открытие и закрытие файлов, чтение и запись в файлы, переименование и удаление файлов, поиск файлов, получение и установку файловых атрибутов, блокирование записей.
Сервис печати. Рабочая станция может ставить файлы в очередь для печати на сервере и получать информацию об очереди печати.
Сервис сообщений. SMB поддерживает простую передачу сообщений со следующими функциями: послать простое сообщение; послать широковещательное сообщение; послать начало блока сообщений; послать текст блока сообщений; послать конец блока сообщений; переслать имя пользователя; отменить пересылку; получить имя машины.
На высоком уровне представление протокола SMB довольно просто. Он включает в себя все возможные операции для работы с файлами и принтерами, которыми вы пользуетесь на обычном компьютере, например :
создание и удаление директорий;
посылка на печать и отмена печати на принтере.
Все эти операции могут быть помещены в сообщение SMB и переданы к и от сервера. Название SMB происходит от названия формата данных √ разновидности стандартных системных вызовов DOS к различным структурам данных или Server Message Blocks, адаптированная для передачи данных другому компьютеру по сети.
Richard Shape из команды разработчиков Samba дал определение протоколу SMB как запрос-ответ. На практике это означает, что клиент посылает запрос SMB к серверу и сервер отвечает сообщением на этот запрос. Сервер редко формирует ответы, которые не относятся к клиенту.
Сообщение SMB не так сложно. Рассмотрим структуру сообщения. Его можно разделить на две части: заголовок фиксированного размера и поле команды, размер которой меняется динамически в зависимости от состава сообщения.
Таблица 3.1 показывает формат заголовка SMB. Команды SMB не обязательно должны заполнять все поля заголовка SMB. Например, когда клиент впервые пытается соединиться с сервером, то значение идентификатора дерева (TID) пусто √ он появляется после успешного соединения и нулевое значение TID (0xFFFF) устанавливается в соответствующее поле заголовка. Другие поля могут также устанавливаться в ноль, когда не используются.
Значения полей заголовка SMB перечислены в Таблице 3.1.
Таблица 3.1 Поля заголовка SMB
| Поле | Размер (байты) | Описание |
| 0xFF 'SMB' | 1 | Идентификатор протокола |
| COM | 1 | Код команды, от 0x00 до 0xFF |
| RCLS | 1 | Класс ошибки |
| REH | 1 | Зарезервирован |
| ERR | 2 | Код ошибки |
| REB | 1 | Зарезервирован |
| RES | 14 | Зарезервирован |
| TID | 2 | ID Дерева; уникальное ID для ресурса, исп. клиентом |
| PID | 2 | ID Вызывающего процесса |
| UID | 2 | Идентификатор пользователя |
| MID | 2 | Мультиплексный ID; используемый для передачи запросов внутри процесса |
После того, как заголовок представлен определенным числом байт, происходит выполнение команды SMB. Любая команда, например такая, как открыть файл (ID поля COM: SMBopen ) или получить запрос на печать (SMBsplretq), имеет свой набор параметров и данные. Как и в поле заголовка SMB, здесь также могут быть заполнены не все командные поля, все зависит от команды. Например, команда GetServerAttributes (SMBdskattr) устанавливает поля WCT BCC в 0. Поля командных сегментов показаны в Таблице 3.2.
Таблица 3.2 - Содержание команды SMB
| Поле | Размер в байтах | Описание |
| WCT | 1 | Счетчик слов |
| VWV | Переменная | Параметр слов (размер, определяемый WCT) |
| BCC | 2 | Параметр счетчика байт |
| DATA | Переменная | Данные (размер, определяемый BCC) |
Служба Доменных Имен (Domain Name System) предназначена для того, чтобы машины, работающие в Internet, могли по доменному имени узнать IP-адрес нужной им машины, а также некоторую другую информацию; а по IP-номеру могли узнать доменное имя машины.
Служба Доменных Имен была разработана для именования машин в глобальной сети. Основной особенностью глобальной сети является распределенное администрирование, когда один администратор физически не может уследить за выделением имен. Поэтому Служба Доменных Имен функционирует на принципе делегирования полномочий. Каждая машина либо знает ответ на вопрос, либо знает кого спросить. При правильном функционировании система замкнута, т.е. если запрошенная информация имеется у кого-либо, то она будет найдена и сообщена клиенту, либо, если вопрос не имеет ответа, клиент получит сообщение о невозможности получения ответа на вопрос.
Каждый клиент знает своего сервера; обычно указывается не один, а несколько серверов - если первый не отвечает, клиент обращается ко второму и так далее до исчерпания списка. В принципе неважно, к какому серверу обращаться - они дают (должны давать при правильном функционировании) одинаковые ответы на любой запрос. Поэтому для ускорения работы обычно указывают ближайший. Следует помнить, что на одной машине могут функционировать одновременно Name-сервер и программы-клиенты; поэтому если на машине запущен Name-сервер, то в качестве Name-сервера на ней должен быть прописан "я сам".
Имеется некий домен верхнего уровня, обозначаемый точкой: ".". Имеется девять серверов (по крайней мере на моем Name-сервере записано столько), которые отвечают за эту зону. Они не знают ни одного доменного имени - они только авторизуют серверы верхних зон. Серверы верхних зон тоже гнушаются хранить информацию о конкретных машинах и передают это право нижележащим серверам. Тут уже появляются первые упоминания о конкретных машинах, равно как и происходит авторизация нижележащих серверов.
Очень редко используются доменные имена из двух сегментов; имена из трех и четырех сегментов составляют подавляющую долю всех имен Internet; имена из пяти сегментов встречаются довольно редко.
Допустим, клиент запросил адрес "www.организация.город.страна". Поиск информации по доменному имени происходит следующим образом:
Клиент спрашивает своего сервера.
Если тот является сервером данной зоны, то ответит, на чем все заканчивается.
Сервер спрашивает корневой сервер.
Тот не может ответить, потому что не знает; зато знает, какой сервер отвечают за зону "страна".
Сервер зоны "страна" тоже не может ответить, но знает, что нужно спросить сервер зоны "город.страна".
Тот в свою очередь отсылает запрос серверу зоны "организация.город.страна", который сообщит нужную информацию.
Это приближенная модель, которая тем не менее позволяет представить работу системы DNS.
Однако эту стройную картину искажают системы кэширования и вторичных серверов. Дело в том, что получив ответ на свой вопрос, DNS-сервер получает также некоторое число, которое говорит ему о том, по истечении какого времени эта информация должна считаться устаревшей. Таким образом, все серверы, участвовавшие в поиске ответа на вопрос, заданный клиентом, могут (и скорее всего будут) помнить как ответ на заданный вопрос, так и путь, по которому шел поиск. При следующих запросах, имеющих общую правую часть с недавно сделанными запросами, поиск будет упрощен (ускорен).
Следует обратить внимание на сходство, различие и взаимодействие систем DNS и IP-маршрутизации. Как и IP-маршрутизация, DNS работает по принципу делегирования полномочий, но выделение доменных имен совершенно не зависит от выделения IP-адресов. Для примера рассмотрим домен freebsd.org. Это - домен организации, занимающейся распространением операционной системы FreeBSD Unix. FTP-сервер, содержащий дистрибутив операционной системы и множества утилит для нее, имеет копии в нескольких десятках стран.
Политика и стратегия назначения имен
Имена зон условно можно разделить на "организационные" и "географические". В высшей зоне зарегистрированы следующие "организационные" зоны:
com - commercial (коммерческие);
edu - educational (образовательные);
gov - goverment (правительственные);
mil - military (военные);
net - network (организации, обеспечивающие работу сети);
org - organization (некоммерческие организации).
Система NFS обеспечивает разнообразным приложениям на клиентских хостах прозрачный доступ к файловым системам и файлам на сервере. Слово доступ здесь означает, что становятся доступными разнообразные операции с отдельными частями содержимого файлов (а не только копирование файлов целиком с помощью специализированного клиента подобно тому, как это происходит при пересылке файлов в FTP). Предоставляемый доступ является прозрачным в том смысле, что каждое приложение на клиентской машине, работающее с локальными файлами, точно так же работает через NFS и с файлами на удаленной системе, причем без каких-либо изменений в коде этого приложения.
Система NFS построена по принципу клиент-сервер и базируется на RPC фирмы Sun Microsystems. NFS-клиент получает доступ к файлам на хосте NFS-сервера, посылая ему RPC-запросы. С принципиальной точки зрения NFS-клиент и NFS-сервер могли бы быть обычными пользовательскими процессами, взаимодействующими через RPC, однако из практических соображений NFS обычно реализуют иначе, и на это есть две причины. С одной стороны, как было сказано, доступ к файлам с помощью NFS должен быть прозрачным для любых приложений на стороне клиента. Следовательно, все обеспечивающие удаленную работу с файлами NFS-запросы с клиентской машины должны автоматически генерироваться операционной системой. С другой стороны, высокая производительность NFS-сервера достигается, только если он функционирует как часть операционной системы на его хосте. Если бы NFS-сервер был реализован как пользовательский процесс, то обращения сервера с запросом к файловой системе вместе с записываемыми и считываемыми данными в каждой транзакции пересекали бы границу между ядром и этим пользовательским процессом, что неизбежно повлекло бы значительные издержки и резко снизило производительность. Поэтому NFS-серверы реализуют в коде ядра.