Как P2P снижает пропускную способность видео в реальном времени на 75%?

задний план

Прямая трансляция в реальном времени стала стандартной технологией для интернет-приложений после прошлогодней «Войны тысяч вещателей», но стоимость платформ прямого вещания остается высокой. , часть стоимости.

На данном этапе технология прямого эфира делится на две части с точки зрения передачи:CDN и система Lianmai, CDN отвечает за распространение и передачу потокового мультимедиа, а система Lianmai отвечает за решение проблемы передачи связи в реальном времени одновременного взаимодействия между несколькими якорями. Мы всегда считаем, что технология прямого вещания, основанная на системе CDN + Lianmai, является технологией с высокими затратами и высоким потреблением, что подтверждается потерей основных платформ прямого вещания. В дополнение к стоимости полосы пропускания проблема задержки также является недостатком современной технологии прямого вещания. Мы очень рано поняли, что эта традиционная технология прямого вещания не может осуществлять крупномасштабную интерактивную прямую трансляцию онлайн-образования, поэтому Xuebajun начала разрабатывать интерактивную систему прямого вещания на основе технологий UDP и P2P со второй половины 2016 года. Целями проектирования всей системы являются:

Сквозная задержка контролируется в течение нескольких секунд.
Делайте все возможное, чтобы сохранить пропускную способность канала распределения без ущерба для качества видео.

Вся архитектура дистрибуции, основанная на технологии P2P, тестировалась и оптимизировалась на платформе прямых трансляций мощностью 10 Вт+ в течение 9 месяцев, и изначально цель проекта была достигнута. Как устроена вся система? Какие технологии использовались для достижения целей? Далее я сосредоточусь на том, чтобы поделиться архитектурным дизайном и техническими деталями.

Архитектура распределительной сети P2P

В сети передачи и распределения мы объединяем систему Lianmai и систему распределения в одну и используем распределенную потоковую передачу и распределение граничных узлов в качестве набора систем передачи и добиваемся минимальной задержки Lianmai за счет связи P2P и маршрутизации между службами. , структура следующая:

Вся распределительная сеть передачи делится на три части:Потоковая часть, P2P между сервисами и клиентским узлом P2P. Эта сеть передачи имеет системную привязку: при условии, что динамик-толкатель передает данные на пограничный сервер без потери пакетов и задержки, пограничный сервер быстро распределяет полученные потоковые данные на другие пограничные серверы через межсервисный P2P. потеря пакетов во время этого процесса. Зачем нужен такой якорь? Поскольку сеть P2P на клиентском узле должна обеспечивать плавность и минимальную задержку, то есть все пограничные серверы должны иметь полные данные в кратчайшие сроки, Что касается того, почему это необходимо, мы сосредоточимся на разделе компенсации потока позже. .

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

фрагментация медиаданных

Фрагментация медиаданных является самой основной частью всей системы распределения и передачи.Мы в основном учитываем задержку и потребление при проектировании фрагментации.Если фрагментация слишком велика, задержка передачи будет выше, например, HLS;Если фрагментация слишком отлично, в сети будет много пакетов обратной связи, а лишнее потребление — тоже проблема для P2P-сети. Наконец, мы опираемся на опыт RTP и FLV, используяФрагментация данных по кадрам, который имеет следующие преимущества:

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

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

Push Streaming и Lianmai

После подтверждения шардинга медиа можем пушить поток.Пути проталкивания и распространения объединяются в один, пользователь отправляет сегмент потоковых данных на ближайший к нему пограничный сервер, а не на выделенную подключенную микрофонную систему. Мы используем алгоритм передачи RUDP для потоковой передачи.Этот RUDP использует алгоритм перегрузки, аналогичный BBR, основанный на задержке и потере пакетов, а пакет перегружается и отбрасывается.Схема выглядит следующим образом:

Подробнее о RUDP читайте в другой моей статье "Как сделать ненадежный UDP надежным?". А почему бы и нет RTP или RTMP/TCP для передачи потока, потому что, хотя RTP основан на UDP, он должен использовать RTCP и NACK для обеспечения надежности, должен разработать алгоритм перегрузки, а также должен преобразовать и расширить RTP, а также ограничен сам протокол RTP, поэтому мы не принимали RTP напрямую. Использовать RTMP/TCP для проектирования очень просто, но в слабой сетевой среде задержка очень велика, и легко вызвать переподключение, поэтому в начале проектирования он был отклонен.

P2P между серверами

Поскольку вся сеть распределения передачи является распределенной и состоит из нескольких пограничных серверов, в зависимости от привязки системы медиаданные, сегментированные на пограничный сервер, должны быть распределены на другие пограничные серверы как можно скорее. В самом начале мы использовали сервер BGP для передачи, который потребляет большую полосу пропускания BGP, и как только сервер BGP выйдет из строя, связь между всеми пограничными серверами будет прервана. На самом деле, в большинстве случаев задержка между пограничными серверами у разных операторов не так велика, как предполагалось, что можно считатьИспользуйте одноранговую связь между пограничными серверами для решения проблемы., поэтому мы проектируем Модель безоконной многопутевой передачи RUDP используется для связи между пограничными серверами, как показано на следующем рисунке:

Модель связи на рисунке выше представляет собой модель параллельной связи с несколькими путями. Мы добавляем таблицу маршрутизации путей перед отправкой RUDP. В этой таблице маршрутизации записывается вероятность распределения каждого пути. Каждый раз, когда RUDP отправляет пакет на принимающую сторону, он будет проходить через таблицу маршрутизации.вероятность выбора пути. Поэтому определение вероятности таблицы маршрутизации — очень важная вещь. Мы получаем состояние сети (потеря пакетов, задержка, джиттер) посредством обратной связи ACK в режиме реального времени RUDP и обнаружения ping в реальном времени пути, а затем вводим параметры состояния сети в функцию аппроксимации f(x), чтобы определить вероятность каждого маршрута. Здесь действует принцип: если задержка и потеря пакетов прямого соединения между пограничными серверами достаточно малы, то вероятность прямого маршрута связи будет близка к 100%, если маршрут периодически отключается или задержка превышает 200 мс, ее вероятность будет близка к 0. Ниже приведена схема всего процесса оценки вероятности маршрутизации:

Процесс построения P2P сети

Данные медиапотока достигают каждого пограничного сервера через многоканальную сеть передачи P2P между пограничными серверами.Далее каждому пограничному серверу необходимо распределить данные потока на каждый клиентский узел.Задержка меньше, и процесс аналогичен обычному Модель связи RTC, поэтому я не буду здесь вдаваться в подробности. Распределение на узле просмотра использует самоорганизующуюся сеть P2P.Поскольку оно распространяется через P2P, сеть P2P должна быть построена в группе клиентских узлов.Как построена эта сеть? Он разделен на три шага:Подключайте, оценивайте, наслаивайте.

соединять

Программа клиентского узла выполняется на клиенте. Большинство клиентских узлов находятся за маршрутизаторами или NAT. Чтобы установить соединения между ними, они должны проходить через NAT и брандмауэры друг друга. Хотя есть много способов обхода NAT, таких как STUN, ICE и т. д.,подключение обхода всегда является проблемой, если скорость обхода слишком низкая, многие высококачественные ресурсы узла не будут использоваться полностью. При проектировании схемы обхода мы поставили скорость прямого соединения на первое место, а механизм обхода разработали на основе множественных догадок и попыток порта, модифицировав протокол STUN. Во-первых, определить тип NAT, правило изменения порта NAT, NAT через аналогичный протокол STUN Есть ли такая информация, как механизм черного списка, а затем хранить эту информацию на пограничном сервере в соединении юрисдикции. Когда партнерский узел приходит, чтобы пройти его, он будет обмениваться этой информацией друг с другом. Различные перестановки и комбинации будут иметь разный обход Процесс и результаты обхода будут записываться в нашу фоновую базу данных, и мы будем периодически анализировать эти данные и корректировать согласованную стратегию обхода. Как показано ниже:

После завершения обхода между узлами будет выполнено рукопожатие соединения и аутентификация сертификата идентичности (причина сертификата будет подробно обсуждена позже), и будут установлены канал связи и отношения соседства. Так как же динамически меняются отношения соседей?

Соседские отношения и оценка

соседская проблема

Как только соединение установлено, узлы становятся соседями, и они будут обмениваться состоянием и сердцебиением друг с другом.Тогда возникает проблема.В системе прямого вещания участвуют тысячи узлов.Если все они подключены попарно, оптическая связь пульса can Полоса пропускания загрузки клиентского узла заполнена. Мы разработали связанный список исключения LRU узлов. В связанном списке 40 подключенных соседних узлов. Старые узлы будут выходить, а новые узлы присоединятся. LRU будет добавлять и удалять LRU в соответствии со статусом связи между соседями и самим собой. Принципы таковы. следующим образом:

По принципу близости предпочтительнее интрасеть, второй сетью одного оператора в том же городе.
Периодически оценивайте задержку и частоту попаданий медиа-осколков, и последнее место будет устранено.
Когда в списке LRU менее 40 узлов, новый узел будет выбран из списка резервных узлов для подключения и присоединения к LRU.

Оценка узла

Вычислительная мощность, коммуникационные возможности и сетевой раздел каждого клиентского узла различны, что заставляет нас проводить оценку для каждого узла.Оценка узла делится на две части:Соседний узел оценивает самого себяа такжесамооценка. Оценки соседства в основном:

RTT
Скорость потери пакетов
процент попаданий по запросу

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

Оцените себя по следующим пунктам:

процессор, память
Тип сети: WIFI/4G/проводная сеть
пропускная способность загрузки

Узлы будут периодически вычислять эти два типа параметров и использовать сетевую функцию конвергенции QOS f(x) для расчета возможностей узла и политик соседнего QOS.

Узел иерархии

Конечной целью оценки узлов является превращение способных узлов в суперузлы, чтобы разделить давление распределения пограничного сервера. Итак, каковы условия для того, чтобы узел стал суперузлом? Есть следующие условия:

При достаточной пропускной способности загрузки он не может стать суперузлом при 4G и слабом WIFI.
Младшие мобильные устройства с недостаточной вычислительной мощностью не могут стать суперузлами с запасным процессором и памятью.
Удобство общения с соседями, а не островок общения.
Получите назначение пограничного сервера, и связь с пограничным сервером будет гладкой.

Что, если производительность суперузла снизится? Ответ заключается в том, что он выродится в обычный узел, потому что оценка узла выполняется периодически в режиме реального времени.Если производительность узла ухудшится, пограничный сервер ухудшит его.

Теперь, когда назначен суперузел, как он работает? Каждому суперузлу будет присвоен идентификатор группы при его назначении, а пограничный сервер будет сгруппирован в соответствии с количеством суперузлов в его собственной юрисдикции.Каждая группа состоит из нескольких суперузлов, и суперузлы в группе несут ответственность для распространения собственных сгруппированных медиа-осколков. Например: имеется 5 групп суперузлов, а в единичном цикле имеется от 1 до 20 сегментов, тогда первая группа отвечает за распределение сегментов с номерами 1, 6, 11, 16 и т. д., вторая группа — отвечает за 2, 7, 12, 17... Это сделано для предотвращения выхода из строя одного суперузла и повышения стабильности P2P-распределения. Схематическая диаграмма выглядит следующим образом:

Процесс распространения потокового мультимедиа P2P

Благодаря описанному выше процессу построения сети P2P мы знаем, что вся сеть P2P на самом деле представляет собойИерархический ориентированный графРаспределительная сеть, то как работает потоковое распространение данных? Также в три шага:Сначала толкни, потом потяни (потяни), потом компенсируй, ниже приводится подробное объяснение того, как это достигается.

push

При введении суперузла было упомянуто, что данные будут отправлены в соответствующую группу суперузлов в соответствии с идентификатором сегмента.Как суперузел обрабатывает эти сегменты после их получения? В соответствии с принципом построения P2P данные должны пересылаться на суперузлы или обычные узлы других групп, но если они передаются таким образом, это может привести к избыточности передачи по сети и потреблению слишком большой полосы пропускания.

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

Из приведенного выше рисунка можно увидеть следующие принципы:

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

pull

Сегмент данных проталкивается на каждый клиентский узел с помощью предварительной подписки, но сеть будет терять пакеты, а суперузел может выйти на полпути, что приведет к потере пакетов конечным узлом Что делать, если пакеты потеряны ? Мы разрабатываем механизм для извлечения недостающих осколков у соседей, общий процесс выглядит следующим образом:

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

Весь шаг будет периодически пытаться тянуть несколько раз.Схема выглядит следующим образом:

Это стоит упомянуть здесь, потому что информация о сплетнях в буфере будет периодически обмениваться, а это означает, что чем меньше информация о сплетнях в буфере, тем лучше Мы разработали аналогичный фильтр Блума для описания информации о сплетнях, который может не только уменьшить сплетни размер данных и скорость сравнения также очень быстро.

компенсировать

Поскольку клиентский узел P2P нестабилен, возможно, что сегмент не был получен после многократного извлечения, и сегмент близок к позиции воспроизведения, поэтому узел, пропустивший этот сегмент, будет напрямую запрашивать компенсацию с пограничного сервера. чтобы позволить ему передать этот сегмент как можно скорее.Фрагментация, цель этого состоит в том, чтобы предотвратить потерю пакетов, вызванную связью P2P. Это означает, что каждый пограничный сервер должен владеть всеми данными сегментов, что является точкой привязки системы. Процесс выглядит следующим образом:

В большинстве случаев с этим процессом проблем не возникает, но если у большинства клиентских узлов одновременно отсутствует несколько сегментов сегмента, к пограничному серверу будет поступать большое количество компенсационных запросов, что вызовет сетевые штормы. В ответ на эту проблему мы разработалиМеханизмы оценки дефицита и отказа в обслуживании. Этот механизм означает, что, когда на пограничный сервер поступает слишком много запросов на компенсацию в единицу времени, пограничный сервер будет отклонять запросы, превышающие его собственные возможности, и повторно отправлять только фрагменты в пределах емкости. Кроме того, этот процесс также проведет оценку дефицита по запросу компенсации.Если у большинства узлов в сегменте его нет, он возьмет на себя инициативу передать сегмент. Группа суперузлов снова отправляет запрос.

Буферный буфер и управление задержкой

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

Ниже поясняется значение каждого интервала на приведенном выше рисунке:

интервал нажатия: Поскольку осколки проталкиваются через разные суперузлы, это неизбежно вызовет определенное количество джиттера, поэтому в начале буфера будет стадия буфера дрожания, пока информация о сплетнях первого соседнего узла не получит этот сегмент. , и этот этап обычно длится 100 ~ 300 мс.
интервал вытягивания: после того, как время осколка войдет в интервал вытягивания, потерянные осколки будут периодически проверяться, а вытягивание будет взвешиваться в соответствии с соседями, освоившими сплетни, и будет сделано 3 попытки.Время каждой попытки - это значение RTT между локальный узел и сосед. Если он выйдет из строя 3 раза, он войдет в зону компенсации.
Интервал компенсации: после того, как время сегмента войдет в интервал компенсации, он также будет периодически проверять потерянные сегменты и напрямую запрашивать пограничный сервер для извлечения на основе потерянного идентификатора сегмента, и пытаться 4 раза, каждый раз это время между локальным узлом и Пограничный сервер RTT. Если 4 выйдет из строя, он будет находиться в состоянии ожидания, ожидая, пока соседний сплетник или пограничный сервер активно подтолкнет.
Интервал экспирации: после воспроизведения сегмент будет помещен в этот интервал истечения срока действия, а не сразу удален.Почему? Поскольку время воспроизведения каждого узла отличается, возможно, что локально воспроизводимый осколок — это осколок, потерянный другими узлами, и возможно, что другие узлы вытащат его через pull, поэтому мы поместим воспроизведенный осколок в истечение срока действия. интервал Удалить через 3 секунды.

Откройте проблему за секунды

Вышеупомянутые три этапа распределения и управления буфером решают проблему непрерывного распределения потока и управления задержкой воспроизведения, но на этом этапе все технологии прямого вещания должны иметь секунды на открытие. решение проблемы секунд, чтобы открыть Просто. Miaokai означает, что пользователи могут мгновенно увидеть видеоизображение хоста, когда они входят в комнату прямой трансляции.Цель Miaokai заключается в том, что вновь введенный клиентский узел требует, чтобы пограничный узел сервера отправлял данные из предыдущего ключевого кадра GOP видео, Затем клиентский узел кодирует видео в соответствии с видео.Нулевой процессор ожидает ускоренного воспроизведения из этого ключевого кадра GOP. Наш вновь вошедший узел в распределительную сеть P2P получит идентификатор фрагмента последнего ключевого кадра GOP пограничного сервера, и клиентский узел будет использовать этот ID быстро извлекает все данные шарда GOP от каждого соседа вместо того, чтобы просто позволить пограничному серверу отправить их, а скорость открытия в секундах сокращается в среднем на 100 миллисекунд.

Лицензирование контента P2P

В дополнение к передаче и распространению, технология распространения в реальном времени также должна учитывать защиту от кражи контента и авторизацию, а системная безопасность должна больше учитываться в системах P2P. Мы вводим сертификат CA и схему шифрования с двусторонним согласованием для обеспечения легитимности ссылки. Общий подход заключается в том, что каждый легальный узел узла (пограничный сервер и все клиентские узлы) инициирует юридическую проверку в ЦС. Если проверка пройдена, ЦС проверит проверку в соответствии с идентификатором узла, открытым ключом узла RSA, авторизацией время начала и завершения авторизации.Такая информация, как время, используется для генерации сертификата RSA ЦС. Каждый узел, получивший сертификат, должен связаться с другими узлами, сначала обменяться сертификатом, проверить действительность сертификата другой стороны, а затем использовать в сертификате алгоритм шифрования с открытым ключом RSA. КЛЮЧ возвращается стороне, выдавшей сертификат. После того, как сторона, выдавшая сертификат, получит зашифрованный КЛЮЧ, она расшифрует его с помощью закрытого ключа RSA, чтобы получить симметричный зашифрованный КЛЮЧ. Таким образом, обе стороны завершают проверку действительности и используют обмененный КЛЮЧ для шифрование сообщений и дешифрование связи. Процесс выглядит следующим образом:

онлайн сравнение данных

Приведенный выше технический анализ предназначен только для того, чтобы помочь читателям понять механизм работы этой системы.Кроме того, конечно, необходимо опубликовать онлайн-данные, чтобы доказать работоспособность системы.Сравнительные данные. В одном и том же объекте живой комнаты на том же пограничном сервере мы отключили P2P для половины пользовательских узлов и включили P2P для половины пользователей, чтобы наблюдать за потреблением полосы пропускания этими двумя группами пользователей на одном и том же пограничном сервере за один день. .

Как видно из приведенного выше рисунка, потребление полосы пропускания в режиме P2P составляет всего 1/4 от потребления без включения режима P2P Наша система P2P экономит 75% стоимости полосы пропускания. Образец видео этих данных представляет собой одноканальный прямой эфир 480P 800 кбит/с, фактическое количество узлов в пиковый период составляет более 1000, а окончательная средняя задержка всех терминалов составляет 1,07 секунды.

постскриптум

На этом технический анализ распределительной сети P2P завершен.Прошло 19 лет с момента появления технологии P2P, и P2P CDN также является основной технологией CDN следующего поколения.Технология и модели P2P также были изменены и улучшен. Мы используем UDP и P2P в области распространения прямых трансляций, чтобы решить проблему взаимодействия на нашей образовательной сцене с точки зрения затрат и задержек.Если отправная точка отличается, мы получим разные результаты.Если вы столкнетесь с проблемами затрат и задержек , вы можете попробовать использовать эту технику для решения проблемы.

об авторе

Юань Жунси, Xuebajun старший архитектор, 16 лет программиста C, хорошо разбирается в создании высокопроизводительных сервисных систем и настройке производительности системы, хорошо разбирается в сети связи P2P, стеке протоколов связи TCP / IP и технологии шифрования аутентификации, присоединился к Xuebajun в 2015 году, отвечает за создание Xuebajun интеллектуальная маршрутизация в режиме реального времени, система передачи аудио и видео и сеть для решения проблемы аудио и видео связи в реальном времени.

благодарныйЮтада ХикаруПланирование и рецензирование этой статьи.