Publish your project for free and start receiving offers from freelance contractors in serveral minutes after publication!
500 ₴

Настройка сервера и доступа к нему через временные ключи.

closed without completion


Добрый день.

Есть сервер на Ubuntu LTS 16.x x64, на нем стоит движок, который выполняет функцию стриминга трансляций.

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

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

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

3. Затем, по этой http ссылке на плейлист трансляции, следует запрос от плеера пользователя. По мимо основной части, на сам плейлист, ссылка еще содержит ключ пользователя и ключ временной сессии. Перед тем, как отдать плейлист, необходимо по ключу пользователя проверить на валидность его временный ключ сессии, сверив его с тем ключом сессии, что сохранен у нас в БД. Если ключ сессии из нашей локальной БД, совпадает с ключом полученным в запросе, то пропускаем запрос дальше. Если нет, то отдаем соответствующее сообщение.

4. Плейлист трансляции содержит в себе ссылки на файлы длительностью 5 сек.. Примерно каждый 10-20 сек, движок обновляет содержимое плейлиста трансляции,  дописывая новые ссылки. И примерно с такой же периодичностью, плеер пользователя обращается к плейлисту за новой порцией ссылок:) Следовательно, проверять валидность ключа сессии необходимо при каждом обращении плеера к плейлисту. 

5. Касательно ссылок на куски по 5 сек., то такие запросы проходят без каких-либо ключей и проверок. 


Из всей схемы видно, что существует три типа запросов к серверу, каждый из которых имеет индивидуальные условия:

1. Запрос на запуск трансляции - пропускаем запросы только с основного домена, остальные дропаем.

2. Запрос к плейлисту трансляции - пропускаем запросы только в случае валидного ключа сессии у конкретного юзера.

3. Запрос к файлам трансляции - пропускаем все запросы без проверок


Все работы касаются серверной части. Со стороны основного домена, готово все, кроме генерации ключа сессии, т.к. хотелось бы утвердить его формат с тем, кто будет настраивать сервер.

По мимо этого, есть еще две задачи касательно глобальных настроек сервера:

- настройка ограничений трафика

- создать виртуальный диск в озу

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



  1. 3 days1500 ₴
    Oleg Tokar
     141   3   0

    Недавно реализовал пару проектов по схожей схеме.
    Есть свой протокол общения backend/streamer для защиты HLS стримов, есть своя реализация стримера на базе nginx. Пишите - обсудим.

    Ukraine Kyiv | 18 July at 12:21 |
  1. 2 days6000 ₽
    Максим Семёнов
     295   1   0

    Добрый день.

    Имею многолетний опыт настройки и сопровождения серверов на базе ОС Linux/FreeBSD. Последние годы работаю в крупнейших Российских сетевых компаниях, так что о слове highload знаю не по наслышке.

    Готов помочь с настройкой Вашего сервера. А так же могу предложить разработку необходимого решения на языке Python.

    Russia Saint-Petersburg | 17 July at 13:45 |

Project published
17 July at 13:32
43 views
Share