Несколько лет назад, когда коммутирующие маршрутизаторы только входили в моду, любые разговоры о коммутации на четвертом — седьмом уровнях эталонной модели OSI воспринимались не иначе как очередной маркетинговый трюк. Но время все расставило по своим местам. Сегодня коммутация L7 реализована в продукции ряда крупнейших компаний, а использующие ее сети доставки контента (Content Delivery Network, CDN) приобрели огромную популярность. Правда, пока только на Западе.

Так выглядит старшая модель высокоуровневого коммутатора ServerIron 800 производства Foundry Networks
Своим возникновением эти сети обязаны успешному развитию сразу нескольких технологий, и высокоуровневая коммутация стала лишь одним из слагаемых успеха. Не меньшее значение имели разработки в области кэширования данных и выравнивания нагрузки (load balancing) между Web-серверами, активное проникновение мультимедиа-приложений в сетевую среду, естественное стремление поставщиков контента повысить степень интерактивности Web-сайтов и одновременно выйти на более широкую аудиторию, наконец, необходимость улучшить качество предоставляемых услуг.

Более того, появление трафика, чувствительного к задержкам передачи, со всей очевидностью показало, что простого увеличения пропускной способности магистральных каналов недостаточно для соответствия требованиям оперативности получения информации, предъявляемым абонентами. В последнее время в литературе появился даже специальный термин, отражающий степень удовлетворенности пользователей качеством сетевых услуг, — Quality of Experience (QoE). Надо ли объяснять, что для среднестатистического пользователя QoE определяется скоростью получения запрошенного контента.

В действительности, конечно, все не так однозначно, и задержки при приеме или отправке почты либо «скачивании» файлов из Internet остаются практически незамеченными, тогда как медленная загрузка Web-страниц или неравномерности при воспроизведении потокового видео выведут из себя кого угодно. Собственно, на дифференциацию трафика по типам приложений и были нацелены разработки в области высокоуровневой коммутации.

Вверх по коммутационной лестнице

Напомним, что коммутация третьего уровня (Layer 3 Switching) представляет собой особый вид маршрутизации данных между IP-подсетями. Маршрут вычисляется лишь для первого пакета из входного потока, а все последующие пакеты этого потока передаются по уже выбранному пути. Ускорение передачи (по сравнению с использованием традиционных, то есть программных маршрутизаторов) оказывается весьма значительным, однако платой за него становится потеря гибкости и интеллектуальности, присущих традиционным маршрутизаторам. (Компромиссный вариант обеспечили специализированные микросхемы, реализующие функции маршрутизации на аппаратном уровне.)

Коммутация, четвертого уровня, строго говоря, коммутацией уже не является, поскольку она не использует ни MAC-, ни IP-адрес узла-получателя. Фактически речь идет об анализе заголовков пакетов TCP или UDP с целью определения номеров портов, соотносящих отправляемые пакеты с протоколами прикладного уровня (HTTP, SMTP, FTP и т. д.). Это позволяет (исходя из номера порта, а значит и типа приложения) выработать особые правила дальнейшей транспортировки потока данных, прежде всего — присвоить ему тот или иной приоритет (уровень QoS). Физически же путь передачи потоков с разными приоритетами зачастую бывает одним и тем же. Применение коммутации четвертого уровня дает возможность настраивать конфигурацию сети с учетом потребностей запускаемых в ней приложений, а также собирать детальные статистические сведения о проблемах функционирования сети. Эта идея давно реализована на практике: устройства с поддержкой коммутации L4 уже несколько лет выпускаются компаниями 3Com, Cisco, Enterasys, Lucent, Nortel и др.

Коммутация следующих уровней базируется на тех же принципах: после анализа заголовков соответствующих протоколов принимается решение об особенностях обработки трафика. Вот почему сегодня нередко можно встретить обобщенный термин — коммутация уровней 4-7 модели OSI.

От балансировки — к доставке

Задача распределения нагрузки между Web-серверами поначалу решалась с применением простейшего алгоритма циклической Web-коммутации: первый запрос направлялся на первый сервер, второй — на второй и т. д. Позднее была введена более совершенная схема: проанализировав заголовок пакета, Web-сервер определял, какое устройство должно обслужить поступивший запрос. Следующий шаг напрашивался сам собой. С Web-сервера, выполняющего множество разнообразных задач, стоило снять ответственность за первичный анализ запросов. Так возникла новая категория сетевых устройств — средства выравнивания нагрузки.

Задача выравнивания нагрузки в условиях постоянного роста интенсивности трафика сыграла свою роль и при разработке коммутаторов L7. Во второй половине 90-х годов соответствующие продукты, называемые также коммутаторами контента, выпустили сразу несколько фирм — Alteon WebSystems (модели Alteon 180 и ACEdirector, сегодня принадлежащие корпорации Nortel Networks), ArrowPoint Communications (вошла в состав Cisco Systems; линия CSS 11000), F5 Networks (серия BIG-IP) и Foundry Networks (серия ServerIron). Позднее к ним присоединились ClickArray Networks, Extreme Networks, HydraWeb Technologies, Intel, NetScaler, Top Layer Networks. Богатый выбор присутствующих на рынке моделей позволяет сетевому администратору при решении вопроса о покупке принимать во внимание не только реализацию базовых средств задания правил коммутации, обеспечения отказоустойчивости и управления, но и наличие дополнительных функций фильтрации пакетов, перенаправления запросов в кэш, приоритизации трафика и т. д.

Коммутаторы седьмого уровня обеспечили оптимизацию загрузки ресурсов на Web-сервере контент-провайдера, однако проблема эффективной доставки запрошенной информации непосредственно на компьютер пользователя осталась за кадром. Такую доставку и призваны обеспечить сети CDN.

По кирпичикам

CDN можно рассматривать как сеть, построенную поверх инфраструктуры Internet с целью высокоскоростной доставки мультимедиа или динамического контента конечным пользователям. Выполнение этой задачи достигается благодаря согласованной работе трех функциональных компонентов:

  • сервисы переадресации запроса на кэш-сервер, способный наиболее эффективно его обслужить. В терминологии CDN такой кэш-сервер именуется сервером-заменителем (surrogate);
  • сервисы распределения копий оригинального контента по системе серверов-заменителей, расположенных на границе опорной сети (в точках присутствия Internet-провайдера, на базовых станциях беспроводной сети, на корпоративном ptoxy-сервере и т. д.). В результате их применения удается минимизировать число запросов и объемы ответных данных, передаваемых по магистральным каналам;
  • сервисы учета и биллинга, позволяющие поставщику CDN-услуг выставлять счета провайдерам контента, а также другим CDN-провайдерам, с которыми он обменивается трафиком. Необходимые для этого статистические данные собирает ПО, устанавливаемое на кэш-серверах. Эти же данные используются для управления контентом, анализа трендов в «потреблении» той или иной информации, а также для планирования мер по наращиванию ресурсов сети и серверов.
Принцип работы сети CDN

В структурном отношении сети CDN включают в себя множество компонентов (см. рисунок), которые также можно объединить в три большие группы.

Доставка контента. Компоненты этой группы отвечают за большую часть операций обработки данных — от кодирования до собственно доставки конечному пользователю. Средства сжатия потокового трафика и его разбиения на пакеты должны учитывать как тип контента, так и способ доступа пользователя во Всемирную сеть (по коммутируемой или DSL-линии, по выделенному каналу и т. д.). Следующие за этим операции защиты потокового контента выполняют так называемые системы управления цифровыми правами (Digital Rights Managemnt, DRM). Они отвечают за шифрование контента, его электронную публикацию, отслеживание прав доступа пользователей и имеющихся у них лицензий, управление ключами.

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

Обработку запросов пользователя осуществляет медиа-сервер. Так называют специальное программное обеспечение, функционирующее на сервере общего назначения под управлением Windows или Unix. В его обязанности входят сопровождение потоков реального времени, поддержка операций доставки контента, предоставляемого по запросу, тиражирование входного «живого» видеопотока на множество клиентских станций (для уменьшения сетевой нагрузки), поддержка широкого диапазона скоростей передачи (например, от 8 кбит/с до 2 Мбит/с), адаптация параметров контента к пропускной способности канала «последней мили». Доставка мультимедиа-контента по IP-сети осуществляется с использованием открытых протоколов — RTSP, RTP, MMS. Тем не менее при создании самих медиа-серверов производители обычно опираются на патентованные алгоритмы обработки данных; в результате средства кодирования, медиа-сервер и средства воспроизведения контента от разных фирм с большой вероятностью окажутся несовместимыми. В аппаратную составляющую системы доставки входят также сами Web-серверы, на которых хранятся метаданные и индексы (указатели).

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

В отличие от использования простейшей схемы Web-кэширования в сети CDN могут задействоваться кластеры или иерархии серверов-заменителей, позволяющие снизить нагрузку на магистральные каналы. Если запрошенные данные отсутствуют на кэш-сервере, последний выясняет его наличие у своих «собратьев» с помощью протокола ICP (Internet Cache Protocol); в итоге данные поступают с ближайшего кэш-сервера без обращения к исходному источнику контента.

Замыкают этот архитектурный блок клиентское ПО и средства управления контентом. Сохраняющаяся несовместимость серверных платформ различных производителей требует установки на компьютере пользователя сразу нескольких приложений для обработки и воспроизведения потокового трафика. Как правило, дело ограничивается «джентльменским набором» из трех программ — RealPlayer компании RealNetworks, QuickTime фирмы Apple и Windows Media производства Microsoft. В области методов управления наблюдается не меньший разнобой, так что, выбирая для этих целей тот или иной продукт, провайдер CDN-услуг должен прежде всего руководствоваться здравым смыслом и пожеланиями клиентов.

Маршрутизация контента. Проблема маршрутизации разбивается на две части — глобальную и локальную.

Средства глобальной маршрутизации призваны направить запрос клиента в одну из точек присутствия CDN-провайдера. Поскольку IP-адреса разных точек присутствия ставятся в соответствие одному и тому же доменному имени, глобальную маршрутизацию может выполнить сервер DNS. Такое простейшее решение имеет существенный недостаток: DNS-сервер будет распределять поступающие запросы по IP-адресам на основе простейшей циклической схемы, тогда как этому процессу не повредил бы учет загруженности отдельных серверов-заменителей.

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

Локальная маршрутизация, называемая также локальной переадресацией или интеллектуальной коммутацией, отвечает за распределение запросов между серверами в пределах одной точки доступа. Как правило, для этой цели используется коммутация уровней 4 — 7, позволяющая принять во внимание тип контента, данные о пользователе, сведения о текущей загрузке отдельных серверов в кластере, собираемые средствами протокола SNMP. Высокоуровневая коммутация может быть реализована путем установки коммутаторов или маршрутизаторов, о которых говорилось выше, либо инсталляции на сервере специального ПО.

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

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

Запускаем маховик

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

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

Новое вино в старые мехи

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

Во-вторых, модель CDN обеспечивает провайдерам услуг доступа (ISP или NSP) получение дополнительной прибыли путем предоставления подписчикам новых видов услуг, получивших название граничных сервисов (edge services). Провайдер, отвечающий за передачу трафика по «последней миле», обычно располагает наиболее детальной информацией о клиентах. Профили пользователей (механизмы их получения — предмет отдельного разговора) могут задействоваться для индивидуальной адаптации запрошенной информации. Адаптация состоит, например, в размещении на сервере-заменителе сведений о товарах, предлагаемых в местных магазинах, системах скидок, ближайших культурных мероприятиях и т. д. Эти сведения не возбраняется предлагать за небольшую плату в качестве дополнительной информационной услуги. Другими примерами граничных сервисов являются защита от хакерских атак, сканирование на наличие вирусов, перевод контента с одного языка на другой. Наконец, никто не мешает провайдеру добавить в контент, кэшируемый в точке присутствия, рекламу — опять же с учетом предпочтений отдельных пользователей.

В-третьих, в последнее время концепция CDN стала проникать на корпоративный рынок. Появление в корпоративных сетях мультимедиа-приложений, а также распространение интра- и экстрасетей (табл. 1) сделало задачу оперативного распространения контента более чем актуальной. Организация CDN в корпоративной среде дает возможность оптимизировать документооборот и повысить эффективность процессов принятия решений, наладить оперативную доставку информации в отдаленные филиалы, упростить электронное распространение ПО, вывести на новый уровень систему внутрикорпоративного обучения. По оценкам аналитиков, переход от обычных вариантов обучения на сетевой (с применением технологий CDN) позволит крупным фирмам снизить затраты на обучение на 70%, а общий выигрыш от замены традиционных коммуникаций (совещаний, встреч, переговоров) на аудио- и видеоконференции — на 60%.

Таблица 1. Примеры приложений для CDN
Тип сетиПриложения
CDN в InternetОбучение клиентов

Обслуживание заказчиков

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

Видео-FAQ.

Анонсы новых товаров и услуг
Корпоративная CDNДоведение до сотрудников распоряжений руководства

Распространение корпоративной информации

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

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

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

Техническое обучение

Web-семинары

Управление каналами поставок

Действующие лица и исполнители

Поскольку концепция CDN своим появлением прежде всего обязана разрастанию Всемирной паутины, высокоскоростная доставка Web-контента пользователям Internet на Западе сегодня развита в наибольшей степени. Услуги CDN успешно предоставляют компании Adero, Akamai Technologies, BT Ignite, Cidera, Digital Island (сегодня — в составе Cable & Wireless), ePic Realm, Globix, iBeam, InterNAP Network Services, MirrorImage Internet, Speedera Networks, st3, Yahoo!, Broadcast. Одни фирмы располагают собственной разветвленной инфраструктурой магистральных каналов и точек присутствия, поверх которой развертывается сеть CDN, другие арендуют такую инфраструктуру у крупных ISP, третьи для увеличения территориального охвата используют комбинированный подход. Примеры контента, авторы которого предпочитают прибегать к услугам CDN-провайдеров, разнообразны — от видео по запросу до материалов систем дистанционного обучения, от изображений высокого разрешения, используемых в телемедицине, до лент финансовых новостей и видеотрансляций концертов.

Тарификация CDN-услуг обычно основывается на учете используемых ресурсов. У крупных провайдеров (Akamai, Digital Island) цены могут доходить до 2 тыс. долл. за 1 Мбит/с. Многими американскими контент-провайдерами эти цифры поначалу воспринимались как непомерно высокие (особенно при их сопоставлении со стоимостью простого Web-хостинга и выхода в магистральные каналы). Операторы collocation-сервисов — вроде AboveNet Communications и Exodus Communications — берут за 1 Мбит/с всего 600 долл. Однако такое сравнение не вполне корректно, ведь традиционный хостинг к доставке контента вообще не имеет никакого отношения.

Востребованность новой бизнес-модели стимулировала выпуск разнообразных продуктов для сетей CDN. Поскольку их архитектура включает в себя множество разнообразных компонентов, на рынке образовалось несколько ниш, в каждой из которых действуют свои игроки. Как можно видеть из табл. 2, некоторые фирмы предлагают широкий спектр решений, другие сконцентрировали свое внимание на «нишевых» продуктах. Стоит отметить также, что схожесть базовых принципов построения корпоративных и глобальных сетей CDN позволяет использовать некоторые продукты в средах обоих типов, хотя во втором случае обычно требуются большие мощность и масштабируемость.

Таблица 2. Производители продуктов для CDN
Категория продуктовКомпании-производители
Коммутаторы уровней 4 - 7Cisco, ClickArray, Extreme, F5 Networks, Foundry, HydraWeb, Intel, NetScaler, Nortel, Top Layer Networks
Инструментарий для создания и персонализации контентаATG, Broadvision, Documentum, Interwoven, Open Market, Vignette, Volera
Средства кэширования контентаCacheFlow, Cisco, Digital Pipe, Inktomi, Infolibria, Network Appliance, Novell, Persistence, Ultra DNS
Устройства выравнивания нагрузки и переадресацииCisco, F5 Networks, Foundry, Inktomi, Nortel, RADware.
Средства управления системами храненияCereva, Foundry, I-Drive, Nortel, Scale Eight
Инструментарий для мониторинга и анализа трафикаKeynote, Resonate, RADview
Средства интеллектуального анализа данных для сетей CDNATG, E-Piphany

Куда кривая выведет?

По мнению аналитиков компании GartnerGroup, в 2003 году половина всех сайтов электронной коммерции в целях увеличения объемов продаж начнут распространять мультимедиа-трафик через сети CDN, а к 2006 году четыре из пяти крупнейших фирм мира, входящих в список Global 2000, будут использовать потоковые аудио и видео в корпоративных сетях. В целом же, по прогнозам HTRC Group, объем мирового рынка CDN-услуг в 2003 году достигнет 2,17 млрд долл., тогда как в прошлом году он составлял всего 97 млн долл. Рынок оборудования и программных средств для CDN за тот же период возрастет с прошлогодних 101 до 749 млн долл.

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

Актуальность проблемы была осознана примерно полтора года назад, когда с разницей в один месяц возникло два индустриальных консорциума. В них вошли первые провайдеры CDN-услуг и фирмы-производители, успевшие продать им свое оборудование. Наиболее многочисленной на сегодня является Content Alliance, созданный в августе 2000 года компаниями Cisco, Cable&Wireless, Digital Island и PSINet. В настоящее время этот консорциум объединяет более 60 компаний. Другая организация — Content Bridge Alliance — была образована при непосредственном участии Adero и Inktomi. Пока она насчитывает в своих рядах около десяти членов, правда, среди них есть такие гиганты, как Exodus и America Online. Позднее возникло и еще одно объединение — Internet Protocol Detail Record (IPDR), учредителями которого стали AT&T, Intel и Sprint.

BIG-IP Controller — коммутатор контента компании F5
Наличие нескольких организаций, ревниво оберегающих интересы своих членов, вряд ли будет способствовать скорейшему принятию единого стандарта. Тем не менее два первых консорциума уже направили в Internet Engineering Task Force (IETF) свои технические предложения. Мало того, на заседании IETF в декабре прошлого года говорилось о целесообразности создания в рамках этой организации четырех специализированных рабочих групп по сетям доставки контента. Эти группы занялись бы стандартизацией следующих функциональных областей: пиринговые отношения между провайдерами CDN-услуг; дополнительные сервисы proxy-кэшей (вроде переадресации запроса на сервер, поддерживающий иностранный язык); аналогичные дополнения к функциональности DNS-серверов; процессы тиражирования и кэширования контента в распределенной системе серверов-заменителей. К сожалению, пока эта программа остается нереализованной. В составе IETF появилось лишь одно подразделение — Content Distribution Internetworking (CDI), еще даже не получившее статуса рабочей группы. Впрочем, если верить бодрым заявлениям представителей Content Alliance, изменение статуса произойдет не сегодня-завтра. По мнению экспертов, при благоприятном стечении обстоятельств сам процесс стандартизации займет не более года.

Пока на Западе ломают копья по поводу стандартизации сетей доставки контента, Россия (по традиции — не спеша) выходит из состояния спячки. Как свидетельствует опыт последнего десятилетия, передовые технологии и новые бизнес-модели, включая различные варианты аутсорсинга, пробивают себе дорогу и на нашей земле. Взять те же услуги ASP: пока их набор сильно ограничен, но, как говорится, лиха беда начало. Рост популярности Internet и стремительное увеличение числа русскоязычных сайтов неизбежно приведут к постановке вопроса об оптимизации механизмов доставки информации по сети. Вот только когда это произойдет? С уверенностью можно сказать только одно: на разработку стандарта сетей CDN времени у IETF хоть отбавляй.

Поделитесь материалом с коллегами и друзьями