FastCGI снимает ограничения популярного Web-интерфейса

Интерфейс CGI (Common Gateway Interface) стал общепринятым стандартом при разработке приложений для серверов Web. Тем не менее он не лишен существенных недостатков, среди которых - проблемы с производительностью и ограниченная масштабируемость. Возможно, новое расширение для этого популярного интерфейса, названное FastCGI, позволит снять указанные ограничения.

Интерфейс CGI был разработан для расширения функциональных возможностей Web-серверов наиболее общим способом. CGI-приложения работают независимо от ПО Web-сервера, а их запуск осуществляется по URL-запросу, т. е. по той же схеме, что и вызов документов HTML. Приложение CGI взаимодействует с Web-сервером посредством двустороннего обмена переменными среды через стандартные каналы ввода/вывода данного приложения.

Поскольку CGI-программы работают независимо от приложения Web-сервера и имеют простой общий интерфейс, разработчики Web имеют возможность создавать свои CGI-программы на любом языке, поддерживающем стандартные файловые операции ввода/вывода. Кроме того, при независимой разработке можно создавать такие приложения, которые легко переносятся с одного на другой Web-сервер.

Как устроен интерфейс CGI

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

Такие операции создают заметную дополнительную нагрузку на сервер, что сказывается на его производительности. К тому же запуск нового процесса при каждом запросе снижает эффективность постоянных процессов и доступность данных. Информацию, которая сгенерирована в ходе обработки одного запроса, невозможно использовать при обработке другого.

Для того чтобы обойти проблемы, связанные с быстродействием CGI, многие поставщики Web-серверов, включая Netscape Communications и Microsoft, разработали соответствующие интерфейсы прикладного программирования (API). Они тесно интегрированы с Web-сервером и расширяют возможности CGI-программ, позволяя сохранять доступность постоянно используемых процессов и данных. Благодаря API-интерфейсу программа базы данных может оставлять соединение с ней открытым, так что следующему запросу к базе данных не придется тратить время на открывание и закрывание соединения.

Однако API-интерфейсы Web-серверов - хоть и неплохое, но нестандартное решение. Большинство приложений нельзя переносить с одного API на другой, и очень редко удается переносить приложения на другие платформы. Кроме того, большинство приложений для Web-серверов все еще создаются для интерфейса CGI, поэтому переход к приложениям на базе API не представляется экономически оправданным.

В этой ситуации может выручить интерфейс FastCGI. Подобно CGI-программам, приложения на его базе работают независимо от Web-сервера и запускаются через стандартные URL. Но, как и программы на базе API, программы для FastCGI являются постоянно действующими. Когда программа заканчивает обработку очередного запроса, ее процесс остается открытым в ожидании нового запроса. В результате способы взаимодействия с Web-сервером такой программы и CGI-программ оказываются совершенно разными.

Структура FastCgi

Web-сервер, поддерживающий интерфейс FastCGI, должен иметь возможность взаимодействия с работающим приложением. Для этого интерфейс FastCGI превращает все стандартные потоки ввода/вывода данных и переменные среды CGI в двунаправленное соединение между сервером и приложением. Если приложение, поддерживающее интерфейс FastCGI, размещается на одной машине с Web-сервером, это соединение передает информацию через стандартные потоки ввода/вывода. Если же приложение и Web-сервер размещены на разных машинах, то взаимодействие между ними осуществляется по протоколу TCP.

Большинство CGI-программ можно легко преобразовать в форму, совместимую с интерфейсом FastCGI. Простая CGI-программа на языке С может выглядеть, например, следующим образом:

#include
void main(void){
   printf("Content-type: text/html
");
   printf("
");
   printf("Hello Network World!

");
   exit(0);
}

Программа посылает ответ "Hello Network World!" на запрос клиента и заканчивает на этом свое действие. Ее работа состоит в посылке HTML-текста на стандартный выход c использованием функции printf( ).

Та же программа, преобразованная для интерфейса FastCGI, будет выглядеть так:

#include
void main(void){
   while( FCGI-Accept( ) >=0 ){
      printf("Content-type: text/html
");
      printf("
");
      printf("Hello Network World!

");
      }
   exit(0);
}

Здесь файл применяется вместо стандартных подпрограм ввода/вывода. Стандартная функция printf( ) была переопределена, чтобы выходное сообщение выдавалось через единственное соединение FastCGI, а не через стандартный канал ввода/вывода. Аналоги этой функции имеются для Perl и других языков. Разработчики могут использовать их в качестве примеров реализации поддержки интерфейса FastCGI.

Функция FCGI-Accept( ) является основой интерфейса FastCGI. После ее активизации система ждет запроса от Web-сервера и блокирует дальнейшее выполнение программы. Получив запрос, функция FCGI-Accept( ) снимает блокировку и разрешает выполнение той части программы, которая записана в цикле while. Затем программа возвращается к функции FCGI-Accept( ) и ожидает нового запроса от сервера. Использование цикла while является стандартным в приложениях для интерфейса FastCGI.

FCGI-Accept( ) может также определить, с какого сервера - поддерживающего интерфейс CGI или FastCGI - была вызвана та или иная программа. Распознав запрос от сервера с CGI-интерфейсом, эта функция заставит программу после обработки запроса завершить свою работу, симулируя таким образом поведение интерфейса CGI. Во всех остальных случаях цикл while будет выполняться до тех пор, пока системный администратор или сервер Web не закончит выполнение приложения, использующего интерфейс FastCGI (или пока не будет выключен сервер Web).

В случае преобразования более сложной программы ее текст можно вставлять до или после оператора WHILE. Это будет приводить к однократному запуску программы и очистке памяти по завершении ее работы. Например, установление связи с базой данных можно производить до оператора WHILE, а необходимая очистка памяти производится непосредственно перед выходом из программы.

Протокол FastCGI поддерживает сценарии (группы подпрограмм) для приложений, взаимодействующих с сервером через интерфейс FastCGI. На основании данных о пути к файлу или типа расширения URL сценарии указывают серверу, каким образом ему следует обрабатывать данный запрос. В настоящее время интерфейс FastCGI поддерживает три сценария: Responder ("Ответчик"), Filter ("Фильтр") и Authorizer ("Авторизатор").

Программы группы Responder работают так же, как стандартные программы интерфейса CGI: они получают запрос и выдают на него ответ. Программы группы Filter осуществляют динамическое конвертирование документов, выполнение встроенных SQL-запросов или присоединение стандартных верхних и нижних колонтитулов к страницам документов. Программы группы Authorizer верифицируют пользователей и управляют доступом к серверу.

Как правило, цикл разработки программы для интерфейса FastCGI оказывается лишь ненамного длиннее, чем в случае CGI. Например, многие программы для интерфейса CGI не пытаются закрывать файлы или освобождать память при завершении своей работы, поскольку это происходит автоматически. В отличие от них, приложения для FastCGI, оставаясь активными, должны бережно распоряжаться используемыми ими ресурсами. Программам для FastCGI требуется аккуратно обходиться и с постоянно используемыми данными. Разработчику необходимо позаботиться о том, чтобы оставшаяся после предыдущего запроса информация не повлияла на обработку последующего.

Ограниченная поддержка

Самым крупным недостатком интерфейса FastCGI является его слабая распространенность. Лишь небольшая часть серверов Unix поддерживает протокол FastCGI, а производители Web-серверов, разрабатывающие свои собственные нестандартные API, очень неохотно его используют. Так, Netscape не планирует включать поддержку FastCGI в сервер Commerce Server; Microsoft продвигает на рынке свой Transaction Server, обеспечивающий реализацию предложенной этой компанией технологии динамических страниц. Оба производителя говорят, что рассмотрят вопрос о включении FastCGI в свои серверы лишь при настойчивых требованиях рынка.

Видимо, им все же придется пополнить свои серверы новым интерфейсом, причем весьма скоро. Похоже, что интерфейс FastCGI пришелся по душе разработчикам Web-приложений, о чем свидетельствует поддержка FastCGI на узле Apache, где размещается самый популярный сервер Web.