Стандарт CGI

Спецификация CGI является открытым стандартом. Это означает, что скрипт, написанный для одного сервера, будет прекрасно работать и с другими серверами, поддерживающими спецификацию. В этом легко может убедиться любой, кто пожелает мигрировать, скажем, с сервера NCSA или CERN на Apache или обратно. Единственное исключение составляют продукты Microsoft. Но даже в этом случае, как правило, переносимость скриптов от одного сервера к другому сохраняется. Спецификация CGI не зависит от платформы. Действительно, в любой операционной среде есть переменные окружения и понятия стандартных потоков ввода, вывода и ошибок. В частности, это позволяет выполнять скрипты, разработанные для ОС Unix, в среде MS-DOS. Типичным примером является скрипт Imagemap. Любопытно, что при переносе его на MS-DOS сохранилась даже ошибка с обработкой конца файла при просмотре описаний разбиения графического образа на фрагменты. Естественно, что при всех своих несомненных достоинствах CGI имеет и недостатки. Главным из них является низкая скорость реакции на запрос пользователя. В то время, когда NCSA ввел в обращение CGI, количество обращений к сайту было невелико. О масштабах AltaVista или Lycos не могло быть и речи. В этих условиях можно было пренебречь скоростью в угоду простоте и надежности. Главной причиной медленного отклика является порождение полноценного процесса при обращении к скрипту. Это тем более выглядит нелепо, если даже Apache для повышения своей "реактивности" при старте запускает сразу несколько серверов-потомков, ускоряющих обработку запросов пользователей. Если при этом через данных потомков обращаются к CGI-скриптам, то весь выигрыш оказывается потерян. Другим недостатком скриптов является тот факт, что использовать их можно только для ответа клиенту. Провести их обработку стандартными средствами сервера перед отправкой клиенту уже нельзя. Для этого приходится пользоваться отложенным обращением к результатам работы скрипта, которые предварительно помещаются в файл. API-интерфейсы Низкая производительность CGI вызвала к жизни спецификации API-интерфейсов. Суть API-интерфесов заключается в повышении производительности работы сервера за счет того, что новых полноценных процессов не порождается, и либо порождаются потоки, либо сам сервер выполняет необходимые операции по обработке запросов. Наиболее известным API на русскоязычных серверах является модуль автоматической перекодировки раскладок кириллицы, написанный Крюковым для сервера Apache. Этот модуль применяется многими отечественными провайдерами на своих серверах. Его идея состоит в том, что реально хранится только одно дерево документов, а не четыре (cp1251, cp866, koi-8, ISO). Кроме повышения производительности API позволяет повысить мощь сервера за счет добавления новых свойств. В настоящее время известны NSAPI (API для Netscape), ISAPI (API для IIS), API для Apache и ряд других. Достоинства этого механизма мы уже перечислили. Остановимся на его недостатках. Серьезнейший недостаток API - это его сложность. Для написания API-приложения необходимы глубокие знания архитектуры сервера и ее реализации. Например, модуль Крюкова кроме компиляции вместе с сервером требует еще и накладывания соответствующих "заплаток" на модули сервера. Совершенно очевидно, что при программировании API-приложений появляется языковая зависимость. Приложение нельзя написать на командных языках, например PERL. Выполняется приложение в адресном пространстве сервера. Это значит, что неотлаженное приложение может в случае ошибки привести к сбою в работе сервера. Плохо это и с точки зрения обычной безопасности. Написанное для определенного сервера приложение не может быть перенесено на другую платформу. Слишком тесно оно завязано на другие компоненты. Кроме этого, многие механизмы обеспечения синхронизации работы частей сервера или его взаимодействия со средой функционирования, как правило, зависят от ОС. Но именно они и используются в API для повышения эффективности работы. Таким образом, можно сказать, что при несомненно более высокой производительности приложения, реализованные согласно спецификации API, теряют многие замечательные качества CGI-скриптов. FAST CGI В этих условиях совершенно естественным шагом стало появление спецификации FAST CGI ("Быстрый" CGI). Заложенная в ней идея довольно проста: совместить преимущества обычного CGI и API. Для этого скрипт должен быть загружен либо в момент старта сервера, либо по требованию клиента и оставаться в памяти так долго, как это необходимо для обслуживания запросов. Нет необходимости создавать полновесный процесс при каждом обращении к скрипту - процесс создается один раз и потом только получает управление и данные от сервера. Но Fast CGI не только позволяет увеличить производительность приложений, но разрешает включить дополнительную обработку информации, отправляемой клиенту, и расширяет возможности сервера. Для этой цели в спецификацию включено понятие фильтра. Чисто внешне программы, выполненные в соответствии с требованиями Fast CGI, ничем, кроме включения в начало программы цикла обработки запросов сервера, не отличаются от CGI-скриптов. Канал приложение-сервер циклически опрашивается на предмет наличия запроса от сервера. Конечно, девственность CGI сохранить в Fast CGI не удалось. Сервер должен иметь модуль, который поддерживает взаимодействие с этим типом приложений. Сами приложения также обязаны быть откомпилированы с библиотекой функций Fast CGI. (Это самый простой способ получения нужного результата, так как в противном случае придется писать взаимодействие с сервером по протоколу Fast CGI вручную.) Сведем теперь преимущества Fast CGI воедино. Производительность Fast CGI существенно выше, чем у CGI, и немногим уступает API. Существуют даже примеры, когда Fast CGI работает быстрее API-приложения. Мигрировать от CGI к Fast CGI гораздо проще, чем к API. Кроме того, Fast CGI можно использовать и просто как обычный CGI. Fast CGI-скрипт можно написать и на простом командном языке. Существуют соответствующие компоненты для Perl и shell. FCGI-скрипт запускается в своем собственном адресном пространстве и не влияет на работу сервера. Спецификация доступна для широкого спектра как коммерческих, так и свободно распространяемых серверов, что делает скрипты мобильными. Кроме того, FCGI позволяет организовать распределенные вычисления, то есть работать с удаленными информационными ресурсами самостоятельно без сервера, установленного на вычислительной установке, на которой исполняется скрипт. Некоторые итоги Выше мы перечислили основные способы расширения возможностей сервера протокола HTTP, которые имеются у разработчика Web-узлов. Однако на самом деле на проблему необходимо взглянуть несколько шире. Решить проблемы конкретного Web-узла можно, используя различные способы, которые предлагают разработчики сервера, избранного в качестве основы для сайтов. Другое дело - распределенная информационная система. Здесь, имея в виду "зоопарк" аппаратных и программных возможностей, придется решать много задач, которые не встают обычно перед администрацией Website. Но где появляются эти системы? Ответ на самом деле один: в системах intranet. Здесь сервер представляет собой только центр, который связывает разные информационные технологии, основной из которых безусловно является ведение корпоративной базы данных. Насколько эффективно будет решаться данная задача, зависит от разработчиков системы и ее жизненного цикла, но выбирать все равно придется только из вышеперечисленных трех вариантов.