Часть пользователей уже могли заметить в нашем видеоплеере окно с предложением разрешить использование пиринговой сети. Просмотр роликов с использованием технологии peer-to-peer проходит последний этап тестирования. Из всех загружаемых на сайт роликов в тот или иной момент, как правило, просматриваются не более 10–15%. Еще 15–20% от этих роликов можно считать популярными. Переход на P2P существенно снижает нагрузку на сервера, предоставляя пользователям возможность принимать видеопоток также и с соседних клиентов (разумеется, так же подтвердивших участие в пиринговой сети).
Разработка использует протокол RTMFP, реализуемый Flash Player 10.1 с клиентской стороны и Adobe Cirrus — с серверной.
Это снижает задержки при воспроизведении видео сразу по двум причинам. С одной стороны, реже делаются прямые запросы к северу, и серверу становится легче дышать и отвечать на другие запросы. С другой стороны, скорость получения данных от «соседей» нередко может быть выше, чем от сервера в дата центре, поскольку система выбирает партнеров исходя из соображений максимальной эффективности.
Видеоплеер может раздавать только то видео, которое просматривается в тот или иной момент — и только ту его часть, которая была загружена и все еще находится в памяти. При этом размер буфера не может превышать 64 Мб, чтобы не отъедать слишком много оперативной памяти. Теоретически для включения режима P2P достаточно и двух одновременно смотрящих видео пользователей. Однако целесообразно это только для тех роликов, которые смотрят одновременно десятки пользователей (как уже упоминалось выше, для ВКонтакте такие видео составляют порядка 15–20% от активно просматриваемых). В случае проигрывания роликов, для которых использование p2p не принесет видимых результатов, плеер переключается на стандартное скачивание.
Для идентификации клиентов используется только ключ, выдаваемый Cirrus-сервером Adobe, ни IP-адрес, ни uid пользователя восстановить по нему не представляется возможным).
Как уже было упомянуто выше, для объединения в отдельную группу пользователей, просматривающих один и тот же видеоролик (в одном и том же разрешении), в данный момент используется сервис Cirrus от Adobe, взаимодействие с которым происходит по протоколу RTMFP. Поддержка соответствующего класса NetGroup появилась только в флэш плеере версии 10.1 — поэтому пользователи с плеером десятой версии предложение использовать P2P не увидят.
Чтобы организовать обмен между пользователями частями одного видео, файл разбивается на чанки размером 64 Кб. Каждый чанк в первую очередь запрашивается у соседних пиров (регулируется весь этот процесс внутренне флэш плеером и сервером Cirrus), а при отсутствии ответа в течение нескольких секунд делается запрос напрямую к видеосерверам «В Контакте» — полученные данные разбиваются на чанки и раздаются другим пользователям.
Для вывода загруженных чанков используется так называемый «режим создания данных» (Data Generation Mode) у класса NetStream. К сожалению, он не поддерживает формата MP4, который сейчас используется для хранения видео «В Контакте», поэтому у собранных из чанков видеофайлов теперь на лету меняется контейнер с MP4 на FLV.
Из-за необходимости сохранять воспроизводимый файл идентичным независимо от точки начала воспроизведения, было решено отказаться от создания ключевых кадров на стороне сервера при воспроизведении с произвольного места. Выбор ближайшего к выбранному моменту кадра теперь так же производится клиентом, что дополнительно уменьшает задержки при перемотке видео.
Основные результаты на текущей стадии — ощутимое снижение задержек:
Разработка использует протокол RTMFP, реализуемый Flash Player 10.1 с клиентской стороны и Adobe Cirrus — с серверной.
Это снижает задержки при воспроизведении видео сразу по двум причинам. С одной стороны, реже делаются прямые запросы к северу, и серверу становится легче дышать и отвечать на другие запросы. С другой стороны, скорость получения данных от «соседей» нередко может быть выше, чем от сервера в дата центре, поскольку система выбирает партнеров исходя из соображений максимальной эффективности.
Видеоплеер может раздавать только то видео, которое просматривается в тот или иной момент — и только ту его часть, которая была загружена и все еще находится в памяти. При этом размер буфера не может превышать 64 Мб, чтобы не отъедать слишком много оперативной памяти. Теоретически для включения режима P2P достаточно и двух одновременно смотрящих видео пользователей. Однако целесообразно это только для тех роликов, которые смотрят одновременно десятки пользователей (как уже упоминалось выше, для ВКонтакте такие видео составляют порядка 15–20% от активно просматриваемых). В случае проигрывания роликов, для которых использование p2p не принесет видимых результатов, плеер переключается на стандартное скачивание.
Для идентификации клиентов используется только ключ, выдаваемый Cirrus-сервером Adobe, ни IP-адрес, ни uid пользователя восстановить по нему не представляется возможным).
Технические детали
Как уже было упомянуто выше, для объединения в отдельную группу пользователей, просматривающих один и тот же видеоролик (в одном и том же разрешении), в данный момент используется сервис Cirrus от Adobe, взаимодействие с которым происходит по протоколу RTMFP. Поддержка соответствующего класса NetGroup появилась только в флэш плеере версии 10.1 — поэтому пользователи с плеером десятой версии предложение использовать P2P не увидят.
Чтобы организовать обмен между пользователями частями одного видео, файл разбивается на чанки размером 64 Кб. Каждый чанк в первую очередь запрашивается у соседних пиров (регулируется весь этот процесс внутренне флэш плеером и сервером Cirrus), а при отсутствии ответа в течение нескольких секунд делается запрос напрямую к видеосерверам «В Контакте» — полученные данные разбиваются на чанки и раздаются другим пользователям.
Для вывода загруженных чанков используется так называемый «режим создания данных» (Data Generation Mode) у класса NetStream. К сожалению, он не поддерживает формата MP4, который сейчас используется для хранения видео «В Контакте», поэтому у собранных из чанков видеофайлов теперь на лету меняется контейнер с MP4 на FLV.
Из-за необходимости сохранять воспроизводимый файл идентичным независимо от точки начала воспроизведения, было решено отказаться от создания ключевых кадров на стороне сервера при воспроизведении с произвольного места. Выбор ближайшего к выбранному моменту кадра теперь так же производится клиентом, что дополнительно уменьшает задержки при перемотке видео.
Промежуточные итоги
Основные результаты на текущей стадии — ощутимое снижение задержек:
- При воспроизведении популярных роликов, одновременно загружаемых большим количеством пользователей.
- При проигрывании любых видео с произвольного места.
