Сравнение РНР как интерпретатора CGI и как модуля Apache
Сравнение РНР как интерпретатора CGI и как модуля Apache
Как было сказано выше, РНР можно компилировать
- в виде самостоятельного интерпретатора CGI
- как модуль Apache.
Если
РНР сконфигурирован как
Если РНР скомпилирован как модуль Apache (рис. 2.1), он выполняется в адресном пространстве процесса самого веб-сервера, благодаря чему обеспечивается заметное увеличение производительности по сравнению с обычными интерпретаторами CGI, являющимися самостоятельными процессами.
Некоторые функции, такие как постоянные соединения с базами данных (persistent database connections), доступны только в версии модуля Apache.
Программирование в среде Web. Зачем нужно использовать РНР?
Теперь, когда мы знаем, как устанавливать РНР, стоит задаться вопросом, для чего вообще нужен РНР. Можно было бы ограничиться HTML - в конце концов, это старый испытанный метод создания веб-страниц. Почему необходимы «динамические» веб-страницы? Значительно проще овладеть в совершенстве HTML, чем изучать совершенно новую технологию.
Недостатки HTML
Содержание многих веб-сайтов статическое, например научные статьи. Страницы на этих сайтах являются документами, состоящими из простого текста, изображений и гиперссылок на другие документы. Для сайтов такого типа обычно достаточно простых технологий на стороне клиента. HTML и каскадные таблицы стилей (CSS) предоставляют средства структурирования и представления содержимого страницы, а с помощью JavaScript при желании можно несколько оживить ее.
Однако Интернет и интранет все в большей степени используются для приложений, и большинство из них включает в себя базы данных. Эти сайты и приложения являются динамическими, поскольку их содержание меняется в зависимости от участвующих в них данных и действий пользователя. Именно здесь вступает в игру РНР. Благодаря запуску на сервере программ РНР можно создавать очень мощные приложения, взаимодействующие с базами данных и динамически создающие содержание.
Главное различие между страницами РНР и страницами HTML состоит в том, как с ними работает веб-сервер.
Что происходит со страницами HTML?
Когда от броузера поступает запрос страницы, веб-сервер делает следующие три шага:
• читает запрос от броузера;
• находит страницу на сервере;
• посылает страницу обратно броузеру через Интернет или интранет.
Что происходит со страницами РНР?
С помощью РНР добавляется еще один шаг. Вместо того чтобы отослать пользователю статическую страницу HTML, мы потребуем от сервера выполнить некоторые действия в соответствии с нашим кодом РНР:
РНР примет некоторые решения и создаст страницу, соответствующую конкретной ситуации. Поэтому при использовании РНР сервер действует следующим образом:
- читает запрос от броузера;
- находит страницу на сервере;
- выполняет инструкции РНР для модификации страницы;
- посылает страницу обратно броузеру через Интернет или интранет.
Что же такого делает РНР, чего не может HTML?
Решающее отличие состоит в том, что чистый HTML интерпретируется броузером, а не выполняется на сервере. Написав код, который должен выполняться на веб-сервере, можно достичь таких результатов, которые иначе были бы невозможны.
Например, мы хотим написать код страницы, которая извещает о новостях в среду, если запрос происходит в среду, а в четверг извещает о новостях в четверг. В другом случае мы хотим создать страницу, которая определяет тип броузера пользователя и, в зависимости от этого, оптимизирует запрашиваемые данные. С помощью РНР действия такого рода выполняются сервером на третьем шаге описанной последовательности.
Вот еще несколько примеров того, что можно делать с помощью РНР, но нельзя делать с помощью только HTML:
- упрощать изменение содержимого веб-страницы, обновляя содержание базы данных, а не кода HTML;
- создавать страницы, настроенные на вывод данных, представляющих интерес для конкретного пользователя;
- выводить и обновлять базы данных на веб-странице благодаря возможности сортировать данные в любом порядке или просматривать их подмножество;
- создавать страницы, попеременно показывающие ряд графических изображений;
- получать ответную реакцию пользователя и передавать ему информацию на основе этой реакции.
Этот перечень охватывает лишь то, что лежит на поверхности; в действительности РНР позволяет решать значительно более широкие задачи.
WWW - новое поколение
В сущности, РНР является лишь одной из нескольких технологий, которые можно использовать для создания более динамичных и интерактивных веб-страниц. В этом разделе мы остановимся на истории развития РНР и на некоторых конкурирующих с ним технологиях.
Статические публикации
Первое поколение было представлено статическими публикациями — страницами, образованными с помощью HTML и состоящими из статических картинок и текста, которые можно было точно расположить, указав координаты х и у. Такие страницы достаточно элементарны, и чтобы получить с помощью такой технологии действительно производящие впечатление результаты, нужно быть экспертом в HTML или привлекать художника-оформителя! Кроме того, для обновления страницы необходимо редактировать HTML вручную или с помощью редактора, а вдобавок, статические страницы не были совместимы с базами данных. Помимо отображения текста и изображений с их помощью можно было сделать немногое.
Активные веб-сайты
Некоторое время WWW развивалась в направлении активных веб-сайтов, позволяющих посылать пользователю заказные страницы и предоставляющих для просмотра более динамичное содержание. Такие сайты создаются с помощью сочетания ряда языков и технологий, которые можно использовать отдельно или в комбинациях независимо друг от друга (в том смысле, что изучение одной технологии не предполагает необходимости предварительного знания другой).
Эти технологии молено разбить на две группы: технологии на стороне клиента и технологии на стороне сервера. В первую группу входят:
- Управляющие элементы ActiveX, создаваемые с помощью Visual C++ или Visual Basic
- Апплеты Java
- Сценарии, выполняемые на стороне клиента, и динамический HTML
В число технологий, используемых на стороне сервера, входят:
- CGI
- Фирменные API для веб-серверов, такие как ISAPI и NSAPI
- Active Server Pages
- JavaServer Pages и Java Servlets
- PHP
Остановимся вкратце на каждой из них.
Динамические технологии на стороне клиента
Все технологии являются относительно недавними нововведениями. Основной недостаток реализации функций на стороне клиента заключается в том, что вебмастер никак не может влиять на то, какое программное обеспечение используется для просмотра страницы. А поскольку компании хотят привлечь как можно больше пользователей с как можно большим числом различных броузеров, принятие новых технологий происходит очень медленно, и поддерживаются они лишь в новейших версиях основных броузеров. Напротив, технологии, используемые на стороне сервера, обычно не требуют какого-либо специального броузера, и принятие их в целом происходит быстрее.
Управляющие элементы ActiveX
Управляющие элементы ActiveX являются отдельными программами, которые известны как компоненты. Разрабатываются они на таких языках, как С++ или Visual Basic. Располагаясь на веб-странице, такой элемент реализует какую-либо специальную функцию, например, выводит диаграммы и графики, играет роль таймера, производит аутентификацию клиента или доступ к базе данных. Управляющие элементы ActiveX добавляются к страницам HTML с помощью тега <OBJECT>, который вошел в стандарт HTML. Встроенные в веб-страницу управляющие элементы ActiveX могут выполняться броузером или сервером.
Существует некоторое препятствие: управляющие элементы ActiveX разработаны Microsoft и, несмотря на совместимость со стандартом HTML, функционируют только в Internet Explorer. Некоторая поддержка ActiveX обеспечивается и для броузера Netscape при использовании подключаемого модуля (plug-in), поставляемого фирмой NCompass. Следовательно, на практике нельзя рассматривать ActiveX как не зависящий от платформы способ создания динамических страниц.
Апплеты Java
Апплет - это программа, написанная на языке программирования Java, которую можно включить в страницу HTML способом, похожим на тот, которым включается графический образ. Если для просмотра страницы, содержащей апплет, используется броузер, поддерживающий Java, код апплета пересылается на машину и выполняется броузером. Поскольку апплет написан на Java, он использует все преимущества этого языка, являясь автономным и не зависящим от платформы.
Сценарии на стороне клиента и DHTML
Языки сценариев предоставляют новичкам более легкий доступ к программированию. Языки сценариев для использования в Сети на стороне клиента были разработаны с целью создания динамической альтернативы статическому HTML. Когда броузер находит в коде HTML команду сценария, он транслирует этот сценарий в чистый HTML (если броузер понимает данный язык сценариев). Это позволяет разработчику создавать более интерактивные веб-страницы со значительно расширенной по сравнению со страницами чистого HTML функциональностью.
Основным языком сценариев, используемым на стороне клиента, служит JavaScript. Он поддерживается как Netscape Navigator (с версии 2), так и Microsoft Internet Explorer (с версии 3). Используемый на стороне клиента VBScript поддерживается только в Internet Explorer и потому не очень полезен для создания универсальных сценариев для Интернета. Тем не менее, он иногда применяется в интранет, использующих исключительно решения Microsoft.
Динамический HTML используется аналогично языку сценариев, поскольку сценарий интерпретируется броузером и создает представление страницы в HTML. На практике, единственное, что отличает динамический HTML от сценариев, - это то, что он позволяет осуществлять дополнительные функции, например, помещать анимацию на страницы и точно располагать графику и текст с использованием абсолютных координат. В конечном итоге, броузер все равно создает страницу из чистого HTML.
Технологии на стороне сервера
Несколько лет назад единственным практическим решением для размещения в Сети динамического содержания была технология под названием Common Gateway Interface (CGI - интерфейс общего шлюза). CGI-программы предоставляли сравнительно простой способ создания веб-приложения, получающего введенные пользователем данные, выполняющего запрос к базе данных и возвращающего результаты обратно броузеру. Как Microsoft, так и Netscape разработали собственные API, с помощью которых для обслуживания веб-запросов можно было создавать код, выполняющийся в рамках того же процесса (in-process). В число новейших предлагаемых технологий на стороне сервера входят Active Server Pages (ASP), Java Servlets и JavaServer Pages (JSP), хотя существует много других.
Интерфейс общего шлюза - Common Gateway Interface (CGI)
CGI является
наиболее часто используемой
сетевой технологией,
Наиболее крупным недостатком CGI-программирования является то, что оно плохо масштабируется. При каждом получении веб-сервером запроса создается совершенно новый процесс. Каждый процесс состоит из собственного набора переменных окружения, отдельного экземпляра необходимой среды этапа исполнения, экземпляра программы и памяти, выделенной для использования программой. Нетрудно представить себе, что может произойти с сервером, когда одновременно приходит большое количество запросов. Ресурсы сервера подвергаются большому испытанию, что может вызвать его отказ.
Фирменные API веб-серверов (ISAPI, NSAPI)
Видимо, в ответ на неэффективность CGI Microsoft и Netscape разработали собственные API, позволяющие разработчикам создавать серверные приложения в виде библиотек совместного доступа. Эти библиотеки загружаются в процесс веб-сервера и могут обслуживать несколько запросов, не создавая новых процессов. Они могут загружаться при запуске веб-сервера или по мере необходимости в них. Если в течение определенного времени они не используются, веб-сервер выгружает их из памяти.
Хотя выполняемые
в рамках процесса библиотеки являются
эффективным расширением веб-
- • Поскольку эти API специфичны для каждой платформы, написанные с их использованием программы могут работать только на соответствующей платформе. Перенесение этих программ в другую среду является очень сложной задачей.
- • Поскольку доступ к этим библиотекам осуществляется одновременно несколькими пользователями, они должны быть написаны с применением методов обеспечения безопасности потоковых переменных (thread-safe). Это означает, что доступ к глобальным и статическим переменным должен осуществляться с большой осторожностью.
- • Если в выполняемой на сервере программе происходит нарушение прав доступа, то поскольку она находится в том же процессе, что и сам веб-сервер, может произойти авария всего веб-сервера.
Active Server Pages (ASP)
ASP имеет
сходство с РНР, сочетая HTML,
сценарии и компоненты на
Active Server Page может быть написана с использованием HTML, Jscript (вариант JavaScript, созданный Microsoft) и VBScript. Благодаря использованию сценариев, Active Server Page может иметь доступ к компонентам на стороне сервера. Компоненты можно создавать на любом языке, который предоставляет интерфейс к СОМ (спецификация компонентов, разработанной Microsoft). Несомненным; недостатком активных серверных страниц является то, что их можно использовать только с веб-сервером Microsoft (US, PWS) под операционными системами Microsoft (Win9x, WinNT). Существуют переносы на другие платформы и веб-серверы, но отсутствие широкой поддержки СОМ снижает их эффективность.
Java Servlets и JSP
Java-сервлеты (Java Servlets) и JavaServer Pages (JSP) являются технологиями, применяемыми на стороне сервера и использующими язык Java. Недавно Sun представила ряд новых API, позволяющих подключать программы к корпоративным службам и данным. Java Servlet API является одним из краеугольных камней этих расширений платформы Java, предоставляя мощный способ создания динамического содержания и расширения функциональности веб-серверов.
Сервлет Java является программой, выполняемой на стороне сервера, обслуживающей запросы HTTP и возвращающей результаты в виде ответа HTTP. В этом отношении она очень похожа на CGI, но на этом сходство и заканчивается. Хорошей аналогией сервлета является невидимый апплет, выполняемый на веб-сервере. Его жизненный цикл аналогичен жизненному циклу апплета, а выполняется он внутри виртуальной машины Java (JVM).
JavaServer Pages (JSP) аналогичны активным серверным страницам Microsoft (ASP). Страница JavaServer содержит HTML, код Java и компоненты JavaBean. JSP позволяет встраивать в страницы компоненты и обеспечивать выполнение ими работы по генерации страницы, посылаемой в конечном итоге клиенту. При запросе пользователем файла JSP веб-сервер сначала генерирует соответствующий сервлет, если его еще не существует. Затем веб-сервер запускает сервлет и возвращает созданное им содержание броузеру.
JavaServer Pages и Java Servlets страдают тем же недостатком, что и язык Java, используемый на стороне клиента: Java относительно сложен для изучения программистами-новичками.
РНР
Последняя из рассматриваемых нами технологий на стороне сервера служит темой данной книги: РНР. РНР был разработан в 1994 году Расмусом Лер-дорфом (Rasmus Lerdorf) с целью отслеживания тех, кто просматривал его электронное резюме, и был выпущен на следующий год под названием Personal Home Page Tools (средства разработки личной домашней страницы). Позднее в том же году он был переработан и объединен с интерпретатором форм HTML Form Interpreter, получив название PHP/FI Version 2. Популярность продукта быстро росла, и в середине 1997 года РНР перестал быть личным проектом Расмуса Лердорфа, превратившись в важную сетевую технологию. Зив Сураски (Zeev Suraski) и Энди Гутмане (Andi Gutmans) полностью переписали синтаксический анализатор, и в июне 1998 года был выпущен РНР 3..
РНР работает аналогично JSP и ASP: разделы сценария заключаются в теги <?php.. ?> и встраиваются в страницу HTML. Эти сценарии выполняются на сервере перед тем, как послать страницу броузеру, поэтому проблемы поддержки броузером РНР не существует. Однако, в отличие от ASP, РНР является независимым от платформы, и существуют различные версии для разных вариантов Windows, Unix и Linux, а также ряда веб-серверов, в том числе Apache и IIS. Определяющее значение имеет то, что он является бесплатным продуктом с открытым кодом (open source).
Преимущества обработки на стороне сервера
Обработка и генерация веб-страниц на стороне сервера имеет ряд преимуществ перед технологиями, используемыми только на стороне клиента:
- уменьшается поток данных в сети в результате уменьшения необходимости многократного общения броузера и сервера друг с другом;
- способствует уменьшению времени загрузки, поскольку в итоге фактически загружается только страница HTML;
- устраняются проблемы совместимости броузеров;
- клиенту могут поставляться данные, которые отсутствуют на его машине;
- обеспечивается лучшая защита данных, поскольку код невозможно просмотреть броузером.
