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

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

450

Часть

Web-приложения

12.5.

Резюме

Аудио- и видеопотоки отличаются от традиционного Web-содержания по трем

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

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

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

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

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

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

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

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

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

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

щие протоколы будут продолжать эволюционировать.

Часть VI

Перспективы исследований

Перспективы исследований,

связанных с кэшированием

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

ния

—

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

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

ной кэшированию (глава И), мы рассмотрели различные технические проблемы,

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

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

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

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

альных документах (RFC) Internet Engineering Task Force (IETF) или в коммерче-

ских продуктах.

Как отмечалось в главе И, имеются три основных причины, но которым кэши-

рование получило массовое признание: уменьшение времени ожщ1апия на стороне

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

сервер. Неудивительно, что большинство исследовательских работ, связанных с кэ-

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

ра. Вместо того чтобы попытаться представить обширный обзор по разнообразным

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

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

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

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

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

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

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

лится на следующие три части:

• Проверка актуальности и аннулирование элементов кэша. При отсутствии

явного указания времени истечения срока хранения проверка актуальности

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

тов.

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

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

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

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

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

кладными расходами. Мы рассмотрим новую технологию совмещения (piggy-

backing),

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

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

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

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

454

Часть VL Перспективы исследований

• Комплексный информационный обмен. Идея комплексного информационно-

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

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

исходным серверам. Основу составляет технология совмещения с добавлени-

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

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

чтобы формировать сигнатуру стратегий кэширования в качестве фильтра и

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

фильтр к набору рекомендаций.

• Упреждающая выборка. Упреждающая выборка

—

это технология, преду-

сматривающая извлечение информации до того, как она будет необходима

или затребована. Главная побудительная причина

—

сократить время ожида-

ния на стороне пользователя. В последовательности действий при типовой

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

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

будет установлена связь), на уровне TCP (предварительное установление.со-

единения) и на уровне HTTP (упреждающая выборка ресурса, который веро-

ятно будет запрошен).

Каждая область исследований будет детально рассмотрена в контексте мотива-

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

13.1.

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

элементов кэша

Юночевые изменения, принятые в НТТР/1.1, призваны гарантировать актуаль-

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

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

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

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

актуальным. В главе 7 (раздел 7.3) и в главе И мы обсуждали различные пробле-

мы,

связанные с кэшированием в Web, и ввели несколько относящихся к кэширо-

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

ального

состояния и возраст.

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

мер,

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

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

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

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

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

сти на исходном сервере. И в НТТР/1.0, и в НТТР/1.1 проверка актуальности вы-

полняется с помощью запроса GET с модификатором запроса If-Modified-Since.

В НТТР/1.1 имеется модификатор запроса If-None-Match для использования его

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

возвращает ответ 304 Not Modified, не содержащий тела, либо ответ 200 ОК с пол-

ноценным телом содержимого.

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

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

вает, что от 10 до 30 процентов трафика составляют запросы на проверку актуаль-

Глава

13.

Перспективы

исследований,

связанных

кэшированием

455

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

кси-сервера показывает, что около 16% всех ответов составили ответы 304 Not

Modified. Можно считать число ответов 304 Not Modified в журнале сервера явля-

ются

нижней

оценкой числа запросов на проверку актуальности. Некоторые запро-

сы на проверку актуальности порождают ответы 200 ОК, которые содержат тело

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

актуальности приводит к выдаче ответа 200 ОК:

• Ресурс был изменен, и сервер посылает новое значение.

• Сервер не знает точное время последней модификации. Например, ресурсом

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

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

заголовок ETag вместо времени последней модификации.

• Выдача ответа 304 Not Modified не является обязательным требованием для

серверов (согласно спецификации протокола, оно относится к уровню требо-

ваний SHOULD (Желательно)).

Далее в этом разделе мы остановимся на составляющих затрат, связанных

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

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

трат. К этим трем методам относятся: упреждающая проверка актуальности, совме-

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

альности состоит в выполнении проверки кэшированных объектов, срок хранения

которых мог истечь до

того,

как они будут запрошены клиентами. Упреждающая

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

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

интервал между проверками может быть увеличен). Совмещение

—

это технология,

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

туальности. Аннулирование под управлением сервера

—

это способ для исходного

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

Проверка актуальности увеличивает трафик, в то время как аннулирование серве-

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

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

ка ответов.

13.1.1.

Затраты, связанные с проверкой актуальности

Рассмотрим различные составляющие затрат в следующем сценарии:

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

мую исходным серверам.

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

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

• На запрос возвращается ответ 304 Not Modified, и прокси-сервер посылает кэ-

шированный ответ клиенту.

Средний размер HTTP-запроса с модификатором запроса If-Modified-Since со-

ставляет около 200 байтов. HTTP-ответ с кодом ответа 304 Not Modified имеет

размер менее 200 байт и может составлять всего 50 байтов. Запрос на повторную

проверку актуальности в НТТР/1.0 требует установления соединения с исходным

сервером (или прокси-сервером, в случае его наличия на пути). Несколько пакетов

456 Часть VI. Перспективы исследований

требуется для установления (трехэтанное ТСР-взаимодействие) и завершения (че-

тыре ТСР-пакета завершения соединения) НТТР-взаимодействия. Запрос на про-

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

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

проса, отправить обратно ответ, зарегистрировать обмен (необязательно) и закрыть

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

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

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

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

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

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

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

уменьшение. Время ожидания при передаче всего содержимого ресурса с исходно-

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

ловок HTTP-ответа без тела содержимого. Это, скорее всего, будет составлять

лишь малую часть от общих затрат. Если ответ содержался в кэше прокси-сервера,

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

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

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

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

ми,

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

ту. Сокращение трафика запросов на проверку актуальности может значительно

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

13.1.2.

Упреждающая проверка актуальности

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

можность избежать ожидания при выдаче запроса. Упреждающая выборка

—

дос-

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

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

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

Упреждающая проверка актуальности — это упреждающая выборка информации

об актуальности.

Метод HEAD HTTP дает возможность осуществлять выборку метаданных ре-

сурса без фактической передачи ресурса. Кэш может выдать запрос HEAD и прове-

рить,

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

ные,

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

вапный ответ устарел, кэш может отправить запрос GET. Однако запрос HEAD

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

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

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

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

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

HEAD или GET, отправить. Предварительная проверка актуальности посредством

запросов HEAD потенциально снижает требования к пропускной способности

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

Заметим, что использование кэшем запроса GET с заголовком If-Modified-Since не

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

прос,

может отправить ответ типа 200 ОК с содержимым ресурса.

Глава 13. Перспективы исследований, связанных с кэшированием 457

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

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

с блокированием (см. главу 7, раздел 7.5.4), т.к. запросы HEAD обычно не требуют

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

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

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

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

телю,

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

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

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

ный сервер.

13.1,3.

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

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

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

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

ром. Частично это объясняется тем, что фактическое время, затрачиваемое на пере-

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

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

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

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

Один из способов избежать затрат на соединение — передать несколько запро-

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

соединений в НТТР/1.1 позволяет уменьшить потребность в новых соединениях.

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

ния — протокол это допускает. Если соединение с исходным сервером уже откры-

то,

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

без затрат на установление новых соединений. Однако в связи с тем, что в кэше

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

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

проверку на актуальность до истечения этого интервала.

Рассмотрим технологию, впервые описанную в [KW97J, в соответствии с кото-

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

Предположим, что запрос на ресурс инициирует соединение с одним из исходных

серверов. Соединение с этим исходным сервером будет установлено в любом слу-

чае,

поэтому в нем можно осуществить проверку на актуальность множества отве-

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

выполняется путем совмещения этих запросов с запросом на ресурс путем помеще-

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

ет десяток ответов исходного сервера www.a.org, четыре из них находятся в кэше,

время хранения для них истекло. При получении запроса на ресурс www.a.org/

other.html прокси-сервер формирует запрос GET в интересах клиента. Прокси-сер-

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

к запросу на www.a.org/other.html. Добавленная информация состоит из имени

ресурса, времени его последней модификации и, возможно, его размера. Исходный

сервер отвечает на запрос на ресурс www.a.org/other.html и может добавить мета-

данные о четырех других ресурсах.

Исходный сервер, который отправляет информацию о других проверяемых на

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

458

Часть

VI.

Перспективы исследований

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

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

модификации. Исходный сервер отправляет обратно список URL этих ответов,

больше не являющихся актуальными, вместе с ответом для ресурса www.a.org/

other.html. Прокси-сервер возвращает ответ для other.html обратившемуся с за-

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

кси-сервер может отдельно обработать эту информацию, увеличив время хранения

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

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

лять ли добавочную информацию как часть ответа для other.html, или же в отдель-

ном сообщении.

На рисунках с 13.1 по 13.4 показаны различные этапы процесса совмещения.

Клиент взаимодействует через прокси-сервер с тремя исходными серверами: А, В и

С. Прокси-сервер имеет в своем кэше два ресурса (г2, гЗ), полученные от исходно-

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

на ресурс г1 (рис. 13.1).

Клиент

GETrl

•

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

Кэш

[гЦ

Исходный

сервер А

Исходный

сервер В

Исходный

сервер С

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

г1

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

В этот момент прокси-сервер не имеет в своем кэше ресурса г1 и должен пере-

дать запрос исходному серверу В, на котором размещен ресурс г1. Предположим,

что в соответствии со стратегией прокси-сервера должна быть осуществлена про-

верка актуальности имеющихся в кэше ресурсов г2 и гЗ. Прокси-сервер совмещает

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

г1,

посылаемым

исходному серверу В, как показано на рис. 13.2.

Исходный сервер В возвращает ресурс г1 и информацию об актуальности ре-

сурсов г2 и гЗ, как показано на рис. 13.3.

Прокси-сервер возвращает ресурс г1 клиенту и обновляет содержимое своего

кэша на основе информации об актуальности ресурсов г2 и гЗ. Как показано на

рис.

13.4, прокси-сервер удалил ресурс гЗ из кэша, поскольку он признан устарев-

шим на основе иР1формации об актуальности, возвращегнюй исходным сервером В.

Глава

13^

Перспективы исследований,

связанньис

с кэшированием

459

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

Клиент

Кэш

г2

гЗ

GETrl

Проверить

актуальность г2, гЗ

г2

гЗ

Исходный

сервер В

Рис.

13.2. Прокси-сервер запрашивает г1 и совмещает с запросом проверку

актуальности ресурсов г2, гЗ

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

Клиент

Кэш

[г2|

[гз]

Ресурс г1

Информация об

актуальности г2, гЗ

[гТ]

[г2]

[гз]

Исходный

сервер В

Рис.

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

ресурсов г1 и г2

Преимущества совмещения очевидны: не устанавливаются специальные соедине-

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

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

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

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