Практический пример. Web-cepвep Apache

Чгобы проиллюстрировать работу Web-сервера, мы рассмотрим практический пример использования популярного, свободно распространяемого сервера Apache [Ара, LL99J. Выпущенная в 1995 г. первая версия (0.6.2) сервера Apache была оснО- вапа на созданном рапее Web-сервере NCSA [KBM94J. Название Apache было связано с тем, что разработчики широко используют технологию «программных за- плагок» (patches), и является сокращением от "а patchy server". Программное обеспечение было разработано несколькими добровольцами, образовавшими группу Apache Group [MFH00J. Сервер Apache в настоящее время является наиболее популярным Web-сервером [Netc]. Также широко используется коммерческое программное обеспечение Web-серверов, главным образом разработанных Microsoft и Netscape, которое нашло наибольшее применение при создании больших коммерческих Web-сайтов.

В этом разделе мы познакомимся с основными возможностями версии 1.3.3 сервера Apache. Установка сервера Apache состоит в простом копировании соответствующих исполняемых файлов на Компьютер. Однако в большинстве случаев Web-адмипистраторы приспосабливают программное обеспечение к требованиям своих сайтов.Эта настройка обычно заключается в задании параметров, которые влияют на выделепие ресурсов, интерпретацию HTTP-запросов, генерацию заголовков HTTP-ответов, управление доступом и регистрацию действий сервера. В этом разделе мы постараемся в общих чертах рассказать, как работает Web-cepвер, а также проиллюстрировать, какие возможности пастройки достунны администратору сайта. Хотя обсуждение будет посвящено серверу Apache, многое из сказанного Можно отнести и к другим Web-серверам.

Управление ресурсами

Сервер Apache 1.3.3 назначает отдельный процесс каждому соедипепию, в противоположность недавно разработанному серверу Apache 2.0, который реализован как мпогопоточпый. Ресурсы размещаются в динамических областях (пулах), которые автоматически освобождаются после завершения процесса.

МОДЕЛЬ ПРОЦЕССА

Сервер Apache использует модель с управлением по процессам с главным процессом, который назначает процесс каждому повому соединению. Вместо того чтобы создавать повый процесс для каждого нового соединения, процесс-родитель создает несколько дочерних процессов при запуске сервера. Количество начальных дочерних процессов (StartServers) представляет собой один из параметров настройки, относящихся к дочерним процессам. Эти параметры приведены в таблице 4.2. Сервер поддерживает балапс между слишком большим и слишком маленьким числом процессов. Сервер накладывает ограничение на число одновременно выполняющихся процессов (MaxClients), которое задается при компиляции программного обеспечения Web-cepвepa. Теоретически сервер может всегда работать с данным числом процессов, даже если большинство из них пеактивны и ожидают новых соедииепий. Наличие неактивных процессов позволяет избежать затрат на создапие новых процессов при поступлении дополнительных запросов. Однако наличие большого числа неактивных процессов приводит к перациоиалыюму использованию ресурсов операционной системы.

Сервер Apache накладывает ограиичения на минимальное и максимальное количество иеактивпых процессов (MinSpareServers и MaxSpareServers). Каждые несколько секупд родительский процесс определяет, сколько дочерних процессов являются неактивными. Затем родитель создает или завершает дочерние процессы, в зависимости от того, является ли это число слишком маленьким или слишком большим. Уничтожение неактивных процессов возвращает операционной системе ресурсы, которые могут быть использованы активными процессами, и сокращает нагрузку на систему. Если количество неактивных процессов мало, создание новых процессов подготавливает сервер к обслуживанию будущих клиентских запросов. Порождая дополнительные процессы до поступления запросов, сервер гарантирует, что создание процесса не задержит обработку новых клиентских запросов. Такой подход к созданию и завершению процессов является эффективным способом добиться компромисса между относительно небольшим числом неактивных процессов и созданием иовых процессов. Помимо периодического удаления неакгивиых процессов, сервер Apache накладывает настраиваемое ограничение на количество HTTP-запросов, обрабатываемых каждым дочерним процессом (MaxRequests- PerChild). Дочерний процесс завершается при достижении этого ограничения.

Таблица 4.2. Основные параметры настройки для дочерних процессов и сетевых соединений

Параметр

Описание (значение по умолчанию в Apache 1.3.3)

StartServers

Начальное число дочерних процессов (5)

MaxClicnts

Максимальное количество дочерних процессов (256)

MinSparcServers

Минимальное число неактивных дочерних процессов (5)

MaxSpareServers

Максимальное число неактивных дочерних процессов (10)

MaxRequcstsPcrChild

Максимальное число запросов на дочерний процесс (30)

ListenBacklog

Максимальное число ожидающих соединений (511)

SendBufferSize

Размер буфера передачи TCP (размер по умолчапию для ОС)

MaxKeepAliveRequests

Максимальное число запросов на соединение (100)

KcepAliveTimcout

Максимальное время, в течение которого соединение может оставаться неактивным (15 с)

Сервер Apache имеет определенные значения по умолчанию для каждого из настраиваемых параметров. Однако оптимальные значения параметров зависят от совокупности клиентских запросов. Возьмем сервер, который получает запросы от большого числа клиентов, подключенных в Internet с помощью соединений с низкой пропускной способностью. Это является аргументом в пользу того, чтобы разрешить серверу иметь относительно большое количество активных процессов. Причины здесь две: во-первых, ограниченная пропускная способность клиентов требует от сервера передачи данных с низкой скоростью, т.е. на обслуживание каждого запроса уходит больше времени. Во-вторых, серверу нужно выполнить достаточно большое число последовательных передач, чтобы эффективно использовать свое подключение к Internet. Другой пример — сервер, который исполняет сценарий практически для каждого HTTP-запроса. Выполнение сценария требует значительных ресурсов процессора сервера. Для обеспечения разумпого времени отклика на клиентский запрос может потребоваться наложить относительно строгое ог- рагшчение на число одновременно выполняющихся процессов. Оптимизация производительности сервера и времени ожидания пользователей требует подбора настраиваемых параметров.

Сервер Apache имеет возможности настройки параметров, значения которых определяются сетевым соединением, обслуживаемым каждым из дочерних процессов. Протокол Transmission Control Protocol (TCP) координирует доставку сообщений с запросами и ответами, о чем подробнее пойдет речь в главе 5 (раздел 5.2). Родительский процесс прослушивает клиентские запросы для установления ТСР-соеди- непий. Когда все дочерние процессы обрабатывают соединения, операционная система поддерживает очередь ожидающих соедипепий. Сервер Apache накладывает ограничение на число соединений в очереди (ListenBacklog). Операциоипая система имеет буфер передачи для храпения исходящих данных для каждого установленного соединения. Сервер Apache может изменять размер этого буфера (SendBufferSize). Увеличение размера буфера передачи позволяет повысить производительность, особенно в случае большой задержки при обмене данными между сервером и клиентом. Наконец, сервер ограничивает число HTTP-запросов для одного ТСР-соединения (MaxKeepAliveRequests) и максимальное время, в течение которого соединение может оставаться неактивным (KeepAliveTimeout). При достижении одного из эгих ограничений клиентский процесс закрывает ТСР-соединение.

ПУЛЫ РЕСУРСОВ

Web-cepBep состоит из программных модулей, выполняющих различные задачи, такие как прослушивание новых соединений, синтаксический анализ запросов, создание ответов и передача сообщений-ответов. Подобно любому другому программному обеспечению, эти модули потребляют ресурсы операционной системы. Например, обработка запроса может потребовать от процесса выделепия памяти, доступа к файлам, создания дочернего процесса для исполпепия сцеиария, передачи данных через ТСР-соединение клиенту. Одна из основных проблем при разработке интенсивно работающего сервера — обеспечить, чтобы эти ресурсы операционной системы использовались эффективно. Проблемы возникают, когда прикладное программное обеспечение не освобождает эти системные ресурсы после завершения задачи. Если объем системных ресурсов со временем убывает, то активные процессы не смогут получить необходимые им ресурсы. Это неприемлемо для Web-сервера, который должен постоянно выполняться в течение долгого периода времени. Система должна возвращать ресурсы после завершения задач.

Сервер Apache решает эту проблему с помощью специальных пулов. Пул представляет собой структуру данных, которая отслеживает группу ресурсов операционной системы, создаваемых и уничтожаемых совместно. Допустим, что некорректный запрос привел к ошибке. Процесс, обрабатывающий запрос, может просто уничтожить соответствующий пул, чтобы вернуть ресурсы операционной системе для их использования другими модулями. Концепция пулов Позволяет оформить выделение и освобождение ресурсов в виде небольшого, удобпого для тестирования фрагмента программного обеспечения сервера. Это защищает сервер от программных ошибок или некорректных ситуаций, возникающих в других фрагментах кода. Концепция пулов осиовываегся на двух основных принципах: процедуры, поддерживающие концепцию пулов, будут работать корректно, а остальное программное обеспечение сервера должно выделять и освобождать ресурсы только с помощью механизма пулов.

Другие части программного обеснечеиия сервера взаимодействуют с пулами через интерфейс прикладного программирования (API). API содержит базовые функции для создания, инициализации или уничтожения пулов. Другие функции предоставляют информацию о доступных для пула ресурсах или о размещении ресурсов внутри пула. Например, пул, созданный для обработки клиентского запроса, может выделить намять для храпения сообщения HTTP-запроса и для создания сообщения HTTP-ответа. В API также имеются специальные функции для работы со строками. Это особенно полезно при построении заголовков НТТР-ответов. Например, серверному процессу может понадобиться скопировать информацию из клиентского запроса в другой буфер или сцепить две строки. После завершения обработки клиентского запроса процесс может очистить пул, чтобы освободить буфера, закрыть файлы и/или соединения. Завершение процесса также освобождает системные ресурсы, ассоциированные с пулом.

Обработка НТТР-запросов

Сервер Apache выполняет пять основных действий при обработке НТТР-заиро- ca: (1) преобразование запрошенного URL в путь к файлу в файловой системе сервера, (2) определение, имеет ли запрос разрешение на доступ к файлу, (3) идентификация и вызов обработчика для создания ответа, (4) передача ответа клиенту, (5) создапие записи о запросе в журпале [Tha96]. Каждая фаза запроса обрабатывается одним или несколькими программными модулями. Сервер Apache включает в себя иабор базовых модулей. Для обеспечения альтернативных способов выполнения каждой из фаз обработки запроса стороиними разработчиками могут быть нанисапы дополнительные модули. Сочетание открытого программного обеспечения и расширяемость модулей стало главным фактором, способствовавшим широкому распространению сервера Apache.

ПРЕОБРАЗОВАНИЕ URL В ПУТЬ В ФАЙЛОВОЙ СИСТЕМЕ СЕРВЕРА

На первом этапе обработки HTTP-запроса сервер преобразует URL в путь в файловой системе, если запрашиваемый файл в пей имеется. Это может представлять собой достаточно сложный процесс, который зависит от настроек сервера. Ядро программного обеспечения сервера выполняет предварительную работу по преобразованию URL. Например, на многих Web-сайгах пользователям разрешено создавать Web-страницы. URL http://www.bar.com/ peter может соответствовать пути /usr/users/peter/public_html/wwwfiles. Это подразумевает настройку сервера для выполнения функции преобразования для всех URL, содержащих символ "-". Серверу также может потребоваться выполнить предварительную обработку URL для удаления определенных строк. Например, http://www.bar.eom//a.html должно быть преобразовано в http://www.bar.eom/a.html путем удаления повторяющегося символа "/". Аналогично, http://www.bar.com/b/../a.html должно быть преобразовано в http://www.bar.eom/a.html при обнаружении подстроки "..".

Apache включает большое число настраиваемых программных модулей для преобразования URL. Каждый сервер имеет настраиваемый основной каталог, в котором размещаются файлы. Рассмотрим Web-cepBep www.bar.com с корневым каталогом /www. URL http://www.bar.com/foo.html будег преобразован в путь /www/ foo.html. Для хранения файлов в других каталогах сервером Apache используются псевдонимы. Псевдонимы предоставляют способ отделить структуру каталогов сервера от URL, видимых извне. В противном случае реорганизация файлов на сервере приводила бы к пекорректпости существующих URL. Кроме того, псевдопимы могут быть использованы для того, чтобы дать возможность нескольким URL ссылаться на один и тот же ресурс. Например, URL http://www.bar.com/~bala/kandr.ps и http://wWw.bar.com/~jrex/kandr.ps могут оба соответствовать файлу /ww^o- okl7.ps. Установка соответствия между URL и именем файла может также зависеть от времени получения запроса сервером. Например, сервер может быть настроен так, чтобы URL http://www.bar.eom/a.htmI соответствовал http://www.bar.com/mor- ning.html утром и http://www.bar.com/afternoon.html днем.

Программное обеспечение Apache включает дополнительный модуль для коррекции типичных ошибок в URL. Модуль может просматривать запрашиваемый каталог с целью выявить, нет ли в ней файла с именем, близким к запрашиваемому (это позволяет найти ошибки, связанные с лишиими или отсутствующими символами, использованием одного символа вместо другого, либо использованием неправильного регистра символов). Однако эта функция обусловливает дополнительную пагрузку, связанную со сканированием списка файлов в каталоге и идентификацией возможных совпадений. Кроме того, передача ответов на осиове частичного совпадения может непроизвольно «засветить» файл, который не предназначен для клиентских запросов. Сервер также имеет модуль, который переписывает запрашиваемые URL на осиове настраиваемого пабора правил. Модуль перезаписи использует при сипгаксическом анализе регулярные выражения для сопоставления с фрагментами строки URL. Действия могут различаться в зависимости от ряда параметров, включая заголовки HTTP-запросов. Например, сообщение НТТР-заиро- ca может включать заголовок User-Agent, который предоставляет информацию о браузере пользователя. Преобразование URL, основанное на этой информации, дает возможность серверу возвращать различные ресурсы пользователю в зависимости от используемого им браузера.

АВТОРИЗАЦИЯ ЗАПРОСА

Стратегии управления доступом зависят от настроек сервера. Например, доступ к ресурсу http://www.bar.eom/books/a.html может быть ограничен определенным кругом клиентов. Запросы, поступающие от определенных доменных имен или IP-адресов, могут быть отвергнуты, либо пользователям может быть предложено указать имя и пароль. Чтобы избежать задания стратегии управления доступом для каждого ресурса, можно применить одну стратегию для Группы ресурсов. Конфигурационные файлы состоят из директив, которые управляют доступом к Web- pecypcy в зависимости от URL, имени файла, каталога или виртуального сервера. Указание

<Directory /www/books>

AuthType Basic

AuthName specialuser

AutUserFile /www/let_them_in/users

require valid-user

</Directory>

ограничивает доступ к файлам в каталоге /www/books теми пользователями, которые укажут корректные имя и пароль для области specialuser. Файл /www/ let_them_in/users содержит список имен пользователей и их паролей (в зашифрованном виде). Указание

<Directory /www/cgi-bin>

order deny, allow

deny from all

allow from 10.9.57.188

</Directory>

разрешает доступ к ресурсам в каталоге /www/cgi-bin только Web-клиенту с IP-адресом 10.9.57.188.

Администратор Web-сайта может задавать эти стратегии в основном конфигурационном файле rio одной директиве в строке. Однако использование основного конфигурационного файла имеет два основных недостатка. Во-первых, внесение любого изменения в файл требует перезапуска сервера. Во-вторых, реализация стратегий управления доступом в интересах большого числа Web-страниц различных авторов может стать излишне обременительным делом для администратора сайта. Чтобы справиться с этими проблемами, администратор сайта может разрешить отдельным пользователям замещать настройки по умолчанию в основном файле. В каждом каталоге может иметься файл .htaccess, в котором можио задать стратегии управления доступом для этого каталога и всех его подкаталогов. Это дает возможность пользователю с именем Viv, хранящему файлы в каталоге /www/users/viv, создать файл /www/users/viv/.htaccess, который замещает стратегию доступа по умолчанию, заданную в каталоге /www/users. В основном конфигурационном файле Можно задать, какие директивы могут быть указаны в других файлах .htaccess. Это позволяет администратору сайта ограничивать стратегии управления доступом, применяемые отдельными пользователями.

Выяснив, что URL соответствует определенному файлу, сервер начинает процесс обхода каталогов, чтобы определить, какие стратегии управления доступом применить к запрашиваемому файлу. Сервер проверяет основной конфигурационный файл на наличие директив, применяемых к этому файлу. Затем сервер просматривает файлы .htaccess во вложенных подкаталогах. Для каталога /www/ users/viv сервер проверяет основной конфигурационный файл, затем /www/ users/.htaccess и /www/users/viv/.htaccess. На каждом этапе сервер может добавлять дополнительные директивы настройки, которые применяются к запрашиваемому файлу. Поскольку файлы .htaccess просматриваются для каждого запроса, иастройки могут быть изменены без перезапуска сервера. Однако поиск файла .htaccess в каждом подкаталоге приводит к повышению нагрузки на сервер при обработке запроса. Администратор сайта может уменьшить эти затраты, указав в основном конфигурационном файле подкаталоги, для которых разрешается замещать директивы.

СОЗДАНИЕ И ПЕРЕДАЧА ОТВЕТА

При синтаксическом анализе HTTP-запроса сервер создает и заполняет структуру данных записи запроса, которая используется различными программными модулями. Занись запроса содержит информацию из самого запроса, включая URL, версию протокола HTTP, тип содержимого и формат кодирования даииых, отправляемых клиентом в теле запроса (если таковые имеются). Запись имеет указатель на пул, который был выделен для обработки этого запроса; пул очищается, когда сервер заканчивает обработку запроса. Запись включает информацию, нолучеиную на предыдущих этапах обработки запроса: путь к файлу, ассоциированному с URL, список директив настройки, относящихся к ресурсу. Другие составляющие записи запроса, такие как заголовки HTTP-ответа, указываются, когда сервер генерирует сообщение-ответ.

В Apache имеется набор обработчиков (handlers), которые выполняют операции с запрашиваемым файлом. Эти обработчики представлены в таблице 4.3. Обработчик обычно назначается на основе расширения файла или его местоположения, что определяется настройками сервера. Программное обеспечение Apache содержит несколько встроенных обработчиков. Обработчик по умолчанию передает содержимое файла клиенту, добавляя необходимые HTTP-заголовки. Другой обработчик может посылать файл «как есть», включая HTTP-заголовки, имеющиеся в файле. Это полезно, например, для возврата предварительно созданного НТТР-сообще- ния, которое перенаправляет клиента в случае, если запрашиваемый ресурс был перемещен в другое место. Apache определяет обработчики для динамического содержания, которые трактуют файл как CGI-сцепарий, включение на стороне сервера или карту изображений, обрабатываемую на стороне сервера. Например, рассмотрим запрос

http://www.germancities.de/imagemap/count гу?163,83

где числа 163 и 83 отражают позицию курсора мыши, при щелчке мышью на карте изображений. Файл /www/imagemap/country связывает области изображения с URL. Чтобы обработать запрос, сервер идентифицирует URL, ассоциированный с координатами, и отправляет ответ, который указывает браузеру инициировать другой HTTP-запрос с повым URL. Файл также может быть интерпретировап как карта типов (type тар), которая содержит список имен файлов с различными вариантами ресурса (например, на английском или испапском языках). В зависимости от информации в заголовке запроса сервер определяет, какой файл и какие HTTP-заголовки возвращать клиенту. Другие обработчики имеюг отношение к управлению сервером, трактуя файл как хранилище настроечной информации.

Таблица 4.3. Встроенные обработчики и файловые расширения по умолчанию для сервера Apachc

Обработчик

Назначение (расширение файла)

default-handler

Передает файл как статическое содержимое

scnd-as-is

Передает файл как сообщение HTTP-ответа (.asis)

cgi-script

Активизирует файл как CGI-сцепарий (.cgi)

server-parsed

Трактует файл как включение на стороне сервера (.shtmI)

imap-filc

Трактует файл как файл карту изображений, обрабатываемую на стороне сервера (.imap)

type-map

Трактует файл как карту типов для альтернативной передачи содержания (.var)

server-info

Получает настроечную информацию о сервере

server-status

Получает отчет о состоянии сервера

Настройки сервера также задают, какие метаданные присутствуют в заголовке HTTP-ответа. Web-сервер ассоциирует определенные файловые расширения с определенными атрибутами ресурса. Сервер может иметь файл конфигурации, который определяет тип MIME (Multipurpose Internet Mail Extensions), ассоциированный с каждым файловым расширением:

application/octet-stream               bin exe pax tgz jar

application/pdf                        pdf

application/postscript                 ai eps ps

audio/x-pn-realaudio                   ram rm

audio/x-realaudio                       ra

image/gif                              gif

image/jpeg                             jpeg jpg jpe text/html  html htm

text/plain                              txt

video/mpeg                              mpeg mpg mpe

Например, URL, который соответствует файлу /www/index.html, будет инициировать обработчик по умолчанию default-handler, который передает содержимое файла клиенту. Файловое расширение .html заставит сервер включить в сообщение-ответ заголовок Content-Type: text/html. При получении ответа браузер использует заголовок Content-Type для выбора соответствующего приложения для отображения ответа, о чем говорилось ранее в главе 2 (раздел 2.4.3).

Интерпретация сообщения-ответа браузером также зависит от других метаданных, таких как формат кодирования и язык. Сервер назначает эти атрибуты на основе команд настройки, таких как

AddEncoding        x-compress           Z

AddEncoding        x-gzip              gz

AddLanguage        en                 .en

AddLanguage        fr                 .fr

AddLanguage        de                 .de

AddLanguage                it                  .it

Файл может иметь несколько расширений, каждое из которых соответствует различным метаданным. Например, файл /www/index.en.html.Z будет соответствовать сжатому HTML-файлу на английском языке. Настройки также определяют, содержит ли заголовок сообщения информацию, связанную с кэшированием. Предположим, что администратор сайта знает, что определенный набор ресурсов изменяется каждый депь в полдень. В этом случае сервер может быть настроен так, чтобы включать соответствующее время истечения срока актуальности в заголовок HTTP-ответа. Обратившийся с запросом клиент может воспользоваться этой информацией при принятии решения, как долго сохранять ответ в кэше.

Резюме

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

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100