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

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

410 Часть V. Web-приложения

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

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

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

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

держания, отделяют от перехватывающих устройств. Может использоваться один

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

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

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

строя одного кэша.

Поскольку перехватывающий прокси-сервер располагается на пути всего трафи-

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

ключен от Internet. Способом предотвращения таких отказов является отслеживание

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

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

му серверу. Более устойчивый механизм [Fou] повторяют запрос исходному серверу,

если кэш не обнаруживает соответствующих пакетов TCP SYN/ACK для SYN.

КОМПЛЕКСНЫЕ АППАРАТНЫЕ РЕШЕНИЯ

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

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

в сокращении затрат на администрирование по сравнению с редиректорами. Ис-

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

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

монтируется в стойку.

Имеются две категории таких комплексных решений: устройства первой катего-

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

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

мутаторов L4/L5. Гибридная версия устройств включает модули, которые осущест-

вляют коммутацию на четвертом уровне. При обнаружении отказа кэша устройст-

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

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

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

С комплексными аппаратными решениями обычно поставляются специализиро-

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

жет потребовать перенастройки кэша. Возможности перенастройки (добавление

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

нии. Потребитель может оказаться неспособным собрать подробную информацию

о трафике своих кэшей. В общем случае ему приходится использовать те виды из-

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

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

лия специализированных ядра ОС и файловой системы.

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

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

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

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

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

Глава 11. Кэширование 411

11.11.

Препятствия для кэширования

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

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

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

ки их преодолеть. Начнем с отключения кэширования (cash busting)

—

преднамерен-

ных действий некоторых исходных серверов, чтобы предотвратить кэширование от-

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

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

11.11.1.

Отключение кэширования

Не все исходные серверы заинтересованы в кэшировании ответов прокси-серве-

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

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

кэшированное Web-содержание, есть некоторая вероятность того, что это Web-со-

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

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

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

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

ширование не нарушает функциональности Web-сайта.

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

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

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

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

веру нужно узнать точное число клиентов, которые загружали его страницы и

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

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

девших рекламу.

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

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

щую предотвратить кэширование ответа. Первоначально такая методика рассмат-

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

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

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

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

параметров кэширования, которые эффективно отключают кэширование. Напри-

мер,

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

что ресурс считается устаревшим сразу после поступления в кэш. Кэш не храпит

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

чить в заголовок ответа директивы Cache-Control: по cache или Cache-Control: по

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

ния

—

умышленное изменение страницы без фактического изменения ее содержи-

мого.

Например, объявление на странице может только слегка перемещено, изме-

няя тем самым компоновку страницы.

Рассмотрим два способа снижения мотивации для отключения кэширования.

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

изображений с исходного сервера на прокси-сервер.

Одной из попыток решения проблемы отключения кэширования было предло-

жение методики названной подсчет числа обращений к ресурсу (hit-metering)

412 Часть V. Web-приложения

[ML97J. Методика вводит новый НТТР-заголовок, Meter, который будет использо-

ваться кэшем для передачи исходному серверу числа обращений к ресурсу. Основ-

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

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

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

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

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

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

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

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

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

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

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

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

реализовать измерения числа обращений к ресурсам в Web-компонентах. Админи-

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

щений. Отключение кэширования, в некотором смысле, оказалось самым простым

и надежным путем для администраторов исходных серверов.

Вторая методика, называемая ad-inseition [Ami99], предполагает, что прокси-

сервер добавляет рекламные объявления на страницу и снимает эту задачу с исход-

1ЮГ0 сервера. Такой подход требует, чтобы прокси-сервер взаимодействовал с ис-

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

ные объявления действительно помещаются на Web-страницы. Выигрыш агентов

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

ся,

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

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

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

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

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

ков».

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

пользователю и размещаются на странице в качестве счетчиков. Большинство

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

мент. Путем проверки содержимого HTML-страницы можно обнаружить присутст-

вие таких «изображений». Загрузка «Web-жучков» может привести к вызову сце-

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

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

показаны.

11Л1-2.

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

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

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

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

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

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

средственно запрашива10ш.ему пользователю. Таким образом, конфиденциальность

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

НТТР/1.1 предлагает новые заголовки и механизмы для защиты конфиденциаль-

ности. Например, Д1!ректива запроса и ответа no-store предотвравдает кэширование

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

Глава 11. Кэширование 413

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

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

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

ность. Однако для большинства HTTP-сообщений нет необходимости включать

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

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

сурс не кэшировался на пути своего прохождения от сервера к клиенту. Аналогич-

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

широван.

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

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

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

от исходных серверов. Исходный сервер, заинтересованный в отслеживании поль-

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

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

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

Использовапие перехватывающих прокси-серверов, которые практически неви-

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

альности. В то время как некоторые исходные серверы можно рассматривать как

системы занимающиеся сбором информации о клиентах со всеми вытекающими

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

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

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

тывающего прокси-сервера.

Популярность Web и легкость, с которой нарушается конфиденциальность,

привлекли к этой проблеме повышенное внимание. Проблема конфиденциально-

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

Европейского Союза защитить конфиденциальность пользователей и провайдеров

Web-содержания. Некоторые корпорации в США имеют теперь в штате сотрудни-

ка отвечающего за безопасность пользователей (Chief Privacy Officer), обязанно-

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

11.12.

Кэширование и репликация

Репликацию можно рассматривать как альтернативу кэшированию. При кэши-

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

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

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

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

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

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

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

ду собой для устранения устаревания ресурсов. Однако часто на зеркалах публику-

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

па зеркала по необходимости.

Одним из преимуществ репликации над кэшированием заключается в модели

обновления. Обновление ресурсов при репликации выполняется вне протокола

HTTP. Список реплик заранее известен администраторам зеркал, что позволяет

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

414 Часть V. Web-приложения

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

также используется групповое вещание.

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

методы. В главе 15 (раздел 15.2) будут изложены основы механизма пересылки

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

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

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

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

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

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

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

доставить изменения без ожидания запроса от пего. Устаревание ресурса может

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

сурсы могут меняться довольно часто.

Доступ к зеркальным сайтам может осуществляться несколькими способами:

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

шее к нему зеркало. Предполагается, что клиент из Новой Зеландии скорее

выберет зеркало, находящееся в Австралии, чем в США. Запросы к сайту су-

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

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

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

печивающих доступ к программному обеспечению большого объема.

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

реадресацию на уровне HTTP с помощью кодов запросов 302 Moved Tempo-

rarily, 303 See Other или 307 Temporary Redirect. Клиент использует инфор-

мацию в заголовке Location для контакта с репликой. Переадресация на уров-

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

ответа, вызванной созданием двух соединений вместо одного.

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

стым способом. DNS-сервер при преобразовании доменного имени, может

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

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

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

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

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

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

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

в главе 5, раздел 5.3.5).

11.13.

Распределение Web-содержания

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

цию.

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

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

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

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

логии, в том числе и DNS. Один из способов заключается в распределении основ-

ных и встроенных ресурсов. Основные документы

—

это документы-контейнеры, а

Глава 11. Кэширование 415

встроенные ресурсы, — изображения или скрипты, — являются частью Web-стра-

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

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

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

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

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

изображения. Термин «ближайший» может трактоваться либо в географическом

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

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

конечного пользователя.

Цель распределения Web-содержапия не отличается от целей кэширования.

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

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

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

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

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

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

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

держание в соответствие с текущими потребностями.

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

серверов в Internet. При подходе, использующем распределение Web-содержания,

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

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

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

Web-содержания, об изменении ресурсов.

Рассмотрим в качестве примера распределение Web-содержапия, предложенное

Akamai [AkaJ. Сайт, который распределяет часть своих ресурсов с помощью Akamai,

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

с именем компьютера, например, al025o.akamaitech.net. Посредством DNS это имя

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

копия ресурса. Решение, какой IP-адрес возвратить клиенту, принимается DNS-cep-

вером. Указа1Н1ый таким DNS-сервером ресурс должен находится близко к DNS-

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

близко к своему DNS-серверу в терминах сетевого расстояния, и, таким образом, ре-

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

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

чтобы определить подходящий сервер Akamai, имеющий запрашиваемый ресурс. На-

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

http://www.cnn.com. Встроешюе изображение secdef.gif ресурса http://www.cnn.com/

secdef.gif будет переименовано в http://al38g.akamai.technet/cnn.com/secdef.gif

Префикс http://al38g.akamai.technet относится к серверу Akamai, который обслу-

живает этот ресурс. Когда DNS преобразует доменное имя al38g.akamai.technet, то

определяется некий IP-адрес (скажем

1.2.3.4),

который адресует к ближайшему

к клиентскому DNS-серверу серверу Akamai. Этот сервер должен иметь изображе-

1ше

secdef.gif.

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

протокол, запросит ресурс или с другого сервера Akamai, или с исходного сервера

http://www.cnn.com. Далее этот ресурс будет кэширован сервером Akamai для ис-

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

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

URL http://al38g.akamai.technet/cnn.com/foo.gif Различие будет заключаться в том.

416 Часть V. Web-приложения

что будет возвращен IP-адрес

5.6.7.8

другого сервера Akamai, который находится

бл1гже к DNS-серверу клиента.

Распределение Web-содержапия по серверам Akamai должно выполняться та-

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

сай г. Алгоритм Akamai запатентован, а механизм — нет. Значение TTL DNS-сер-

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

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

al38g.akamai.technet может получить IP-адрес зеркального сервера Akamai, кото-

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

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

выполнение преобразований. Хотя изменение значений TTL DNS-сервера Akamai

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

DNS-трафик в сети и недостаточно изучено.

Существует несколько проблем при распределении Web-содержания. Исходные

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

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

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

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

RTT, чем с выбранным сервером распределения Web-содержания. В главе 15 (раз-

/1с;

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

тов [)аспределения Web-содержания на производительность.

Гех1И1чески сайты распределения Web-содержапия функционируют от лица ос-

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

ния Web-содержания, предполагая, что сервер распределения Web-содержапия со-

вместим с протоколом HTTP. Сайты распределения Web-содержания используют

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

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

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

Среди компаний, использующих решения для распределения Web-содержания

можно назвать Adero [Ade], Akamai, Cisco

[Cis],

Digital Island

[Dig],

Exodus

[Exo],

Mirror Image

[Mir],

Netcaching [Netb], SolidSpeed

[Sol],

Speedera [Speb] и Unitech

[Uni].

Adero является примером сети распределения Web-содержания, где достав-

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

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

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

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

работать с потоковым Web-содержапием.

11.14.

Адаптация Web-содержания

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

исходные серверы путем перемещения части его функций ближе к клиенту. Адап-

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

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

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

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

Цель распределения Web-содержания — переместить Web-содержание ближе

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

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

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

Глава 11. Кэширование 417

Проект протокола ЮАР (Internet Connection Adaptation Protocol) [ICAOl]

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

ции Web-содержания. Клиент адаптации Web-содержания посылает HTTP-сооб-

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

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

ICAP может располагаться на прокси-сервере и играть роль как прокси-сервера,

так и ICAP-клиента. В некотором смысле размещение ЮАР-клиента может осво-

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

В качестве примера адаптации Web-содержания рассмотрим ресурс, имеющий-

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

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

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

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

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

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

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

звукового сопровождения, так и форматов Web-содержания. Однако преобразова-

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

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

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

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

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

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

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

ции Web-содержания. Роль серверов адаптации Web-содержания заключается

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

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

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

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

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

рез который ресурс поступает к клиенту. Адаптация Web-содержания пока что пе-

реживает период становления и еще рано обсуждать ее потенциал.

11.15.

Резюме

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

шированием. Кэширование является зрелой технологией с решениями, предлагае-

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

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

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

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

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

пределения Web-содержания и его адаптации. Кэширование является развиваю-

щейся областью бизнеса, связанного с Web, и хотя кажется, что необходимо

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

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

Доставка

мультимедийных потоков

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

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

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

текста и изображений. Кэширование в Web ста7ю средством, позволившим сокра-

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

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

имеющих высокоскоростные подключения к Internet. Подобно обычному тексту и

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

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

копий видео1а1ипов или звукового сопровождения для последующего воспроизведе-

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

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

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

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

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

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

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

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

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

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

содержания через Internet. Хотя для передачи мультимедийного содержания может

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

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

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

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

и видео. Далее мы рассмотрим ряд Internet-протоколов, которые поддерживают

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

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

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

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

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

вер,

что и Web. Эти приложения обычно используют протокол Real Time Streaming

Protocol (RTSP) как альтернативу HTTP. Определенный в документе RFC 2326

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

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

тика RTSP во многом заимствованы из НТТР/1.1. Мы поговорим о сходстве меж-

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