Кришнамурти Б., Рексфорд Дж. Web-протоколы. Теория и практика

Подождите немного. Документ загружается.

120 Часть IL Компоненты программного обеспечения Web

http://www.bar.com/index.html означает обращение к ресурсу /index.html на вир-

туалыюм сервере www.bar.com. При отправке HTTP-запроса Web-клиент должен

определить IP-адрес Web-сервера. На первых порах существования Web каждый

виртуальный сервер должен был иметь собственный IP-адрес, чтобы гарантиро-

вать,

что клиентский HTTP-запрос дойдет до нужного сервера. Например, серве-

рам www.foo.com и www.bar.com могли быть присвоены адреса 10.63.127.8 и

10.63.127.9, соответственно, несмотря на то, что два виртуальных сервера выполня-

ются на одном компьютере.

Многие операционные системы предусматривают поддержку назначения мно-

жества IP-адресов одному сетевому интерфейсу. Трафик, отправленный на один из

таких адресов, достигает нужного компьютера; затем операционная система на-

правляет данные соответствующему виртуальному серверу. Такой подход эффек-

тивен, но не слишком производителен. Во-первых, операционная система может

накладывать ограничения на число серверных процессов или на число IP-адресов

для одного компьютера. Во-вторых, назначение отдельного IP-адреса каждому

Web-серверу приводит к нерациональному использованию дефицитных в настоя-

щее время ГР-адресов. Быстрый рост числа Web-сайтов в 90-х годах прошлого века

обострил обе эти проблемы. Это вызвало необходимость внесения изменений

в протокол HTTP, разрешающих нескольким виртуальным серверам иметь один и

тот же IP-адрес, о чем пойдет речь в главе 7 (раздел 7.8).

4.5.2.

Несколько компьютеров для одного Web-сайта

Наиболее популярные Web-сайты получают чрезвычайгю большое число кли-

ентских запросов, которые не могут быть обслужены одним компьютером. Обслу-

живание большого потока запросов обычно требует репликации содержания на не-

скольких компьютерах. Простейший способ репликации содержания — это выде-

лить отдельное домегнюе имя для каждой реплики. Предположим к примеру, что

имеется Web-сайт, на котором размещено для загрузки пользователями новое про-

граммное обеспечение, например, последняя версия Web-браузера. Пользователь

может выбирать из списка один из сштов-зеркал. Это помогает распределить на-

грузку между сайтами. В списке также может быть указано географическое место-

положение различных реплик, давая возможность пользователю получать содер-

жимое с ближайшего сервера. Это снижает нагрузку на сеть и уменьшает задержку

при загрузке содержания. При загрузке больших программных пакетов эти пре-

имущества перевешивают неудобства, связанные с необходимостью для пользова-

теля выбирать реплику вручную.

Однако наличие отдельного сервера для каждой реплики имеет несколько недос-

татков. Ручной выбор сервера утомителен для пользователя, особенно при просмот-

ре Web-содержания. В идеале репликация содержания на различных компьютерах

должна быть незаметной для пользователя. Ручной выбор не обязательно равгюмер-

ио распределяет нагрузку. Отдельный пользователь не осведомлен о решениях, при-

нятых другими пользователями, или о текущей загрузке серверов. Наличие различ-

ных доменных имен для каждой реплики порождает ситуацию, когда несколько

URL ссылаются на одно и то же содержание. Рассмотрим Web-страницу bar.html,

которая реплицирована на два сервера: wwwl.big.com и www2.big.com. Предполо-

жим, что ресурс http://wwwl.big.com/bar.html был сохранен в кэше браузера.

В дальнейшем пользователь может выдать запрос па ресурс http://www2.big.com/

bar.html. Однако браузер не знает, что этот URL ссылается на то же самое содержи-

мое и, следовательно, не сможет вернуть кэшированное содержимое.

Глава 4. Web-серверы

121

Использование одного доменного имени для всех реплик устраняет эти пробле-

мы.

Однако при этом требуется эффективный способ доставки клиентского запро-

са к отдельной реплике. Простейший подход состоит в том, чтобы назначить раз-

личные IP-адреса каждой из реплик. Например, www.big.com может быть разме-

щен на двух компьютерах с IP-адресами 10.198.3.47 и 10.198.3.48, соответственно.

Преобразование доменного имени сервера в определенный IP-адрес выполняется

сервером доменных имен (DNS), о чем будет рассказано в главе 5 (раздел 5.3.5).

При альтернативном подходе имя www.foo.com может быть ассоциировано с од-

ним IP-адресом, который соответствует серверу-заместителю, расположегнюму пе-

ред комплексом Web-хостипга, как показано на рис. 4.1. Этот сервер-заместитель

может принимать решения, какая реплика будет обрабатывать клиентский запрос.

Выбор реплики может основываться на различных критериях, таких как нагрузка

на серверы или запрашиваемые URL. В настоящее время ведутся исследования по

разработке оптимальной стратегии выбора реплики, о чем подробнее будет гово-

риться в главе И (раздел 11.13).

в/из Internet

www.foo.com

www.bar.com

www.big.com

1 www.

mid.

com

Рис.

4.1. Хостииговая система с сервером-заместителем перед четырьмя

Web-серверами

Репликация одного и того же содержания па нескольких серверах сопровождает-

ся рядом проблем. Последовательность запросов от одного и того же клиента может

не быть обработана одной и той же репликой. Чрезвычайно важно, чтобы каждая ре-

плика генерировала один и тот же ответ па один и тот же запрос. Каждый сервер

должен иметь однозначное соответствие между URL и содержанием, а также выда-

вать идентичный HTTP-ответ. Если содержание изменяется, новые данные должны

быть доступны от каждой реплики. Если сервер извлекает ресурсы из собствегпюй

файловой системы, любое изменение в файле требует обновления каждой реплики.

Кроме того, реплики должны иметь одинаковые стратегии управления доступом.

Пользователю не должен быть разрешен доступ к ресурсу для одной реплике и за-

прещен для другой. Это требует, чтобы па каждым сервере имелась одинаковая ин-

формация об имени пользователя и пароле, а также одинаковая стратегия управле-

ния доступом. Ана7югично, если Web-сайт использует cookies, реплики должны

иметь соглашение о том, как их генерировать и интерпретировать.

122

Часть

П. Компоненты программного обеспечения Web

4.6.

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

Чтобы проиллюстрировать работу Web-сервера, мы рассмотрим практический

пример использования популярного, свободно распространяемого сервера Apache

[Ара, LL99J. Выпущенная в 1995 г. первая версия (0.6.2) сервера Apache была осно-

вана на созданном ранее Web-сервере NCSA [KBM94J. Название Apache было свя-

зано с тем, что разработчики широко используют технологию «программных за-

платок» (patches), и является сокращением от "а patchy server". Программное обес-

печение было разработано несколькими добровольцами, образовавшими группу

Apache Group [MFHOO]. Сервер Apache в настоящее время является наиболее по-

пулярным Web-сервером [Netc]. Также широко используется коммерческое про-

граммное обеспечение Web-серверов, главным образом разработагнхых Microsoft и

Netscape, которое нашло наибольшее применение при создании больших коммер-

ческих Web-сайтов.

В этом разделе мы познакомимся с основными возможностями версии 1.3.3 сер-

вера Apache. Установка сервера Apache состоит в простом копировании соответст-

вующих исполняемых файлов на компьютер. Однако в большинстве случаев

Web-администраторы приспосабливают программное обеспечение к требованиям

своих сайтов. Эта настройка обычно заключается в задании параметров, которые

влияют на выделение ресурсов, интерпретацию HTTP-запросов, генерацию заго-

ловков HTTP-ответов, управление доступом и регистрацию действий сервера.

В этом разделе мы постараемся в общих чертах рассказать, как работает Web-сер-

вер,

а также проиллюстрировать, какие возможности настройки доступны админи-

стратору сайта. Хотя обсуждение будет посвящено серверу Apache, многое из ска-

занного можно отнести и к другим Web-серверам.

4.6.1.

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

Сервер Apache 1.3.3 назначает отдельный процесс каждому соединению, в про-

тивоположность недавно разработанному серверу Apache 2.0, который реализован

как мпогопоточный. Ресурсы размещаются в динамических областях (пулах), кото-

рые автоматически освобождаются после завершения процесса.

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

Сервер Apache использует модель с управлением по процессам с главным про-

цессом, который назначает процесс каждому новому соединению. Вместо того что-

бы создавать повът процесс для каждого нового соединения, процесс-родитель

создает несколько дочерних процессов при запуске сервера. Количество начальных

дочерних процессов (StartServers) представляет собой один из параметров па-

стройки, относящихся к дочерним процессам. Эти параметры приведены в табли-

це 4.2. Сервер поддерживает баланс между слишком большим и слишком малень-

ким числом процессов. Сервер накладывает ограничение па число одновременно

выполняющихся процессов (MaxClients), которое задается при компиляции про-

граммгюго обеспечения Web-сервера. Теоретически сервер может всегда работать

с данным числом процессов, даже если большинство из них неактивны и ожидают

новых соединений. Наличие неактивных процессов позволяет избежать затрат на

создание новых процессов при поступлении дополнительных запросов. Однако на-

личие большого числа неактивных процессов приводит к нерациональному ис-

пользованию ресурсов онерациопной системы.

Глава

Web-серверы

123

Сервер Apache накладывает ограничения на минимальное и максимальное ко-

личество неактивных процессов (MinSpareServers и MaxSpareServers). Каждые

несколько секунд родительский процесс определяет, сколько дочерних процессов

являются неактивными. Затем родитель создает или завершает дочерние процессы,

в зависимости от того, является ли это число слишком маленьким или слишком

большим. Уничтожение неактивных процессов возвращает операционной системе

ресурсы, которые могут быть использованы активными процессами, и сокращает

нагрузку на систему. Если количество неактивных процессов мало, создание новых

процессов подготавливает сервер к обслуживанию будущих клиентских запросов.

Порождая дополнительные процессы до поступления запросов, сервер гарантирует,

что создание процесса не задержит обработку новых клиентских запросов. Такой

подход к созданию и завершению процессов является эффективным способом до-

биться компромисса между относительно небольшим числом неактивных процес-

сов и созданием новых процессов. Помимо периодического удаления неактивных

процессов, сервер Apache накладывает настраиваемое ограничение на количество

НТТР-занросов, обрабатываемых каждым дочерним процессом (MaxRequests-

PerChild). Дочерний процесс завершается при достижении этого ограничения.

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

и сетевых соединений

Параметр

StartServers

MaxClients

MinSpareServers

MaxSpareServers

MaxRequestsPerChild

ListenBacklog

SendBufferSize

MaxKeepAliveRequests

KeepAliveTimeout

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

1.3.3)

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

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

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

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

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

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

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

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

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

оставаться неактивным (15 с)

Сервер Apache имеет определенные значения по умолчанию для каждого из на-

страиваемых параметров. Однако оптимальные значения параметров зависят от со-

вокупности клиентских запросов. Возьмем сервер, который получает запросы от

большого числа клиентов, подключенных в Internet с помощью соединений с низ-

кой пропускной способностью. Это является аргументом в пользу того, чтобы раз-

решить серверу иметь относительно большое количество активных процессов.

Причины здесь две: во-первых, ограниченная пропускная способность клиентов

требует от сервера передачи данных с низкой скоростью, т.е. на обслуживание каж-

дого запроса уходит больше времени. Во-вторых, серверу нужно выполнить доста-

точно большое число последовательных передач, чтобы эффективно использовать

свое подключение к Internet. Другой пример ~ сервер, который исполняет сцена-

рий практически для каждого HTTP-запроса. Выполнение сценария требует значи-

тельных ресурсов процессора сервера. Для обеспечения разумного времени откли-

ка на клиентский запрос может потребоваться наложить от1юсительно строгое ог-

124 Часть II. Компоненты программного обеспечения Web

рапичение на число одновременно выполняющихся процессов. Оптимизация

производительности сервера и времени ожидания пользователей требует подбора

настраиваемых параметров.

Сервер Apache имеет возможности настройки параметров, значения которых оп-

ределяются сетевым соединением, обслуживаемым каждым из дочерних процессов.

Протокол Transmission Control Protocol (TCP) координирует доставку сообщений

с запросами и ответами, о чем подробнее пойдет речь в главе 5 (раздел 5.2). Роди-

тельский процесс прослушивает клиентские запросы для установления ТСР-соеди-

пепий. Когда все дочерние процессы обрабатывают соединения, операционная систе-

ма поддерживает очередь ожидающих соединений. Сервер Apache накладывает огра-

ничение на число соединений в очереди (ListenBacklog). Операционная система

имеет буфер передачи для хранения исходящих данных для каждого установленного

соединения. Сервер Apache может изменять размер этого буфера (SendBufferSize).

Увеличение размера буфера передачи позволяет повысить производительность, осо-

бенно в случае большой задержки при обмене данными между сервером и клиентом.

Наконец, сервер ограничивает число HTTP-запросов для одного ТСР-соединепия

(MaxKeepAliveRequests) и максимальное время, в течение которого соединение мо-

жет оставаться неактивным (KeepAliveTimeout). При достижении одного из этих ог-

раничений клиентский процесс закрывает ТСР-соединение.

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

Web-сервер состоит из программных модулей, выполняющих различные задачи,

такие как прослушивание новых соединений, синтаксический анализ запросов, соз-

дание ответов и передача сообщений-ответов. Подобно любому другому программ-

ному обеспечению, эти модули потребляют ресурсы операционной системы. На-

пример, обработка запроса может потребовать от процесса выделения памяти, дос-

тупа к файлам, создания дочернего процесса для исполнения сценария, передачи

данных через ТСР-соединение клиенту. Одна из основных проблем при разработке

интенсивно работающего сервера — обеспечить, чтобы эти ресурсы операционной

системы использовались эффективно. Проблемы возникают, когда прикладное

программное обеспечение не освобождает эти системные ресурсы после заверше-

ния задачи. Если объем системных ресурсов со временем убывает, то активные

процессы не смогут получить необходимые им ресурсы. Это неприемлемо для

Web-сервера, который должен постоянно выполняться в течение долгого периода

времени. Система должна возвращать ресурсы после завершения задач.

Сервер Apache решает эту проблему с помощью специальных пулов. Пул пред-

ставляет собой структуру данных, которая отслеживает группу ресурсов операци-

онной системы, создаваемых и уничтожаемых совместно. Допустим, что некоррект-

ный запрос привел к ошибке. Процесс, обрабатывающий запрос, может просто

уничтожить соответствующий пул, чтобы вернуть ресурсы операционной системе

для их использования другими модулями. Концепция пулов позволяет оформить

выделение и освобождение ресурсов в виде небольшого, удобного для тестирова-

ния фрагмента программного обеспечения сервера. Это защищает сервер от про-

граммных ошибок или некорректных ситуаций, возникающих в других фрагментах

кода. Концепция пулов основывается на двух основ1Ш1х принципах: процедуры,

поддерживающие концепцию пулов, будут работать корректно, а остальное про-

граммное обеспечение сервера должно выделять и освобождать ресурсы только

с помощью механизма пулов.

Другие части программного обеспечения сервера взаимодействуют с пулами че-

рез интерфейс прикладного программирования (API). API содержит базовые

Глава 4. Web-серверы 125

функции для создания, инициализации или уничтожения пулов. Другие функции

предоставляют информацию о доступных для пула ресурсах или о размещении ре-

сурсов внутри пула. Например, пул, созданный для обработки клиентского запро-

са, может выделить память для храпения сообщения HTTP-запроса и для создания

сообщения HTTP-ответа. В API также имеются специальные функции для работы

со строками. Это особенно полезно при построении заголовков HTTP-ответов. На-

пример, серверному процессу может понадобиться скопировать информацию из

клиентского запроса в другой буфер или сцепить две строки. После завершения об-

работки клиегггского запроса процесс может очистить пул, чтобы освободить буфе-

ра, закрыть файлы и/или соединения. Завершение процесса также освобождает

системные ресурсы, ассоциированные с пулом.

4.6.2.

Обработка HTTP-запросов

Сервер Apache выполняет пять основных действий при обработке HTTP-запро-

са: (1) преобразование запрошенного URL в путь к файлу в файловой системе сер-

вера, (2) определение, имеет ли запрос разрешение на доступ к файлу, (3) иденти-

фикация и вызов обработчика для создания ответа, (4) передача ответа клиенту,

(5) создание записи о запросе в журнале [Tha96J. Каждая фаза запроса обрабаты-

вается одним или несколькими программными модулями. Сервер 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.eom/b/../a.html должно быть

преобразовано в http://www.bar.eom/a.html при обнаружении подстроки "..".

Apache включает большое число настраиваемых программных модулей для пре-

образования URL. Каждый сервер имеет настраиваемый основной каталог, в кото-

ром размещаются файлы. Рассмотрим Web-сервер 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 и

126

Часть

П. Компоненты программного обеспечения Web

http://w\vw.bar.com/~jrex/kandr.ps могут оба соответствовать файлу /www/bo-

17.ps.

Установка соответствия между URL и именем файла может также зависеть

от времени получения запроса сервером. Например, сервер может быть настроен так,

чтобы URL http://www.bar.eom/a.html соответствовал http://www.bar.com/mor-

ning.html утром и http://www.bar.com/aftemoon.html днем.

Программное обеспечение Apache включает дополнительный модуль для кор-

рекции типичных ошибок в URL. Модуль может просматривать запрашиваемый

каталог с целью выявить, нет ли в ней файла с именем, близким к запрашиваемому

(это позволяет найти ошибки, связанные с лишними или отсутствующими симво-

лами, использованием одного символа вместо другого, либо использованием непра-

вильного регистра символов). Однако эта функция обусловливает дополнительную

нагрузку, связанную со сканированием списка файлов в каталоге и идентификаци-

ей возможных совпадений. Кроме того, передача ответов на основе частичного сов-

падения может непроизвольно «засветить» файл, который не предназначен для

клиентских запросов. Сервер также имеет модуль, который переписывает запраши-

ваемые URL на основе настраиваемого набора правил. Модуль перезаписи исполь-

зует при синтаксическом анализе регулярные выражения для сопоставления

с фрагментами строки URL. Действия могут различаться в зависимости от ряда па-

раметров, включая заголовки HTTP-запросов. Например, сообщение НТТР-занро-

са может включать заголовок User-Agent, который предоставляет информацию о

браузере пользователя. Преобразование URL, основанное на этой информации,

дает возможность серверу возвращать различные ресурсы пользователю в зависи-

мости от используемого им браузера.

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

Стратегии управления доступом зависят от настроек сервера. Например, доступ

к ресурсу http://www.bar.eom/books/a.html может быть ограничен определенным

кругом клиентов. Запросы, поступающие от определенных доме1Н1ых имен или

IP-адресов, могут быть отвергнуты, либо пользователям может быть предложено

указать имя и пароль. Чтобы избежать задания стратегии управления доступом

для каждого ресурса, можно применить одну стратегию для группы ресурсов. Кон-

фигурационные файлы состоят из директив, которые управляют доступом к Web-

ресурсу в зависимости от URL, имени файла, каталога или виртуального сервера.

Указание

AuthType Basic

AuthName specialuser

AutUserFile /www/let_them_in/users

require valid-user

</Directory>

ограничивает доступ к файлам в каталоге /www/books теми пользователями, кото-

рые укажут корректные имя и пароль для области specialuser. Файл /www/

let_them_in/users содержит список имен пользователей и их паролей (в зашифро-

ванном виде). Указание

order deny,allow

deny from all

allow from 10.9.57.188

</Directory>

Глава

Web-серверы

127

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

с IP-адресом 10.9.57.188.

Администратор Web-сайта может задавать эти стратегии в основном конфигу-

рационном файле но одной директиве в строке. Однако использование основного

конфигурационного файла имеет два основных недостатка. Во-первых, внесение

любого изменения в файл требует перезапуска сервера. Во-вторых, реализация

стратегий управления доступом в интересах большого числа 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 содержит не-

сколько встроенных обработчиков. Обработчик по умолчанию передает содержи-

128

Часть

П. Компоненты программного обеспечения Web

мое файла клиенту, добавляя необходимые HTTP-заголовки. Другой обработчик

может посылать файл «как есть», включая HTTP-заголовки, имеющиеся в файле.

Это полезно, например, для возврата предварительно созданного HTTP-сообще-

ния, которое перенаправляет клиента в случае, если запрашиваемый ресурс был

перемещен в другое место. Apache определяет обработчики для динамического со-

держания, которые трактуют файл как CGI-сценарий, включение на стороне серве-

ра или карту изображений, обрабатываемую на стороне сервера. Например, рас-

смотрим запрос

http://www.germancities.de/imagemap/country7163,83

где числа 163 и 83 отражают позицию курсора мыши, при щелчке мышью на карте

изображений. Файл /www/imagemap/country связывает области изображения

с URL. Чтобы обработать запрос, сервер идентифицирует URL, ассоциированный

с координатами, и отправляет ответ, который указывает браузеру инициировать

другой НТТР-запрос с новым URL. Файл также может быть интерпретирован как

карта типов (type тар), которая содержит список имен файлов с различными ва-

риантами ресурса (например, на английском или испанском языках). В зависимо-

сти от информации в заголовке запроса сервер определяет, какой файл и какие

HTTP-заголовки возвращать клиенту. Другие обработчики имеют отношение

к управлению сервером, трактуя файл как хранилище настроечной информации.

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

для сервера Apache

Обработчик

default-handler

scnd-as-is

cgi-script

server-parsed

imap-filc

type-map

server-info

server-status

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

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

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

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

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

Трактует файл как файл карту изобрал<ений, обрабатываемую на

стороне сервера (.imap) |

Трактует файл как карту типов для альтернативной передачи

содержания (.var) |

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

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

Настройки сервера также задают, какие метаданные присутствуют в заголовке

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

Глава

Web-серверы

129

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

AddEncoding

x-gzip

AddLanguage

en .en

AddLanguage

fг .fr

AddLanguage

de .de

AddLanguage

it .it

Файл может иметь несколько расширений, каждое из которых соответствует раз-

личным метаданным. Например, файл /www/index.en.html.Z будет соответство-

вать сжатому HTML-файлу на английском языке. Настройки также определяют,

содержит ли заголовок сообщения информацию, связанную с кэшированием. Пред-

положим, что администратор сайта знает, что определенный набор ресурсов изме-

1шется каждый день в полдень. В этом случае сервер может быть настроен так, что-

бы включать соответствующее время истечения срока актуальности в заголовок

HTTP-ответа. Обратившийся с запросом клиент может воспользоваться этой ин-

формацией при принятии решения, как долго сохранять ответ в кэше.

4.7.

Резюме

в процессе создания и передачи ответов на клиентские запросы Web-сервер вы-

полняет множество важных задач. Сервер связывает URL в сообщении-запросе

с определенным файлом в файловой системе и определяет, как генерировать сооб-

щение-ответ. Кроме того, сервер принимает решение, следует ли разрешить доступ

к ресурсам для запроса. Создание ответа на запрос может состоять в извлечении

запрашиваемого файла с диска или в активизации сценария, генерирующего ответ.

Сценарий может создавать ответ на основе пользовательских cookies и информа-

ции, хранимой во внутренней базе данных, без участия Web-сервера. Сервер не

обязательно сохраняет какую-либо информацию между последовательными запро-

сами, хотя сохранение информации может уменьшить затраты при обработке буду-

щих запросов. Активно работающий сервер обычно одновременно обрабатывает за-

просы от большого числа клиентов. При настройке сервера на обслуживание пото-

ка клиентских запросов требуется учитывать архитектуру сервера. Ограничения,

свойственные архитектурам с управлением по событиям и с управлением по про-

цессам, привели к созданию гибридных схем. Обслуживание большого потока об-

ращений к популярному Web-сайту требует репликации содержания на несколько

компьютеров. И наоборот, несколько менее популярных сайтов могут быть разме-

щены на одном компьютере.