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

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

460

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

Клиент

Ресурс г1

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

Кэш

г2

г1 г2

7з

Исходный

сервер В

Рис.

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

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

Теперь мы рассмотрим способы, с помощью которых прокси-серверы могут по-

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

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

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

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

альности в составе запроса:

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

Заголовок HEAD содержит модификатор запроса If-Modified-Since, значение

которого берется из заголовка Last-Modified кэшироваппого ответа. Очевид-

но,

что если ответ был сформирован динамически, либо не содержит инфор-

мации Last-Modified по другим причинам, кэш не будет включать такой от-

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

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

ся.

Если НТТР-соединепие уже открыто, дополнительных затрат на соедине-

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

обработке. Подобная технология работает и в НТТР/1.0, но в НТТР/1.1 она

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

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

ресурс не был изменен.

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

таревших ответов и метки времени, соответствующие заголовку Last-Mo-

dified в кэшированпом ответе. Эта структура дагп1ых добавляется в регуляр-

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

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

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

ем.

С другой стороны, если HTTP будет модернизирован с учетом возможно-

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

с совместимыми с данной версией HTTP-серверами.

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

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

ствовать одним из следующих двух способов:

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

просы HEAD, исходный сервер просто возвращает соответствующие ответы.

Никакого изменения поведения от него не требуется.

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

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

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

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

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

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

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

ет НТТР/1.1, а прокси-сервер способен обрабатывать ответы НТТР/1.1,

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

тить дополнительную информацию с ответом для other.html.

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

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

Прокси-сервер включает заголовок запроса TEiTrailer, а сервер отправляет до-

полнительную информацию в трейлере ответа. Прокси-сервер посылает запрос:

Get /other.html НГГР/1.1

Host: www.piggy.com

ТЕ:

trailers

URL1

LMT: ...

URL2

LMT: ...

URLS

LMT: ...

URL4

LMT: ...

CRLF

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

НТТР/1.1 200 ОК

Content-Type: text/html

Content-Length: 2100

Transfer-Encoding: chunked

Trailer: Piggy

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

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

В разделе 13.2.3 мы разъясним синтаксические элементы протокола, использо-

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

ловок ТЕ, а серверу использовать трейлер для включения донол1Н1тельной инфор-

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

сти в заголовок, предшествующий телу содержимого. При этом подразумевается,

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

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

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

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

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

трейлера после пересылки тела сообщения пользователю.

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

13.1.4.

Аннулирование, управляемое сервером

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

ность. С другой стороны, исходный сервер

—

это компонент, который знает, когда

ресурс на сайте изменяется. Таким образом, вместо отправки запроса на проверку

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

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

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

ей проталкивания (pull technology), в то время как проверка актуальности а?1ало-

гична модели принудительной загрузки информации (push technology).

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

• Как сервер посылает агнхулирующую информацию?

• Каким клиентам и прокси-серверам адресована аннулирующая информация?

• С какой частотой посылается аннулирующая информация?

Ответ на первый вопрос очевиден, так как в HTTP исходный сервер не может

инициировать передачу сообщений. Прежде чем сервер сможет ответить, должен

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

вет на некий запрос. В исследовании, описанном в [KW98], в основу которого лег-

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

ем совмещения (см. раздел 13.1.3), был изучено совмещение с ответами информа-

ции об аннулировании. Как и в случае совмещения с запросом информации о

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

Второй вопрос связан с сохранением промежуточного состояния на сервере, ко-

торый посылает аннулирующую информацию. Сильно загруженный исходный сер-

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

сведения о них для передачи информации об аннулировании, исходному серверу

потребуется хранить значительный объем информации о состоянии. В некоторых

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

в получении аннулирующей информации. Сервер может использовать подход,

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

в разделе 11.7, но при этом по-прежнему требуется сохранение информации о со-

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

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

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

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

цию,

совмещенную с ответами.

Третий вопрос, связанный с частотой отправки информации об аннулировании,

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

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

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

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

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

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

как только ресурс изменяется. Для часто меняющихся ресурсов это может сущест-

венно увеличить объем трафика.

Подход, основанный на фиксированном времени хранения и описанный в [LC97J,

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

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

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

Глава

13.

Перспективы

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

связанных

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

463

фиксированного времени хранения. При подходе с совмещением аннулирования

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

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

что не следует хранить информацию об а1П1улироваиии на уровне отдельных ре-

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

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

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

ставления, какие клиенты заинтересованы в ресурсе. Даже если исходный сервер

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

ответах, которые были возвращены из кэша, и, таким образом, никогда не узнает о

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

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

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

ленного информационного обмена подводит нас к следующей теме: комплексному

обмену информацией.

13.2.

Комплексный обмен информацией

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

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

ентские запросы. В этом разделе мы обобщенно дадим вам представление об ин-

формационном обмене между прокси-серверами и исходными серверами, обеспе-

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

замещение ресурсов в кэше и упреждающую выборку. Эффективность работы про-

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

которые с большой вероятностью будут затребованы в будущем. Однако исходный

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

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

вер может совместить

рекомендации

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

просы от прокси-серверов. Сервер формирует эти рекомендации путем группиров-

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

Однако некоторые ресурсы в томе могут не иметь отношения к прокси-серверу.

Прокси-сервер один знает, какую стратегию кэширования он проводит, а также ка-

кие ресурсы в настоящий момент имеются в его кэше. Эта информация сводится

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

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

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

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

которые совмещаются с сообщением-ответом. Двунаправленный обмен информа-

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

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

вместно использовать серверные тома и фильтрацию. В нем также содержится де-

тальная информация, связанная с реализацией совмещенной доставки фильтров и

рекомендаций, а также приведены алгоритмы для построения томов [CKR98,

CKR99].

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

нове информации, полученной из журналов серверов.

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

13.2.1.

Серверные тома

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

в зависимости от ресурса, запрошенного прокси-сервером. В ответ па запрос ресур-

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

дыдущих исследованиях, посвященных файловым системам, было введено понятие

тома как группы взаимосвязанных ресурсов. В работе [KW98J, посвященной со-

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

тику работы [KW97J, понятие тома было применено к аннулированиям, управляе-

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

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

• Ресурсы, доступ к которым осуществляется близко по времени (временной

шаблон доступа).

• Ресурсы, имеющие общий синтаксический префикс (применителыю к UNIX

—

это ресурсы, расположенные в одном каталоге).

• Ресурсы, имеющие общие атрибуты (схожий тип содержания, размеры и т.д.).

• Ресурсы, которые модифицируются вместе (например, ресурсы, которые из-

менились в течение последних пяти минут).

Сервер может ассоциировать идентификатор с каждым томом, а прокси-сервер

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

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

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

редать лишь небольиюй объем информации о том, как изменились ресурсы в VI.

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

групповые операции над кэшированными ресурсами, принадлежащими VI.

Выбор соответствующей эвристики при построении тома зависит от конкретного

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

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

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

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

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

занрашиваун^сь сразу же после обращения к ресурсу г. Если много клиентов запроси-

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

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

ляет собой HTML-файл, R s — одно из встроенных в него изображений. Включая s

в том для г, сервер может совместить информацию о 5 с ответом прокси-серверу на

запрос для г. Пересылая ответ для г обратившемуся с запросом lamenTy, прокси-сер-

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

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

представлять собой чрезвычайно популярную гипертекстовую ссылку в ресурсе ?;

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

строению томов мы рассмотрим в разделе 13.2.4.

Второй способ построения томов основан на предположении, что содержание

Web-сайта организовано в виде каталогов в файловой системе сервера. Связанные

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

пировать ресурсы, просматривая имена файлов в каталогах. Рассмотрим Web-сайт,

имеющий три подкаталога dotty, lefty и neato. Каждый из этих каталогов может со-

держать несколько файлов. Одноуровневый том может содержать URL в виде

/dotty/index.html, /dotty/src/graph.c и /dotty/src/Makefile. Однако информация

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

о ресурсах /lefty/editor.с и /neato/download.html не будет включена в одноуров-

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

больших томов. Чтобы уменьшить размер тома, сервер может сгруппировать ресур-

сы,

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

гах, начинаюш.ихся с /dotty/src/, может быть назначен один том.

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

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

Прокси-сервер может применять стратегию, которая ограничивает кэширование

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

мер,

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

верженные частым изменениям. Подобный метод имеет тот недостаток, что реше-

ния принимаются, только исходя из информации исходного сервера. Если кэши-

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

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

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

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

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

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

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

или не включать в рекомендации онределегн1ые тома.

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

в течение определегнюго интервала времени. В основу этой эвристики положен тот

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

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

чение этого периода, помогает серверу ограничить число рекомендаций. Кроме того,

ресурсы, изменяющиеся в одно время, могут быть связанными друг с другом. Запрос

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

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

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

Формирование томов увеличивает нагрузку сервера. Расчет тома в ходе обра-

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

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

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

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

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

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

ить и обновлять тома в фоновом режиме. Тем самым сервер способен предоставить

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

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

мов и частотой изменений томов.

13.2,2.

Фильтры прокси-серверов

Построение томов осуществляется на основе информации, имеющейся на серве-

ре.

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

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

лей, с беспроводным подключением к Internet. Такой прокси-сервер может при-

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

которых превышает 1 мегабайт. Отправка рекомендаций относительно этих ресур-

сов приведет к ненужной загрузке Web-сервера и прокси-сервера. Однако исход-

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

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

ством прокси-серверов, посылающих запросы Web-серверу. Прокси-сервер может

включить информацию о собственной стратегии кэширования в свои сообще-

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

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

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

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

Фильтр прокси-сервера служит нескольким целям. Во-первых, фильтр может

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

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

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

зывать, какие метаданные должны быть включены в каждую из рекомегщаций. На-

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

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

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

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

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

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

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

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

включение сервером рекомендаций в сообщение-ответ. Прокси-сервер может от-

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

мендацию для определенного запроса. Кроме того, фильтр прокси-сервера может

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

ветом. Например, прокси-сервер с помощью фильтра может потребовать, чтобы

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

чены в порядке их важности.

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

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

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

фильтр для множества исходных серверов. Следовательно, храпение фильтра про-

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

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

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

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

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

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

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

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

комендаций ресурсами, имеющими размер, меньший заданного. Такая эффектив-

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

работке запросов от прокси-серверов.

13.2.3.

Тома и фильтры. Практическое использование

Практическое использование серверных томов и фильтров прокси-серверов тре-

бует более строгой спецификации томов, фильтров и технологии совмещения. Том

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

соответствует определенному ресурсу па Web-сайте. Каждый элемент содержит

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

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

467

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

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

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

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

при применении фильтров прокси-серверов. Помимо элементов тома, сервер мо-

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

тельно последних доставленных методом совмещения томов (RPV — Recently

Piggybacked Volumes), прокси-сервер может проинструктировать сервер не переда-

вать эти рекомендации повторно, включив идентификаторы тома в фильтр, совме-

щенный с последующими запросами. При получении этого фильтра сервер пропус-

тит рекомендации, связанные с данными идентификаторами томов.

Совмещение прокси-сервером фильтра с сообщением-запросом избавляет сервер

от необходимости хранить информацию о каждом прокси-сервере. В противном слу-

чае система не смогла бы работать с большим количеством прокси-серверов. Фильтр

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

может быть расширен, чтобы учесть другие параметры фильтрации. Любые допол-

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

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

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

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

элементов фильтра: управляющие параметры и атрибуты ресурсов. Управляющие

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

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

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

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

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

пом содержания или временем последней модификации. Кроме того, прокси-сервер

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

ленного HTTP-заголовка, например, Accept-Language.

Таблица 13.1. Элементы фильтров

Элемент фильтра

Hints

RPV

MaxPiggy

MinAcccss

MinProb

Level

Size

OKType

NotOKTypc

Примеры

значений

On/Off

{1,2,4}

100

0.8

0, 1, 2

1 MB, 10 KB

HTML

CGI

Назначение 1

Посылать ли рекомендацию? |

Сервер пе должен отправлять перечисленные тома |

Максимальное число рекомендаций в сообщении |

Мипимальпое число обращений к ресурсу |

Минимальная вероятность стелующего обращения |

Рекомендации, совместно использующие пре4)икс1л

с указанным уровнем |

Ограничение па размер элементов тома |

Ограничение выдачи рекомендаций указаппььми 1

типами содержания |

Не посылать рекомендации относительно данного

типа содержания

468

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

Элемент фильтра

Lastmod

PITTP method

HTTP header

Примеры

значений

1 min

PUT

ETag, Accept

Назначение

Минимальное время, прошедшее после последней

модификации |

Ресурсы должны допускать примспепис указанного

метода 1

Ресурс должен содержать данный заголовок

Обмен фильтрами и рекомендациями требует эффективного способа совмеще-

ния информации с сообщениями запросов и ответов HTTP. Фильтры и рекоменда-

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

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

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

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

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

достигнуто за счет посылки метаданных в трейлере сообщения HTTP/1.1. Трейле-

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

даваемых данных и заголовок Trailer, о чем говорилось ранее в главе 7 (раздел 7.6).

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

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

заканчивается трейлером.

Например, прокси-сервер мог отправить серверу запрос:

GET /random.html НТТР/1.1

Host: smartse rve

г.com

ТЕ:

trailers

Piggy-filter: maxpiggy=5; content-type=gif

Заголовок Piggy-filter содержит фильтр прокси-сервера, a заголовок ТЕ: trailers

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

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

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

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

том с рекомендациями, будет игнорировать заголовок Piggy-filter. Сервер, участ-

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

НТТР/1.1 200

ОК

Trailer:

P-volume

Transfer-encoding: chunked

< Размер фрагмента

<данные>

P-volume: vol=7; pe=Vrandom-img1.gif, 895527629, 546";

pe=Vr'andom-ifng3.gif, 891527021,192";

pe="/random-img21.gif.821993421,900"

CRLF

Заголовок ответа имеет заголовок Trailer со значением P-volume, указывающим,

что заголовок с этим именем присутствует в конце сообщения. Ответ разбит на

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

Глава

13.

Перспективы

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

у связанных

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

. 469

щения. Трейлер содержит идентификатор тома (7) и три элемента тома, включая

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

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

ры распознавали новые заголовки. НТТР-компоиенты игнорируют заголовки, ко-

торые они не воспринимают. Сервер, который не способен посылать рекомендации,

будет игнорировать незнакомый заголовок Piggy-filter и генерировать обычный от-

вет. Не участвующий в данной схеме обмена прокси-сервер будет генерировать

обычные запросы, которые не содержат заголовок Piggy-filter. Для прокси-серве-

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

вает добавление небольшого объема данных в сообщениях запросов и ответов. На-

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

ний URL состоит примерно из 50 однобайтных символов (не включая доменное

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

семь байт. Следовательно, для каждой рекомендации потребуется 66 байтов. От-

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

носительно немного в сравнении со средним размером Web-pecypca — около

8 Кбайтов, о чем говорилось в главе 10 (раздел 10.4.2). Отправка нескольких реко-

мендаций самое большее потребует от сервера передать один дополнительный

ТСР-пакет. На деле рекомендации могут размещаться в том же пакете в конце тела

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

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

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

13.2.4.

Алгоритмы построения томов

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

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

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

построения томов.

ПОКАЗАТЕЛИ ЭФФЕКТИВНОСТИ

Разработка и оценка алгоритмов построения томов основываются на достиже-

нии конкретных, подлежащих измерению характеристик эффективности. В идеале

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

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

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

• Объем рекомендаций. Среднее число рекомендаций, совмещенных с сообще-

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

прокси-сервера. Небольшой объем рекомендаций обусловливает незначитель-

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

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

• Коэффициент попадания (recall). Коэффициент попадания учитывает, какая

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

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

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

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

запросов не было предсказано заранее.

• Точность. Показатель точности оценивает долю рекомендаций сервера, кото-

рые успешно предсказали будущий запрос. Высокая точность означает, что