Writing Apache Modules with Perl and C
By: Lincoln Stein and Doug MacEachern
Chapter 1 - Server-Side Programming with Apache
Код примеров из книги лежит тут.
Итак , в начале был веб-сервер . Это был CERN httpd, веб-сервер ,
написанный на си в 1991 в одной из европейских физических лабораторий.
CERN httpd был разработан для обслуживания статических веб-страниц .
Он вылавливал из сети URL-запросы с помощью т.н. протокола HTTP/0.9 ,
переводил их в пути и возвращал контент запрашиваемых страниц .
Если вам нужно было расширить функциональность этого веб-сервера , нужно было перекомпилировать исходники .
Конечно , это было гибко , но не очень удобно .
На раннем этапе CERN работал с внешними программами для обработки запросов.
Была построена система обработки таких запросов , которая вызывала командный шелл или внешний скрипт.
Вывод скрипта перенаправлялся в броузер , в котором страница генерировалась на лету.
Эта схема позволяла передавать скрипту список аргументов , создающих поисковую систему.
Затем некто Rob McCool из Иллинойского университета разработал другой веб-сервер - Mosaic.
NCSA httpd был меньше , чем CERN httpd,быстрее и легче в реконфигурировании .
Он быстро вырос до уровня CERN httpd , особенно в штатах.
Он также позволял на лету генерировать страницы с помощью внешних скриптов.
Но скрипты , написанные для работы с NCSA , не работали с CERN httpd.
Рождение CGI
К счастью , разработчики этих серверов , а также другие разработчики , обьединились и
создали стандарт , называемый Common Gateway Interface.
Через какое-то время после появления CGI возникла первая проблема .
Особенность CGI-скриптов в том , что они пожирают большое количество памяти и ресурсов .
Они хорошо проявляют себя на юниксовых системах , но неважно работают на NT .
Другой проблемой CGI скриптов является то , что по окончанию работы они
выгружаются из памяти ,и для следующего запроса нужна его очередная загрузка .
Server APIs
Первой альтернативой для CGI стало изобретение серверных API ,
механизма , с помощью которого программисты расширяли функциональность
за счет написания новых серверных модулей .
Примером такого web API является Plexus web server, написанный Tony Sanders для BSDI.
Plexus был 100% написан на перл 4-й версии . Вебмастер мог писать новые модули на перл ,
компилировать и добавлять их .
Позже были разработаны :
NSAPI - интерфейс для Netscape;
ISAPI - интерфейс для Microsoft IIS;
Apache API.
Самой большой проблемой всех этих API является их ограниченная
портабельность для разных платформ .
Server-Side Includes
Одним из возожностей веб-серверов стало появление SSI - включение внутри HTML
специального кода внутри специальных тегов .
Впервые это нашло применение в NCSA httpd.
Наиболее продвинуто SSI используется в ASP.
Наибольшей проблемой SSI является опять все та же несовместимость для разных платформ .
Embedded Interpreters
Для избежания проблем проприетарности API , некоторые вендоры вернулись к
использованию высокоуровневых
языковых интерпретаторов . Примером может служить mod_pyapache, использующий Python .
Исполняемый скрипт на языке питон выполняется очень быстро ,
потому что интерпретатор уже находится
в памяти . Sun Microsystems' "servlet" API позволяет выполнять программы ,
написанные на Java .
Эта книга в основном посвящена апачевскому модулю mod_perl,
который запускает на веб-сервере
перловый интерпретатор . Он предоставляет программистам полный доступ к Apache API.
Script Co-processing
Другим путем для ускорения CGI-скриптов является их загрузка и постоянное
хранение в памяти .
Первой такой системой был FastCGI протокол,реализованный Open Market в 1996.
Существующие скрипты можно было легко адаптировать под FastCGI небольшим изменением
в коде .
Реализации FastCGI доступны для Apache, Zeus, Netscape, Microsoft IIS.
Но FastCGI не нашел широкого распространения .
Тем не менее , он поддерживается для Apache в модуле mod_fastcgi.
Клиентские скрипты
Другой путь для улучшения производительности веб-сервера - переложить
часть его тягот на клиента . JavaScript был добавлен Netscape в 1995,
VBScript добавлен Microsoft чуть позже , повысил возможности клиентского броузера .
Комбинация возможностей скриптовых языков , css, document layers и других
HTML-фич породила "Dynamic HTML" (DHTML). Основная проблема DHTML все та же -
несовместимость . Причем несовместимость может быть на уровне одной платформы
для разных броузеров . Затем появились Java applets.
Затем возникла Microsoft ActiveX-технология в форме COM (Common Object Model)
Сравнительный анализ
Следующая таблица дает сравнительную характеристику различных веб-технологий .
|
Портабельность
|
Производительность
|
Обслуживание
|
Power
|
|---|
CGI
|
++++
|
+
|
+++
|
++
|
FastCGI
|
++
|
+++
|
+++
|
++
|
Server API
|
+
|
++++
|
+
|
++++
|
Server-side includes
|
++
|
++
|
++++
|
++
|
DHTML
|
+
|
+++
|
+
|
++
|
Client-side Java
|
++
|
+++
|
++
|
+++
|
Embedded interpreter
|
+++
|
+++
|
++
|
++++
|
Integrated system
|
+
|
+++
|
++
|
++++
|
Apache Project
Apache-проект начался в 1995 . Сначала это была public-domain-версия сервера NCSA.
За это время были добавлены такие фичи , как хостинг виртуальных серверов
на одном веб-сервере,различные варианты аутентификации, кэширующее прокси .
Например , только на апаче на данный
момент реализована HTTP/1.1 Digest Authentication scheme.
Была разработана модульная расширяемая архитектура .
Мало что осталось от первоначального NCSA httpd ,
например остался набор конфиг-файлов.
Успех апача оказался феноменальным . Менее чем за 3 года апач превратился
в лидера отрасли .
Netcraft, британская компания , мониторящая развитие веба , выяснила ,
что на данный момент
апач работает более чем на 50% веб-сайтов .У Microsoft всего 22% рынка.
Апач послужил кодовой основой для нескольких других коммерческих серверов ,
например C2Net's Stronghold с его SSL , WebTen by Tenon Intersystems, Macintosh PowerPC,
Red Hat Secure Server. В 1997 году апач был портирован на Win32.
Апач компактен , хорошо документирован и может быть свободно скачан .
Как и другие open-source продукты , такие как Perl, GNU tools , Linux ,
Apache имеет много преимуществ над коммерчискими продуктами .
Его С-код включает 25,000 строк кода . Он очень быстр и потребляет меньше ресурсов ,
чем многие коммерческие сервера . Его модульная архитектура позволяет
гибко настраивать конфигурацию .
Apache портабелен на многих платформах .
Любой софт имеет баги . Девелопментский процесс у апача открыт и публичен .
Исходный код доступен любому , и вы всегда можете принять участие в подписке .
Как , правило , баги не остаются долго открытыми . Модульность апача не заставляет вас
использовать всю его функциональность . Его конфигурация проста и прозрачна за счет
конфиг-файлов . Вы можете сохранять копии конфиг-файлов и восстанавливать
их при необходимости .
Возможность управлять конфигурацией из командной строки упрощает его поддержку .
Разрабатываются продвинутые средства конфигурирования , например веб-интерфейс для
удаленного управления ( http://stein.cshl.org/~lstein/user_manage).
Apache C и Perl API
API предоставляет доступ к процессам , протекающим внутри сервера .
Вы можете детально рассмотреть , что происходит во время любого цикла HTTP-транзакции .
Вы можете вызывать произвольные акции при старте и выходе сервера ,
добавлять новые директивы в конфиг-файлы , настраивать процесс обработки URLs ,
создавать новые системы аутентификации . Все это поддерживается с помощью модулей ,
которые загружаются вместе с сервером либо динамически (DSO).
Особенность архитектуры апача в том , что его API , написанные на С , используются в
наиболее ответственных модулях . Для конкретных приложений больше подходят CGI-скрипты ,
FastCGI.
В 1996 году Doug MacEachern разработал mod_perl,Perl-интерпретатор ,
встроенный в модуль.
Этот модуль позволяет вызвать любую сишную API на языке Perl .
|
LINUX