text

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

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

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

Все идеи, рассматривавшиеся до сих пор, соответствуют модели, показанной в листинге 6.1: клиент сообщает серверу имя файла, а тот в ответ возвращает файл.

В первые годы существования Всемирной паутины все ее содержимое и в самом деле было статическим (просто файлы). Однако в последние годы в Сети появля­ется все больше динамических объектов, то есть таких, которые создаются по тре­бованию, а не хранятся постоянно на диске. Автоматическое создание объектов может происходить как на стороне сервера, так и на стороне клиента. Рассмотрим оба случая по порядку.

В 1995-1997 годы проблемная группа проектирования сети Интернет (IETF) прилагала множество усилий по продвижению архитектуры потокового мульти­медиа.

В результате появилось две дюжины документов RFC, начинающихся с префикса RFC и включающих порядковые номера 2205-2210. Общее название этих трудов — потоковые алгоритмы или интегральное обслуживание. Предла­гаемая технология предназначена как для одноадресных, так и для многоадрес­ных приложений. Примером первых может быть видеоклип на сайте новостей, доставляемый в виде потока пользователю, пожелавшему посмотреть его. При­мер вторых — набор станций цифрового телевидения, осуществляющих широко­вещательное распространение своих программ в виде потоков IP-пакетов. Дан­ной услугой может пользоваться большое число абонентов, расположенных в разных географических точках. Далее мы более подробно рассмотрим многоад­ресную рассылку, поскольку однонадресная передача — это лишь особый случай многоадресной. Во многих приложениях с многоадресной маршрутизацией груп­пы пользователей могут меняться динамически. Например, люди могут подклю­чаться к участию в видеоконференциях, но со временем это занятие им надоеда­ет, и они переключаются на мыльные оперы или спортивные каналы. В данном случае стратегия предварительного резервирования пропускной способности не совсем подходит, потому что при этом каждому источнику пришлось бы запоми­нать все изменения в составе аудитории. В системах, предназначенных для пере­дачи телевизионного сигнала миллионам абонентов, такой подход и вовсе не го­дится.

Итак, мы узнали кое-что о требованиях, входящих в понятие «качество обслужи­вания». Как же заставить систему удовлетворять этим требованиям? Во-первых, необходимо учесть, что не существует никакой волшебной палочки. Ни один метод не обеспечивает безусловно высокое качество обслуживания. Напротив, разрабо­тано большое количество методов, практические реализации которых зачастую ис­пользуют смешанные технологии. Далее мы рассмотрим некоторые методы, при­меняемые разработчиками систем для повышения качества обслуживания.

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

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

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

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

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

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

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

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

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

В очень больших сетях двухуровневой иерархии может оказаться недостаточ­но. Может потребоваться группировать регионы в кластеры, кластеры в зоны, зоны в группы, и т. д., пока у нас не иссякнет фантазия на названия для новых образований. В качестве примера многоуровневой иерархии рассмотрим марш­рутизацию пакета, пересылаемого из университета Беркли (Berkeley), штат Ка­лифорния, в Малинди (Malindi) в Кении. Маршрутизатор в Беркли знает детали топологии в пределах Калифорнии, но трафик, направляющийся за пределы шта­та, он посылает маршрутизатору в Лос-Анджелесе. Маршрутизатор в Лос-Анд­желесе может выбрать маршрут для трафика в пределах США, но все пакеты, на­правляемые за рубеж, переправляет в Нью-Йорк. Нью-йоркский маршрутизатор направит трафик на маршрутизатор страны назначения, ответственный за прием
трафика из-за границы. Он может располагаться, например, в Найроби. Нако­нец, направляясь вниз по дереву иерархии уже в пределах Кении, пакет попадет в Малинди.

На рис. 5.13 приведен количественный пример маршрутизации в двухуровне­вой иерархии с пятью регионами. Полная таблица маршрутизатора 1А, как пока­зано на рис. 5.13, б, состоит из 17 записей. При использовании иерархической маршрутизации, как показано на рис. 5.13, в, таблица, как и прежде, содержит сведения обо всех локальных маршрутизаторах, но записи обо всех остальных регионах концентрируются в пределах одного маршрутизатора, поэтому трафик во второй регион по-прежнему пойдет по линии 1В — 2А, а во все остальные ре­гионы — по линии 1С — ЗВ. При иерархической маршрутизации размер таблицы маршрутов уменьшается с 17 до 7 строк. Чем крупнее выбираются регионы, тем больше экономится места в таблице.

К сожалению, этот выигрыш памяти не достается бесплатно. Платой за умень­шение размеров таблицы маршрутов является увеличение длины пути. Напри- Мер, наилучший маршрут от 1А до 5С проходит через регион 2, однако при ис­пользовании иерархической маршрутизации весь трафик в регион 5 направляет­ся через регион 3, поскольку так лучше для большинства адресатов в регионе 5.

Когда единая сеть становится очень большой, возникает интересный вопрос: сколько уровней должна иметь иерархия? Для примера рассмотрим подсеть с 720 маршрутизаторами. Если иерархии нет, то каждому маршрутизатору необхо-

димо поддерживать таблицу из 720 строк. Если подсеть разбить на 24 региона по 30 маршрутизаторов в каждом регионе, тогда каждому маршрутизатору потребу­ется 30 локальных записей плюс 23 записи об удаленных регионах, итого 53 за­писи. При выборе трехуровневой иерархии, состоящей из 8 кластеров по 9 ре­гионов из 10 маршрутизаторов, каждому маршрутизатору понадобится 10 строк в таблице для локальных маршрутизаторов, 8 строк для маршрутизации в дру­гие регионы в пределах своего кластера, плюс 7 строк для удаленных кластеров, итого 25 строк. Камоун (Kamoun) и Кляйнрок (Kleinrock) в 1979 году показа­ли, что оптимальное количество уровней иерархии для подсети, состоящей из N маршрутизаторов, равно In N. При этом потребуется е In Дозаписей для каждо­го маршрутизатора. Они также показали, что увеличение длины эффективного среднего пути, вызываемое иерархической маршрутизацией, довольно мало и обычно является приемлемым.

Маршрутизация на основе векторов расстояний использовалась в сети ARPANET вплоть до 1979 года, когда ее сменил алгоритм маршрутизации с учетом состоя­ния линий. Отказаться от прежнего алгоритма пришлось по двум причинам. Во- первых, старый алгоритм при выборе пути не учитывал пропускную способность линий. Пока все линии имели пропускную способность 56 Кбит/с, в учете пропу­скной способности не было необходимости. Однако стали появляться линии со скоростью 230 Кбит/с, а затем и 1,544 Мбит/с, и не принимать во внимание про­пускную способность стало невозможно. Конечно, можно было ввести пропуск­ную способность в качестве множителя для единицы измерения, но имелась еще и другая проблема, заключавшаяся в том, что алгоритм слишком долго приходил к устойчивому состоянию (проблема счета до бесконечности). Поэтому он был заменен полностью новым алгоритмом, который сейчас называется маршрутиза­цией с учетом состояния линий. Варианты этого алгоритма широко применяют­ся в наши дни.

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

1. Обнаруживать своих соседей и узнавать их сетевые адреса.
2. Измерять задержку или стоимость связи с каждым из своих соседей.
3. Создавать пакет, содержащий всю собранную информацию.
4. Посылать этот пакет всем маршрутизаторам.
5. Вычислять кратчайший путь ко всем маршрутизаторам.

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

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

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

В результате при использовании метода формирования трафика клиент сооб­щает оператору связи: «Мой график передачи будет выглядеть следующим об­разом. Сможете ли вы это обеспечить?». Если оператор связи соглашается, то возникает вопрос о том, как оператор связи будет сообщать клиенту, что тот со­блюдает соглашение, и что делать, если клиент нарушит договор. Наблюдение за потоком трафика называется политикой трафика. Договориться о форме трафи­ка и регулировать его впоследствии легче в подсетях с виртуальными каналами, чем в дейтаграммных подсетях. Тем не менее даже в дейтаграммных подсетях можно применить те же идеи к соединениям транспортного уровня.