Роль прокси-серверов в НТТР/1.1

Одним из решающих улучшений в НТТР/1.1 было осознание той важпой роли, которую играют промежуточные компоненты между отправителем и получателем. Хотя тупиели и шлюзы также являются промежуточными компонентами, наиболее важным промежуточным компонентом является прокси-сервер. Роль прокси-сер- вера стала центральной в архитектуре Web. Структура и детали организации про- кси-серверов были изложены в главе 3. В частности, вопросы, относящиеся к прокси-серверу как к программе, обрабатывающей запросы и ответы HTTP, были рассмотрены в главе 3 (раздел 3.4.2). Чтобы сосредоточить впимапие на той роли, которую играют прокси-серверы, мы разделили обсуждение внесенных измепеиий на четыре части, следующим образом.

•   Типы прокси-серверов.

•   Синтаксические требования, предъявляемые к прокси-серверам в НТТР/1.1.

•   Семантические требования, предъявляемые к прокси-серверам в НТТР/1.1.

•   Влияние других компонентов Web на прокси-серверы в НТТР/1.1.

Типы прокси-серверов

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

•          Прокси-сервер действует в качестве посредника с другими системами, поддерживая ряд протоколов, таких как WAIS, FTP или Gopher.

•          Прокси-сервер работает по протоколу HTTP и является промежуточным компонентом между отправителем и получателем НТТР-сообщений.

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

Для прокси-серверов, действующих в качестве посредников с другими системами, в НТТР/1.1 не было введепо никаких иовых требований. они продолжают функционировать так же, как они это делали в соответствии с НТТР/1.0.

Во втором случае прокси-сервер может ответить на запрос, если оп может сделать это удовлетворительно, то есть его ответ гараптировапио актуален. Гарантия актуальности может быть ограничена клиентом или сервером. Если так, прокси-сервер может передать запрос дальше по цепочке. Когда спустя какое-то время вернется ответ, прокси-сервер может, по не обязательно, сохранить этог ответ в кэше, прежде чем пересылать его запрашивающей стороне. Прокси-сервер может изменить запрос или ответ.

В третьем случае прокси-сервер может также функционировать как туннель, когда используется метод CONNECT. Хотя в спецификации НТТР/1.1 этот метод просто зарезервирован, он использовался при инициировании Transport Layer Security (TLS) [KL00J поверх существующего TCP-соединения посредством механизма Upgrade.

Синтаксические требования к прокси-серверу, поддерживающему НТТР/1.1

В НТТР/1.1 к прокси-серверу предъявляются следующие два класса основных синтаксических требований:

•   Требование, связанные с передачей сообщений.

•          Требования, связанные с изменением существующих заголовков или добавлением новых.

Далее мы рассмотрим оба эти требования.

ПЕРЕДАЧА СООБЩЕНИЙ

При передаче сообщения прокси-сервер должен учитывать версию протокола отправителя, от которого он получил сообщение, и получателя, которому он передает это сообщение. Предположим, что прокси-сервер, поддерживающий НТТР/1.1, пересылает сообщение-запрос, которое он получил от отправителя, поддерживающего НТТР/1.0. Даже если этот прокси-сервер получил ответ НТТР/1.1 от ближайшего к нему сервера, он не может вернуть этот ответ отправителю. Исходный отправитель, поддерживающий НТТР/1.0, может не суметь правильно воспринять некоторые из возможных аспектов этого сообщения НТТР/1.1. Однако если исходный отправитель правильно воспринимает НТТР/1.1, прокси-сервер, поддерживающий НТТР/1.1, может возвратить ответ НТТР/1.1 нетронутым. На самом деле в спецификации предполагается, что прокси-сервер сохраняет в кэше помер версии своего ближайшего сервера-соседа так, чтобы знать какого типа сообщение ему передавать.

Имеются специальные правила, связанные с передачей ответов класса lxx. Например, прокси-сервер не может передать ответ 100 Continue, если прокси-сервером добавлен заголовок Expect (т.е. заголовок Expect отсутствовал в исходном сообщении, переданном ирокси-серверу). Если прокси-сервер получает запрос, который не соответствует его возможностям, он должен вериуть ответ 417 Expectation Failed вне зависимости от того, обладает ли следующий за ним сервер требуемыми возможностями. Связано это с тем, что механизм Expect является механизмом промежуточных передач.

Для методов TRACE и OPTIONS прокси-серверы должпы проверять наличие заголовка Max-Forwards (см. раздел 7.7.1) и то, что его значение не равно нулю. Необходимо также уменьшить значение заголовка на единицу, прежде чем передать сообщение дальше. Аналогично, запрос без заголовка Host от клиента, поддерживающего НТТР/1.1, не должен передаваться прокси-сервером дальше; вместо этого прокси-сервер должен вернуть 400 Bad Request.

Заголовки, не воспринимаемые прокси-сервером, должиы по-прежиему пересылаться дальше, если только Они не перечислены в заголовке Connection (описаи- ном в разделе 7.5). Прокси-серверы должпы осторожно обрабатывать заголовки промежуточных нередач. Ошибочно переданные дальше заголовки, предназначен- пые для данного соединения, могут создать проблемы. Прокси-сервер должен удалять любые заголовки, совпадающие с лексемами, перечисленными в заголовке Connection, прежде чем пересылать сообщение дальше.

ДОБАВЛЕНИЕ ЗАГОЛОВКОВ ИЛИ ИЗМЕНЕНИЕ СУЩЕСТВУЮЩИХ ЗАГОЛОВКОВ

Прокси-серверы, поддерживающие НТТР/1.1, обязаны добавлять информацию о себе в заголовке Via, как это обсуждалось в разделе 7.7. Прокси-серверы должпы также указывать помер версии протокола вышестоящего сервера в цепочке, от которого получепо дагшое сообщение. Однако прокси-сервер, являющийся внешним шлюзом сети (например, функционирующий как сетевой экран), должен скрывать информацию о компьютерах, находящихся во внутренней сети и не добавлять информацию о них в заголовки Via.

Прокси-серверы, поддерживающие НТТР/1.1, не могут изменять порядок значений полей в заголовках сообщений, так как при этом может измениться их семантика. Две кодировки содержания в строке могут дать абсолютно разпые результаты, если их применить в другом порядке. Некоторые сквозпые заголовки (например, ETag, Content-MD5) и поля в заголовках Expires не должны изменяться прозрачными прокси-серверами. Кроме того, наличие директивы управления кэшем no-transform не допускает изменения некоторых заголовков (например, Content-Encoding, Content-Type). Прокси-сервер не должен изменять заголовок запроса From (указывающий адрес электронной почты пользователя, пославшего этот запрос) и заголовок ответа Server (идентифицирующий программное обеспечение и помер версии Web-cepBepa).

Прокси-серверам не разрешается изменять полностью определенное имя домепа, представленное в URI сообщения. Однако если прокси-сервер получает имя хоста, которое не является полиостыо определенным доменным именем, то ему разрешается добавить имя домепа к имени хоста. Прокси-серверам не разрешается генерировать некоторые заголовки (например, сквозпой заголовок проверки целостности Content-MD5; см. раздел 7.2.2). Прокси-сервер может, тем не менее, использовать значение, представленное в заголовке Content-MD5, чтобы проверить корректность тела полученного им сообщения.

Семантические требования к прокси-серверу, поддерживающему НТТР/1.1

Семантические изменения в HTTP/1.1, касающиеся прокси-серверов, являются значительными в четырех областях: кэширование, запросы на диапазоны, долговременные соединения и обеспечение безопасности.

ТРЕБОВАНИЯ К ПРОКСИ-СЕРВЕРУ, СВЯЗАННЫЕ C КЭШИРОВАНИЕМ

Некоторые изменения в НТТР/1.1 относятся к кэшированию. Поскольку прокси-серверы играют главную роль в кэшировании, то изменения в этой области оказывают на них силыюе влияние. Например, прокси-серверы должпы уделять впимапие атрибутам содержимого, которые посылаются в качестве индикаторов кэша и обеспечивают соблюдение семантической прозрачности при возвращении значений из кэша. Прокси-сервер обязап принимать во впимапие различные поля в условном заголовке до принятия решения об актуальности кэшированных объектов. При наличии директивы управления кэшем Cache-Control: s-maxage=0 кэш совместно используемого прокси-сервера должен проверить кэшированный ответ.

Если прокси-сервер действует в качестве кэша и возвращает кэшировапиые ответы, он должен посылать заголовок Age со своими ответами, чтобы указать, что данный ответ не является сгенерированным исходным сервером, г.е. «пе из первых рук». Заголовок Age включает оцепку времени, прошедшего с момента первопачальпой генерации данного ответа или с момента подтверждения его актуальности сервером-источником. Получатель может использовать значение Age для оценки возраста ответа.

ТРЕБОВАНИЯ К ПРОКСИ-СЕРВЕРУ, СВЯЗАННЫЕ С УПРАВЛЕНИЕМ СОЕДИНЕНИЕМ

Прокси-серверы, поддерживающие НТТР/1.1 и реализующие долговременные соединения, должны обеспечивать долговремеипость и восходящего (по направлению к исходному серверу), и нисходящего (rio направлению к клиенту) соединений. В НТТР/1.0 существовала реализация долговременного соединения (заголовок Keep-Alive), которая требовала явного согласования. Однако взаимодействие заголовков Connection и Keep-Alive может привести к «зависанию» соединения. Это происходит из-за того, что клиент НТТР/1.0 может послать заголовок Keep- Alive прокси-серверу, который не воспринимает Connection, но может ошибочно передать его дальше. Если писходящее соединение также поддерживает соединение Keep-Alive, находящийся в середине ирокси-сервер никогда не получил бы завершающей части этого ответа. Чтобы избежать таких проблем, прокси-серверам, поддерживающим НТТР/1.1, не разрешено устанавливать долговременное соединение с клиентами, поддерживающими НТТР/1.0.

Прокси-серверы могут использовать различные наборы правил (по сравнению с клиентом или исходным сервером) при принятии решения о закрытии долговременного соединения. Исходный сервер может иметь уважительные причины закрывать долговременные соединения раньше, так как он обслуживает множество клиентов. У ирокси-сервера Обычно меньше клиентов, чем у популярного Web-cepвера. И поэтому прокси-серверу «виднее», какие соединения поддерживать открытыми, так как он успевает следить за комбинациями запросов клиентов. В протоколе не указывается как долго (в единицах времени) прокси-серверу следует поддерживать долговременное соединение, по все же устанавливаются общие правила для количества долговременных соединений, которые ему следует поддерживать параллельно с любым сервером, расположенным выше в цепочке. В протоколе говорится, что однопользовательский клиент может поддерживать не более двух долговременных соединений с любым сервером или прокси-сервером. Прокси-сервер должен ограничиться 2n соединениями с другими серверами или прокси-серверами, где n — количество одновременно работающих пользователей.

ТРЕБОВАНИЯ К ПРОКСИ-СЕРВЕРУ, СВЯЗАННЫЕ С УПРАВЛЕНИЕМ

ПОЛОСОЙ ПРОПУСКАНИЯ

НТТР/1.1 клиенты могут выполнять запросы на диапазоны. Это накладывает на прокси-сервер специфические ограничения. Если прокси-сервер пересылает запрос на диапазон серверу и получает в качестве ответа весь ресурс, оп должен вер- нуть клиенту только указанную им часть ресурса. Тем не меиее, сохранить прокси-сервер должен весь ответ. Однако если кэш прокси-сервера не поддерживает запросы на диапазоны, то оп не должен кэшировать частичные ответы.

Для прокси-серверов, поддерживающих НТТР/1.1, существуют дополнительные правила работы с механизмом Expect. Роль, которую играет прокси-сервер, усложнилась, так как теперь, имея дело с частичным запросом клиента, он должен учитывать возможности нижерасположенного сервера. В соответствии с обсуждением правил передачи заголовков, которое проводилось ранее в этом разделе, про- кси-серверы, поддерживающие НТТР/1.1, обязапы пересылать заголовок Expect вместе с запросом. Однако если прокси-серверу известпо, что у ближайшего сервера версия протокола мепьше, чем НТТР/1.1, то этот прокси-сервер должен вернуть ответ 417 Expectation Failed, а не пересылать запрос дальше. Аналогично, если прокси-сервер получил от сервера ответ 100 Continue, оп не должен пересылать этот ответ клиенту за исключением того случая, когда клиентский запрос включает заголовок Expect.

ТРЕБОВАНИЯ К ПРОКСИ-СЕРВЕРУ, СВЯЗАННЫЕ С ОБЕСПЕЧЕНИЕМ

БЕЗОПАСНОСТИ

Некоторые заголовки и коды ответов были введепы для удовлетворения требований к прокси-серверу, связаииых с обеспечением безопасности. К пим относятся заголовки запросов, такие как Proxy-Authenticate, и коды ответов, такие как 407 Proxy Authorization Required.

Заголовок запроса Proxy-Authenticate требуется тогда, когда ресурс доступеп только для клиентов, прошедших аутентификацию. Клиент должен предоставить необходимые полномочия. Заголовок определяет используемую схему идентификации и включает вызов, чтобы дать возможность клиенту вернуть свои идентификационные данные.

Код ответа 407 Proxy Authorization Required похож на код ответа НТТР/1.0 401 Unauthorized. Однако 407 Proxy Authorization Required служит для аутентификации ближайшего участника соединения в отличие от сквозпого заголовка 401 Unauthorized. Код ответа 407 Proxy Authorization Required используется прокси-сервером для того, чтобы проинформировать клиента, что требуется сапкция на доступ к прокси-серверу, тогда как ответ 401 Unauthorized иснользуется исходным сервером для отправки вызова клиенту непосредственно. Прокси-сервер посылает заголовок аутентификации Proxy-Authenticate клиенту с вызовом, указав подходящую схему аутентификации и параметры запрашиваемого URI. Клиент должен прислать прокси-серверу свои полномочия для заданного URI с помощью нового заголовка запроса Proxy-Authorization.

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

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

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

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

 
Rambler's Top100