Таненбаум Э. Распределенные системы. Принципы и парадигмы

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

11.1.

World Wide Web 711

Методы HTTP

HTTP разрабатывался

как

протокол общего назначения

для

архитектуры кли-

ент-сервер, ориентированный

на

передачу документов

обоих направлениях.

Клиент может запрашивать выполнение любой

из

операций, перечисленных

табл.

11.2, просто послав на сервер запрос с нужной операцией

(в

таблице пере-

числены наиболее часто используемые операции).

Таблица 11.2. Операции, поддерживаемые протоколом HTTP

Операция Описание

head Запрос на возвращение заголовка документа

get Запрос на возвращение клиенту документа

put Запрос на сохранение документа

post Данные, добавляемые к документу (набору)

del

ete Запрос на удаление документа

HTTP предполагает,

что

каждый документ может иметь ассоциированные

с ним метаданные, сохраняемые

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

латься вместе

запросом или ответом. Операция head посылается

на

сервер

том

случае, если клиент

не

хочет получать документ,

нуждается только

метадан-

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

кумента).

Эта

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

для

проверки правильности

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

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

Наиболее важная операция

—

get. Она

используется

для

извлечения доку-

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

что документ должен быть возвращен только

том случае, если

он

был изменен

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

иметь ассоциированные

ними теги, представляющие собой строки символов,

и извлекать документы, только если они содержат соответствующие теги.

Операция put противоположна операции get. Клиент может потребовать от сер-

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

с запросом). Разумеется, сервер не будет слепо выполнять операцию put, он при-

мет подобный запрос только

от

авторизованного клиента.

том,

как

работают

механизмы защиты, мы поговорим позже.

Операция post чем-то похожа

на

сохранение документов

за

исключением то-

го,

что

клиент может потребовать, чтобы данные были добавлены

документу

или набору документов. Типичный пример

—

посылка заметки

группу ново-

стей.

По

сравнению

операцией

put

особенность состоит

том,

что в

операции

post указывается,

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

Статья посылается вместе

запросом. В противоположность этому операция

put

пересылает документ

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

И, наконец, операция delete используется

для

того, чтобы сервер удалил до-

кумент

именем, которое содержится

сообщении, посланном серверу. Будет

произведено удаление

или

нет, зависит

от

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

Воз-

712 Глава 11. Распределенные системы документов

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

документа. В конце концов, сервер

—

это всего лишь пользовательский процесс.

Сообщения HTTP

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

ний. HTTP различает только два вида сообщений

—

сообщения-запросы и сооб-

щения-ответы. Как показано на рис. 11.5, а, сообщения-запросы состоят из трех

частей.

Строка запроса {request line)

имеет стандартный вид и определяет опера-

цию,

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

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

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

щений.

Операция

Имя заголовка сообщения

Разделитель

Ссылка

Значение

Версия Н Строка запроса

Имя заголовка сообщения Значение

Заголовки сообщения для запроса

Тело сообщения

Версия Н Код состояния

Имя заголовка сообщения

Фраза

Значение

Имя заголовка сообщения Значение

1 Строка состояния

Заголовки сообщения для запроса

Тело сообщения

Рис. 11.5. Сообщение-запрос (а). Сообщение-ответ (б)

11.1.

World Wide Web 713

Ответное сообщение начинается

строкой состояния

{status

line),

содержащей

номер версии и код состояния из трех цифр, как показано на рис. 11.5, 6. Код

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

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

ботан и имеет ассоциированную с ним фразу «ОК». Вот другие часто используе-

мые коды:

400 (Bad Request)

403 (Forbidden)

404 (Not Found)

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

головки. Так, например, если клиент отправляет запрос на операцию post с до-

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

с кодом состояния 405 (Method Not Allowed) и заголовком сообщения Allow, опре-

деляющим допустимые операции (например, head и get). Другой пример: клиент

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

мени Г, В этом случае клиент отправляет запрос get, дополненный заголовком

сообщения If-Modif1ed-S1nce с определенным значением Г.

В табл. 11.3 приведены некоторые корректные заголовки сообщений, которые

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

сами за себя, так что обсуждать их мы не будем.

Таблица 11.3- Некоторые заголовки сообщений HTTP

Заголовок

Источник Содержимое

Accept-Charset

Accept-Encoding

Accept-Language

Authorization

www-Authenticate

Date

ETag

Клиент

Сервер

Оба

Сервер

Expires

Сервер

From

Host

If-Match

If-None-Match

Клиент

Тип документов, которые клиент в состоянии

обрабатывать

Наборы символов, которые клиент может

воспринимать

Кодировки документов, которые клиент

в состоянии обрабатывать

Естественный язык, который понимает клиент

Список атрибутов авторизации клиента

Требование системы защиты, на которое клиент

должен отреагировать

Дата и время отправки сообщения

Теги,

ассоциированные с возвращаемым

документом

Время,

в течение которого полученная

информация будет соответствовать

действительности

Электронный адрес клиента

ТСР-адрес сервера документа

Теги,

которые следует иметь документу

Теги,

которые не следует иметь документу

продолжение^

714 Глава

11.

Распределенные системы документов

Таблица 11.3

(продолжение)

Заголовок Источник

Содержимое

If-Modified-Since Клиент

If-Unmodi f1ed-S1псе Клиент

Last-Modified

Location

Referer'

Upgrade

Warning

Сервер

Клиент

Оба

Возвратить документ, только если за время,

прошедшее с определенного момента,

он был изменен

Возвратить документ, только если за время,

прошедшее с определенного момента,

он не был изменен

Время последнего изменения возвращаемого

документа

Ссылка на документ, на которую клиент должен

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

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

документ клиента

Прикладной протокол, на который хочет

переключиться отправитель

Информация о состоянии данных, передаваемых

в сообщении

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

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

жет иметь средства для приема ответов, сжатых при помощи архиватора gzip,

доступного на большинстве машин под управлением Windows и UNIX. В этом

случае клиент может послать вместе со своим сообщением заголовок сообщения

Accept-Encoding, содержащий строку

Accept-Encoding:

gzip.

Точно так же заголовок

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

щать только web-страницы на языке HTML.

Имеется два заголовка сообщений, относящихся к средствам защиты, но, как

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

циальных протоколов транспортного уровня.

Заголовки сообщений Location и Referer используются для перенаправления

клиента к другому документу (отметим, что слово «Referer» в спецификации за-

писано с орфографической ошибкой). Перенаправление соответствует примене-

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

описывали в главе 4. Когда клиент посылает запрос на документ

Z),

сервер может

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

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

ссылки на D' клиент может добавить заголовок сообщения Referer со ссылкой на Д

чтобы показать, чем было вызвано перенаправление. Обычно этот заголовок со-

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

Заголовок сообщения Upgrade позволяет перейти на другой протокол. Так,

например, клиент и сервер могут вначале использовать протокол НТТР/1.1 —

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

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

по безопасной версии HTTP

—

протоколу SHTTP

[378].

Для этого сервер дол-

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

11.1.

World Wide Web 715

11.1.3.

Процессы

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

—

браузеры, при помо-

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

их на своем мониторе, и web-серверы, которые обрабатывают запросы браузеров.

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

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

мер сценариями CGI. Далее мы рассмотрим типичные для Web программы кли-

ента и сервера.

Клиенты

Наиболее важные клиенты Web

—

это программы, называемые web-браузерами

{Web

browser),

которые позволяют пользователям путешествовать по web-стра-

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

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

жет легко выделять их одиночным щелчком мыши.

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

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

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

ные комплексы.

Одна из проблем, с которой сталкиваются разработчики web-браузеров, со-

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

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

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

дули расширения. Модули расширения {plug-ins) — это небольшие программы,

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

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

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

лем с удаленного сервера.

Модули расширения предоставляют браузеру стандартный интерфейс и са-

ми,

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

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

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

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

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

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

ния удаляются из браузера.

Другой часто используемый клиентский процесс [275] носит название web-

заместитель

{Web proxy). Изначально, как показано на рис. 11.7, этот процесс

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

колами, кроме HTTP. Так, например, для получения файлов с FTP-сервера бра-

узер мог послать HTML-запрос к своему локальному заместителю по FTP, ко-

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

HTTP.

716 Глава

11.

Распределенные системы документов

Интерфейс браузера

для модулей расширения

гп

Хи-

Браузер

ОС

J3 Z

ее

S г

-^^ч

Q-I

Расширяемые модули

подгружаются

при необходимости

Интерфейс модуля Локальная

расширения для браузера файловая система

Рис. 11.6. Использование модуля расширения в web-браузере

Браузер

Запрос HTTP

Ответ HTTP

Web-заместитель

Запрос FTP

Ответ FTP

FTP-сервер

Рис. 11.7. Использование web-заместителя, если браузер не понимает протокола FTP

В настоящее время большинство web-браузеров в состоянии поддерживать

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

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

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

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

кальному web-заместителю. До того как связываться с удаленным сервером, где

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

жится ли он в локальном кэше.

Серверы

Как мы говорили, web-сервер

—

это программа, которая обрабатывает входящие

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

В качестве конкретного примера мы кратко рассмотрим общую структуру

сервера

Apache,

основного web-сервера на платформах UNIX.

Общая структура web-сервера Apache показано на рис. 11.8. Сервер состоит

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

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

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

проса.

Для каждого приходящего запроса модуль ядра образует запись запроса с по-

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

с HTTP-запросом заголовков, для заголовков ответа HTTP и т. д. Любой модуль

работает с этой записью, считывая и изменяя соответствующие поля. В конце

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

11.1.

World Wide Web

717

из них вернет запрошенный документ клиенту. Отметим, что в принципе каж-

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

Модуль Модуль

DQD

1DDD

Логический поток

управления

Модуль

Обработчик

Ядро

^>|

Apache

Запрос I • Ответ

Рис. 11.8. Общая структура web-сервера Apache

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

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

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

обработчиков

(handlers),

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

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

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

поля этой записи.

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

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

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

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

ботчики зарегистрированы для этой фазы, и вызывает один из них. Фазы пере-

числены ниже.

Разрешение ссылки на документ в локальное имя файла.

Аутентификация клиента.

Контроль доступа клиента.

Контроль доступа запроса.

Определение типа MIME ответа.

6. Общая фаза обработки.

Пересылка ответа.

8. Протоколирование данных по обработке запроса.

Ссылки предоставляются в виде

унифицированного идентификатора

ресурса

{Uniform Resource

Identifier,

URI), о котором мы поговорим ниже. Существует не-

сколько способов разрешения URI. Во многих случаях частью URI является имя

локального файла данного документа. Однако когда документ генерируется, на-

пример, при помощи программы CGI, URI будет содержать информацию о про-

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

метров этой программы.

Вторая фаза

—

это аутентификация клиента. В принципе она подразумевает

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

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

718 Глава

11,

Распределенные системы документов

При контроле доступа клиента сервер проверяет, известен ли на самом деле

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

мы можем определить, принадлежит ли этот клиент к определенной группе поль-

зователей.

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

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

На следующей фазе производится определение типа MIME документа. Опре-

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

файлов или с помощью специального файла, содержащего тип MIME документа.

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

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

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

мых ссылок

ИЛР1

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

Наконец, ответ пересылается пользователю. И снова сделать это можно раз-

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

ответ.

Последняя фаза включает в себя протоколирование всех действий, совершен-

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

пользовать в самых разных целях.

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

ванных обработчиков каждой фазы. Он выбирает обработчик и вызывает его.

Обработчик может отклонить запрос, обработать его или сообщить об ошибке.

Если обработчик отклоняет запрос, это означает, что он не в состоянии его обра-

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

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

батывается и начинается следующая фаза обработки. Если обработчиком возвра-

щается сообщение об ошибке, обработка запроса прекращается и клиенту возвра-

щается сообщение об ошибке.

Какие модули войдут в состав сервера Apache на самом деле, определяется во

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

ядра выполняет всю обработку запросов, и в этом случае сервер «сжимается» до

уровня простого web-сервера, который способен обрабатывать только HTML-

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

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

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

конфигурирования и программирования сервера Apache можно найти в

[257].

Кластеры серверов

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

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

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

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

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

ний интерфейс

[150].

Этот принцип иллюстрирует

рис.

11.9 и представляет собой

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

11.1.

World Wide Web

719

Web-сервер

Web-серввр Web-сервер

СЛ

Web-сервер

YTJT

Внешний

интерфейс

Запрос

гг

Локальная сеть

Внешний интерфейс

обрабатывает все входящие

запросы и исходящие ответы

Ответ

Рис. 11.9. Принципы использования кластера рабочих станций

для реализации web-службы

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

—

это организация внешнего

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

сти.

Обычно вводится подразделение на внешние интерфейсы, играющие роль

переключателей транспортного уровня, и внешние интерфейсы уровня приложе-

ний.

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

ет с сервером соединение TCP. Переключатель транспортного уровня просто пе-

ресылает данные через соединение TCP одному из серверов в зависимости от из-

меренной загрузки серверов. Основной недостаток такого подхода состоит в том,

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

через соединение TCP. Он может только на основании данных о загрузке серве-

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

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

распределение запросов

с извест-

ным

содержимым

(content-aware request

distribution),

при котором внешний ин-

терфейс сначала просматривает пришедший HTML-запрос, а затем решает, на

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

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

[499].

Распределение запросов с известным содержимым имеет несколько досто-

инств. Так, например, если внешний интерфейс всегда пересылает запросы на

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

этот документ, результатом чего станет резкое сокращение времени отклика.

Кроме того, фактически можно разделить набор документов между серверами,

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

зволяет более эффективно использовать имеющиеся емкости накопителей и вы-

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

ких как аудио- или видеозаписи.

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

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

Для повышения производительности в [339] был предложен механизм, посред-

ством которого соединение TCP переключается непосредственно на сервер. В ре-

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

как показано на рис. И.

10,

а. Переключение соединения TCP полностью про-

720 Глава

11.

Распределенные системы документов

зрачно для клиента; клиент посылает свои сообщения по TCP внешнему интер-

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

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

Одно логическое

соединение TCP

Ответ

Клиент

Web-сервер

Запрос

Внешний

интерфейс

^ Запрос

(переданный)

Web-сервер

Клиент

6. Сервер посылает ответ

5. Пересылка

прочих сообщений

Другие

сообщения

Запрос

на установку

соединения

Web-сервер

Дистрибьютор

Переключатель

3. Передать

соединение TCP

4. Информировать

переключатель

Послать дистрибьютору

запрос на установку

соединения

Дистрибьютор

Web-сервер

Диспетчер

выбирает сервер

Рис. 11.10. Переключение соединения TCP (а). Масштабируемый кластер

web-серверов с известным содержимым (б)

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

терфейса и переключателя транспортного уровня так, как излагается в [18]. В ва-

рианте с переключением соединения TCP внешний интерфейс решает две задачи.

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

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

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

лученные по соответствующему переключаемому соединению TCP.

Эти две задачи можно распределить так, как показано на рис. 11.10, б. Диспет-

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

а дистрибьютор отслеживает входящий по TCP трафик в поисках нуждающихся

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

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

Web,

его сообщение, предназначенное для установления соединения TCP, пере-