у SCTP есть минусы:
— нет IP-migration
— 4-way handshake вместо 0-RTT
— на старте соединение нужно указать кол-во потоков
— не решает проблему head-of-line-blocking для стримов
мы делали свой протокол поверх UDP исключительно для беспроводных сетей, учитывая их особенности по bw/pl/jitter
например у нас есть FEC )
Aeron подойдет для высокоскоростных магистралей и сетей уровня ДЦ
но challenge accepted — сделаю тесты
вы не замечали, что при прочих равных google сайты и сервисы работают быстрее?
Google сначала они придумали BBR (congestion control в TCP), который в случае конкуренции за канал с другими congestion control-ами их выжимает
никто не знает, какой CC у google сейчас на серверах как для TCP так и для QUIC/UDP
но уверен что самый агрессивный из доступных
согласен, было бы круто сказать что у тебя в рамках мультиплексированного соединение есть не только приоритеты, но и возможность иметь стрим с гарантированным packet loss, например не более 1% PL (для видео этой пройдет незаметно)
или сказать что есть стрим, где пакеты теряют свой смысл после задержки более 1 сек, для конференц связи или live трансляций например
для медиастриминга мы используем друго свое решение habr.com/ru/company/oleg-bunin/blog/413479
используя свой протокол поверх UDP получилось на 7-10% увеличить скорость загрузки контента (API + картинки) на устройства пользователя, гугл сейчас публикует более скромный результат для QUIC в 3%
увеличение пользовательской активности на 1% оценено на десятках миллионов DAU по системе А/Б тестирования, основанной на матстатистике
которая говорит что с вероятностью 99.98% именно изменение протокола приводит как минимум к 1% роста активности )
но мы продолжаем работы над протоколом и эксперименты
сейчас UDP недоступен менее чем в 3% сетей и число таких сетей стремительно падает
на случай недосупности UDP почти во всех протоколах есть есть fallback на TCP
да в статье идет речь про такой вариант mitm в webRTC:
p2p соединение скомпрометировано и mitm проксирует все сообщения в data канале, т.е. mitm делает два DTLS (по одному с каждым абонентом) и получает доступ к трафику
в этом случае нет возможности валидировать, что вы DTLS делаете именно с вашим абонентном, а не злоумышленником
да, клиент это сложная задача:
нужно скомпилировать webRTC одной командой и прикрутить в ваше iOS или Android приложение, а на вебе 5 шагов pastebin.com/EjsdJx1h (ссылка из статьи)
повторюсь: на видео доклада говорится что в докладе не будет Highload-а ;)
и доклад про то как работает сервис видеозвонков
инкрементить номера портов это скорее хак, чем фича
мы это сделали на уровне приложения, чтобы обновление библиотеки происходило более безболезненно
Но вообще идея хорошая, можем сделать патч для webRTC
Добрый день, у нас не было цели «изобрести» что-то новое ;)
мы решали задачу мобильного стриминга с низкой задержкой в FullHD, и то что из это вышло описано в докладе
очевидно, что на TCP хорошо это делать не получится: head-of-line-blocking, и накопление буфера, отсутсвие приоритезации…
от webRTC отказались, потому что:
1) webRTC сложный протокол для звонков, в котором очень много всего лишнего, что не требуется для ведения трансляций: например AEC (Acoustic Echo Cancellation), STUN/TURN…
2) в webRTC не возможна смена разрешения не лету в одностороннем порядке, нет приоритезации audio
3) webRTC умеет восстанавливать потерянные пакеты, но звонки это прежде всего это история про lowLatency и нам не удалось избавится от эффектов («рассыпания» или «замораживания») изображения на webRTC при изменения пропускной способности канала (а блоггеры часто ведут свои трансляции в движении), поэтому OKTP аккуратнее работает с каналом: делает промер канала избыточными пакетами и обратную связь по packetloss и по latency на канале
4) в webRTC не просто сделать стриминг 1 к N (где N ~ 1 млн, если вникнуть в сам протокол и вспомнить, что каждый зритель, так может попросить персональный опорный кадр)
5) мы поддержали IP migration, т.е. смена IP стримера происходит прозрачно (это важная вещь для мобильного стриминга в движении)
другие предложения:
5) VP{8,9} на iOS реализованы софтварно и съедают аккумулятор больше чем h264 (по независимым тестам, OKLive использует батарею меньше конкурентов)
6) HLS, для стриминга с клиента кажется не лучшей затеей: если внутри MPEG-TS (то пакеты по 188 байт ведут к росту нагрузки на CPU клиента и сервера), в HLS нельзя сменить разрешение на лету
> т.е. не надо ничего ждать, все сразу можно получать без задержек
в HLS, если вы пришли на стрим между опорными кадрами, то у вас выбор или играть с прошлого или подождать следующего (т.е. выбор или ждать или отставать)
7) OkLive вышел в сторы более 2х лет назад, тогда еще у QUIC даже не было 1ой версии драфта datatracker.ietf.org/doc/draft-ietf-quic-transport
при этом QUIC не является протоколом стриминга с потяреми!
конечно стримить через него можно
но в OKTP обратная связь по потерянным пакетам и по latency (как у BBR), которая тюнит кодировщик (bitrate, fps, resolution)
очень буду признателен, если перечислите протоколы у которых есть возможность этим управлять ;)
8) udt — это высокопроизводительный протокол передачи данных предназначенный для передачи наборов данных большого объёма на высокой скорости по глобальным сетям
а у нас приложение про мобильный стриминг ;)
9) srt — в начале 2016ого публичной информации про srt не было, в 2017ом появилась первая версия на github
reversecode, как у SRT обратная связь на кодировщик реализована? можно ли менять resolution,fps,bitrate?
из всего выше описанного, следует, что OK сделали правильный выбор, реализовав свой протокол поверх UDP
для решения узкой задачи: стриминг в мобильных сетях в высоком качестве и с низкой задержкой
и мой призыв, что если у кого-то есть узкая задача, то сделать свой протокол будет хорошим решением
буду рад провести тесты с любым приложением стриминга в условиях мобильной сети с переменным качеством (например в поезде )
habr.com/ru/company/oleg-bunin/blog/413479
а по нашему UDP протоколу мы гоняем и API json-ы и картинки
спасибо за TCP pacing!, на досуге попробую сделать эксперимент на пользователях )
— нет IP-migration
— 4-way handshake вместо 0-RTT
— на старте соединение нужно указать кол-во потоков
— не решает проблему head-of-line-blocking для стримов
tools.ietf.org/html/draft-joseph-quic-comparison-quic-sctp-00
например у нас есть FEC )
Aeron подойдет для высокоскоростных магистралей и сетей уровня ДЦ
но challenge accepted — сделаю тесты
wireshark точно поможет найти quic пакеты )
Google сначала они придумали BBR (congestion control в TCP), который в случае конкуренции за канал с другими congestion control-ами их выжимает
никто не знает, какой CC у google сейчас на серверах как для TCP так и для QUIC/UDP
но уверен что самый агрессивный из доступных
или сказать что есть стрим, где пакеты теряют свой смысл после задержки более 1 сек, для конференц связи или live трансляций например
для медиастриминга мы используем друго свое решение habr.com/ru/company/oleg-bunin/blog/413479
увеличение пользовательской активности на 1% оценено на десятках миллионов DAU по системе А/Б тестирования, основанной на матстатистике
которая говорит что с вероятностью 99.98% именно изменение протокола приводит как минимум к 1% роста активности )
но мы продолжаем работы над протоколом и эксперименты
на случай недосупности UDP почти во всех протоколах есть есть fallback на TCP
p2p соединение скомпрометировано и mitm проксирует все сообщения в data канале, т.е. mitm делает два DTLS (по одному с каждым абонентом) и получает доступ к трафику
в этом случае нет возможности валидировать, что вы DTLS делаете именно с вашим абонентном, а не злоумышленником
нужно скомпилировать webRTC одной командой и прикрутить в ваше iOS или Android приложение, а на вебе 5 шагов pastebin.com/EjsdJx1h (ссылка из статьи)
повторюсь: на видео доклада говорится что в докладе не будет Highload-а ;)
и доклад про то как работает сервис видеозвонков
но я не хотел в докладе на этом останавливаться, поэтому использовал «вроде как» ;)
как раз в этой задаче поможет zRTP
на видео доклада говорится что в докладе не будет Highload-а ;)
и доклад про то как работает сервис видеозвонков
мы это сделали на уровне приложения, чтобы обновление библиотеки происходило более безболезненно
Но вообще идея хорошая, можем сделать патч для webRTC
мы решали задачу мобильного стриминга с низкой задержкой в FullHD, и то что из это вышло описано в докладе
очевидно, что на TCP хорошо это делать не получится: head-of-line-blocking, и накопление буфера, отсутсвие приоритезации…
от webRTC отказались, потому что:
1) webRTC сложный протокол для звонков, в котором очень много всего лишнего, что не требуется для ведения трансляций: например AEC (Acoustic Echo Cancellation), STUN/TURN…
2) в webRTC не возможна смена разрешения не лету в одностороннем порядке, нет приоритезации audio
3) webRTC умеет восстанавливать потерянные пакеты, но звонки это прежде всего это история про lowLatency и нам не удалось избавится от эффектов («рассыпания» или «замораживания») изображения на webRTC при изменения пропускной способности канала (а блоггеры часто ведут свои трансляции в движении), поэтому OKTP аккуратнее работает с каналом: делает промер канала избыточными пакетами и обратную связь по packetloss и по latency на канале
4) в webRTC не просто сделать стриминг 1 к N (где N ~ 1 млн, если вникнуть в сам протокол и вспомнить, что каждый зритель, так может попросить персональный опорный кадр)
5) мы поддержали IP migration, т.е. смена IP стримера происходит прозрачно (это важная вещь для мобильного стриминга в движении)
другие предложения:
5) VP{8,9} на iOS реализованы софтварно и съедают аккумулятор больше чем h264 (по независимым тестам, OKLive использует батарею меньше конкурентов)
6) HLS, для стриминга с клиента кажется не лучшей затеей: если внутри MPEG-TS (то пакеты по 188 байт ведут к росту нагрузки на CPU клиента и сервера), в HLS нельзя сменить разрешение на лету
> т.е. не надо ничего ждать, все сразу можно получать без задержек
в HLS, если вы пришли на стрим между опорными кадрами, то у вас выбор или играть с прошлого или подождать следующего (т.е. выбор или ждать или отставать)
7) OkLive вышел в сторы более 2х лет назад, тогда еще у QUIC даже не было 1ой версии драфта
datatracker.ietf.org/doc/draft-ietf-quic-transport
при этом QUIC не является протоколом стриминга с потяреми!
конечно стримить через него можно
но в OKTP обратная связь по потерянным пакетам и по latency (как у BBR), которая тюнит кодировщик (bitrate, fps, resolution)
очень буду признателен, если перечислите протоколы у которых есть возможность этим управлять ;)
8) udt — это высокопроизводительный протокол передачи данных предназначенный для передачи наборов данных большого объёма на высокой скорости по глобальным сетям
а у нас приложение про мобильный стриминг ;)
9) srt — в начале 2016ого публичной информации про srt не было, в 2017ом появилась первая версия на github
reversecode, как у SRT обратная связь на кодировщик реализована? можно ли менять resolution,fps,bitrate?
из всего выше описанного, следует, что OK сделали правильный выбор, реализовав свой протокол поверх UDP
для решения узкой задачи: стриминг в мобильных сетях в высоком качестве и с низкой задержкой
и мой призыв, что если у кого-то есть узкая задача, то сделать свой протокол будет хорошим решением
буду рад провести тесты с любым приложением стриминга в условиях мобильной сети с переменным качеством (например в поезде )