Search     or:     and:
 LINUX 
 Language 
 Kernel 
 Package 
 Book 
 Test 
 OS 
 Forum 
iakovlev.org
 

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 .
Оставьте свой комментарий !

Ваше имя:
Комментарий:
Оба поля являются обязательными

 Автор  Комментарий к данной статье
a
  aaa
2012-09-14 17:46:01