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

Поскольку прокси-сервер является ключевым компонентом при выполнении Web-транзакций, прокси-серверы действуют в соответствии с правилами протокола HTTP. В главе 7 (раздел 7.11) мы обсудим особые правила, определяющие поведение прокси-сервера. Если обобщить, прокси-сервер должен выполнять несколько синтаксических и семантических требований. Синтаксические требования обычно связаны с заголовками, которые прокси-сервер добавляет к сообщениям, и с модификацией имеющихся заголовков. Семантические требования включают в себя корректную обработку запросов и ответов, а также поддержку ограничений, действующих при возврате кэшировапиых ответов.

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

Идентификация. Прокси-сервер может идентифицировать себя в поле заголовка, чтобы другие компоненты в цепочке запрос-ответ знали, что сообщение прошло через прокси-сервер. В последней версии протокола (НТТР/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-cepee- py. Прокси-сервер должен принять соединение, создать программный поток или ироцесс для обслуживания запроса и сохранять соединение до тех пор, пока запрос не будет обработан. Позже он может занести информацию о запросе в системный журнал и выполнить все необходимые действия по освобождению ресурсов, связанных с сохранением состояния процесса или выделенными буферами. Такие операции должны быть выполнены в процессе буферизации ответов от других серверов для других запросов. Количество соединений, доступных прокси-серверу на транспортном уровне, ограничено, поэтому новые соединения не могут быть нрипяты, пока не будут закрыты некоторые из старых соединений. Аналогично, поскольку прокси-сервер буферизует ответы и по возможности кэширует их, здесь также могут возникать проблемы с ресурсами для их размещения. Подробнее о проблемах, с которыми сталкивается сервер при обслуживании множества одновременных запросов, рассказано в главе 4 (раздел 4.4).

Работа с cookies. В главе 2 (раздел 2.6) мы узпали, как клиент использует cookies. В главе 4 (раздел 4.4) мы увидим, как серверы работают с cookies. Поскольку прокси-сервер действует и как клиент, и как сервер, он видит cookies в co- общепиях-ответах и возвращает cookies в сообщениях, пересылаемых исходному серверу, если они присутствуют в запросах. Например, клиент отправляет запрос на ресурс исходному серверу S через прокси-сервер Р. Исходный сервер S отнрав- ляег cookie в заголовке Set-Cookie обычпым образом. С точки зрепия исходного сервера прокси-сервер P является клиентом, на котором будет размещен cookie. Прокси-сервер передает заголовок Set-Cookie клиенту для сохранения [KM00j. Когда клиент в следующий раз связывается с исходным сервером, клиент использует URL для принятия решения, какой cookie включить в свой заголовок Cookie. Прокси-сервер передает этот заголовок без изменений. На деле ирокси-серверу запрещается добавлять свои собственные связанные с cookies заголовки в любом направлении. Таким образом простое присутствие прокси-сервера на маршруте не влияет на семантику cookies и для клиента, и для сервера. Однако Web-сервер может проинструктировать прокси-сервер не кэшировать определенные заголовки. Например, можио указать, чтобы заголовок Set-Cookie не кэшировался (см. главу 7, раздел 7.3.3, где описаны различные механизмы для управления кэшированием).

Источник: 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