Использование совмещения

Запросы HEAD могут также быть использованы для определения, не устарел ли ответ, не выполняя передачи самого ресурса. Однако основной составляющей времени ожидания являются время на установление соединений с исходным сервером. Частично это объясняется тем, что фактическое время, затрачиваемое на передачу ответа от исходного сервера прокси-серверу, является относительно небольшим, принимая во внимание, что большинство ответов имеет небольшой размер. Для очепь больших или динамически генерируемых ответов время, затрачиваемое на генерирование ресурса, может превысить время передачи.

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

Рассмотрим технологию, впервые описанную в [KW97j, в соответствии с которой исходным сервером отслеживается актуальность кэшированпых ресурсов. Предположим, что запрос на ресурс инициирует соединение с одним из исходных серверов. Соединение с этим исходным сервером будет установлено в любом случае, поэтому в пем можно осуществить проверку на актуальность множества ответов исходного сервера, срок хранения которых истек. Такая проверка актуальности выполняется путем совмещения этих запросов с запросом на ресурс путем помещения их в конец запроса. В качестве примера предположим, ч го прокси-сервер имеет десяток ответов исходного сервера www.a.org, четыре из них находятся в кэше, время хранения для них истекло. При получении запроса на ресурс www.a.org/ other.html прокси-сервер формирует запрос GET в интересах клиента. Прокси-сервер добавляет информацию о четырех ресурсах, время храпения которых истекло, к запросу на www.a.org/other.html. Добавленная информация состоит из имени ресурса, времени его последней модификации и, возможно, его размера. Исходный сервер отвечает на запрос на ресурс www.a.org/other.html и может добавить метаданные о четырех других ресурсах.

Исходный сервер, который отправляет информацию о других проверяемых на актуальность ресурсах, выполняет меньше работы, поскольку полноценный обмен запрос/ответ при этом не осуществляется. Предположим, что прокси-сервер имеет снисок ресурсов для проверки на актуальность вместе со временем их последней модификации. Исходный сервер отправляет обратно список URL этих ответов, больше не являющихся актуальными, вместе с ответом для ресурса www.a.org/ other.html. Прокси-сервер возвращает ответ для other.html обратившемуся с запросом клиенту после выделения информации о проверке актуальности. Прокси-сервер может отдельно обработать эту информацию, увеличив время хранения для актуальных ответов и удалив устаревшие ответы из кэша. Сутыо проблемы, как мы увидим далее в этом разделе, является механизм для определения, отправлять ли добавочиую информацию как часть ответа для other.html, или же в отдельном сообщении.

На рисунках с 13.1 по 13.4 показаны различные этапы процесса совмещения. Клиент взаимодействует через прокси-сервер с тремя исходными серверами: А, В и С. Прокси-сервер имеет в своем кэше два ресурса (r2, r3), нолученные от исходного сервера В. Теперь предположим, что клиент посылает запрос исходному серверу на ресурс rl (рис. 13.1).

Рис. 13.1. Клиент запрашивает ресурс rl у прокси-сервера

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

Исходный сервер В возвращает ресурс rl и информацию об актуальности ресурсов r2 и r3, как показано на рис. 13.3.

Прокси-сервер возвращает ресурс rl клиенту и обновляет содержимое своего кэша на основе информации об актуальности ресурсов r2 и r3. Как показано на рис. 13.4, ирокси-сервер удалил ресурс r3 из кэша, поскольку он признап устаревшим на основе информации об актуальности, возвращенной исходным сервером В.

Рис. 13.2. Прокси-сервер запрашивает rl и совмещает с запросом проверку актуальности ресурсов r2, r3

 

Рис. 13.3. Исходный сервер В возвращает ресурс rl и информацию об актуалыюсти ресурсов rl и r2

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

Рис. 13.4. Прокси-сервер возвращает ресурс rl и обновляет кэш

РЕАЛИЗАЦИЯ СОВМЕЩЕНИЯ

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

1.       Прокси-сервер может отправить группу запросов HEAD исходному серверу. Заголовок HEAD содержит модификатор запроса If-Modified-Since, значение которого берется из заголовка Last-Modified кэшированпого ответа. Очевидно, что если ответ был сформирован динамически, либо не содержит информации Last-Modified по другим причииам, кэш не будет включать такой ответ в список для упреждающей проверки актуалыюсти. В действительности во многих случаях динамически генерируемые ответы вообще не кэшируют- ся. Если НТТР-соединение уже открыто, дополнительных затрат на соединение не возникает. Запросы HEAD могут с успехом подвергаться копвейерпой обработке. Подобная технология работает и в НТТР/1.0, но в НТТР/1.1 она реализована лучше. Однако для каждого дополнительного запроса сервер должен возвратить ответ с информацией о проверке актуалыюсти, даже если ресурс не был измепеп.

2.       Прокси-сервер формирует простую структуру данных, содержащую URL устаревших ответов и метки времени, соответствующие заголовку Last-Mo- dified в кэшировапиом ответе. Эта структура данных добавляется в регулярный запрос, как было сказано выше. Прокси-сервер предполагает, ч го исход- пому серверу известно, как извлечь данпые, т.е. должны быть использованы серверы, которые знают, как реагировать на подобные запросы с совмещением. С другой сторопы, если HTTP будет модериизировап с учетом возможностей по обработке совмещений, прокси-серверы смогут без проблем работать с совместимыми с данной версией НТТР-серверами.

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

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

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

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

Прокси-сервер включает заголовок запроса TE:Trailer, а сервер отправляет дополнительную информацию в трейлере ответа. Прокси-сервер посылает запрос:

Get /other.html НТТР/1.1 Host: www.piggy.com ТЕ: trailers

URL1 LMT: … URL2 LMT: … URL3 LMT: … URL4 LMT: … CRLF

Исходный сервер отправляет обратно ответ

НТТР/1.1 200 0K Content-Type: text/html Content-Length: 2100 Transfer-Encoding: chunked Trailer: Piggy

<тело ответа>

Piggy: <здесь располагается дополнительно отправляемая информация>

В разделе 13.2.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