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

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

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

того,

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

Internet динамически предоставляет IP-адрес при соединении пользователя с In-

ternet. Теоретически сайт может потребовать от пользователя указания уникально-

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

для пользователя и вызвать у пего раздражение.

Вместо этого можно указать браузеру включать уникальный cookie в каждый

HTTP-запрос. Вернувшись к нашему примеру, предположим, что Web-сервер получа-

ет HTTP-запрос на ресзфс http://www.bar.com/book.cgi?name=Noam+Chomsky. За-

прос содержит cookie. Сервер вызывает сценарий /www/book/cgi и передает cookie

через переме1Н1ую окружения НТТР_СООК1Е. Сценарий может использовать cookie

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

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

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

ра cookie представляет собой произвольную строку символов. Сценарий же, со своей

стороны, связывает с этой строкой определенный смысл. В простейшем случае строка

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

пользователя или числовой код. Если запрос не содержит cookie, сценарий может соз-

дать 1ЮВЫЙ cookie и включить его в заголовок сообщения-ответа

Set-Cookie: Customer="user17"; Version="1"; Path="/book"

Последующие запросы от этого пользователя будут содержать cookie

Cookie: Customer="user17"; Version="1"; Path="/book"

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

модействии с внутренней базой данных. Например, сайт электрогнюй коммерции

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

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

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

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

рий, взаимодействующий с базой данных.

В других ситуациях cookie может содержать дополнительную информацию, та-

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

для динамического создания Web-содержимого, настраиваемого на основе указан-

ных атрибутов. Например, Web-cтpaIIицa может содержать персональное приветст-

вие,

включающее имя пользователя. Cookie может также содержать информацию о

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

ленной информации в cookie может избавить от необходимости сохранять инфор-

мацию о пользователе во внутренней базе данных. Например, в cookie сайта элек-

тронной коммерции может храниться текущий список заказанных пользователем

товаров. Допустим, па сайте электронной коммерции пользователь заполняет раз-

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

ных товаров, что заставляет браузер послать НТТР-занрос, содержащий cookie, ас-

социированный с этим Web-сайтом. Сценарий создает сообщение-ответ, включаю-

щий в себя заголовок

Set-Cookie: Order="Chomsky_Bio"; Version="1"; Path="/book"

Затем пользователь добавляет в список еще одну книгу, что инициирует HTTP-за-

прос,

включающий в себя

Cookie: Customer="user17"; Version="1"; Path='7book"

Order="Chomsky_Bio"; Version="1"; Path="/book"

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

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

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

иметь слишком большие размеры. Браузер может не разрешать хранения cookie,

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

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

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

ных на сервере.

Браузер трактует cookie как строку, передаваемую от имени пользователя. Одна-

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

или модифицировать cookies. Предположим, что Web-сайт не позволяет пользовате-

лю загрузить определенный ресурс, если HTTP-запрос не содержит cookie. Пользо-

ватели могут сформировать свои собствегпшю cookies, чтобы не допустить отслежи-

вания сайтом их запросов. Кроме того, один пользователь может «позаимствовать»

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

вете Set-Cookie. Обратившись к предыдущему примеру, мож1Ю предположить, что

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

строку user 17 на userS. Здесь userS соответствует корректному пользователю. Чтобы

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

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

от своего имени. Как часть обработки запроса сценарий может осуществлять провер-

ку cookie на корреьсгность. Хотя это предотвращает использование фиктивных

cookies, все еще остается риск, что пользователь воспользуется cookie, принадлежа-

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

быть назначено время жизни. По истечении времени жизни cookie пользователю не-

обходимо принять новый cookie для получения доступа к сайту.

4.3.

Совместное использование информации

несколькими запросами

Хотя Web-сервер обрабатывает каждый запрос независимо, он может сохранять

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

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

или часть HTTP-ответа в оперативной памяти для дальнейшего использования.

Аналогично, сервер может сохранять информацию, сформированную в процессе

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

вить клиенту устаревшую информацию.

4.3.1.

Совместное использование HTTP-ответов

несколькими запросами

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

ботке большинства запросов. Сервер может уменьшить издержки па обработку этих

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

жим, что сервер получает запрос на ресурс http://www.bar.com/foo.html, представ-

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

и прочитать файл, соответствующий этому URL. При чтении файла данные копиру-

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

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

112

Часть

П.

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

Web

/foo.html не должен вызывать повторное открытие и чтение файла. Вместо этого

сервер может передать данные непосредственно из оперативной памяти. Это называ-

ется

кэшированием

на

стороне

сервера,

поскольку данные с диска кэшируются в опе-

ративной памяти сервера.

Кэширование ресурса на Web-сервере несколько отличается от кэширования

в браузере или в прокси-сервере. С целью увеличения производительности сервер

храпит данные в оперативной памяти. Серверу необходимо убедиться, что копия

в оперативной памяти совпадает с данными, хранящимися на диске. Если содержи-

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

тивной памяти. Чтобы избежать передачи устаревшего ответа, сервер может прове-

рить время последней модификации файла на диске до возврата кэшированной ко-

пии; если файл был изменен, сервер может удалить кэшированную копию из

оперативной памяти. Альтернативой является уведомление сервера системой о

том, что файл был модифицирован. При этом сервер удаляет кэшированное содер-

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

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

Кроме кэширования статических файлов, Web-сервер может также сохранять

в оперативной памяти динамически генерируемые ответы. Рассмотрим Web-сайт,

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

перссылки на Web-страницы, содержащие ее. Многие запросы пользователей со-

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

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

сов в оперативной памяти. Сервер может обработать результаты, соответствующие

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

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

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

того,

как просмотрит первую. Сервер может сформировать вторую страницу иа ос-

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

генерировать содержимое второй Web-страницы «с нуля». Кэширование динами-

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

для сайтов, задача которых в основном состоит в динамическом формировании от-

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

нужно обеспечить, чтобы кэшировагнхый результат был актуальным. Добавление

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

полнения предыдущих запросов из оперативной памяти.

4.3.2.

Хранение метаданных между запросами

в дополнение к кэшированию Web-ресурсов, сервер может сохранять информа-

цию,

сформированную в процессе обработки HTTP-запроса, одним из следующих

способов.

• Преобразование URL в путь к файлу в файловой системе. Сервер должен

установить соответствие между URL в сообщении-запросе и путем к файлу

в файловой системе сервера. Кэширование результатов преобразования избав-

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

того же URL. Однако сервер должен гарантировать, чтобы кэшированная ин-

формация была актуальной; внесение изменений в настройки сервера может

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

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

• Управляющая информация о ресурсе. Сервер может также кэшировать деск-

риптор файла, идентифицирующий местонахождение файла в файловой сис-

теме. Кроме того, сервер может кэшировать основные атрибуты файла, такие

как размер и время последней модификации. Это сокращает затраты на по-

строение заголовка HTTP-ответа для будущих запросов на этот же ресурс.

Однако сервер должен гарантировать, что кэшированные атрибуты не будут

использоваться, если файл будет изменен.

• Заголовки HTTP-ответа. Сервер может кэшировать часть заголовка HTTP-

ответа. Многие заголовки в сообщении-ответе несут в себе атрибуты запраши-

ваемого ресурса (например, размер, тип содержимого и время последней мо-

дификации). Кэширование этих заголовков избавляет сервер от необходимо-

сти формировать их при обработке будущих запросов. Однако сервер не дол-

жен кэшировать весь заголовок ответа, поскольку некоторые поля (например,

дата/время ответа) могут измениться с момента предыдущего запроса па тот

же ресурс.

Кэширование информации между последовательными ответами для одного и

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

больше запросов.

Помимо кэширования информации между несколькими запросами на один и

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

сов на различные ресурсы:

• Текущие дата/время. Текущие дата/время присутствуют в заголовке HTTP-

ответа и в журнале сервера. Определение текущего времени требует активиза-

ции системного вызова (например, gettimeoJdayQ в UNIX), что сказывается на

увеличении загрузки сервера. Значение времени в заголовке указывается

с точностью до секунды. В то же время сервер за секунду может обработать

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

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

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

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

действии. Однако кэширование результатов системного вызова в течение дос-

таточно большого времени может ограничить точность информации о значе-

нии времени, записываемом в журнал сервера.

• Доменное имя клиента. В некоторых случаях обработка запроса может зави-

сеть от доменного имени клиента, сделавшего запрос. Например, сервер может

ограничить доступ к ресурсу или произвести настройку ответа для клиентов

из определенных доменов (например, .edu или .competitor.com). Преобразо-

вание IP-адреса в доменное имя компьютера клиента требует от сервера акти-

визации системного вызова (например, gethostbyaddrQ). За счет кэширования

этой информации сервер может избежать повторения процесса преобразова-

ния IP-адреса в имя для будущих запросов с того же IP-адреса. Однако через

некоторое время IP-адрес и доменное имя могут перестать соответствовать

друг другу.

Кэширование информации между запросами на разные ресурсы позволяет по-

высить эффективность работы сервера.

114

Часть

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

4.4.

Архитектура сервера

Web-сервер обычно обрабатывает множество клиентских запросов одновремен-

но.

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

вой и оперативной памяти, сетевому интерфейсу сервера. В этом разделе мы обсу-

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

скими запросами. Сервер с управлением по событиям осуществляет обработку

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

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

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

ства каждого из этих подходов. Хотя указанные подходы были достаточгю подроб-

но исследованы и до появления Web, выбор архитектуры сервера оказывает суще-

ственное влияние на производительность.

4.4.1.

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

Простейшим подходом является сервер с единственным процессом, который об-

служивает один запрос за раз. Процесс принимает клиентский запрос, генерирует и

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

расширением для Web-сервера, обрабатывающего запросы в одном процессе, являет-

ся переключение с одного обрабатываемого запроса на другой. Вместо того чтобы

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

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

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

большого объема работы. Обработка Web-запроса легко подразделяется на неболь-

шое количество действий: соединение с клиентом, чтение HTTP-запроса, нахожде-

ние соответствующего ресурса и передача ответа. Во многих случаях сервер может

завершить каждое из этих действий за короткий период времени.

Однако некоторые из этих действий могут породить задержки, неподконтрольные

Web-серверу. Например, сервер не может начать генерировать ответ, пока не будет по-

лучено сообщение-запрос от клиента. Точ1Ю так же, извлечение данных с диска может

задержать передачу сообщения-ответа. Ожидая завершения операции, сервер должен

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

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

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

дач,

относящихся к сетевым соединениям и операциям с дисковой памятью. Чтобы

избежать ожидания завершения выполнения этих задач, Web-сервер с управлением

по событиям обычно осуществляет неблокирующие системные вызовы, которые по-

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

ной системы. При завершении выгюлнения системной операции возбуждается собы-

тие,

которое должно быть обработано серверным процессом.

В любой заданный момент времени сервер может иметь одно или более собы-

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

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

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

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

ра. После получения клиентского запроса и преобразования URL в путь к файлу

в файловой системе сервер инициирует событие для извлечения соответствующего

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

работать другой запрос. Обработка всех запросов в одном процессе дает возмож-

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

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

одни и те же данные. Это особенно важно применительно к Web, поскольку

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

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

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

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

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

дагн1ых разными запросами. Предположим, например, что два пользователя выда-

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

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

Выполнение запросов в одном лхроцессе с управлением по событиям имеет

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

жет превышать некоторого значения. Например, синтаксический анализ HTTP-за-

проса представляет собой относительно простую задачу. Однако другие операции,

такие как ожидание получения НТТР-занроса, могут обусловить длительную за-

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

ность серверному процессу обрабатывать в это время другие запросы. Тем не менее,

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

сание серверного программного обеспечения, которое позволяет явно переключаться

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

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

нерируемые Web-ответы обычно требуют от сервера выполнения сценария. Сервер

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

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

держкам для других запросов. Вместо этого следует вьпюлнять сценарий в отдель-

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

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

держки операционной системой неблокирующих системных вызовов. Поддержка не-

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

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

фейсом, обладают хорошим быстродействием. Взаимодействие с дисковой подсисте-

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

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

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

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

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

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

большинство высокопроизводительных Web-серверов не используют подобную ар-

хитектуру. Несмотря па это, некоторые экспериментальные Web-серверы реализуют

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

по событиям, находят применение в других архитектурах.

4.4.2.

Архитектура серверов с управлением по процессам

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

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

отдельный процесс выполняет все действия по обработке данного запроса. Выполне-

ние множества процессов дает серверу возможность обрабатывать множество запро-

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

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

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

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

выполняет процесс некоторый период времени (допустим, 10 мс или 100 мс), преж-

де чем переключиться на другой процесс. При этом создается впечатление, что каж-

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

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

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

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

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

который прослушивает новые клиентские соединения. Для каждого нового соеди-

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

После синтаксического анализа клиентского запроса и передачи ответа процесс за-

вершается. Завершение процесса после обработки запроса защищает систему от оп-

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

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

называется утечкой памяти. При завершении процесса операционная система ав-

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

дает возможность разработчикам сосредоточиться на базовой составляющей сер-

верного программного обеспечения (синтаксический анализ запросов и создание

ответов). Большинство первых Web-серверов следовали этой модели, в том числе

серверы CERN и NCSA [KMR95].

Затраты на создание и завершение процесса составляют значительную часть ра-

боты при обработке HTTP-запроса для небольшого статического ресурса. Для сни-

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

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

нового соединения главный процесс предоставляет существующий, неактивный

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

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

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

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

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

сценарии, написанные сторонними программистами. Такое программное обеспече-

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

завершать процесс после обработки определеппого числа запросов. В качестве аль-

тернативы Web-сервер может воспользоваться одним из усовершенствованных ме-

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

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

нии Web-сервера Apache в разделе

4.6.1.

Несмотря на повышение производительности, которое достигается при исполь-

зовании пула заранее созданных процессов, подход с управлением по процессам

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

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

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

личные таблицы и списки перед загрузкой информации о следующем процессе;

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

хранятся в одном процессе. В модели с управлением по процессам переключение

с одного процесса на другой может потребовать загрузки данных с диска в опера-

тивную намять, или из оперативной памяти в кэш процессора. Большинство

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

ду процессами составляет достаточно большую часть работы, выполняемой серве-

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

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

совместное использование данных. Каждый процесс представляет собой отдельную

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

полняется для относительно небольшого числа ресурсов. Хранение этих часто за-

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

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

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

мяти требует координации между процессами.

4.4.3,

Серверы с гибридной архитектурой

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

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

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

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

но.

Фактически каждый процесс при этом становится сервером с управлением по со-

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

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

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

гюму процессу. Однако такой подход сохраняет ряд недостатков, присущих подхо-

дам с управлением по событиям и с управлением по процессам. Подобно серверам

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

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

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

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

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

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

сами. Тем не менее, обслуживание нескольких запросов в одном процессе сокращает

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

внутри процесса.

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

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

мых программных потоков^. Каждый нрохраммгшш поток вьпюлняется в адресном

пространстве породившего его процесса. Многопоточный Web-сервер может создать

программный 1ЮТ0К для каждого запроса. Сервер будет иметь один процесс, подобно

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

подобно серверу с управлением по процессам. В отличие от сервера с управлением по

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

профаммными потоками явным образом. Когда один программный поток выполняет

блокирующий системный вызов, в том же процессе MOiyr выполняться другие про-

фаммные потоки. Затраты на переключение между нрофаммгшхми потоками сущест-

венгю меньше, чем на перек/почение между процессами, гюскольку профаммные по-

токи в процессе совместно используют адресное пространство процесса. Это дает воз-

можгюсть профаммным потокам совместно использовать и информацию о запросах.

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

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

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

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

Иногда программный поток (thread) называют облстчсипым или легковесным процес-

сом.

—

Прим.

ред.

118

Часть

II.

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

Web

ной задачей. Программные потоки, выполняющиеся в одгюм процессе, не защищены

друг от друга; без тщательной координации один программный поток может испор-

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

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

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

личных платформах.

Третий подход объединяет явные преимущества моделей с управлением по со-

бытиям и с управлением по процессам в гибридной схеме [PDZ99]. Подход

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

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

Web-запросы порождают короткие сообщения-ответы, не требующих доступа

к дисковой памяти. Допустим, клиент запросил несуществующий ресурс. Распо-

знав,

что URL не соответствует какому-либо файлу или сценарию на сайте, сервер

отвечает коротким сообщением об ошибке. Кроме того, на сервере в оперативной

памяти может быть кэшировано множество часто используемых Web-ответов, что

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

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

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

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

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

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

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

операции, требующий много времени, вспомогательному процессу. Процесс

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

щие системные вызовы.

4.5.

Размещение Web-серверов

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

на отдельном компьютере. Однако это не всегда так. На практике на одном компь-

ютере может быть размещено содержимое многих Web-сайтов. Кроме того, попу-

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

4.5.1.

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

На первых порах существования Web отдельные лица и учреждения, желающие

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

ном компьютере. Администрирование Web-сайтов осуществлялось локально. По

мере коммерциализации Internet все чаще используется подход, при котором

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

панией. Компания, занимающаяся Web-хостингом, может иметь группу компьюте-

ров в одном или в нескольких местах. Разделение ролей создателя содержания и

хостинг-провайдера имеет несколько преимуществ.

• Хостинговая компания берет на себя всю заботу по эксплуатации Web-серве-

ров,

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

нимающихся обслуживанием Web-серверов.

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

• Хостинговая компания обеспечивает вычислительную и сетевую инфраструк-

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

формационного содержания от необходимости приобретения оборудования и

программного обеспечения.

• Хостинговая компания может разложить затраты на вычислительные и сете-

вые ресурсы на большое число Web-сайтов.

• Владелец содержания защищен от риска раскрыть свои конфиденциальные

данные в Internet, разрешив доступ к своим компьютерам. Кроме того, трафик

к и от Web-сайта не создает нагрузку на IP-сеть организации.

Однако владелец содержания становится существенно зависимым от хостинго-

вой компании в плане предоставления эффективного и надежного доступа к Web-

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

ствий с хостинговой компанией.

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

возможность создателям содержания обновлять его. Многие Web-сайты не слиш-

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

оперативной памяти компьютера. Некоторые сайты очень часто посещаемы в опре-

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

мер,

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

кательные сайты

—

в вечернее время. Размещение нескольких Web-серверов на од-

гюм компьютере позволяет хостинговой компании эффективно снижать затраты.

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

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

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

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

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

сайтов на одном компьютере позволит эффективно использовать и процессор, и

дисковую подсистему.

При размещении и обслуживании нескольких сайтов на одном компьютере тре-

буется иметь способ направления клиентских запросов соответствующему сайту.

Пусть компания hostmany.com размещает содержание, предоставляемое компания-

ми foo.com и bar.com, на одном компьютере. Самый простой подход

—

иметь компь-

ютер,

выполняющий один сервер www.hostmany.com, который принимает запросы,

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

наборы файлов на диске, а все URL должны начинаться с http://www.hostmany.com/

foo/

или с http://www.hostmany.com/bar/ для указания, к какому набору файлов на

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

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

предпочитает иметь собственные доменные имена, зарегистрированные в Internet. На-

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

www.foo.com и www.bar.com.

Чтобы позволить использование отдельных доменных имен, хостинговая компа-

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

Такие серверы называются виртуальными серверами. Каждый виртуальный сервер

имеет свое собственное дерево документов, параметры настройки и работает, как

если бы он был единственным Web-сервером на компьютере. Предположим, что

серверы www.foo.com и www.bar.com выполняются на одгюм и том же компьюте-

ре.

Запрос http://www.foo.com/index.html будет означать обращение к ресурсу

/index.html на виртуальном сервере www.foo.com, в то время как запрос