Создавая сервис видеотрансляций, рано или поздно, при увеличении числа потребителей контента, возникает вопрос о масштабировании и доставке. Вы столкнетесь с проблемой не только вычислительных мощностей, но и пропускной способности вашей сети.
Большинство современных решений основаны на распределении статических видеочанков через HTTP-серверы (DASH, HLS), так как такие данные легко кэшируются, что позволяет масштабировать их распространение. При этом могут быть использованы уже существующие сети доставки контента (CDN).
Узкие горлышки частных сетей
На схеме видно, как контент распространяется с учетом географических особенностей, разгружая инфраструктуру видеосервиса.
Однако, к сожалению, CDN не способны решить проблемы "последней мили". Представим ситуацию, когда несколько пользователей из одной локальной сети смотрят трансляцию, каждый обращается к EDGE серверу, создавая нагрузку на пропускную способность сети. При достаточном числе таких зрителей они могут перегрузить канал, и никто больше не сможет просматривать контент. Обратите внимание, что при этом каждый из них получает один и тот же контент, но для каждого отдельно.
Локальные кэш-сервера
Для решения проблемы узкого горлышка необходимо установить внутри сети единого получателя трансляции, который будет выступать ретранслятором.
Можно разместить локальные кэш-сервера в наиболее ответственных сетях.
P2P
Но очевидно, что невозможно разместить кэш-сервер во всех частных сетях мира. Однако, что если только один из участников будет получать трансляцию извне сети и передавать её остальным внутри? Такой подход называется Peer-to-Peer сетью или eCDN.
Решения на рынке
eCDN подход уже неплохо себя зарекомендовал и имеет несколько успешных реализаций различными компаниями. Вот некоторые из них:
Как устроены
Практически все решения представляют из себя набор плагинов для основных библиотек видеоплееров (video.js, hls.js, dash.js, shaka и т.д.).
В основе решений используется технология webrtc. Эта технология предназначена для прямого P2P подключения двух пользователей между собой и поддерживается всеми современными браузерами.
Как работает webrtc
Чтобы подключить двух клиентов через интернет необходимо построить маршрут. Для этой задачи используется STUN-сервер, который помогает преодолеть NAT и установить маршрут от внешнего порта и IP-адреса до локального порта и IP-адреса. Такой маршрут называется набором ICE-кандидатов. Далее эти ICE-кандидаты должны быть переданы противоположному пиру для установки соединения, для этого, как правило, используется дополнительный сигнальный сервис.
Серверная часть
Архитектура может различаться, и некоторые сервера бизнес-логики могут объединять функции нижеперечисленных сущностей.
Авторизатор
Авторизует пользователей в сети и предоставляет им первоначальные параметры.
Сворм сервер
Управляет сетью, владеет информацией о всех узлах сети и определяет её структуру, принимает решения о том, какой пир будет подключен к какому.
STUN
Вспомогательный сервис для установления соединения по WebRTC, помогает пирам собрать свои ICE-кандидаты.
Сигналер
Необходим для обмена сообщениями между пирами при установке соединения по WebRTC.
Сервис сбора статистики
Используется для анализа работы сети и тарификации.
Топология сети - каждый к каждому
За основу взяты принципы, лежащие в основе архитектуры протокола BitTorrent. Сервер Swarm пытается установить как можно больше соединений от каждого пира к каждому, учитывая ограничение на количество подключений к одному пиру (обычно несколько десятков), и отбрасывая неудачные попытки соединения в черный список.
Алгоритм
1. Регистрация
Первым делом новый пир регистрируется на сервере авторизации, предоставляя всю необходимую информацию и получая первоначальные параметры.
2. Получение списка пиров
После регистрации пир получает от сервера список пиров-кандидатов для подключения.
3. Подключение ко всем доступным пирам
Далее, пир пытается установить соединение с каждым кандидатом из списка с помощью STUN сервера и сигнализатора.
4. Распространение чанков в сети
Обмен сообщениями и передача чанков между пирами осуществляются через webrtc data channel.
После загрузки чанка с CDN, аналогично BitTorrent, пир сообщает всем подключенным участникам о его наличии в своей памяти.
Получив уведомление о наличии чанка, пиры по мере необходимости запрашивают его. Если никто из сети не сообщил о наличии чанка, пир загружает его с CDN. Таким образом, HTTP запросы чанков плеером, по возможности, заменяются webrtc запросами к другим пирам сети.
Недостатки
Данные решения, в первую очередь, направлены на снижение нагрузки и затрат на CDN.
Пиры в одной P2P сети не обязательно находятся в одной локальной сети, следовательно, проблема узкого горлышка не решена.
Подход с получением чанков из сети по запросу больше подходит для VOD, в то время как прямые трансляции не могут иметь задержку менее 6 секунд.
Как видно выше, для управления такой сетью требуется специальный высоконагруженный сервер, который управляет логикой всех подключений в сети.
Собственное решение
Наше решение не предназначено для интеграции в сторонние сервисы и не ставит своей целью экономию или извлечение средств, а скорее направлено на повышение надежности. Это означает, что мы должны эффективно использовать вычислительные ресурсы и интегрироваться в существующую инфраструктуру.
Сбор информации о пирах и создание карты сети для P2P осуществляется сервисом сбора статистики, поскольку он уже обладает всей необходимой информацией.
Самое ресурсоемкое действие - это расчет структуры сети и определение поведения для каждого пира. Обычно этим занимается централизованный сервер. Представьте, сколько ресурсов требуется для онлайн-обработки сетей из нескольких тысяч, а иногда и десятков тысяч пиров. Благодаря ограничению наших P2P сетей рамками локальных сетей, мы смогли обеспечить каждого пира актуальной картиной своей сети. Это позволило отказаться от централизованного сервера и поручить пирам принятие решений о своем поведении и связанные с этим вычисления.
Топология сети - дерево
В нашем подходе используется структура дерева подключений, что усложняет реализацию, однако обеспечивает более высокий уровень контроля, снижает нагрузку и уменьшает паразитный трафик на узлах сети.
Алгоритм
1. Отправка статистики
Каждый зритель трансляции, независимо от того, является ли он участником P2P, отправляет о себе статистику, достаточную для участия в P2P.
2. Определение своей сети и необходимости участия в P2P
Сбор ICE candidates
Для определения того, в какой локальной сети находится потенциальный пир, необходимо воспользоваться STUN-сервером и собрать список ICE-кандидатов.
Определение типа кэша
Иногда внутри сети располагается локальный кеш. В таких случаях нет необходимости использовать P2P-сеть. Для определения, за каким кешем сейчас находится пир, скачивается специальный файл, из заголовков которого понятно, отдал ли его локальный кэш или нет.
Данные полученные при скачивании этого служебного файла могут быть полезны и для других функций, например для ABR.
3. Подписка на список пиров внутри своей сети
Поскольку принятие решений о собственном поведении возложено на сами пиры, им необходимо иметь актуальное представление о сети. Для этого пир подписывается на все изменения внутри сети.
Эти данные являются общими для всех участников сети и могут быть закешированы.
4. Определение необходимости поиска источника в P2P
Критериями, побуждающими пир искать новый источник внутри сети, являются наличие других участников (потенциальных источников) и низкая скорость получения через CDN (текущего источника).
Наличие в сети других пиров
Если в сети отсутствуют другие участники, нет смысла запускать алгоритм поиска лучшего кандидата для подключения.
Замер скорости
Нет смысла искать новый источник, если текущий удовлетворяет потребностям. В качестве такого критерия используется не скорость напрямую, а зависимо от типа текущего источника разные показатели:
• При получении с CDN оценивается отклонение от целевой задержки.
• При получении из P2P оценивается время на прохождение пингов (меньше 10 мс - хорошо, больше 50 мс - плохо).
5. Выбор подходящего пира для подключения
При отборе кандидатов для подключения среди пиров сети используется несколько критериев в качестве фильтра:
Это другой пир
Необходимо исключить себя из кандидатов на подключение.
Есть свободные слоты
Убеждаемся, что у кандидата есть свободные слоты для новых подключений.
Мы используем ограничение дочерних пиров до трех.
Не отмечен ранее как плохой
Проверяем, чтобы кандидат не был ранее отмечен как неподходящий.
Быстрее
Убеждаемся, что скорость подключения не ниже, чем у текущего узла.
Не глубже в структуре дерева подключений
Каждый пир должен стремится расположится в иерархии подключений как можно ближе к CDN и находиться на минимальной доступной глубине.
Нет в цепочке родительских и дочерних пиров
Исключаем кандидата, если он находится в цепочке родительских или дочерних пиров, чтобы избежать образования замкнутых колец.
Не в кольце
В некоторых случаях, из-за асинхронной природы структуры дерева сети, на непродолжительное время, все же, могут образовываться замкнутые кольца, на этот счет производится дополнительная проверка.
Проверяется количество пиров в цепочке родителей, если глубина превышает лимит, делается вывод о закольцованности.
6. Подключение
Как только пир получает отобранный список кандидатов для подключения, производятся попытки установить эти соединения.
Типы подключения
При P2P подключении есть две стороны: ретранслирующая стрим и получающая сторона.
Receiver
Пир, получающий стрим, называется Receiver. Receiver может иметь до трех активных подключений разных типов.
• Основное подключение - активное соединение, через которое пир получает стрим.
• Резервное подключение - в случае разрыва основного соединения пир начинает получать стрим через резервное подключение.
• Тестовое подключение - при подключении к новому кандидату измеряются его характеристики, результаты сравниваются с основным и резервным соединениями; в случае положительного результата он заменяет собой текущее соединение.
Relay
Пир, который ретранслирует стрим, называется Relay. Получив запрос на подключение от ресивера, релей проверяет наличие свободных слотов. Каждый релей может иметь не более трех активных подключений от ресиверов.
Сигналинг для подключения
Значительную нагрузку на сервера БЛ создает взаимодействие между пирами, поэтому необходимая сигнализация для подключения сведена к минимуму.
Минимальный набор данных для подключения
При установке WebRTC соединения пиры обмениваются записями SDP (Session Description Protocol), содержащими описание сессии, включающее следующие данные:
Описание сессии
Открытый ключ шифрования
ICE кандидаты
Описание медиа секций
Поскольку мы контролируем обоих участников соединения, можно не передавать большую часть этих данных, а генерировать SDP по шаблону. К уникальным данным для соединения можно отнести только два пункта: ключ шифрования и набор ICE кандидатов.
Предварительная генерация сертификата
Обычно браузер для каждого соединения WebRTC генерирует новый сертификат и размещает его открытый ключ в SDP. Однако можно заранее сгенерировать сертификат и использовать его во всех последующих подключениях. Таким образом, открытый ключ становится общедоступным параметром, который нет необходимости передавать через сигналинг.
Нужны только ICE кандидаты
К сожалению, нельзя использовать предварительно сгенерированные ICE кандидаты, так как порты для подключения уникальны для каждого подключения.
Сигналинг через dataChannel
Таким образом, собранный из шаблона исходный SDP содержит только одну медиа-секцию для передачи данных (dataChannel). Все последующее взаимодействие между пирами, включая сигнализацию для пересогласования SDP и добавления новых медиа-секций (аудио, видео), производится через этот канал.
Способы передачи данных
WebRTC предоставляет возможность передавать потоковое медиа разных типов - аудио, видео, данные. Это дает нам некоторую вариативность в способах передачи потока.
Передача стрима через dataChannel
Такой подход основан на подмене HTTP запросов плеера и их перенаправлении в P2P сеть. Содержимое чанков в виде ArrayBuffer передается через dataChannel и используется в качестве ответа на HTTP запросы плеера. Это позволяет плавно переключаться между источниками, получая чанки от любого из пиров или от CDN, в случае необходимости, незаметно для зрителя. Однако, у этого способа есть особенности и недостатки. Необходима проверка целостности и подмены чанка, необходимо иметь контрольную сумму чанка и сверять ее при получении из P2P. Есть некоторые осложнения, связанные с ABR: пиры могут просматривать трансляцию в разных качествах, технически это разные видео с разными файлами чанков. Эту проблему можно решить различными способами, например:
Использование разных сетей для разных вариантов качества может привести к необходимости смены сети при изменении качества, что приведет к дополнительным расходам. Кроме того, каждая дополнительная сеть увеличивает нагрузку на канал.
Можно использовать чанки пира источника в любом доступном качестве, подменять чанки в своем качестве. Но это может вызвать недоумение у пользователя, который ожидает определенного качества, но получает другое.
Можно ограничить выбор качества для пользователя во время получения данных из P2P сети, используя строгое качество пира источника.
Еще одной проблемой может быть игнорирование перегрузки локальной сети. Между двумя пирами качество видео не адаптируется для компенсации падения скорости внутри сети.
Передача стрима через аудио и видео медиа секции
При данном подходе необходимо пересогласовывать SDP для каждого нового медиастрима с новыми видео и аудио медиасекциями. Однако, остальную работу по управлению потоками данных WebRTC берет на себя, включая адаптацию качества для устранения проседания скорости в сети. В связи с этим пользователю временно приходится лишить возможности выбора качества вручную при получении данных из P2P сети. К недостаткам такого подхода можно отнести переключение между источниками через небольшой фриз.
Симулятор
Для отладки алгоритма построения топологии таких сложных сетей нельзя обойтись без симуляции. Мы создали отдельную программу, которая эмулирует поведение заданного количества пиров в сети с учетом заданных параметров. Сеть может состоять от одного до сотен тысяч пиров с меняющимися параметрами скорости, обрывов, выходов и входов и т.д.
Мониторинг и анализ
Сбор статистики
Для функционирования сети, при сборе статистики с пользователей, мы опираемся на следующие метрики:
Информация о локальной сети
Наличие в сети локального кеша
Глубина в дереве подключений
К каким пирам подключен
Откуда получает данные (P2P или CDN)
Скорость получения
Скорость отдачи данных другим пирам
Визуализация сети
Для отладки и контроля не обойтись без инструмента, который бы визуализировал сеть в онлайн режиме.
Выводы
Распространение видео через пиринговые сети ECDN представляет собой эффективный и экономичный подход к инфраструктуре, позволяющий значительно снизить затраты на передачу данных. Этот метод особенно полезен при проведении крупномасштабных мероприятий, таких как чемпионат мира по футболу, когда необходимо обеспечить быструю и надежную трансляцию контента большому количеству зрителей.
В нашем случае, применение данной технологии решает конкретную и узконаправленную задачу, оптимизируя процесс передачи видеосигнала и обеспечивая высокое качество стриминга внутри локальных сетей.
Потенциал
Прогресс в области сетевых технологий приводит к постоянному обновлению и увеличению пропускной способности. Однако, этот процесс происходит неравномерно, что вынуждает ориентироваться на большинство существующих сетей. В то же время, требования к качеству и размерам видеоконтента продолжают расти.
Появление и внедрение новых стандартов связи, таких как 5G и 6G, а также спутниковый интернет и рост производительности устройств, могут вывести актуальность P2P-сетей на новый уровень.
