Взаимосвязь сети доставки контента - 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.
Пример сквозной доставки контента с использованием CDNI.

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

Сценарии использования

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

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

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

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

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

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

Кроме того, взаимосвязанные сети могут позволить кочевым конечным пользователям получать доступ к контенту с постоянным 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) (см. Статус стандартизации раздел) [1][2] определяет пять интерфейсов, необходимых для соединения пары CDN с технической точки зрения, как показано на рисунке 2. Интерфейсы представляют собой интерфейсы уровня управления, работающие на уровне приложений, которые направлены на повторное использование или усиление существующих протоколов, например HTTP, а не определять новый. Эта модель CDNI не определяет получение контента, доставку, интерфейсы запросов и механизмы, потому что сегодня CDN уже используют для них стандартизованные протоколы, например HTTP, FTP, rsync и т. Д. Используются для получения контента. Взаимосвязь позволяет подключать несколько сетей CDN в различных топологиях, таких как линейная, сеточная или начальная топология. Важно отметить, что для развертывания CDNI необходимо установить дополнительные деловые соглашения между CSP и uCDN, а также между uCDN и dCDN. На момент написания подробные операции интерфейсов и структура обмениваемых объектов находятся в процессе стандартизации.[2][3][4][5][6][7][8] Определенные интерфейсы кратко описаны ниже.

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

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

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

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

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

Интерфейс рекламы посадочных мест и возможностей (FCI)

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

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

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

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

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

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

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

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

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

Перенаправление запроса контента в 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.
Пример итеративного 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) [11] особенно реализовано. Большие объекты разбиваются на последовательность небольших независимых фрагментов, например видео, которые воспринимаются, как если бы между фрагментами не было никакой связи. В результате получение контента и очистка фрагментов выполняются для каждого фрагмента. Чтобы уменьшить нагрузку на CDNI, спецификации либо разрешают относительные унифицированные указатели ресурсов (URL), либо изменяют абсолютные URL-адреса в файле манифеста ресурса, распространяемого через HAS.

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

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

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

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

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

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

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

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

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

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

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

Рекомендации

  1. ^ а б Дж. Бертран, Э. Стефан, Т. Бербридж, П. Эрдли, К. Ма и Дж. Уотсон. Примеры использования для подключения к сети доставки контента. RFC 6770 (Информационное), ноябрь 2012 г.
  2. ^ а б Л. Петерсон и Б. Дэви. Платформа для взаимодействия CDN. draft-ietf-cdni-framework-06 (Активный Интернет-проект), октябрь 2013 г.
  3. ^ Б. Нивен-Дженкинс, Ф. Ле Фошер и Н. Битар. Постановка проблемы подключения к сети распространения контента (CDNI). RFC 6707 (Информационное), сентябрь 2012 г.
  4. ^ Ф. Ле Фоше, Ж. Бертран, И. Опреску, Р. Петеркофский. Интерфейс регистрации CDNI. draft-ietf-cdni-logging-08 (Активный Интернет-проект), октябрь 2013 г.
  5. ^ К. Люнг и Ю. Ли. Требования к сетевому соединению распространения контента (CDNI). draft-ietf-cdni-requirements-11 (активный интернет-проект), октябрь 2013 г.
  6. ^ Р. Мюррей и Б. Нивен-Дженкинс. Интерфейс управления CDNI / триггеры. draft-ietf-cdni-control-triggers-01 (активный интернет-проект), октябрь 2013 г.
  7. ^ Б. Нивен-Дженкинс, Р. Мюррей, Г. Уотсон, М. Колфилд, К. Люнг и К. Ма. Метаданные межсоединения CDN. draft-ietf-cdni-metadata-03 (Активный Интернет-проект), октябрь 2013 г.
  8. ^ Данхуа. Ван, Б. Нивен-Дженкинс, Сяоянь. Он, Чен. Ге и Вэй. Ni. Интерфейс перенаправления запросов для подключения к сети CDN. draft-ietf-cdni-redirection-01 (Активный Интернет-проект), октябрь 2013 г.
  9. ^ Дж. Зеедорф, Дж. Петерсон, С. Превиди, Р. ван Бранденбург и К. Ма. Маршрутизация запросов CDNI: семантика следа и возможностей. draft-ietf-cdni-footprint-sizes-semantics-01 (Активный Интернет-проект), октябрь 2013 г.
  10. ^ Э. Стефан и С. Эллуз. Сессия ALTO для соединения CDN. draft-stephan-cdni-alto-session-ext-04 (Активный Интернет-проект), октябрь 2013 г.
  11. ^ Р. ван Бранденбург, О. ван Девентер, Ф. Ле Фошер и К. Леунг. Модели для HTTP-адаптивного сетевого взаимодействия с потоковой передачей контента (CDNI). RFC 6983 (Информационное), июль 2013 г.
  12. ^ Распространение медиа-контента (MCD); CDN Interconnection, варианты использования и требования. Технический отчет, ETSI, 2012. TS 102 990.
  13. ^ Архитектура взаимодействия CDN. Технический отчет, ETSI, 2013. TS 182 032.
  14. ^ D3.1 Функциональная архитектура OCEAN и спецификация открытого интерфейса. Технический отчет, ОКЕАН, 2012.
  15. ^ Результат D2.2. Окончательные требования для сетей с открытым контентом. Технический отчет, ОКЕАН, 2013.
  16. ^ Спецификация сценария использования соединения CDN и требования высокого уровня. Технический отчет, ATIS, 2011. ATIS-0200003.
  17. ^ Сценарии использования соединения CDN и требования для многоадресного распределения контента. Технический отчет, ATIS, 2012. ATIS-0200004.
  18. ^ Сценарии использования и требования для подключения к сети CDN в среде многосторонней федерации. Технический отчет, ATIS, 2012. ATIS-0200010.

внешняя ссылка