Как работает CDN, Описание сервисов CDN

Печать

1. Аннотация

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

2. Архитектура и сервисы сети

Для оказания услуг компания CDNvideo использует собственную сеть доставки контента (Content Delivery Network, CDN). По функциональным признакам сеть CDNvideo делится на две области: ядро и серверы раздачи контента.
Серверы раздачи устанавливаются в местах наибольшей концентрации конечных пользователей. В общем случае контент сначала агрегируется в сети CDNvideo, а затем доставляется конечному пользователю с ближайшего к нему сервера. При этом под «ближайшим» понимается сервер, обладающий лучшей комплексной метрикой (оптимальный сервер не обязательно будет наиболее близким географически). За перенаправление запросов пользователей на оптимальные серверы раздачи отвечает редиректор, механизм работы которого рассмотрен в разделе 3. Редиректор входит в состав ядра сети и по сути является DNS-сервером, на котором запущено интеллектуальное программное обеспечение, работающее в связке с сервисом DNS.
В случае вещания в режиме реального времени (Live Streaming) поток предварительно доставляется на серверы публикации, входящие в состав ядра сети и далее транслируется на серверы раздачи.

«Главная цель CDN – максимально приблизить контент, в первую очередь видео, к конечным пользователям.»

Основные сервисы CDN:

  • Живые трансляции (Live Streaming). Позволяет вести прямые видеотрансляции событий для широкой аудитории в режиме реального времени. Трансляция может идти с сервера поставщика контента или непосредственно с IP-камеры. Другая область применения Live Streaming – трансляция прямого эфира телеканалов через Интернет (реализовано практически каждым крупным телеканалом).
  • Раздача аудиопотоков.
  • Вещание по запросу (Video On Demand Streaming). Предполагает просмотр видеоконтента в любой момент времени, удобный конечному пользователю.
    Возможен просмотр видеоролика с любого места без загрузки всего содержимого.
  • HTTP-кэширование. HTTP-контент по мере необходимости кэшируется на серверах раздачи и отдаётся с оптимального сервера по запросу пользователя.

Дополнительные сервисы CDN:

  • Авторизация доступа к контенту.
  • Доступ к программному интерфейсу (API) сети.
  • Генерация скриншотов.
  • Транскодирование потоков.
  • Навигация по эфиру (DVR).
  • Запись трансляций.

3. Перенаправление запросов пользователей

Перенаправление запросов пользователей на оптимальные серверы раздачи происходит на уровне DNS. Распространяемый контент должен быть доступен по доменным именам, находящимся в зоне ответственности CDNvideo. Для этого поставщику контента выделяется доменное имя в зоне CDNvideo (например, customer.cdnvideo.ru), которое должно использоваться при формировании ссылок на контент. Также возможен доступ к контенту по доменному имени в зоне ответственности поставщика (например, cdn.customer.com), в этом случае поставщику необходимо создать ресурсную запись CNAME (псевдоним) на своих DNS-серверах вида:
cdn.customer.com. CNAME customer.cdnvideo.ru

На сайте поставщика для распространяемого контента указываются ссылки с использованием доменного имени в зоне ответственности CDNvideo (например, http://customer.cdnvideo.ru/goal.flv) или с использованием псевдонима, указанного в записи CNAME (например, http://cdn.customer.com/goal.flv). Упрощённая схема перенаправления запросов представлена на Рис. 1.

Схема перенаправления запросов

Непосредственное перенаправление запросов выполняет редиректор в составе ядра сети, результатом является IP-адрес выбранного сервера раздачи. Для выбора оптимального сервера раздачи используется интеллектуальное программное обеспечение, оперирующее несколькими метриками доступности и работающее в связке с сервисом DNS. Выполняется постоянный мониторинг доступности серверов, что исключает перенаправление запросов на недоступный сервер.

4. Основные сервисы

4.1 Прямые трансляции (Live Streaming)

Базовые принципы

Для ведения прямой трансляции поток должен быть доставлен на серверы публикации CDNvideo. Источником трансляции может быть сервер, IP-камера, ноутбук со
специальным ПО, специальное кодирующее устройство. Существует несколько способов доставки потока на серверы публикации, более подробно вопрос рассмотрен в разделе
4.1.3.
В сети CDNvideo поток преобразуется в требуемый формат и транслируется конечным пользователям с оптимальных узлов раздачи. Трансляция инициируется по запросу от
пользовательского плеера к серверу раздачи. Ограничений на тип пользовательского плеера нет.
Возможно ведение трансляции в нескольких битрейтах, более подробно вопрос рассмотрен в разделе 4.1.4.

Требования к кодированию потока

Публикуемый поток должен удовлетворять следующим требованиям:

  • видеокодек – H.264;
  • аудиокодек – AAC или MP3.

Рекомендуем упорядочить публикуемый поток по ключевым кадрам (key frames) – в настройках H.264 выставить фиксированный интервал между ключевыми кадрами, 1-2
секунды. При выборе аудиокодека, следует учитывать, что, некоторые плееры в HTML5 реализации не поддерживают работу с MP3, и кодек AAC является более универсальным.

Публикация потока

Возможные способы публикации потока в сети CDNvideo:

  • RTMP-publish
  • RTMP-pull
  • RTSP-publish
  • RTSP-pull
  • MPEG_TS-publish

RTMP-publish
Наиболее предпочтительный способ публикации. Кодер должен поддерживать протокол RTMP. Примеры: Adobe FMLE, Apple QuickTime Broadcaster, ffmpeg. Для публикации выделяются два URL (основной и резервный) и имя потока с указанием авторизационного токена. Пример:
URL primary: rtmp://pub1.rtmp.test.cdnvideo.ru/test
URL backup: rtmp://pub2.rtmp.test.cdnvideo.ru/test
Stream: test.sdp?auth=261016ClEq

Резервный URL следует использовать только при наличии достаточной полосы пропускания.
Имя потока в настройках кодера обязательно должно указываться вместе с авторизационным токеном, в противном случае попытка публикации будет отклонена.
Рекомендованные настройки в случае использования ПО Adobe FMLE (для других кодеров аналогично):

  • Format: H.264
  • Frame Rate: 30 fps
  • Input Size: 640×480
  • Bit Rate: 700 Kbps
  • Output Size: 640×480
  • Audio: 64k AAC mono 44100 Hz

В случае трансляции одного события в нескольких битрейтах одновременно на вкладке “Encoding Options” можно создать до 3-х потоков, указав для каждого битрейт и выходное разрешение. Имена потоков произвольные, указываются в строке “Stream:” через точку с запятой:
Пример задания нескольких потоков

С системными требованиями к Adobe FMLE можно ознакомиться по ссылке:
Flash Media Encoder


RTMP-pull
Способ может быть использован, если существует готовый RTMP-поток (origin). Необходимо предоставить URL потока вида:
rtmp://origin.server/app/stream
Можно указать два URL — основной и резервный. Сервера CDNvideo будут настроены на забор потока и ретрансляцию.


RTSP-publish
Способ может быть использован, если кодер поддерживает публикацию потока по протоколу RTSP (например Apple QuickTime Broadcaster). Для публикации выделяются два URL (основной и резервный) вида:
rtsp://01.domain.cdnvideo.ru:PORT/domain-publish
rtsp://02.domain.cdnvideo.ru:PORT/domain-publish

Резервный URL следует использовать только при наличии достаточной полосы пропускания. Также выделяется пара Login/Password (запрашивается при подключении к серверу публикации). Имя потока может быть любым.


RTSP-pull
Способ может быть использован, если кодирующее устройство (обычно это IP-камера) поддерживает раздачу потоков по протоколу RTSP. Предварительно должны быть выполнены следующие условия:

  • доступность кодирующего устройства по постоянному публичному IP-адресу;
  • на кодирующем устройстве должен быть доступен для входящих соединений порт 554/tcp.

Для конфигурирования необходимо предоставить следующую информацию:

  • URL RTSP-источника;
  • название потока, например cam1.stream

Пример URL RTSP-источника для камеры Axis:
rtsp://login:secret@10.1.1.1:554/axis-media/media.amp
где пара login: secret – это, соответственно, логин и пароль для доступа к камере. В URL должен использоваться публичный IP-адрес кодирующего устройства.
Сервера публикации CDNvideo будут настроены на забор потока по заданному URL.


MPEG_TS-publish
Способ используется для публикации в формате MPEG_TS over UDP. Необходимо предоставить следующую информацию:

  • количество публикуемых потоков;
  • если есть пожелания по именованию раздаваемых потоков, сообщите нам имя каждого потока, (например, «stream1», «stream2»). Опционально.

Для публикации выделяются адреса двух серверов (основной и резервный) и каждому потоку назначается отдельный UDP-порт. Например:

  • поток stream1, UDP-порт 1111, IP: 1.2.3.4 primary, 2.3.4.5 backup
  • поток stream2, UDP-порт 2222, IP: 1.2.3.4 primary, 2.3.4.5 backup

Кодирующее устройство должно быть настроено на отправку потока (потоков) по указанным адресам и портам. Потоки будут раздаваться под заданными именами.


HTTP-livestream pull

Необходимо предоставить URL потока вида:

  • http://origin.server/app/stream/manifest.f4m
  • http://origin.server/app/stream/playlist.m3u8
  • http://origin.server/app/stream/Manifest
  • http://origin.server/app/stream/manifest.mpd

Контент загружается в кэш сервера раздачи с сервера-источника при первом запросе пользователя и используется при обслуживании последующих запросов. Объекты
хранятся в кэше в течение определенного периода времени:

  • Учитываются заголовки Cache-Control и Expires, выставленные на сервер-источнике.
  • Если заголовки отсутствуют, то время кэширования выставляется на стороне CDNvideo в зависимости от типа контента и/или с учётом дополнительных
    требований по времени кэширования.

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

Вещание конечным пользователям

Для вещания конечным пользователям используются следующие протоколы:

  • RTMP/RTMPT;
  • RTSP;
  • Adobe HDS;
  • Apple HLS;
  • Microsoft Smooth Streaming (MSS).
  • MPEG-DASH.

В случае проблем с трансляцией потока по протоколу RTMP в сторону пользователей, находящихся в корпоративных сетях с жёсткими политиками безопасности, рекомендуется рассмотреть следующие варианты:

  • Вещание по протоколу RTMP, при этом на сервере раздачи задействован порт tcp/80, обычно используемый веб-серверами. Передаются стандартные RTMP-пакеты. Способ позволяет обойти большинство фильтров.
  • Вещание по протоколу RTMPT (RTMP tunneling over HTTP). Трафик RTMP инкапсулируется в HTTP, сервер раздачи отдаёт пакеты с порта tcp/80. С точки зрения межсетевого экрана такие пакеты ничем не отличаются от стандартного веб-трафика.

Возможно ведение трансляции в нескольких битрейтах, с возможностью переключения между ними в плеере. Переключение между битрейтами вручную или автоматически в адаптивном режиме, в зависимости от реализации плеера. При этом для HTTP-based протоколов (HLS/HDS/MSS/MPEG-DASH) мы можем объединить несколько битрейтов
одним манифест-файлом, то есть дать на выходе готовое решение для адаптивного вещания.
Возможные варианты реализации вещания в нескольких битрейтах:

  • Для каждого битрейта публикуется отдельный поток.
  • Публикуется один поток в высоком качестве, который на выходе преобразуется в несколько битрейтов. Вариант реализуется за счёт использования сервиса «Транскодирование выходных потоков», описанного в разделе 5.6.

Порядок действий при подключении

1. Для размещения ссылок на трансляцию будет выделен домен в зоне CDNvideo вида customer.cdnvideo.ru. Вы можете создать псевдоним (CNAME) в своей зоне DNS вида
cdn.customer.ru (опционально).
2. Если планируется масштабная трансляция – 50 тысяч и более одновременных зрителей – сообщите нам об этом.
3. Выберите способ публикации и сообщите нам. В зависимости от выбранного способа мы предоставим дополнительную информацию.
4. Настроить кодирующее устройство.
5. Проверить показ трансляции на странице с тестовым плеером (ссылку мы предоставим).
6. Настроить ваш плеер на отображение потоков через сеть CDNvideo.

4.2 Вещание по запросу (Video on Demand)

Базовые принципы

Потоковое вещание по запросу подразумевает загрузку файлов на сервера раздачи CDNvideo с сервера-источника. Загрузка файла происходит пофрагментно, по мере необходимости и только в случае отсутствия соответствующего фрагмента в кэше сервера раздачи, обрабатывающего запрос пользователя. Например, в обязательном порядке начнётся загрузка файла на сервер раздачи при первом пользовательском запросе, направленном на данный сервер. Для загрузки используется протокол HTTP, полученные фрагменты сохраняются в кэше сервера раздачи и используются при следующих обращениях пользователей.
Требования к исходным файлам – тип контейнера:

  • FLV;
  • MP4.

Требования к исходным файлам – кодеки:

  • видеокодек – H.264;
  • аудиокодек – AAC или MP3.

Вещание конечным пользователям

Для вещания конечным пользователям используются следующие протоколы:

  • RTMP/RTMPT;
  • RTSP;
  • HTTP (псевдостримминг, более подробно в разделе 4.2.3);
  • Adobe HDS;
  • Apple HLS;
  • Microsoft Smooth Streaming (MSS);
  • MPEG-DASH.

В случае проблем с трансляцией видео по протоколу RTMP в сторону пользователей, находящихся в корпоративных сетях с жёсткими политиками безопасности,
рекомендуется рассмотреть следующие варианты:

  • Вещание по протоколу RTMP, при этом на сервере раздачи задействован порт
    tcp/80, обычно используемый веб-серверами. Передаются стандартные
    RTMP-пакеты. Способ позволяет обойти большинство фильтров.
  • Вещание по протоколу RTMPT (RTMP tunneling over HTTP). Трафик RTMP
    инкапсулируется в HTTP, сервер раздачи отдаёт пакеты с порта tcp/80. С точки
    зрения межсетевого экрана такие пакеты ничем не отличаются от стандартного
    веб-трафика.

Псевдостримминг

В нашей сети поддерживается псевдостриминг видеофайлов по протоколу HTTP c возможностью поиска по файлу (“перемоткой”). Возможны разные варианты реализации поиска. Обратите внимание, что поддержка поиска также должна быть реализована в плеере.
Первый вариант — с использованием аргумента start в строке запроса. Время старта указывается в секундах. Пример URL:
http://customer.cdnvideo.ru/filetoplay.mp4?start=300

Поддерживаемые контейнеры видео для этого варианта – MP4 и FLV, при этом в именах файлов должны использоваться расширения .mp4 или .flv соответственно.
Второй вариант реализации поиска — запрос байтовых диапазонов файла (byte-range requests), при этом специальных требований к формату видео не предъявляется.
Независимо от варианта реализации, необходимо подготовить файлы для псевдостримминга. Во-первых, необходимо правильно настроить вставку ключевых кадров (key frames) при кодировании, мы рекомендуем фиксированный диапазон 1-2 секунды. Во-вторых, необходимо вынести метаданные в начало файла. Более подробно о подготовке файлов можно прочитать по ссылкам:
http://flash.flowplayer.org/plugins/streaming/pseudostreaming.html#prepare
http://nginx.org/ru/docs/http/ngx_http_mp4_module.html

Для обоих вариантов поддерживается опция ограничения скорости отдачи файла, что позволяет контролировать объём передаваемого трафика. По умолчанию скорость отдачи не ограничивается.

Порядок действий при подключении

1. Для размещения ссылок на контент вам будет выделен домен в зоне CDNvideo вида customer.cdnvideo.ru. Для этого домена вы можете создать псевдоним (CNAME) в
своей зоне DNS вида cdn.customer.ru (опционально).
2. Оцените и сообщите нам общий объем контента.
3. Сообщите URL источника контента (например, http://origin.customer.ru/video/).
4. При использовании псевдостриминга – определить необходимость ограничения скорости отдачи файлов и указать значение, если такая необходимость есть. По умолчанию скорость отдачи не ограничивается.
5. После получения подтверждения от службы технической поддержки проверить корректность показа видео на тестовом объекте/домене.
6. Настроить ваш плеер на отображение потоков через сеть CDNvideo.

4.3 Раздача аудиопотоков

Базовые принципы

В нашей сети поддерживается три варианта работы с аудиопотоками:
1. Вещание конечным пользователям в формате интернет-радио по протоколу Icecast. Доступны все стандартные возможности Icecast. Оригинальный аудиопоток должен быть предварительно опубликован на SHOUTcast/Icecast сервере, который будет являться источником для серверов раздачи CDNvideo.
Внимание: мы не предоставляем сервер для начальной публикации, выбор возлагается на вас.
2. Источник трансляции в формате Icecast, вещание конечным пользователям по протоколам RTMP, RTSP, HDS, HLS, MPEG-DASH.
Внимание: протокол Microsoft Smooth Streaming не поддерживает audio-only потоки.
Поддерживаемые кодеки: AAC, AAC-LC, HE-AAC (aacPlus), MP3. В этом случае мы забираем предварительно опубликованный Icecast-поток (аналогично варианту 1) и преобразуем его в необходимый формат.
3. Публикация audio-only потоков стандартными средствами (RTMP, RTSP, MPEG-TS), как описано в разделе 4.1.3. Вещание конечным пользователям по протоколам RTMP, RTSP, HDS, HLS, MPEG-DASH.
Для создания ссылок на трансляцию вам будет выделен домен в зоне CDNvideo вида customer.cdnvideo.ru. Вы можете создать псевдоним (CNAME) в своей зоне вида cdn.customer.ru (опционально).
Статистика по текущим подключениям к аудиопотокам доступна через API, подробней в разделах 5.3.1 и 5.3.2.

Порядок действий при подключении (1-й вариант)

1. Сообщите нам URL потока на сервере-источнике SHOUTcast/Icecast. Пример URL: http://icecast.abc-customer.ru:8000/
2. Проверьте трансляцию аудио на странице с тестовым плеером (URL страницы мы предоставим).
3. Настройте ваш плеер на вещание аудиопотоков через сеть CDNvideo. Итоговая ссылка на поток, используемая для вещания через нашу сеть, будет выглядеть следующим образом: http://icecast.customer.cdnvideo.ru:8000/stream_name

Порядок действий при подключении (2-й вариант)

1. Сообщите нам URL потока на сервере-источнике SHOUTcast/Icecast. Пример URL: http://icecast.abc-customer.ru:8000/
2. Проверьте трансляцию аудио на странице с тестовым плеером (URL страницы мы предоставим).
3. Настройте ваш плеер на вещание аудиопотоков через сеть CDNvideo.

Порядок действий при подключении (3-й вариант)

1. Выберите способ публикации и сообщите нам. В зависимости от выбранного способа мы предоставим дополнительную информацию.
2. Настройте кодирующее устройство.
3. Проверьте трансляцию аудио на странице с тестовым плеером (URL страницы мы предоставим).
4. Настройте ваш плеер на вещание аудиопотоков через сеть CDNvideo.

4.4 Кэширование HTTP-контента

Базовые принципы

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

Алгоритм кэширования

Характерные особенности:

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

Как это работает. Допустим, на вашем сайте www.mycompany.com есть картинка с полным URL вида http://www.mycompany.com/images/logo.gif. Вам будет выделено доменное имя вида customer.cdnvideo.ru для модификации доменной части ссылок на кэшируемые объекты. Таким образом, новая ссылка на картинку будем выглядеть так:

http://customer.cdnvideo.ru/images/logo.gif

Обратите внимание, что относительный путь объекта не изменился. Обращение пользователя к такому объекту на сайте попадёт на один из серверов раздачи. Если это обращение было первым, объект будет запрошен с сервера-источника, отдан пользователю и сохранён в кэше для обслуживания последующих запросов.

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

Время хранения объекта в кэше определяется HTTP-заголовками Cache-Control (со значением ‘max-age’) и Expires. Заголовки должны выставляться на сервере-источнике; достаточно указать только один из них. Одновременное использование обоих заголовков не запрещается, хотя и является избыточным; в этом случае следует проследить, чтобы их значения не противоречили друг другу. Если эти заголовки отсутствуют, то по умолчанию время хранения объекта в кэше принимается равным 24-м часам. Следует особо обратить внимание на правильное выставление указанных HTTP-заголовков в случае динамически меняющегося контента, поскольку это напрямую влияет на актуальность объекта, хранящегося в кэше.
Высокого уровня актуальности динамического контента можно добиться, используя API сети CDNvideo для удаления отдельных объектов из кэша всех серверов раздачи. В этом случае объект будет загружен из источника заново при первом обращении пользователя. Более подробно очистка кэша рассмотрена в разделе 5.3.4.

Обработка query string

При раздаче объектов с URL, содержащими строку параметров (query string) вида:
http://server/path/program?query_string
следует учесть, что по умолчанию при кэшировании такого объекта query string удаляется из заголовка Request URI. При последующих запросах пользователям будет выдаваться первый закэшированный объект с таким URL, без учёта значения query string в запросе. Если вас такая модель работы не устраивает и сохранение ‘query string’ в URL необходимо – сообщите нам об этом и мы сделаем необходимые настройки.

Файл robots.txt

Файл robots.txt предназначен для роботов поисковых систем. В нашей сети поддерживается три варианта использования файла:
1. Мы используем собственный robots.txt, который запрещает индексирование всего кэшируемого контента всем поисковым роботам. Это стандартная опция, которая применяется по умолчанию.
2. Мы проксируем с сервера-источника ваш robots.txt без изменений.
3. Мы используем кастомный robots.txt, присланный вами.
По умолчанию мы используем вариант 1, чтобы предотвратить множественную индексацию контента. В большинстве случаев этот вариант наиболее предпочтителен. Тем не менее, в некоторых случаях (например, при кэшировании CSS и скриптов) при использовании варианта 1 возможны нежелательные эффекты, которые могут привести к потере позиций сайта в выдаче поисковых систем. В этом случае оптимальным выбором может стать вариант 2 или 3. Окончательное решение остаётся за вами (и вашим SEO), исходя из структуры сайта и характера кэшируемого контента.
Рекомендации Яндекс и Google:
Яндекс
Google

 

Заголовки CORS

В определённых случаях обращение к контенту, размещённому в CDN, расценивается браузером как кросс-доменный запрос и блокируется. В первую очередь это касается шрифтов. Проблема решается выставлением заголовков CORS (Cross-Origin Resource Sharing) для кэшируемых объектов. Вариантов два:
1. Вы сами выставляете заголовки CORS на сервере-источнике.
2. Мы добавляем заголовок Access-Control-Allow-Origin на своей стороне. Значение заголовка формируется по вашим требованиям. По умолчанию будет выставлено значение Access-Control-Allow-Origin: *, открывающее доступ к ресурсу с любого домена.

Сообщите нам, если вы выбрали второй вариант. По умолчанию заголовки CORS для кэшируемых объектов не добавляются.
Более подробно о CORS можно прочитать по ссылке:
enable-cors.org

Порядок действий при подключении

1. Сообщите нам следующие исходные данные :

  • URL источника контента.
  • Общий объем контента (в случае, если этот объем превышает 100 Мбайт). В соответствии с этим значением для вас будет выделена дисковая ёмкость на каждом сервере раздачи. По умолчанию 100 Мбайт.
  • Время хранения объектов, для которых не выставлен заголовок Cache-Control или Expires. По умолчанию 24 часа.
  • Вариант использования query string (если актуально).
  • Вариант использования robots.txt. По умолчанию индексирование кэшируемого контента запрещено.
  • Вариант использования заголовков CORS (если актуально).

2. Настройте на сервере-источнике генерацию корректных HTTP-заголовков Cache-Control или Expires.
3. Для размещения ссылок на контент вам будет выделен домен в зоне ответственности CDNvideo вида customer.cdnvideo.ru. Для этого домена вы можете создать псевдоним (CNAME) в своей зоне DNS вида cdn.mycompany.com (опционально).
4. После получения подтверждения от службы технической поддержки проверьте корректность загрузки веб-контента на тестовом объекте/домене.
5. Для кэшируемых объектов разместите на своем сайте ссылки с использованием выделенного доменного имени в зоне CDNvideo (или псевдонима CNAME).

Сервис TLS/SSL

Для веб-ресурсов, использующих защищенные соединения HTTPS, мы предлагаем сервис терминации TLS/SSL на наших серверах раздачи. Проясним терминологию. HTTPS – это расширение обычного протокола HTTP, позволяющее передавать веб-трафик в зашифрованном виде. Передаваемые данные защищены от прослушивания (конфиденциальность) и подмены (целостность). Кроме того, при установлении HTTPS-соединения проверяется подлинность сервера (аутентификация сервера). Для установления HTTPS-соединений используется протокол TLS, который ранее назывался SSL. Далее по тексту используется термин TLS.
Необходимым условием работы TLS является наличие на сервере цифрового сертификата. В нашей сети возможно два варианта использования сертификата и выбор находится в прямой зависимости от того, какое доменное имя вы используете для кэшируемого контента.
В первом случае кэшируемый контент находится в зоне *.cdnvideo.ru. Мы используем наш собственный сертификат, подписанный одним из доверенных международных удостоверяющих центров (УЦ), детали сертификата можно уточнить у нашей службы технической поддержки. Сертификат CDNvideo уже размещён на всех серверах раздачи нашей сети, от вас дополнительных шагов не требуется.
Обратите внимание, что наш сертификат валиден только для доменов третьего уровня. Домены 4-го и следующих уровней нашим сертификатом не подтверждаются. Примеры:
домен customer.cdnvideo.ru — OK!
домен static.customer.cdnvideo.ru – FAIL!

Использование сертификата CDNvideo

Во втором случае кэшируемый контент находится в вашей доменной зоне с использованием CNAME. Используется ваш сертификат, подписанный доверенным УЦ, и соответствующий ему закрытый ключ. От вас нам потребуется два файла, которые будут размещены на всех серверах раздачи CDNvideo:
Цифровой сертификат в формате PEM. Обычно это файл с расширением .crt. Сертификат должен быть подписан общепризнанным доверенным УЦ и быть валидным — с неистёкшим сроком действия, доменное имя в сертификате должно соответствовать используемому CNAME. Проверьте это заранее. В случае сомнений присылайте сертификат нашей службе технической поддержки для проверки.
Соответствующий сертификату закрытый ключ в формате PEM. Обычно это файл с расширением .key. При генерации ключа не используйте passphrase, мы не сможем использовать такой ключ!

Использование своего сертификата

Примеры выбора варианта:
Контент в зоне customer.cdnvideo.ru — используется сертификат CDNvideo.
Контент в зоне static.yourcompany.com — используется ваш сертификат.

Терминация TLS в нашей сети подразумевает, что защищённое соединение устанавливается между пользователем и сервером раздачи CDNvideo. Между серверами раздачи и источником обычно используется стандартный HTTP и в большинстве случаев этого вполне достаточно. Если по какой-то причине вам необходимо использовать TLS на участке «сервер раздачи – источник», убедитесь, что на сервере-источнике имеется валидный сертификат, подписанный доверенным УЦ.

5. Дополнительные сервисы

Авторизация доступа к потоковому контенту

Сервис применим как для live-потоков, так и для VOD. Авторизация поддерживается для всех протоколов, доступных в нашей сети: RTMP, RTSP, HLS, HDS, MSS, MPEG-DASH. Реализовано два механизма авторизации:
1. Внешняя авторизация, когда решение о доступе к потоку принимается средствами владельца контента.
2. Локальная авторизация, когда решение о доступе к потоку принимается средствами нашей сети на основе критериев, обозначенных владельцем контента.

Внешняя авторизация

В данном случае авторизация запросов к потокам происходит за пределами сети CDNvideo, например, с помощью скрипта авторизации на стороне владельца контента.
При каждом обращении пользователя к защищённому потоку сервер CDNvideo отправляет HTTP-запрос HEAD к скрипту авторизации на стороне владельца контента. В заголовках запроса передаются следующие параметры:
x-cdn-method : тип запрошенного потока;
x-cdn-stream-name : имя запрошенного потока;
x-cdn-client-ip : IP-адрес пользователя;
x-cdn-query : авторизационные параметры запроса; в случае HTTP это queryString, в случае RTMP – аргументы NetConnect, указанные после знака ‘?’;
x-cdn-uri : URI потока;
x-cdn-referrer : URL Flash-плеера (только для Flash);
x-cdn-user-agent : название и версия плеера пользователя;
x-cdn-page-url : URL страницы, содержащей код Flash-плеера (только для Flash);
x-cdn-session-id : идентификатор сессии;
x-cdn-event : событие.

Возможные значения заголовка x-cdn-method:
flash : Adobe Flash Player/RTMP;
http : HTTP-протоколы (HDS, HLS, MSS, MPEG-DASH);
rtp : RTSP

Возможные значения заголовка x-cdn-event:
play : запрос на проигрывание потока;
publish : запрос на публикацию потока (только для RTMP).

Владелец контента может формировать ссылки с указанием авторизационных параметров после знака ‘?’, которые будут переданы в заголовке x-cdn-query. Ниже пример для RTMP:
rtmp://flash.cdnvideo.ru/live?auth_id=13211
Stream name: stream.sdp

В итоге, для ссылки, приведённой в качестве примера, заголовки могут быть следующими:
x-cdn-method: flash
x-cdn-stream-name: stream.sdp
x-cdn-client-ip: 212.2.11.117
x-cdn-query: auth_id=13211
x-cdn-uri: rtmp://flash.cdnvideo.ru/live
x-cdn-referrer: http://www.cdnvideo.net/aloha/wowza-examples/LiveVideoStreaming/client/live.swf
x-cdn-user-agent: MAC 10,1,85,3
x-cdn-page-url: http://www.cdnvideo.net/aloha/wowza-examples/LiveVideoStreaming/client/live.html
x-cdn-session-id: 921547595
x-cdn-event: play

В ответ сервер CDNvideo ожидает HTTP response со статусом ‘200 OK’, содержащий следующие заголовки:
x-cdn-status-int : результат авторизации;
x-cdn-status-text : текстовое описание ответа;
x-cdn-msg : текст для передачи ошибки в Flash-плеер (только для Flash/RTMP).

Возможные значения заголовка x-cdn-status-int:
0 : доступ разрешен;
1 : доступ запрещен.

Пример разрешающего ответа:
x-cdn-status-int: 0
x-cdn-status-text: OK

Пример запрещающего ответа:
x-cdn-status-int: 1
x-cdn-status-text: Access forbidden, auth_id not exist.

Для настройки авторизации необходимо предоставить URL внешнего скрипта.
Упрощённая схема успешной авторизации представлена на Рис. 5.
Схема успешной авторизации

Локальная авторизация (на основе подписи)

В данном случае авторизация запросов пользователей выполняется исключительно в сети CDNvideo, внешние ресурсы не используются.
В момент обращения пользователя к защищённому ресурсу владельцу контента необходимо сформировать специальную ссылку. Пример для RTMP:
rtmp://customer.cdnvideo.ru/mc10/mp4:10/f/s3/75/756_a90c4c43ef0986b5b34df83827adc50b/m/756_a90c4c43ef0986b5b34df83827adc50b_2013-11-07_sample_video_14_63.mp4?md5=xs1YG76uMJF2kfkpg_cRlg&e=1387984516

Ссылка содержит два авторизационных параметра:
‘md5=’ — хэш MD5 в формате Base64 for URL, сгенерированный на основе URI запрошенного ресурса, времени жизни ссылки, секретного ключа, IP-адреса пользователя (опционально);
‘e=’ — время окончания действия ссылки в формате POSIX time.

При обращении к потоку с использованием сгенерированной ссылки, CDN вычисляет значение MD5 и сравнивает его с полученным. Если значение не совпадает или текущее время превышает значение “e”, то пользователю возвращается ответ с кодом ‘403 Forbidden’ (запрет на воспроизведение).

Пример алгоритма расчета MD5-хэша с использованием IP-адреса пользователя в качестве одного из входных параметров:
md5 = base64_url(md5(SECRET:1382106248:1.2.3.4:/app_name/stream_name.sdp))

Обратите внимание, что доменная часть URI при вычислении хэша не используется!

Пример генерации ссылки

1. Есть следующие входные данные:
секретный ключ: zah5Mey9Quu8Ea1k
IP-адрес пользователя: 1.2.3.4
URI ресурса для RTMP:
rtmp://customer.cdnvideo.ru/mc10/mp4:10/f/s3/75/756_a90c4c43ef0986b5b34df83827adc50b/m/756_a90c4c43ef0986b5b34df83827adc50b_2013-11-07_sample_video_14_63.mp4

2. Вычисляем время действия ссылки. В приведённом примере – неделя с момента генерации.
php -r ‘print time() + (7 * 24 * 60 * 60) . «\n»;’
1387984516

3. Вычисляем хэш MD5 в формате Base64 for URL:
php -r ‘print str_replace(«=», «»,strtr(base64_encode(md5(«zah5Mey9Quu8Ea1k:1387984516:1.2.3.4:/mc10/mp4:10/f/s3/75/756_a90c4c43ef0986b5b34df83827adc50b/m/756_a90c4c43ef0986b5b34df83827adc50b_2013-11-07_sample_video_14_63.mp4», TRUE)), «+/», «-_»)) . «\n»;’
xs1YG76uMJF2kfkpg_cRlg

4. Итоговая ссылка:
rtmp://customer.cdnvideo.ru/mc10/mp4:10/f/s3/75/756_a90c4c43ef0986b5b34df83827adc50b/m/756_a90c4c43ef0986b5b34df83827adc50b_2013-11-07_sample_video_14_63.mp4?md5=xs1YG76uMJF2kfkpg_cRlg&e=1387984516

Важное замечание: хэш MD5, вычисленный для RTMP, является базовым для данного ресурса. То есть, один и тот же хэш будет использован для ссылок на видеоролик по протоколам RTMP, RTSP, HLS, HDS, MSS, MPEG-DASH несмотря на то, что URI для разных протоколов может немного отличаться. Ещё раз – а) хэш для всех ссылок на данный файл будет один и тот же б) хэш вычисляется на основе URI для RTMP. Для приведённого примера HLS-ссылка будет выглядеть так:
http://customer.cdnvideo.ru/mc10/_definst_/mp4:10/f/s3/75/756_a90c4c43ef0986b5b34df83827adc50b/m/756_a90c4c43ef0986b5b34df83827adc50b_2013-11-07_sample_video_14_63.mp4/playlist.m3u8?md5=xs1YG76uMJF2kfkpg_cRlg&e=1387984516

Обратите внимание, что несмотря на то, что URI отличается, хэш MD5 используется тот же, что и для RTMP.
При локальной авторизации контролируются следующие параметры:
1. URI запрашиваемого ресурса. Проверяется, что ссылка была сформирована именно для этого потока.
2. Секретный ключ. Проверяется, что ссылка сформирована именно владельцем контента.
3. Время окончания действия ссылки.
4. IP-адрес пользователя (опционально). Проверяется, что поток запрошен именно с того IP-адреса, для которого была сформирована ссылка.

Дополнительно могут быть проверены и другие параметры запроса пользователя:
1. Географическая принадлежность пользователя (на основе IP-адреса), с детализацией до уровня города.
2. URL страницы, содержащей код Flash-плеера (только для Flash). Позволяет контролировать, на каких сайтах может быть размещён код плеера.
Для настройки необходимо предоставить следующую информацию:
1. секретный ключ;
2. вариант расчёта MD5 (с использованием IP-адреса пользователя или без);
3. необходимость проводить авторизацию по дополнительным параметрам (GeoIP, привязка к доменам).

5.2 Авторизация доступа к HTTP-контенту

Мы поддерживаем два метода ограничения доступа к HTTP-контенту:
1. Внешняя авторизация с обращением к скрипту на стороне владельца контента. Метод хорош для статического контента (большие файлы), настоятельно не рекомендуем для динамически генерируемого контента – файлов HLS, HDS, MSS, MPEG-DASH (чанки и манифесты).
2. Локальная авторизация с проверкой на серверах раздачи MD5-хэша и времени жизни ссылки. Рекомендуемый метод для авторизации контента HLS, HDS, MSS, MPEG-DASH. Для статики тоже подходит без проблем.

Внешняя авторизация

Защищаемый статический контент должен быть помещён в отдельный каталог на сервере-источнике. Например:
http://origin.client.ru/secure/
Доступ к каталогу должен быть разрешен только для серверов CDNvideo (мы предоставим IP-адреса). Каталог будет исключён из доступа по прямым ссылкам вида http://client.cdnvideo.ru/secure/file.

Отдача защищенных файлов будет осуществляться только через обязательную проверку по ссылкам с авторизационными параметрами вида:
http://client.cdnvideo.ru/secure/path/to/file?parameter=value

Ссылки формируются владельцем контента. Сервер раздачи при получении такого обращения проксирует запрос к скрипту авторизации на стороне владельца контента. В запрос добавляются следующие заголовки:
X-Real-IP : IP-адрес пользователя;
X-CDN-Query : запрошенный URI.

Например:
X-Real-IP: 1.2.3.4
X-CDN-Query: /secure/file.mp4?parameter=value

Скрипт авторизации должен проверить валидность запроса и прислать HTTP-ответ:
Ответ с кодом 403 или 401 запрещает доступ;
Ответ с кодом 200 разрешает доступ.

Нам нужна следующая информация для настройки:
путь к каталогу с защищаемым веб-контентом на сервере-источнике;
URL скрипта авторизации.

Локальная авторизация

Защищаемый статический контент должен быть помещён в отдельный каталог на сервере-источнике. Например:
origin.client.ru/secure/

Доступ к данному каталогу должен быть разрешен только для серверов CDNvideo (мы предоставим IP-адреса). Каталог будет исключён из доступа по прямым ссылкам вида http://client.cdnvideo.ru/secure/file. Отдача защищенных файлов только через обязательную поверку по ссылкам с авторизационными параметрами вида:
http://client.cdnvideo.ru/secure/file.mp4?md5=TJwAm-lsft38vJEdDh-Kbg&e=1306830000

В URL содержится два авторизационных параметра:
md5 — MD5-хэш, сгенерированный на основе URI, времени жизни и секретного ключа;
e — время окончания действия ссылки (POSIX time).

При получении такого запроса, сервер раздачи вычисляет значение MD5 и сравнивает его с полученным. Если значение не совпадает или текущее время превышает значение “e”, то пользователю возвращается HTTP-ответ с кодом ‘403 Forbidden’ (запрет на воспроизведение).

Алгоритм расчета MD5-хэша может также использовать IP-адрес пользователя в качестве входных данных. Пример вычисления MD5-хэша без использования IP-адреса:
md5 = base64_url(md5(SECRET:1306830000:/secure/file.mp4))

Пример вычисления MD5-хэша с использованием IP-адреса:
md5 = base64_url(md5(SECRET:1306830000:1.2.3.4:/secure/file.mp4))

Пример генерации MD5 с использованием PHP:
php -r ‘print str_replace(«=»,
«»,strtr(base64_encode(md5(«SECRET:1306830000:1.2.3.4:/secure/file.mp4», TRUE)),
«+/», «-_»)) . «\n»;’
TJwAm-lsft38vJEdDh-Kbg

Результирующая ссылка для пользователя будет следующей:
http://client.cdnvideo.ru/secure/file.mp4?md5=TJwAm-lsft38vJEdDh-Kbg&e=1306830000

Информация, необходимая для настройки локальной авторизации для статики:
путь к каталогу с защищаемым веб-контентом на сервере-источнике;
секретный ключ;
вариант расчёта MD5 (с использованием IP-адреса пользователя или без).

Для динамически генерируемого контента HLS, HDS, MSS, MPEG-DASH используется аналогичная схема, но с некоторыми отличиями. Во-первых, нет необходимости выделять контент в отдельный каталог. Во-вторых, при расчёте MD5 используется неизменяемая часть URI. Рассмотрим на примере HLS. Запрос HLS-ресурса инициирует обращение плеера последовательно к мастер-плейлисту, чанклисту, и, наконец, к самим медиа-чанкам:
http://hls.client.cdnvideo.ru/app1/stream1/playlist.m3u8
http://hls.client.cdnvideo.ru/app1/stream1/chunklist.m3u8
http://hls.client.cdnvideo.ru/app1/stream1/media_40.ts
http://hls.client.cdnvideo.ru/app1/stream1/media_41.ts
Неизменяемая часть URI: /app1/stream1/

Авторизовываться будет каждая единица контента – плейлисты, чанклисты, медиа-чанки.

5.3 Программный интерфейс (API) сети CDNvideo

API позволяет просматривать статистику и статус раздачи видео- и аудиопотоков, выполнять просмотр и очистку HTTP-кэша на серверах раздачи. Авторизация доступа к API осуществляется двумя способами:

  • Авторизация с использованием авторизационного токена (разделы 5.3.1 и 5.3.2). Этот метод авторизации используется для просмотра статистики раздачи потоков (разделы 5.3.3 и 5.3.4).
  • Авторизация по белому списку доступа. Этот метод используется для вызовов API работы с HTTP-кэшем (разделы 5.3.5 и 5.3.6). Если вы планируете использовать эти вызовы — сообщите перечень IP-адресов, с которых будут идти запросы к API, адреса будут внесены в белый список доступа.

Получение авторизационного токена

Авторизационный токен необходим для обращения к API статистики раздачи потоков (раздел 5.3.3). Авторизационный токен валиден в течение 6 часов с момента его генерации, последующие генерации не перезаписывают ранее сгенерированные токены и равносильно валидны в течение персонального времени жизни.
Шаблон запроса:
Метод: POST
POST-параметры запроса: username, password
URL: https://api.cdnvideo.ru/app/oauth/v1/token/
Пример выполнения запроса:
$ curl -s -d «username=testuser@testemail.ru&password=test» «https://api.cdnvideo.ru/app/oauth/v1/token/»
{«person_id»: 65745670, «status»: 200, «token»: «cdn1_VGO1T5G11785ODJZP4VJ260ZI4V7FP»}
Тело ответа содержит следующие параметры:
person_id : идентификационный номер клиента.
status: : HTTP-код ответа.
token : авторизационный токен.
Полученный токен необходимо передавать в заголовке запроса cdn-auth-token при обращении к API статистики раздачи потоков (разделы 5.3.3 и 5.3.4). В реальном запросе в полях username и password должны быть указаны e-mail и password, которые используются для доступа в личный кабинет CDNvideo. Если у Вас нет доступа в личный кабинет, обратитесь, пожалуйста, за доступом к Вашему менеджеру.

Получение списка аккаунтов

Информация о доступных аккаунтах для текущего person_id. Уникальный идентификатор аккаунта необходимо указывать при обращении к API статистики раздачи
потоков (разделы 5.3.3 и 5.3.4).
Шаблон запроса:
Метод: GET
URL: https://api.cdnvideo.ru/app/inventory/v1/accounts

Пример выполнения запроса:
$ curl -H ‘cdn-auth-token:cdn1_VGO1T5G11785ODJZP4VJ260ZI4V7FP’
‘https://api.cdnvideo.ru/app/inventory/v1/accounts’
[{«uid»: «1-1-test», «name»: «test»}, {«uid»: «1-1-cdntest», «name»: «cdntest»},]
Тело ответа содержит следующие параметры:
uid : уникальный идентификатор аккаунта
name : имя аккаунта

Статистика раздачи потоков

Информация о текущем количестве подключений к потокам. Исходные потоки могут быть опубликованы в сети CDNvideo с помощью стриминговых протоколов (подробнее в разделе 4.1.3) или проксированы при помощи HTTP-livestream pull.
Шаблон запроса:
curl -H ‘cdn-auth-token:TOKEN’
‘https://api.cdnvideo.ru/app/streamstat/v1/accounts/UID/activesessionsummary’
В реальном запросе в заголовке cdn-auth-token должен быть передан авторизационный токен (раздел 5.3.1), в поле UID должен быть указан uid аккаунта по которому запрашивается информация о потоках. Пример выполнения запроса:
$ curl -H ‘cdn-auth-token:cdn1_VGO1T5G11785ODJZP4VJ260ZI4V7FP’
‘https://api.cdnvideo.ru/app/streamstat/v1/accounts/1-1-cdntest/activesessionsummary’
В теле ответа содержится разбивка по протоколам раздачи для каждого опубликованного потока:
{
«streams»: {
«test/_definst_/airstream0012» : {
«sessionsFlash» : 91,
«sessionsTotal» : 91
},
«test/_definst_/airstream0011» : {
«sessionsFlash» : 34,
«sessionsHLS» : 31,
«sessionsTotal» : 65
}
}
}

Идентификаторы протоколов:
SanJose: HDS
Smooth: Microsoft Smooth Streaming
Flash: RTMP
RTSP: RTSP
Icecast: Icecast
HLS: HLS

Список текущих подключений к потокам

Перечень подключений к потокам с подробной информацией о каждом подключении.
Шаблон запроса:
curl -H ‘cdn-auth-token:TOKEN’
‘https://api.cdnvideo.ru/app/streamstat/v1/accounts/UID/activesessiondetail’http://api.cdnvideo.ru:8888/0/streamsinfo?id=num_name

В реальном запросе в заголовке cdn-auth-token должен быть передан поле id авторизационный токен (раздел 5.3.1), в поле UID должен быть указан uid аккаунта по которому запрашивается подробная информация о потоках.должно быть указано значение выделенного вам идентификатора. Пример выполнения запроса:
$ curl -H ‘cdn-auth-token:cdn1_VGO1T5G11785ODJZP4VJ260ZI4V7FP’
‘https://api.cdnvideo.ru/app/streamstat/v1/accounts/1-1-cdntest/activesessiondetail’

В теле ответа содержится список текущих подключений к потокам:
{
«streams» : {
«live/_definst_/stream1» : [
{
«SessionType» : «HLS»,
«SessionId» : «7a8899e2a72573593c415e8d1c892728»,
«UserId» : «50f8c986a2c4ec4e12f2438d719549a5»,
«IpAddress» : «151.33.12.11»,
«UserAgent» : «HLS Client/2.0 (compatible; LG NetCast.TV-2012)»
},

],
«stream2» : [
{
«SessionType» : «Icecast»
},

],

}
}

Для идентификации пользователя/сессии можно использовать все поля, в частности SessionId, UserId, IpAddress, UserAgent. Для подключений Icecast подробная информация недоступна.

Просмотр HTTP-кэша

Для поиска отдельного объекта в кэше серверов раздачи используется команда list1.
Команда проверяет наличие объекта в кэше хотя бы одного из серверов раздачи. Для файла с URL на сервере-источнике вида http://origin/path/to/file.jpg шаблон запроса будет выглядеть следующим образом:
http://api.cdnvideo.ru:8888/0/list?id=num_name&type=http&object=http://origin/path/to/file.jpg
В реальном запросе в поле id должно быть указано значение выделенного вам идентификатора. В ответе HTTP 200 OK передаётся заголовок X-cdn-command, содержащий информацию о статусе выполнения команды с диапазоном значений от 0 до 9. Значение, отличное от нуля, означает ошибку выполнения.
Пример успешного выполнения команды:
HTTP/1.1 200 OK
X-cdn-command: 0

Результат выполнения команды передаётся в теле ответа. При наличии объекта в кэше одного или нескольких (или всех) серверов раздачи тело ответа будет содержать URL объекта.
Пример выполнения команды list для объекта http://test/7/5/4/754_45966.flv, идентификатор клиента 01_test, объект обнаружен в кэше:
curl -v ‘http://api.cdnvideo.ru:8888/0/list?id=01_test&type=http&object=http://test/7/5/4/754_45966.flv’
< HTTP/1.1 200 OK
< X-cdn-command: 0
{
«01_test»: {
«http»: {
«object»: [
{
«name»: «http://test/7/5/4/754_45966.flv»
}
]
}
}
}

Для поиска объектов с QueryString все знаки ‘&’ после ‘?’ нужно заменить на ‘%26’.
Пример:

  • не сработает: curl -v ‘http://api.cdnvideo.ru:8888/0/list?id=01_test&type=http&object=http://www.shop.test.ru/pictures/image.php?width=427&height=500&image=/upload/mediabank/619602-106/front_belyy.jpg’
  • сработает: curl -v ‘http://api.cdnvideo.ru:8888/0/list?id=01_test&type=http&object=http://www.shop.test.ru/pictures/image.php?width=427%26height=500%26image=/upload/mediabank/619602-106/front_belyy.jpg’

 

Очистка HTTP-кэша

Для удаления отдельного объекта в кэше всех серверов раздачи следует использовать команду delete. Для файла с URL на сервере-источнике вида http://origin/path/to/file.jpg шаблон запроса будет выглядеть следующим образом:
http://api.cdnvideo.ru:8888/0/delete?id=num_name&type=http&object=http://origin/path/to/file.jpg
В реальном запросе в поле id должно быть указано значение выделенного вам идентификатора.

В ответе HTTP 200 OK передаются заголовки:

  • X-cdn-command, содержащий информацию о статусе выполнения команды с диапазоном значений от 0 до 9. Если значение равно нулю, объект был успешно удалён из кэша всех серверов раздачи. Значение, отличное от нуля, означает ошибку выполнения.
  • X-cdn-command-id, содержащий в себе идентификатор команды в очереди задач.
  • Также может быть передан заголовок X-cdn-comment, содержащий текстовый комментарий.

Пример ответа после успешного удаления объекта:
HTTP/1.1 200 OK
X-cdn-command: 0
X-cdn-command-id: aa29e3a8-e711-11e6-9af6-00259006bb2e
X-cdn-comment: OK
Пример неуспешного выполнения команды:
HTTP/1.1 200 OK
X-cdn-command: 1
X-cdn-comment: Fail. Retry later.
Пример удаления из кэша CDN объекта http://test/7/5/4/754_45966.flv (команда delete), идентификатор клиента 01_test:
curl -v ‘http://api.cdnvideo.ru:8888/0/delete?id=01_test&type=http&object=http://test/7/5/4/754_45966.flv’

>
< HTTP/1.1 200 OK
< X-cdn-command: 0
Для удаления всех объектов на всех серверах раздачи (полная очистка кэша) следует использовать команду delete со специальным параметром object=*. Шаблон запроса будет выглядеть следующим образом:
http://api.cdnvideo.ru:8888/0/delete?id=num_name&type=http&object=*
В реальном запросе в поле id должно быть указано значение выделенного вам идентификатора.
В течение последующего часа можно узнать статус выполнения команды с помощью command_status с параметрами id, и command_id — идентификатор полученный в заголовке при вызове delete. В заголовке X-cdn-comment возвращается статус выполнения задания: COMPLETED или RUNNING или UNKNOWN.
curl -v
‘http://api.cdnvideo.ru:8888/0/command_status?id=num_name&command_id=8ca1de3a-43b4-11e2-a9d5-00259006
bb2e’
< X-cdn-command: 0
< X-cdn-command-progress: COMPLETED

Для удаления объектов с QueryString все знаки ‘&’ после ‘?’ нужно заменить на ‘%26’.
Пример:

  • не сработает: curl -v ‘http://api.cdnvideo.ru:8888/0/delete?id=01_test&type=http&object=http://www.shop.test.ru/pictures/image.php?width=427&height=500&image=/upload/mediabank/619602-106/front_belyy.jpg’
  • сработает: curl -v ‘http://api.cdnvideo.ru:8888/0/delete?id=01_test&type=http&object=http://www.shop.test.ru/pictures/image.php?width=427%26height=500%26image=/upload/mediabank/619602-106/front_belyy.jpg’

Выгрузка логов статистики при помощи ПО get_lo.py

 (скачать скрипт)

Скрипту передаются аргументы (* — обязательные):
1. —account * (-a). Аккаунт пользователя.
2. —username * (-u). Юзернейм пользователя.
3. —password (-p). Пароль пользователя.
При отсутствии аргумента:

  • Пароль берется из переменной окружения «CDNVIDEO_PASSWORD».
  • Пароль запрашивается при выполнении скрипта.

4. —service * (-s). Определяет тип скачиваемого лога.
Возможные значения:

  • static. Только статические файлы (mp3, jpg, ..) В личном кабинете эти данные представлены в вкладке «Ускорение загрузки web-контента» («Web-content load acceleration»)
  • media. Только потоки (HLS, ..) В личном кабинете эти данные представлены во вкладке «Онлайн трансляции и видео по запросу» («Live streaming and VOD»)
  • all. Представляет собой static + media. В личном кабинете эти данные представлены в вкладке «Всего» («Total»)

5. —date * (-d). Определяет дату, за которую нужно скачать лог. Скачать лог можно в
точности до часа.

Внимание: параметр часа указывается в формате GMT.
Возможные значения:

  • 2013. Скачиваем лог за 2013 год
  • 2013-12. Скачиваем лог за декабрь 2013 года
  • 2013-12-23. Скачиваем лог за 23 декабря 2013 года
  • 2013-12-23-04. Скачиваем лог за 23 декабря 2013 года 4 утра по GMT

6. —progressbar (-pb). Вывод прогресса скачивания.
Внимание: для пользования данным функционалом потребуется установить дополнительный python модуль.
7. —file (-f). Вывод логов в файл $account_$date_$service.gz .
По умолчанию скрипт выдает поток сжатых логов в stdout.

Установка

  • Установить pip (пример установки на RHEL, CentOS, Fedora): sudo yum install
    python-pip
  • Установить библиотеку requests: pip install requests
  • Положить get_log.py в нужную директорию

Выполнение
ПО представляет собой простой консольный python-скрипт, принимающий различные аргументы (Подробнее в информации по архитектуре). На выход дает поток в формате gzip.
Возможные сценарии использования:
1. Скачиваем полный лог за 2014 год и архивируем его в файл account_2014_all.gz
python get_log.py -a account -u username -s all -d 2014 -f
2. Скачиваем лог по статическим файлам за декабрь 2013 года с выводом
прогрессбара, архивируем его в файл account_2013-12_static.gz
python get_log.py -a account -u username -s static -d 2013-12 -pb -f

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

Название поля Описание поля Пример
timestamp Дата и время в формате UNIX timestamp 1417135813.178
remote_addr IP-адрес пользователя 81.19.133.15
remote_user Служебное поле
time_local Дата и время в читаемом формате 28/Nov/2014:03:50:13 +0300
request Путь к файлу или видео потоку /live/smil:chanel1.smil/m_b1600000_126952.ts
status Статус ответа 200
body_bytes_sent Объём отправленных байт (без заголовка) 80840
out_bytes Объём отправленных байт (с заголовком) 81076
referrer Реферер, адрес источника http://www.site1.ru/
useragent Агент/браузер веб-пользователя Mozilla/5.0 (Windows NT 6.1; WOW64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/39.0.2171.65 Safari/537.36
http_x_forwarded_for Содержимое HTTP-заголовка
X-Forwarded-For, может
содержать оригинальные
IP-адреса пользователя
192.168.7.114, 192.168.0.205
host Имя хоста запроса site1.cdnvideo.ru
torso_id (служебное поле)
duration Длительность запроса или части
продолжающегося запроса в
секундах
0.616
upstream_response_time Время ответа проксируемого сервера 0.021
upstream_status Статус ответа ориджина (если запрос отдавался не из кэша) 200
country Код страны по ISO_3166-1 RU
service Тип услуги (static-«Ускорение
загрузки веб кнтента»,
media-«Онлайн трансляции и
видео по запросу»)
media
custom_field (опционально) некоторые дополнительные значения 193

 

Ошибки
1. «Error: A connection error occurred»
Возможные причины: Отсутствие интернета, проблемы с сетью. Упал сервер.
Что делать:
1. Убедиться, что у вас есть интернет (ping google.com)
2. Если не помогло, обратиться в службу поддержки

2. «Timeout: page connection timeout more than seconds: 5»
Возможные причины: Сервер не отвечает, проблемы с сетью
Что делать:
1. Проверить сетевое подключение.
2. Обратиться в службу поддержки.

3. «Error: Wrong username or password»
Возможные причины: Неверно введена пара логин/пароль (аргументы -u username, -p password )
Что делать:
1. Проверить, что аргументы username, password правильно заполнены.
2. Если ошибка остается, обратиться в службу поддержки.

4. «Error: account not found»
Возможные причины: Нет такого account для username.
Что делать:
1. Проверить, что аргумент -a account введен верно для username.
2. Если ошибка остается, обратиться в службу поддержки.

5. «Error: We don’t have any log for this date»
Причина: У нас нету лог-файла за данный период времени или по данному сервису
Что делать:
Так как новая функциональность скачивания лог-файла будет введена в середине сентября 2014 года, то и лог-файлы будут доступны только с этой даты и далее.

6. «Error: Problem with server/page down»
Возможные причины: Проблемы с сервером
Что делать:
1. Обратиться в службу поддержки

5.4 Генерация скриншотов

Базовые принципы

Сервис позволяет оперативно получать «моментальные снимки» (скриншоты) live-потока. Условия применимости сервиса:

  • только для трансляций в режиме реального времени (live);
  • live-поток предварительно опубликован в сети CDNvideo.

Скриншот представляет из себя статичное изображение в формате JPEG заранее определённого размера. Скриншоты формируются с заданной периодичностью (по умолчанию 1 минута). Может быть одновременно сформировано несколько скриншотов разного размера. Текущие скриншоты потока доступны для скачивания по HTTP, предоставляется постоянный URL для каждого размера. При остановке потока будет доступен последний зафиксированный скриншот.

Порядок действий при подключении

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

5.5 Транскодирование входного потока

Базовые принципы

CDNvideo предоставляет два сервиса транскодирования – «Транскодирование входного потока» и «Транскодирование выходных потоков», при необходимости эти два вида могут комбинироваться. Сервисы применимы только к live-потокам.

Транскодирование входного потока применяется в том случае, если у вас нет возможности отдать нам поток стандартными для нашей сети способами, описанными в разделах 4.1.2 и 4.1.3, то есть, не выполняются требования к кодированию потока и способам доставки. В этом случае мы берём на себя «нормализацию» потока, приведение его к виду, понятному нашим потоковым серверам. При этом попутно могут меняться и другие характеристики потока, такие, как битрейт и разрешение. После транскодирования поток транслируется в сторону конечных пользователей стандартными средствами нашей сети, описанными в разделе 4.1.4. Важное замечание – вы отдаёте один поток на вход и на выходе получаете тоже один поток.

Порядок действий при подключении

1. Сообщить нам URL live-потока.
2. Сообщить необходимые значения битрейта и разрешения потока после транскодирования (опционально; по умолчанию сохраняются исходные параметры).
3. Проверить показ трансляции на странице с тестовым плеером (URL страницы мы предоставим).
4. Настроить плеер, размещаемый на вашем сайте, на отображение потока через сеть CDNvideo.

5.6 Транскодирование выходных потоков

Базовые принципы

В нашей сети есть два сервиса транскодирования – «Транскодирование входного потока» и «Транскодирование выходных потоков», при необходимости эти два вида могут комбинироваться. Сервисы применимы только к live-потокам. Транскодирование выходных потоков – это преобразование одного входного live-потока в несколько выходных потоков с разным битрейтом и разрешением. При этом упорядочиваются ключевые кадры (key frames) в потоках, что позволяет плавно переключаться между битрейтами в плеере (автоматически в адаптивном режиме или вручную).
Важное замечание – в большинстве случаев один поток на входе преобразуется в несколько потоков с разным битрейтом на выходе. Тем не менее, можно использовать сервис для транскодирования по схеме «один в один», с одним потоком на выходе.

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

  • только для трансляций в режиме реального времени (live);
  • видеокодек входного потока – H.264;
  • аудиокодек входного потока – AAC или MP3;
  • убликация потока стандартными для нашей сети способами – RTMP, RTSP, MPEG_TS-publish.

Доступные протоколы вещания в сторону конечных пользователей:

  • RTMP/RTMPT;
  • RTSP;
  • Apple HLS;
  • Microsoft Smooth Streaming – MSS;
  • MPEG-DASH.

Внимание: протокол Adobe HDS для вещания в нескольких битрейтах не поддерживается.
Для протоколов HLS, MSS и MPEG-DASH сервис позволяет не просто создавать набор потоков с разным битрейтом, но и объединять эти потоки манифест-файлом, то есть получить на выходе готовое решение для адаптивного вещания.

Порядок действий при подключении

Опубликовать оригинальный поток.
2. Определиться с протоколами вещания в сторону конечных пользователей.
3. Соообщить требуемые параметры выходных потоков — битрейт, разрешение, профиль кодека H.264.
4. Проверить показ трансляции на странице с тестовым плеером (URL страницы мы предоставим).
5. Настроить плеер, размещаемый на вашем сайте, на отображение потоков через сеть CDNvideo.

5.7 Навигация по эфиру (DVR)

Базовые принципы

Смысл сервиса — постоянная запись live-потока в рамках определённого временно́госкользящего окна с возможностью навигации в рамках этого окна. Размер окна называется глубиной DVR. Окно постоянно «скользит», то есть при глубине DVR, равной 2-м часам, «отмотать» назад в плеере удастся максимум на 2 часа от текущего момента.

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

  • только для live-трансляций;
  • видеокодек входного потока – H.264;
  • аудиокодек входного потока – AAC или MP3;
  • поток опубликован по схеме RTMP-publish или RTMP-pull.

Для нормальной работы сервиса публикуемый поток должен быть упорядочен по ключевым кадрам (key frames), а именно:

  • интервал между ключевыми кадрами должен быть фиксированным;
  • интервал между ключевыми кадрами должен быть небольшим (1-2 секунды).

Для вещания в сторону конечных пользователей поддерживаются только HTTP-based протоколы:

  • Adobe HDS;
  • Apple HLS;
  • Microsoft Smooth Streaming (MSS);
  • MPEG-DASH.

Cтриминговые протоколы RTMP и RTSP не поддерживаются.
Доступные модели вещания с поддержкой DVR:
1. Вещание в одном битрейте. Публикуется один поток.
2. Вещание в нескольких битрейтах, с возможностью переключения между ними. Каждый битрейт публикуется отдельным потоком. Переключение между битрейтами вручную или автоматически, в зависимости от реализации плеера.
3. Вещание в нескольких битрейтах, с возможностью переключения между ними.
Вариант реализуется за счёт использования сервиса «Транскодирование выходных потоков», описанного в разделе 5.6. Публикуется один поток в высоком качестве, который на выходе преобразуется в несколько потоков с разными битрейтами. Переключение между битрейтами вручную или автоматически, в зависимости от реализации плеера. Действуют ограничения, описанные в разделе 5.6 – не поддерживается протокол HDS при вещании в нескольких битрейтах.

Глубина DVR должна быть разумной. Теоретический предел – 30 часов, но чем больше глубина – тем больше плейлист с описанием всех фрагментов в скользящем «окне», при этом плейлист скачивается раз в несколько секунд. Оптимальная глубина – 1-4 часа; приемлемая – до 10 часов; сомнительно – 10-12 часов; больше 12 часов – необходимо предварительное тестирование, нормальная работа не гарантируется.

В рамках предоставления сервиса доступно две стратегии записи DVR:

  • append. В случае остановки потока DVR-контент не удаляется. При возобновлении потока контент бесшовно добавляется к ранее записанному.
  • delete. В случае остановки потока более, чем на 5 минут, записанный DVR-контент удаляется. При возобновлении потока запись DVR начинается заново.

Порядок действий при подключении

1. Опубликовать поток (потоки) по алгоритму, описанному в разделе 4.1.5.
2. Сообщить нам следующие данные:

  • имя потока (потоков);
  • требуемую глубину DVR;
  • выбранную стратегию записи;
  • протоколы вещания в сторону конечных пользователей.

3. Проверить показ трансляции на странице с тестовым плеером, URL страницы мы предоставим.
4. Настроить плеер на запрос потоков через сеть CDNvideo.

6. Техническая поддержка

В случае технических проблем обращайтесь в службу технической поддержки:

  • по телефону +7 (499) 502 42 29
  • по электронной почте на адрес support@cdnvideo.ru

При обращении сообщите название организации и/или номер договора, ФИО и контактный телефон сотрудника, передавшего сообщение, описание проблемы и иную информацию, имеющую отношение к проблеме. Время реакции на заявку составляет:

  • 4 часа для заявок, оставленных по телефону;
  • 12 часов для заявок, отправленных по электронной почте.

Печать
Попробовать бесплатно