Проблемы, связанные с внедрением дельта-механизма в НТТР/1.1

Внедрение дельта-мехаиизма требует изучения изменений, которые необходимо будет впести в протокол НТТР/1.1. Клиент или прокси-сервер должен иметь возможность заявить о своей поддержке дельта-механизма. Сервер, принимающий запрос, должен уметь генерировать разности для различных версий ресурсов и идентифицировать соответствующие разности. Рабочий проект [MKD+01J для этого предложения прошел несколько этапов стандартизации и на момент издания этой книги имел статус предложения по стандарту. Поскольку проект обсуждался в течение двух лет, итоговые предложения оказались достаточно зрелыми. Некоторые дополнения, не относящиеся к главному принципу применения дельта-механизма, были выделены в другой проект стандарта [MDHj.

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

1.       Основные проблемы, связанные с внедрением дельта-механизма.

2.       Обзор этапов преобразования HTTP-сообщения в процессе дельта-кодирова- иия.

3.       Краткое рассмотрение некоторых основных этапов преобразования.

Соображения, связанные с внедрением. К основным проблемам, связанным с внедрением дельта-механизма в НТТР/1.1, относятся следующие:

•          Идентификация экземпляров. Клиент должен идентифицировать экземпляр (экземпляры), для которого (которых) он хотел бы вычислить разность. Клиент, который имеет иесколько кэшированных экземпляров, может применить эвристику для определения экземпляров, которые он планирует включить в свой запрос. Кэшированный экземпляр и соответствующая этому экземпляру разность должны быть правильно идентифицированы, чтобы получить на сервере наиболее свежий экземпляр. Не все экземпляры, кэшированные клиентом, могут оставаться доступными на исходном сервере.

•          Синтаксис. Должен быть определен синтаксис, относящийся к спецификации содержания и преобразования кодирования для клиента и сервера, который согласуется с выбором способа кодирования/декодирования разности. Клиент может поддерживать только некоторые из алгоритмов вычисления разности и иметь определенные предпочтения для этих алгоритмов. Клиент должен иметь возможность выразить свои предпочтения, чтобы повысить вероятность получения разности в том формате, который наиболее ему подходит. Решение при выражении иредиочтепий может зависеть от типа содержания и размера кэшированного ответа.

•          Реализация. Формирование, передача, применение и кэширование разности составляют практические проблемы реализации дельта-механизма. Исходный сервер может оценивать затраты, связанные с применением дельта-механизма, на осиове времени, которое требуется для формирования разностей для набора экземпляров. Если сформированная разность больше, чем текущий экземпляр, исходный сервер может просто отправить сам экземпляр. Сервер может согласовать выбранный им образ действий с клиентскими предпочтениями, если при этом затраты для исходного сервера не увеличиваются. Например, исходный сервер может посчитать для себя более выгодным генерировать разность в одном избранном формате, предпочтя его всем другим. Если исходный сервер имеет кэшированные разности для предыдущих экземпляров, использующих определенный дельта-механизм, он может выбрать этот механизм, даже если данный конкретный механизм не является наиболее предпочтительным для обратившегося с запросом клиента. Принятие решения, какие разности кэшировать и как долго хранить кэшированные значения, представляют собой дополнительные задачи, которые должен решать исходный сервер.

Преобразование НТГР-сообщения. К основным действиям по преобразованию НТТР-сообщений, описанным в [MKD+01], относятся следующие:

•   Идентификация запрашиваемого ресурса сервером.

•   Выбор варианта ресурса.

•          Генерирование тела, ассоциированного с экземпляром (но не с содержимым) ресурса.

•   Формирование дельта-кодированного содержимого.

•   Передача дельта-кодированпого сообщения.

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

Исследование основных этапов обработки разности. Существуют следующие основные этапы обработки запроса клиента и ответа с кодированием разиости:

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

•   Сервер вычисляет и передает соответствующую разность.

•   Осуществляется взаимодействие.

•   Клиенту становятся доступными несколько экземпляров ресурса.

Сиачала клиент выражает свою заинтересованность и возможность применения дельта-механизма с помощью заголовка A-IM (Accept-Instance-Manipulation), который задает множество приемлемых алгоритмов вычисления разности. Например,

GET /chap15.html НТТР/1.1 Host: www.vcdiff.com If-None-Match: "38432-s8-13" A-IM: vcdiff, diffe, gzip

означает, что клиент нредночитает в первую очередь кодирование vcdiff, а во вторую очередь кодирование diffe для разности и gzip в качестве формата сжатия, даже если ответ не был кодирован с применением дельта-кодирования. Заголовок If-None-Match идентифицирует экземпляр, к которому следует применять дель- та-механизм. Как и во всех других случаях, сервер может возвращать ответ 304 Not Modified, если текущий экземпляр ресурса chapl5.html совпадает с вариантом, связанным с атрибутом содержимого "38432-s8-13". Если текущий ресурс имеет другой атрибут содержимого, сервер, допускающий применение дельта-механизма, может вычислить разность между текущим экземпляром и экземпляром, на который ссылается атрибут содержимого "38432-s8-13". Клиент предпочитает использовать алгоритм vcdiff, и сервер должен попытаться применить именно этот механизм вычисления разности, если такое возможно.

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

НТТР/1.1 226 IM Used

Date: Sun, 2 Jul 2000 23:35:35 GMT

ETag: "192-qpt-899"

IM: vcdiff

Сервер использует новый код ответа 226 IM Used и заголовок ответа IM, указывающий на выбор алгоритма кодирования разности. Экземпляр ресурса имеет по- вый атрибут содержимого (192-qpt-899), который будет предположительно сохранен прокси-сервером или клиентом для дальнейшего использования.

Предположим, клиент заинтересован в получении только части разности между двумя экземплярами. Клиент может попросить сервер вычислить разность, а затем извлечь часть разиости:

GET /foo.html НТТР/1.1 Host: www.vcdiff.com If-None-Match: "38432-s8-13" A-IM: vcdiff, range Range: bytes=0-200

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

НТТР/1.1 226 IM Used

Date: Mon, 20 Nov 2000 11:48:45 GMT

ETag: "192-pqr-99"

IM: vcdiff, range

который подразумевает, что сервер вычислил разность с использованием vcdiff для текущего экземпляра на основе коиии экземпляра с атрибутом содержимого "38432-s8-13", а затем извлек первые 201 байт этого кодированного с помощью vcdiff экземпляра. Обратите впимапие, что заголовок Instance Manipulation (IM) указывает порядок, в котором осуществлялось манипулирование экземплярами: кодирование разности с последующим извлечением диапазона.

Наличие прокси-серверов, которые не воспринимают дельта-механизм, заставляет ввести новый код ответа. Поскольку большинство существующих на сегодняшний день прокси-серверов не поддерживают даже последнюю версию HTTP, маловероятно, что в ближайшем будущем прокси-серверы смогут поддерживать дельта-механизм. Большинство прокси-серверов игнорирует коды ответов, которые они не понимают, и пересылают эти ответы, не кэшируя их; следовательно, они будут вести себя аналогичным образом и для ответов с новым кодом 226 IM Used. Прокси-сервер, который не поддерживает дельта-механизм, но ошибочно кэширует ответ с разностным кодом, может вернуть такой ответ клиенту, который не способен обработать разность. При использовании нового кода ответа 226 IM Used про- кси-сервер, не воспринимающий дельта-механизм, скорее всего не будет кэшировать ответ, поскольку он не понимает код ответа. Таким образом, маловероятно, что прокси-сервер возвратит неверный ответ клиенту, обратившемуся с запросом на этот же ресурс позднее.

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

GET /chap15.html НТТР/1.1 Host: www.vcdiff.com

If-None-Match: "38432-s8-13", "97-ru486-v", "2-dumbya-1f" A-IM: vcdiff, diffe, gzip

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

HTTP/1.1 226 IM Used

Date: Sun, 2 Jul 2000 23:35:35 GMT

ETag: "282-ela-899"

IM: vcdiff

Delta-Base: "97-ru486-v"

Сервер выбирает экземпляр с атрибутом содержимого "97-ru486-v" в качестве базы вычисления разности для текущего экземпляра ответа. Выбор экземпляра указывается в новом заголовке Delta-Base. Поле ETag в ответе с разиостыо идентифицирует текущий экземпляр ответа. Клиент теперь знает, как реконструировать последнюю версию ресурса. Если экземпляр, для которого создавалась разность, не был указан, то подразумевается, что запрос должен иметь возможность уникально идентифицировать базовый экземпляр. Сервер просто возвращает разность для этого базового экземпляра и не обязан предоставлять какую-либо дополнительную информацию.

На рис. с 15.1 но 15.4 представлены упрощенные версии этапов обработки разности. Клиент имеет в своем кэше экземпляр vl ресурса r с ассоциированным с ним атрибутом содержимого "xyz", полученным от исходного сервера А. Теперь предположим, что клиент отправляет запрос на ресурс исходному серверу А, а в за-

Рис. 15.i. Клиент запрашивает ресурс г с исходного сервера

головке If-None-Match запроса указан атрибут содержимого ETag экземпляра, который он имеет в своем кэше (рис. 15.1).

Исходный сервер имеет новый экземпляр ресурса, а именно v2, с ассоциированным с ним атрибутом содержимого "abc". Исходный сервер А формирует разность между экземплярами vl и v2 и возвращает ее клиенту вместе с атрибутом содержимого нового экземпляра, а именно, "abc" (рис. 15.2). Клиент реконструирует текущий экземпляр ресурса r на основе кэшированного экземпляра vl и разности.

Рис. 15.2. Исходный сервер возвращает разность относительно экземпляра vl

На рис. 15.3 представлен клиентский запрос на этот же ресурс, когда клиент имеет два кэшированных экземпляра vl и v2.

Текущим является экземпляр v3. Исходный сервер вычисляет разность между экземплярами v2 и v3, значение атрибута содержимого для нового экземпляра "pqr". Он также включает заголовок Delta-Base со значением "abc", чтобы уведомить клиента, что базовым экземпляром, относительно которого была вычислена разность, был v2 (рис. 15.4).

Рис. 15.3. Клиент запрашивает ресурс г, указывая свои кэшированные экземпляры

 

Рис. 15.4. Исходный сервер возвращает разность между текущим экземпляром и экземпляром v2

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

Текущее состояние дел с внедрением дельта-механизма в НТТР/1.1

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

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