Uploaded byMedia Gorod
Сервер Flash-вещаний (RTMP) на Python или создание высоконагруженных сетевых серверов с использованием Twisted
Документ описывает разработку высоконагруженного RTMP-сервера с использованием Python и Twisted, включая выбор архитектуры и основные проблемы. Рассматриваются существующие коммерческие и свободные решения, а также возможности, такие как управление пропускной способностью и работа с потоками. В итоге представлена архитектура решения pyfms, которая обеспечивает эффективную работу с высокой нагрузкой и возможностью ретрансляции на большое количество клиентов.
Сервер Flash-вещаний (RTMP) на Python или создание высоконагруженных сетевых серверов с использованием Twisted
- 1. Сервер Flash-вещаний (RTMP) на Python или создание высоконагруженных сетевых серверов с использованием Twisted Андрей Смирнов NetStream
- 2. Содержание Обзор существующихрешений . Разработка своего решения ( pyFMS): выбор архитектуры, основные проблемы и пути их решения . Борьба за качество: ретрансляция . Полученные количественные характеристики .
- 3. Общая схема RTMP RTMP: симметричный; проприетарный; закрытый. Возможности: удаленный вызов процедур ( RPC) ; управление пропускной способностью; работа с аудио-видео потоками (просмотр и запись). Клиент ( Flash) Сервер RTMP RTMP
- 4. Существующие решения Коммерческие:Adobe Flash Media Server (FMS) ; Wowza Media Server Pro . Свободное ПО : Red5 ( http://osflash.org/red5/ ) ; Milenia Grafter ( http:// milgra.com / ) ; …
- 5. Архитектура сетевого сервераМного процессов. Много нитей. Один поток (асинхронный ввод-вывод). Комбинированный: асинхронный ввод/вывод + много нитей / процессов.
- 6. Концепция нашего решенияПростота: не будем реализовывать ничего лишнего; простая архитектура - один поток выполнения. Python : Twisted Framework ; готовые модули: pyAMF , ...
- 7. Twisted Framework Концепцияотложенного выполнения ( Deferred) . Переносимый асинхронный ввод-вывод ( reactor) . Реализация большого числа базовых протоколов ( HTTP, DNS, Telnet, и т.п.)
- 8. Архитектура pyFMSПриложение 2 Приложение 1 Сервер pyFMS Комната 1 Комната 2 Разделяемый объект Поток (вещание) Клиенты:
- 9. Схема вещания APIКлиент pyFMS Сайт ( API) Сбор и анализ статистики Вещание Чат Разделяемый объект Поток (вещание) Запись потока на диск с последующей обработкой Удаленные вызовы процедур ( RPC)
- 10. Эффективность реализации Python– интерпретируемый ЯП прозрачная сложность операций; легкое расширение с помощью модулей на С. Для увеличения производительности в два раза достаточно было : переписать 5% кода на Python; написать один модуль на C ( около 1000 строк кода).
- 11. Ретрансляция Вещание на10 000 клиентов? Легко! pyFMS 1 pyFMS 2 pyFMS 3 pyFMS 4 Источник вещания Ретрансляторы Клиенты вещания Автор вещания
- 12. Количественные характеристики Наодин процесс (одно ядро процессора): 10 тыс. соединений без потока вещания; Вещание: в среднем 100 Мбит/с, пик 140 Мбит/с; примерно соответствует 700-900 человек, которые смотрят вещание. Ретрансляция позволяет наращивать мощность практически неограниченно.
- 13.
Editor's Notes
- #2 Добрый день! Меня зовут Андрей Смирнов, я работаю техническим директором компании NetStream. Я расскажу о нашем опыте по созданию сервера вещаний для Flash. Сегодня этот сервер работает в качестве движка вещаний на сайте Smotri.com.
- #3 Начнём мы с краткого рассказа о различных существующих решениях, потом уже поподробнее рассмотрим то, что у нас получилось реализовать и почему именно так, как получилось.
- #4 Сначала несколько слов о самой технологии – о протоколе RTMP. Вещание во флеше организуется по проприетарному протоколу RTMP. Клиент, который является просто флешкой, подключается к серверу, после выполнения первоначального «рукопожатия» открывается в принципе симметричный канал, по которому передаются данные. Протокол является бинарным, соединение разделяется на независимо функционирующие каналы, по которым можно передавать пакеты, пакеты при этом разрезаются на кусочки ( chunk), которые позволяют в принципе осуществлять перемешивание ( interleaving ) данных из разных каналов. В пакетах можно передавать удаленный вызов процедур, которые кодируются с помощью AMF- кодирования (стандартного во флеше). Сам по себе протокол закрыт, основная часть работы по reverse engineering была выполнена в рамках проекта Red5. Однако документации по протоколу так и не получилось, необходимо изучать исходники Red5, других open-source серверов, где-то идти методом проб и ошибок, пока не получится результат.
- #5 Мы рассматривали вариант реализации вещаний где-то год назад и решения принимались на тот момент. О чем можно сказать? Во-первых, коммерческие решения, ну и, конечно же, первое из них , Adobe Flash Media Server – это, собственно основной вариант реализации. Так сказать, вариант «от создателей RTMP ». Все остальные варианты – это так или иначе попытки реализовать что-то близкое. Ну если не рассуждать о плюсах и минусах таких закрытых решений, первое, что нас не устроило – это лицензирование сервера по количеству соединений, а по этому параметру как раз хотелось бы свободного масштабирования. Сегодня уже Wowza, например, предлагает лицензию просто за инсталляцию без учёта кол-ва соединений на сервер. Соответственно, следующий взгляд мы бросили в сторону свободного ПО. Тогда из более-менее готовых был только Red5. Это попытка полностью переписать Adobe FMS на Java, возможно, с некоторыми даже улучшениями по сравнению с оригиналом. Получается у них очень раздутый, сложный, но полнофункциональный сервер. Состояние по их же оценкам – честно бета. Он действительно работает, однако полностью отсутствует документация по тому, как писать приложения. Сотни способов установки, вариантов использования и т.п. Однако в результате понять что к чему бывает не так просто. Первый наш эксперимент сервера вещания был именно с Red5. Через месяц мучений и экспериментов удалось написать рабочее приложение вещания и чата, всё вполне сносно работало. Появились проблемы – утечка памяти (не уникальная проблема, судя по спискам рассылки), «утыкание» в процессор, но также возникли проблемы задержек. По непонятным причинам на не 100% загруженной машине запросы к red5 обслуживались с некоторыми довольно значительными задержками. Мы долго пытались разгадать причину, точно выяснили что проявляется она под нагрузкой, хотя процессор не нагружен. После не одной недели копания в исходниках и логах удалось обнаружить интереснейшую проблему. Мы обращались из ред5 к апи сайта при наступлении опеределенных событий во время вещания по HTTP . Red5 использует большое количество внешних библиотек (порядка 20) и в одной из них, которая реализует клиента HTTP, стояло замечательное ограничение по умолчанию на 2 коннекта к одному хосту в один момент времени. У нас же хост был всегда один. Ограничение было предназначено, видимо, для скачивателей, чтобы не перегружали хост скачивания, хотя он вообще сомнителен. Всё, чтоб было больше ограничения – вставало в очередь, забивало нити, дальнейшая деградация была уже каскадной. После обнаружения подобных проблем пропало дальнейшее желание с таким возиться. Milenia Grafter появился попозже, чем мы рассматривали первые решения, но это тоже RTMP- сервер на Java, но написан по минималистическому принципу, без использования внешних библиотек – гораздо более понятный код, однако слабый функционал, нужны существенные доработки, процесс разработки ведет один прграммист, отсутствие community. Еще существует некоторое количество проектов на разных языках программирования, но они были далеки от первой версии.
- #6 Больше примеров? Может, разбить на несколько слайдов?
- #11 Можно вспомнить, что Red5, например, написан на Java, который при помощи hotspot- компилятора превращается в исполняемый код, в то время как Python будет интерпертироваться. В то же время задача вещания является сильно ориентированной на центральный процессор. В RTMP формально нельзя просто копировать исходные данные из потока вещателя в потоки слушателей. Да, конечно, не стоит задача перекодирования видео или аудио потока, но формально может потребоваться достаточно большое количество преобразований, при этом поток состоит из большого количества «кусочков», на которые RTMP разрезает исходный поток, которые необходимо обрабатывать. Плюс поток состоит не только из пакетов аудио и видео, а из вызова удаленных процедур и т.п. действий.