Взаимодействие сетей доставки контента

Андрей Робачевский

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

Ценность данных или контента сегодня во многом определяется качеством доступа – насколько быстро загружается страница веб-сайта, насколько бесперебойно можно смотреть потоковое видео, насколько быстро реагируют интерактивные приложения. Во многом – это ощущения пользователя. Быстрый сайт с хорошей реакцией подспудно является признаком качества предлагаемого материала, включая рекламу. И именно последняя играет существенную роль в желании провайдеров контента минимизировать задержки при доставке данных – если пользователь не может комфортно взаимодействовать с сайтом или рекламные вставки загружаются слишком долго, это ведет к реальным финансовым потерям.
По мере роста пропускной способности каналов и производительности серверов, казалось бы, эта цель будет достигнута естественным образом. Но, как мы знаем, Интернет по-прежнему не предоставляет никаких гарантий качества. Если пакет окажется утерян вследствие перегрузки какого-либо участка сети или доставлен с опозданием, вне изначального порядка, например, вследствие недоступности основного маршрута, задача приложений – обработать такие нерегулярности соответствующим образом. Пропускная полоса коммуникационного канала между приложениями также не гарантирована и заранее не известна. Она определяется множеством факторов, начиная от пропускной способности отдельных сегментов сетей, через которые передается трафик между приложениями, и заканчивая загрузкой самих сетей.
Поэтому для одного пользователя портал онлайн-магазина может загрузиться за 2 секунды, а для другого занять минуты, видео-ролик вдруг внезапно замирает, пусть и на секунды, а повторяющиеся операции могут значительно различаться по времени.
Перефразируя известную поговорку, если пользователь не может забрать необходимый контент, контент должен быть доставлен пользователю! Так появилась идея сетей доставки контента – CDN (Content Delivery Networks) – наложенных сетей или еще одного приложения Интернета.
Эффективность CDN во многом определяется тем, насколько близко точки ее присутствия находятся к потребителю контента. Поэтому многие крупные CDN насчитывают десятки тысяч граничных серверов с глобальным покрытием. Например, на август 2016 года CDN компании Akamai насчитывала более 216 000 серверов, расположенных в 120 странах и работающих внутри более чем 1500 сетей. Но даже такая впечатляющая сеть не может покрыть весь Интернет. В то же время зоны покрытия существующих CDN имеют значительные перекрывающиеся области. Наконец, относительно небольшие CDN, чаще всего развернутые в рамках провайдера интернет-доступа или корпоративной сети, не могут достичь высокой эффективности в силу ограниченного покрытия.
Поэтому возможность взаимодействия между CDN, возможность создания федераций открывают перспективное направление их развития в сторону увеличения охвата и уменьшения стоимости. Рабочая группа IETF CDNI (Content Delivery Networks Interconnection) занимается стандартизацией протоколов и документированием практики, необходимых для осуществления обмена данными между автономными CDN.
Но прежде чем более детально рассмотреть архитектуру CDNI, давайте кратко освежим в памяти, что же такое сеть доставки контента и зачем она нужна.

Как работает CDN

Идея CDN проста – разместить реплики контента как можно ближе к потенциальным его потребителям и тем самым обеспечить стабильную необходимую пропускную способность, а также распределить нагрузку на серверы, поставщики контента, например, на веб-серверы. Реализация этой идеи в глобальном Интернете гораздо сложнее и требует ответа на вопросы: где и сколько реплик должно быть размещено, как синхронизировать контент, каким образом осуществлять перенаправление запросов пользователя к нужной реплике?
Решение связанных с этими вопросами задач требует создания распределенной наложенной сети с функциями управления и мониторинга. Можно выделить следующие основные компоненты CDN, представленные на рисунке 1.

Граничные кэширующие узлы

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

Управление кэшем

Различные классы контента требуют различных характеристик кэша. На основе статистической популярности и метаданных контента (например, заголовков Last-Modified) узел может вычислить возможное время истечения годность кэша и заранее освежить данные от источника. Это особенно важно в случае, когда сервер-источник не обеспечивает информацию по управлению кэшем (с помощью заголовков cache-control, etag, expires). Но даже если сервер использует заголовки для управления кэшем, они рассчитаны на кэширование браузером и не всегда адекватно работают в условиях CDN.
Поскольку CDN располагает значительной информацией относительно конкретного контента – его типа, характера запросов и т.п., управление кэшем может обеспечиваться более динамично, нежели с помощью заданных статических параметров кэша на сервере. Например, даже динамический контент, который обычно не подлежит кэшированию, имеет определенный период годности, в течение которого граничный узел может отвечать на запросы клиентов без обращения к серверу.

Определение местонахождения источника контента, включая обработку ситуаций недоступности

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

Изменение HTTP-заголовков

Граничные узлы могут добавлять, удалять или изменять заголовки HTTP-запросов и ответов, особенно заголовки куки (cookie), такие как set-cookie и cookie. Это может использоваться для обмена служебной информацией с сервером-источником и с пользователями, а также для управления каскадными кэшами.

Транспортная система доставки контента

В задачу транспортной системы входит оптимальная доставка требуемого контента к граничным кэширующим узлам. Небольшие CDN могут себе позволить одноуровневую структуру, когда граничные узлы посылают запросы на обновление кэша непосредственно веб-серверам. При этом для связности часто используется Интернет, а не выделенная сеть.
Крупные CDN используют многоуровневую структуру, когда группы граничных узлов приписаны к кэширующим кластерам более высокого уровня. Таким образом уменьшается нагрузка на веб-серверы – источники контента за счет увеличения частоты попадания в кэш (cache hit), а также уменьшается задержка доставки за счет дополнительного уровня распределения.
В качестве транспортной сети в крупных CDN используются либо наложенная, либо выделенная сеть. Во многих случаях используется оптимизация маршрутизации с использованием непрерывных тестов связности и пропускной способности между узлами. Все чаще для управления передачей трафика в транспортной сети используется архитектура SDN.
Более сложная структура иерархических кэшей используется при необходимости доставки видеопотоков, особенно в реальном времени. От граничных узлов также требуется дополнительная функциональность, так как они выполняют роль потоковых серверов. Потоковые серверы обеспечивают необходимую фрагментацию потока, его кодирование с различным разрешением/качеством и взаимодействие с клиентами.
Например, в сети Akamai в качестве узлов транспортной сети используется система «входных узлов» (entrypoint), расположенных в непосредственной близости к поставщику контента, и рефлекторов (set reflector), обеспечивающих оптимальную доставку данных в граничные узлы. Наконец, граничный узел представляет собой систему серверов, объединенных в мультикаст-сеть. Как и в обычной CDN, он обеспечивает доставку контента конечному пользователю.

Система маршрутизации запросов

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

Методы, основанные на использовании DNS

Эти методы являются наиболее популярными вследствие повсеместного присутствия DNS. В основе этого метода лежит использование специализированного DNS-сервера для трансляции имени ресурса, например, веб-сервера. В зависимости от указанных выше параметров выбора сервер возвращает различные записи ресурсов A/AAAA, CNAME или NS.
Так, например, в простейшем случае сервер может вернуть один или несколько IP-адресов оптимального граничного узла. Несколько IP-адресов позволяют осуществлять простейшую балансировку загрузки, когда клиенты буду получать поочередно IP-адреса из множества, тем самым распределяя нагрузку среди нескольких граничных узлов.
В более сложных ситуациях может использоваться многоуровневая трансляция имени, позволяющая распределить процесс принятия решений по маршрутизации запроса между основным DNS-сервером и несколькими, более специализированным и обладающим более полной информацией, DNS-серверами. Для этого используются записи NS или CNAME.
Основным недостатком использования записи NS для «каскадирования» процесса трансляции является то, что число уровней ограничено числом частей самого DNS-имени. Например, имя a.b.example.com допускает лишь один уровень «каскадирования» от сервера, отвечающего за example.com к серверу, авторитетному за b.example.com, который, в свою очередь вернет IP-адрес a.b.example.com.
Поэтому наиболее распространенным является использование CNAME, которое не накладывает такого ограничения.
Например, для получения IP-адреса граничного узла CDN Akamai, обслуживающего сервер www.apple.com, клиенту необходимо обработать три перенаправления: сначала на www.apple.com.edgekey.net., затем на www.apple.com.edgekey.net.globalredir.akadns.net. и наконец, на e6858.dscc.akamaiedge.net., адрес которого укажет на оптимальный для клиента граничный узел. Этот процесс схематично представлен на рис. 2.

Как мы видим, DNS-серверы, осуществляющие эти перенаправления, на самом деле являются компонентами системы маршрутизации запросов и генерируют имена в соответствии с алгоритмом поиска оптимального граничного кэширующего узла.
Однако использование DNS для маршрутизации запросов имеет существенные ограничения.
Во-первых, маршрутизация происходит на уровне запрашиваемого доменного имени, хотя предпочтительней была бы маршрутизация на уровне запрашиваемого объекта. Например, объекты контента с различными характеристиками (размер, частота обновления, транспортные характеристики) могут быть размещены на различных кэширующих узлах. И в то же время все они могут быть адресованы различными URL с общим доменным именем.
Во-вторых, для определения местонахождения клиента используется IP-адрес DNS-резолвера клиента, а не самого клиента, поскольку DNS-запрос на трансляцию имени поступает именно от резолвера. В некоторых случаях это может привести к существенным ошибкам в определении «ближайшего» граничного узла. Особенно когда используются резолверы, расположенные вне сети клиента, например, общедоступные резолверы PublicDNS или OpenDNS.
Для решения этой проблемы в IETF недавно был документирован механизм (RFC7871 “Client Subnet in DNS Queries”), позволяющий резолверу при обращении к авторитетному DNS-серверу указать префикс сети клиента (обычно /24 в случае IPv4). Для передачи этой информации используется специальная опция механизма расширений DNS EDNS0. Крупнейшие общедоступные резолверы PublicDNS (Google) и OpenDNS (Cisco), как и растущее число CDN, поддерживают эту опцию.
Тем не менее, проблема отчасти остается, как, впрочем, и проблема недостаточной детализации конкретного запрашиваемого объекта. Для этого используются методы маршрутизации на транспортном уровне и уровне приложений.

Маршрутизация запросов на транспортном уровне

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

Маршрутизация запросов на уровне приложений

Анализ запроса на уровне приложений дополнительно позволяет получить информацию о запрашиваемом объекте (или объектах) контента и, соответственно, обеспечить наиболее оптимальную маршрутизацию.
Типичным является анализ запрашиваемого URL для более точного определения обслуживающего граничного узла или ближайших кэшей более высокого уровня, содержащих запрашиваемые данные.
Также часто используется анализ заголовков, таких как Cookie, Accept-language и User-agent, для определения более оптимального источника данных. Куки используются для идентификации клиента сайта или веб-сессии.
Для перенаправления запроса используется возможность протокола HTTP сигнализировать новый маршрут с помощью кода перенаправления (коды «302 Found» или «307 Temporary Redirect»). В этом случае ответ содержит новый URL, который приложение должно использовать для доступа к контенту.
Иногда маршрутизация запросов для встроенных объектов, например, изображений, может осуществляться в момент загрузки страницы. В этом случае используется техника «переписывания URL», когда встроенные директивы HTTP переписываются на лету, указывая на наиболее оптимальное для данного клиента расположение объектов.

Взаимодействие CDN

Архитектура Интернета основана на взаимодействии сетей. В Интернете отсутствует «ядро», или опорная сеть, напротив, глобальная связность обеспечивается путем взаимодействия множества независимых сетей, а не одним суперпровайдером. Логично предположить, что аналогичная модель будет работать и для доставки контента. Вместо того, чтобы расширять собственную сеть в зонах, где уже присутствуют CDN, сеть может осуществлять «делегирование» доставки другим CDN, тем самым объединяя ресурсы и увеличивая общую эффективность.
Решением данной проблемы, разработкой и стандартизацией соответствующих протоколов занимаются несколько организаций, включая ETSI, Alliance for Telecommunications Industry Solutions (ATIS). Также разработка открытых интерфейсов взаимодействия ведется в рамках проекта ЕС Open ContEnt Aware Networks (OCEAN). В этой статье я подробно расскажу о подходе, который был стандартизован в рамках рабочей группы CDNI IETF.
В этом случае возможным сценарием доставки контента может быть следующий процесс:

Изначальный запрос от потребителя контента (пользователя) принимается авторитетной CDN – CDN, обслуживающей провайдера контента в рамках соответствующего соглашения. Часто такую CDN называют CDN вверх по потоку (Upstream CDN, uCDN).
Авторитетная CDN может обслужить запрос самостоятельно или же перенаправить его другой CDN, в случае, если последняя может сделать это лучше (например, вследствие близости к пользователю). Такую CDN называю CDN вниз по потоку (Downstream CDN, dCDN).
В ответ браузер пользователя запросит контент у dCDN, который, если требуется, будет подкачан из авторитетной uCDN и, если необходимо, от провайдера контента.

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

Кратко остановимся на интерфейсах этого взаимодействия:

CDNI Control interface (CI). Управляющий интерфейс, обеспечивающий обмен данными между системами управления CDN. Этот интерфейс необходим для инициализации всех остальных интерфейсов. В этом смысле он также иногда называется Trigger Interface.
CDNI Logging interface (LI). Через этот интерфейс происходит обмен информацией об операциях CDN. Например, взаимодействующие CDN могут использовать этот интерфейс для мониторинга трафика в реальном времени, либо асинхронно обмениваться данными для анализа работы и финансовых расчетов.
Интерфейс маршрутизации запросов отвечает за операции, необходимые для определения, какая CDN (и, возможно, какой граничный сервер) будет обслуживать запрос пользователя. Этот интерфейс состоит из двух взаимосвязанных интерфейсов:
CDNI Footprint & Capabilities Advertisement interface (FCI). Через этот интерфейс осуществляется асинхронный обмен информацией, требуемой для маршрутизации запросов, а именно информацией о зоне охвата и возможностях CDN.
CDNI Request Routing Redirection interface (RI). Этот интерфейс обеспечивает синхронные операции для определения CDN, отвечающую за доставку контента пользователю в ответ на конкретный запрос.
CDNI Metadata interface (MI). Этот интерфейс обеспечивает обмен метаданными, определяющими параметры обслуживания контента CDN. В качестве примера таких метаданных можно привести указания по геоблокированию, временные промежутки доступности контента и параметры доступа.

На сегодня основные спецификации, определяющие параметры этих интерфейсов и формат данных, стандартизованы. Приведу основные из них:

RFC 8006 “CDN Interconnection Metadata”
Эта спецификация определяет формат метаданных и протокол для обмена. Метаданные, связанные с определенным контентом, предоставляют dCDN информацию, необходимую для обслуживания запросов пользователя.
RFC 7975 “Request Routing Redirection interface for CDN Interconnection”
Этот документ определяет формат данных и протокол запросов uCDN другой о возможности последней обслужить конкретный пользовательский запрос. Также он определяет ответ обслуживающей dCDN, содержащий информацию о параметрах перенаправления пользовательского запроса.
RFC 7937 “CDNI Logging Interface”
Эта спецификация определяет структуру и протокол обмена информацией об операциях между взаимосвязанными CDN, а также формат файлов регистрационного журнала.
RFC 8007 “CDNI Control Interface / Triggers”
Эта спецификация определяет часть интерфейса CI, позволяющего одной CDN вызвать определенные действия со стороны другой CDN, которой делегирована доставка контента пользователю. Примером таких действий может быть подготовка контента и метаданных или очистка метаданных и кэша.
RFC 8008 “CDNI Request Routing: Footprint and Capabilities Semantics”
Этот документ определяет требования к протоколу FCI и, в частности, тип и формат данных, необходимых для извещения других CDN (выше по потоку) о возможностях и зоне охвата данной CDN.
URI Signing for CDN Interconnection
Эта спецификация находится в заключительной стадии стандартизации. Этот документ описывает, как концепция электронной подписи URI обеспечивает контроль доступа, и предлагает метод подписи URI.

Обеспечение защищенных соединений при взаимодействии CDN

Использование протокола TLS/HTTPS для шифрования данных и аутентификации веб-серверов становится все более общей практикой. При этом весь трафик между браузером и сервером зашифрован на уровне приложений, означая, что все данные HTTP, включая заголовки, URL и собственно сам контент, являются недоступными для промежуточных устройств.
Это, безусловно, представляет проблему для CDN. Отсутствие доступа к этим данным означает, что контент невозможно кэшировать, не представляется возможным манипулировать с заголовками и проводить анализ трафика для оптимальной маршрутизации запросов. Означает ли это, что сайты, использующие HTTPS, не могут эффективно обслуживаться CDN?
Для решения этой проблемы граничные узлы и система мониторинга должны иметь доступ к незашифрованному контенту. Обычно это достигается путем размещения секретного ключа и сертификата TLS, объединяющего параметры ресурса (полное доменное имя и организацию-оператор) с соответствующим публичным ключом, на каждом граничном узле, обслуживающем этот контент.
Этот процесс схематично показан на рис. 4. В этом случае каждый граничный узел может расшифровать передаваемые данные и вновь зашифровать его для передачи от и к поставщику контента (веб-сайту) по внутренней сети CDN. Для этого могут использоваться другие ключи и схемы шифрования.

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

LURK

В рамках совещания IETF96 в июле 2016 года был организован BoF LURK (Limited Use of Remote Keys, Ограниченное использование удаленных ключей) для обсуждения решения этой проблемы. Суть предлагаемой архитектуры заключается в следующем:
Вместо размещения секретного ключа на граничном узле предлагается использовать сервер ключей для удаленного выполнения криптографических операций. Авторизованные граничные узлы обращаются к серверу ключей для выполнения криптографических операций, в частности, для генерирования симметричного секретного сеансового ключа, используемого для шифрования данных. Даже если один из граничных узлов является скомпрометированным, это повлияет только на запросы, обслуживаемые этим узлом, а не на всю систему в целом, как в случае неавторизованного доступа к секретному ключу. Такой же подход может применяться для взаимодействующих CDN в рамках модели CDNI, которую мы только что рассмотрели. В этом случае CDN, которой делегирована функция доставки контента пользователю, должна получить доступ к серверу ключей.
Модель такой архитектуры представлена на рис. 5.

Внеполосное перенаправление (Out-of-band, OOB)

Этот подход, детально описанный в проекте спецификации «’Out-Of-Band’ Content Coding for HTTP»,
предлагает использование нового заголовка accept-encoding для указания местонахождения реплики запрашиваемого контента.
Работает это следующим образом: клиент (веб-браузер) отправляет первичный запрос на сервер, обслуживающий контент, www.example.com. В ответ сервер посылает код 200 OK вместе с картой альтернативных мест получения этого контента. Браузер обращается к одному из новых серверов и получает контент.
Этот механизм перенаправления предназначен для использования в CDN, а в случае взаимодействующих CDN – CDNI. Преимуществом является то, что альтернативные реплики ресурсов адресуются собственными URL. Соответственно, и TLS-сертификаты находятся под их полным контролем и не нуждаются в делегировании или репликации.
Обмен запросами в случае взаимодействующих CDN показан на рис. 6.

Краткосрочные сертификаты

В идеале, в рамках подхода LURK владелец контента/веб-сайта должен контролировать и обслуживать сервер ключей. Однако это не является практически реализуемым по нескольким причинам. Во-первых, это усложнит инфраструктуру владельца контента, а упрощение инфраструктуры является одним из мотивирующих факторов использования услуг CDN. Во-вторых, необходимость обслуживания запросов на криптографические операции с каждого граничного узла будет иметь серьезные негативные последствия для производительности и устойчивости всей системы. По этим причинам оператор CDN скорее всего создаст собственную масштабируемую инфраструктуру серверов ключей. Это оставляет проблему размещения секретного ключа в инфраструктуре оператора CDN нерешенной.
Использование краткосрочных (например, сроком действия три дня) сертификатов может уменьшить серьезность этой проблемы. В этом случае CDN периодически запрашивает у владельца контента новый сертификат и связанную с ним пару ключей (секретный и публичный). Владелец контента должен иметь возможность получения сертификата с помощью автоматизированного процесса, например, ACME. Разумеется, обмен данными происходит в зашифрованном виде.
Другая идея заключается в использовании так называемых делегированных сертификатов. Суть ее заключается в создании ограниченного механизма делегирования, который позволяет оператору сервера TLS выдавать свои учетные данные в рамках сертификата, выданного внешним центром сертификации. Поскольку такое делегирование, осуществляемое путем создания подчиненного сертификата, не связано с функцией CA по проверке владения именами, оно является безопасным, если получатель делегации выступает только от имени, разрешенного родительским сертификатом.
В настоящее время LURK, Внеполосное перенаправление и краткосрочные и делегированные сертификаты находятся на ранней стадии разработки. Однако некоторые прототипы уже существуют для OOB и LURK. Время покажет, насколько широким станет их внедрение. Станут ли основой архитектуры CDN стандарты CDNI или будущее останется за более закрытыми подходами, такими как расширение CDN с использованием облачной инфраструктуры, или решений типа OpenPlay.