HighLoad++ 2017 Зал «Дели + Калькутта», 8 ноября, 11:00 Тезисы: http://www.highload.ru/2017/abstracts/3071.html Пишем свой протокол стриминга с гарантированной задержкой поверх UDP. Архитектура отказоустойчивого стриминг-сервиса, способного выдержать потерю дата-центра и миллион онлайнов. Проблемы мобильного стриминга и TCP-протокола, QUIC как замена TCP, UDP и fast retransmit, forward error correction (FEC), задержка или потеря пакетов, приоритезация потоков, шифрование и многое другое. Сервис Видео в Одноклассниках – вторая площадка в Рунете по просмотрам видео, ежедневно мы фиксируем свыше 400 миллионов просмотров видео. ...

1. Пишем свой протокол
поверх UDP или
платформа потокового
видео с нуля на миллион
онлайнов
Александр Тоболь

2. 2 Live Timeline
1949
Первая
передвижная
телевизионная
станцая (ПТС)
в МСК
март 2015
Запустился
Periscope
январь 2016
Тест
Одноклассниками
Periscope в
высокогорье
июнь 2016
OK Live
OK Live
ноябрь 2016
Insta Live
март 2017
Стрим с
высокогорья
из OK Live

3. 3
Арихитектура и ТЗ
без них нельзя вести разработку

4. Архитектура и ТЗ4

5. Что НЕ хочет пользователь5
ЖДАТЬ
Старта
трансляции

6. Что НЕ хочет пользователь6
Низкое Качество
Видео
трансляции

7. Заголовок
Видео: ok.ru/video/402843570592, автор Pladform
7 Что НЕ хочет пользователь
ЗАДЕРЖКИ
Между
стримером
и зрителем
Итак, с лесной опушки наш
специальный корреспондент – Роман!… Роман?!Так! Слушайте, Роман, я не понимаю, о
чем вы говорите!
Скажите, вы сейчас находитесь в
лесу?…Татьяна?!… … …?!… … … ?!

8. Протоколы стриминга8
SMOOTH
RTMP
RTMFM
MPEG-DASH HLS
WebRTC
OKMP MPEG-TS
RTSP/RTP
?

9. 9
Конкуренты
или с чего начать

10. Periscope10
RTMP
RTMP
HLS
"Our video streaming engine is powered by Wowza. So all of the broadcasting and
all the consuming is going through this service called Wowza.” —Sara Haider,
Periscope Engineering Lead

11. Старт, качество, задержка11
600 px 12 sec
качество задержка
<1
старт
sec

12. Задержка12
29:48
29:33
17:15
15 ms
12 sec

13. 13
Причины задержки и ее лечение
профилируем стриминг видео

14. Причины задержки14
видеопамять
encoder
socket buffer
камера
сеть
socket buffer
decoder
encoder
socket buffer
buffer
1
Кодирование/
декодирование
2 Сеть/протокол

15. Что такое видео15

16. Быстрое транскодирование16
1 Убираем b-frame
ставим профайл
baseline
2
Уменьшаем длину ссылки
до предыдущего кадра
Тюним кодек
3 Постоянный битрейт
Включаем CBR
4 H264 Server
ставим zerolatency

17. Промышленные стандарты17
Потоковые
протоколы
Сегментные
протоколы
RTMP
webRTC
RTSP/RTP
HLS
DASH
SMOOTH

18. 18
Потоковые протоколы
сложный стриминг 1 к N

19. RTMP и мобильный Интернет19

20. Потоковые протоколы 1 к N20
RTMP
Low Q Low Q
HD
FullHD
Low Q
HD
FullHD
RTMP с
нарезкойFull HD

21. TCP: Head-of-line blocking21
audio
video
RTMP
audio
video
RTMP

22. TCP-стриминг: buffer22
1 Отсутствие управления
буфером
2 Нет приоритезации
A A HD HD HD
Buffer
A A SD SD SD
Codec

23. Мобильные сети23
0.1 % 300 ms
avg packet loss avg RTT
1.1
avg bandwidth
Mbit/s
mts.arm
>3% packet loss
~600ms RTT

24. TCP–стриминг: packet loss24
Отказать 1-3% потерь на
беспроводных сетях –
это норма!

25. WebRTC–стриминг25
1 Cоздан для p2p конференций,
потребует доработок для стриминга
1 к N
2 Шифрует весь поток данных, что,
для броадкаст стриминга зря и
нагружает CPU
Отказать

26. RTP–стриминг26
I-D.ietf-avtcore-rtp-multi-stream
ref-I-D.ietf-avtcore-multi-media-rtp-session
I-D.ietf-avtcore-rtp-multi-stream-optimisation
draft-ietf-rtcweb-security-arch-11
rfc3711, rfc5124, rfc7007, rfc5506 ,rfc4961
rfc7164, rfc5104, rfc4585, rfc60519, rfc6464
rfc6904 (https://bugs.chromium.org/p/webrtc/issues/
detail?id=3411)
I-D.ietf-mmusic-sdp-bundle-negotiation
draft-ietf-rtcweb-video-06
rfc4585: NACK и retransmit.
I-D.ietf-rtcweb-fec - FEC
I-D.ietf-rmcat-cc-requirements
I-D.ietf-avtcore-rtp-circuit-breakers - congestion control
Отказать

27. 27
Сегментные протоколы
большие задержки

28. MPEG-Dash28
bandwidth
time
http://
example.com/
manifest.mpd
data 2
data 2
data 2
data N
… …
… …
… … 144p
720p
2160p
data N
data N
data 1
data 1
data 1
data k
data k
data k
Fragmented MP4

29. HLS - Http Live Streaming29
http://example.com/
high000.ts
MPEG2 Transport stream
http://example.com/
high001.ts
http://example.com/
high002.ts
http://example.com/
lowest.m3u8
http://example.com/
low.m3u8
http://example.com/
medium.m3u8
http://example.com/
high.m3u8
http://example.com/
video.m3u8

30. Проблемы HLS30
… …HLS 1.ts 2.ts k.ts N.ts
MPEG2-TS …188 bytes 188 bytes 188 bytes 188 bytes
Header 184 bytes4 bytes
40Гбит/сек по 188байт пакет = 26 млн пакетов в сек
Fragmented MP4

31. Фрагментный стриминг31
1
2
Быстрый старт
Задержка на длину сегмента
Можно выдавать сегмент на лету,
но старт всегда с опорника
3
Отказать

32. Сложность vs задержка32
t
Complexity
Latency
WebRTC RTMP HLS Dash

33. Подождем решение?33
UDP–протокол для стриминга 1 к N
с задержкой, сравнимой с p2p,
с опциональным шифрованием на
уровне пакетов

34. Пилим свой UDP–протокол — OKMP34
Многопоточность
Приоритезация потоков
Опциональное шифрование на
уровне пакетов для потока
1
3
4
Опциональная гарантия
доставки
2

35. Качество vs задержка vs реальность vs задержка35
Quality Latency
Network
t
Latency
WebRTC RTMP HLS DASHOKMP
Quality

36. 36
Разработка
пилим свой UDP-протокол видеостриминга

37. 37
2.5 % 1000 ms0.2 Mbit/s EGDE
Мобильные сети EDGE/3G/LTE/WIFI
0.5 % 600 ms1.0 Mbit/s 3G
0.7 % 220 ms2.0 Mbit/s LTE
0.5 % 110 ms2.2 Mbit/s WIFI

38. Пишем UDP-протокол38
int s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);
sendto(s, buffer, strlen(buffer) + 1, 0,
(struct sockaddr*)&sa, sizeof(struct sockaddr_in));
1
1
2
sendto(s, buffer, strlen(buffer) + 1, 0,
(struct sockaddr*)&sa, sizeof(struct sockaddr_in));
2
сеть

39. UDP. Pacer39
100%
98,40%
85,60%
1 6 11 16 21
PACER
NO PACER

40. UDP. Packet Loss40
1–3% потерь на беспроводных сетях — это норма!

41. Packet Loss: fast retransmit41
Client Server
pkt 1
pkt 2
ack 2
ack 3
ack 1
fast retransmit
+ нет избыточности
– retransmit period
pkt 3
packet
drop
pkt 3
retransmit
period

42. Retransmit period: jitter42
PING highload.ru (178.248.233.16): 56 data bytes
icmp_seq=11 ttl=43 time=117.177 ms
icmp_seq=12 ttl=43 time=132.868 ms
icmp_seq=13 ttl=43 time=176.413 ms
icmp_seq=14 ttl=43 time=225.981 ms
50 ms
avg jitter
117ms to 132ms = 15ms
132ms to 176ms = 44ms
176ms to 225ms = 79ms
(14 + 44 + 79) / 3 = 46ms

43. Fast retransmit: retransmit period (rfc6298)43
RTT
retransmit period = RTT + Δ
15 %
avg jitter/RTT
t0

44. Packet Loss: fast speculative retransmit44
Client Serverack 2
ack 3
pkt 3
packet
drop
pkt 3
retransmit
period
fast retransmit
– проблема со сходимостью
например, потеря 5% приводит к
лишнему RTT каждые 400
пакетов
400 пакетов * 0.05 * 0.05 = 1
1
fast speculative retransmit
+ избыточность только при
потере пакетов
– нет лишних RTT
2
speculative
retransmit
pkt 3
pkt 3
packet
drop
retransmit
period
pkt 4
ack 4

45. Forward Error Correction45
… +
K
FEC
– избыточность
+ Zero RTT
P
XOR
…… …
K
Reed-Solomon codes
N
PP
а если пропадет несколько пакетов?
а если пропадут все пакеты?

46. Packet Loss: negative acknowledgement — NACK46
Client Server
pkt 1
pkt 2
pkt 4
nack 4
pkt 4
packet
drop
RTT
NACK
+ прост в реализации
+ совместим с FEC
– можно потерять сам NACK
pkt3
pkt5

47. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Packet gap47
6 пакетов
avg packet gap

48. 48
2.5 % 105 ms17 gap EGDE
GAP size/Packet loss/Gap duration
0.5 % 24 ms8 gap 3G
0.7 % 29 ms7 gap LTE
0.5 % 22 ms5 gap WIFI

49. FEC+NACK vs Fast Retransmit49
<10пакетов
90% packet loss
25 ms
packet gap duration
FEC + NACK
Fast
retransmit
?

50. FEC + NACK50 1Mb/sec
1% packet loss
300ms RTT
1000byte Packet size
1000packet/sec
10
P P… …
10
1010
FEC: 500 пакетов : 500ms
FastRetransmit: RTT + data : 310ms
NACK: RTT + data : 310ms

51. Fast Retransmit51 1Mb/sec
1% packet loss
300ms RTT
1000byte Packet size
1000packet/sec
Client Serverpkt 1
pkt 2
ack 2
pkt 3
pkt 14
ack 15
retransmit
period
10 packets
drop
pkt 13
pkt 15
pkt 3
pkt 13
350 ms
retransmit period
25 ms
packet gap duration

52. UDP. Pacer и packet drop52
IPB
tt > tdrop
BIP

53. 1100 4001100
1 2
MTU: IP fragmentation53
сеть
1500
1500
Header 4
bytes DataHeader

54. MTU discovery54
int val = IP_PMTUDISC_DO;
setsockopt(fd, IPPROTO_IP,
IP_MTU_DISCOVER, &val, sizeof(val));
//выставляем пакетам флаг DF
256
bytes
MTU of Network
Interface
set packet size
1500 bytes
1100 4001100
1 2
1100 4001100
1 2
set packet size
1100 bytes
1100 11001100 1100 11001100

55. MTU distribution55
~1100bytes
AVG MTU of
OKLive users

56. Шифрование56
1 Шифрование заголовков или
всех данных
Diffie-Hellman
Адаптирован к потере пакетов2
AES-256

57. Приоритезация57
Данные Приоритет Гарантия доставки Шифрование
Метадата Высокий Гарантирована Включено
Аудио Средний < 500* мс Опционально
Видео Низкий < 300* мс Опционально
t t > t drop
IPBBI AAA M
t

58. NAT Unbinding58
Probability
Sec
ping-pong
30-60sec

59. UDP availability59
7 %
no UDP available
1 VOIP (webRTC)
2 QUIC
3 Игры

60. ДА!60
1 Задержка снизилась до 1 сек
2 Нет накопительного эффекта
задержки в плохих сетях
3 Снизилось кол-во stall’ов
4 FullHD

61. 61
Результаты
как это внедрили

62. Задержка < 1сек62
27:28
27:03
26:34
25 ms
690 ms

63. Стриминг на ОК и протоколы63
OKMP
RTMP
WebRTC

64. WebRTC 2 RTMP64
OPUS AAC
https://github.com/Blooof/FFmpeg/commit/4e3f764

65. Внутренности65
240p
360p
480p
720p
1080p
TransformUpload Java
оригинал
видео
RTMP
OKMP
WebRTC
RTMP
Storage
запись эфира
Download
Nginx
DASH
HLS
WebRTC
DASH/HLS/WebRTC
RTMP оригинал

66. Железо66
3 сервера
upload
150серверов
transform download
21 сервер

67. Отказоустойчивость и балансировка67
Storage
RTMP
OKMP
WebRTC
Upload Transform
… …
Download

68. 68
Продукт
что получилось и как применилось

69. 69
OK Live — мобильное приложение
для выхода в прямой эфир

70. 70 Прямой эфир Full HD
Android
Action
Camera
Live Full HD

71. Прямая линия с Президентом РФ и вопросы71

72. OKLive цифры72
2 тыс 3 млн 30 млн
онлайн стримов установок просмотров

73. 73 Просмотры прямых эфиров на ОК
просмотров
прямых эфиров
х3
апрель
2017
октябрь
2017
Просмотры
прямых эфиров

74. OKLive хранение записей стримов74
50 тыс +17 TB/
сутки +1 PB
стримов в сутки записей стримов всего видео в месяц

75. Что получили МЫ75
гарантию задержки между стримером и зрителями1
непрерывный стриминг даже при потере части оборудования
2
балансировка нагрузки во время популярных3
стриминг в FullHD на динамично меняющемся мобильном Интернет-канале
4

76. Что узнали ВЫ76
что такое видео и как его
стримить1
как писать свой UDP-протокол2
архитектура стримингового
сервиса3

77. Контакты77
Александр Тоболь
ведущий разработчик
alexander.tobol@corp.mail.ru
спасибо