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

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

Часть

П.

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

Web

3.3.

применение прокси-серверов

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

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

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

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

3.3.1.

Совместный доступ к Web

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

им возможность осуществлять совместный доступ к Web. Клиенты совместно осу-

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

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

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

одно соединение. Альтернативой может служить установка отдельных соединений

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

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

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

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

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

смысле

локальным

соединением (т.е. расстояние в сети между ними небольшое), а

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

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

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

ты,

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

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

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

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

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

решение делать это, большинство пользователей провайдеров Internet и поставщи-

ков информационного содержимого (таких как America Online) осуществляют вы-

ход в Internet через прокси-серверы. Ряд таких прокси-серверов являются кэши-

рующими прокси-серверами.

3.3.2. Кэширование ответов

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

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

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

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

рует ответ, который и будет возвращен). Кэширование подробно рассматривается

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

т.е.

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

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

кси-серверы в Internet играют роль некэширующих прокси-серверов. Не все клиен-

ты получают выигрыш от наличия кэширующего прокси-сервера. Например, если

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

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

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

ентов. Для большинства ответов вероятность, что они снова будут востребованы.

Глава 3. Прокси-серверы 81

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

ров имеют ограниченный объем дискового пространства для кэширования ответов,

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

ществляющими сканирование Web-ресурсов.

3.3.3.

Анонимизация клиентов

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

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

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

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

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

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

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

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

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

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

(например, связанную с состоянием здоровья), и могут не захотеть раскрывать

себя. Конечно, прокси-серверу известно, какой клиент осуществляет доступ к ре-

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

данную информацию. Обычно организации, поддерживающие прокси-серверы,

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

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

в Web отдельных клиентов.

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

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

имени которого пересылается сообщение. В общем случае, хотя прокси-серверы

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

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

• Первый фрагмент информации

—

это заголовок User-Agent, присутствующий

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

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

• Второй фрагмент информации

—

это данные, используемые для идентифика-

ции состояния сеанса клиента. Эти данные часто хранятся в cookies (о чем

шла речь в разделе 2.6 главы 2) или в других полях идентификатора сеанса,

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

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

пень анонимности. Исходным серверам не известны IP-адреса компьютеров

клиентов, поскольку запросы приходят через прокси-сервера. Хотя cookies не

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

анонимизации, обеспечиваемую прокси-сервером.

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

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

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

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

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

Часть

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

Web

3.3.4. Преобразование ответов

запросов

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

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

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

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

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

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

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

висимости от запросов и от ответов.

Прокси-сервер может также преобразовывать запрос вне зависимости от воз-

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

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

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

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

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

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

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

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

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

ответ в более современном формате. Преобразования не оказывает влияния на се-

мантику запроса или ответа.

3.3.5.

Шлюзы к системам, не являющимся

HTTP-серверами

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

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

обеспечения беспрепятственного доступа к ресурсам в Internet. Важно, что про-

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

может действовать как промежуточное звено между Web-клиентом и FTP-серве-

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

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

сылается обратно клиенту. Однако вследствие того, что Web-клиент и FTP-сервер

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

клиента в РТР-запрос и переформатировать ответ FTP-сервера в HTTP-ответ. Та-

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

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

пример, FTP), может сделать эту задачу достаточно сложной.

Предположим, что Web-клиент посылает запрос FTP-серверу ftp://ftp.re-

search.att.eom/F через прокси-сервер. Запрос, направляемый прокси-серверу,

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

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

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

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

чае протокола FTP прокси-сервер должен сначала установить FTP-соединение,

действуя как FTP-клиент. В отличие от HTTP, в FTP для взаимодействия между

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

чем более подробно рассказывается в главе 5 (раздел 5.4.2). Таким образом, про-

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

Глава

Прокси-серверы

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

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

к серверу электронной почты с целью получения почтового ресурса М. На рис. 3.2

показано, как прокси-сервер выступает в качестве шлюза к FTP-серверу и серверу

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

FTP-сервер

Клиент 1

Клиент 2

Клиент 3

Сервер

электронной почты

Рис. 3.2. Прокси-сервер, действующий в качестве шлюза к FTP,

HTTP-серверам и серверам электронной почты

С точки зрения Web-клиента был сделан Web-запрос ресурса ftp://ftp.re-

search.att.eom/F, после чего ресурс F был получен. Этапы обработки FTP-занро-

са

—

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

и закрытие соединения ~ выполняются прокси-сервером. Прокси-сервер должен

возвратить файл Web-клиенту в виде HTTP-ответа с соответствующим кодом от-

вета и HTTP-заголовками ответа.

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

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

Socket Layer (SSL) прокси-сервер действует как туннель. SSL выполняет шифрова-

ние содержимого сообщения. Прокси-сервер передает биты сообщения в обоих на-

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

жет нарушать требования к конфиденциальности, которые предъявляются к SSL.

Даже если прокси-серверу разрешено было «увидеть» лишь унифицированный

указатель ресурса (URL), это уже может нести некоторую информацию, снижаю-

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

«увидеть» прокси-сервер при работе с SSL,

—

это адрес целевого сервера и номер

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

прокси-серверов. Подробнее о SSL рассказывается в главе 6 (раздел 6.4).

3.3.6. Фильтрация запросов и ответов

Прокси-сервер исполняет роль «стража», отфильтровывая ненадлежащие запросы

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

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

ответы на основе определенных их параметров, например, размера ответа. Организа-

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

посещение определенных сайтов, например, развлекательных (т.е. игровых сайтов,

сайтов с анекдотами, порнографических сайтов), электронных аукционов и сайтов по

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

тов,

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

работке таких запросов, отправляя сообщение об ошибке. Сравнение может выпол-

няться по полному URL (например, http://www.uiiitedmeclia.com/dilbert), но чаще

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

вера (www.umtedmedia.com). При фильтрации вполне очевидна возможность излиш-

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

низации могут иметься вполне разумные причины для посещения «запретных» сай-

тов.

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

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

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

кси-сервер ~ это специализированное программное средство, поэтому он допускает

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

{фимер, Netnanny, SurfWatch и др.), которые фильтруют запросы к нежелательным

сайтам, сопоставляют запрашиваемый URL с набором шаблонов. Другой причиной,

1Ю

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

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

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

для других клиентов.

Фильтрация запросов на основе URL

—

это только один из примеров использо-

вания фильтрации. Другой пример

—

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

при указании определенных ключевых слов в строке поиска. Это заставляет про-

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

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

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

ции запросов

—

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

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

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

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

ние заголовков в сообщении-запросе.

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

содержащие да1Н1ые в форматах, вызывающих подозрения. Некоторые вирусы пе-

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

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

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

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

ются программы. В качестве примеров можно привести апплеты Java или сценарии

JavaScript. Интеллектуальный прокси-сервер способен выполнять проверки таких

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

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

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

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

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

Глава 3. Прокси-серверы

3.4. Роль прокси-серверов в обработке

запросов и ответов HTTP

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

тов HTTP. Начнем мы с рассмотрения различных этапов передачи запросов и ответов,

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

вером. Далее мы посмотрим, как прокси-сервер обрабатывает запросы и ответы. После

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

Web-сервера. Затем мы рассмотрим роль прокси-сервера в качестве Web-клиента и

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

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

3.4.1.

Этапы обмена запросами и ответами при наличии

прокси-сервера

На рис. 3.3 представлены этапы взаимодействий, имеющие место при наличии

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

версия примера, представленного на рис. 2.1 (глава 2, раздел 2.3).

После того, как пользователь выбрал URL, браузер обращается к серверу до-

менных имен (DNS) для определения IP-адреса прокси-сервера, для работы с кото-

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

(этапы 1 и 2). HTTP-запрос, поступивший от браузера (этап 3), заставляет про-

кси-сервер обратиться к DNS за IP-адресом исходного сервера (этап 4). Браузер и

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

навливает ТСР-соединеиие с исходным сервером, а затем посылает HTTP-запрос

исходному серверу (этапы 5 и 6). Ответ от исходного сервера направляется обрат-

но прокси-серверу, который пересылает его браузеру (этапы 7 и 8). На этой стадии

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

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

лельные соединения с исходным сервером (этапы 9 и 10).

Запрос

KDNS

3. HTTP-запрос

8. HTTP-ответ

|t:::::::::::::::{|

Дополнительные

параллельные

соединения

5. ТСР-соединени(

6. HTTP-запрос

7. HTTP-ответ

10.

Дополнительные]

параллельные

соединения

}

Рис.

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

прокси-сервера

Часть

II.

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

Web

3.4.2. Обработка запросов и ответов HTTP

Поскольку прокси-сервер является ключевым компонентом при выполнении

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

ла HTTP. В главе 7 (раздел 7.11) мы обсудим особые правила, определяющие пове-

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

синтаксических и семантических требований. Синтаксические требования обычно

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

фикацией имеющихся заголовков. Семантические требования включают в себя

корректную обработку запросов и ответов, а также поддержку ограничений, дейст-

вующих при возврате кэширова1Н1ых ответов.

Прокси-сервер будет передавать любые заголовки HTTP-сообщений, которые

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

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

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

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

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

через прокси-сервер. В последней версии протокола (HTTP/1.1) все прокси-серве-

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

—

необхо-

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

Изменение номера версии. Прокси-сервер может изменять строку запроса

(первую строку HTTP-запроса), которая включает метод запроса, URI и номер

версии. Например,

GET /foo/bar.html НТГР/1.0

заголовок, отправленный клиентом, может быть заменен прокси-сервером НТТР/1.1 на

GET /foo/bar.html НИР/1.1

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

нить новые возможности НТТР/1.1 (см. главу 7) к сообщению, передаваемому меж-

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

лее старой версией протокола. Если сообщение получено прокси-сервером от отпра-

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

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

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

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

HTTP-сообщения. Если прокси-сервер изменяет номер версии, некоторые поля заго-

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

—

остаться неизменными. Для пере-

сылки запросов должны быть соблюдены дополнительные требования НТТР/1.1.

В главе 6 (раздел 6.5) подробно обсуждается, как должным образом интерпретиро-

вать номера версий HTTP.

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

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

ную информацию о ресурсе. Например, это может быть время, прошедшее с того

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

Семантическая нейтральность. Одной из сложных задач, которые стоят перед

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

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

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

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

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

Глава

Прокси-серверы

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

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

кэша),

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

туннель и «вслепую» переслать запрос, получив сообщение, которое он не может

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

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

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

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

формирования ответа. Ответ может генерироваться динамически. В этом случае

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

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

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

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

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

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

сурсов прокси-сервера. Риск занесения в буфер прокси-сервера очень больших объе-

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

к передаче сообщений, была прописана особенно тщательно. В главе 7 (раздел 7.6)

эта проблема обсуждается более подробно.

Управление состоянием и стратегии поведения. Действуя как игггерфейс для

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

ных приходящих запросов и ответов. Прокси-сервер не может закрыть соединение,

пока обмен по нему не будет закончен. Если пользователь щелкает мышью на кноп-

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

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

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

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

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

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

чае,

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

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

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

Чтобы прокси-сервер эффективно функционировал в качестве промежуточного

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

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

пому серверу и клиенту. Тогда как исходные серверы принимают и отвечают на

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

единения и состояния соединений, ассоциированные с многими клиентами и сер-

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

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

вер,

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

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

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

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

шей вероятностью повторно воспользуется своим соединением с прокси-сервером.

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

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

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

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

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

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

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

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

не будет обработан. Позже он может занести информацию о запросе в системный

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

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

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

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

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

пока не будут закрыты некоторые из старых соединений. Аналогично, поскольку

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

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

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

рассказано в главе 4 (раздел 4.4).

Работа с cookies. В главе 2 (раздел 2.6) мы узнали, как клиент использует

cookies. В главе 4 (раздел 4.4) мы увидим, как серверы работают с cookies. По-

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

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

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

на ресурс исходному серверу S через прокси-сервер Р. Исходный сервер S отправ-

ляет cookie в заголовке Set-Cookie обычным образом. С точки зрения исходного

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

Прокси-сервер передает заголовок Set-Cookie клиенту для сохранения [КМОО].

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

зует URL для принятия решения, какой cookie включить в свой заголовок Cookie.

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

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

правлении. Таким образом простое присутствие прокси-сервера на маршруте не

влияет на семантику cookies и для клиента, и для сервера. Однако Web-сервер мо-

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

пример, можно указать, чтобы заголовок Set-Cookie не кэшировался (см. главу 7,

раздел 7.3.3, где описаны различные механизмы для управления кэшированием).

3.4.3.

Прокси-сервер в роли Web-сервера

Когда прокси-сервер играет роль Web-сервера, его главное назначение — при-

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

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

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

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

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

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

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

имеется ли ответ в его кэше. Если прокси-сервер не может найти ответ в кэше, он

должен ответить сообщением об ошибке.

Если требования отвечать локально не предъявляется, прокси-сервер проверяет,

имеется ли ответ в его кэше и является ли ответ актуальным. В противном случае

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

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

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

Глава 3. Прокси-серверы 89

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

кси-сервером, ответ может быть помещен в кэш.

Рассмотрим рис. 3.3 в предположении, что запросы клиента проходят через про-

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

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

foo.html ресурсов, допустим, что

foo2.gif.

Получив запрос на ресурс

foo2.gif,

про-

кси-сервер ищет ресурс в своем кэше. Если ресурс найден в кэше, прокси-серверу

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

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

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

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

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

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

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

—

так курс акций нель-

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

С точки зрения клиента прокси-сервер ведет себя как исходный сервер. Глав-

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

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

к клиенту, чем исходный сервер. Между кэширующим прокси-сервером и исход-

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

вероятность возникновения узких мест в сети.

3.4.4, Прокси-сервер в роли Web-клиента

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

ру. Существуют две причины, по которым прокси-сервер пересылает запрос:

• Прокси-сервер является кэширующим прокси-сервером, но он не может удов-

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

• Прокси-сервер не является кэширующим прокси-сервером или явным обра-

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

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

ту. Ему нужно определить IP-адрес исходного сервера, обратившись к DNS-серве-

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

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

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

жет также отправить прокси-серверу запросы на эти ресурсы. Прокси-сервер обра-

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

запрос, получает ответы от сервера и пересылает ответы клиенту.

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

с клиентом. Так, прокси-сервер может иметь лучшее подключение к Internet, чем

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

сии протокола, чем клиентом. Это главным образом обусловлено тем, что новые

версии браузеров распространяются быстро и бесплатно. Обновление программно-

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

в настоящее время в Web имеется гораздо больше пользовательских агентов и

Web-серверов, чем прокси-серверов, работающих под HTTP/1.1. Если версия про-

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

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

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