Сетевые протоколы предоставляют так называемые службы канала данных и составляют нижние три уровня модели OSI. Эти протоколы обрабатывают информацию адресации и маршрутизации, контроль ошибок и запросы повторной пересылки. Сетевые протоколы определяют также правила для коммуникации в сетевом окружении, таком как Ethernet или Token Ring. Наиболее популярные сетевые протоколы перечислены ниже:
1. IP (Internet Protocol), протокол TCP/IP для маршрутизации и пересылки пакетов.
2. IPX (Internetwork Packet Exchange), протокол NetWare для пересылки пакетов и маршрутизации.
3. NWLink, реализация Microsoft протокола IPX/SPX.
4. NetBEUI, транспортный протокол, который предоставляет службы транспорта данных для сеансов NetBIOS и приложений.
5. DDP (Datagram Delivery Protocol), протокол транспорта данных AppleTalk.
Мы увидели, как эти протоколы укладываются в модель OSI, и получили представление о функциях каждого из них. Теперь следует рассмотреть, как все это отображается в совокупности, после чего можно исследовать различия в поведении этих протоколов, как используется каждый из них, а также различные уровни функциональности.
Заголовок SPX состоит из следующих семи полей:
• Управление соединением — 1 байт
• Тип потока данных — 1 байт
• Идентификатор соединения источника — 2 байта
• Идентификатор соединения места назначения — 2 байта
• Номер последовательности - 2 байта
• Номер подтверждения — 2 байта
• Номер размещения — 2 байта
Управление соединением Остановимся на некоторых функциях, предоставляемых полем управления соединением. Эквивалент флагов TCP, которые были показаны в главе 2, управление соединением предоставляет механизм двунаправленного потока данных, управления перегрузкой и другие связанные с этим возможности. Поле управления соединением указывает три типа пакетов управления соединением. Эти значения могут быть либо логическими, либо могут быть заданы вместе с несколькими флагами. Сначала рассмотрим флаг конца сообщения.
• Флаг "Конец сообщения" (End-of-message). Этот флаг устанавливается, когда в поле управления соединением появляется 0x10. Он используется для указания конца сообщения партнеру по передаче. Так как SPX является транспортным протоколом на основе сообщений, посылающая сторона задает этот флаг для указания, что сообщение завершено. После того как получающая сторона получит этот пакет, она передаст данные в буфер сообщения вышележащего приложения. Это не запрос конца соединения, но скорее указание, что текущий обмен сообщениями закончился.
• Флаг "Требуется подтверждение" (Acknowledgment-Required). Флаг требования подтверждения устанавливается, когда в поле управления соединением появляется 0x40. Он используется для указания, что данные были посланы партнеру по передаче и требуется подтверждение. Прежде чем будут отправлены новые данные, должно быть получено подтверждение для этого пакета.
• SPX требует подтверждения посланных данных; когда они получены, устанавливает флаг, сигнализирующий "конец сообщения" для партнера. Число является комбинацией 0x40 и 0x10 и равно 0x50.
• Флаг "Системный пакет" (System-Packet). Флаг системного пакета устанавливается, когда в поле управления соединением появляется 0x80. Это пакет подтверждения, используемый внутренне протоколом SPX для подтверждения, что партнер по сеансу работает и соединение существует. Это сообщение типа "Я здесь".
• Флаг "Комбинация системных пакетов" (System-Packet combination). Флаг комбинации системных пакетов устанавливается, когда в поле управления соединением появляется ОхСО. ОхСО является суммой 0x80 и 0x40. Он используется внутренне протоколом SPX, показывая, что соединение все еще существует, требуя подтверждения (АСК) от партнера по коммуникации. Это пакет типа "Вы еще здесь?".
Протокол IPX является протоколом третьего уровня без поддержки соединения, предназначенным для передачи дейтаграмм. Компания Novell адаптировала его из старого протокола межсетевых дейтаграмм (протокол IDP) стека Xerox (XNS).
Протокол без соединения
Поскольку он является протоколом без поддержки соединения, то когда процесс, выполняющийся на определенном узле, использует IPX для коммуникации с процессом на другом узле, между двумя узлами не устанавливается соединение. Таким образом, пакеты IPX адресуются и посылаются к своему месту назначения, но нет гарантии или проверки успешной доставки. Любое подтверждение пакета или управление соединением обеспечиваются протоколами выше IPX, такими как SPX. Термин дейтаграмма означает, что каждый пакет интерпретируется как отдельная сущность, не имеющая логической или последовательной связи с любым другим пакетом.
Работа на сетевом уровне модели 0SI
Как протокол сетевого уровня IPX адресует и маршрутизирует пакеты из одного местоположения в другое при межсетевом обмене IPX. IPX принимает решения о маршрутизации, просматривая поля адресов заголовка и на основе информации, которую он получает из RIP или NLSP. IPX использует эту информацию для пересылки пакетов в их узел назначения или следующему маршрутизатору, предоставляющему путь к узлу назначения.
Структура пакета
Так как протокол IPX был адаптирован из старого протокола XNS ГОР, не удивительно, что их структуры похожи. Пакет IPX состоит из двух частей. Первая часть является 30-байтовым заголовком, который содержит адреса сети, узла и сокета для машин источника и места назначения. Вторая часть является разделом данных, который иногда содержит заголовок протокола более высокого уровня, такого как SPX. Минимальный пакет IPX имеет 30 байтов (не считая заголовок MAC). Максимальный размер маршрутизированных пакетов IPX обычно имеет только 576 байтов, включая заголовок IPX и нагрузку данных. Однако при использовании IPX II это число возрастает до 1500 байтов.
Как было отмечено в главе 2 о TCP, сетевой уровень следует за заголовком MAC, поэтому IPX помещается после заголовка MAC и перед полезной нагрузкой. На рис. 3.2 показано, что заголовок IPX помещается внутри протокола MAC таким же образом, как описано в главе 2.
Номер узла является шестибайтовым шестнадцатеричным числом, используемым для уникальной идентификации устройства в среде IPX. Это число идентично физическому адресу платы сетевого интерфейса, который соединяет устройство с сетью.
Заголовок IPX содержит поля узла назначения и узла источника. Поскольку номера узлов являются такими же, как адреса сетевой интерфейсной платы, эти поля содержат такие же адреса места назначения и источника, как находящиеся в заголовке MAC. Например, рабочая станция, выполняющая IPX/SPX, использует адрес узла назначения для определения места и пересылки пакетов другой рабочей станции в том же сетевом сегменте.
Номер узла IPX должен быть уникальным в том же сетевом сегменте. Например, узел в сети 3001 может использовать номер 006008A1D4B4, а узел в сети 3002 также может использовать номер 006008A1D4B4. Это действует так же, как протокол IP, потому что адрес хоста может совпадать в различных сетях IP. Поскольку каждый узел имеет отличный сетевой номер, IPX распознает каждый узел, как имеющий законный уникальный адрес.
Номер сокета
Двухбайтовый шестнадцатеричный номер сокета идентифицирует место назначения процесса внутри узла. Это может быть нечто вроде маршрутизации (RIP) или объявления (внутри устройства SAP). Так как обычно одновременно действуют несколько процессов, номер сокета обеспечивает что-то вроде "почтового ящика", используемого каждым процессом для идентификации себя для IPX.
Когда процессу требуется коммуникация в сети, он запрашивает номер сокета. Все пакеты, полученные IPX и адресованные сокету, пересылаются затем процессу. Номера сокетов предоставляют быстрый метод маршрутизации пакетов в узле. Это работает таким же образом, как сокеты Windows или номера портов TCP/IP. Они являются логическими местами назначения на удаленной машине для межпроцессной коммуникации. В таблице 3.5 перечислены некоторые номера сокетов и процессы, встречающиеся обычно в достаточно активных сетях.
Сокеты под номерами между 0x4000 и 0x7FFF являются динамическими; они создаются в ходе работы, когда рабочей станции понадобится коммуникация с файловым сервером или другими сетевыми устройствами. Сокеты под номерами между 0x8000 и OxFFFF являются общеупотребительными; Novell присваивает их определенным процессам. Например, 0x9001 является номером сокета, который идентифицирует NLSP. Разработчики программного обеспечения, пишущие приложения NetWare, могут контактировать с Novell для выяснения общеупотребительных сокетов.
Диалекты протокола NT LM 0.12 и более поздние версии поддерживают операции распределенной файловой системы (DFS — Distributed File System). DFS предоставляет для этого протокола способ использования единственной согласованной схемы именования файлов, которая может охватывать совокупность различных серверов и ресурсов общего доступа. Модель DFS использует модель на основе направлений. Этот протокол определяет способ, которым клиенты получают направления.
Клиент может установить в заголовке запроса SMB флаг, указывающий, что клиент хочет, чтобы сервер разрешил в DFS пути доступа SMB, которые известны серверу. Сервер пытается разрешить запрошенное имя в файл, содержащийся внутри локального дерева каталогов, указанного TID запроса, и затем нормально продолжить. Если путь доступа запроса разрешается в файл на другой системе, то сервер возвращает следующую ошибку.
STATUS_DFS_PATH_NOT_COVERED - сервер не поддерживает часть пространства DFS, требуемую для разрешения пути доступа в запросе. Клиент должен запросить на этом сервере направление для дополнительной информации.
Клиент запрашивает направление с помощью запроса TRANS2-DFS-GETREFERRAL, содержащего интересующий путь доступа DFS. Ответ с сервера указывает, как клиент должен продолжить.
Метод, с помощью которого топологическое представление DFS хранится и поддерживается серверами, не определен этим протоколом.
Заголовок SMB
Хотя каждая команда SMB имеет определенное кодирование, в заголовке SMB есть несколько полей, которые имеют значение для всех SMB. Как можно увидеть в распечатке ниже, протокол SMB выполняется поверх NetBIOS, который переносится поверх TCP, реализованный поверх IP, который реализован поверх метода доступ к среде Ethernet. Эти поля описаны в последующих разделах.
