Взаимосвязь сети доставки контента - Content delivery network interconnection

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

Обоснование

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

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

Давайте рассмотрим соединение двух CDN, как показано на рисунке ниже. ISP-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 предложит улучшенное QoS и QoE для конечных пользователей, уменьшит и позволит контролировать входящий трафик в сети интернет-провайдера, уменьшит емкость оборудования и площадь uCDN и позволит интернет-провайдеру получить некоторую прибыль.

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

Разгрузить

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

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

Возможность

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

Когда поставщик CDN запускает множество сетей с различными технологиями, использует стратегию с несколькими поставщиками или развертывает отдельные сети для многих поставщиков услуг связи, соединение может упростить его технологию создания и взаимодействие поставщиков за счет упрощения или автоматизации некоторых операций между 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 обозначает интерфейс запроса.

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

Позволяет 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, устанавливается соответствующее значение параметра time-to-live. Недостатком этого метода является то, что кеши DNS скрывают IP-адрес конечного пользователя.

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

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

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

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

Перед перенаправлением любого запроса CDN-B (dCDN) объявляет информацию о поддерживаемых местах и возможностях.
UE выполняет поиск DNS для сервера cdn.csp.com в домене CSP, с которого оно собирается загружать контент.
Маршрутизатор запросов в CDN-A (uCDN), обслуживающий домен cdn.csp.com, обрабатывает запрос и распознает, основываясь на исходном IP-адресе запроса, что конечный пользователь может лучше обслуживаться с помощью dCDN. Следовательно, он выполняет запрос в dCDN, чтобы определить, желает ли и может ли он обслужить этот запрос.
Если dCDN может обработать запрос, маршрутизатор запросов в uCDN возвращает ответ DNS CNAME. Этот ответ содержит новый домен, например b.cdn.csp.com , с указанием dCDN и исходный домен, а также запись NS, которая сопоставляет этот новый домен с маршрутизатором запросов в dCDN.
UE выполняет поиск в DNS, используя новый домен ( b.cdn.csp.com ). Маршрутизатор запросов в dCDN отвечает на этот запрос IP-адресом подходящего узла доставки.
UE запрашивает контент / foo у узла доставки в dCDN. В этот момент узел доставки получает реальный IP-адрес UE и информацию о запрошенном контенте. Если перенаправления на предыдущих шагах были неправильными, узел доставки мог выполнить перенаправление HTTP.
Если метаданные для content / foo недоступны в dCDN, интерфейс метаданных используется для запроса их из uCDN.
Если запрос будет обслуживаться, т. Е. Были соблюдены ограничения метаданных и произошел сбой в кэше, узел доставки в dCDN должен начать процесс получения. Узел доставки выполняет поиск в DNS для адреса внутреннего домена op-b-acq.op-a.net . UCDN распознает, что запрос исходит от dCDN, а не от UE, и возвращает IP-адрес узла доставки в uCDN.
Content / foo доставляется в узел доставки в dCDN из узла доставки в uCDN.
Content / foo доставляется в UE из узла доставки в dCDN.
Через некоторое время uCDN может дать команду dCDN очистить содержимое / foo, чтобы гарантировать, что он не будет доставлен снова.
После доставки контента в 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. .

Смотрите также

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

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

Languages

In other projects