Соединение сетей доставки контента

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

Обоснование

Благодаря многочисленным преимуществам CDN, например снижению стоимости доставки, улучшенному качеству взаимодействия (QoE) и повышенной надежности доставки, CDN стали популярными для крупномасштабной доставки кэшируемого контента. По этой причине провайдеры CDN расширяют свою инфраструктуру, и многие интернет-провайдеры (ISP)/провайдеры сетевых услуг (NSP) развернули или развертывают свои собственные CDN для собственного использования или для аренды, если между ними существует коммерческое и техническое соглашение. и провайдер CDN. Эти автономные CDN с четко определенными системами маршрутизации, доставки, сбора, учета и протоколами запросов могут рано или поздно столкнуться с ограничениями по занимаемому объему, ресурсам или возможностям. CDNI нацелен на использование отдельных CDN для обеспечения сквозной доставки контента от CSP конечным пользователям, независимо от их местоположения или сети подключения.

Пример работы

Давайте рассмотрим соединение двух CDN, как показано на рисунке ниже. Интернет-провайдер-A развертывает авторитетную восходящей CDN (uCDN) и заключил техническое и деловое соглашение с CSP. Поскольку CDN-A имеет право обслуживать от имени CSP, пользователь в сети ISP-B запрашивает контент у CDN-A (1). uCDN может либо обслуживать запрос сам, либо перенаправлять его в нисходящую CDN (dCDN), если, например, dCDN находится ближе к пользовательскому оборудованию (UE). Если запрос перенаправляется, взаимосвязанные сети CDN должны предоставить запрошенный контент в dCDN. Если контент недоступен в uCDN, его можно сначала получить от CSP (2), а затем отправить суррогатному поставщику в dCDN (3). UE после перенаправления запросит контент у dCDN (4), и, наконец, запрошенный контент будет распространен от суррогата.

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

В этом примере все четыре стороны могут получить выгоду от межсоединения: конечные пользователи могут получить выгоду от лучшего качества обслуживания (QoS); CSP получает выгоду, поскольку ему нужно заключить только одно деловое и техническое соглашение с uCDN; преимущества uCDN заключаются в том, что ей не нужно развертывать такую ​​обширную сеть CDN; и dCDN получит некоторую компенсацию за доставку. Процедуры и алгоритмы, отвечающие за выбор правильного dCDN, выбор суррогата и процедуру получения контента, передаваемого суррогату, могут различаться, но dCDN обслуживает контент от имени uCDN.

Варианты использования

Ниже приведен неполный список вариантов использования, для которых был представлен CDNI. Варианты использования, по-видимому, совпадают между подходами к стандартизации (см. раздел «Состояние стандартизации» ).

Расширение посадочного места

Footprint определяется как регион, для которого CDN может доставлять контент. Благодаря развернутому CDNI неглобальные провайдеры CDN могут предложить CSP расширенное географическое присутствие без

• ухудшение качества доставки;
• дополнительные затраты на транзит, если контент будет доставляться от географически или топологически удаленных суррогатов; и
• развертывание и эксплуатация суррогатов, не оправданных в соответствующем регионе, например, высокие инвестиционные затраты и низкий объем поставок.

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

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

Кроме того, взаимосвязанные сети могут позволить кочующим конечным пользователям получать доступ к контенту с одинаковым качеством QoE на различных устройствах и/или географических регионах.

Разгрузка

CDNI может быть очень полезен при обработке перегрузок, поскольку он позволяет распределять неожиданные всплески трафика, например, мгновенное скопление трафика, превышающее пиковые значения, для которых была рассчитана CDN, между uCDN и dCDN. Если CDN будут совместно использовать свои ресурсы, они могут получить выгоду от измерения экономии. Чтобы такой механизм работал правильно, uCDN требует от dCDN в режиме реального времени информации об объеме трафика, который он может выгрузить. Тогда как для запланированных событий, таких как техническое обслуживание или распространение специальных событий, статического резервирования ресурсов может быть достаточно.

Кроме того, CDNI обеспечивает средства устойчивости к ошибкам доставки и получения контента. Его развертывание в случаях, когда суррогатные и исходные серверы CSP недоступны, позволяет перенаправлять запросы на доставку на другой CDN. Аналогичным образом, при развернутом CDNI, если источник получения данных по умолчанию выходит из строя, можно использовать другие источники внутри межсоединения, например, альтернативный uCDN. Это, в свою очередь, обеспечивает балансировку нагрузки между источниками получения контента.

Возможность

CDNI может быть средством расширения диапазона поддерживаемых устройств и сетевых технологий, если CDN не может их поддерживать или если его провайдер не желает их предоставлять. Например, поставщик CDN может захотеть расширить свой портфель услуг адаптивной потоковой передачей HTTP и/или IPv6, поддерживая при этом только потоковую передачу HTTP и/или IPv4. Это расширение можно реализовать путем подключения к CDN, которая может предоставлять запрошенные протоколы. Аналогично, межсоединение может позволить провайдеру CDN фиксированной связи распространить свои услуги на мобильные устройства.

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

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

Интерфейсы в CDNI

Инженерная группа Интернета (IETF) (см. раздел «Состояние стандартизации» ) определяет пять интерфейсов, необходимых для соединения пары CDN с технической точки зрения, как показано на рисунке 2. Интерфейсы представляют собой интерфейсы плоскости управления, работающие на уровне приложений, которые направлены на повторное использование или усиление существующих протоколов, например HTTP, а не на определение нового один. Эта модель CDNI не определяет получение, доставку, интерфейсы и механизмы запроса, поскольку сегодня CDN уже используют для них стандартизированные протоколы, например HTTP, FTP, rsync и т. д. используются для получения контента. Межсоединение позволяет соединить несколько CDN в различных топологиях, таких как линейная, ячеистая или начальная топология. Важно отметить, что для развертывания CDNI необходимо установить дополнительные деловые соглашения между CSP и uCDN, а также между uCDN и dCDN. На момент написания этой статьи подробные операции интерфейсов и структура обмениваемых объектов находятся в процессе стандартизации. Определенные интерфейсы кратко описаны следующим образом.

Модель CDNI, определенная IETF.

Интерфейс управления (CI)

CI предназначен для инициирования соединения между двумя CDN и начальной загрузки других интерфейсов CDNI. Например, интерфейс управления может использоваться для предоставления адреса сервера регистрации для начальной загрузки интерфейса регистрации или для установления ассоциаций безопасности для других интерфейсов. Это также может позволить uCDN предварительно размещать, повторно проверять или очищать метаданные и контент в dCDN.

Интерфейс перенаправления маршрутизации запросов (RI)

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

Интерфейс объявления площади и возможностей (FCI)

Обеспечивает асинхронный обмен маршрутной информацией о возможностях и площади для поддержки выбора dCDN для последующих запросов пользователей. Объединение интерфейсов RI и FCI обозначает интерфейс запроса.

Интерфейс метаданных (МИ)

Позволяет dCDN предоставлять метаданные контента из uCDN. Метаданные могут включать информацию о необходимой авторизации, геоблокировке, окнах доступности и белых и черных списках делегирования. Эта информация может, например, ограничить распространение определенной страной или сделать контент, предназначенный для взрослых, доступным только в ночные часы. Собранные метаданные используются позже для перенаправления CDNI и ответов на запросы пользовательского контента.

Интерфейс регистрации (LI)

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

Критерии выбора нисходящей CDN

Для выбора dCDN в основном используется информация о его площади и возможностях. Зона обслуживания может быть указана с использованием IP-подсетей, номеров автономных систем (AS) или комбинаций страны, штата и кода. Возможности описывают функции, услуги и состояния, которым CDN может или не может соответствовать, и включают в себя сетевые и административные возможности, информацию о кэшах и ресурсах. Сетевая информация может раскрывать подробности о QoS или поддерживаемой полосе пропускания потоковой передачи. Административные возможности могут предоставлять информацию об установленных ограничениях и политиках. Данные о кэшах могут информировать о загрузке и доступных ресурсах. Информация о ресурсе может указывать поддерживаемые технологии доставки и типы контента, такие как возможность потоковой передачи видео на устройство определенного типа.

Учитывая информацию о занимаемой площади и возможностях, uCDN может перейти к первоначальному выбору dCDN — сначала на основе занимаемой площади, а затем на основе возможностей. Однако такие процедуры могут привести к неоптимальным или неправильным решениям; например, когда dCDN выбирается на основе занимаемой площади, он не может обеспечить запрошенную технологию доставки. Поэтому более одобренная процедура предполагает включение информации о посадочном месте в требования к возможностям.

Рассматриваются различные протоколы для обмена информацией либо о зоне действия, например BGP, либо о возможностях, например HTTP, либо как о зоне действия, так и о возможностях, например, оптимизации трафика прикладного уровня (ALTO).

Перенаправление запроса контента в CDN

Для перенаправления пользовательских запросов в CDN используются, среди прочего, два механизма: в основном перенаправление HTTP и DNS.

Метод HTTP использует ответ перенаправления HTTP, например 302, содержащий новый URL-адрес для посещения. Помимо возможности изменения имени сервера в новом URL-адресе, URL-адрес может содержать имя исходного сервера, что обеспечивает возможность внутриполосной связи. Более того, механизм перенаправления может использовать информацию об IP-адресе клиента, запрошенном типе контента или пользовательском агенте для выбора целевого суррогата. К сожалению, изменение домена URL-адреса приведет к тому, что веб-браузеры не будут отправлять файлы cookie.

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

Оба метода перенаправления, основанные на HTTP и DNS, могут выполняться в CDNI как итеративно, так и рекурсивно. Рекурсивное перенаправление более прозрачно для конечного пользователя, поскольку оно включает в себя только одно перенаправление UE, но имеет и другие зависимости от реализации межсоединения. Одно перенаправление UE может быть предпочтительнее, если количество взаимосвязанных CDN превышает два.

Пример работы интерфейсов CDNI при доставке контента

Диаграмма последовательности, представленная на рисунке ниже, предоставляет некоторые подробности о CDNI и операции итеративного перенаправления DNS. В изображенном примере UE загружает контент с адреса cdn.csp.com/foo , который в основном доставляется CDN-A от имени CSP с адресом csp.com .

Пример итеративного DNS-перенаправления запроса контента в CDNI.

1. Перед любым перенаправлением запроса CDN-B (dCDN) объявляет информацию о поддерживаемом пространстве и возможностях.
2. UE выполняет поиск DNS для сервера. cdn.csp.com в домене CSP, из которого будет загружаться контент.
3. Маршрутизатор запросов в CDN-A (uCDN), обслуживающий домен. cdn.csp.com обрабатывает запрос и на основе IP-адреса источника запроса распознает, что dCDN может лучше обслуживать конечного пользователя. Поэтому он выполняет запрос в dCDN, чтобы определить, готов ли он и способен ли он обслужить этот запрос.
4. Если dCDN может обработать запрос, маршрутизатор запросов в uCDN возвращает ответ DNS CNAME. Этот ответ содержит новый домен, например b.cdn.csp.com , указывающий dCDN и исходный домен, а также запись NS, которая сопоставляет этот новый домен с маршрутизатором запросов в dCDN.
5. UE выполняет поиск DNS, используя новый домен ( b.cdn.csp.com ). Маршрутизатор запросов в dCDN отвечает на этот запрос IP-адресом подходящего узла доставки.
6. UE запрашивает контент /foo с узла доставки в dCDN. В этот момент узел доставки получает реальный IP-адрес UE и информацию о запрошенном контенте. Если перенаправления на предыдущих шагах были неправильными, узел доставки мог выполнить перенаправление HTTP.
7. Если метаданные контента /foo недоступен в dCDN, для запроса его из uCDN используется интерфейс метаданных.
8. Если запрос будет обслужен, т. е. были соблюдены ограничения метаданных и произошел промах в кэше, узел доставки в dCDN должен начать процесс получения. Узел доставки выполняет DNS-поиск внутреннего адреса домена. op-b-acq.op-a.net . uCDN распознает, что запрос исходит от dCDN, а не от UE, и возвращает IP-адрес узла доставки в uCDN.
9. Содержание /foo доставляется на узел доставки в dCDN из узла доставки в uCDN.
10. Содержание /foo доставляется в UE из узла доставки в dCDN.
11. Через некоторое время uCDN может дать указание dCDN очистить контент. /foo , чтобы гарантировать, что он не будет доставлен снова.
12. После доставки контента в uCDN предоставляется журнал действий по доставке.

Адаптивная потоковая передача HTTP

Если это указано в спецификациях CDNI, поддержка адаптивной потоковой передачи HTTP (HAS). особенно осознается. Большие объекты разбиваются на последовательность небольших независимых фрагментов (например, видео), которые воспринимаются так, как будто между фрагментами нет никакой связи. В результате получение контента и очистка фрагментов выполняются для каждого фрагмента. Чтобы уменьшить нагрузку CDNI, спецификации либо допускают относительные унифицированные указатели ресурсов (URL), либо изменяют абсолютные URL-адреса в файле манифеста ресурса, распространяемого через HAS.

Безопасность

Безопасность CDNI не является обязательной, и ее поддержка представлена ​​как возможность CDN. Безопасность CDNI включает защиту конфиденциальности контента, обмен данными между аутентифицированными узлами и аутентификацию источника данных . Аутентификация источника данных имеет большое значение, если доверие к каналу между CDN подвергается сомнению. Безопасность обеспечивается путем переключения на безопасные версии протоколов, развернутых в CDNI, например HTTPS. Обычно, если CDNI устанавливается с помощью безопасных протоколов, безопасные протоколы также используются для получения и распространения контента.

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

Статус стандартизации

Ряд организаций и проектов, например, IETF, Европейский институт телекоммуникационных стандартов (ETSI), Альянс решений для телекоммуникационной отрасли (ATIS) и Open Content Aware Networks (OCEAN), работали или работают над стандартизацией интерфейсов и методов CDNI. Существуют некоторые несоответствия и различия между спецификациями определенных интерфейсов, а также в терминологии.

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

Структура OCEAN исчерпывающе определяет открытые интерфейсы и процессы предлагаемого CDNI. Документы определяют дополнительные интерфейсы бизнеса, сбора данных и внутренних метаданных. Кроме того, интерфейс метаданных, определенный ETSI, разделен на еще два специализированных интерфейса, которые вместе образуют эталонную модель с девятью интерфейсами.

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

См. также

• Сеть доставки контента
• Соединение
• Федерация (информационные технологии)
• Балансировка нагрузки (вычисления)
• Код страны
• перенаправление URL-адресов
• CNAME-запись
• Динамическая адаптивная потоковая передача через HTTP

Дальнейшее чтение

• С. Пуополо, М. Латуш, Ф. Ле Фошёр и Ж. Дефур. Федерации сетей доставки контента (CDN) Как поставщики услуг могут выиграть битву за потребителей, жаждущих контента, 2011 г.
• А. Патан и Р. Буйя. Таксономия и обзор сетей доставки контента. Технический отчет, GRIDS-TR-2007-4, Лаборатория грид-вычислений и распределенных систем, Мельбурнский университет, Австралия, февраль 2007 г.

Внешние ссылки

• Соединение сетей доставки контента (cdni)
• OpenCDN | Федерация CDN | EdgeCast
• SwiftServe — технология прозрачного кэширования и сети доставки контента (CDN)
• Мульти-CDN-федерация | Cedexis — данные в реальном времени для принятия решений в реальном времени. Архивировано 22 сентября 2017 г. на Wayback Machine.
• Блог о стратегии CDN, новости CDN, новости отрасли CDN, стратегии сетей доставки контента. Архивировано 28 октября 2013 г. на Wayback Machine.
• Что такое Multi-CDN и как он работает?