Javascript: организация прокси сервера на клиенте?

Question

[Hocok_B_KapMaHe]

Вообще javascript не знаю (использовал до этого только некоторые простые функции)
Интерисует возможность сделать следующее:
организовать что-то типа прокси-сервера на клиенте посредством javascript.
Для чего?
Например есть обычный тег видео в который вписан mp4 файл
<video src="http://example.com/video.mp4">

Проблема в его дистрибуции.
Хотелось бы весь файл хранить на разных серверах (разбить его на куски)
(что-то типа hls чтобы получилось).

Так вот этот прокси-сервер на клиенте брал бы кусочки с серверов, и склеивал их в один mp4.

Возможно?
Какой самый простой путь для достижения цели?
Может уже есть такие решения?

Возможно ли использовать старые технологии (и какие), для поддержки старых браузеров ?

Answer 1

[TomaZ Vazovsky]

А зачем один файл разбивать на куски и хранить на разных серверах?
Или Вы хотите, чтобы видео проигрывалось сначала с одного сервера, потом со второго, а затем с третьего?
Тогда Вы можете просто показывать видео с одного адреса, а когда оно закончится переключаться на другое, затем на третье. Просто меняя атрибут src у видео-тега.

Comments

[Сергей Протько]

Тогда будут разрывы по идее. Лучше стриминг-сервером воспользоваться и тогда без разницы где лежат исходники.

[Hocok_B_KapMaHe]

OMG))) Каждый первый задает этот вопрос. Представте что у вас кучка серверов и видео разбросано по разным сервакам. Тут есть проблема "горячих видео". Прикинем что одно видео смотрят 10 тысяч пользователей в hd. Любой сервер упадет. На счет "покупай оборудование" - не катит. Я не миллионер

[Hocok_B_KapMaHe]

И да, видео должно проигрыватся непрерывно. Точно также как в http live streaming. Только с mp4.

[TomaZ Vazovsky]

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

[TomaZ Vazovsky]

ИМХО, тогда речь уже о бланасировке нагрузки. Зачем видео то разбивать, есть несколько реплик, и есть баласировщик, который говорит с какого сервера сейчас лучше всего смотреть видео.

[Hocok_B_KapMaHe]

@TomaZ: Я Вам скажу однозначно не самое простое. Т.к. во первых он не решает проблему горячих видео (т.к. видео все равно с одного сервера раздается) Во вторых каждому стриминг серверу надо откуда-то брать оригинал, а для этого нужно внешний NAS или SAN строить и переделывать всю архитектуру проекта.

[TomaZ Vazovsky]

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

[Hocok_B_KapMaHe]

@TomaZ: Ну предположим есть 200 серверов. Одно видео "мега-поопулярное". Его смотрят тысячи. Разделив видео на кусочки и разложив его по всем серверам можно обеспечить равномерную нагрузку на все сервера. И это при том что каждый сервер дешевый гигабит. А в случае с одним mp4 который нельзя разделить, приходится его отдавать с front-end сервера \одной ноды или строить балансировщики \ кешеры и прочее которые как правило от 10Gbit и больше и влетят в копеечку.

[TomaZ Vazovsky]

Может мы недопонимаем друг друга. Но Вы предлагаете один файл разбить на 200 частей и 200 раз переключать пользователя на разные стримы. При этом все сервера будут с разной нагрузкой, как можно в таком случае заранее сказать, что на все сервера нагрузка будет распределяться равномерно? Я бы предпочел продублировать один файл на 200 серверов и использовать логику с балансировкой. Просто предзапрос на балансир и вы получаете адрес для стрима, с которого нужно смотреть. Причем если так получилось, что со временем, с 199 серверов пользователи ушли, а 200-м их 100 штук, можно их перекинуть на свободные в процессе. Да балансировщик надо выстроить так, чтобы он быстро обрабатывал запросы, но я бы выбрал такой путь. Скажем так, я по нему уже ходил, может быть в данной ситуации я чего-нибудь недопонимаю.

[Hocok_B_KapMaHe]

@TomaZ: Если вы имеете ввиду "риалтайм" = live streaming то конечно же нет. Схема для VOD видео. Что касается про "горячие куски", - это вы имеете ввиду когда все пользователи запрашивают кусок с одного сервера? Ок. Ну придут. Сам сервер физически не сможет отдать более 128мб (1Gbit) в секунду. Он будет ставить в очередь пользователей, обслуживать по 64 пользователя в секунду (файлы по 2МБ) и по 64 человека отправлять их на следующие ноды, таким образом обеспечивать очередь. Да, пользователям в конце очереди надо будет подождать, но только при старте видео. Дальше же, - произойдет самостоятельная балансировка, т.к. на второй нод придет столько пользователей, сколько первый смог отпустить. Надеюсь я правильно изложил мысль...

[TomaZ Vazovsky]

Да, они придут на второй нод, а там у нас вообще не продохнуть, потому что оттуда еще не ушли другие пользователи, и они снова ждут. А ноды 27, 44, и 188 вообще курят, потому что так вышло, что никто сейчас на них ничего не смотрит, но как мы туда нагрузку перекинем?

[TomaZ Vazovsky]

К тому же, с балансировкой в реальном времени, мы ведь еще может отдать пользователю самый "близкий" (географически) стрим (если сервис с большим охватом).

Answer 2

[xmoonlight]

www.vuze.com
jstorrent.com
и т.п. смотрите...

Answer 3

[frees2]

можно хранить на ютубе, файл большой разбить на куски и проигрывать в режиме автопроигрывания в плейере html5 и прописать какой именно файл, mp4 или иной проигрывать по умолчанию, а получать в ленте json.