Всем привет, мы снова встретились, я ваш друг Цюаньчжаньцзюнь.

заявление:Эта статьяCSDNОригинальная статья,без разрешения,Любая форма воспроизведения запрещена. автор:Циниюнь Редактор:Цянь Шугуан,сосредоточиться Если вы ищете отчеты или материалы в области архитектуры и алгоритмов, отправьте электронное письмо по адресу qianshg@csdn.net. Также есть «CSDN. «Группа старших архитекторов», в которую входят многие талантливые архитекторы из известных интернет-компаний. Архитекторы могут добавить WeChat qshuguang2008, чтобы подать заявку на вступление в группу, и укажите их имя + компанию + должность.

Циниюнь于6В конце месяца А.видеопрямая трансляциясеть потокового вещанияLiveNetи полныйпрямая трансляция облачного решения, многие разработчики очень интересуются деталями и сценариями использования этой сети и решения.

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

Схема этой серии статей такова:

（один）коллекция （два）иметь дело с （три）Кодирование и упаковка (4) Потоковая передача и передача (5) Принципы современных игроков (6) Оптимизация задержки (7) Модель тестирования производительности SDK

В прошлом выпуске обработки мы представили кодирование и инкапсуляцию. Эта статья является четвертой в серии «Расшифровка технологии прямой трансляции видео»: потоковая передача и передача. Push-стриминг — это первая миля прямой трансляции, и прямая трансляция оказывает большое влияние на канал прямой трансляции. Если сеть, передающая поток, нестабильна, независимо от того, как мы ее оптимизируем, впечатления аудитории будут очень плохими. Следовательно, для нас это также первый шаг к устранению проблем. Как систематически решать такие проблемы, нам необходимо иметь базовое понимание соответствующих теорий.

push-протокол

Давайте сначала представим, какие существуют push-протоколы, их текущий статус и преимущества в области прямой трансляции недостатка.

• RTMP
• WebRTC
• Частный протокол на основе UDP

RTMP

RTMP — это аббревиатура от «Протокол обмена сообщениями в реальном времени». Этот протокол основан на TCP и представляет собой семейство протоколов, включающее базовый протокол RTMP, RTMPT/RTMPS/RTMPE и другие варианты. RTMP — это сетевой протокол, предназначенный для передачи данных в реальном времени. Он в основном используется для передачи аудио, видео и данных между платформой Flash/AIR и серверами потокового мультимедиа/интерактивными серверами, поддерживающими протокол RTMP. Программное обеспечение, поддерживающее этот протокол, включает Adobe Media Server/Ultrant Media Server/red5 и т. д.

RTMP — это текущий основной протокол передачи потокового мультимедиа, который широко используется в сфере прямого вещания. Можно сказать, что подавляющее большинство продуктов прямого вещания на рынке используют этот протокол:

преимущество

• Поддержка CDN хорошая, поддерживается основными поставщиками CDN.
• Протокол прост и легко реализуется на различных платформах.

недостаток

• При использовании TCP стоимость передачи высока, и проблема становится серьезной, когда скорость потери пакетов высока в слабой сетевой среде.
• Push через браузер не поддерживается
• Соглашение о собственности Adobe, Adobe больше не обновляет

WebRTC

WebRTC, название которого происходит от аббревиатуры Web Real-Time Communication (англ. Web Real-Time Communication), представляет собой API, который поддерживает веб-браузеры для голосовых разговоров или видеоразговоров в реальном времени. Он был открыт с открытым исходным кодом 1 июня 2011 года и был включен в рекомендуемые стандарты W3C Консорциума World Wide Web при поддержке Google, Mozilla и Opera.

В настоящее время он в основном используется в видеоконференциях и непрерывном микрофоне. Уровни протокола следующие:

преимущество

• Стандарт W3C, широко поддерживаемый основными браузерами.
• За этим стоит Google, у которого есть эталонные реализации на каждой платформе.
• Нижний уровень основан на SRTP и UDP, и здесь есть много возможностей для оптимизации в условиях слабой сети.
• Может обеспечить двухточечную связь с низкой задержкой между сторонами связи.

недостаток

• Традиционные CDN ICE, STUN, TURN не предоставляют подобных услуг.

Частный протокол на основе UDP

Некоторые приложения прямого вещания будут использовать UDP в качестве базового протокола для разработки своих собственных частных протоколов. Из-за преимуществ UDP в слабых сетевых средах лучших эффектов оптимизации слабой сети можно достичь за счет некоторой индивидуальной настройки. Однако, поскольку это частный протокол. , это связано с реальными проблемами:

преимущество

• Больше возможностей для индивидуальной оптимизации

недостаток

• Высокие затраты на разработку
• CDN не дружелюбен, вам нужно создать свой собственный CDN или договориться с CDN.
• Сражайтесь независимо и не можете развиваться вместе с сообществом.

транспортная сеть

Потоковое мультимедиа, которое мы продвигаем, должно быть передано аудитории, и вся связь является транспортной. аналогия с грузовой логистикой - это все расстояние от пункта отправления до пункта назначения. Если пропускной способности дороги будет недостаточно, это вызовет пробки в сети, то есть перегруженность сети. В это время мы будем менять расстояние, которое есть. так называемое интеллектуальное планирование, но транспортная сеть Примет меры с глобальной точки зрения,Следовательно, оно будет иметь лучшие результаты, чем планирование в атомном мире.,Вполне возможно, что на небе находится Бог, наблюдающий за всей информацией о дорожном движении между пунктом отправления и пунктом назначения.,И это в режиме реального времени,Тогда дайте вам ясный путь,Какое чудо,Но мы уже реализовали это в LiveNet.

Давайте сначала рассмотрим традиционную сеть распространения контента.

Почему существует сеть распространения контента? Происхождение сети распространения контента?

Интернет возник из внутренней сети вооруженных сил США. Тим Бернерс-Ли — один из изобретателей Интернета. Он давно предвидел, что перегрузка сети станет самым большим препятствием для развития Интернета в ближайшем будущем. подняла академическую проблему. Чтобы изобрести новый и принципиально решающий метод достижения распространения интернет-контента без перегрузок, эта академическая проблема в конечном итоге породила инновационный интернет-сервис - CDN. Рядом с доктором Бернерс-Ли находился кабинет профессора Тома Лейтона, профессора прикладной математики Массачусетского технологического института, которого заинтриговала задача Бернерса-Ли. Леттон наконец решил эту проблему и начал свой собственный бизнес-план, основав Akamai и став первой в мире компанией CDN.

Архитектура традиционной CDN

На приведенном выше рисунке представлена ​​схема типичного трехуровневого развертывания системы CDN. Узлы — это самые основные единицы развертывания в системе CDN. Они разделены на три уровня развертывания: центральный узел, региональный узел и пограничный узел. верхний уровень — это центральный узел, а средний — это региональный узел, а краевые узлы географически разбросаны для предоставления пользователям близлежащих услуг доступа к контенту.

Ниже представлена ​​классификация узлов CDN, которые в основном делятся на две категории: магистральные узлы и магистральные узлы POP, которые далее делятся на центральные узлы и региональные узлы:

• магистральный узел
  • центральный узел
  • Региональный узел
• POP-узел
  • краевой узел

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

прямая трансляциятранспортная сеть Больные точки, которые отличаются от традиционной CDN

С наступлением эры Live прямая трансляция стала еще одним важным полем битвы для нынешних производителей CDN. Так какие же услуги CDN должна поддерживать в эпоху Live?

• Поддержка протоколов потокового мультимедиа, включая RTMP, HLS, HTTP-FLV и т. д.
• Первый экран открывается за секунды, а время от щелчка пользователя до управления воспроизведением — за секунды.
• Управление задержкой 1–3, от конца потоковой передачи до конца воспроизведения, задержка регулируется в пределах 1–3 секунд.
• Интеллектуальная маршрутизация в масштабе всей глобальной сети,Все узлы во всей сети CDN могут использоваться для обслуживания одного пользователя.,Никаких географических ограничений. Поскольку процесс глобальной интеграции продолжает развиваться,Межрегиональная, межстрановая и межконтинентальная прямая трансляция становится нормой.,Очень вероятно, что якорь находится в Европе и США.,А пользователи находятся в Азии.
• Узлы уровня дня добавляются по мере необходимости.,Выход китайских компаний за границу стал общей тенденцией.,CDN нужно больше зарубежных узлов,В настоящее время конкуренция больше связана с быстрым развертыванием зарубежных узлов.,От выдвижения требования о добавлении узлов к добавлению узлов в сеть для предоставления услуг.,Нужно добраться в течение одного дня,верноCDNЭксплуатация и обслуживание и планирование предъявляют очень высокие требования. Исходное ежемесячное планирование и доступ к сети не могут удовлетворить расширенные требования.

Маршрутизация каналов традиционной CDN

CDN основан на топологии древовидной сети. На каждом уровне имеется GSLB (глобальная балансировка нагрузки сервера) для балансировки нагрузки нескольких узлов CDN на одном уровне. Каковы преимущества этого?

Среди многих сценариев приложений CDN, упомянутых ранее, ускорение веб-страниц, ускорение видео и ускорение передачи файлов основаны как на GSLB, так и на системах кэширования. Система кэширования — это стоимость всей системы CDN, и древовидная структура может быть спроектирована так, чтобы максимизировать ее. Сэкономьте капитальные вложения в системе Cache. Поскольку только центральному узлу необходимо поддерживать все копии кэша, их количество постепенно сокращается. На периферийном узле только небольшое количество кэшей точек доступа может обрабатывать большинство запросов на доступ к CDN. Это значительно снижает стоимость сети CDN. в соответствии с текущей ситуацией. Потребности пользователей CDN можно охарактеризовать как беспроигрышную ситуацию. Но в эпоху прямых трансляций бизнес прямых трансляций представляет собой потоковый бизнес и редко задействует систему кэширования. По сути, ресурсы хранения могут быть освобождены после трансляции. Даже если существует потребность в хранилище по политическим причинам, все это является холодным хранилищем. , а инвестиции в хранилище относительно невелики. Это очень дешево и не требует хранения во всех узлах, если данные можно отследить и они доступны.

Давайте посмотрим на топологию древовидной сети. Количество вариантов ссылок для пользователей ограничено. Как показано на рисунке ниже, количество ссылок, которые пользователи могут выбрать в определенной области, составляет: 2*5=10.

Если пользователь находится в определенной области, GSLB (обычно Smart DNS на уровне пограничного узла) направит пользователя на пограничный узел в этой области, а верхний уровень направит пользователя на региональный узел (здесь обычно GSLB). внутренний балансировщик нагрузки) и, наконец, обратно к центральному узлу, который будет подключаться к исходному сайту.

Предположения здесь следующие:

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

Но так ли это на самом деле? Действительно ли правильно вводить столько предположений?

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

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

Мы видим, что как только мы меняем структуру сети на ячеистую структуру, выбираемые пользователем ссылки становятся: все пути между указанными двумя точками неориентированного графа. Студенты, изучавшие теорию графов, знают, что это число ошеломляет.

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

Расширение CDN

Как упоминалось ранее, зарубежная экспансия китайских компаний стала тенденцией, и спрос на зарубежные узлы CDN растет. В этой ситуации поставщикам CDN необходимо развертывать новые магистральные сети и пограничные узлы в новых регионах, и требуется детальное сетевое планирование. Времена изменились. Оказывается, все пользователи CDN — это пользователи корпоративного уровня. Цикл итерации их собственных бизнес-линий длинный, и у них есть долгосрочное планирование, оставляющее больше времени производителям CDN. Интернет-компании уделяют внимание скорости, и итерации раз в две недели стали нормой. Это связано с противоречием между стоимостью и скоростью ответа. Если узлы развернуты заранее, они смогут лучше обслуживать эти интернет-компании, но будет более высокое ценовое давление, и наоборот. наоборот. Невозможно ответить этим быстро растущим интернет-компаниям.

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

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

Назад к основам: LiveNet

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

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

Чтобы сделать вышеизложенное, нам необходимо:

• Децентрализованная ячеистая топология
• Планирование глобальной сети
• Узлы не имеют состояния, узлы являются одноранговыми
• Интеллектуальная эксплуатация и обслуживание

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

Децентрализованная ячеистая топология

Сетчатая топология — это основа и основа проектирования. Только когда мы ясно понимаем, как можно уменьшить потребность в кэше, ячеистая топология может иметь больше преимуществ.

Планирование глобальной сети

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

Узлы не имеют состояния, узлы являются одноранговыми

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

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

Интеллектуальная эксплуатация и обслуживание

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

Ниже перечислены некоторые из интеллектуальных средств, используемых LiveNet. эксплуатация и обслуживаниеплан,Пусть сеть доставки контента снова обновится,Чтобы соответствовать требованиям эпохи Live.

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

LiveNet VS P2P

Наконец, мы проводим сравнение с P2P-сетью:

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

В этой статье представлены толкающие и транспортные Что касается части сети, мы отправили потоковое мультимедиа на терминал аудитории. Следующий шаг — отобразить его на экране. Если вы хотите узнать больше об этой части, продолжайте фокусироваться. Наш следующий контент.

22-23 сентября 2016 г., [SDCC 2016технология больших данных&Практический саммит по архитектуре](http://bss.csdn.net/m/topic/sdcc_invite/hangzhou /) пройдут в Ханчжоу. На двух саммитах примут участие лекторы из известных интернет-компаний, таких как Alibaba, JD.com, Suning, Vipshop, Meituan-Dianping, Youzu, Ele.me, Youzan, Echo и т. д. обсудить влияние больших объемов данных на построение системы мониторинга приложений, алгоритмы и реализацию обнаружения аномалий, практику работы в инфраструктуре больших данных, создание и применение гибкой платформы данных, применение алгоритмов машинного обучения для аудиоанализа, а также проектирование системной архитектуры высокой доступности/высокого параллелизма/высокопроизводительности. , Архитектура электронной коммерции, распределенная архитектура и другие темы и технологии. 9луна5день~18день是八折优惠票价阶段,Специальные скидки доступны при групповых покупках более 5 человек или при покупке двух пропусков на вершину.,Ограниченная по времени скидка,Сделайте предзаказ прямо сейчас。（Ссылка на подробную информацию о билетах）。

Издатель: Лидер стека программистов полного стека, укажите источник для перепечатки: https://javaforall.cn/162845.html Исходная ссылка: https://javaforall.cn