Иерархический подход к описанию процессов сетевого взаимодействия позволяет разделить функции уровней между различными модулями сетевого программного обеспечения и сетевого оборудования. При этом решение круга задач каждого уровня описывается с помощью соответствующих протоколов. Набор протоколов различных уровней, достаточный для организации взаимодействия в сети, принято называть стеком.
В различных телекоммуникационных сетях и в различных сетевых операционных системах используются различные стеки протоколов. Существование различных сетевых протоколов обусловлено целым рядом причин. Каждый из этих протоколов имеет свою область применения. Один протокол может хорошо работать с сетью определенного типа, но быть полностью непригодным для другой сети, которая, на первый взгляд, ничем не отличается от предыдущей. Есть, однако, несколько ключевых аспектов, которые касаются всех протоколов без исключения. Потребность в памяти, использование полосы пропускания, уровень функциональности, масштабируемость - все это очень важно.
Допустим, вам при работе в сети нужно только читать и записывать файлы, находящиеся на относительно небольшом файл-сервере. Это значит, что для вас основные критерии - скорость транспортировки и простота эксплуатации. Чтобы этого добиться, можно выбрать протокол, использующий память небольшого объема и не вызывающий дополнительных расходов ресурсов сети. В другой сети, к примеру, пользователям может потребоваться регистрация, для того чтобы получить доступ к хостам и предавать большие объемы данных. Для этих пользователей протокол, богатый функциональными возможностями, более важен, нежели требуемый для него объем памяти или производительность.
В сети Windows могут использоваться такие стеки протоколов, как NetBIOS/NetBEUI (Microsoft), IPX/SPX (Novell) и TCP/IP.
Стек протоколов TCP/IP представляет собой семейство протоколов, обеспечивающих соединение и совместное использование различных систем. Стек был разработан для работы в разнородных сетях. Протоколы стека отличаются высокой надежностью: они отвечают требованию обеспечения возможности работы узлов сети, уцелевших при ограниченном ядерном нападении. В настоящее время стек протоколов TCP/IP используется как для связи в сети Интернет, так и в локальных сетях.
В основу архитектуры TCP/IP была целенаправленно заложена одноранговая структура. TCP/IP имеет распределенный характер, в отличие от классической "нисходящей" модели обеспечения надежности. В среде с TCP/IP никакого центрального органа нет. Узлы взаимодействуют непосредственно друг с другом, и каждый из них обладает полной информацией о всех доступных сетевых сервисах. Если какой-либо из хост-компьютеров отказывает, ни одна из остальных машин на это не реагирует (если только ей не нужны данные, которые как раз на отказавшем компьютере и находятся).
Приведем список протоколов, входящих в стек TCP/IP:
Основные протоколы стека TCP/IP можно представить в виде структуры, изображенной на рис.1.
Рис. 1. Архитектура стека TCP/IP
Модель, основанная на стеке TCP/IP, включает в себя 4 уровня: прикладной, основной (транспортный), уровень межсетевых взаимодействий (сетевой), уровень сетевых интерфейсов (канальный). Соответствие этих уровней архитектуре модели OSI показано в таблице 1.
Таблица 1. Сопоставление уровней моделей OSI и TCP/IP
| Модель OSI | Модель TCP/IP |
| Прикладной | Прикладной |
| Представления данных | |
| Сеансовый | Основной (транспортный) |
| Транспортный | |
| Сетевой | Уровень межсетевых взаимодействий |
| Канальный | Уровень сетевых интерфейсов |
| Физический |
Как видно из таблицы, обе архитектуры взаимодействия включают похожие уровни, но в модели TCP/IP несколько уровней модели OSI объединены в один.
Рассмотрим функции всех четырех уровней модели, основанной на стеке протоколов TCP/IP.
Стек IPX/SPX разработан фирмой Novell для сетевой операционной системы Novell NetWare. Его структура предусматривает наличие множества сетевых сегментов, он эффективен в сложных средах.
Протоколы стека разрабатывались с учетом применения в локальных сетях с небольшими сетевыми ресурсами, но с хорошими физическими коммуникационными средствами. Поэтому эти протоколы не очень хорошо работали в составных сетях с глобальными низкоскоростными связями. В настоящее время, с одной стороны, возросла пропускная способность глобальных сетей, с другой - усовершенствованы протоколы стека. Все это теперь позволяет стеку IPX/SPX успешно конкурировать с другими стеками при создании корпоративных сетей.
Структура комплекта протоколов NetWare представлена на рис. 2.
Рис. 2. Архитектура стека IPX/SPX
Рассмотрим основные протоколы стека.
Протокол IPX, который наиболее широко используется в NetWare, размещается на самом нижнем уровне стека и выполняет для остальной части комплекта сетевые функции. IPX следит за различными сегментами сети и соответствующим образом управляет доставкой данных. Если узел-получатель находится в локальной сети, то данные передаются непосредственно ему, а если в удаленной, то данные передаются для доставки на маршрутизатор. Протокол IPX выполняет и другие функции сетевого уровня, например, инкапсулирование высокоуровневых протоколов, и является единственным протоколом пересылки данных в среде NetWare. IPX, тем не менее, не гарантирует доставку и не предоставляет услуги по коррекции ошибок. Эти функции выполняют транспортные протоколы, SPX и PEP.
Таким образом, протокол IPX выполняет функции адресации, маршрутизации и переадресации в процессе передачи пакетов сообщений. Несмотря на отсутствие гарантий доставки сообщений (адресат не передает отправителю подтверждения о получении сообщения), в 95% случаев не требуется повторной передачи. На уровне IPX выполняются служебные запросы к файловым серверам, и каждый такой запрос требует ответа со стороны сервера. Этим и определяется надежность работы методом дейтаграмм, так как маршрутизаторы воспринимают реакцию сервера на запрос как ответ на правильно переданный пакет.
Еще одна особенность IPX заключается в том, что он определяет размеры пакетов, руководствуясь пропускной способностью среды, к которой он подключен. Хотя минимальная величина IPX-пакета составляет 512 байтов, если два узла непосредственно соединены с Ethernet-сегментом, они пользуются пакетами размером 1024 байта. Если оба узла находятся в кольцевой сети с маркерным доступом, они будут использовать пакеты размером 4096 байта. IPX-маршрутизаторы, однако, всегда конвертируют пакеты обратно в стандартные 512-байтовые. Метод маршрутизации, принятый Novell, позволяет также повышать эффективность передачи данных, ограничивая в пакетах "пустое пространство" путем так называемого разреженного пакетирования. Общую длину пакета можно сократить до размера "конверта" и находящихся в нем данных. Этот метод применяется, в основном, для повышения эффективности работы маршрутизатора.
Протокол последовательного обмена пакетами SPX работает на транспортном уровне модели OSI, но имеет и функции, свойственные протоколам сеансового уровня. Он осуществляет управление процессами установки логической связи, обмена и окончания связи между любыми двумя узлами локальной компьютерной сети. После установления логической связи сообщения могут циркулировать в обоих направлениях с гарантией того, что пакеты передаются без ошибок. Протокол SPX гарантирует очередность приема пакетов согласно очередности отправления.
Гарантированная доставка данных обеспечивается благодаря использованию метода "окна". SPX не подтверждает прием каждого пакета, но, пользуясь методом "окна", подтверждает прием всех пакетов, которые поступили в этом окне, а также выполняет коррекцию ошибок, отслеживая последовательность, в которой были приняты пакеты.
Другой транспортный протокол - протокол обмена пакетами PEP - используется исключительно для доставки команд протокола ядра NetWare (NetWare Core Protocol, NCP). NCP содержит словарь команд сетевого ввода-вывода. NCP - сердце серверной системы NetWare. PEP считается частью подсистемы NCP и не документирован.
PEP выполняет функции коррекции ошибок с помощью "таймеров". Когда из PEP посылается пакет, в NCP запускается внутренний таймер, и до получения ответа больше ни один NCP-пакет не посылается. Если время истекает, PEP повторно отправляет пакет, а NCP перезапускает таймер. Такое квитирование и ожидание приводит к крайне неэкономному "расходованию" полосы пропускания NCP, но гарантирует доставку пакетов. В небольших локальных сетях это проходит незамеченным, но в крупных и чрезвычайно сложных сетях производительность может существенно снизиться.
Протокол оповещения о сервисах SAP "рекламирует" сетевые устройства и ресурсы. SAP выдает информацию о сервера, маршрутизаторах, интеллектуальных принтерах и т.д. Хотя SAP, в принципе, протокол прикладного уровня, он обращается к IPX напрямую. Информацию у SAP получают и другие подпротоколы, в частности, NCP и SPX.
Поскольку NetWare - это сеть, в которой для адресации используются номера устройств, должен быть какой-то способ перевода установленных человеком имен устройств в "реальные" числовые адреса этих устройств. SAP предоставляет эту услугу. Когда появляется программа или сервис, SAP замечает ее и создает соответствующий элемент у себя в таблицах. Хотя такой динамический реестр имен и облегчает жизнь пользователям, на постоянное обновление информации может быть "истрачена" вся полоса пропускания сети, потому что каждое SAP-устройство имеет свои таблицы рассылки. Для пользователей глобальной сети фильтрация SAP-пакетов на маршрутизаторах - хороший способ освобождения солидной части полосы пропускания. SAP можно также имитировать на маршрутизаторах: сервис объявляется, но линии глобальной сети не занимаются передачей SAP-пакетов - передаются только "образы" сервисов.
Напомним, что IPX - протокол сетевого уровня. Он ничего не знает о других сетях - кроме того, что они существуют. Когда в IPX появляется пакет, предназначенный для удаленной подсети, этот протокол передает его в ближайший маршрутизатор и забывает о нем. Услуги по маршрутизации IPX-пакетов выполняет протокол маршрутной информации RIP. Когда узел впервые включается в сеть, он выдает RIP-запрос, чтобы установить номер сети, в которой он находится.
Если узел подключен к нескольким сетям и конфигурирован как маршрутизатор, он посылает всем узлам сети RIP-изменение и оповещает их о маршрутах, которые может предложить. Маршрутизаторы посылают такие изменения каждые 60 секунд, сообщая другим устройствам, о каких сетях они знают. Если в течение отпущенного времени маршрутизатор RIP-изменение не посылает, он считается выключенным и соответствующая запись удаляется.
IPX-сети не относятся к числу иерархических, т.е. каждый маршрутизатор должен знать, как попасть во все остальные сегменты сети. По мере роста сетей эта схема становится неуправляемым и крайне дорогостоящим способом слежения за удаленными сетями. Novell разработала протокол состояния канала (NetWari Link State Protocol, NLSP), который работает гораздо лучше в очень сложных сетях. Маршрутизаторы не соуществляют непрерывную широковещательную передачу информации обо всех сетях и маршрутизаторах, которые им известны, а рассылают только ту информацию, которая изменилась, что значительно сокращает потребность в полосе пропускания.
Протокол IPX использует адрес, состоящий из номера сети, номера узла и номера сокета. Номер сети назначается на сервере администратором. Номер узла - это его аппаратный адрес (MAC-адрес сетевого адаптера или порта маршрутизатора). Номер сокета идентифицирует приложение, которое передает сообщение по протоколу IPX.
Конфигурирование клиентской части не требует значительных затрат. Адрес узла считывается автоматически из сетевого адаптера узла. Адрес сети узнается из серверных объявлений SAP. Для выяснения адреса маршрутизатора при старте системы клиента посылается сообщение SAP, в ответ на которое имеющиеся маршрутизаторы сообщают свои адреса.
Исторически сложилось так, что пользовательский интерфейс NetBIOS и его транспортный протокол, NBF, стали самыми "любимыми" протоколами Microsoft. Полученный в результате стек много раз переопределялся, перестраивался и переукомплектовывался для многих сетевых продуктов, включая LAN Manager, Windows for Workgroups, Windows NT.
Сегодняшний стек NetBIOS/NetBEUI разбит на три составляющих: NetBIOS API, SMB и транспортный протокол NBF. Взаимосвязь этих модулей изображена на рис. 3.
Рис. 3. Архитектура стека NetBIOS/NetBEUI
Рассмотрим основные протоколы стека.
NetBIOS - это сокращение от Network BIOS, и, как пользовательский интерфейс, NetBIOS распространил понятие базовой системы ввода-вывода ПК на сети. Когда фирма IBM, создавшая NetBIOS, начала работу, ее целью было создать простой сетевой протокол для небольших сетей персональных компьютеров. Этот протокол должен был предоставлять API для разработки сетевых приложений, которые могли бы взаимодействовать на межмашинном или межпрограммном уровне. Кроме того, такая система именования сетей позволяла бы использовать назначаемые человеком имена устройств, например, MyServer, которые легче запоминать и с которыми проще работать, чем со сложной схемой нумерации.
NetBIOS осуществляет адресацию в локальных сетях на основе уникальных имен узлов и практически не требует настройки (поэтому он привлекателен для поддержки сетей с небольшим числом компьютеров). Длина имени хостов - 16 байт, из них 6 байт - сетевой адрес машины, 10 байт - служебные. Кроме того, каждый компьютер имеет произвольное символьное имя. Также произвольные имена имеют рабочие группы из нескольких узлов. Эти имена назначаются и удаляются системным администратором. При каждом подключении к сети протокол NetBIOS опрашивает сеть для проверки уникальности имени узла.
Подчеркнем, что NetBIOS является API (Application Programming Interface - интерфейс прикладного программирования) сетевых приложений и не указывает, как данные перемещаются между системами, а лишь определяет, как данные упаковываются и получаются приложениями. Пакеты NetBIOS могут, в принципе, использовать любой транспортный протокол - и Microsoft заставляет их это делать, пользуясь протоколом NetBIOS-над-TCP (NBT). NBF обозначает конкретный транспортный протокол, изначально предназначенный для работы с NetBIOS.
Когда Microsoft избрала NetBIOS основной для первого поколения своего ПО локальных сетей, она ввела еще один компонент, характерный для ее программных средств, - блоки сообщений сервера SMB. SMB наделяет интерфейс NetBIOS сетевыми функциональными возможностями помимо того, что дает сам по себе транспортный протокол этого стека NBF (SMB можно транспортировать по протоколу IP или IPX так же свободно, как и по NBF).
SMB - это четко сформулированный метод взаимодействия серверов и узлов. Спецификация SMB включает достаточно полный словарь команд сетевого ввода-вывода. Например, если пользователь хочет открыть файл, расположенный на сервере, то из одной системы в другую передается SMB-команда SMBopen.
Команды SMB обеспечивают выполнение широкой гаммы операций и являются быстрым и экономически эффективным способом реализации большинства общеупотребительных сетевых функций. Есть команды для таких операций, как проверка прав доступа при регистрации, печать, непосредственная работа с файлами и каталогами.
Команды, входящие в спецификацию SMB, можно рассматривать как "команды наименьшего общего кратного". Поскольку эта спецификация предполагает, что в сети будут работать компьютеры разных типов, то для существенного повышения эффективности операций допускается использование "расширенных протоколов". Например, два DOS-компьютера в общении между собой пользуются расширением DOS, две NT-системы пользуются расширением NT и т.п. Это позволяет узлам взаимодействовать с максимальной эффективностью, гарантируя п то же время совместимость между разнородными устройствами.
NBF находится на самом нижнем уровне стека. Он выполняет функции протокола транспортного и сетевого уровней и предоставляет базовые услуги связи между устройствами. При сетевом вводе-выводе верхние уровни (NetBIOS-приложения или SMB-транзакции) передают данные прямо в NBF для обработки. NBF инкапсулирует данные в кадры, находит устройство или устройства, с которыми нужно установить связь, и передает данные в сетевую интерфейсную плату для последующей доставки, хотя и при помощи других механизмов. Некоторые услуги предоставляются лишь после установления соединения, что подразумевает ведение подробного и тщательно контролируемого "разговора" между двумя системами по виртуальному каналу. Некоторые услуги предоставляются без установления соединения, с помощью дейтаграмм. В таких случаях о переданных пакетах никто больше не вспоминает. Это метод используется в ситуациях, когда передаются повторяемые широковещательные сообщения, например, сообщения об изменении состояния и тому подобное.
NBF - самое слабое звено в стеке NetBEUI. Как и сама система NetBIOS, NBF не позволяет осуществлять маршрутизацию, т.е. может взаимодействовать только с теми устройствами, которые видит в ближайшей подсети или в подсети, соединенной с данной локальной сетью мостом. Вместе с тем, ввиду отсутствия потребности в дополнительных расходах на ведение маршрутных таблиц и тому подобной информации, NBF исключительно мал и быстр, - а это идеальный вариант для небольших сетей, насчитывающих менее 100 устройств. Кроме того, поскольку IBM создавала NBF в расчете на кольцевые сети с маркерным доступом, стандартный размер кадра в таких пакетах - 4096 байтов, что позволяет значительно повысить пропускную способность в сетях, которые могут работать с этим протоколом.
NBF является протоколом с интенсивным использованием широковещательной передачи. Поскольку предполагалось, что в сети будет всего несколько узлов и что устройства будут появляться там и исчезать произвольно, то считалось, что лучше обнаруживать устройства с помощью широковещательной передачи, нежели с применением какого-то централизованного реестра. К сожалению, в сегодняшних сетях с маршрутизаторами широковещательные пакеты работают не очень хорошо, так как маршрутизаторы не пропускают пакеты, не адресованные конкретно другому сегменту сети. А поскольку структура имен NetBIOS - не иерархическая, то устройства не могут указывать на удаленные сетевые сегменты. Таким образом, единственный способ заставить NetBIOS работать в больших сетях - соединить разные сегменты мостами в одну виртуальную сеть. К сожалению, такая зависимость от широковещательного режима ограничивает сфер применения относительно небольшими сетями, потому что большие соединенные мостами сети все равно работают не очень хорошо.
Специально для локальных сетей, работающих на базе протокола NetBIOS, корпорацией IBM был разработан расширенный интерфейс для этого протокола. Он рассчитан на поддержку небольших локальных сетей (не более 150-200 машин). Данный протокол может использоваться только в отдельных сегментах локальной сети, т.к. пакеты NetBEUI не могут транслироваться через мосты (устройства, соединяющие несколько сегментов сети). Этот стандарт считается устаревшим. Он поддерживается в ОС семейства Windows 9x/ME/2000, но уже не поддерживается Windows XP.
