4.Внутреннее устройство Windows (гл. 12-14)

Поддержка QoS в Windows основана на наборе Winsock-функций, определенных Microsoft и позволяющих приложениям запрашивать QoS для трафика через свои сокеты Winsock, а также на API управления трафиком (TC API), который позволяет административным приложениям более точно контролировать трафик через сети.

Центральное место в реализации QoS в Windows занимает протокол RSVP (Resource Reservation Setup Protocol), представляющий собой Windows-сервис (WindowsSystem32Rsvp.exe), как показано на рис. 13–22. Провайдер службы RSVP (WindowsSystem32Rsvpsp.dll) передает QoS-запросы приложений через RPC службе RSVP Ta в свою очередь контролирует сетевой трафик с помощью TC API. TC API, реализованный в WindowsSystem32Traffic.dll, посылает команды управления вводом-выводом драйверу GPC (Generic Packet Classifier) (WindowsSystem32DriversMsgpc.sys). Дpaйвep GPC — втесном взаимодействии с планировщиком пакетов QoS (промежуточным драйвером NDIS) (WindowsSystem32DriversPsched.sys) — контролирует поток пакетов с компьютера в сеть, гарантируя уровни QoS, обещанные конкретным приложениям. При этом он вставляет в пакеты соответствующие заголовки QoS.

ПРИМЕЧАНИЕ B Windows XP и Windows Server 2003 служба RSVP по-прежнему работает, но действует лишь как посредник между приложениями и компонентами, управляющими трафиком.

Последний фрагмент головоломки под названием «сетевая архитектура Windows» — способ, посредством которого сетевые компоненты, расположенные на различных уровнях (сетевых API, драйверов транспортов TDI, драйверов NDIS), находят друг друга. Процесс соединения уровней называется привязкой (binding). Вы сами были свидетелем привязки, если хоть раз изменяли конфигурацию сети, добавляя или удаляя компоненты в окне свойств сетевого соединения.

Устанавливая сетевой компонент, вы должны предоставить его INF-файл (INF-файлы описаны в главе 9). Этот файл содержит инструкции, которым должны следовать API-функции установки, чтобы установить и сконфигурировать компонент, учитывая его зависимости от других компонентов. Разработчик может указать зависимости для своего компонента, что позволит SCM загружать его в корректной очередности и только тогда, когда все компоненты, от которых он зависит, уже присутствуют в системе (о SCM см. главу 4). Привязки определяются механизмом привязки (bind engine) на основе информации из INF-файла компонента, что позволяют соединить его с другими компонентами, расположенными на различных уровнях. Эти соединения указывают, какие компоненты нижележащего уровня могут быть использованы сетевым компонентом данного уровня.

Так, служба рабочей станции (редиректор) автоматически привязывается к протоколам TCP/IP и NWLink. Порядок привязки, который можно увидеть на вкладке Adapters And Bindings (Адаптеры и привязки) диалогового OKHaAdvancedSettings (Дополнительные параметры) (рис. 13–23), определяет приоритет привязки. (O том, как открыть это диалоговое окно, см. раздел «Поддержка нескольких редиректоров» ранее в этой главе.) Получив запрос на доступ к удаленному файлу, редиректор выдает запрос обоим драйверам протоколов. После того как редиректору приходит ответ, он дополнительно ждет ответы от любых драйверов протоколов с более высоким приоритетом. И только тогда редиректор возвращает результат вызывающей программе. Поэтому, присвоив высокий приоритет привязкам, которые дают максимальную производительность или применимы к большинству компьютеров в сети, можно добиться определенного выигрыша.

Рис. 13–23. Редактирование привязок в диалоговом окне Advanced Settings

Информация о привязках компонента содержится в параметре Bind подраздела Linkage того раздела реестра, в котором хранится конфигурация данного сетевого компонента. Например, информацию о привязках службы рабочей станции можно найти в HKLMSYSTEMCurrentControlSetServices LanmanWorkstationLinkageBind.

Windows включает сетевые сервисы, построенные на основе API и компонентов, представленных в этой главе. Описание возможностей и внутренних деталей их реализации выходит за рамки этой книги, но мы приведем здесь краткий обзор по удаленному доступу, службе каталогов Active Directory, Network Load Balancing, службе репликации файлов (File Replication Service, FRS) и распределенной файловой системе (Distributed File System, DFS).

Windows Server с установленной службой Routing and Remote Access Service (Служба маршрутизации и удаленного доступа) позволяет клиентам удаленного доступа подключаться к серверам удаленного доступа и обращаться к таким сетевым ресурсам, как файлы, принтеры и службы, создавая иллюзию физического подключения к серверу удаленного доступа через локальную сеть. Windows поддерживает два типа удаленного доступа.

• Удаленный доступ через телефонную линию (dial-up remote access) Используется клиентом при подключении к серверу удаленного доступа через телефонную линию или иную телекоммуникационную инфраструктуру Телекоммуникационная несущая среда используется для создания временного физического или виртуального соединения между клиентом и сервером.

• Удаленный доступ через виртуальную частную сеть (virtual private network, VPN) Позволяет клиентам VPN устанавливать с сервером виртуальное соединение типа «точка-точка» через IP-сеть, например Интернет.

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

Active Directory — реализация службы каталогов LDAP (Lightweight Directory Access Protocol) в Windows. Active Directory основана на базе данных, в которой хранятся объекты, представляющие ресурсы, определенные приложениями в сети Windows. Например, в Active Directory хранится структура и список членов домена Windows, включая информацию об учетных записях и паролях пользователей.

Классы объектов и атрибуты, определяющие свойства объектов, задаются схемой (schema). Иерархическая организация объектов в схеме Active Directory напоминает логическую организацию реестра, где объекты-контейнеры могут хранить другие объекты, включая контейнеры.

Active Directory поддерживает несколько API, используемых клиентами для обращения к объектам в базе данных Active Directory.

• LDAP C API Предназначен для программ на С/С++ и использует сетевой протокол LDAP. Приложения, написанные на С/С++, могут работать с этим API напрямую, а приложения, написанные на других языках, — через транслирующие уровни.

• ADSI (Active Directory Service Interfaces) СОМ-интерфейс Active Directory, реализованный поверх LDAP и абстрагирующий от деталей программирования для LDAP. ADSI поддерживает несколько языков, в том числе Microsoft Visual Basic, C и Microsoft Visual C++. ADSI также доступен приложениям Windows Script Host (Сервер сценариев Windows).

• MAPI (Messaging API) Поддерживается для совместимости с клиентами Microsoft Exchange и клиентскими приложениями Outlook Address Book.

• Security Account Manager (SAM) API Базируется на сервисах Active Directory и предоставляет интерфейс пакетам аутентификации MSVlO (WindowsSystem32Msvl_O.dll) и Kerberos (WindowsSystem32Kdcsvc.dll).

• Сетевые API Windows NT 4 (Net API) Используются клиентами Windows NT 4 для доступа к Active Directory через SAM.