веб

Беспроводные веб-технологии — это, конечно, замечательное изобретение по­следних лет, однако далеко не единственное. Для многих не что иное, как мульти­медиа, служит чашей святого Грааля сетевых технологий. Слово «мультимедиа» возбуждает и физиков, и лириков, и разработчиков, и коммерсантов. Одни видят в мультимедиа бесконечный источник интересных технических проблем, связанных, например, с доставкой (интерактивного) видео по заказу, другие — не меньший источник прибыли. Поскольку для передачи мультимедийных данных требуется очень высокая пропускная способность, довольно трудно заставить систему рабо­тать даже поверх стационарных соединений. Что касается беспроводных техно­логий, то добиться даже VHS-качества пока что не удается, и на решение этой проблемы потребуется, как минимум, несколько лет. Мы будем рассматривать далее методы передачи мультимедийных данных по проводным сетям.

Буквально мультимедиа означает использование двух или более средств аудио­визуальной информации. Если бы издатель этой книги захотел присоединиться к всеобщей моде пускания пыли в глаза, он мог бы разрекламировать ее как ис­пользующую мультимедийные технологии. В конце концов, в ней действительно используются два средства информации: текст и графика (рисунки). Тем не ме­нее, когда употребляется это слово, обычно имеются в виду некие информаци­онные сущности, длящиеся во времени, то есть проигрываемые в течение опре­деленного интервала времени, обычно во взаимодействии с пользователем. На практике чаще всего это аудио и видео, то есть звук плюс движущееся изобра­жение.

Несмотря на такое довольно понятное определение, многие, говоря «мульти­медиа», имеют в виду только чисто звуковую информацию, например интернет- телефонию или интернет-радио. Строго говоря, они не правы. Более удачным термином в данном случае является словосочетание потоковая информация (strea­ming media), однако мы, поддавшись стадному инстинкту, все же будем имено­вать аудиоданные, передающиеся в реальном масштабе времени, «мультимедиа». В следующих разделах мы узнаем, как компьютер обрабатывает звук и видео и как он сжимает такого рода данные. Затем мы рассмотрим некоторые сетевые технологии, связанные с мультимедиа. Довольно понятно и в хорошем объе­ме (три тома) взаимодействие сетевых и мультимедийных технологий описано в (Steinmetz и Nahrstedt, 2002; Steinmetz и Nahrstedt, 2003а; Steinmetz и Nahr- stedt, 2003b),

Довольно простым способом повышения производительности является сохране­ние ранее загружавшихся страниц на случай их повторного запроса. Этот метод особенно эффективен при работе с часто посещаемыми страницами (такими как www.yahoo.com или www.cnn.com). Сохранение веб-страниц «про запас» для по­следующего использования называется кэшированием. Обновление кэша являет­ся обычной процедурой для некоторого процесса, называемого сервером-посред­ником, или прокси. Чтобы иметь возможность использовать метод кэширования, браузер должен быть настроен на обращение к посреднику, а не к реальному сер­веру, на котором хранится страница. Если у сервера-посредника есть нужная стра­ница, она сразу же возвращается пользователю. В противном случае ее придется получить с сервера, добавить в кэш для будущего использования и только после этого предоставить пользователю.

С кэшированием связаны два важных вопроса.

1. Кто должен .заниматься кэшированием?

2.    Сколько времени страницы должны храниться в кэше?

На первый вопрос есть несколько ответов. На отдельных персональных ком­пьютерах часто имеется прокси, поэтому поиск ранее запрошенных страниц про­исходит быстро. В корпоративной ЛВС прокси-сервер обычно устанавливается на машине с разделяемыми ресурсами, и если один из клиентов данной ЛВС за­просил страницу с сервера, то другой может получить ее уже из кэша сервера-по- средника (прокси). Прокси-серверы часто устанавливают у себя провайдеры с целью повышения скорости доступа для всех своих клиентов. Нередко все эти кэши работают одновременно, поэтому запрос вначале отправляется на локаль­ный прокси-сервер. Если там страница не обнаружена, запрос передается на прок­си-сервер ЛВС. Не найдя у себя запрашиваемую страницу, последний обраща­ется к прокси-серверу провайдера. На этом этапе страница уже должна быть по­лучена в любом случае: либо она берется из кэша, либо приходит с веб-сервера. Схема с несколькими кэшами, работающими последовательно, называется ие­рархическим кэшированием. Возможная реализация этого метода показана на рис. 7.18.

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

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

Решается этот философский вопрос с использованием двух подходов. Пер­вый подразумевает эвристический анализ для принятия решения о сроке хране­ния страницы. Обычно он основывается на значении заголовка Last-Modified (см. табл. 7.13). Если страница подвергалась изменениям час назад, она будет храниться в кэше также в течение часа. Если же последние изменения были вне­сены в страницу год назад, очевидно, она содержит довольно стабильную инфор­мацию (например, список греческих и римских богов), и ее можно хранить в кэше в течение года, резонно предполагая, что за это время ничего на ней не изменит­ся. Несмотря на то, что такой эвристический анализ работает весьма успешно, все же время от времени из кэша извлекаются устаревшие страницы.

Другой подход является более дорогим, но и более надежным в смысле ис­ключения возможности хранения в кэше устаревших страниц. Используются осо­бенности RFC 2616, имеющие отношение к управлению кэшем. Одной из самых полезных особенностей является наличие заголовка If-Modified-Since, который сервер-посредник может посылать веб-серверу. В нем указывается страница, со­стояние которой хочет выяснить прокси, а также время внесения последних из­менений (значение заголовка Last-Modified на странице). Если страница не под­вергалась изменениям, сервер отошлет обратно короткое сообщение Not Modified («Изменений нет», код 304, см. табл. 7.12). Это будет означать, что прокси может использовать хранящуюся в кэше страницу. Если же на странице произошли ка­кие-либо изменения, сервер пришлет ее обновленную версию. Такой подход тре­бует обмена запросами и ответами, но если страница еще не устарела, ответ сер­вера будет очень коротким.

Два указанных подхода можно комбинировать. В течение первого интервала времени AT после получения страницы прокси просто извлекает запрошенную страницу из кэша. По прошествии определенного промежутка времени прокси использует If-Modified-Since для проверки состояния страницы. Выбор А Г под­разумевает некоторый эвристический анализ, базирующийся на знании времени последних изменений на странице.

Динамические веб-страницы (например, созданные PHP-скриптом) не должны кэшироваться вообще никогда, так как их содержимое переменное по определе­нию. Для этого, а также для некоторых других специальных случаев предусмотрен механизм, с помощью которого сервер может информировать все серверы-посред- ники на пути к клиенту о том, что не следует использовать текущую страницу без запроса ее актуальности. Этот же механизм может применяться для страниц, которые могут меняться довольно часто. В RFC 2616 определен также ряд дру­гих механизмов управления кэшированием.

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

Понятно, что кэширование во Всемирной паутине реализуется далеко не три­виально. Эту тему можно было бы обсуждать еще долго. На самом деле, ей по­священы отдельные книги, например (Rabinovich и Spatscheck, 2002; Wessels, 2001). Однако нам пора двигаться дальше.

Последовательность пакетов, передающихся от источника к приемнику, называ­ется потоком. При этом в сетях, ориентированных на соединение, все пакеты по­тока следуют по одному и тому же маршруту, а в сетях без установления соединения они могут идти разными путями. Каждому потоку требуются определенные усло­вия, которые можно охарактеризовать следующими четырьмя основными пара­метрами: надежность, задержка, флуктуация и пропускная способность. Все вме­сте они формируют то, что называется качеством обслуживания (QoS — Quality of Service), необходимым потоку. Некоторые общие приложения особенно строго подходят к вопросу качества обслуживания, как показано в табл. 5.3.

Первые четыре приложения предъявляют высокие требования к надежности. Некорректная доставка битов должна быть исключена. Обычно это достигается подсчетом контрольной суммы для каждого пакета и ее проверкой у получателя.

Если пакет во время передачи был испорчен, подтверждение о его доставке не высылается, и источник вынужден передавать его повторно. Такая стратегия обеспечивает высокую надежность. Четыре последних (аудио/видео) приложе­ния весьма толерантны к ошибкам, поэтому здесь нет никаких вычислений и про­верок контрольных сумм.

Приложения, занимающиеся передачей файлов, включая электронную почту и видео, не чувствительны к задержкам. Даже если все пакеты будут доставляться с задержкой в несколько секунд, ничего страшного не произойдет. Однако ин­терактивные приложения — например, обеспечивающие веб-доступ или удален­ный доступ, — к задержкам более критичны. Что касается приложений, работаю­щих в реальном масштабе времени, их требования к задержкам очень строги. Если при телефонном разговоре все слова собеседников будут приходить с задержкой ровно 2,000 с, пользователи сочтут такую связь неприемлемой. С другой сторо­ны, проигрывание видео- или аудиофайлов, хранящихся на сервере, допускает наличие некоторой задержки.

Первые три приложения спокойно отнесутся к неравномерной задержке дос­тавки пакетов, а при организации удаленного доступа этот фактор имеет более важное значение, поскольку при сильных флуктуациях символы на экране будут появляться скачками. Видео- и особенно аудиоданные исключительно чувстви­тельны к флуктуациям. Если пользователь просматривает видео, доставляемое на его компьютер по сети, и все кадры приходят с задержкой ровно 2,000 с, все нормально. Однако если время передачи колеблется от одной до двух секунд, то результат будет просто ужасен. При прослушивании звукозаписей будут замет­ны флуктуации даже в несколько миллисекунд.

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

В сетях ATM принята следующая классификация потоков по требованиям к качеству обслуживания:

1. 
   Постоянная битовая скорость (например, телефония);
2. Переменная битовая скорость в реальном времени (например, сжатые видео­данные при проведении видеоконференций);
3. Переменная битовая скорость не в реальном времени (например, просмотр фильмов через Интернет);
   
4. Доступная битовая скорость (например, передача файлов).

Такое разбиение по категориям может оказаться полезным и для других це­лей, и для других сетей. Постоянная битовая скорость — это попытка моделиро­вания проводной сети путем предоставления фиксированной пропускной спо­собности и фиксированной задержки. Битовая скорость может быть переменной, например, при передаче сжатого видео, когда одни кадры удается сжать в боль- Шей степени, нежели другие. Кадр, содержащий множество разноцветных де­талей, сожмется, скорее всего, плохо, и на его передачу придется потратить мно­го битов, тогда как кадр, запечатлевший белую стену, сожмется очень хорошо.

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

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

Мы уже видели различия характеристик сети при высокой и низкой флуктуа­ции на рис. 5.26. На рис. 5.27 изображен поток пакетов, доставляемый при значи­тельной флуктуации. Пакет 1 посылается с сервера в момент времени ( = 0 с и прибывает в момент времени t = 1 с. Задержка пакета 2 составляет уже не 1, а 2 с. Прибывающие пакеты буферизируются на клиентской машине.

В момент времени 10 с начинается воспроизведение, при этом пакеты с 1-го по 6-й уже находятся в буфере, поэтому их можно оттуда извлекать через равные интервалы и воспроизводить. К сожалению, пакету 8 не повезло: он задержался настолько, что его невозможно воспроизвести вовремя. Выдача пакетов приоста­навливается до его прибытия. Возникает досадная задержка в проигрывании му­
зыки или фильма. Проблему можно решить увеличением задержки начала выда­чи пакетов, но для этого потребуется буфер большей емкости. Все коммерческие веб-сайты, на которых содержится потоковое видео или аудио, используют про­игрыватели, которые начинают воспроизведение только после примерно десяти- секундной буферизации.