Функциональный стек LAMP

LAMP — акроним, обозначающий набор (комплекс) серверного программного обеспечения, широко используемый во Всемирной паутине. LAMP назван по первым буквам входящих в его состав компонентов:

Linux — операционная система Linux;

Apache — веб-сервер;

MySQL — СУБД;

PHP — язык программирования, используемый для создания веб-приложений (помимо PHP могут подразумеваться другие языки, такие как Perl и Python).

Акроним LAMP может использоваться для обозначения:

Инфраструктуры веб-сервера

Парадигмы программирования

Пакета программ

Хотя изначально эти программные продукты не разрабатывались специально для работы друг с другом, такая связка стала весьма популярной из-за своей гибкости, производительности и низкой стоимости (все её составляющие являются открытыми и могут быть бесплатно загружены из Интернета). Набор LAMP входит в состав большинства дистрибутивов Linux и предоставляется многими хостинговыми компаниями.

Обнаружение ресурсов в сети веб

Информация в Интернете организована с помощью архитектуры, определенной ор­ ганизацией Internet Society (ISOC). Это целеустремленная (хотя и управляемая комите­ тами) организация, которая поддерживает согласованную работу и операционную со­ вместимость в Интернете.

Информацию об организации Internet Society можно найти в разделе 14.1.

Организация ISOC определяет три способа идентификации ресурсов: унифициро­ ванные идентификаторы ресурсов (Uniform Resource Identifier — URI), унифицирован­ ные указатели ресурсов (Uniform Resource Locator — URL) и унифицированные име­ на ресурсов (Uniform Resource Names — URN). Как показано на рис. 23.1, по существу, унифицированные указатели и имена ресурсов представляют собой частный случай уни­ фицированного идентификатора ресурсов.

Рис. 23.1. Классификация унифицированных идентификаторов ресурсов

В чем же различия между ними?

• Унифицированные указатели ресурсов сообщают вам, как найти ресурс, описывая

его механизм первичного доступа (например, http://admin.com).

• Унифицированные имена ресурсов идентифицируют (“называют”) ресурс без указания на него или сообщают, как получить доступ к нему (например, urn:isbn:0-13-020601-6).

Что же тогда называется URI? Если доступ к ресурсу возможен только через Интер­ нет, то используется указатель URL. Если же доступ к ресурсу возможен не только через Интернет, но и с помощью других средств, то используется идентификатор URI.

Унифицированные указатели ресурсов

Большую часть времени мы работаем с указателями URL, описывающими доступ к объекту с помощью пяти базовых компонентов.

• Протокол или приложение

• Имя узла

• Порт TCP/IP (необязательно)

• Каталог (необязательно)

• Имя файла (необязательно)

В табл. 23.1 перечислены протоколы, которые наиболее часто упоминаются в URL- адресах.

Глава 23. Веб-хостинг 1003

Таблица 23.1. Протоколы URL-адресов

Протокол Назначение Пример



file Доступ к локальному файлу (выход в Интернет file://etc/syslog.conf не осуществляется)

ftp Доступ к файлам по протоколу FTP ftp://ftp.admin.com/adduser.tar.gz

http Доступ к файлам по протоколу HTTP http://admin.com/index.html

https Доступ к файлам по протоколам HTTP/SSL https://admin.com/order.shtml

ldap Доступ к службе каталогов LDAP ldap://ldap.bigfoot.com:389/cn=Herb

mailto Отправка электронного сообщения по указан­ mailto:sa-book@admin.com ному адресу

Принцип работы HTTP

HTTP — это клиент-серверный протокол, не хранящий информацию о состоянии сеанса. Клиент запрашивает у сервера “содержимое” заданного URL-адреса. Сервер от­ вечает, передавая поток данных или возвращая сообщение об ошибке. Затем клиент мо­ жет запросить следующий объект.

Поскольку протокол HTTP настолько прост, можно легко подключиться к веб-бра­ узеру с помощью утилиты telnet. Для этого достаточно подключиться к порту 80 вы­ бранного веб-сервера. После установления соединения сервер готов принимать НТТР- команды.

Чаще всего используется команда GET, которая запрашивает содержимое документа. Обычно она задается в формате GET /. В этом случае возвращается корневой документ сервера (как правило, начальная страница). Протокол HTTP чувствителен к регистру символов, поэтому команды следует набирать прописными буквами.

$ telnet localhost 80

Trying 127.0.0.1...

Connected to localhost.atrust.com.

Escape character is '^]'.

GET /

<далее следует содержимое файла, заданного по умолчанию> Connection closed by foreign host.

Более “полный” HTTP-запрос должен включать номер версии протокола HTTP, за­ прашиваемый узел (необходимый для того, чтобы извлечь файл из виртуального узла, использующего имена) и другую информацию. В этом случае ответ, помимо возвращае­ мых данных, содержит информативные заголовки.

$ telnet localhost 80

Trying 127.0.0.1...

Connected to localhost.atrust.com. Escape character is '^]'.

GET / HTTP/1.1

Host: www.atrust.com

HTTP/1.1 200 OK

Date: Sat, 01 Aug 2009 17:43:10 GMT

Server: Apache/2.2.3 (CentOS)

Last-Modified: Sat, 01 Aug 2009 16:10:22 GMT

Content-Length: 7044

Content-Type: text/html

1004 Часть II. Работа в сети <далее следует содержимое файла, заданного по умолчанию>

 Connection closed by foreign host.

В данном случае мы сообщили серверу, что собираемся передавать данные по прото­ колу НТТP версии 1.1, и назвали виртуальный узел, у которого мы запрашиваем инфор­ мацию. Сервер вернул нам код состояния (НТТР/1.1 200 ОК), текущую дату и время, имя и версию программного обеспечения, на котором выполняется протокол, дату по­ следнего изменения запрашиваемого файла и содержимое запрашиваемого файла. Ин­ формация заголовка отделена от содержимого одной пустой строкой.

Генерирование содержимого "на лету"

Помимо работы со статическими документами, HTTP-сервер способен выдавать пользователям страницы, формируемые “на лету”. Например, если требуется отобра­ зить текущие время и температуру, сервер вызывает сценарий, предоставляющий эту информацию. Такие сценарии зачастую создаются средствами CGI (Common Gateway Interface — единый шлюзовой интерфейс).

CGI является не языком программирования, а, скорее, спецификацией, описываю­ щей обмен информацией между HTTP-сервером и другими программами. Чаще всего CGI-сценарии представляют собой программы, написанные на языке Perl, Python или РНР. В действительности подойдет практически любой язык программирования, кото­ рый поддерживает операции ввода-вывода в режиме реального времени.

Встроенные интерпретаторы

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

Кроме поддержки дополнительных внешних сценариев CGI, многие веб-серверы определяют модульную архитектуру, позволяющую интерпретаторам сценариев, таким как Perl и РНР, самим встраиваться в веб-сервер. Это связывание значительно увеличи­ вает производительность, поскольку веб-сервер больше не обязан запускать отдельный процесс, чтобы обрабатывать каждый запрос сценария. Архитектура, большей частью, скрыта от разработчиков сценариев. Как только сервер видит файл, имя которого за­ канчивается специфическим расширением (например, .pl или .php), он посылает со­ держимое файла встроенному интерпретатору для выполнения. Некоторые интерпрета­ торы, которые могут выполняться внутри веб-сервера Apache, перечислены в табл. 23.2.

Таблица 23.2. Модули встроенных сценариев для веб-сервера Apache

Язык Имя встроенного интерпретатора

Python mod_python

РНР mod_php (традиционно)

Zend server (коммерческий ускоритель)

Источник информации

Perl mod_perl

perl.apache.org

modpython.org

apache.org

zend.com

Ruby on Rails Phusion Passenger (он же mod_rails или mod_rack) modrails.com



Глава 23. Веб-хостинг 1005

Модуль FastCGI

В некоторых ситуациях удобно использовать модуль FastCGI (fastcgi.com). Этот модуль улучшает производительность сценариев, запуская их один раз, а затем оставляя выполняться для обслуживания многих запросов. Такая схема снижает стоимость запу­ ска интерпретатора и анализа сценария при выполнении нескольких запросов. Иногда она работает быстрее, чем запуск интерпретатора внутри самого веб-сервера Apache.

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

Безопасность сценариев

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

Сайт OWASP (Open Web Application Security Project, owasp.org) публикует массу пре­ восходных материалов о веб-безопасности. Общую информацию по вопросам безопас­ ности можно найти в главе 22.

Серверы приложений

Сложные промышленные приложения могут требовать больше функциональных возможностей, чем может предоставить базовый НТТP-сервер. Например, современные страницы Web 2.0 часто содержат компоненты, связанные с динамическими котиров­ ками (например, биржевым аппаратом). Несмотря на то что на веб-сервере Apache эту функциональную возможность можно реализовать с помощью таких технологий, как AJAX и JavaScript Object Notation (JSON), некоторые разработчики предпочитают более богатые языки, такие как Java. Обычно для взаимодействия приложения, написанного на языке Java, с другими источниками данных на предприятии используется “сервлет”.

Сервлеты (servelet) — это программы, которые выполняются на сервере прикладных программ поверх его платформы. Серверы прикладных программ могут работать не­ зависимо или в сочетании с веб-сервером Apache. Большинство серверов прикладных программ разрабатывается “программистами для программистов” и не имеет достаточно мощного механизма отладки, необходимого системным администраторам. В табл. 23.3 перечислены некоторые серверы прикладных программ для систем UNIX/Linux.

Если вам придется столкнуться с необходимостью поддержки одного из этих серве­ ров прикладных программ, поищите документацию, описывающую программы, и по-

1006 Часть II. Работа в сети

тренируйтесь. Поверьте нам, это не та технологию, которую можно освоить “на ходу”, как большинство приложений для систем UNIX и Linux. Мы вас предупредили.

Таблица 23.3. Модули встроенных сценариев для веб-сервера Apache

Сервер Тип Веб-сайт



Tomcat Открытый код tomcat.apache.org

GlassFish Открытый код grassfish.dev.java.net

JBoss Открытый код jboss.org

OCJ4 Коммерческий oracle.com/technology/tech/java/oc4j

WebSphere Коммерческий ibm.com/websphere

WebLogic Коммерческий oracle.com/appserver/weblogic/weblogic-suite.html

Jetty Открытый код eclipse.org/jetty

Поиск по сайту: