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

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

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

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

\тя функционируют независимо. Точная начальная оценка значений RTT поможет

установить для нового соединения время таймаута повторной передачи (КТО). Бо-

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

окна каждого соединения. Ансамбль может трактоваться как одно ТСР-соединепие

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

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

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

ТСР-соединению. Подобная стратегия позволяет Web-браузеру иметь несколько

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

пропускной способности сети. WebMux также решает эту проблему. Главным от-

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

ТСР-соединении, тогда как TCP Control Block Interdependence координирует со-

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

ТСР-соединений в ансамбль.

Временное совместное использование предусматривает инициализацию управ-

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

соединения. При закрытии ТСР-соедипепия значение MSS, размер скользящего

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

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

ТСР-соединепие с Web-сервером для извлечения встроенного изображения после

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

ре поддерживает временное совместное использование, повое соединение может

начаться со скользящего окна большего размера и при более точной оценке значе-

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

изображения. В отличие от согласованного совместного использования, временное

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

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

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

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

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

информации о состоянии.

Предложение TCP Control Block Interdependence является попыткой оптимизи-

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

менных характеристик. Особенно актуально это для НТТР-трафика, поскольку

при извлечении Web-CTpaimn используется большое количество ТСР-соединений.

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

ких Web-передач сильно зависит от поведения TCP в переходных режимах. Эф-

фективные методы управления группами ТСР-соединений могут также избавить

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

ют несколько сеансов в одном ТСР-соединении. Предложение Control Block

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

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

открытие и закрытие ТСР-соединений [Вга92, Bra94j. Внедрение предложения

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

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

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

скользящего окна. Предложение TCP Control Block Interdependence было опубли-

ковано в качестве информационного документа IETF в 1997 г. и не проходило по-

следующих этапов процесса стандартизации IETF.

Глава

15.

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

511

15,1.3.

Integrated Congestion Management

WebMux и TCP Control Block Interdependence предлагают более тесную связь

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

тем же удаленным компьютером. Однако успех Web и коммерциализация Internet

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

ем загруженностью. Некоторые коммерческие продукты повышают эффективность

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

вые алгоритмы управления TCP. Как говорилось в главе 12, многие приложения

для работы с потоками аудио и видео используют UDP вместо TCP. Этим прило-

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

это делается в TCP. Рост объема трафика, для которого не осуществляется управ-

ление загруженностью, поставил под угрозу стабильность Internet. Например,

Web-сервер может посылать дагншю более агрессивно, чем предполагает механизм

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

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

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

ва заторов в сети. Кроме того, традиционный программный интерфейс сокетов не

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

тупной пропускной способности. Например, мультимедийное приложение может

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

ной способности-

В предложении Integrated Congestion Management предусматривается исгюльзо-

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

блем справедливого распределения ресурсов при параллельных ТСР-соединениях.

Помимо эффективного мультиплексирования трафика предлагается архитектура

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

реагировать на изменения пропускной способности [BRS99, BSOO]. В состав пакета

Congestion Manager входят несколько программных модулей, которые управляют

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

ция TCP может быть выстроена поверх этих модулей. На передающей стороне

Congestion Manager определяет пропускную способность, доступную для передачи

данных удаленному компьютеру, применяя специальный алгоритм. Этот алгоритм

основан на использовании информации о предыдущих передачах дагнгых и перио-

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

тестовые передачи гарантируют, что Congestion Manager будет обладать своевре-

менной информацией о загруженности сети, даже если принимающее приложение

не предоставляет ее. Например, медиаплейер, принимающий UDP-пакеты, может

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

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

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

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

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

личиями. Подобно TCP, Congestion Manager передает данные с помощью скользя-

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

и мультипликативно (в геометрической прогрессии) уменьшается в случае потерь

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

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

в TCP. В отличие от традиционных реализаций TCP, Congestion Manager задает

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

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

Congestion Manager передает данные медленнее при отсутствии информации от по-

лучателя, чтобы избежать перегрузки сети. Таким образом Congestion Manager от-

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

сети отсутствует.

После определения доступной пропускной способности соединения с удален-

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

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

совместным использованием в TCP Control Block Interdependence. Это решает

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

ствии Web-клиента и сервера через несколько ТСР-соединений одгювременно.

При простейшей стратегии выделения ресурсов имеющаяся пропускная способ-

ность делится пор»овну между конкурирующими потоками. Затем Congestion

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

ной способности. Приложение, например Web-сервер, решает на основе выделен-

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

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

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

от традиционной абстракции сокетов. Приложение выражает заинтересованность

в передаче данных. Через некоторое время Congestion Manager уведомляет прило-

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

шает, какие данные отправлять. Congestion Manager может также уведомлять при-

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

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

аудио или видео к доступной пропускной способности.

Предложение Integrated Congestion Management пересматривает роль, которую

играют хосты в управлении загруженностью в Internet и обеспечении требований

приложения. Таким образом предложение затрагивает гораздо более широкий круг

проблем и решает более амбициозные задачи, чем WebMux и TCP Control Block

Interdependence. Предложенный подход требует внесения изменений в интерфейс

прикладного программирования, что осложняет его широкое внедрение. С другой

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

Congestion Manager взаимодействует с традиционными получателями (например,

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

gestion Manager). Congestion Manager был принят в качестве рабочего проекта

в июле 2000 г. [BSOO] в результате работы группы Endpoint Congestion Mana-

gement Working Group IETF. Оценить окончательные результаты усилий па этом

начальном этапе процесса стандартизации довольно трудно.

15.2.

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

За последние несколько лет возросло беспокойство, связанное с ростом объема

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

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

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

этой проблемы. Предложению применить данный механизм предшествовали два

других подхода: сжатие данных и селективная загрузка ответов. Сокраш.ение объе-

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

разделе описываются шаги, предпринятые в этом направлении сообществом, зани-

мающимся совершенствованием протокола HTTP. Обзор эволюции протокола так-

Глава

15.

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

513

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

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

с учетом таких изменений.

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

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

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

сжат отправителем (как правило, исходным сервером) и подвергнут декомпрессии

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

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

НТТР/1.1 было замечено, что многие Web-ресурсы передавались в несжатом виде.

Сжатие да1Н1ых функционально доступно и в НТТР/1.0. Текст, который хорошо

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

Текстовые ресурсы обычно имеют меньший размер по сравнению с изображения-

ми,

а популярные форматы изображений уже являются сжатыми (например, GIF,

JPEG).

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

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

того,

можно использовать тот или иной алгоритм сжатия в зависимости от типа со-

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

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

го языка. Такие словари создаются для оптимизации поиска часто используемых

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

выполнять свое собственное сжатие. Однако с учетом того, что Web-сообщеиие

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

ментов пути передачи данных. Поскольку меньший объем данных обычно переда-

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

перемещается от отправителя к получателю через множество сегментов. Экспери-

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

фект, чем сжатие, выполняемое модемами [Nie97].

Особая проблема связана с использованием протоколом HTTP в качестве

транспортного механизма протокола TCP. Затраты на ожидание первого пакета

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

состоящего из текста (HTML) и изображений, сначала загружается HTML, а затем

изображения. Сжатие HTML-страницы (которая часто находится в первом пакете)

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

время ожидания контейнерного документа снижается. Браузер может быстрее на-

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

зователя.

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

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

использованы существующие механизмы HTTP, такие как заголовки Accept-

Encoding и Content-Encoding. Другой способ уменьшить объем данных состоит

в использовании условных запросов в HTTP, например, заголовок If-Modifled-

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

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

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

Механизм запросов на диапазоны в НТТР/1.1 был шагом в этом направлении и

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

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

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

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

514

Часть

VI.

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

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

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

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

ми на диапазоны.

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

тов,

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

необходимых

для

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

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

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

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

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

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

нологиях. Имеется множество алгоритмов, которые постоянно совершенствуются

применительно к различным форматам данных. Средства определения разности

для традиционных файлов достаточно популярны. Однако применительно к Web

механизм вычисления разности (дельты) должен учитывать определенные ограни-

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

ловых систем.

Мы начнем этот раздел с рассмотрения побудительных причин для применения

дельта-механизма для HTTP-сообщений. Далее мы поговорим о выборе алгорит-

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

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

в HTTP/1.1. В конце мы познакомимся с текущим состоянием дел по добавлению

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

Немного о терминологии: в НТТР/1.1 нет термина для описания значения, ко-

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

бранной версии данного ресурса. Для этой цели вводится термин экземпляр.

15.2.1.

Побудительные причины для использования

дельта-механизма для HTTP-сообщений

Как описывалось ранее в главе 10 (раздел 10.4), ресурсы в Web часто изменяют-

ся,

и эти измененные ресурсы часто снова запрашиваются тем же клиентом

[DFKM97].

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

женная в байтах, является небольшой. Например, ответ может содержать число об-

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

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

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

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

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

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

Исходный сервер может потратить меньше времени на формирование и отправку

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

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

что приведет к амортизации затрат на формирование разности. Сокращается загруз-

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

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

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

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

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

Глава

15.

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

515

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

ля,

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

руется, и последующие обращения к ресурсу будут браться из кэша, рели на пути

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

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

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

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

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

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

прос на получение разности) перед его передачей исходному серверу.

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

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

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

ные способы вычисления разности.

15.2.2.

Сравнение дельта-алгоритмов

Для вычисления разности между версиями ресурса существует множество алго-

ритмов. В традиционных файловых системах для создания разности между двумя

текстовыми файлами используется команда UNIX

diff.

Разность может быть пред-

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

сти:

добавление, удаление и изменение. Использование опции -е команды diff длет

возможность генерировать сценарий. Этот сценарий может использоваться про-

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

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

вычислена на одной стороне и передана другой стороне в виде сценария, а этот

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

что разность имеет гораздо меньший размер по сравнению с новой версией.

Чтобы оценить алгоритмы вычисления разности для ресурсов в Web, следует

иметь в виду следующие факторы:

• Время вычисления разности между вариантами ресурса.

• Размер разности.

• Частота изменения ресурса.

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

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

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

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

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

вычисления текстовой разности, такими как Revision Control System (RCS) [Tic85]

и Source Code Control System (SCCS) [Roc75], принципа

опережающей

разности.

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

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

сию.

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

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

ближайшими версиями обычно невелика. Главное наблюдение состоит в том, что

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

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

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

мер,

текстовые ресурсы изменяются чаще изображений [DFKM97].

516

Часть

VI.

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

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

ным в 1997 г., целью которого было оценить, надо ли расширять протокол, добав-

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

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

менять дельта-механизм, а также познакомимся с общими соглашениями по

внедрению расширений в инфраструктуру НТТР/1.1. В конце мы поговорим о те-

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

НТТР/1.1.

МЕТОДОЛОГИЯ ИССЛЕДОВАНИЯ

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

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

ские соображения:

• Чтобы обеспечить репрезентативность различных атрибутов, таких как тип

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

ресурсов.

• Следует вычислять разность для различных версий ресурсов во времени.

• Эксперимент должен повторяться через определенный период времени для

множеств ресурсов, отобранных из самых разнообразных мест.

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

жения:

• Частота, с которой изменяются ресурсы.

• Время вычисления разности между версиями ресурсов.

• Экономия в объеме данных при передаче разности в сравнении с передачей

полного ответа.

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

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

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

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

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

опубликован в [MDFK97a], а более подробный отчет можно найти в [MDFK97bJ.

Исследование проводилось несколько лет назад, гю единственный основной фак-

тор,

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

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

ний в различных форматах). Никаких значительных изменений, связанных с уско-

рением вычисления разности или с алгоритмами сжатия, не произошло.

Главным отличием этого исследования от проводившихся ранее (например,

[HL96J), было использование потока реальных запросов и ответов в Web, вместо

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

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

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

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

расположенных в США. Один источник данных представлял собой корпоративный

прокси-сервер. Прокси-сервер отслеживал все исходящие запросы. В течение всего

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

ших примерно полмиллиона трасс примерно 8000 различных клиентов). Второй

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

Глава

15.

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

517

пизации. Было записано 19 гигабайтов данных в течение 17 дней, что составило

около миллиона трасс примерно 7500 клиентов. Трассировка пакетов перехватыва-

ет данные на низком уровне и реконструирует их в запросы и ответы HTTP, как

говорилось в главе 14 (раздел 14.1). Множество ресурсов для оценки дельта-мех-

иизма было выбрано из этих двух наборов.

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

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

Идентифицировались ответы для одного и того же ресурса, имеющие код статуса

200 ОК для более чем одного экземпляра, а значения в заголовке ответа Last-

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

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

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

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

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

ваются

дельта-приемлемыми.

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

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

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

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

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

та команды diff -е с помощью программы gzip для уменьшения размера разности.

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

vdelta (позднее переименованный в vcdiff

{¥NQQ])y

который не только находит раз-

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

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

плохо подходили для вычисления разности. Например, изображения GIF и JPEG

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

мало пользы. Программы, подобные

diff,

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

сурсов и не будут работать с двоичными ресурсами. В то же время алгоритм vcdiff

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

для всех ресурсов, включая изображения.

РЕЗУЛЬТАТЫ ИССЛЕДОВАНИЯ

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

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

38%

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

ми,

в то время как только около 10% ресурсов оказались дельта-приемлемыми

в трассах пакетов. Главная причина такого различия заключается в том, что при

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

—

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

GIF,

JPEG, MPEG и аудиоформаты.

При более широком исследовании никакие форматы не исключались, а данные со-

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

ления типов содержания, имеющихся в Web.

Были рассчитаны две группы показателей: количество байтов, которое будет сэ-

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

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

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

ние (и декодирование) разности. Поскольку разность вычисляется только при по-

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

дываются на все содержание.

518

Часть

Vl.

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

Исследование показало, что около 30% объема полных ответов, имеющих тела,

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

ется

vcdiff.

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

ляра, 83% объема тел ответов нет необходимости передавать. В ходе исследования

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

ханизма к предыдущему экземпляру. Кроме того, исследование показало, что из

всех протестированных алгоритмов vcdiff в большинстве случаев дал наилучший

результат.

Один из результатов состоял в том, что библиотечная реализация (что является

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

Web-серверов) t;ct/z//^работает с производительностью линии Т-1 (193 Кб/с). Таким

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

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

кодирования разности и сжатия. Исследование подтвердило, что vcdiff является

наиболее эффективным (с точки зрения затрат времени) для кодирования разно-

сти и сжатия. Исследование также показало, что кодирование разности и сжатие

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

больших файлов.

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

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

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

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

ло,

что объем передаваемых данных ответа может быть сокращен почти на треть, а

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

40%.

Для трасс пакетов с разнообразными типами содержания (нетекстовые типы

не игнорировались) может быть достигнут очень большой выигрыш в объеме пере-

даваемых данных (около 85%), если ресурсы дельта-приемлемы. Однако включе-

ние всех типов содержания снижает общую эффективность примерно на 9%. В ре-

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

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

тие,

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

ДРУГИЕ СООБРАЖЕНИЯ, СВЯЗАННЫЕ С ДЕЛЬТА-МЕХАНИЗМОМ

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

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

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

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

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

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

может оказаться подходящим местом для применения дельта-механизма. Размер

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

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

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

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

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

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

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

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

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

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

Глава

15.

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

519

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

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

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

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

связанную с применением дельта-механизма на клиенте.

15.2.3.

Проблемы, связанные с внедрением

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

Внедрение дельта-механизма требует изучения изменений, которые необходимо

будет внести в протокол НТТР/1.1. Клиент или прокси-сервер должен иметь воз-

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

прос,

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

тифицировать соответствующие разности. Рабочий проект [MKD"^01J для этого

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

книги имел статус

предложения

по

стандарту.

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

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

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

были выделены в другой проект стандарта [MDHJ.

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

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

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

ния.

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

Соображения, связанные с внедрением. К основным проблемам, связанным

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

• Идентификация экземпляров. Клиент должен идентифицировать экземпляр

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

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

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

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

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

сервере наиболее свежий экземпляр. Не все экземпляры, кэшироваиные кли-

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

• Синтаксис. Должен быть определен синтаксис, относящийся к спецификации

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

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

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

иметь определенные предпочтения для этих алгоритмов. Клиент должен

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

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

при выражении предпочтений может зависеть от типа содержания и размера

кэшированного ответа.

• Реализация. Формирование, передача, применение и кэширование разности

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

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

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

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