Расширение функций веб-серверов. Модули ISAPI (IIS) и DSO (Apache)

Модульная архитектура веб-сервера

Изначально, единственным средством выполнения программ на стороне веб-сервера было обращение к ним через общий шлюзовый интерфейс (CGI). Практика показала, что в CGI имеется ряд недостатков, в числе основных — высокие требования к аппаратным ресурсам веб-сервера и высокие накладные расходы на этапах загрузки и выгрузки CGI-приложений. Альтернативным решением стало использование модульной архитектуры веб-серверов, позволяющей расширять их возможности за счет внешних библиотек — модулей.

Модули веб-сервера — это статически или динамически подключаемые библиотеки функций, доступных веб-серверу. В отличие от CGI, модульные расширения быстрее и требуют меньших ресурсов, т.к. многопоточны, т.е. для обработки еще одного запроса не требуется загрузки еще одной копии приложения. Рассмотрим модульные расширения наиболее распространенных веб-серверов: DSO для веб-сервера Apache и ISAPI для Internet Information Services

Apache DSO

Веб-сервер Apache имеет открытую модульную архитектуру и его базовые возможности представлены в основном модуле ядра(apache core). Дополнительные возможности вынесены во внешние модули, которые могут быть подключены к ядру статически или динамически. Это позволяет очень тонко настраивать Apache под конкретные задачи, включая в сборку только те функции, которые действительно нужны. Такой подход позволяет управлять производительностью и функциональностью веб-сервера.

Для статического подключения модулей Apache должен быть скомпилирован вместе с кодом нужных модулей. Динамически подключаемые модули добавляют свою функциональность при их загрузке во время запуска/перезапуска веб-сервера. Для динамического подключения модуль должен быть представлен в виде DSO (Dynamic Shared Object). Для поддержки DSO Apache использует опять же модуль, mod_so, который загружает модули в виде разделяемых библиотек или разделяемых файлов. Способ загрузки DSO указывается в конфигурационном файле веб-сервера Apache (httpd.conf) соответствующими директивами:

• LoadModule — задает связь с указанным модулем и добавляет его в список активных модулей. Синтаксис:

  LoadModule module filename

  Имя модуля является названием внешней переменной типа module и определено как Module Identifier в документации модуля. Имя файла (filename) задается относительно корня веб-сервера (ServerRoot). Пример:

  LoadModule status_module modules/mod_status.so

• LoadFile — задает связь с указанным файлом; используется для загрузки файла или библиотеки, которые требуются для работы модуля. Синтаксис:

  LoadFile filename [ filename ] ...

  Где filename — абсолютный путь к файл[у|ам] или относительный путь от корня веб-сервера (ServerRoot). Пример:

  LoadFile libexec/libxmlparse.so

Модули взаимодействуют с сервером Apache через единый интерфейс. Они регистрируют свои обработчики в ядре Apache или в других модулях. Ядро Apache обращается к этим обработчикам когда это требуется. С другой стороны, модули могут обращаться к функциям и структурам данных ядра через Apache API. Это может потребоваться, например, при передаче данных или выделении памяти.

Модуль Apache прозрачен для пользователя, т.е. не является конечной точкой клиентского запроса, чем напоминает ISAPI-фильтр. Модуль может представлять функции обработки программных прерываний (handlers for hooks), связывания директив конфигурации, фильтрации запроса и дополнительные функции.

• Программное прерывание (hook) — это любое критичное событие, произошедшее на этапе выполнения кода веб-сервера и которое должно быть обработано. Вызов функций этого типа контролируется ядром сервера, поскольку обработчики модуля могут дополнять код ядра.
• Функции связывания директив конфигурации предназначены для считывания и применения настроек модуля, которые у каждого модуля будут разными, из общего файла конфигурации веб-сервера.
• Фильтрация запросов позволяет выполнять обработку как входящих запросов, так и ответов сервера.
• Дополнительные функции — это некритичные функции и фильтры, результаты которых игнорируются ядром и возвращаются «как есть».

Приведем краткое описание некоторых модулей Apache.

• mod_access — отвечает за доступ к каталогам и файлам веб-сервера и переопределение ряда параметров веб-сервера для заданных каталогов и файлов.
• mod_alias — отвечает за переадресацию и использование псевдонимов, позволяет перенаправлять запросы к физическим каталогам по их псевдонимам (алиасам). Такое перенаправление используется, например, для каталога с CGI-скриптами.
• mod_asis позволяет отдавать клиенту запрошенный ресурс «как есть», без какой-либо обработки сервером.
• Модули из семейства mod_auth отвечают за аутентификацию пользователей. Различные модули из этого семейства реализуют разные способы аутентификации. Подробности — в документации на модули mod_auth, mod_auth_dbm, mod_auth_digest и подобных.
• mod_autoindex предназначен для автоматической генерации индексных файлов. Это может быть очень удобно при работе, например, с файловым архивом, когда нужно просто поместить на индексной странице названия файлов. С помощью директив этого модуля можно сортировать файлы, добавлять разным типам файлов свои иконки, отображать или скрывать файлы с заданными расширениями и так далее.
• mod_deflate позволяет сжимать файлы в формат GZIP перед отправкой пользователю для ускорения загрузки.
• mod_status позволяет администратору контролировать работу веб-сервера. Система будет сама записывать в файл все запросы, время перезагрузок и остановок сервера, загрузку процессора компьютера и другую информацию.
• mod_proxy позволяет использовать Apache в качестве прямого или обратного прокси-сервера. В первом случае он управляет доступом во внешнюю сеть из ЛВС, во втором — напротив, предоставляет доступ к узлам ЛВС, которые не видны «извне».
• mod_rewrite отвечает за перенаправление запросов и позволяет скрывать параметры скриптов. Например, с помощью этого модуля можно настроить преобразование клиентского запроса вида:

  http://example.com/news/2009/05/03

  к фактическому виду:

  http://example.com/news.php?date=20090503

• mod_perl — загружаемый (а не вызываемый, как в CGI) интерпретатор Perl.
• mod_include — набор функций препроцессинга SSI (Server Side Includes), позволяющих «собирать» веб-страницу на стороне сервера из отдельных файлов.

Это далеко не полный перечень модулей Apache, но даже он позволяет дать представление о гибкости этого самого распространенного веб-сервера.

ISAPI

ISAPI (Internet Server Application Programming Interface) — это набор интерфейсов, предоставляемых веб-сервером MS IIS (Internet Information Services) для написания приложений, взаимодействующих с этим сервером и расширяющих его возможности. Приложения ISAPI представляют собой динамически подключаемые библиотеки (Dynamic Link Library, DLL), напрямую взаимодействующие с API IIS. Приложения ISAPI загружаются и выполняются в адресном пространстве IIS, поэтому серверу не нужно создавать новый процесс при каждом HTTP-запросе. Поскольку Windows загружает динамически подключаемую библиотеку один раз при первом вызове функции в DLL, то приложение ISAPI остается загруженным и не удаляется, пока не будет остановлен/выключен веб-сервер (если включено кэширование ISAPI), либо приложение не будет выгружено явным образом (если кэширование выключено).

Рис. 1. Архитектура ISAPI

Приложения ISAPI могут быть оформлены или в виде расширений, или в виде фильтров.

• ISAPI-расширение — это приложение IIS, которое является адресатом запроса, оно выполняет действия, которые веб-сервер не может выполнять сам (например, обращение к базе данных). Расширение не влияет на параметры запроса, а использует их как входные данные. В этом ISAPI-расширение напоминает CGI-приложение. ISAPI-расширение может быть вызвано как явно (через запрос вида http://<URL/path>/isapiext.dll?paramstring), так и неявно (через карту расширений, в которой указаны обработчики для зарегистрированных типов файлов (mapping), или при вызове через фильтр). Расширения ISAPI — наиболее частый способ применения ISAPI.
• ISAPI-фильтр, в отличие от расширения, является своего рода посредником в обработке пользовательского запроса с момента его получения веб-сервером и до момента отправки ответа. Фильтр может модифицировать запрос или ответ, вызвать специфичный для конкретного запроса обработчик и т.п., при этом сам фильтр не является конечным обработчиком. Фильтры ISAPI довольно сложны в разработке и сфера их использования ограничена, как правило, решением таких задач, как шифрование, журналирование, аутентификация, сжатие данных.

Основное преимущество ISAPI — в скорости выполнения операций. ISAPI-приложение работает быстрее, чем обычная CGI-программа (которая должна всякий раз загружаться и выгружаться) или скрипт (который сначала должен быть загружен, потом обрабатан интерпретатором, которому, в общем случае, тоже нужно время на загрузку).

Среди недостатков — трудности при отладке ISAPI-приложений. Незамеченная ошибка может привести к нарушению работоспособности не только самой библиотеки dll, но и всего веб-сервера. При разработке ISAPI-приложений на универсальных языках программирования, таких как C++ или Object Pascal еще одной проблемой становится неконтролируемый код. Т.е. разработчик должен сам заботиться об управлении памятью, «сборке мусора» и прочих аспектах системного уровня. Еще один недостаток, пожалуй, самый главный — непереносимость. Несмотря на то, что ISAPI — открытая спецификация и поддержка технологии реализована, например, в модуле mod_isapi.dll для Apache for Win32, нет никакой возможности применять ISAPI на платформах, отличающихся от MS Windows.

CC-BY-SA Анатольев А.Г., 31.01.2012