Добавление дельта-механизма в НТТР/1.1

За последние несколько лет возросло беспокойство, связанное с ростом объема трафика в Internet и требованием снижения времени ожидания на стороне пользователя при получении ответов на Web-запросы. В этом разделе мы обсудим предложение, связанное с добавлением в НТТР/1.1 дельта-мехапизма для решения этой проблемы. Предложению применить данный механизм предшествовали два других подхода: сжатие данных и селективная загрузка ответов. Сокращение объема ненужных данных, передаваемых через сеть, является важной задачей, в этом разделе описываются шаги, предпринятые в этом направлении сообществом, занимающимся совершенствованием протокола HTTP. Обзор эволюции протокола также проливает свет на то, как возникают определенные идеи, которые требуют внесения изменений в протокол, а также на то, как протокол продолжает развиваться с учетом таких изменений.

Типичным механизмом, с помощью которого можно достичь двух целей, заключающихся в уменьшении числа пакетов, передаваемых через Internet, и времени ожидания на стороне пользователя, является сжатие данных. Ответ может быть сжат отправителем (как правило, исходным сервером) и подвергнут декомпрессии получателем. При этом передается меньший объем данных, а время, затрачиваемое на передачу этих данных, обычно уменьшается. В процессе эволюции протокола НТТР/1.1 было замечено, что миогие Web-ресурсы передавались в несжатом виде. Сжатие данных функционально доступно и в НТТР/1.0. Текст, который хорошо поддается сжатию, по-прежнему составляет значительную часть Web-трафика. Текстовые ресурсы обычно имеют меньший размер по сравнению с изображениями, а популярные форматы изображений уже являются сжатыми (например, GIF, JPEG). Наличие и доступность алгоритмов быстрой компрессии и декомпрессии для текстовых документов сделало этот подход еще более привлекательным. Кроме того, Можно использовать тот или иной алгоритм сжатия в зависимости от тина содержания. Например, могут быть использованы специализированные словари, которые учитывают частотные характеристики появления символов алфавита данного языка. Такие словари создаются для оптимизации поиска часто используемых в языке слов. Помимо компрессии сообщений программным путем, модемы могут выполнять свое собственное сжатие. Однако с учетом того, что Web-сообщение проходит по множеству каналов, модемы представляют лишь один из многих сегментов пути передачи данных. Поскольку меньший объем данных обычно передается за меньшее время, можно достичь совокупной экономии, учитывая, что ответ перемещается от отправителя к получателю через множество сегментов. Эксперименты показали, что традиционное сжатие данных дает значительно больший эффект, чем сжатие, выполняемое модемами [Nie97].

Особая проблема связана с использованием протоколом HTTP в качестве транспортного механизма протокола TCP. Затраты на ожидание первого пакета TCP выше, чем для последующих пакетов. При передаче контейнерного документа, состоящего из текста (HTML) и изображений, сначала загружается HTML, а затем изображения. Сжатие HTML-страницы (которая часто находится в первом пакете) приведет к тому, что последующие изображения будут поступать быстрее. Общее время ожидания контейнерного документа снижается. Браузер может быстрее начать отображать документ, сокращая тем самым время ожидания на стороне пользователя.

Сжатие является общим механизмом уменьшения объема данных, передаваемых между отправителем и получателем. Для задания способа сжатия могут быть использованы существующие механизмы HTTP, такие как заголовки Accept- Encoding и Content-Encoding. Другой способ уменьшить объем данных состоит в использовании условных запросов в HTTP, например, заголовок If-Modified- Since используется для извлечения ресурса только в том случае, если он был модифицирован после определенного момента времени, указанного в запросе. Это полезно при наличии кэшей, в которых хранятся предыдущие версии ответов..

Механизм запросов на диапазоны в НТТР/1.1 был шагом в этом направлении и дал возможность передавать только части ресурса. Однако механизм запросов на диапазоны годится для отправки только непрерывных фрагментов ресурса. Предположим, что ресурс изменяется так, что с помощью запроса на диапазон могут быть запрошены только новые фрагменты ресурса. Подобный запрос приведет к передаче минимального объема данных. Однако ресурсы часто изменяются таким образом, что клиентам не известно, в каком месте произведены изменения, и они не могут запросить только эти измененные фрагменты, воспользовавшись запросами на диапазоны.

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

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

Немного о терминологии: в НТТР/1.1 нет термина для описания значения, которое будет возвращено в ответ на запрос GET в текущий момент времени для выбранной версии данного ресурса. Для этой цели вводится термин экземпляр.

Побудительные причины для использования дельта-механизма для НТТР-сообщений

Как описывалось ранее в главе 10 (раздел 10.4), ресурсы в Web часто изменяются, и эти измененные ресурсы часто снова запрашиваются тем же клиентом [DFKM97]. Можно предположить, что разность между экземплярами ресурса, выраженная в байтах, является небольшой. Например, ответ может содержать число обращений к ресурсу. Если два различных экземпляра этого ресурса отличаются только значением этого числа, разность между экземплярами ничтожна в сравнении с самим ресурсом. Исходный сервер может отправить либо весь экземпляр, либо разность между кэшированным экземпляром у получателя и текущим экземпляром на исходном сервере. Отправка разиости и быстрое воссоздание нового экземпляра на стороне получателя положительно сказывается на всех участниках транзакции. Исходный сервер может потратить меньше времени на формирование и отправку разности, чем в случае формирования и отправки всего экземпляра целиком. Помимо этого исходный сервер может кэшировать разность, а не различные экземпляры, что приведет к амортизации затрат на формирование разности. Сокращается загрузка сети, поскольку разность, как правило, имеет гораздо меньший размер, чем полный экземпляр. В действительности, если разность велика, сервер может отправить полный экземпляр. Принимающий клиент или прокси-сервер должен обработать ответ и воссоздать полный экземпляр из кэшированного экземпляра и разности. Если это может быть сделано быстро, пользователь вряд ли заметит какую-либо дополнительную задержку. Задержка может стать ощутимой только для первого пользователя, для которого инициируется обновление. Модифицированный экземпляр кэши- руется, и последующие обращения к ресурсу будут браться из кэша. Если на пути следования запроса-ответа имеется прокси-сервер, разность будет сохранена и отправлена дальше, если прокси-сервер участвует в механизме вычисления разности. Прокси-сервер может также применять дельта-механизм к своей кэшированиой записи и использовать обновленный кэшировапный ответ как полный ответ для будущих запросов от клиентов, не поддерживающих дел’ьта-мехаиизм. Кроме того, последующие запросы от таких клиентов могут преобразовываться в дельта-запрос (запрос на получение разности) перед его передачей исходному серверу.

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

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